GUIs Get a Makeover
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 think they have been slowly DEvolving over the years, becoming more bloated and complex. They are starting to outreach the average joe.
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.
---- Booth was a patriot ----
Gotta love an article on graphical user interfaces with no ... graphics ... of the user interface.
You'll take my File/Edit/View from my cold, dead hands.
So long as we're still using the mouse/keyboard as a primary interface for our computers, the current GUI model will likely stay pretty much the same for at least a good ten years or so. Once something better comes along, such as AI-assisted video/object recognition, it may open options similar to what was in Minority Report. Until then though, using a cursor for interaction will remain more effective than cursing at our machines directly.
8==8 Bones 8==8
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?
I'd wager that, in the long term, GUIS might not increase productivity.. But an -intuitive- GUI for the end user sure as hell minimizes training for a lay user. Visual Icons representing actions are great reminders for those people, especially older ones, who can't remember three letter short-cut commands.
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 based on user account deletion
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
Take a look and feel free: http://www.PieMenu.com
So if I'm airbrushing a busy background out of a photo, which has enough colour variation to make it a bit confusing where the background ends and main thing begins (I edit photos for the technical manuals I write for industrial equipment), you can do this in GIM with scripting?! Cool!
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.
A sphincter says what?
> There's nothing you can't do in a shell that a gui provides extra ability for, when you've been well trained or decided to -learn- how to use a text mode interface well.
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.
there is no need to sign your posts. this isn't usenet. your username is right there above your post. stop it.
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 a common thing I read here, but I whole-heartedly disagree. I already think office noise chatter is too high. I don't wnat to imagine when everyone is talking to their computer to tell it what to do.
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?
:wq
Congrats on picking my pet effing hate, our university servers seem to have that DAMNED gnome filechooser as their only installed one, and as a result both eclipse and firefox use them for everything.
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.
I think that by convention every function available in an application should be accessible either directly or indirectly from the main menu.
.ini files like on windows, or the registry, etc). Using a scripting language to configure the application makes the file more difficult to edit for novice users, makes syntax errors more likely because the syntax is necessarily more complex, and makes parsing by third party applications more difficult because, again, the syntax is necessarily more complex. Additionally, a scripting language is just stupid overkill for a configuration file that needs to turn on and off options and specify a path. By definition, a configuration file shouldn't be doing anything *conditionally*. If something like that is in a .conf file, than you put it in the wrong place. Sadly, many linux daemans are guilty of this (especially apache, which is otherwise a nice and powerful web server).
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
In Vista, you apparently are supposed to click on the small Windows logo, click on an unlabelled right arrow, and then click Shut Down to turn off the computer. You have to love progress...
Depends on the type of "expert." What if I'm an expert drafter? Or an expert artist (visual or musical)? Or, hell, even an expert accountant?
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 of the year
With GNU/Screen, you don't even need that!
ny filesystem manipulation?
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.
Comment of the year
The analogy is false, because its premise is false.
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.
Please stop stalking me, bro.
Worthless? Time is priceless. It's the only thing that, once you give it away, you can't get it back. Unlike money or love, time only ever flows in one direction.
--help and man are the problem. I've got 7 chunks in mind, I need to write a command to use them, shit, what's the name of that option again? man foo. Ahh, I see, now what was it was I doing again? Oh yeah, did I write that down? No, damn, better go back and find it. When you use the command line you actually learn not to keep 7 things in mind. You keep about 4 or 5 in mind and write the rest down cause you know you're gunna need 2 or 3 slots just to get the commands to work. GUIs eliminate that. And before you start scream "that's not true" or "I don't do that", scientific usability studies have shown this to be the case, go do some research.
How we know is more important than what we know.
Which of today's innovations will become tomorrow's gaffs?
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!
Don't blame me, I didn't vote for either of them!
A 5 page story about GUI's and not a single picture.
Some people, you just can't reach.
Au contraire!
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.
Scully: Should we arrest David Copperfield?
Mulder: Yes we should, but not for this.
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.
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
Take a look and feel free: http://www.PieMenu.com