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?

Comments

No reason not to

[adamjaskie]

Text based interfaces are better for some things, GUI for others. I don't use a text based web browser, but many other programs are great in text mode. The best thing about X is I can run lots of xterms all attatched to the same screen session.

Depends on the type of machine

[bulldog2260]

On my SPARC's and on my Mac running OpenBSD, I have found that the GUI is faster since the frame buffer has limited RAM, and therefor runs pretty slow at times. I have to agree that some GUI's are resource hogs, but with a small window manager on X, its just fine.

What's going on here?

[Gleng]

Text based user interfaces? DOS Games?

What is this? The Dark Ages?

Ah, I see. We must be experiencing some latency from the frame dragging.

TUI emphasises transaction based interaction

[danpat]

I've always found that in situations where I need to refer back to things that I've done (i.e. why exactly is my filesystem empty? Oh dear, a space in rm -rf asdf *) a serial, text based interface is the fastest way to work. You can quickly look back over operations you've performed in the recent past. The interface is consistant too, so any number of different operations look the same, no new interface to learn.

GUI's on the other hand are good where you don't need that audit trail, or the information for the audit trail is unlikely to be used and can be condensed into a text-based format of some kind (think saving the undo-log in a wordprocessor to disk).

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

average users

[cloudless.net]

The average users don't want to remember text commands and syntax, it is as simple as that. Yes the command line interface is more efficient at many tasks, however the learning curve is deeper.

Re:average users

[yuri benjamin]

The average users don't want to remember text commands and syntax

Text-based != Command-based.

