Text Based User Interfaces in the 21st Century? 120
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?
Think of the users (Score:1, Interesting)
Re:Think of the users (Score:2, Interesting)
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 plannin
Re:Think of the users (Score:2)
Re:Think of the users (Score:2, Insightful)
No reason not to (Score:5, Insightful)
Re:No reason not to (Score:2)
Re:No reason not to (Score:2)
Re:No reason not to (Score:1)
Re:No reason not to (Score:2)
Depends on the type of machine (Score:4, Interesting)
What's going on here? (Score:5, Funny)
Text based user interfaces? DOS Games [slashdot.org]?
What is this? The Dark Ages?
Ah, I see. We must be experiencing some latency from the frame dragging [slashdot.org].
Slightly off the main topic... (Score:3, Insightful)
Re:Slightly off the main topic... (Score:2, Insightful)
Re:Slightly off the main topic... (Score:2)
With high enough quality, the problems with accuracy can be handled.
Re:Slightly off the main topic... (Score:1)
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... (Score:2)
Re:Slightly off the main topic... (Score:2)
Re:Slightly off the main topic... (Score:1)
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... (Score:2)
Re:Slightly off the main topic... (Score:1)
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 shoul
Re:Slightly off the main topic... (Score:2)
Sure, just let me lay down on my desk, put my hand on the joystick, and lay on the hip cradle [si.edu]to adjust the lateral motion of my mouse pointer and we'll be all set.
Re:Slightly off the main topic... (Score:1)
The interface in Minority Report would be cool...
Re:Slightly off the main topic... (Score:2)
TUI emphasises transaction based interaction (Score:5, Insightful)
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 (Score:5, Informative)
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--
I think it might be worth considering... (ot) (Score:2, Interesting)
average users (Score:5, Insightful)
Re:average users (Score:3, Insightful)
GUIs vs TUIs and menu vs command (Score:5, Insightful)
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 (Score:2, Informative)
* "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 page
Re:GUIs vs TUIs and menu vs command (Score:3, Interesting)
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...
Re:GUIs vs TUIs and menu vs command (Score:1)
/.'s search seems down at the moment, so: here. [slashdot.org]
Re:GUIs vs TUIs and menu vs command (Score:2)
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 th
Re:GUIs vs TUIs and menu vs command (Score:2)
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 bu
Re:GUIs vs TUIs and menu vs command (Score:2)
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:average users (Score:3, Insightful)
So how come you never wrote him a wizard-like step-by-step interface?
-a
Re:average users (Score:2)
Re:average users (Score:5, Insightful)
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 (Score:5, Interesting)
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.
Some people learn (Score:1)
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 inter
Re:average users (Score:2)
That said, a text-based system would not be ideal for an interface whose users have a high turn-over rate, for example. "Differe
Re:average users (Score:2)
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 pict
MV DBMS (Score:1)
TUI? (Score:3, Insightful)
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 [barnesandnoble.com] 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? (Score:2)
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? (Score:2)
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? (Score:1)
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? (Score:1)
Not true. There are plenty of ncurses-based programs that accept mouse input.
Re:TUI? (Score:3, Informative)
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.
And this is a TUI.
Re:TUI? (Score:2)
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? (Score:2)
Re:TUI? (Score:2)
The full text of Stephenson's essay is available here:
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 (Score:4, Insightful)
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? (Score:2)
Re:Q: How do you spell Midnight Commander? (Score:2)
An idea: you could start with newt (Score:5, Informative)
It's a RedHat thing but it's apparently become popular (available on Debian, FreeBSD, well anything that has ncurses). It supports UTF-8 which is nice.
That'd sort of be your toolkit (ala GTK). So you're halfway there.
Library Catalogues (Score:4, Interesting)
Are there any real reasons against? (Score:5, Insightful)
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? (Score:1)
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
Re:Are there any real reasons against? (Score:1)
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 [cosmos.ne.jp]) 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
Re:Are there any real reasons against? (Score:1)
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.
Lots and lots of terms in a screen session (Score:5, Interesting)
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 (Score:1)
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 (Score:3, Interesting)
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.
Heh Synchronicity (Score:2)
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 I
Cell phones and mobile applications (Score:5, Insightful)
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 (Score:2, Funny)
Re:Cell phones and mobile applications (Score:2)
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... (Score:4, Informative)
I can vouch for this (Score:5, Insightful)
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
eLinks... (Score:2)
Naim is pretty cool (Score:3, Interesting)
Re:Naim is pretty cool (Score:2, Interesting)
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.
Re:I can vouch for this (Score:1)
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 (Score:1)
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 (Score:1)
I once asked for the same thing [slashdot.org], 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 (Score:1)
> 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
Nobody? (Score:2, Interesting)
They use text-- (Score:2)
running a text mode application. Black background,green text.
same as any other technology (Score:2, Interesting)
plan9 - the text based GUI (Score:2)
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 [proweb.co.uk]
screeny_dec_03-a.gif [proweb.co.uk]
plan9.desktop-Dec-2002.jpg [proweb.co.uk]
The GUI is cool but (Score:3, Interesting)
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. (Score:2)
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 t
several projects (Score:1)
Another interesting project is twin [linuz.sns.it], which is a text-mode windowing environment, something like screen with a TUI.
nstti [freezope.org], 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 tha
Re:several projects (Score:1)
Why not an efficient GUI? (Score:3, Insightful)
Re:Why not an efficient GUI? (Score:2)
Two Major Reasons (Score:4, Informative)
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 (Score:2)
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.
Text-based UIs are best... (Score:2)
Text-based UIs tend to be fairly
GUI is where it is at. (Score:3, Insightful)
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)
GUI is where it is at... for graphical apps. (Score:1)
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. (lo
Re:GUI is where it is at... for graphical apps. (Score:2)
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 graphi
Still C-worthy (Score:1)
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. (Score:2, Insightful)
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
TUI MUA (Score:2)
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 an
Text based interfaces are often better (Score:3, Interesting)
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.
It's over. (Score:2)
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 d
3D TUI, anyone? (Score:1)
Re:XMLterm (Score:2)
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!