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

Think of the users

[rkrabath]

Who would want to use them? Sure, we would, but we're by and large geeks. the 'normal' users can't handle anything that doesn't have pictures to keep them focused.

Re:Think of the users

[eugene ts wong]

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.

Re:Think of the users

[shibbie]

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

Re:Think of the users

[bhtooefr]

Cool! Now, I just need a text-based X system and WM, as the only X apps Twin can run are XMMS (via a plugin) and a port of KCalc to Twin (the result is a Twin app, not an X app).

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.

Re:No reason not to

[Wolfrider]

--Would you care to explain that pls? I haven't been able to initiate X Windows from a "screen" session for a couple of *years.* (Either using "startx" or "xinit".) If I back out of "screen" to the bare VT, X starts up fine.

Re:No reason not to

[vsync64]

I think he meant that he can keep a screen session going independently of X sessions, and that a bunch of xterms can show different views of this session via screen -x and the like.

Re:No reason not to

[Wolfrider]

--Ah, that makes sense. Thx

Re:No reason not to

[adamjaskie]

Yes, that is indeed what I am doing. Its nice too because I can sit down on any computer, ssh back to my computer, and attatch to the screen.

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.

Slightly off the main topic...

[bob_dinosaur]

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

Re:Slightly off the main topic...

[rkrabath]

the biggest problem with a 3D interface is the interface. It's not coincidence that we have a 2d pointing device for a 2d interface. when we design an easy to use 3d pointing device, widespread adoption of the interface will come shortly behind.

Re:Slightly off the main topic...

[brsmith4]

We've had joy sticks since the kitty hawk flyer took its first flight. Easy to use 3d pointing device? We've had em for about a century.

With high enough quality, the problems with accuracy can be handled.

Re:Slightly off the main topic...

[Mr. Slippery]

Easy to use 3d pointing device? We've had em for about a century.

A joystick is just as much a 2-dimensional pointing device as a mouse. In an airplane-like interface, the joystick controls the direction that the nose points, but you need the throttle to control forward motion.

Re:Slightly off the main topic...

[brsmith4]

Quite true... I stand corrected. I was thinking of how aircraft can move along x,y,z (yes, with throttle) and forgot that the stick itself only moves along x,y.

Re:Slightly off the main topic...

[0x0d0a]

There are pressable and swivelable joysticks, though, either of which would give an additional degree of freedom.

Re:Slightly off the main topic...

[mhesseltine]

We've had joy sticks since the kitty hawk flyer took its first flight. Easy to use 3d pointing device? We've had em for about a century.

Sure, just let me lay down on my desk, put my hand on the joystick, and lay on the hip cradle to adjust the lateral motion of my mouse pointer and we'll be all set.

Re:Slightly off the main topic...

[rkrabath]

joysticks are still only 2d, unless you pick them up. i was thinking more like a vr headset (smaller than todays tech) and an "interface glove" or the like. move your hand in 3d, tap something to open it. punch it to delete. heh now i'm just dreaming!

The interface in Minority Report would be cool...

Re:Slightly off the main topic...

[Frizzle Fry]

GUI's that use the 3D-rendering powers built into your video card to make very pretty looking desktops without putting too much strain on your cpu are right around the corner (e.g., longhorn). I would imagine this is what he is referring to, although I agree that this is not really a "3D interface", just a much prettier 2D interface (not that that's bad, of course).

Re:Slightly off the main topic...

[Gilk180]

Agreed, technically, but how do these translate into motion in three dimensions in an intuitive way?

controlling a pointer like the position of your (plane, character) in a (flight sim, FPS) would be a huge pain in the ass.

Re:Slightly off the main topic...

[0x0d0a]

Yes, you're right -- it isn't perfectly intutitive. I do, however, play games that use the mouse wheel to provide a third degree of freedom (quite common in 3d RTSes to control camera height, for instance), and don't have much difficulty adapting to it, so I don't think it's an unreasonable proposition.

Re:Slightly off the main topic...

[Gilk180]

Good point, but that is still isn't like using this as a pointing device.

The central difference between this and a pointing device as I originally envisioned it is that all of the examples given are for use when moving your point of view in three dimensions instead of moving an object in your view in three dimensions.

However I think this raises a valid question. In a three dimensional window manager(for example) should we use a pointing device to bring an object to ourselves, point to something, or should we move ourselves the the object? I hope this is clear.

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

[Brutus (moo)]

