One thing that many developers fail to think about until it is too late is the user interface of their application. They may have a wonderful idea, or a really neat way of presenting it, but they don't think about whether they are properly presenting the information. They don't think about users with color blindness, problems with limited dexterity, people who can only type with one hand, or any number of other people with disabilities. Another thing that gets commonly overlooked (and tends to affect an even wider audience) is failing to use common menu shortcuts, keyboard mmenonics or other common UI practices. For example, imagine how annoyed you would be if you went to paste some text into an edit field, and you hit Ctrl+V and nothing happened. Or worse yet, if it did something other than paste text! These are the sort of things you need to watch out for when designing your interface. Now I'm going to spend some time picking on VS .NET for its interface mishaps. Some of these are things you should never do with an application, and others are just general nitpicks about how things behave.
What Were They Thinking?
- The first thing that popped out in my mind is the horrible use of menu shortcut combinations. They break the very first rule of UI design -- the principle of least surprise. They have keyboard shortcuts where you hit one set of shortcuts (like Ctlr+Alt+M) which switches you into a wait state (which you only know about if you happen to notice the message in the status bar, which is a terrible idea since there's no explicit feedback) until you hit another key (such as 1, 2 or 3, to open up Memory viewers while in the debugger). There are multiple things wrong with this concept, such as the stunning lack of feedback to let you know that the application is now in a wait-state. But the most pervasive thing wrong with this is the fact that keyboard shortcuts are meant to be quick and intuitive. There is nothing quick about hitting a shortcut and then trying to figure out why nothing else is working until you hit another key, much less intuitive. This is a great example of a good idea (shortcuts to fire common menu commands) gone horribly wrong. And they use this abomination no less than 24 times in their menus!
- Speaking of horrible shortcuts... The above example demonstrated a second, more easy to overlook UI problem. You should never, ever use Ctrl+Alt as a keyboard shortcut unless you absolutely have to. On non-English systems, Ctrl+Alt has a special meaning (typically called AltGr) and is used in regular typing. For example, Ctrl+Alt+n on some systems may actually enter the ñ character. Can you imagine how mad your Spanish users would be if they were trying to type niño in an editfield, and a menu command fired instead? When I went through and counted, I spotted at least 31 shortcuts with this combination. Unless they have different shortcuts for different systems, or they managed to hit only AltGr combinations that do nothing on all non-English systems, this spells trouble. Better to just avoid Ctrl+Alt combinations completely.
- One thing that bothers me is the fact that there is way too much UI going on all at once. At any given point in time, you're presented with a sensory overload of widgets to deal with. A typical code editor pane has no less than 4 different windows to look at, and at least two dozen controls all total. The form editor is just as complicated. I had a feeling of being overwhelmed by the code editor when I first started looking at it.
- The code editor behaves in wonky ways. One thing that I don't like is that it never seems to remember the state of the code hider widgets. When I hide the layout code (since I never add anything in there as it stands, and it's a huge method), it always seems to pop itself back open. Furthermore, the act of closing a code block with a '}' causes your code to move around and brackets to shift. This sort of thing drives me nuts. If you're going to force a code indention scheme (or other code schemes) on me, then do it from the start (like REALbasic does where the code indents when you open the block) and be done with it. Don't start moving things around on me when I close a block -- that's too distracting.
- One thing that drives me nuts about code editors is when the slow down to the point of being choppy. If a word processor can display 30 pages of text seamlessly, so too should a code editor be able to handle it. There were a number of times where I would be typing, and the act of wrapping a line would cause a scroll to occur, and it would choppily scroll down a handful of lines for me. It looks horrible!
- There seems to be no standard shortcut to go from the form editor over to the properties listbox. You should be able to tab from the control directly into the listbox. But since Microsoft chose to make tab move between controls (which is very acceptable in my book), there is no way to get to the properties list without using the mouse. Hitting enter takes you to the code editor (as expected), and any other tab combination already has a pre-defined meaning (like tabbing between applications with Alt+Tab or switching tabs within the application with Ctrl+Tab). Any time you force your users to use a mouse, you are angering people who like to use only the keyboard (like myself).
- The menu editor leaves a lot to be desired. For instance, it's somewhat WYSIWYG in that it shows you the mmenonics. But it doesn't show you the shortcuts. Also, it assumes that every menu item is going to have a submenu to it. Why not just mark which items are submenus when you want to make one? I think the number of terminal menu items is far greater than the number of submenus, and it cuts down on UI clutter.
- Another great UI mishap is the fact that the controls palette and properties window stick around while you're in the code editor. There is absolutely no excuse to have those pieces of UI taking up room in a location where you will not (cannot!) use them. They take up extra space, add to the visual clutter, and confuse users.
Things They're Doing Right
- The use of tooltips is very pervasive throughout the application. This is an excellent way to provide helpful information so that the user doesn't have to remember every single detail about what's going on. The tooltips are also interactive in a very intuitive way, making them an even stronger asset.
- The block comment autofill is a great concept. It's very intuitive to use and makes writing block comments really nice. It always keeps the same spacing as the previous line, and it makes the comment look very uniform.
- It is tough to pinpoint what things are being done well since you just expect them to work that way. You only notice UI when it gets in the way of the work you are trying to accomplish. So if you didn't hear me gripe about something, it's either because I think it's working well, or it's because I haven't tried using it yet.
These are just a handful of things I noticed in my first tour through the IDE. I'm sure there are other things lurking for me to pick on, as well as other things I think are excellent ideas. And I'm sure you'll hear about them as I explore more. ;-)
My overall impression of the IDE is that it is basically functional, and that's it. It's not a pleasure to use (like the language), and could handle a lot more polish. Hopefully Microsoft takes the IDE as seriously as they take the framework, and spend time improving the user experience. One thing companies with cool technology forget sometimes is that the UI you put on your product is your face to the world. If the UI is poor, and people don't like the looks of your application, they will never find out about the cool technology you have. They'll get frustrated by poor UI decisions and decide to find a different product. It's always worth your time to put extra effort into making your application look and feel as great as possible. You can skimp on other things, like annoying sales and marketing people instead. :: grins :: :-P
Leave a comment