2 ms·

Ask HN: Is it worth to build a TUI-based ERP software?

So, my company is about to begin a new project to deliver an ERP-like application. There are currently no strict requirements regarding the technology stack to be used. Ease of deployment is desirable, but even that could be traded for, for instance, faster development times. I'm a big fan of old-school text user interfaces, like the ones we used to have with Clipper. I'm of course aware of its many limitations, but, to the best of my knowledge, its simplicity is unmatched by more recent technologies. So I'm seriously considering building a POC consisting of a web-based client operating as a specialized dumb terminal (performing some app-specific functions, like report printing, besides its basic terminal stuff), accessing the TUI-based main application in the server side. We believe it's going to be possible to detect most of the limitations of such approach with that proof-of-concept, but I also considered asking the community looking for other ideas and limitations I may be ignoring at the moment.

sfgweilr4f 6y ago
Depends on who the clients are. I've got a todo / schedule / calendar thats purely text. But thats just what I like.
jbn 6y ago
TUI for order entry or accounting sounds great (worked with such a system in the 90s, clerks achieved amazing speed using such a system, it would be all but impossible using "modern" web interface), but most of the reporting/dashboarding (i.e. high level views of the data) would be better in a more modern fashion. Under a TUI you could have something that communicates with the backend using modern web technologies, that sounds great :)
- throwaway135703 6y ago
  Indeed, some of our main concerns are about user speed. We also know some concrete use cases where 3 decades old systems are still in place because none of the previous attempts at modernizing the application were able to allow for even half of the speed -- and, in one of those use cases, user speed was really, really mandatory. When I talk about those cases, people usually argue that those systems are being used by "old farts" who will always resist to the change. However, it's really interesting to notice that even the younger users prefer those old systems because of their reliability and speed. Overall, I think there's a huge misunderstanding about UX. I mean, things like Material Design animations and icons are nice but, in business applications, users want simply to query/input their stuff from/into the system and leave and go to do the rest of their jobs. They don't want to feel "pleased", they don't want to "experience" the software. The software should operate as an extension of their minds and they don't even want to realize they are using it.

sfgweilr4f 6y ago

Depends on who the clients are. I've got a todo / schedule / calendar thats purely text. But thats just what I like.

jbn 6y ago

TUI for order entry or accounting sounds great (worked with such a system in the 90s, clerks achieved amazing speed using such a system, it would be all but impossible using "modern" web interface), but most of the reporting/dashboarding (i.e. high level views of the data) would be better in a more modern fashion. Under a TUI you could have something that communicates with the backend using modern web technologies, that sounds great :)

throwaway135703 6y ago
Indeed, some of our main concerns are about user speed. We also know some concrete use cases where 3 decades old systems are still in place because none of the previous attempts at modernizing the application were able to allow for even half of the speed -- and, in one of those use cases, user speed was really, really mandatory. When I talk about those cases, people usually argue that those systems are being used by "old farts" who will always resist to the change. However, it's really interesting to notice that even the younger users prefer those old systems because of their reliability and speed. Overall, I think there's a huge misunderstanding about UX. I mean, things like Material Design animations and icons are nice but, in business applications, users want simply to query/input their stuff from/into the system and leave and go to do the rest of their jobs. They don't want to feel "pleased", they don't want to "experience" the software. The software should operate as an extension of their minds and they don't even want to realize they are using it.