Previous Table of Contents Next


5.2.4. An Example of Visual Prototyping

During the layout step it was determined that our example application needed a single tall, narrow window containing four views: candidates, sections, query, and data sheet. Based on the subtask flow within the scenarios, the “sections” and “query” views are the starting points, the “candidates” next, and the “data sheet” last. Since the catalog window is tall and narrow, the views would be approximately arranged top-down. Initial sketches suggested that arranging four views vertically will make them short so that they won’t be able to display very much content. Since the scenarios always begin with either the “sections” view or the “query” view but never both, they might be overlaid into the same space with a button added to switch between them.

The representation for three of the views, based on platform standards, was straightforward:

  Candidates — Collections of objects are usually represented either spatially, with large icons, or in a list, with small icons and additional information. The spatial view was chosen since there was no additional information to display and since users prefer large icons for both easy visual identification and drag-and-drop operation.
  Query — Query views typically consist of a type-in field, a “Find” button, and some option buttons for indicating additional query criteria if any.
  Data sheet — This view contains a text description. The background information included statements about the kinds of information that is important to selecting an appropriate component so a simple format was designed on that basis.
  Users — An added view that would show the components that used the selected component in their own implementations; an additional form of documentation. Another “collection of objects” view and again a spatial view was selected.

It was unclear how to best represent the “sections” view. One member of the development team thought that a “tab” view would be best while another suggested some sort of “web-browser” approach. The author thought that a multicolumn browser, typical for this platform, was the best representation based on the likelihood that there would be a large number of sections and the use of this kind of view elsewhere on the platform for similar tasks. Some members also questioned the idea of overlapping the query and section views although they agreed that it seemed logical.

The designer developed a layout for each alternative, four in all as shown in Figure 4.3. Layout “A” shows the tab-style “section” view and “D” shows the web-browser alternative. Layouts “B” and “C” are straightforward layouts based on appropriate platform-standard views and controls. “B” shows all four views while “C” overlays the “section” and “query” views. The views were laid out top-to-bottom based on the sequence of tasks in the user scenarios as described above with a couple of exceptions. Based on an earlier design by one of the developers, in layout “A” the data sheet opened in a separate window and the “users” and search results shared the same area. In layout “B” the query area was moved below “candidates” to save space and the “info” and “users” views were overlapped.

The prototype could be quickly switched to show the different views allowing for easy comparisons. Each layout supported the basic tasks of locating candidates by turning to a section or by query, selecting a candidate, and reading its data sheet. The prototype supported clicking on buttons and typing into the query field to simulate performing these actions although there were no real data behind the prototype.

The prototype took a few days to develop and was used for just a few minutes by each developer. It was clear that violating the top-down flow caused much confusion. Overlapping the “sections” and “query” views saved space and made it clear which was the source of candidates. Consensus was reached on layout “B” in those few minutes and the developers bought-in to the design, avoiding repeated questioning as the project progressed. Quick user studies could have also been run using the prototype, but in this unusual case the developers were members of the target user group. The artwork and interaction of the selected design were also reused in a subsequent visual prototype of the application editor.


Previous Table of Contents Next