Slashdot Mirror
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?
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.
/usr/games/fortune
Since when are 3D interfaces 'just around the corner'? There have been commercial systems available for at least a decade (and probably much longer), but their widespread adoption seems no closer than it was a decade ago...
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).
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.
Okay, guess I'm left to ask the dumb questions.
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!
So, its stupid question time again. Is TUI pr. as the text equivalent of the GUI? ie goo-eee? Or is it more like a tea-you-eye ?
As to the pro's and cons of using a GIU vs. a TUI, all I can say is "Read In the Beginning Was The Command Line by Neil Stephenson". He explains the pro's and cons of using GUI vs. the TUI much better than I ever could. and you could read it in an afternoon. It's more of an essay than an actual book.
As to what my preferences are..a little Perl, a little Python and Apache! (guess you can see where I stand on this issue)
Quod scripsi, scripsi.
Text is as much a component of graphical interfaces as widgets are. I would consider GUIs more of an expansion on text interfaces than a replacement for them. Consider that slashdot is 99% text based, yet your likely viewing it using a GUI. So your text interface hasn't gone away, it just got a great deal more flexible.
And really, you can consider text-mode a graphical interface in the sense that the computer is displaying little graphics that we interpret. Advanced hieroglyphics. We recognize them as text, but others would see rows of silly icons.
And this 3d desktop you speak of, will simply be an expansion of graphical interfaces, as I'm certain it will involve graphics. And I'm sure it will also involve text.
There are of course other interfaces conceivable that wouldn't involve visuals at all. Such as text-to-speech and btty for the blind.
I would imagine that the ultimate interface would be capable of interacting with humans using any and all methods. Of course I don't neccesarily want to taste anything my computer has to offer.
Text interfacing will be around as long as we use text. As for text only interfaces, I'm a big fan of irssi and I'm not planning on giving it up any time soon.
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?!
--
Don't like it? Respond with words, not karma.
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.
The Ro Factor - Jeep/Linux Weblog
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
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.
May we never see th
Think of users as primary school kids. Remember your progression from moving from picture books to black and white illustration with text to text only books? Its exactly the same with end users, except they don't want to make the transition from GUI to sleek simplistic GUI (read dev geek style window manager) to command line. They just can't hack it (pun intended) and thats the reason we have jobs, to make it easy for them, otherwise they'd be writing their own code...
I find it crazy that people put the blame on the technology (GUIs make slow software!) when the blame should be on bad developers. Just because a button is on a screen doesn't mean there shouldn't be a hotkey for it. Just because the GUI lets new or stupid users be productive doesn't mean that the software can't also let advanced users do things quickly. And a TUI (as opposed to a CLI) is exactly the same as a GUI, except with a different back-end for the rendering. I mean, come on, all the metaphors are the same. You can't tell me that text-based menus and input boxes are somehow superior to graphical ones from a usability perspective. One poster wrote about using Screen to allow disconnecting and reconnecting sessions, so that he doesn't need to close his work and can access it from anywhere. Well, that is useful, but it will eventually happen with GUIs (It's already partly there, with things like VNC).
Think about it. We are visual creatures. we see things in terms of shapes and colors. Not words and lines. The first writings were cave drawings. Then we got up to hyroglyphs, then to sandscript and the like. We were born with the idea of an image. It took thousands of years to coalesce it into witten words.
When we have a vocabulary. A set of established words. You do not need any vocabulary when it comes to images, though you do need to anticipate what images the user is familiar with. Like VCR controls.
Text-UIs require language:words, grammar and syntax. GUIs don't. You cam make a multi-lingual application easily if you never need a word. Though, you may need to make a application multicultural by changin out the icons. Still you don't need a right-to-left reading order, verb tenses and plurality.
Animation (eek) can help to avoid words, when statuc icons are not enough. but the way the mind works, the mind will learn the icon and the action quicker, so the icon need not always be animated- just animated during training. it is alto easier to share artwork between applications for a consistant experience.
Whatmore, a picture is worth a thousand words. You can convey or influence mood (cool blues, hot reds)
Slashdot's rate-of-post filter: Preventing you from posting too many great ideas at once.
Text-based interfaces cannot be beat for data entry. Anecdotes about users typing several screens ahead without looking at the terminal are correct; I used to do this myself when entering sales orders and A/R/ invoices. (Hundreds, sometimes thousands per day; this was an early-Eighties monkey-work job doing software order fulfillment.)
There's a much firmer-feeling connection with the interface when you don't have to constantly reach for the mouse, find the tiny button, and click it. I never felt a single twinge of RSI until I had to start mousing around.
Oh, and while we're on the subject of old-school technology that worked best, I dearly loved my high-speed dot-matrix printer and fanfold multi-layer NCR forms. When the LaserJets landed it was a Sign of the Apocalypse.