I've been building a CRM/accounting system for my personal small company. It's still in an early stage and is lacking a few features. But it is finally usable.
I like ncurses, and have been a fan of this interface for 20 years. I know that these days, we are supposed to build web interfaces, push them on to a load-balanced server and so forth, but I think small tools which can be run on the linux terminal are still relevant. Whenever the application is a single-user app, and the data not too huge, this kind of an app has its charming simplicity. I am not an expert developer, but I like this project!
I have used ncurses to build a simple backend interface, that I use for testing new features etc. The end result looks nice, and is functional, but ncurses the library is a pain. It feels like something that would not be written by a programmer today: C, manual pointer-management, the interface feels too low-level. I ended up writing a C++ wrapper around it, adding thread-safety, better scrolling and some convenience functions (the ncurses form library I believe was a particular pain).
What I would like is a high-quality redesign of ncurses with a modern C++ interface.
A modernized curses library with clean UTF-8 support would be really nice. There's no need to make it a drop-in system library replacement, either, so there's no need to maintain ABI compatibility, as ncurses does.
Perhaps a more fruitful approach would be to generate both from a common abstraction. Otherwise, you either impose ncurses look&feel to the web (might look like a web terminal emulator), or you force the web into the terminal (might look like a text browser e.g. w3m, lynx, links, elinks)
you'd create a markup with component names, instead of html. so you'd have panel, button, divider, pane, window, menu, etc as tags. you can then render those using polymer or react etc. and none of it is polluted by garish html.
A comment about the single user and huge data. I've a test database with 100 000 account, 1 000 000 events, etc. That is about 2 gb in size. Not huge, but not tiny either.
There's no multiuser support yet, but I plan to add it.
Wrong, if the data is huge it is better to have it running totally on your machine. This is the most scalable as you can get, plus you get infinite bandwidth.
Beautiful and reminiscent of old school mainframe systems in CICS.
When system users were mainly roomfuls of data entry staff (universally female) these systems were absolutely optimised for power users banging through as many transactions as possible. No mice in sight, all keyboard operation.
My thought is that such interfaces are bad for learning software and for get a good overview. But when you're a power user of a certain system (like the data entry staff) there's nothing that's better.
I would prefer software that I use often to be hard to learn but easy to use. Seldom used software should instead be easy to learn, hard to use. I find that most software today is in the latter category.
The reality is the world has moved completely away from terminal. The speed and productivity advantages are well known, but no one cares. By no one, i mean sales and procurement who hold cobol/green screen apps in very low regard. In other words, it's very difficult to sell trerminal applications when the competition is browser based i.e. insurance claim processing
Sell them what they demand with a browser-based presentation, then package the terminal-based presentation as a separate, paid add-on option for high-volume customers. Market the add-on as meant only for high-end customers who will take the time to train staff in the kind of high-speed entry that only the terminal-based presentation can keep up with. Sprinkle in some stats about some multiplier of efficiency and accuracy improvement, then let the customers implement what they prefer.
Between advances in ML-based OCR and dictation, I anticipate future data entry to get much more sophisticated, and demand extremely low-latency, quick-updating screens that might bring about more awareness of terminal-based interfaces in some situations.
It seems a bit silly to write an accounting system, this is no easy task once you get to the complicated bits and pretty fatal if you screw it up. Surely saner to throw a curses interface on top of an already existing one? Like https://github.com/beancount/beancount or http://ledger-cli.org/
Storing accounting information is not that hard. Generating reports on them is. I know about ledger and beancount and will definitely look into them.
Unfortunately local laws demand each verification to be enumerated and not editable. That's something ledger and beancount doesn't provide to my knowledge. (and this again proves your point, writing accounting systems are hard, perhaps it's better to stick with the CRM bit).
Accounting software must not provide the means for you to do it. You can hack it of course, like anything else, like you could fix your books in the old days of paperwork, but it's you then who breaks the law, not the app author.
Thanks for sharing! It seems that computer systems have regressed heavily from decades ago when every keystroke resulted in an instantaneous action, even with hundreds of simultaneous users. I miss those days of simple tui's.
I do most my work in the terminal, using vim and mutt. I wanted something fast, I can't stand waiting for a webpage to load. That's not a good user experience for mem.
So I tried to mimic vim (fast load times and no use for a mouse). Then ncurses was a natural choice because I wanted to be able to reach the app from everywhere (at least until I've made it network aware).
I absolutely adore this. This reminds me of the old AS400 greenscreens I used to work on. Clean, fast, and everything within finger's reach. Can't wait to get home and play with this a bit.
I'm sorry, but all I've right now is a video. The software isn't ready to be released and I'm still thinking about how it should be release (closed or open source).
I appreciate your feedback and will definitely reach out to hacker news as soon as I've something for you to play with.
I remember how, when I was child, video store clerks used to operate this kind of systems blazingly fast, knowing all the key shortcuts by heart and achieving incredible productivity.
This reminds me that I used to do my Dad's Tax return preparation with MONEY.BAS (QBASIC) for far longer than we had any right too.. definitely in the 2000s.
This is lovely. There have been a few projects floating around HN aimed at personal CRM lately, and I could see this being an excellent interface for such a thing. I'd love to know more: how is the data being stored / how configurable do you plan on it being (custom objects, fields )
Thanks for your support. The data is stored in a sqlite3 database. The next two big features will be network awareness (that is, you can have multiple databases sync with eachothers) and custom data fields where I was planning doing something like http://backchannel.org/blog/friendfeed-schemaless-mysql to get a fully customable configurations.
Instead of multiple databases in sync, why not use a real RDBM such as Postgres and have the clients sync to the master. The distributed databases-in-sync idea feels a bit like Git, which I love for code but would hate for production customer data. Those types of things need a canonical representation.
I definitely agree that you should continue to use sqlite as a local cache and read from it for initial display. But I believe that on save writing back to a central server and occasionally polling it for updates would provide many benefits, the most obvious of which is decoupling the UI from the data. See my reply to self in which I mentioned a possible HTTP interface.
Reply to self. Another advantage of having a master database would be to allow rodent-dragging hipsters to write their own web client using a dozen Javascript libraries and get the latency that they would otherwise miss!
I love this, but I would instantly want to access the info from mobile.
I'm a heavy Evernote user. About once a year I look for a replacement and consider rolling my own low tech CLI interface. Then I remember all the notes I take on my phone and how often I use the web version to look things up.
You said above, "...local laws demand each verification to be enumerated and not editable." That suggests a good value from open-sourcing where you can get 3rd party validation on your operations and security.
Thanks! It's written in C for the reason that I want to become a faster C developer. It hasn't always been the most convenient experience but I sure get better in writing C :).
A web based interface IMHO would be more usable. However nice project. I am an emacs person so using the system via a vi-like editing style seems hard to me.
Maybe you could automatically generate invoices with LaTeX and save a pdf, that would be cool.
Also, you could add an account overview, where you could see the balances of all your accounts, compare it with previous periods. Paint them red if you're expenses are soaring etc. Maybe some graphs...
You could also prepare a screen for financial indexes such as cash flow, debt-capital ratio etc.
Hi,
I'm the developer. Thank you for your suggestions. I must make you dissappointed that there's no plan for emacs style keybindings at this point.
The system has a very clear API between GUI and backend, so future plans is to add more interfaces, a web based one is on the list (although IMHO web based interfaces are worse to use).
The LaTeX idea is great, so great that it's already done. I tried to keep the video short and don't show all features. I also have integration with mutt. Sending a new invoice is just a keystroke away and then mutt is opened with an attached pdf and a template mail body.
The account overview is the biggest weakness right now and something I look forwared to improve. I definitely take your suggestions with me towards that work.
While your idea of auto generating web gui might be nice (I haven't seen it in action yet), there's no such solution what I know on the market yet. I want to be able to have a native feel on every platform. That means a web UI, a windows UI, an Android UI, etc.
Therefor my current solution is to have a really tiny presentation layer that is able to adjust to multiple UI.
if you look at blessed for example https://github.com/chjj/blessed you'll see that the widgets fit every use case you would need for a webapp, but just need to write a wrapper for web rather than ncurses if that makes sense.
> A web based interface IMHO would be more usable.
I'm sure you're not the only one but I can see how this could be much nicer than a Web UI for someone (like me) who prefers Vim and Mutt over Atom and Gmail.
I have a supicision that OP is also a Vimmer who (like me) gets upset when a user interface doesn't accept hjkl and all the other idiomatic Unix/Vi keyboard commands.
ncurses should just be seen as an unthemed webapp, it's a shame devs can't just create an ncurses app and themed it into a webapp without touching html/css
The more tools the better, one with a web interface would work better for some, less so for others. Even better if they can use the same format (i.e Ledger)
