Flex Article

Designing for Flex – Part 3: Structuring your application

Designing creation structures

Employ creation structures when your users’ goals involve being creative—making entirely new content or making extensive changes to content used as a starting point. They are most useful when your users’ goals call for free-form sequences that combine the functions of your application in ways you cannot fully predict. Creation structures allow experienced users a great deal of power and control, but they do so with some sacrifice in approachability for more casual users.

Always consider your own application’s domain and user goals when deciding which structures to employ. However, keep in mind that most people don’t use most of their applications regularly. Think of your own work; chances are you use a small handful of applications on a daily basis, but use of a much wider range of desktop and web applications weekly, monthly, or even more rarely. For this reason, it is often unwise to choose a creation structure as the organizing principle of your application. Consider using creation structures for smaller, more limited subtasks where they can be made simpler and easier to grasp even for casual users. Or don’t use them at all; As I mentioned earlier in the photo editor example, many creation structures should be replaced with process structures when designing for casual users with more predictable tasks.

When designing creation structures, ensure that your users’ content takes center stage. Allocate the most screen real estate to the creation surface. Place controls (such as toolbar buttons) off to the side or display them only when users need them. This is more difficult to achieve than with an information structure since the number and variety of functions available at any one time will be much greater. Eliminate complex, control-heavy dialog boxes through direct manipulation techniques and carefully prioritize the editing functions you provide; many creation applications make the mistake of offering more functionality than the majority of their users need, to the detriment of the overall user experience.

Figure 6. Picnik is primarily creation-structured, yet it simplifies the photo editing task by keeping functionality to the essentials and providing options in context rather than requiring users to hunt for them in dialog boxes.

If the creation structure in your application reaches a sufficient level of complexity, provide extensive task-oriented documentation to help users understand how to achieve their tasks within the tool. Make this documentation easily accessible from the application itself through prominent help search and contextual help buttons. Design this documentation not to be read cover-to-cover, but to be accessed in small chunks—to quickly answer users’ questions when they get stuck so that they can easily get up and running again. Never use the documentation as a crutch for bad design; almost all users are highly documentation-averse and they should require it as little as possible.

Figure 7. The help system for Adobe Fireworks is written in a primarily task-oriented fashion. Instead of describing features such as “filters” as tools disconnected from user workflows, it discusses what the user is likely to want to do with filters, such as applying them to graphics, adjusting the color and tone of bitmaps, and creating custom filters.

Page 5 of 8

Previous Page

Next Page