Follow Slashdot stories on Twitter

 


Forgot your password?
Close
typodupeerror
×
GUI Software Technology

Text Based User Interfaces in the 21st Century? 120

Posted by Cliff from the lose-the-rodent dept.
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?
This discussion has been archived. No new comments can be posted.

Text Based User Interfaces in the 21st Century? More

Text Based User Interfaces in the 21st Century?

Comments Filter:

  • Think of the users (Score:1, Interesting)

    by rkrabath ( 742391 )
    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.
    • 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 plannin
      • 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).

    • Re:Think of the users (Score:2, Insightful)

      by shibbie ( 619359 )
      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...

  • No reason not to (Score:5, Insightful)

    by adamjaskie ( 310474 ) on Monday April 19, 2004 @11:40PM (#8913073) Homepage
    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.

  • Depends on the type of machine (Score:4, Interesting)

    by bulldog2260 ( 649125 ) on Monday April 19, 2004 @11:42PM (#8913081) Journal
    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? (Score:5, Funny)

    by Gleng ( 537516 ) on Monday April 19, 2004 @11:44PM (#8913095)

    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)

    by bob_dinosaur ( 544930 ) on Monday April 19, 2004 @11:44PM (#8913100)
    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...
    • 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.
      • 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.
        • 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.

          • 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.
            • There are pressable and swivelable joysticks, though, either of which would give an additional degree of freedom.
              • 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.
                • 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.
                  • 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 shoul
        • 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 [si.edu]to adjust the lateral motion of my mouse pointer and we'll be all set.

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

  • TUI emphasises transaction based interaction (Score:5, Insightful)

    by danpat ( 119101 ) on Monday April 19, 2004 @11:50PM (#8913138) Homepage

    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)

    by ka9dgx ( 72702 ) * on Monday April 19, 2004 @11:51PM (#8913145) Homepage Journal
    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--

    • 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 th

  • average users (Score:5, Insightful)

    by cloudless.net ( 629916 ) on Monday April 19, 2004 @11:56PM (#8913184) Homepage
    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 (Score:3, Insightful)

      by Brutus (moo) ( 661605 )
      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'l

      • GUIs vs TUIs and menu vs command (Score:5, Insightful)

        by 0x0d0a ( 568518 ) on Tuesday April 20, 2004 @03:47AM (#8914179) Journal
        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.
        • 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 page
          • "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...
            • the recent debacle on Slashdot about National City's CMU ATM

              /.'s search seems down at the moment, so: here. [slashdot.org]

            • 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 th

              • 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 bu
                • 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:average users (Score:3, Insightful)

        by God! Awful 2 ( 631283 )
        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
        • 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 remem

    • Re:average users (Score:5, Insightful)

      by yuri benjamin ( 222127 ) <yuridg@gmail.com> on Tuesday April 20, 2004 @12:38AM (#8913448) Journal
      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 (Score:5, Interesting)

        by Hes Nikke ( 237581 ) on Tuesday April 20, 2004 @02:25AM (#8913875) Journal
        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.
        • 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 inter
    • 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. "Differe

    • 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

  • 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 [rainingdata.com] jBase [jbase.com] ibm's u2 family [ibm.com]. 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? (Score:3, Insightful)

    by bluethundr ( 562578 ) * on Tuesday April 20, 2004 @12:08AM (#8913285) Homepage Journal
    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 [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)
    • 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.

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

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

        • you're still using the keyboard to input commands

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

    • Re:TUI? (Score:3, Informative)

      by nathanh ( 1214 )

      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 Sl

      • 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! ;)

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

    by _aa_ ( 63092 ) <j&uaau,ws> on Tuesday April 20, 2004 @12:12AM (#8913305) Homepage Journal
    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.

  • An idea: you could start with newt (Score:5, Informative)

    by Ayanami Rei ( 621112 ) * <rayanami&gmail,com> on Tuesday April 20, 2004 @12:20AM (#8913352) Journal
    Newt [redhat.com] 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.

  • Library Catalogues (Score:4, Interesting)

    by stick_figure_of_doom ( 729073 ) <rnk-slashdot@NospAM.kleckner.net> on Tuesday April 20, 2004 @12:24AM (#8913370) Homepage
    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? (Score:5, Insightful)

    by FFFish ( 7567 ) on Tuesday April 20, 2004 @12:39AM (#8913453) Homepage
    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?!

    • 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

      • 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 [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

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

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

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

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

  • Cell phones and mobile applications (Score:5, Insightful)

    by JonnyRo88 ( 639703 ) on Tuesday April 20, 2004 @12:56AM (#8913538) Homepage Journal
    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.
    • And just what's wrong with Remote Desktop?
      • 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... (Score:4, Informative)

    by burns210 ( 572621 ) <maburns@gmail.com> on Tuesday April 20, 2004 @01:02AM (#8913565) Homepage Journal
    ... 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 [bitsoft.com] off of Google Image Search. Very cool system, and it is GPLed, too!

  • I can vouch for this (Score:5, Insightful)

    by PedanticSpellingTrol ( 746300 ) on Tuesday April 20, 2004 @01:26AM (#8913679)
    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

    • I prefer ELinks [elinks.or.cz] over Links and Lynx.

    • Naim is pretty cool (Score:3, Interesting)

      by JonnyRo88 ( 639703 )
      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.
      • 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.

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

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

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

          • 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

  • Nobody? (Score:2, Interesting)

    by erydo ( 620806 )
    "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.
  • 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.
  • 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 cho

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

    by Gary Destruction ( 683101 ) * on Tuesday April 20, 2004 @07:10AM (#8914798) Journal
    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'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 t
  • First, there's tvision [slashdot.org], 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 [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

  • Why not an efficient GUI? (Score:3, Insightful)

    by Mr. Shiny And New ( 525071 ) on Tuesday April 20, 2004 @10:00AM (#8916065) Homepage Journal
    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).

  • Two Major Reasons (Score:4, Informative)

    by pete-classic ( 75983 ) <hutnick@gmail.com> on Tuesday April 20, 2004 @10:02AM (#8916088) Homepage Journal
    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
  • 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.
  • ...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

  • GUI is where it is at. (Score:3, Insightful)

    by scorp1us ( 235526 ) on Tuesday April 20, 2004 @02:41PM (#8919921) Journal
    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)

    • 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. (lo

      • 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 graphi
  • 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.
  • 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
  • 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 an

  • Text based interfaces are often better (Score:3, Interesting)

    by Jerky McNaughty ( 1391 ) on Tuesday April 20, 2004 @06:29PM (#8922941)
    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.
  • "'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 d
  • 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!

Slashdot Top Deals

"God is a comedian playing to an audience too afraid to laugh." - Voltaire

Close