I work (well, I get to play for free as payment, since I'm underage) at a lan shop which also does computer sales and repairs, the manager there just turned 50 a couple weeks ago and I've known him for about 4 years now, around 2 years ago this 19 year old college student showed up and made a VB (oh, the horror) program for him that basically keeps a text-based database of all the computer parts, which needs to be updated manually and also allows for a person to tell him I want this, this and that and he'll just click 'add' on each one and see what the total outcome is, as well as be able to print out this little page that has all the parts, their prices and the final price written on them.

Other than also calculating it with Dollar>NIS rate, VAT and ammount of profit (also inputted manually), that's pretty much what the program does, not too complicated I guess, or is it?

A program as simple as this should be easy to use, even for a 50 year old man, right? wrong; it took him around 3 months just to remember what each button does, and what's the order of buttons he's supposed to click (call it syntax, if you like), for example to remember that he needs to first choose the ammount of profit for the sale, then choose the parts, then click 'next', then click the little checkmark that says 'print' and then click 'done', which then closes the program and prints out the price offer.

Now imagine that being text based, the above proccess would be consisted of something like this:
profit 20%
parts "mother boards"
list
choose "Asus ABCDE-34 USB2.0 S-ATA IEEE1394" (he would actually need to type in the entire thing that describes the mother board)
parts "RAM"
choose "Samsung DDRRAM 256MB 400MHz"
parts "CPU"
etc.

I think you get my point by now, remembering the syntax for that, for a 50 year old man (or even for me) would be extremely annoying and tiresome, when he could just run a simple GUI like he is on a 133 MHz PC, not to mention actually typing out the entire names of the models or whatnot.

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.

Re:average users

[God! Awful 2]

it took him around 3 months just to remember what each button does, and what's the order of buttons he's supposed to click (call it syntax, if you like), for example to remember that he needs to first choose the ammount of profit for the sale, then choose the parts, then click 'next', then click the little checkmark that says 'print' and then click 'done', which then closes the program and prints out the price offer.

So how come you never wrote him a wizard-like step-by-step interface?

-a

Re:average users

[TwistedGreen]

Ergo, if efficiency is important a command-based interface may be ideal. It may take a little while to get used to, but once you do, you'll be able to get things done much faster. Just take a look at what an experienced AutoCAD user can do with the text interface. Hunting for icons feels excruciatingly slow for someone used to the speed inherent in a text-based command system.

That said, a text-based system would not be ideal for an interface whose users have a high turn-over rate, for example. "Different strokes for different folks."

Re:average users

[4of12]

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.

Perhaps users don't like to have to remember text commands and syntax. But they are pre-programmed for text interfaces just because reading and writing are done this way. And as much as dramatic and visual arts have progressed, their effectiveness for conceptual communication is much more of a niche (eg, using pictures to illustrate geometry, picking points on an object, creating a spline curve).

GUI's have been over utilized on occassions where a text-based interface would have sufficed. For drawing, for manipulating geometric objects a GUI is perfect. But opening up a dialog box and inputting a text string and moving a mouse to click OK?

The usefulness of text based interfaces accounts for so much of why many small businesses are more than happy to run off some crusty old DOS program they installed in 1988. It gets the job done and there's no technical or economic reason for migrating to a GUI.

Regarding the learning curve: The learning curve for text interfaces can be just as well or as poorly designed as the learning curve for a GUI interface. Either way, you need a good help system with keyword searches, etc. And, as a confession, I end up going to google now more than doing "man -k" to find out answers to questions that really only need a text answer and I do use Mozilla instead of Lynx.

Re:average users

[Frizzle Fry]

This is a good point. I think it's interesting for this discussion that such a system could easily work as either with GUI (choose something from a drop-down menu or enter it in a text field, and then click next) or with a TUI (a series of questions asked on the console). Either one would be better than the current system where you have to click the buttons in the right order, but it doesn't indicate what the order is, or than the grandparent's (your parent's) theoretical text interface that makes you remember what order to give the commands in (and what the commands are). IOW, you can design a good or a bad interface as a TUI or a GUI.

I think it might be worth considering... (ot)

[Ayanami Rei]

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

Re:I think it might be worth considering... (ot)

[Anonymous Coward]

MSN Messenger does that too in the latest versions. You can assign a graphical character to a string of text and have it transmitted to the recipient of your message and displayed.

MV DBMS

[adamshelley]

Text based gui's are still being created but it depends on your backend. Some DBMS's still rely on terminal type input and output natively. Examples of these are: d3 jBase ibm's u2 family. There are various options for gui'zing them but they excel at POS and terminal type input and output. Check them out. You can read about these types of databases on usenet @ comp.databases.pick.

TUI?

[bluethundr]

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)

Re:TUI?

[Gleng]

I've NEVER heard a command line referred to as a TUI!

I think it's referring to actual text based user interfaces with equivalents of windows, menus, buttons, etc, rather than straight command line interfaces.

Something ncurses based like the Debian/Slackware installers, for example.

Re:TUI?

[p4ul13]

Agreed, though even for character based menus such as you described, I still prefer the term CLI. Somehow in my mind, if it's in a terminal it's a Command Line Interface.

I'm probably just being stubborn, but my reasoning is that even with an ascii menu, you're still using the keyboard to input commands. It's by no means a rock-solid arguement, but good enough for me.

Re:TUI?

[Mr. Slippery]

