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
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.
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.
"Proudly Posting Without Reading The Article"
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).
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--
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.
the "tile mode" of various elder consoles and current handheld gaming systems. Where the ability to program the character glyphs is part of the terminal protocol. If this were standardized on top of an existing console standard it'd pretty damn cool (best of both worlds). While an IBM PC BIOS is not capable of it, real framebuffers are easy to come by and could emulated it. And maybe you can design the protocol to gracefully degrade (graphical tiles will display garbage or have wrong colors, but at least the text parts can still be displayed).
You save memory on the side hosting the application (but not necessarily on the display, if it needs a seperate framebuffer).
THIS THING CAN TURN ON A DIME, MACROSSZERO STYLE ALSO FUCK BETA, ~NYORON
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.
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.
THIS THING CAN TURN ON A DIME, MACROSSZERO STYLE ALSO FUCK BETA, ~NYORON
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.
If someone drops a fort on Will, he makes a reflex save.
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.
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).
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
... 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 off of Google Image Search. Very cool system, and it is GPLed, too!
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
"nobody seems to use or think about text based user interfaces (TUI) anymore." That's not true at all; I for one use command-line interfaces multiple times every day, both on my Linux box and my Windows XP machine. I find command-line and TUI interfaces to be just as useful, often more powerful, and less distracting than modern GUI interfaces, and I know I'm not alone in this perspective.
Our company sells text based accounting software that has been made with FoxPro. Yes, we are moving into graphic software, but there still is a willingness to put up with this kind of stuff.
Text is all we need when dealing with numbers.
My advice is to sell the advantage of speed. Customers who want good accounting software will rather put up with a good text based system that is fast, than a good gui based system that is slow. Time is money. We just need to make it easier to use.
For those who are planning on making text based software, might I recommend Twin?
* it is text based
* has windows [like ncurses]
* has multitasking [unlike ncurses]
* uses the mouse
* has a desktop
* can work with X11
* has a window manager [yes, you can maximize & minimize]
* you can detach & reattach windows
I wish that there were more applications for it.
testing out my trending skills
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...
yeah, i found this comment same as any made for other technologies. the advancement in technology is to help people. any change in current one is not so much readily accpeted by others. like when changin from hand held fans to electric ceiling fans, people were afraid to digest the fact that, these fans will not fall off on their heads!!! it took some time to accept the fact that newer technology is more usefl than the old. i don't say that the older ones are useless, but it's just that its a personal choice what we find easier to use. now a days people are fed up with all the gadgets humans have created and they prefere staying in coutry side where they will be away from amenities like mobile, fax, telephones and even electricity!!! and i think (TUI or tee-you-eye or too-yeee) is not much different. once people get fed up with some things they try to go back to the past things and say they are more useful. trying different things is in human nature. things (like GUI etc) are not invented/discovered abruptly they serve a specific purpose. if the purpose is solved for you, you can move on to the next thing, but this does not take away any importance of the previous one!
The GUI is cool but the CLI is still more powerful and more efficient. Anywhere you want to go on your drive takes only a couple commands. The GUI on the other hand requires a little more user intervention, even it means simply creating a shortcut.
CLI = cut to the chase
GUI = take the scenic route
You arrive at the same place. It just depends how fast you want to get there. And 3D desktops are coming. But it's going to take a long time for the transition. Remember, the more dimensions you add, the more coordination is needed.
I agree with you, NAIM has a really nice interface once you figure it out. Have you ever chatted with the author? He is still the default contact on every NAIM install. I think that is pretty cool. On his web page he mentions that he meets at least 10 people a day from new installs.
The Ro Factor - Jeep/Linux Weblog
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).
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
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.
A lot of other posters have already explained reasons why they are, so instead of rehashing their arguments, I'll just give some real-world examples with which I was involved.
My mother had two stores at one point, both of which used computerized point-of-sale systems. The system was DOS and worked pretty well. It did the reporting she needed, interfaced with mechanized cash drawers, a poll display, and a bar code scanner. Things worked pretty well, and it was even networked and had two machines. She was much happier than with the old system of a cash register with a lot of hand inventory keeping.
Then, the vendor decided to come out with a new Windows based system. She was very reluctant to change because the new system meant having to buy all new hardware and some new training for her and her employees as many of the screens had changed. But, she couldn't continue to get support for the old DOS based system because the vendor, understandably, wanted to only support their new Windows-based system.
So, the new system was installed. Aside from the enormous migration problems which aren't relevant here, she was really unhappy with it. Mice do NOT work well in a retail environment where they are used constantly and get gunk inside their roller balls and buttons. Employees tended to not learn shortcut keys because they seemed to perceive the mouse as easier to use, whereas in the old DOS system, they had no choice but to use keys. The keyboards were beasts and never seemed to die, but the mice did.
There were no new features that interested her at all; she forked out the $10K+ to upgrade because she had to. During the holiday season, the cashiers were slower with the new system than with the old one, in general, partly because they didn't use shortcut keys and partly because shortcut keys weren't always usable in all screens and situations.
Done properly, a GUI can be just as effective as a TUI, but all too many times, a lot of the GUIs I've seen for repetitive tasks (e.g., telemarketing data entry, POS, etc.) are horribly inaccessable. Since TUIs, at least to some degree, have to be accessable, they often work better.