Application Maps and Frameworks
One of Luke W‘s live-tweets of the Web Applications Masters Tour caught my eye. The speaker, Hagan Rivers, described a technique called “application maps.” From Hagan’s original blog post on it:
When I look at an application I look for it’s hubs. The hubs are the work areas – the place where the user creates things and does things to them. In this application the main hub is the List of Addresses and Groups. From there the user can add an address, edit an address, add a group, export – a whole host of activities. In the end, though, he always returns to the hub when he’s done. In complex applications (one with hundreds of screens, for example) there may be dozens of hubs and their relationships may be complicated.
This description reminded me of my description of “frameworks” — a technique that I’ve been using as a more robust flow chart. A framework is less about how users get from point A to point B (a flow) and more about an application architecture that allows users to complete multiple tasks around a given set of objects (what Hagan might call the “work areas”).
I’d love to see more examples of these–evolutions of flow charts that provide both a sense of navigation (as in Hagan’s example) as well as task completion.
Here’s an excerpt of my draft with a description of frameworks:
Web sites are looking and behaving less like a sequence of pages and more like applications you’d find on your desktop. Through this maturity, we find that typical point-A-to-point-B flows are insufficient for representing the range of features in our web applications. The screens making up our web applications can support more than one scenario at a time. A framework, therefore, is a network of screens that permit users to accomplish multiple tasks, or one task within the context of many scenarios.
With this approach, your flow might look more like a site map–a set of connected screens. What makes it more flow-like, in my mind, is:
- It represents a change of state (eg: the transaction of a donation)
- It has a starting point and ending point, though the framework may capture multiple starting and ending points
- Its connections represent a progression through time, not through a hierarchy, taxonomy, or other series of categories.
The donation flow isn’t a good example for a framework. Though users may all have the same larger objective (helping the organization) the nuances in the flow are driven entirely by the user. Compare that to, for example, programming a DVR to record a television show. While users control many of the settings, there are several other variables that can affect how they accomplish the task:
- where and how they trigger the recording
- what else they have scheduled to record
- and the nature of the show they want to record
Figure 34: A framework doesn’t prescribe a particular starting point, or ending point necessarily, but there remains a sense of progression. The relationships between the nodes aren’t hierarchical in the sense of belonging. A screen that points to another screen isn’t a larger category as it might be in a site map.
Generalizing about this flow, processes that might lend themselves to a framework exhibit many of the same properties.
| Processes that lend themselves to a framework… | For example… |
|---|---|
| have multiple possible starting points for a single objective | When programming a DVR, users can initiate the process by browsing the show grid, conducting a search, or recording the show currently playing. |
| focus on a single objective but can have multiple outcomes within that objective | A “program” can mean a show scheduled to record once, a show scheduled to record in episodes, or record something right now. |
| have variable inputs to the application logic depending on the starting point | Hitting “record” while watching the currently playing show yields specific data points (where, when, and what to record). While starting on the search doesn’t provide as much information as a starting point for creating the program. |
| usually follow a hub-and-spoke model, where the application is structured around a central screen or set of screens | I’ve structured the experience around two main screens: the one describing the program and the one with the schedule of shows to record. There are a number of secondary and tertiary screens, but those two constitute the central structure. |
Telling the story with a framework can be complicated. You need to be able to show how the framework successfully supports all the possible scenarios. For most applications, this is impossible: no amount of research will be able to anticipate all the different situations the application will need to support. That said, research and stakeholder knowledge will be able to anticipate several crucial or frequent scenarios, and these are the ones you should show.
