GUIs Get a Makeover 540
jcatcw writes "From Xerox PARC to Apple to Microsoft, the GUI has been evolving over the years, and the increased complexity of current systems means it will continue to change. For example, Microsoft is switching from dropdown menus to contextual ribbons. Mobile computing creates new demands for efficient presentation while the desktop GUI doesn't scale to larger screens. Dual-mode user interfaces may show up first on PDA phones but then migrate to laptops and desktops. Which of today's innovations will become tomorrow's gaffs?"
I dont agree (Score:5, Insightful)
We have had simple and effective GUI's in teh past, like Atari's GEM, and Apple's Newton. Simple and effecitve. but they were tossed aside for much larger and complex systems, requiring more hardware and brain power.
The problem with guis is they don't work (Score:1, Insightful)
For a simple example, look at a spreadsheet in its most basic form. Tab goes to the next column over, return goes to the next row down. Entire usage of the software can be made in a text screen, and FAR quicker than entering a number, moving to the mouse, moving the mouse to the next cell, clicking, then moving back to the keyboard, when instead you can enter a number, hit return, enter a number, hit return, etc.
The "inventors" of the gui really have something to explain.
This must be the stone age (Score:5, Insightful)
Ribbons (Score:4, Insightful)
You'll take my File/Edit/View from my cold, dead hands.
Re:I dont agree (Score:5, Insightful)
I think the argument is better made that GUIs have evolved too much for their own good. I wonder what would happen if you launched NT 4's explorer.exe in WinXP.... I think i'm gonna go try it...
It probably won't change much more (Score:4, Insightful)
Let's cram more stuff on your screen (Score:2, Insightful)
This seems incredibly divorced from reality. Lots of people use multiple screens, and extending the same desktop across those screens works really well to manage the available space. The answer from Microsoft Research -- waste all that space by monitoring more information. So we should just take that extra screen and fill it up with pretty desklets? And this will make me a more productive person?
Re:The problem with guis is they don't work (Score:5, Insightful)
Bottom line: For an expert user, GUIs slow you down. Basic to Intermediate users, especially middle-aged non-techies, GUIs are a godsend, -- when done right --.
Comment removed (Score:2, Insightful)
Re:The problem with guis is they don't work (Score:5, Insightful)
There's a lot of scientific user interface research that contradicts your sweeping claim that "There's been no evidence that they actually increase productivity ...".
A shell is itself quite a sophisticated user interface, and the commands and scripts you type into the shell are user interfaces, themselves. The TOPS-20 operating system provided completion and help built into the command line of all its utilities and applications. Tell me that's not a user interface. Unix has a much worse, non-standard way of providing parameters to programs and getting help about their parameters, and a lackluster hodge-podge of shells and scripting languages, which are some of the worst text based user interfaces in common use.
There are many things that guis make easier, like picking from a list of choices (menus, trees, scrolling lists, etc), drawing and painting (sure you could paint in a shell by typing in x,y coordinates, but that illustrates my point that there are many common tasks that a gui is better for than a command line).
I understand that you're probably just trying to play the Luddite, by rejecting all graphical user interfaces out of hand in favor of a text based shell, but shouldn't you reject all computers, cell phones and other electronic (and steam driven) devices, if you really want to be consistent? I mean, if you hate bad user interfaces, then you certainly shouldn't use the shell (or at least you should run it under Emacs so you have some reasonable input and output editing ability), because most shells have absolutely horrible user interfaces (i.e. arcane syntax). That's right, the syntax of a scripting (or programming) language IS a user interface. Unfortunately many language designers (i.e. PHP, Perl) have no concept of user interface design, and make many foolish usability mistakes that a competent graphical user interface designer should never make.
Have you ever try to explain csh history substitution syntax to your grandmother? Even if she knows how to send and reply to email with a graphical user interface, it'll probably take her a long time to learn how to use the shell.
-Don
Re:The problem with guis is they don't work (Score:2, Insightful)
Re:Let's cram more stuff on your screen (Score:4, Insightful)
Well, they _work_, but I wouldn't say they work *well*. Some examples:
* OS X only has a single menu bar for all applications and all screens. So if your active application window isn't on the primary screen and you want to access the menu, you need to track all the way back to whichever screen is the primary to access it. Ditto for the Dock. Why can't there be a Menubar and Dock on each monitor ?
(Personally I've always found it rather ironic that MacOS was the early bringing of good multimonitor support, but its UI really doesn't handle them well).
* Windows has a similar problem with only one Taskbar and only one Start Menu. Why not a Taskbar for each monitor and/or, even better, the ability to pop the Start Menu up directly under the cursor ?
* Mouse tracking across multiple, big displays is slow or inaccurate unless you've got the twitch muscles of a fifteen year old first-person gamer. I want trackers on top of each screen that can monitor where I'm looking and move the mouse cursor to that spot.
* There's (typically) no "maximise across all screens" button.
So we should just take that extra screen and fill it up with pretty desklets? And this will make me a more productive person?
This seems to be the model most people think of when talking about multiple screens. For example, the typical multimonitor Mac user wants one screen for their Photoshop (or whatever) window and the other for all the palettes, toolbars and feedback windows is spawns.
Re:The Human Computer Interface (Score:2, Insightful)
The Apple OSX voice stuff is pretty cool but not responsive enough to be useable. And all it does is integrate into the window manager.
Actually, in OS X you can ask it the time, and it will speak it. You can also ask the date, tell it to start the screensaver, and a whole bunch of other crap. It's certainly not perfect, but it can do a lot more than just open/close windows.
Re:Ribbons (Score:4, Insightful)
I can tell you, I have used it, and it is far superior to any other layout scheme in an office suite I've seen. It takes up as much space as a toolbar+menus, it has much larger icons which let you see what effect you are going to have. Everything is easy to find, the layout is very logical, it highlights the portions that you need at every moment, and last but not least: it's very pretty. It's actually something that MS has done right, it's shocking!
There is a learning curve, but it's not a very long one. After five minutes of clicking I knew basically where everything were (a vast improvement over the old "hunt through the menus till you find what you want"-approach, here you can actually find stuff where they should be). If you are THAT annoyed over the ribbon you are either a) not very smart and has a hard time learning anything new or b) an unapologetic a-priori Microsoft basher. The fact is, it's far better than anything else on the market.
Re:The problem with guis is they don't work (Score:5, Insightful)
I've gone ahead and highlighted the critical flaw in your well-thought out argument.
People aren't well-trained in anything. The entire point of having a computer for most people is to make the computer SOLVE problems for them, not CAUSE problems that require training to fix. Most people don't want to take the nontrivial amount of time required to learn how to use a command prompt well, and it's for those people who GUIs are for.
Re:I dont agree (Score:3, Insightful)
I'd say the opposite. When systems are overly complex, it's a sign that they're in need of simplification. OS X shows what such a system looks like. Users have an easier time working with the system, while programmers have an easier time maintaining it.
Windows Vista shows what happens when you keep trying to complicate an overly complicated system. The system eventually extends beyond the control of the developers, making each change more and more difficult to make. Users feel it in the way of a confusing interface, and slow progress.
As for biology, I don't see any signs that things are tending toward more complex. Even a single celled organism is quite complex. Multicelled organisms are the ulimate in modular software.
Re:I dont agree (Score:5, Insightful)
I fixed that typo for you, no need to thank me.
Re:GIMP (Score:2, Insightful)
Especially when they're talking about using it through the command-line, for chrissakes. I can definitely think of some good examples of the command-line speeding up tasks immensely, but when you're dealing with graphics it's absurd to suggest most of the tasks (i.e., not mathematically generating abstract patterns or completing very simple tasks like red-eye correction) for which people use Photoshop can be completed more efficiently through scripting.
Graphic-intensive solutions for graphic-intensive problems...
Voice recognition is NOT the answer (Score:5, Insightful)
What most replies here lack the understanding in is that an input method has its purposes and its uses. See the whole CLI vs. GUI argument here. Voice is just another input. It's great for GPS navigation or a mobile phone in your car, but for an office suite? Definitely not: ugh! How about in a library? How about at a LAN party? Anywhere where there are many people.
Voice recognition isn't the "killer app" of input devices. I think a combination of keyboard, mouse, stylus, joy stick, voice recognition, and touch screen would be a good start. Voice recognition for dictation, keyboard for editing, stylus for graphics drawing, mouse for web browsing (fine grain arbitrary clicking), touch screen for fast navigation of larger buttons (coarse grain arbitrary clicking), etc.
Why must we be confined to the keyboard and mouse?
Re:GTK+/GNOME file chooser disaster. (Score:4, Insightful)
Here's a fun one, setting an external application as the default action for filetypes in eclipse, can't just type the command, can't use the $PATH var, have to browse around all the bin directories looking for the app you want with that horrible chooser.
grrr, the eclipse guys do a really good job, but when choosing a "run" application, there should ALWAYS be the option to just type the command if you intend for your product to be used on a *nix variant.
contextual menus are nice but... (Score:3, Insightful)
This used to be more or less a design standard (I think apple published it in their human interface guidelines?). For the most part, people use keyboard combos, toolbar buttons, or context menus; however, the main menu serves as a kind of index of all of the functionality that is available in the application. On macintosh it is also a place to quickly look up the the keyboard shortcut binding for a function.
Unfortunately, some developers have gotten lazy recently and made functionality available through only one source, instead of the usual triplet of main menu, context menu, and keyboard bindings. This is annoying when someone makes functionality that is only accessible by context menu, but it is crippling when functionality is only accessible from a keystroke. Worse, sometimes there is no documentation as to what keystroke is needed, and the functionality becomes less of a feature and more of an easter egg for whoever stumbles upon it.
Sadly, Linux software is the main offender here. Unfortunately many developers are totally unaware of the importance and difficulty of good UI design, and writing a GUI becomes an afterthought. In large companies this is rectified because people who specialize in UI design are hired, and on macintosh and windows, apple and microsoft publish UI standards that all applications should meet, but no one seems to be providing this service for Linux.
One other deadly sin of software design is writing software that is only configurable through a text file. Having a human readable text file to configure the application is a feature, but *not* having a preferences GUI in you application that wraps all supported features in the config file is just downright lazy.
Worse are applications that use a scripting language to configure themselves instead of a regular record format (i.e. xml properties files like apple uses, or
Re:Ribbons (Score:3, Insightful)
Re:I dont agree (Score:3, Insightful)
Re:We don't need any steenkin' new paradigms... (Score:3, Insightful)
Re:The problem with guis is they don't work (Score:5, Insightful)
The only experts who really benefit from CLIs are experts who deal primarily in text.
But the most important thing to me is this: It's very easy to run a CLI in a GUI; it's impossible to run a GUI in a CLI. Therefore, all computers should come with a nice GUI by default and users can easily run Terminal.app (or whatever) if they want a CLI.
Comment removed (Score:3, Insightful)
Re:The problem with guis is they don't work (Score:3, Insightful)
ANY filesystem manipulation?
Like if I wanted to sort my digital images (with the helpful camera name IMG0030-IMG0090) based on which ones were pictures of my cat? That would be quicker with a CLI?
Come on, man. Think about these things for a few minutes before you post them. You'll look smarter.
Johnny Cochran? Is that YOU!?? (Score:4, Insightful)
Rather, if Chewbacca lives on Endor, you must acquit. I think that a function of evolution is that as traits emerge, a species starts to diversify, and the complexity of the system by which the trait is favored becomes more complex, until it flat out wins, then there is a return to simplicity.
It's sort of that way with scientific theory. Someone will have a quantam leap (no pun intended) forward in a model that describes the universe, and it's something really short and sweet, like E=mc^2. And then science says, "Oh, except when you're in a crowded elevator!" and, "Well, not really for very large values of 2!" and wonderful stuff like that, until someone realizes that, duh, the universe is really simple. And so on.
I want to also say that when I say the universe is really simple, I don't mean we can comprehend it. I just mean it's simple. If Chewbacca lives on Endor, you must mod me +5 Insightful.
Re:GIMP (Score:4, Insightful)
Re:The problem with guis is they don't work (Score:3, Insightful)
My prediction (Score:4, Insightful)
My prediction is one mentioned in the blurb: the contextual ribbon. It sucked in XP and it looks like it will get worse in Vista. It's an interface designed around the assumption that users cannot learn. It's great for a newbie, but it blows chunks for intermediate and advanced users. It's a usability issue. When menus reorder items the user is unable to learn where they are. Half locations I click on in Windows menus are those stupid down arrows to see the REST of the freaking menu!
If you have too many menu items that you need to start hiding them, start rethinking if you need all those items. Think of <gasp> submenus. Think about other forms of command. Don't throw out the entire menu concept, because it ain't broke!
Re:GUI? Bah! (Score:3, Insightful)
A 5 page story about GUI's and not a single picture.
Some people, you just can't reach.
I wonder... (Score:1, Insightful)
I wonder if this would be a benefit for a system, like the Mac, where it already has a mile-high menubar.
The ribbon's icons are bigger, true, but the mile-high menubar takes up less space but is "bigger" to hit with the mouse. (Oh, and since you have one ribbon per window, the Mac menubar takes up *far* less space, overall.)
Perhaps Apple didn't invent this because they didn't need to. It does seem like an awkward interface, but Microsoft did need to do something about their tiny, hard-to-hit menubars. Perhaps it was inevitable that they'd come up with a solution less elegant than just fixing the menubar (which would have the side effect of admitting Apple has been right for the past 20+ years, and they were wrong).
If you are THAT annoyed over the ribbon you are either a) not very smart and has a hard time learning anything new or b) an unapologetic a-priori Microsoft basher. The fact is, it's far better than anything else on the market.
Ah, I love that argument. 'If you don't agree with me, you must be prejudiced, and please disregard the implicit prejudice in this sentence.' (Bonus points for using incorrect grammar in a sentence accusing others of being "not very smart"!)
Re:What's the smiley for shaking head! (Score:2, Insightful)
It might not be the most user-friendly way to do things, but I promise you this, a person with good knowledge about a command line will be much more efficient at typical those tasks available through the command line than an equally knowlegdeable GUI user.
From your statement it also sounds as if you are saying that Linux is unable to provide users with a graphical user interface equal in complexity to Windows or OSX. This only proves you do not know what you're talking about.
Don't move, highlight (Score:2, Insightful)
Don't change the position of menu items and controls, highlight or emphasize controls the AI thinks will be useful. Instead of tucking away infrequently used menu items under a submenu or pinning frequently used controls onto a ribbon, why not just change the color or text size of menus/controls according to past use or predicted use?
AI should point out where the menus/controls are rather than risk disorienting the user by moving them around. For example, if the AI determines that the user will probably want to sort the selected data, maybe the menu containing sort can change to a "hot" color while, say, the view menu turns cooler. This way the program is teaching the user a consistent way to do the task.
This is already being done in WinXP, e.g. newly installed programs are highlighted. Visual Studio also has a nice dynamic help panel that directs you how to do things rather than just doing it for you (and leaving you at the whim of the AI when you need to do the task next time).
When I teach people how to use a program, I often find myself telling the user what parts of the window/screen are significant to look at during what particular tasks. Computers are gradually getting better at guessing what you want to do, but since we're not there yet, let's keep the AI's predictions suggestions instead of a forced rearranging of your environment.
Re:I dont agree (Score:2, Insightful)
You really do not want the GUI in a graphics editor to draw attention away from what you're working on, and for instance a pure color will interact with areas in any variation of that color to confuse the eye (well, brain) so you should use neutral colors in the GUI where ever possible unless you've got a very good reason not to.
One way to make the GUI less busy would be to drop the dividers between buttons and instead make the icons themselves stand apart from each other, perhaps using discreet dividers to indicate groups.
Take a look at Photoshop's GUI, and ask yourself if it looks busy or calm. If you think it looks calm, it's probably because of neutral colors (mostly grayscale), high contrast only where needed to catch the eye, seing the cursor over an arbitrary background, or for readability. And tabs to keep functions you don't need out of the way. Note the size of icons, buttons and bevels too.
If you think it looks busy, it's probably your Windows' theme that's messed up
Re:Yeah, that's tab completion. (Score:3, Insightful)
Read the article I linked to: it describes how TOPS-20 programs and commands can document themselves to the CLI, so it can provide the user with consistent completion and full help about the parameters, insert (and ignore) noise words, and provide completion over alternative symbol spaces for special types of arguments, like host names. That was quite useful when ARPANET addresses were only 8 bits long, and you could type "teln mit-?" to get a list of all host names beginning with "mit-" that you could telnet to. TOPS-20 command line help and completion is much more comprehensive and standardized than the hodge-podge of Unix shells and utilities and weird scripting languages and quoting conventions like: find . -name '*~' -exec rm "{}" \;
-Don