but my reasoning is that even with an ascii menu, you're still using the keyboard to input commands

Except that there's no K for Keyboard in CLI, now is there?

Command Line Interface: if you don't have a command line, you ain't got one.

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.

Re:TUI?

[bluethundr]

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.

Agreed. So, mutt, lynx, pine...all TUIs, but no mention of EMACS? egads! Wouldn't that be the best (or the worst, depending on your point of view) of both the TUI and CLI worlds? RMS would be appaled! ;)

Re:TUI?

[Anonymous Coward]

That's what ! is for. Try it in mutt or vi, two curses apps.

Re:TUI?

[Anonymous Coward]

no mention of EMACS? egads! Wouldn't that be the best (or the worst, depending on your point of view) of both the TUI and CLI worlds?

I like to think of it as the best of the operating system and kitchen sink worlds.

Re:TUI?

[Tumbleweed]

emacs isn't a TUI; it's a way of life! :)

Re:TUI?

[mini me]

you're still using the keyboard to input commands

Not true. There are plenty of ncurses-based programs that accept mouse input.

Re:TUI?

[Anonymous Coward]

I've been using the TUI since the old Commie 64 days

Commie 64? I guess the "In Soviet Russia" thread begins here.

Re:TUI?

[Sheriff Fatman]

The full text of Stephenson's essay is available here:

In The Beginning Was The Command Line

I remember seeing it online a long while ago, but I've only recently seen it in print. Googling "in the beginning was the command line" will turn up a bunch of mirrors if the site isn't reachable.

Advanced Hieroglyphics

[_aa_]

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.

Q: How do you spell Midnight Commander?

[DaoudaW]

A: mc

Re:Q: How do you spell Midnight Commander?

[stevesliva]

So that's what starts up when I mistype mv.

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.

Re:An idea: you could start with newt

[Anonymous Coward]

She turned me into a newt! .. I got better

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

Re:Are there any real reasons against?

[babbage]

I dunno, I think a very good case could be made that building any application around its interface is exactly the wrong way to do it. Rather, the developer[s] should develop code that implements the core functionality, and *then* hang some kind of interface on the front of it. (Whether or not these activities happen in parallel is a separate matter: without getting into a diversion about what development methodologies work best, please concede that it's generally considered a good idea to keep interfaces at arm's length from core functionality.

So, with that in mind, you could make a strong case that a well implemented application may be something unassuming like a library or a command line tool. Around this, you can build different kinds of interfaces (a standard GUI, some GUI for different operating systems, different GUIs for different locales, a web interface, etc.

This is getting to be a common way to implement software on OSX. Take Fink Commander, for example: it's a nice, high level graphical tool for driving /sw/bin/fink and related commands. It demonstrates how a command line toolkit (basically, an extended version of Debian's APT tools) can be presented to the user in a simple, easy to understand graphical way, while still allowing users "direct" access to the command line version as well. Likewise, The core of OSX's Network Utility application is a little command line program in /Applications/Utilities/Network Utility.app/Contents/Resources/stroke. Running it in the GUI is nice, but from the command line it's also useful:

$ cd /Applications/Utilities/Network\ Utility.app/Contents/Resources/
$ ./stroke
2004-04-20 13:20:23.875 stroke[23328] stroke address startPort endPort
$ ./stroke localhost 1 1024
Port Scanning host: 127.0.0.1

Open Port: 22 ssh
Open Port: 80 http
Open Port: 111 sunrpc
Open Port: 139 netbios-ssn
Open Port: 427 svrloc
Open Port: 631 ipp
Open Port: 877
Open Port: 936
Open Port: 937
Open Port: 938
$

Nice! And other applications can be driven in similar ways -- StuffIt, some of Adobe's stuff, et cetera. Clearly this is an excellent way to appease both the GUI and TUI user bases.

Another nice example is Request Tracker. RT is a trouble ticketing & tracking system, similar in many ways to Bugzilla (but *ahem* much nicer, IMO). One of the really cool things about RT is that you can interact with it through a Perl/Mason driven web interface, you you can use email or a command line tool. The email interface is nice, because you can basically have a natural mail conversation with your colleagues and RT will keep track of everything for you. The command line version is nice because, well, lots of people like working in command lines. The fact that RT allows you so many ways to work with the system is excellent system design (even if you don't care for the interfaces provided, that's a separate matter; the fact that they are all available (and more can be added if you know some Perl) is clearly a good thing).

Finally, look at databases. Every good database -- that is, more or less everything other than desktop toys like Access or FileMaker -- provides at a minimum a command line interface, one or more graphical interfaces, and a programming API for multiple languages. Often, you can find additional third party interfaces so that you can interact with the database other ways, such as through a web browser. All of these things are generally considered to be minimum requirements for any database that wants to be taken seriously.

So, what of your PHB then? The PHBs and marketing & sales drones may want GUIs, and that's fine -- they should be allowed to have them. But if any boss fails to recognize that providing alternative interfaces for software is obviously a good & necessary thing, then maybe someone else deserves that person's job more than they do.

Re:Are there any real reasons against?

[N1KO]

It's not about not having to think, it's about things being easier.

I do file management on the console because its easier. I change my volume settings using a gui because its easier to move your mouse wheel up and down than typing lots of things.

Most people who have used a console think of command.com, something archaic which feels almost like assembling your own car every time you want to go somewhere.

Re:Are there any real reasons against?

[This is outrageous!]

The core of OSX's Network Utility application is a little command line program (...)stroke.

Stroke isn't "the" core of Network Utility... the app drives eleven command line programs, of which stroke is just one. (The others are in [/usr]/sbin.)

The sort of apps you're talking about here (there are tons more, e.g. SimpleWget) are very limited though: basically they just exec CLI apps, and all they can be is some sort of form-based interface to enter CLI arguments. Which invariably turns out to be crippling -- soon enough we're back to the command line and manpage, if we want to dig -x or wget less than the entire internet.

Much more interesting (and relevant to the TUI question, IMO) are apps that expose libraries: ReSTedit, TestXSLT, TeXShop,...

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

Re:Lots and lots of terms in a screen session

[Mr. Slippery]

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

gnome-terminal now lets you have several tabbed terminals in one window. You can even have them in different styles, I like to use different color combinations for different hosts.

Still doesn't let you do anything like screen -r, though.

Re:Lots and lots of terms in a screen session

[bruthasj]

Ever used a recent copy of Konsole or gnome-terminal? Might give it a try. I've mapped my IBM T30 laptop's back/forward buttons to flip through the embedded virtual terminals. Then you pick one of your desktops to contain a full screen version of that terminal and there you go.

Though, "screen -x user/share" is old-school netmeeting. So it's still quite useful!

TUI/CUI still needs focus for low-bandwidth situations like modem support, etc.

Retail stores

[nitrocloud]

I've noticed many retail stores (Sam's Club, Walmart, Lowes, and quite a few more) use TUIs for POS programs on more advanced cash registers that use DOS on sometime monochrome displays and sometimes... sometimes, are older than I. TUIs aren't gone, but with Windows, many advancements don't typically occur since DOS has extreme limitations placed on it. If bash was running on many computers, ncurses, aalib, and mnay other projects can well justify the use of a TUI. I have, in fact, used TUIs to do anything over SSH when I'm away from home, playing music with MP3blaster, programming with motor, IRC with irssi, Instant messaging with centericq, and many various TUI webbrowsers ass well as mutt for e-mail. With Linux, TUIs will probably never disappear since many projects are still advancing, and with mplayer compiled with the aalib, the Matrix lobby scene never looked so sweet.

