Text Based User Interfaces in the 21st Century?

Jaap Geurts asks: "With the 3D GUI desktop around the corner, nobody seems to use or think about text based user interfaces (TUI) anymore. I know that hardware comes cheap nowadays but can the use of TUIs still be justified? I've always found that GUIs are resource hungry, generally slower and more importantly they often allow multitasking and they are very unpleasant without a mouse! What do you think about developing a (well designed) TUI for DB software (e.g Point of sale, Warehouse manager, etc)? Most current GUI metaphors can be implemented so what are the pros and cons from a user perspective?" Are there any real reasons against deploying text-based applications, today?

Lowest Common Denominator

[ka9dgx]

The fact is that a console screen is fairly easy to generate, heck even the IBM PC BIOS supported console input. You'll always have it there when you really need to dig into the guts of a system.

It takes a lot of things going just right in order to be able to display and keep a GUI going. In terms of RAM and CPU cycles, a console session is a few orders of magnitude cheaper to run.

--Mike--

An idea: you could start with newt

[Ayanami Rei]

Newt [redhat.com] is a toolkit for making text mode user interfaces. It has C, TCL, python and perl bindings.

It's a RedHat thing but it's apparently become popular (available on Debian, FreeBSD, well anything that has ncurses). It supports UTF-8 which is nice.

That'd sort of be your toolkit (ala GTK). So you're halfway there.

best text user interface...

[burns210]

... was turbovision. it ran turbopascal and turboc++(others?), and was a desktop/windows UI using text characters as windows and such, very powerful and light weight. Would be awesome to have a 'gui' over ssh command line action. one example [bitsoft.com] off of Google Image Search. Very cool system, and it is GPLed, too!

Re:GUIs vs TUIs and menu vs command

[Ender_Stonebender]

From your comments, I'm guessing you don't have a lot of experience with TUIs. I work for a company that does credit card processing on Tandem computers (that's a brand name, not just a funny name for an SMP system (although it's that too)), and we have text-based interfaces to *everything*. ...and here's why you're wrong:

* "Must fit on a standard console (24x80)" and "Use of more input elements per screen". Any decent TUI will allow you create multi-page interfaces. Some of our TUI screens have 32 pages worth of data! (Granted, those are the inefficiently-built, difficult-to-use ones; but they are definitely still useful.)

* "Familiarity to users". Not really a big deal. TUIs tend to be very simple, and a lot of things that work in [insert your favorite GUI] work in TUIs as well - tab to move between fields, there's a standardized help key, etc.

* "Windowed interfaces". There are plenty of systems out there that let you work on multiple sessions through a single screen. And we've still got several people from the Old Skool Daze when "personal computer" was an oxymoron and access to the Tandem meant that you had a Tandem-built dumb terminal on your desk (they've got some weird protocol they use) who, even in a windowed MDI environment will have no more than two terminal sessions open.

I can't argue about the "able to display images" part though.

--Ender

Re:TUI?

[nathanh]

First off, I've been using the TUI since the old Commie 64 days (the ay-deez). But, for some reason in all my readings and various meanderings through computer sci I've NEVER heard a command line referred to as a TUI!

That's because a TUI isn't the same thing as a CLI. A TUI is like those DOS programs written with Borland Turbovision. A picture is worth at least 78 words here. This is a CLI.

$ ls
bar baz foo
$ rm bar
$ ls
baz foo

And this is a TUI.

Well I'd like to give you a picture here, but Slashdot thinks TUIs are too lame.

Examples of TUIs on Linux include mutt, links, pine... I suppose emacs and vim. They're a little zany but their distinguishing feature is that they're all text and they aren't command-line.

Two Major Reasons

[pete-classic]

1. Scriptablity.

You can write a shell script for most tasks that you already know how to do from the command line trivially. Others can be a bit tricky, but tools such as expect usually make it possible.

Scripting a gui is usually only possible with special applications that scrape the screen and allow you to make macros. Some gui apps (notably KDE) have built-in scriptablity, but only to the extent that the developer goes out of his way to add it.

2. Efficiency.

For a good discussion see "The Pragmatic Programmer."

While textual interfaces have an inherently steeper learning curve, they are far more efficient for the experienced user.

This manifests in several ways. For example; all command line functionality is at the "top level" of the interface. One needn't click start before invoking grep, or click a pull-down to get to the case-insensitivity option.

-Peter