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?"

Comments

What's wrong with ncurses?

[Secret Rabbit]

IMO, unless you can give a good reason why you shouldn't use ncurses, use it.

Re:What's wrong with ncurses?

[SenFo]

I'm not sure I agree with you. When I was first learning to develop in C, I went the route of implementing ANSI directly and, in the end, I wished I had known about ncurses. I spent a lot of time designing a UI because I had to essentially write everything from scratch (functions to draw shapes, buttons, etc.), whereas I could have designed it pretty quickly had I used ncurses.

I went the ncurses route on a robotic project I developed a few years back and things were way easier and the end result was much more desirable. I was using code that had been in development and tested for years rather than some fun project I built in my spare time at home.

I highly recommend not reinventing the wheel unless you have a really good reason.

what's the problem?

[Anonymous Coward]

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.

It sounds like the client's needs are thought out and perfectly reasonable. The problem seems to be with the person they've asked to do the job.

Re:what's the problem?

[belmolis]

What's your beef? The guy is asking about the best way to do what his client wants, not opposing it.

Re:what's the problem?

[Arker]

Nonetheless, he also appears to express astonishment, dismay... the comment about what century we're in betrays him. There's absolutely nothing wrong with a text interfaces, in fact quite the contrary.

Re:what's the problem?

[Anonymous Coward]

Exactly. I'm the grandparent poster and I can only see this ending with one outcome (based on a lot of experience). Because the submitter is begrudgingly doing this and feels that the client is asking for the wrong thing (nevermind that they've clearly expressed their reasoning for their requirements), he's going to do a half-assed job and come back with something along the lines of "Well, it would've worked better if you had used a web-based interface." If anyone from the client company is reading this, I'd suggest finding someone else to do the job.

I'd rather have text than web

[Blakey Rat]

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.

Re:I'd rather have text than web

[jonabbey]

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...)

Ah.. 1997 called, they want their rant back.

Seriously, Java's pretty clean and clear now, and much better than once it was. Especially with Java Web Start.

Does nothing to help the original poster, but there you are.

Text based UI is underrated!

[mikeburke]

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.

Re:Text based UI is underrated!

[mmogilvi]

Another related text interface benefit is support for essentially unlimited type-ahead (typing in stuff faster then the computer visually responds to it). In GUIs, single windows generally support type-ahead, but it typically does not work if a dialog opens or closes.

Re:Text based UI is underrated!

[Anonymous Coward]

I agree that text based UI's are underrated.

In 2000, I worked for a very small (5 people) mail order photography store. We had a nice text based system. The owner decided it was time to get with the times and he purchased the newest version of the software which was a graphic UI. Almost every keyboard shortcut was eliminated and the tab order was atrocious. The other guys loved the new UI, as they got to use their mouse. Me? I prefer not to touch the mouse when doing data input in a call center, even as small as that one.