Heh Synchronicity

[JabberWokky]

I'm in the middle of a one day project writing a TUI library for Lua. The only reason I'm writing it is to play with the language, really dig into how the object metaphors work and how metatables are built and stored. Kind of like writing a Tetris game or Life simulation, it's a way of coding to learn the system.

I had a flashback to Borland Turbo C 2.0 (or was it 2.5?), and I wanted to reproduce the IDE, plus some SideKick style utilities, just for the heck of it. I still think the Turbo C 2.something IDE was one of the best systems for development. Nice, fast and direct to the point.

So far I have a desktop with a menu that can popup windows that scroll with static content and can load the content from text files. Silly, but fun. And for some reason, it just feels good. Probably just nostalga.

--
Evan

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.

Re:Cell phones and mobile applications

[shadowxtc]

And just what's wrong with Remote Desktop?

Re:Cell phones and mobile applications

[JonnyRo88]

Sometimes you dont have access to a client machine that has it. Basically if you are using an ssh terminal from a remote site.

SSH is soo easy to use for remote admin, although not for everyone. Also remember that i'm a linux admin, not a windows admin. I am however very excited about microsoft's recent push to update their command line interface, which should make the occasional windows system I have to work on easier to deal with.

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 off of Google Image Search. Very cool system, and it is GPLed, too!

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

Re:I can vouch for this

[Prior Restraint]

The thing I really need to finally set aside X is an ncurses-based front-end to GnuCash. If I'm lucky enough to have some free time this summer, I think I'll finally sit down and try to do something about it.

Re:I can vouch for this

[haystor]

I'd be rather happy with just command line functionality for gnucash. It would be nice to be able to say something like:

paid gas 18.44
paid electric 188.34

tab complete and everything. That's the financial program I want.

Re:I can vouch for this

[Prior Restraint]

I once asked for the same thing, and a former developer said it might be possible to write Scheme scripts to do that. I don't know Scheme, so I figured that if I'm going to have to muck about in their code anyway, I might as well go all out.

Tab completion... now that's an idea.

Re:I can vouch for this

[haystor]

I was working on something to make a command driven application using a more natural language. It was to work a bit more like Zork.

