"When I am working on a problem, I never think about beauty. I think only of how to solve the problem. But when I have finished, if the solution is not beautiful, I know it is wrong." - R Buckminster Fuller
User interface is 47% - 60% of the lines of system or application code. Macintyre, Estep and Sieburth, 1990
A GUI is minimally 29% of the software development budget and increases with available functions. Rosenburg, 1989
The UI has been documented as commanding 40% of the development effort. Wixon & Jones, 1992
PAGES ON UI DESIGN
March 1, 2005
When we review programs at DonationCoder.com we look for programs that get both the feature set and the user interface right. It is simply not enough to make a powerful program - in fact the more powerful and complicated the program, the more important it is that the user interface is well designed and not overwhelming or confusing. Try some of the programs that compete with Beyond Compare (they are listed in the left sidebar) - you'll see that it's not easy to present all of the information needed in a folder comparison view, and not easy to present all of the appropriate actions and options to the user.
Your views about what constitutes the perfect user interface may differ from ours. To give you a better idea of how we tend to view user interface issues we've prepared a short summary of our thoughts on the matter.
| Skins | We hate them; we're not totally opposed to building some consistent window theming/skinning functionality into an operating system or window manager, but individual apps should not use their own unique skins except in the very rarest of circumstances. We find skins distract the eye and make it difficult to use the program in an efficient manner. |
| Sounds | We hate them; other than error notifications, they are just distractions and they decrease the effectiveness of error sounds. |
| Confirmation Dialogs | Destructive or potentially damaging operations should have confirmation dialogs on by default, but the user should be able to check a box saying to stop displaying them if the function is one that could be used frequently. |
| Sizeable Windows | Mandatory; we occasionally come across programs that should have sizeable windows but don't, because the programmer was too lazy to implement proper control sizing. We usually uninstall such apps immediately. |
| Drag&Drop Support | Lack of drag&drop support on forms or controls that take file/folder names is a pet peeve of ours. It can require some work on the part of the programmer to support such a thing, but for those of us who use a file manager regularly, the lack of drag and drop support is a real downer. Conversely, we have found that support for drag&drop functionality is a surprisingly reliable predictor of a programmer who has spent time designing a high quality user interface. |
| Right Click Properties | Apple has famously insisted that all applications for Macintosh computers be designed for single button mice, and the official Macintosh mice have only one button. We think this is a great idea, if by good idea you mean the stupidest thing we've ever heard. The idea to use a right-mouse click to bring up options for the current selection was a serious innovation in user interface design. It's a great feature and we expect to see it used liberally in well-designed applications. |
| Icon Subtlety | Some apps overwhelm you with icons on their toolbar and menu - icons that are ether too gaudy, too jarring, or just inconsistent. We have found that the best icons are those that both convey meaning and do so in a subtle way that doesn't distract your eye while you're working. In general we believe that a user interface should fade from your consciousness while you are working. |
| Help Files | A help file is part of the user interface; a program without a help file is incomplete. |
| Shell Integration | 50% of the time it's really great when a program you like adds an entry to your right-click explorer context menu, as in "zip the folder.." and 50% of the time it's super annoying, like when you have a hundred entries on their for programs you rarely use. By all means programs should support shell integration, but make it optional. |
| Registry Use | Don't do it. Or at least do it as little as possible. Programs should as a rule NOT use the windows registry to save their settings. We think the windows registry is in general a horrible thing, it makes backing up settings and moving programs from one computer to another agonizingly difficult. Use an .ini file in the application directory instead. |
See also Zaine Ridling's two excellent Top 10 Lists for software users and developers, which we agree with completely.