Jeff Chapman

The Art in Business System Design


Скачать книгу

vendor, but then once you select them you will be making a major commitment in your vocation to the effort of using that tool. Perhaps it is precisely due to the difficulty of this decision that developers turn into pundits. If you wish to be continually marketable though it’s smarter to stay flexible and multilingual. A software language is a sophisticated tool: respect its art but be cosmopolitan.

      Interface Design

      Whether you use interface design as the engine to drive your software development or whether you consider it a necessary evil to providing functionality to the folks signing your paycheck, one way or another you will become enmeshed with the challenge of placing fields and designing navigation into some sort of visual interface.

      This turns out to be the ultimate smackdown between aesthetics, culture, science, psychology, and your software tools.

      In this chapter I provide a handful of varying approaches to this task. Absorb and understand each one fully, but for creating truly elegant and intuitive interfaces that work well you really need to internalize these separate learnings and implement them in parallel.

      Artistic Menu Arranging

      In the windows-form world menu layouts are pretty settled, but no standard has emerged yet in the web-form world. In a windows form try to keep your menus parallel to how Microsoft has laid out theirs: always a File menu at the farthest left and a Help menu farthest right.

      Partition out items of similar function with horizontal separator lines and be sure to enable hot-key shortcuts to the commonly used items. A single item alone looks wrong isolated between two separators. Limit menus to eight or so items in any dimension (per pulldown or across). Pop-outs shouldn’t be more than two deep, although I usually require a fairly serious reason for any pop-out after the first one.

      Interfaces on web forms are tending toward an artificial “tabbed” approach. This works reasonably well provided you remain consistent with fonts, vertical spacing, and presentation layout. Exceeding three levels of tabs looks ridiculous, as if you were a multilayered teenager with stockings, leg warmers, coolots, a skirt, blouse, vest, jacket, and a scarf. At that point it’s better just to partition off master pages into separate functional groupings. If you use horizontal and vertical menus on the same page the fashion police will arrest you; use a consistent menuing approach throughout your entire application.

      Laying out menus is an art all its own. It’s rather like dressing professionally: take the time to do it right and your menus should look good, clean, intuitive, and stay in the background.

      Artistic Sparsity

      Even though we know it in our hearts, we still fail to account for how a software system grows and becomes more complex over time. Designing interface screens is a lot like planning an informal garden; if you want it to look great once all the plants take hold and fill out you need to think a bit about the future. Instead folks tend to wireframe a product that looks “complete” with reasonable use of the menu real-estate and a felicitous spread of field-density on the screen at the initial planting, as if the product is somehow “finished” once you implement it.

      In doing this we make things look good in the /present/, yet we fail to account for system growth. When we later add significant new functionality… surprise, our screens and menus appear too overgrown and cluttered. It’s as if you planted all the apple trees two yards apart because it looked better; now that they have branched and fruited they are all atop on another.

      Therefore when you are creating a new system plan for expansion by deliberately under-designing menus and occupancy: make the interface artistically sparse. And then don’t worry about it; like a garden your interface will “fill out” as it matures.

      The Art of the Form

      Let’s face it: programs run on data. Your software will either receive a direct supply of this data from another machine or it will be interacting with human beings. Most business programs must ultimately, however, gather input from folks who enter vast quantities of customer-related data by typing on a keyboard into an on-screen form. Hence one key to successful software design is mastering how to develop effective data entry forms.

      Since humans are highly evolved toward visual processing and semiotic signaling, designing a quality form is as challenging as a fashion model who tries to impress a critic: you must attend to placing every detail as the smallest lapses from perfection stand out starkly. We notice if your borders are too wide or your color choices are too pale.

      Organize your forms into logical pieces so that they present related fields to the relevant subgroup of employees with the authority to update them. Required fields should have default values; group commonly-entered fields together near the high-touch areas of the form. Think of organizing your form like you would organize a restaurant menu: appetizers, desserts, drinks.

      Users prefer consistent hand actions that keep the fingers fixed over the home keys. Too much clicking about with a mouse for reading and selecting of pulldown menus is an annoyance for high volume data entry.

      Either the tab or the enter key should advance between fields in a consistent and logical manner. Indicate errors as close as possible to the source field (physically and temporally) with both a visual cue and a subtle audible signal.

      Quality forms take a fair amount of effort to develop; failure to pay attention to all of the small details shows considerable discourtesy to your users. By paying attention to this handful of guidelines you may create forms that are intuitive, promote quality data, are easy to learn, are simple to use, and are haute couture.

      The Art in Courtesy

      A typical Windows form has multiple small visual cues that you can leverage to provide the ultimate courtesy to your client. When you are traveling to a new city on a train as a tourist you expect (and the railway provides) a significant amount of common courtesy to make your traveling to the strange land less stressful and more enjoyable. Every new or intermittent user of your software is like one of these tourists and so you should extend them the same courtesies.

      Begin by considering the lowly mouse-pointer icon. You should change this to different icons under numerous circumstances to signal processing conditions. Always change the pointer to an hourglass if your process is running a thread that disables user input. Change it to a question mark when they hover over a label and then provide help about the field when they click on that label. When a user hovers over a field they may be confused about what to enter. You may pop up a short callout of information or a help-button icon that will display a sub form. So now you’ve got your traveler’s help kiosk all built and wired.

      Use the status area strip at the base of a form to show messages about the internal tasks you are performing. Provide a bit of message detail to assist you in debugging a client’s problem during operation. When you expect the user to enter data in a specific format overlay a graphic example (mm/dd/yy).

      Make the effort to disable buttons, checkboxes, menu items, and fields when they are logically unavailable. If a form requires the user to enter fields before he presses the submit key then that button should not enable until all the required fields have been entered. Always behave in a manner to prevent mistakes proactively.

      Indicate required fields in a manner that is both clear and consistent yet discreet. Take advantage of a changeable title bar: it can show both variable words and an icon and these also display when your application is minimized. So now you have all of the railway’s interactive signage built.

      A mouse usually has two buttons… take advantage of this by providing right-click context menus where appropriate. Finally on any operation that requires extensive processing time, display a progress bar showing the estimated time to completion. Run the long task in a background thread so that the user interface can still be moved or minimized. And remember to provide a button to cancel any long-running operation! So that creates the ever helpful train conductor.

      Correctly handling all the small visual