> show gas bill
(shows the upcoming bill, guessing date and amount based on last bill)

> edit it
(asks some questions about how much and when, in case they are different from last time)

> pay gas bill 36.44
> pay gas bill

Basically, my sentences would consist of a verb (command form), and indirect object and some other stuff.

Indirect objects would map nearly directly to objects and have methods that generally map to the command. These methods would know what to do with the other stuff on the command line and query for whatever was left out.

I kept one object around to be the "it" pronoun.

Everything had reasonable defaults (date defaulted to today, amounts defaulted to last month's amount).

Tab completion was the next thing to go in, as soon as I figured out how to do it.

Just as I had the framework in place where all I had to do was flesh out functionality my hard drive died a terrible death.

Since then I've managed to get Gnucash working. Fiddling with is frustrating, but I don't generally have to double check their math.

My first version was in Python. If I do it over I may look into Scheme for Gnucash or write it in clisp just to simplify parsing sentences.

Re:I can vouch for this

[latroM]

aalib doesn't use ncurses because it would be too slow. Aalib is the rendering library.

eLinks...

[antdude]

I prefer ELinks over Links and Lynx.

Nobody?

[erydo]

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

Re:Nobody?

[Anonymous Coward]

Yeah, YAHOOTASQ (Yet Another Hopelessly Out Of Touch Ask Slashdot Question). It seems the submitter forgot the audience he's asking. Text interface users are the vast majority of Slashdot readers.

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.

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:GUIs vs TUIs and menu vs command

[0x0d0a]

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

Right -- I may not have used correct terminology, but this is what I intended to say. I used "per screen" rather than "per page".

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

True...but I'd still argue that Windows is a more standardized GUI environment than any TUI I can think of. In a TUI, what is the difference between BS and DEL? How, if there is any such method, do I transfer textual data from text field to text field? If the TUI supports text selection in text fields, how does it operate, and what keys control it? How do I move from the beginning to the end of the line or delete the word to the right or left of my cursor?

There are plenty of systems out there that let you work on multiple sessions through a single screen.

I use screen and XFree86 myself, but there is no guarantee of such functionality when using a typical TUI -- there are lots of terminals sitting about. I *know* that I have such functionality in a Windows-based GUI.

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

After all that, I figured you were going to pull out aalib as an example. :-)

Now, keep in mind -- all this doesn't necessarily mean that I think that GUIs are the way to go. I think that for POS, for equipment-control, for data-entry, and for a lot of kiosk applications, TUIs are the way to go. Heck, I do all my file management on a CLI, as well as most of my work (well, aside from most of my web browsing). I wasn't intending to argue that GUIs were unilaterally superior to TUIs -- just to point out the advantages that I feel that GUIs have over TUIs. TUIs have their own (sizeable) set of advantages -- I just didn't list them, since they didn't seem all that germane to the thread. It certainly wasn't intended to be bashing the gurus of the amber screen.

As a matter of fact, I think that the recent debacle on Slashdot about National City's CMU ATM is a great example. It used to be an old but reliable TUI system. Apparently, it didn't look new and sexy enough (and as financial services people on Slashdot pointed out, failed to allow the pushing of multimedia ads to users). It was replaced with an WinXP-based (hey, easy to produce a GUI with) touchscreen kiosk. It crashed at some point, dumping the interface out to Windows, which gleeful students happily tinkered with with, eventually ending up playing Beethoven on loop at the maximum sound level the poor kiosk could put out. If National City had simply stuck with their simple, reliable TUI, they wouldn't have had people monkeying around with the innards of their cash-dispensing systems.

Re:GUIs vs TUIs and menu vs command

[This is outrageous!]

the recent debacle on Slashdot about National City's CMU ATM

/.'s search seems down at the moment, so: here.

Re:GUIs vs TUIs and menu vs command

[Frizzle Fry]

As a matter of fact, I think that the recent debacle on Slashdot about National City's CMU ATM is a great example. It used to be an old but reliable TUI system. Apparently, it didn't look new and sexy enough

This sounds to me like more of an issue of moving from an old, well-tested system to a new system that needed to have its kinks ironed out. I don't think there's an inherent GUI issue here. If they moved from a GUI system to a text system or from one GUI system to another, they easily could have had the same problems-- that the new system had some bugs because it was new and hadn't been fully worked out yet.

Re:GUIs vs TUIs and menu vs command

[0x0d0a]

It isn't necessarily tied to GUIs, no.

The problem is that generally GUI kiosk systems have a large, complex Windows backend. They don't have to do so, but most do, and some of the GUI benefits I listed depend on this.

If you're going to have a Windows core, unless you want to do *serious* modification work on the system, you're going to still have Explorer and friends lying around on your system. You have a lot of complexity coming with your system that you may not want.

