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.

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.

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: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