There is such a thing as text based menus. POS systems in department stores are often text/menu based, although they are moving to GUI I've noticed. I see no benefit in having a GUI client for a POS system running on Windows(tm) when a 3270 session (or similar) would require cheaper hardware at the checkout and less futzing with the mouse (keyboard-entry / barcode-scanner-entry is quicker than point-n-click). It's not about looking pretty, but being able to process transactions quickly.
I work in a call-centre where average handling time of calls is the most important metric (actually, customer satisfaction is more important IMNSHO, but that's harder to measure so they go for AHT instead). We use several different clients to various customer databases and billing systems, and the text-based (3270) clients are so much faster than the gui ones. The drive to swith to GUI for the sake of using GUI is one of my pet peeves.

Re:average users

[Hes Nikke]

i started working at my local CompUSA as a sales drone (please no jokes - i've been done there for years) when it 1st opened, and we had dumb terminals for our POS and inventory. this meant that a sales person could generate a quote at any inventory station, hand the customer a piece of paper and they in turn hand the paper to the cashier who enters the number at the top and takes the money. the cool thing (in my inexperienced humble opinion at the time) as that as sales (and returns) went through, the inventory would be updated in real time.

fast forward 3 months (yes, 3 months after the store opened!) and we moved over to a stupid frame-buffer based POS (it wasn't a GUI, you'll see why soon) that ran on some form of NT (i'm guessing NT4 because they looked like windows95 but these things had 24/7 uptime) now the cashiers had to know what key to press to do a specific thing (yes the dumb terminals had this too, but then they/we could tab from field to field) one operation at a time (it wasn't driven by the screen - as that was used to show the current recipt, and advertisements - but by the little green thing that shows the total!) with the new system, generated quotes were next to useless, (and soon we stopped generating them, and all but 1 printer used for those quotes disappeared from the sales floor) and, here is the best part: the inventory took up to 3 days to refresh! oh, we could still look up the all important % of service plans to everything else sold, but we couldn't rely on the computer to tell us what was in stock!

soon lines grew, due mostly to the lost productivity of the cashiers, and they haven't shrunk since.

today? the cashiers who knew the old system (yeah, there are one or two left) miss the good old says of the dumb terminals, and CompUSA still uses the POS that is a POS.

the moral of the story? If it ain't broke, don't fix it. especially after only 3 months from rollout.

An idea: you could start with newt

[Ayanami Rei]

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

Library Catalogues

[stick_figure_of_doom]

I was just thinking about this today when I skipped down to the local public library to pick up some books for school. Whenever I go there, I grab the text-based console hickey instead of the new-fangled web-page based ones. Whoever designed that text one was a genius, and I wonder if the source is out. Truly, all the formatting and really small links on web pages only serve to get in the way of simple tasks like this one, and the omission of the mouse made it faster. Forced to use a mouse, I would waste precious time moving my hand around. Mice are the devil.

Are there any real reasons against?

[FFFish]

A: Yes. You'll have a bitch of a time getting anyone to actuall pay for your work.

Reality is, PHBs and the minions want point-and-click. It may be slower, it may require more resources, it may make things more complicated, but it means they don't have to think.

Which, really, is probably for the best. Who wants a PHB that thinks?!

Lots and lots of terms in a screen session

[WayneConrad]

When I started my current job, my boss gave me his box and built himself a much faster one :) I put up with the fans in his old box for only a day before I decided I had to do something. I moved the box into the server room and brought in my laptop to use as a terminal. No more fan noise!

Pretty quickly I discovered that if I run all of my terminals in a screen session, I had much better control of them than if I ran separate xterms. You can only fit so many xterms on an X screen before you have to start using virtual screens, but you can easily fit dozens of terms into a screen session (I recompiled screen so I can have a hundred: I ran into the Debian version's maximum of 40 a few times). The best thing is, I can switch between them without using the goshdarned mouse. By giving them names, I can call them up with just a few keystrokes. Oh, it's nice. No more hunting. I want the screen I'm using to tail the apache log? It's ctrl-A ' log and I'm there.

When I go home at the end of the day, I just disconnect my screen session. When I ssh in from home to do some work, or when I come in the next day, I just run "screen -r" and I'm back where I left off. Exactly where I left off. No time wasted starting up xterms and getting them moved around. The log term is still tailing the log, the edit term is still in emacs, the test term is still waiting for me to run the tests again.

When I ssh into the noisy workstation, I use -X so I can run X applications if I want to... now and then the Gimp or feh or gv or some other GUIish thing, but running lots of terms in a screen session does lend itself to text mode applications. My email program is Pine, all text driven, and I like it just fine. Emacs in text mode, of course (no button bars for me!): Usually an emacs for each active project. When I switch from one task to another, I don't have to do anything but switch to the right screen session and start typing.

Text-mode programs and screen are all I need to rule the world (or at least the part of it that sits on my workstation).

Cell phones and mobile applications

[JonnyRo88]

I think that mobile applications are the biggest driver for text based user interfaces. There will always be a desire for the smallest gadget ever, and those LCD text displays continue to provide.

Also, for remote administration of systems, text based user interfaces are indespensible. It is such a hastle to work on systems remotely that dont have them, requiring Remote Desktop Protocol, or VNC, or a graphical web browser, all things hard to set up on the fly.

I can vouch for this

[PedanticSpellingTrol]

It's amazing some of the things that have been done with ncurses lately. I don't even have X installed anymore, I just switch between three vterms.

NAIM - text-mode instant messaging client. I even use this when I'm on my friends' computers because the interface is so neat and clean.

Links - The hihgh-speed web browser you should all know and love

Mplayer/AALib - for all my pornographic urges

GUIs vs TUIs and menu vs command

[0x0d0a]

Christ, man. You may be young, but surely you've run into more advanced TUIs than "enter everything as a command"?

You'd have a screen with a field for profit and parts, and a menu for each of the choices. Look at menuconfig, one of the interfaces used to configure the Linux kernel for a build, for an example. CLI vs menu-based is different from CLI vs GUI. The problem of "displaying all the choices available so that the user doesn't need to remember the sequences necessary to invoke an action" is an issue between menu-based and non-menu-based UIs, not TUI/GUIs. It's even possible to have a GUI that isn't menu-based -- imagine a GUI that used, say, gestures for commands (as a few programs and games do today). Arx Fatalis, Black & White, Opera, etc.

The main real benefits of a GUI over a TUI that I can think of are:

* Use of images. TUIs generally need to fit on a standard console -- 24x80 -- and can generally rely on only ASCII characters, and perhaps bold and a few colors. A GUI can display full-color inline images.

* Use of more input elements per screen. A GUI can make finer-grained use of the display for things like boxes and dividing lines to more clearly mark out where input is going. Since TUIs were designed in the days when displays were quite small, the 24x80 size is really ridiculous in this day of 19" CRTs, but most GUIs allow effective use of all the screen space.

* More effective use of the mouse as an input device. The mouse is pretty good for doing things like selecting an arbitrary subset of items in a group (such as with a window full of selectable icons), or quickly inputting approximate values (such as with a slider). I think that the mouse tends to be overused in a lot of places, that for a lot of applications keyboard input to a TUI is faster and more accurate. The mouse is limited to being used in a very poor resolution, normally.

* Familiarity to users of other GUIs. The windowed GUI is a common input paradigm to almost all computer users today. There are a number of complex operations (like addition and removal of an element to a discontiguous group of selected elements via control-clicking) that have already been taught users of Windows. Software using the Windows interface can expect users to know how to do these actions already, instead of having to instruct them in what to do. TUIs never enjoyed widespread conventions of the sort.

* Windowed interfaces. The windowed interface paradigm is generally a very powerful interface mechanism, and one that can be taken advantage of in a GUI. If a computer is single-purpose and running only a single program, this may not be such a benefit, but on computers that may run many programs, having the ability for a user to do windowed work is a great benefit.

* Non-ASCII charset support. While there is support for non-ASCII characters on text terminals (I suspect there is even UTF-8 and kanji support), most modern GUI environments provide good built-in support for rendering international characters -- TUI environments may not. This is not a hard constraints on TUIs, but given the existing TUI/GUI environments around, it is a practical advantage.