While the "obvious" method for building GUI consoles on Windows (and even Linux, to a much smaller degree, since it's much easier to lock down a Linux GUI -- if there's no window managers or anything running, it's awfully hard to do anything) makes a kiosk application crash dump a user to a position of control over the system, text-based systems that I can think of in common use do *not* do so. Oh, there's probably some DOS-based system somewhere that would dump someone to a DOS prompt, but it's much more feasible to build a text-based system from scratch.

Re:GUIs vs TUIs and menu vs command

[Frizzle Fry]

If you're going to have a Windows core, unless you want to do *serious* modification work on the system, you're going to still have Explorer and friends lying around on your system.

This is why Windows Embedded exists. You can pick which components you want and don't have to include stuff that is unnecessary or dangerous.

Re:GUIs vs TUIs and menu vs command

[Anonymous Coward]

True. For example, the minlogon baseline configuration with a barebones setup.

They use text--

[noselasd]

Peeking on the screen of varios folks at: the bank,postoffice,car parts reseller, video rental, and heaps of others. What do I see ? A screen
running a text mode application. Black background,green text.

same as any other technology

[hutkey]

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!

plan9 - the text based GUI

[DrSkwid]

plan9 is in graphics mode but there's no buttons, sliders, radio boxes, tick boxes etc.

(well there is a widget set but I've never seen it used)

here's some of my desktops :

screeny_dec_03.gif

screeny_dec_03-a.gif

plan9.desktop-Dec-2002.jpg

The GUI is cool but

[Gary Destruction]

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 think it depends on your age.

[bryanp]

I'm old enough that TUI was all I had originally and for a lot of things I still find it faster to drop to a CLI. I admin a bunch of Novell and Windows servers using XP on my desktop - I don't get a choice. To map a drive I actually have to think about it in Windows. At the CMD prompt my fingers have the map command keyed in before my brain finishes thinking about where I'm going.

If I grew up using a GUI I suppose I'd find the CLI completely archaic and pointless.

In closing I'll just say "Bah! Kid's these days!"

several projects

[Chipaca]

First, there's tvision, a port of Borland's turbovision to gcc. Unfortunately turbovision is not in the public domain as could be deduced from that page, so tvision is not free software and on shaky legal grounds, but borland doesn't seem to mind.
Another interesting project is twin, which is a text-mode windowing environment, something like screen with a TUI.
nstti, the not so tiny text interface, might make a good starting point if you decide to write your own in python.
And there was this butt-ugly GUI that worked directly on vga hardware that would've been fine for POSes, but I can't find it right now.

Re:several projects

[Chipaca]

gah. tvision is here. Much too early to be posting on /.

average users-Generational gap.

[Anonymous Coward]

True, but Cloudless net and the original poster, should be a warning shot across the bow. TUI or CLI on Linux is threatened, not because there's so much an organized movement, as their is a great deal of apathy, ignorance, and misinformation being brought over, right along with the "linux needs this or else..." mantra we've been hearing for the past year. TUI's and CLI's prosper because of two things. The people who know them and prefer them haven't decreased beyound a critical threshold, and there are a few willing to learn them IN SPITE OF the whole GUIfying of the world, replenishing the one's who die or leave. And the GUIers haven't reached critical mass to cause a problem. So be vigilent.

XMLterm

[Anonymous Coward]

I am interested in projects which combine the power of a command interface with the visual immediacy of a GUI.

http://xmlterm.sourceforge.net/

Also things like scriptable and hotkey-driven GUI applications. Amiga was way ahead with AREXX, as usual.

http://ros.rubyforge.org/wiki/wiki.pl?BestFeatur es /AmigaOs

Re-implementing WIMP/GUI widgets on character-based platforms is about as relevant as AA-lib (i.e. a fun lark).

Re:XMLterm

[duffbeer703]

Just what the world needs, an XML terminal!

Wouldn't it be great if someone made an XML-enabled toilet. That way humans, robots and animals alike would automatically be able to handle waste products with a single, consistent interface!

Re:XMLterm

[Anonymous Coward]

Just what the world needs, an XML terminal!

Point is not: this uses XML.

Point is: this lets you BOTH see your icons/thumbnails, AND use your pipes/wildcards/CLI constructs.

Show me another interface which does that, XML or no XML.

Naim is pretty cool

[JonnyRo88]

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.

Re:Naim is pretty cool

[boredMDer]

If yall like naim, you should check out pork.

Good ol' CLI (heh TUI) based client, but uses OSCAR instead of TOC, which leads to a plethora of advantages. One of them, you can view away messages of people without actually sending a message to get it.

Also, it uses a buddylist as opposed to a mere list of who's on.

http://dev.ojnk.net

Mind you I am not the developer of the program, just someone who has made some trivial patches to the source to keep it looking nice.

Why not an efficient GUI?

[Mr. Shiny And New]

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

Re:Why not an efficient GUI?

[Lil'wombat]

AutoCAD comes to mind. You can use the Point and Drool interface, and it just builds a command for you on the 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

voice interfaces

[chris_mahan]

Essentially, voice activated applications are command line, since it's one line in, one line out.
It's much easier to port a user interface from command-line to voice than it is to port gui to voice. (what, you describe "There are four little boxes, all alike, and the first one says...")

I think that the merging of voip (sip or otherwise) with cell phones will allow interaction by voice to powerful computers running voice-enabled command-line-style applications.

Re:voice interfaces

[Anonymous Coward]

>"There are four little boxes, all alike, and the first one says..." ...North, the second one says South, the third one says East, and the fourth one says West.

Some people learn

[swusr]

At a local computer store, they initially used a Windows-based GUI program at the cash register. Found out they use an Oracle database.

The poor employees suffered from constantly having to use the mouse to select an option (customer name, item, etc.), and the program ran like a snail. You could hear them rant like crazy.

2 months later, all cash registers were changed to a TUI, menu-based front-end.

Fast as hell, and the employees couldn't be more happy. They only needed the ENTER key to navigate the interface.

Text-based UIs are best...

[cr0sh]

...for those applications where you can't (or don't need/want to) see the screen all the time - termed "heads down". Most of these kind of applications are typically vertical-market apps (you know, the huge b2b-style applications - claims processing, inventory control, etc). Historically because the users (data entry) are entering data from paper (invoices, claim forms) into the system, though this is becoming less and less with OCR input (though correction is still needed).

Text-based UIs tend to be fairly consistent in how they work - type in a field, tab/return to move to the next field (depending on if you are in "add" or "edit" mode), function keys to do various things, etc. A properly trained person can quickly move about the system, many times while on the phone, and looking away from the keyboard!

Such ease of use is not typical of GUIs, because of the mouse, which requires hand-eye coordination by definition. It is possible to build a GUI app that uses keystrokes, and even integrate a "heads down" system into it, but it tends to be clunky, because you are working against the GUI way of doing things, not with it. Furthermore, sometimes the widgets of the GUI will get in your way as a programmer. One example would be how some controls intercept the tab key (a requirement for heads down) - some may fire a defined event handler, others may interpret the tab in some other manner (popping a list down or whatever, without letting you override or intercept the tab), others may require you (as the programmer) to intercept it yourself at a higher level (leading to sometimes messy code, and always more work on your part).

Then, there is always the issue with how to deal with multiple "screens" - do you use a single form (ie, emulating a "terminal"), or do you switch between multiple forms? What about the forms not in focus - do you close them completely, or only hide them?

The list of issues can go on and on. It isn't that it is impossible to make a heads down GUI application - it is just that you are working against the flow of what a GUI is and is for.

So, it really comes down to the type of application being developed and the who the user is. In certain applications, it is better to have a simple green (or amber) screen heads down application - go to AutoZone or a similar place where they use VT100-style old-school terminals and you will see what I mean - in those environments (dirty hands, fat fingers, employees who aren't computer users most of the time), a simple terminal with simple keystrokes work best.

Other applications and users may require something different (and in certain very rare situations - it may not even be a keyboard/screen!)...

Ah yes

[Anonymous Coward]

Test based UI's ... I remember qbasic and edit.com. You can still use em even in Windows. Just do Start | Run ...| edit

Enjoy

My NT starts a console window when I log in, so ..

[Anonymous Coward]

I can type sol or freecell and get there really quick.

GUI is where it is at.

[scorp1us]

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)

Still C-worthy

[marquis111]

One of the things I like about Netware servers is the ability to do most of the necessary things at the console in a Command-based or Text-based environment (C-worthy style). Even in Netware 5/6, you can unload the java console (based on X?) and do a great deal without it. Frees up resources when they don't need to be consumed by a GUI.
Terseness when needed, and a GUI when needed. I am curious to see if Novell's distros of Linux follow this trend.

TUIs: better for speed and RSI prevention.

[Kent Brewster]

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.

GUI is where it is at... for graphical apps.

[pigeon768]

Whatmore, a picture is worth a thousand words. You can convey or influence mood (cool blues, hot reds)

When you're trying to convey or influence the mood of, "We have 18 Model #8264's in stock, and have 40 more on order," you'd have a difficult time convincing me that a picture would be a better representation.

GUI's are undeniably better for certain things. Web browsing, image/video editing, (duh) CAD work, anything that by nature requires images, or has to cram lots of buttons on the screen at once. (look at all the links around your screen right now) I'm not arguing that.

However, for just about any process which isn't fundamentally graphical in nature, a good CLI can probably get it done faster. File management/editing, having text config files vs GUI ones, any basic tasks I can think of are better with a CLI. In fact, I usually end up find myself eliminating the mouse (the fundamental element of a GUI) from as many GUI programs as I can. I only don't map clickable buttons to the keyboard when you actively can't do it. You'll see me sitting in my GUI environment with dozens of terms up opening apps with hotkeys, etc. Sure, I can click the programs icon in the taskbar, but it's faster to alt-tab. Yes, I can right click on the desktop and click aterm, but it's faster to hold the windows key and press x a. I aliased emacs to run with the '-nw' option- so that it doesn't open up the graphical version. Why do I use my GUI as a fancy CLI? Because everything I do, I do faster.

Re:GUI is where it is at... for graphical apps.

[scorp1us]

I think a bar graph, a la the intantenous CPU usage meter in win2k is appropriate there. One color for instock, a shaded box of the same color for ordered.

Some things will be faster in text, undoubtedly. I remember explaining windows to a DOS user. It flat out take longer to copy files graphically than it does via command line, ignoring really long paths and typos.

The funamental proglem you face though is lack of proper GUI tools. Obviously what you want to perform cannot be done [efficiently] in a graphical context (yet). You say web use has to be graphical, but you're talking to someone who used gopher for the first couple years of college. Obviously the paradigm has changed. And it will change on you too. Eventually someone will automate what you do, and they'll do it graphically.

TUI MUA

[Webmoth]

Well, I for one prefer to check my mail by logging in to a shell on the mail server and firing up Pine. Probably 95% of my mail is readable this way, and I can easily zap the spam without having to download or look at it. For those messages with graphics I might want to look at, I use a graphical MUA such as Netscape or Outlook Express, or a web interface to the server.

Using ssh and Pine, I can read my new mail in less time than it takes for Netscape to fire up.

A well-designed TUI will outperform a GUI any day. Just make sure you implement hot keys, and that EVERYTHING can be done from the keyboard. If your right hand is always jumping back and forth between the keyboard and the mouse, you'll lose a ton of productivity.

Yes, your users will have to memorize keystrokes. If they do, then they will be able to do their jobs without even looking at the screen. Try that with a mouse.

Text based interfaces are often better

[Jerky McNaughty]

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.

Text is fast

[Anonymous Coward]

We can read much faster than we can listen. On the other hand, we can type slower than we can talk.

This makes text better than conversation for conveying information. The writer has to be a bit efficient. The reader isn't unduly inconvenienced.

I was aware of RIMs Blackberry in its early stages and I wasn't very impressed. It was just text after all. Boy was I wrong.

It's over.

[SphericalCrusher]

"'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!"

Sure, GUIs hog more resources, but that means absolutely nothing now -- as technology has advanced, we see more powerful computers than we did in the past. Sure, if we threw a GUI on an older model computer, we'd be seeing a big difference in it's performance, but don't you think that TUI is just obsolete now? I respect everything that it has done for us, and I can use it myself, but for the good of the people, it's just... dead.

3D TUI, anyone?

[ae-valkyre]

Where are all those fancy 3D text based interfaces we were promised? I'm still waiting for the one from the movie Hackers to come around. :P ROOT, BACKSPACE, ROOT, SPACE, SPACE, GARBAGE. NOW COPY. Hah!

Gtextle

[Anonymous Coward]

I know what you mean. I spend most of my work
time using this stupid text based app called
"google"

Well, as long as you don't count the one called
"email".

On the other hand, I can defrag my disk with no text input at all! (or play UT 2004)

ah well...there is always hope with the next
generation...sigh.

How do you spell Captain Midnight?

[Anonymous Coward]

CM

oki ...

[Anonymous Coward]

i was at the airport lately and wanted to
get a ticket with a "no frills" airplane
from chinamgai to bangkok. i had my ID card
ready, name, home phone number, date plus
time marked down on apiece of paper. i had
to ask the girl at the counter of course, and
the five customers weren't to happy, maybe
because i looked a bit upset and wanted to
"jump the line", but i just wanted paer and pencil.
anyway i did this, because it took me 35 minutes
in line to get my ticket (oh and yeah, i had
the money just down to the right cent i my other
hand).. anyways whilst standing in line, i was
thinking and wondering to myself why this was
taking such a freaking long time. when it finally
was my turn and poke my head a bit closer to see
what the girl was doing on the computer. it was
terminal session (3870 what-ever?) on a XP box
with this black screen back-ground. boy oh boy,
she had to enter all these cryptical numbers and
short-cut-letters. it was amazing ...
so, all the good ideas that i was having while
standing in line for 33 minutes, like having
a simcity typ of simulation on the screen
displaying in large letters the date and time
of departure and a scematics of the airplane typ
and a mouse for clicking a seat and a field poping
up for entering date customers data for that seat
plus maybe even a barcode scanner that would enter
all this data automatically from the barcode on the id card (it doesn't have one, but it has a
magnetic strip). was def. worthwhile ...
anyway, it's a "no frills" airline so maybe
working there is "no frills" too.
ah, and yes, i have flown with that airline before
but the database of their buying/reservation
system prolly just forgot me ...

the whole point? with gui's you can acctually
display what you're doing and training becomes
super simple ...