From 10/01 until 11/04 I worked in a mortgage call center. We received phone calls from banks and other lenders and purchased the loans they had made in order for them to free up money to loan to newer customers. Yes, we were part of the reason many people had to change where they sent their mortgage payment to. Anyway, we used three systems for our data entry. One system was on AS400 via a terminal window in Windows95. The other two were NLPS and LPS (I do not remember much about them except that I hated them. NLPS and LPS were both text based also, but LPS had a two step process. First the basics were done in a text UI, and then pulled into a graphics UI. That graphics UI had a bad tab order and only had three usable keyboard shortcuts, so I was forced to use the mouse. In my entire time there the AS400 system only went down once, and it was down for about an hour. However, the other two were down constantly. I don't care to know how they were networked or what the server was. I just know that many people hated the AS400 data entry system and loved the graphical UI entry system. I received a good number of pay raises due to my speed of handling customers. This was due to the text based UI of the AS400 system we used. The tab layout was clean; I could read the text no matter what I scaled the window to; Everything worked correctly; Keyboard shortcuts were efficient and well done. I loved that system. When I left they were trying to get everything switched over to a web based system. I tested that for them, I hated it. If it was not for the stroke at age 27 while working for them I would have quit when I hit 28, lol. I will never work attached to a phone again.

But to state again. A text based UI for data entry is much more intuitive and allows for quicker processing. Of course that is if the tab order and layout is done correctly. The mouse should only be used when designing graphics and such or when playing games. Data entry or word processing, it should not have to be touched at all.

What's wrong with text screen GUIs?

[Anonymous Coward]

"Console apps can run *QUICKLY* on any old system of just about any OS or architecture with any speed CPU with any amount of RAM with any amount of bandwidth."

DesqView, PCtools for DOS.

Re:Emacs Trumps

[tomhudson]

The article title has nothing to do with the article contents.

... the title is "Which Text-Based UI Do Yo Code With" - not "Which Text-Based UI Library Do You Write To/Compile Against".

Re:omg

[ralphdaugherty]

...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'm an AS/400 guy, used to be a PC programmer. I'm trying to understand this, any comments appreciated. What's clear to me is the company is converting from an AS/400 to Linux (yes, Linux runs concurrently in partitions on the AS/400, now called system i after several name changes, but I'm also assuming they want a cheap Linux server).

      I remember in some early programming (I was original programmer for Melita Electronics, later International, they did well :) hooking Wyse serial terminals to a PC and controlling multiple terminals from a PC with a multi-serial port board.

      The AS/400 of course has not had serial terminals, they have 5250 terminals or PC terminal emulators over TCP/IP now, IBM networking before that. So I take it this serial port thing is a throwback to what I used to do because this company says, we have a Linux PC server, let's hook up cheap serial port terminals? With serial communications limitations and dirt cheap PC's able to run any kind of terminal emulation cheaply, something very strange about that to me.

      The best I can tell from this is the purpose of NCURSES would be to emulate 5250 PC emulation with a serial port terminal emulator. But like I say, any clarifying comments welcome.

      The replacing a "management software system" equivalent to what they had on the AS/400 in C++ on Linux would seem to be quite a job in itself. All of the work that NCURSES does is taken care of by our 5250 I/O subsystem. That's quite a lot of I/O detail that he will have to insert into the replacement.

      By the way, NCURSES doc says it runs on any POSIX platform, and the AS/400 (which is usually called iseries now) has a C++ compiler and is POSIX compliant. The C++ modules can be bound together with modules from any other language on the iseries into an i5/OS program.

      It could communicate with anything over TCP/IP, but I would have to check if we can rig up serial ports for terminals. :)

  rd

Re:Something you might look into

[kbob88]

I agree: Ruby + ncurses for the UI, calling C/C++ modules to do whatever heavy lifting you need (if any).

There's no reason in this day and age to write a non-performance-sensitive UI in C or C++! Especially a text based one. Why would you go through such hell for a task that doesn't require optimal performance? Seriously: you can learn Ruby and code the UI in less time than it will take you to code it in C or C++. I guarantee it. Plus it will be a lot more fun. And you can link in C and C++ modules to execute any performance-sensitive tasks.

Unless there's some reason your text-based UI needs optimal performance, but I can't think of one offhand... I've sworn off all C/C++ development unless there's an overwhelming reason to use them. Heck, I don't even use Java much any more -- it's mostly all Python and Ruby, with an occasional module in C/C++ for performance.

You should be able to whip out a text-based interface using these tools in no time, even if you've never used Ruby. Like tonight. Or maybe over the weekend.

And no, I'm not some Ruby fanboy. I've got over 20 years professional programming experience, plus another 8 years non-professional. I've used many languages over that time. It's all about the right tool for the job. Python would be another great choice (perhaps even better because of its more extensive libraries). But C and C++ are definitely not the best tools for the job. (Unless there's something you haven't shared with us.)

64bit browser plugin

[Builder]

1997 can have its rant back when someone tells me how to run java apps inside firefox on a 64bit machine. Installing 32bit firefox on 64bit FC5 is more grief than I ever thought would be possible, and Sun don't have a mozilla plugin for 64bit Linux.