Slashdot Mirror
Which Text-Based UI Do You Code With?
JHWH asks: "I've been asked to design and implement a management software system with text based user interface as the replacement of an older one running on AS/400. Despite my attempts towards a web UI, the customer is actually willing to have a text based UI. The main reasons are the need for a very low bandwidth and the ability to run on serial terminals. All this in the 21st century! Host systems will be Linux, the language will be C or C++. I already thought about the use of text based browsers like lynx or links. So now I have to wipe the dust away from my ncurses manual, or can Slashdot suggest something more effective?"
Web interfaces suck in so many novel and unique ways. There's the session timeouts. There's the non-interactivity. There's the random bugs on every browser, and the huge mass of compatibility code required to support all of them. Then there's the web app that requires Sun Java and the web app that requires MS Java, both of which run only in IE, and both of which are supposed to run ON THE SAME MACHINE! (I have to deal with that situation once. Royal pain in the rear-end. I don't remember how I solved it, actually...)
If you want a decent UI, don't bother with web-based stuff. Use a product like RealBasic, do it quick and make a CLI to do all the heavy lifting on the back-end.
Comment of the year
Compared to web, it has advantages that the original poster enumerated, as well as:
- support for hotkeys and shortcuts (especially big for manual data entry/call centre users)
- ability to easily rescale + resize to fit into available screen real estate.
It's simple for a terminal emulator to scale down fonts when the window is resized. Try that with your average GUI or web page.. not to mention component layout issues when dealing with GUIs. This may sound dumb, but it can be a big issue for call centres having to juggle multiple apps but with only one physical screen.
- simplified deployment (yes, even simpler than web) - no issues with browser versions, plugin conflicts, etc etc.
- SPEED! Compared with the latency of your average web front-end.
Issues like this really add up to a big difference for apps that are used intensively.
somebody in ##slackware on freenode
once recommended me to try using the slang API
instead of (n)curses based on the fact that he bought a ncurses book
and it sucked monkeyballs and programming ncurses is not really intuitive
some of the other fine folk who regularly sit idle in that channel
also said that if it could be done in a Shell script
you could try using shell and dialog which is a ncurses based program btw
this could obviously be a biased opinion from slackers since the pkgtools in slackware http://www.slackware.com/ are written this way
and they have served us fine for many years
and will continue to serve us happily for many more years to come.
anyway good luck
Just write ansi escape sequences to the screen
...? Which version? They all support different subsets/extensions of the "standard", and have different bugs.
And you will then discover some of the reasons why you should have used ncurses in the first place:
1. Does the cursor jump to the next line when you hit the 80th column?
2. If you type a character in the lower right corner, does it scroll up the screen?
3. Are they going to bring in some non-ansi terminals and expect you to make them all work?
4. Which subset of the ansi sequences are going to be available? Using xterm, gnome-terminal, putty, ansi.sys,
5. What other intresting "bugs" in all the possible terminals do you need to work around?
I'd rather use a library that already handles all the crap.
Who would win this election: Andrew Weiner vs Andrew Weiner's weiner.