A public forum for discussing the design of software, from the user interface to the code architecture. Now closed.
When I first started my previous project I read several books about UI. I tried to get a lot of different PhD level perspectives. In doing so, I learned that according to academia Microsoft has designed a really bad UI. [flame avoidance note: don't flame me with "everyone knows that" and don't flame me with "the UI for windows is great"] So, when creating a new software you have a choice. Do I do it the Microsoft way that users are used to, or do I do it the PhD UI book way that is more logical and clean, but the users aren't used to?
Microsoft does a lot of things the PhDs don't like. For example, there are several ways to do any one thing in a microsoft program. Think about how many ways there are to cut text. This creates a situation where people are "used to" about four different ways of doing things. The heart of the issue is that the PhDs want you to relate your UI to something people use every day, but your users use Microsoft operating systems and office software every day.
In the end, I went with a mix. I implemented some power users tools (key shortcuts) as well as very visible buttons to do the same task.
Has anyone else had this problem at design time? What were your solutions?
Remember that "Academic" has at least two meanings:
"Academic research is useful"
"Nevermind, that's academic."
As a base for Windows Programs how Microsoft does things is a good baseline because that's what customers expect.
That said, if you're app has different functions than MS-stuff, don't be afraid to "expand and embrace" the UI: that's what MS does...
Saturday, July 09, 2005
I think the four different paths is only a problem if they are in the same mode. If you can reach a screen through menus four different ways, you have a problem. If you can perform the same step through different modes (mouse, keyboard, telepathically), no issue.
Also, good UI is dependent on what the user is already familiar with. If the brake pedal should really be on the right, it doesn't matter. People are already used to it being on the left. No one in their right mind would switch it.
Having four different ways of doing the same thing supposedly confuses new users a lot. That's what the PhDs say. I personally don't think that people do any particular thing in more than two ways (under normal circumstances). I say this because I think people learn to do something a certain way and then they do it that way all the time, almost of our reflex.
It is interesting that you mention "modes" because the PhDs say that you shouldn't have them at all. This is why, they claim, that people can't program the time on their VCR. Clearly, as software engineers, we are used to having different modes. We can program VCRs by and large. The question is whether this is intuitive for program users.
I have a lot of experience programming in the real estate industry and our average user doesn't need four ways, they can't even figure out one (I mean, they are still using faxes for pete's sake!). I helped provide a program that our customers claimed was "easy to use." We only gave the user one way to do most tasks, like create a new entity, whatever that entity might be. Users seemed to like the straight forward UI. I don't think I ever got any complaints about keyboard shortcuts not working (no complaints about something like creating a new entity using Ctrl+N). Admittedly, in our custom forms section we used all the standard Word short cuts. Like I said in the original post, I think it requires something of a mix.
"For example, there are several ways to do any one thing in a microsoft program. Think about how many ways there are to cut text. This creates a situation where people are "used to" about four different ways of doing things."
I don't know about four, but there should definitely be a minimum of two different ways to do the same thing in any app, and very often three ways are appropriate. One way will be to use point and click on the gui, another will be to use the keyboard exclusively, either (1) through shortcut keys or (2) through the menu system. Less than that is an incompletely implemented UI, in my opinion.
This sounds to me like a shortcoming of documentation, not of UI.
There's nothing wrong with having four different ways to do something; but that doesn't mean you should have the docs say "To create a new document, either (1) click New on the File menu, or (2) hit Ctrl-N, or (3) hit Alt-F, then Alt-N, or (4) click the big blank document button on the toolbar." Instead you should pick the most straightforward way (usability testing can tell you which one that is), and document that. IMO, it's only after users are familiar with a command that they'll want to use the keyboard shortcut for it, or rearrange their toolbar, or whatever.
"It is interesting that you mention "modes" because the PhDs say that you shouldn't have them at all. This is why, they claim, that people can't program the time on their VCR."
I think you're making a hasty generalization and perhaps misusing the "mode" in terms of usability).
Mode refers to the context in which the input device can be used.
E.g., if the keypad can refer to POWER and TIME, depending on the MODE you're in. So the keypad can be in POWER MODE or in TIME MODE. VERY confusing to the user b/c they have to remember which mode they're in. (The Design of Everyday Things has an excellent discussion of this.)
This has nothing to do with having TWO ways to interact with the computer (mouse and keyboard).
I see (and have read) nothing wrong with control via mouse and keyboard. They're orthoganal. One does not affect the other. A user using the keyboard is not encumbered by the option of also using the mouse.
Now, if there were two KEYBOARD methods of getting the same job done, then your keyboard methods are twice as cluttered (or "verbose" ?) as they need to be. It'd be like listing an important website link on your home page TWICE. It can *seem* like a good idea, but it really just adds clutter. Less is more when it comes to design and usability.
Mr. Analogy -
<<Now, if there were two KEYBOARD methods of getting the same job done, then your keyboard methods are twice as cluttered (or "verbose" ?) as they need to be.>>
In almost every well-designed Windows app, you can print with either alt, f, p or ctrl-p. Both on the keyboard. The reason why is that ctrl-p is quicker, but the alt key always works without memorization.
Mr. Analogy is right regarding modes. Having multiple ways to do the same thing has nothing to do with having different modes.
In thinking about it, I think there should probably be four ways to do most things:
Two ways not using menus, one with mouse and one without:
(1) By clicking directly on a ui element on button with mouse, and
(2) By a keyboard shutcut that does same thing as (1),
and two ways using menus, one with mouse and one without:
(3) By using mouse to navigate through menu system and choose menu choice you want, and
(4) By using keyboard alt-key sequence and/or cursor keys to navigate through menus and make a choice,
and often a fifth way is good:
(5) Right click with mouse to bring up a context sensitive menu separate from main file system.
I'm actually curious what Ph.D's might disagree with in this. MS certainly has plenty of Ph.D.'s helping them with UI design. If the Ph.D's are objecting only to having different modes in a program, then that's something even people without a college degree can tell you, and that's also something that is not a problem with a UI that has all 5 methods of doing same thing listed above (i.e., you can have all 5 and still be a "single-mode" program). Seems like the problem with modes is largely a relic of the past. There aren't many Windows programs that make heavy (or even light) use of modes, although there are a lot of old Unix ones around that are heavily mode-based, e.g., vi.
Oh, one area where most Windows (and other) programs do make use of "modes" is in their use of "modal windows". These are windows that get the focus and then prevent you from moving focus to another window until they themselves are closed. Most dialog boxes in Windows (and Unix and Max) are this way, I believe. In most cases I think there are good reasons for using modal dialogs, i.e., the user should change whatever he/she wants and close dialog and go on with the program.
In some cases it's useful for dialog can stay open while the main part of the program is used. If this is done, however, then it can be easy to lose behind other windows and user has reponsibility for controlling its visibility. MS makes heavy use of non-modal dialogs, e.g., in the panels that are a big part of interface in VS.NET.
Overall, I don't think MS programs are any worse in their use of modal dialogs than Mac or Unix programs, but I could be wrong. I guess many unix programs lack config dialogs at all and instead force you to do things by remembering arcane key combinations or by editing a configuration file. Hard to see how that can be better than a dialog box, even if the dialog is modal.
Just as an interesting tidbit, "Refactor!" is a new plugin that MS is bundling with VB.NET for code refactoring. One of the big new features of this tool is that it is non-modal in design:
"Refactor! does something no other tool does: it brings the power of an entire suite of refactoring tools to bear with just one key ("One Key Refactoring") and it works directly on your code in your editor - so you'll never have to leave your code just to restructure it."
When using Refactor! you don't ever have to access settings in a modal dialog, instead you're given UI to change things directly on your editor screen, no separate little popup form or dialog that gets focused as a separate modal window.
Refactor! is made by DevExpress but MS struck a deal with them and is bundling it for free with VB.NET 2005, I believe.
[Post script note: I am going to try to find the books I read, but since they are at my old boss's house that might be difficult.]
Concerning user configured toolbars, "contextual" menus and letting the user change the UI in general: We decided that letting the user change the UI wasn't going to work for us. The reason is largely usability, debugging and technical support. If you let the user do interesting things with their menus, toolbars, fonts, and button sizes then you are required to do that much more testing on the product using those features in combination with UI features. Dictating position reduces technical support from people who accidentally moved or hide their toolbar and can't get it back. Dictating color prevents the user from changing his default color scheme and making your program really, really ugly. It also prevents the user from altering the fonts which could result in some very strange labels in your program.
Contextual menus, according to what I read and believe, are not the best UI. The main menu shouldn't change when you go to a different portion of the program. The main menu is where people navigate your program if they get stuck. The main menu should allow the user access to application wide functions and uncommon tasks (mostly so that they are hidden, out of the way of the more commonly used tasks). It provides stability in your program, which unconsciously makes users more at ease. They will report back "it was easy to use."
Concerning modes vs. having lots of ways to do something: modes are not the best design most of the time, because they are hard to learn. Think about how hard it would be to teach your mom how to use VI. Having lots of ways to do something is sometimes, but not always the best design. Microsoft has shifted the balance of this because they offer a great many ways to do any one thing. Therefore, people expect many ways to do something, which means you most likely have to provide them (depending on your users of course). Here are the ways most people use:
Visible UI elements: these are your buttons, text boxes, drop down boxes, check boxes et cetera. These are understood by most users since they have ample previous interaction with them. They are also visible available without doing anything. Additionally, normally they are labeled, sometimes on the specific control, and sometimes with a label right next to the control. Heavy use of these makes your program easier to learn, since they don't have to search for what they want to do. Also, commonly used tasks should have a visual representation because of their high volume use.
Menu Items: We used these for uncommon tasks (import from other programs, update your license, etc). It was part of our design to make sure we had single level static menus. There were no menus inside menus. Admittedly, we never intended to put all the functions that could be done with the program into the menus. In my opinion, the menus would have been a disaster had we done that. There is just too much information for a person who didn't write the program to digest if you put every function of the program into the menu. Contextually changing menus creates a situation where a function might be present in one screen, but not in another. It also breaks up any sense of continuity that your new user might have.
Keyboard short-cuts: I am in favor of these for the power users. They want to enter information quickly and efficiently. They are difficult for new users because you can't see them anywhere (right, since your main menu isn't bloated and listing every function in the entire program). They are a large productivity increase for experienced users. Overuse of these can confuse even the most experienced users though (was that Ctrl+Alt+T or was it Ctrl+Shift+T?).
Right click menus: I can see the use of these if you have a great deal of functionality and are trying to hide the more uncommonly used functions. I think they suffer from the bad UI as keyboard short-cuts, namely they can't be seen on the screen unless the user does something. We decided to try to make all functions visible so that our users could easily see what they were trying to do. Obviously, Microsoft has made large use of this type of feature, so experienced users might expect it, but if everything you want to do is already visible, what is the point of right clicking on something?
Documentation: Someone mentioned that it might not be a UI problem that it might be a documentation problem. Their assessment might be true but it is defeated by users not reading documentation. In my industry, nobody reads documentation. I believe that no single user of our program ever read the documentation. I don't even believe they ever realized it was there. Josh's generalized rule: No user ever reads documentation. Sure, I am generalizing, and you guys are going to come back with how you read documentation, and that's all true, but we are software engineers. We know we need to learn the rules before we can do anything constructive. The vast majority (hence "generalized") of users never read documentation. They expect to be able to "fool around" in the program and know how to use everything. I am almost to the point where I would write a program and not supply documentation in the traditional sense. I would depend on making everything visible, well labeled with the target language, with well explained error and informational messages and organized to the top and left of the program. I certainly wouldn’t print out the manual and send that to people.
I think we might have to break the documentation discussion into another thread…..
"Concerning modes vs. having lots of ways to do something: modes are not the best design most of the time, because they are hard to learn. Think about how hard it would be to teach your mom how to use VI. Having lots of ways to do something is sometimes, but not always the best design. Microsoft has shifted the balance of this because they offer a great many ways to do any one thing. "
The question of whether a program has modes is completely unrelated to whether there is more than one way to do the same thing.
vi has distinct modes: one mode where you can edit and insert text; another mode where you can navigate through and view text but not edit it. This has nothing to do with whether there is more than one way to do same thing. (Which, by the way, vi has too: since you can use cursor keys to navigate as well as corresponding keys mapped to same functions.)
MS programs may have modal dialogs, but I can't think of a single example (not saying there aren't any, though) where an MS program has distinct modes in a way like vi does.
There have to be at least two ways of doing the same thing in a gui program, for accessibility reasons. There should always be a 'point-and-click' way and always be a way to do it merely with keyboard. This is because not everyone can use a mouse, and interfaces for blind or otherwise disabled can't interact properly with mouse. But it's a gui, for godsakes, so you also have to make the functionality available through a mouse. I would go further and say that in many cases there should be four ways to do things (as I said above) because you don't want to restrict users to using the menu system to accomplish everything, and for both menu or non-menu method there should be both point and click and keyboard accessible methods for all functions.
It would be pretty surprising if MS had piss-poor ui's given the amount of time and money they spend on usability testing. Yes, they occasionally come up with some clunker idea, but for the programs that they've had and tweaked for a long time you can bet that they're not poor examples of usability. They may not be the best, but they're not bad. And since the interface on MS programs is basically what most users will be comfortable with, it becomes a standard that you depart from at your own risk (and at risk of confusing your users, even if you're trying to make an improvement).
I can imagine a user asking what the shortcut key combination is for a particular function. I can't imagine saying -- except without great embarrassment -- that there is no keyboard shortcut because I as the ui designer decided that for usability reasons I would restrict the number of ways a user should be able to accomplish that function. Maybe I could cite Ph.D's as support for such a decision, but that user (and others) will just notice that the program is less usable than it might otherwise have been.
This is just my two cents, of course.
"Do I do it the Microsoft way that users are used to, or do I do it the PhD UI book way that is more logical and clean, but the users aren't used to?"
If you want users to likey your program then there is an easy answer: you do it the MS way that users are used to.
Even if it's not the best ui, your users are already used to it. It will very rarely make sense to depart from a standard ui to something that you think is an improvement. Your users will very likely think differently.
People should realize that the usability books should be read like guidelines, not dogma. Actually many books say this in the introductory chapter, but somehow that never gets read...
With guidelines, you must recognize their scope and when other guidelines are more important. For example:
1. Providing a menu item, a keyboard shortcut and a toolbar button for the "Bold" command is usually good design in Windows. This doesn't clutter the conceptual model since there is just one command, but three ways to invoke it.
The most efficient way to invoke the command is the keyboard shortcut, but you should provide the other ways to promote learning (menu item) and platform consistency (toolbar button). On Mac, you'd only provide the menu item and the shortcut, which it guides the people towards the best way. On Windows, you can't do that since Microsoft set the precedent, and people have learned to rely on toolbars.
2. Let's consider a slightly different situation, say, mail marge. You could have a mail merge panel, a mail merge wizard, a mail merge dialog box, and a mail merge toolbar.
Now this will very likely confuse people. "What's the difference between the panel and the wizard? Does either of them miss some features the other has? Can I use them in conjunction?" And so on. Better choose one way of setting up mail merge and focus making that both learnable and efficient.
Similarly, the guideline is that "modes are evil." However, not all modes are equally evil and some modes are not evil at all. I'm sure many of these "Ph.D.s" can provide useful advice if you take care to only use it where it applies.
Sunday, July 10, 2005
Had you thought about asking the users? You could:
1) Give them a prototype (or working version) and observe their behaviours (or capture mouse clicks & keystrokes in the background),
2) Ask to sit in the work environment and watch how they get their job done. Use these observations to refine the UI.
3) Ask lots of dumb "what if" questions. Many users cannot articulate what they want but recognise a good thing when they see it.
Amazing things happen when you bring the end users in to the development process.
It's also amazing how often Ph.D. studies are logically right but practically off the mark. If Ph.D. analysis dictated development, the QWERTY keyboard (as one example) should had died off long ago.
Marcus from Melbourne
Sunday, July 10, 2005
Best way if you can: have users sit down and study how they use the program.
They have people dedicated to this, ie. Visual Studio 2005 -- they give developers a task and then study how they go about solving it in the tool.
Usability is a big deal, but not every boss likes to spend the money to do it right and wonders why the helpdesk is flooded with emails and phone calls. Just get the program done quickly and under budget (quoted by a salesguy most likely).
Marcus, studying the end users' needs and getting them involved is certainly an excellent idea. However, I'm not sure what your argument is regarding Ph.D.s being off the mark is.
Are you implying that if they got to design the next PowerBook, they would use Dvorak keyboard? Any of them I happen to know would know that Dvorak layout's benefits are currently disputed, and that you can't introduce a new layout without a burden unbearable for most people.
On the other hand, if Dvorak layout was shown to be superior and if PCs didn't exist yet, I'm don't know why Dvorak shouldn't be chosen. True, QWERTY was used in typewriters, but the change might be beneficial, underlining the fact that computer is not a fancy typewriter.
Monday, July 11, 2005
Definately a good discussion with alot of good ideas. I always try to keep in mind what the user is going to do, like alot of others suggest. Lotus Notes (I am forced to use it at work) uses F9 to refresh your email. And it has F5 as a shortcut for signing out. So anyone that hits F5 to refresh like any other Windows software will get signed out and they have to log back in again. This only makes me angry as a user. And if I was going to recommend a software package, I would not recommend using Notes for email because of this (and a few other things). So people can have a negative feeling about things in your software that could eventually hurt sales. Notes probably has a way to remap the keps, but I dislike it so much, I am not going to take the time to look it up.
Maybe I phrased it poorly. Too often I’ve heard or read people backing up their case purely on the basis of a ‘study’. My main contention is that any study, regardless of who conducted it, is not prima facie evidence that their case is correct. Or it may be correct in a theoretical sense but fails to translate in a pragmatic manner. I’m not, by any means, discounting or negating the benefits of Ph.D. studies per sè.
Your comment 'introduce a new layout without a burden unbearable for most people' hit the nail on the head. Studies have been conducted with alternative keyboard layouts which have been demonstratively more efficient that the QWERTY designed. Buy as you’ve rightly pointed, the practical implementation of this theoretical construct would be an arduous task.
Regardless of superior design, people’s habits and work practices are entrenched enough that a change is no longer a trivial affair. New Coke, Internal combustion engines, we could go on forever... theoretical study against real world implementation.
P.S. - the design of the QWERTY keyboard had nothing to do with typing efficiency or effectiveness. The intent was to minimise the occurrence of two keys colliding while typing.
Marcus from Melbourne
Monday, July 11, 2005
Marcus, thanks for the clarification. I see your point now and agree.
Tuesday, July 12, 2005
Great thread. Lots of interesting ideas here.
I would like to throw in my $0.02 regarding customizable GUIs. I am currently studying and working part-time on a helpdesk for an ISP.
Getting to an icon in Control Panel can sometimes be a difficult feat due to customization options.
1. The Start menu can be setup like standard Windows XP or in "classic" mode, so I often have to ask "Does your start menu have one column or two?"
2. The Control Panel can be setup in "classic" view or "category" view. So the question must be asked "Do you have about thirty icons or about ten?" (at which point the user begins to count, 1...2...3...4...)
So for the sake of anyone doing helpdesk keep your GUI consistent and non-customizable!
Tuesday, July 12, 2005
Don't be too sure that the Microsoft way is bad--they spend a lot of money on useability testing. 90% of the people out there are already accustomed to Microsoft conventions. They're not gonna like it if your app behaves in unexpected ways, & they won't care that the PhDs think it's "better."
Thursday, July 14, 2005
For the ways of doing things vs. modes discussion:
You have multiple ways of doing things when different actions give the same result.
You have inevitable modes when not all actions are always available. E.g. copy&paste only works if some text is marked.
You have dangerous modes when the same action can give different results, depending on what you are actually doing and where you are.
The latter is not always bad. E.g. the New function in Outlook creates a new mail, a new calendar entry, a new contact or a new notice, depending on the folder you are in. It would be a dangerous option if it would create a new entry in one folder and delete an entry in another folder.
How could the modes be avoided in Outlook? Only the Unix philosophy can help: One highly specialized tool for one task. I.e. one mail application, one calendar application, etc. But then you could have data interchange problems. There doesn't seem to be a silver bullet, and it wouldn't avoid modes at all: In the mail application, there is a mail browsing mode, a mail edit mode, and so on.
The question is: How much mode separation can the normal user handle? A solution could be to provide the ability to enable and disable modes to produce an adaptable application.
What I always wanted in an application is to enable and disable ways of doing things. I only use less than 5 percent of the available hotkeys, I always use the toolbar, context menus or the main menu instead. But more than none, I hit the wrong keys, not knowing what I've done now. Additionally, I have cats...
One big dialog with a list of all available hotkeys, where I can enable and disable them individually, and one single function to test if a key is enabled before starting the action can't be that hard to develop. Yet I've not found one single application providing this functionality.
One more always missing option is a "Fix it on current position" for configurable and dragable menus and toolbars. Given On as default, it would remove most "The gray bar with the text is gone" beginners problems. Better yet, a "Snapshot window outfit" and "Recall window outfit", when you are going to reconfigure the things and thus can mess around the nose straight along, knowing you always can go back.
Friday, July 15, 2005
I always hear about all this usability research that Microsoft is doing when the design of their UI comes up. Are there published studies, or are we just assuming that they did it before they wrote Windows 3.1 or Windows NT? I am seriously asking, not trying to imply that such studies don't exist.
Friday, July 15, 2005
Microsoft employs a small army researchers. See here:
Unfortunately, good research doesn't always translate into good practice. Consider the Microsoft Agent technology, or Clip-It or Clippy between friends. The Agent is actually based on a set of advanced Bayesian filtering algorithms. Unfortunately the interface to access those tools was devised by the management ("Lumiere" as in "The Beauty and the Beast"), and fine-tuned by the marketing ("Hey, it looks like you're writing a letter!").
The Longhorn should feature some of that technology with a more usable, less on-your-face interface. Unless that too gets cancelled, that is.
Microsoft also does or at least used to do usability evaluation, and it does or at least did affect their designs:
And finally, it's not like smart people would never get bad ideas. Such as Inductive User Interfaces for desktop computers.
Friday, July 15, 2005
I use Dvorak and I find it much superior. Sure, there is controversy and disputes, but those all come from ignoramuses that have never even seen much less typed on Dvorak.
Aapo, you mentioned tool bars should not be used on the Mac. Have you ever even used a Mac?
Saturday, July 16, 2005
Sheesh, I'm typing this on a PowerBook right now. It's not like toolbars shouldn't be used in Mac OS X applications. However, unlike in Windows, the toolbars aren't supposed to be cluttered collections of hundreds of buttons. Compare Word and Pages windows to see what I mean.
Here's what Apple has to say about this:
"Avoid toolbars that contain more than one row of controls or icons, and don't provide toolbar access to commands that Mac users typically access using a keyboard shortcut (such as "Open", "Save", "Close", "Quit", and "Undo")."
Saturday, July 16, 2005
OK, I see. Are there many programs on the PC that have multiple rows of toolbar icons? Would this prohibition relate to Photoshop and such wher ethey have palettes, or just to the toolbar at the top of a window. I can't think of any program on either platform where a document window has multiple rows of tool buttons. Uh, well maybe Word but that's the same on both in that way and its configurable.
It is true that you never see a save/open button on a Mac, but there are lots of programs that have undo/redo buttons.
Sunday, July 17, 2005
My Grandmother can't use Windows.
It's not that she doesn't understand what the computer can do, but that the interface in no way corresponds to her thinking of the world.
Say my grandmother wants to print the names of her 'christmass card list' onto the envelopes to send the christmas cards. Think of all the things that have to be done to prepare to do this simple task, so that in future each year of printing would be more efficient.
Where is the create a list of friends button in windows?
or the new envelope button?
Most people who use windows at home have handy tech support in the form of a workplace that uses windows, and their tech support. If you didn't have this level of tech support to answer questions about little used features like how do I configure the new printer I just purchased that only takes 4x6 photo paper, you would be on the phone to microsoft all the time.
Baaah! usability through telling them what they want to do is wrong and forcing users to think like programmers and thus training them, is hardly usability.
Tuesday, July 26, 2005
This topic is archived. No further replies will be accepted.Other recent topics
Powered by FogBugz