Slashdot Mirror
Text Based User Interfaces in the 21st Century?
Jaap Geurts asks: "With the 3D GUI desktop around the corner, nobody seems to use or think about text based user interfaces (TUI) anymore. I know that hardware comes cheap nowadays but can the use of TUIs still be justified? I've always found that GUIs are resource hungry, generally slower and more importantly they often allow multitasking and they are very unpleasant without a mouse! What do you think about developing a (well designed) TUI for DB software (e.g Point of sale, Warehouse manager, etc)? Most current GUI metaphors can be implemented so what are the pros and cons from a user perspective?" Are there any real reasons against deploying text-based applications, today?
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.
I was just thinking about this today when I skipped down to the local public library to pick up some books for school. Whenever I go there, I grab the text-based console hickey instead of the new-fangled web-page based ones. Whoever designed that text one was a genius, and I wonder if the source is out. Truly, all the formatting and really small links on web pages only serve to get in the way of simple tasks like this one, and the omission of the mouse made it faster. Forced to use a mouse, I would waste precious time moving my hand around. Mice are the devil.
If someone drops a fort on Will, he makes a reflex save.
When I started my current job, my boss gave me his box and built himself a much faster one :) I put up with the fans in his old box for only a day before I decided I had to do something. I moved the box into the server room and brought in my laptop to use as a terminal. No more fan noise!
Pretty quickly I discovered that if I run all of my terminals in a screen session, I had much better control of them than if I ran separate xterms. You can only fit so many xterms on an X screen before you have to start using virtual screens, but you can easily fit dozens of terms into a screen session (I recompiled screen so I can have a hundred: I ran into the Debian version's maximum of 40 a few times). The best thing is, I can switch between them without using the goshdarned mouse. By giving them names, I can call them up with just a few keystrokes. Oh, it's nice. No more hunting. I want the screen I'm using to tail the apache log? It's ctrl-A ' log and I'm there.
When I go home at the end of the day, I just disconnect my screen session. When I ssh in from home to do some work, or when I come in the next day, I just run "screen -r" and I'm back where I left off. Exactly where I left off. No time wasted starting up xterms and getting them moved around. The log term is still tailing the log, the edit term is still in emacs, the test term is still waiting for me to run the tests again.
When I ssh into the noisy workstation, I use -X so I can run X applications if I want to... now and then the Gimp or feh or gv or some other GUIish thing, but running lots of terms in a screen session does lend itself to text mode applications. My email program is Pine, all text driven, and I like it just fine. Emacs in text mode, of course (no button bars for me!): Usually an emacs for each active project. When I switch from one task to another, I don't have to do anything but switch to the right screen session and start typing.
Text-mode programs and screen are all I need to rule the world (or at least the part of it that sits on my workstation).
i 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.
Don't call me back. Give me a call back. Bye. So yeah. But bye our, well, but alright we are on a shirt this chill.