Making Applications Easier To Use
Applications have an almost universal tendency to get more complex with succeeding updates. More often than not, this creates confusion and generates some anger among users, read customers – not everyone wants change for its own sake, particularly when improvements, so-called, are perceived as imaginary at best.
Some software developers have recognized this problem and striven to do something about it, which is not an easy task: One user’s (customer’s) feature-set is another user’s (customer’s) annoyance. Nick Bradury, creator of Homesite and FeedDemon, is often trying to make his products easier to use, and takes the time to describe some the challenges and how he addresses them. His posting, The Great ToolButton Slaughter, takes a close look at the Windows toolbar and how he manages it.
The toolbar as a control common to all, or at least most, of an application’s forms goes back a long way, and has many imagined and perceived claims of priority. As used by Microsoft and its early User Interface guidelines (e.g., Everett McKay’s work for Microsoft Press) the toolbar became somewhat unwieldy as each function had its own toolbar button, resulting in very large toolbars or, worse, multiple floating toolbars. More maddening to users (customers), toolbar button positions always changed with updates, forcing the user (customer) into a new learning curve with every release.
One attempted solution to the growth of horizontal toolbar buttons was the vertical Outlook-like layout, which wasn’t a really effective solution. The loss of screen real estate generally wasn’t perceived by users (customers) as worth the relatively small cost in occasionally having to scroll below the fold.
Also tried, and found wanting, was the ‘adaptive’ approach for both toolbars and menu items, most noticeable in MS Office products. These would ‘learn’ the users’ (customers’) choices and prioritize them as usage patterns are detected programmatically. There are ways to configure these to fix the choices are streamline the ‘learning’ algorithm, but most users (customers) merely want to get on with their jobs and activities, and don’t have the time, interest or appreciation in having to learn ways around the obstacles that programmers’ added that make their lives more complicated. The best (or, perhaps more accurately, worst) example of this was cited by Peter Huber in Forbes Magazine, when he called Office2007 Blunder 2007.
Again, toolbars, and their menu list companions, are difficult to manage or present in a way to will satisfy most users (customers). It may well be impossible to attempt to do so as applications take on increasing functionality. One of the possible reasons for this is the tool(s) used to develop and maintain applications: It often isn’t necessary to have a one-to-one mapping of functionality to toolbar button or menu list item, but the tool may not allow such control out of the box. Extra work means extra time for development, extra testing, extra resources, extra costs, all calculable luxuries to public companies that have to continually show quarterly growth in sales and profits.
FutureWare uses toolbars and linked menu lists in all of its Window’s based desktop/laptop applications, but we have worked to manage them by focusing on limiting the number of keystrokes it takes to accomplish a given action.
To begin with, all of our applications are very simple, focusing on one, or a small set of highly related, tasks. We use a relatively small number of large toolbar buttons, whose captions are arranged left to right alphabetically, with their icons, captions and actions mirrored by menu item lists. We also work to make the use of toolbar buttons align with a particular user (customers) workflow, so the buttons’ captions, icons and actions are changed depending on where in a workflow sequence the user (customers) is. We also add a number of training features, like first-use wizards, rich context-based Help subsystems, and short to the point movies on our website made with Camtasia, making sure that user (customer) questions are answered in a timely manner and with a movie added to our website when something come up that isn’t covered in reasonable detail.
Finally, we make sure that our automatic updates do not, repeat not, change the order of toolbar buttons and menu list items.
Managing toolbar buttons and menu lists is trivially easy with Delphi, our programming language of choice for Windows desktop/laptop applications. We use Delphi not for religious reasons, but because we can generate reliable and easily extensible software products in a fraction of the time as can be done with, say, VB or C#, a fact repeatedly supported by metrics and performance challenges over a considerable period of time. And we’ll continue using Delphi for these kinds of applications until something demonstrably faster and better comes along. We’re pretty certain that perhaps all but a handful of users (customers) wouldn’t care if we made our software out of spaghetti, so long as it does what they want, first time and every time out of the box.
Tags: ease of use, software, toolbars