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 wont 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:
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 |