Show HN: A ncurses CRM system (and accounting)
63 comments
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 want to be able to create an ncurses app first and then have a renderer create a web app from the ncurses app.
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.
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.
re. UTF-8 support: ncurses does include this, in libncursesw. It seems to work, although I haven't tried anything outside of Latin-1.
Probably someone will remember this https://en.wikipedia.org/wiki/Turbo_Vision
Turbo Vision is a DOS-based character-mode text user interface (TUI) framework developed around 1990 by Borland for Pascal, and C++.
Turbo Vision is a DOS-based character-mode text user interface (TUI) framework developed around 1990 by Borland for Pascal, and C++.
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)
Why not use https://github.com/Yomguithereal/react-blessed ?
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.
Thanks for your support.
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.
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.
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 appreciate your feedback and will definitely reach out to hacker news as soon as I've something for you to play with.
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.
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.
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.
Love the project :)
Can you create an OpenGL interface in voxels please.
Can you create an OpenGL interface in voxels please.
Waiting for Turbo Vision version :)
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.
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.
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.
don't create a web interface please, maybe there needs to be a way to render ncurses in the web.
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.
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.
You'll want to check out "react-blessed", a way to use Blessed through React -- which enables common UI code for both web and terminal.
https://github.com/Yomguithereal/react-blessed
https://github.com/Yomguithereal/react-blessed
Thanks, very interesting. I didn't know about blessed before.
I'm glad I could help.
If you write a blog post about the CRM and your experience in writing it, that would be a fun read.
Good luck!
If you write a blog post about the CRM and your experience in writing it, that would be a fun read.
Good luck!
> 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.
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.
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)
Just out of curiosity: what prompted you to make it ncurses based?
I can see lots of reasons why this could be practical but most of them (like bad network connection or slow hardware) belong to the past.
Is it just a personal preference or aesthetics?
I can see lots of reasons why this could be practical but most of them (like bad network connection or slow hardware) belong to the past.
Is it just a personal preference or aesthetics?
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).
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).
What's old is new again!
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.
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.
Probably correct. And given that you're spending a comparatively small amount of time in that learning phase, would you want it any other way?
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.
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.
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 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 single database would require a constant internet connection and would be much slower.
I aim for 0.1s feedback, and that's hard going over the network. See https://www.nngroup.com/articles/response-times-3-important-...
I don't think it's such a bad idea for production customer data. Actually I think it's a great idea and wrote my master thesis about that: http://fileadmin.cs.lth.se/cs/Personal/lars_bendix/Teaching/...
I would love to hear why you think it's a bad idea! Would you care to elaborate?
I aim for 0.1s feedback, and that's hard going over the network. See https://www.nngroup.com/articles/response-times-3-important-...
I don't think it's such a bad idea for production customer data. Actually I think it's a great idea and wrote my master thesis about that: http://fileadmin.cs.lth.se/cs/Personal/lars_bendix/Teaching/...
I would love to hear why you think it's a bad idea! Would you care to elaborate?
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.
To get a reasonable real world working application I believe I've to do something like that. Thanks =)
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!
Is there a link to the source or a project page?
Not yet, it's something really early and I haven't had time for a project page yet.
Still figuring out if I should make this open or closed source. Hard choice!
I definitely reach out here again once I've project page up and running.
Still figuring out if I should make this open or closed source. Hard choice!
I definitely reach out here again once I've project page up and running.
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 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.
Thanks for the comments. I can't say I miss those days (I'm too young) but I do miss responsive applications.
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/
Looks pretty nice though!
Looks pretty nice though!
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).
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).
Not editable? Local laws are obviously misguided, because everything is editable.
There's really no need to edit accounting data, because any mistakes can be fixed with additional journal entries.
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.
It should be possible one day for ncurses to serve a web based app and a theme folder.
I'd much rather create an app in ncurses as a developer and then include ncurses-web (if it existed) compile and give the .css file to a designer.
I'd much rather create an app in ncurses as a developer and then include ncurses-web (if it existed) compile and give the .css file to a designer.
Cool. Out of curiosity, what language is it written in?
(Fellow ncurses fan here ;))
I love this. I've been thinking about the error we've made in stuffing so many enterprise interfaces into the browser (I say this as a web developer).
Somehow we decided to trade-off upfront training (no longer required) for long term speed & productivity (no longer available).
An interface that can be used by anyone with almost no training, is almost certainly a low productivity interface.
I haven't expressed this very well. But, in short, I love this and would download and use it tomorrow.
Somehow we decided to trade-off upfront training (no longer required) for long term speed & productivity (no longer available).
An interface that can be used by anyone with almost no training, is almost certainly a low productivity interface.
I haven't expressed this very well. But, in short, I love this and would download and use it tomorrow.
https://asciinema.org/a/0g9f8c00mrkm018p10r8p8km3
Please share your thoughts