According to Kermadec, said some new users are either afraid of computers or bored by them. They don't care about the metaphors of the user interface or the niceties of icons, menus and widgets. Calling it "Start" in the old days was a very good move in that it clearly told users to "start here. From that menu, Vista will open a sort of window-meets-web-page, filled with buttons and icons, that clearly tells the user, in plain English, what to do.
There is even a little colorful shield icon next to some links to suggest some kind of big security system is protecting the computer.
When clicked, these links cause a playful cursor to appear and a big reaction — screen dimming. A strange, awkwardly worded dialog will pop up but that does not matter: there is a big button in there to proceed, which the user can now click, safe in the knowledge the computer is doing some thinking for them. Then, the appropriate window will load, with buttons bigger and brighter than the last one.
The average user feels like a real computer user now: look at how the big machine reacts to his every whim. Kermadec says Mac OS X is more complicated for these users because it wants them to understand the structure and metaphors. Once users learn the logic, then they appreciate its elegance, especially when things go wrong.
I am certainly not arguing that Apple should imitate Microsoft or model its interfaces after Vista's. However, experience clearly shows that logic and elegance are not always the best counselors when it comes to channeling people into action.
For years, we have thought that Microsoft attempted to copy Apple and failed miserably. In some ways, I believe they copied Apple and made a conscious choice to favor immediate action over long-term empowerment, thus creating the much maligned Start menu and Wizards. Besides, the user interface isn't understood from one element or feature; it's about the whole enchilada. Perhaps we can gauge each user interface by the guidelines presented to developer? Here I'm afraid that the depth of the Mac interface and the shallowness of Windows is evident in these documents, and that includes Window's Vista incarnation.
Take, for example, the most basic design principles offered to programmers. Here are the top concepts that Apple and Microsoft present:. Human Interface Design Principles [I added a sentence or two to each item in order to match the Microsoft version. Repair steps how to repair a computer Almost all PCs are not created equal. No matter what happened land crashing your PC, you can still restore it, or at least get all your Read More ». Throughout the keynote he made many references to what he will do with his free time once he retires from day to day operations at Microsoft.
It turns out Bill has big plans in addition to his Read More ». There are a few scenario-specific variations you can use. If the action to be taken is very critical ranging from overloading a nuclear power plant to deleting files permanently , then the default action after the timer runs out should be cancel. The dialog should not go away, but rather the text label changes to show that the action has been canceled.
The user can choose to confirm the command or cancellation. Always make sure buttons that perform critical operations are clearly marked—always use clear text that accurately describes the action.
If the action is the deletion of files, do not write "Remove Files from Repository"; write "Delete Files from Repository. Someone once said, "You are as good as your worst work. A single bad experience with your app can make a big negative impression on the user. To make sure this does not happen, one thing you can do is to make sure that if your application crashes, it goes down gracefully.
If you can add data recovery, or allow the user to try to save a copy of that data, it can be a big plus. The user should be properly notified if the application crashes. A JIT-Debugger or a critical error dialog is not a good thing. While talking about how to handle crashes goes beyond the scope of this article, I will recommend that a simple dialog that apologizes to the user and informs him or her of the situation and possibly with a link to more information on how to recover from this crash would be very helpful to the user.
If you want to take it one step further, you can do what one of my favorite graphic design applications does. If it crashes, it will show a recovery dialog which would allow you to save a separate copy of the file being worked on, and then would give you a feedback dialog where you can enter information about the crash personal information optional, of course and send it to the creators.
At first glance, the method for making a one-of-many selection does not seem so difficult or important. Sometimes it can be—especially if the scenario is an application used for time-sensitive work.
Let's take a look at a real life example. Microsoft recently released a preview version of a graphics application, Expression Graphics Designer formerly codenamed "Acrylic". I had about 20 graphics objects to which I had to assign a certain property separately in this application. It was a dreary process. To do this, I had to select the object, click the button for bringing up the settings window, and set the options.
In one such option two choices had to be picked from a ComboBox, as you can see in the following screen shot. When you have to drop down the ComboBox list and select the second item out of only 2 items it can be really irritating.
What we do not generally realize is the time it takes for the drop down list to appear. It can waste a lot of your time and can be frustrating. This could be solved easily by putting in a GroupBox with two RadioButtons—especially when there is so much space available. Besides wasting time because of the drop-down animation, it also wastes our "mental bandwidth. With the ComboBox it will be processed only after the list has been drawn. While it may seem too unimportant, it actually is very important.
Short of putting a gun to their heads, this is the most destructive thing a developer can do to users. When your application, unnecessarily or otherwise, interrupts the user while he or she is working on another application with a message box or a taskbar flash, you earn negative points from the user. Taskbar flashes can be useful, of course, but should be called upon only when your application's process requires input from the user to continue, or if you have something critical to convey to the user.
If the user has kept the taskbar on Auto-Hide, a flashing taskbar button can obstruct the user from accessing the status bar or other low-anchored controls as the taskbar would be on top of it and will not hide again until the user has clicked the flashing button. It is good policy and manners to not disturb any other application's toasts. Obstruction of such windows can be annoying and unproductive. Sometimes you may need to show multiple items by the toast.
Popping up 3 or more toasts would not really be advisable. Microsoft Outlook implements a similar solution when notifying the user of incoming e-mails. Often there are tasks that require the user to wait. Of course, this is one of the things that the user simply hates to do. But worse is when they are waiting without knowing what is happening. Sometimes your application may need to connect to a Web service or a remote computer, or maybe it is processing large chunks of data—whatever the reason, the user should be made aware of, or at least vaguely aware of, what is happening under the hood.
There are different methods of doing this, based on the situation. If you are connecting to some far off object like a Web service or something placed on a network or Internet server, it would be advisable to show a simple progress dialog see the following image , or a progress bar hosted in the status bar. An accompanying label should describe the current status of the process. For example, if you are connecting to a Web service to process some data, just say "Connecting to Web service It is highly recommended that you set the progress bar Style to Marquee mode if you are using a progress bar and the processing time is unknown, or if you do not have a maximum value.
Another method that is becoming popular is a fixed 'toast' window that displays progress. Of course, this should be used only for asynchronous processes only. Otherwise the user may feel disconcerted. Such windows are best used for background processing such as downloading an update or performing a scheduled task, and should never be set to "Always on top. It is safe to assume that if faced with a plethora of controls on a single form, a typical user will be confused to no end.
Sometimes, no amount of grouping, sizing, or spacing can help you when you have many important controls. A Wizard is the best thing for such scenarios. You can divide controls by task or categories as applicable, and place them in separate steps.
This can help the user stay focused and not be daunted by the task. You can provide step- or task-specific help with a Help button. Wizards are also a good way to help set up the initial configuration of your application. Many applications use such a wizard to set up personalized configuration just after setup is completed, or on first use. Such an initial wizard should also be made optional, if possible—if the user cancels at any point, the unspecified settings go to default values.
If you can make the wizard a bit graphical see the Use Pretty Graphics section , it makes the configuration task that much easier. This is the impression and feeling given by the text in your application. This can be anything from a simple tooltip, to an instruction label control.
That is called proper text tone. When dealing with non-technical or novice users, getting the message across takes on a different aspect. A good alternative is to specify what you want the user to do: "Select the folder where you would like to place these files. Providing a clear description of what you want the user to do also lessens the need for Help files, or at least lessens the details you need to include in Help files.
A very good suggestion from the Windows User Experience Interaction Guidelines applies to any software. It states that the writer should keep the text conversational. The Guidelines defines this as, "Avoid words you wouldn't say to someone else in person. Sometimes you can't escape having a complicated UI. The best thing to do in such a situation is to make the experience as easy as possible for the user.
A sidebar consisting of link labels, or a TreeView for hierarchy-based navigation, suggests a sibling level navigation for the current dialog's task. It makes it very easy for the user to jump between steps of the process while knowing where he or she is. If you go for a hierarchy-based navigation with TreeViews or other similarly complex navigation, a good utility for the user would be a breadcrumb control. While Visual Studio does not ship with a built-in control for this yet, see Creating A Breadcrumb Control for information on creating one yourself.
A breadcrumb control makes it easy to find the current location in relation to the hierarchy. Breadcrumb navigation can be easily merged into the header if the form has one. See the previous section on headers. Everyone loves applications with cool graphics—the majority does, at least. While a UI with pretty graphics isn't a logical choice for all applications, it does help to make a nice impression and can be a pleasure to work in.
This goes on for about, oh, eleven pages. Granted, these comments refer to the beta, but the shipping version of Vista is every bit as schizophrenic in design. There's very little consistency. It also seems every individual team at Microsoft has a profoundly different idea of what the user interface should look like, as Paul Thurrott notes : And what's up with the glaringly inconsistent UI across Windows Vista and all of its applications?
Some windows have menus, some don't, and some have hidden menus. Some have these new black toolbars, some don't. And so on. Why isn't there a team of people just working on consistency issues? Aren't these trivial, nitpicky complaints? They are. And that's entirely the point. This little stuff matters.
0コメント