Previous Table of Contents Next


1.2. BROAD CONTEXT OF THE BRIDGE

The Bridge for fundamental GUI designing is itself one methodology in a complete start-to-finish approach to taking a GUI project from proposal creation through checking the implementation against the user requirements document. The major methodologies in that approach are listed below, with the Bridge methodology italicized.

  Proposal Creating
  Project Planning
  Detailed Customer Requirements Creating
  Fundamental GUI Designing“The Bridge”
  Part 1: Expressing User Requirements as Task Flows
  Part 2: Mapping Task Flows to Task Objects
  Part 3: Mapping Task Objects to GUI Objects
  Detailed GUI Designing
  Formal User Requirements Document Writing
  Conformance Checking of the Implemented GUI Against the User Requirements Document

The Bridge does not require use of any of those other methodologies because The Bridge is only one component of any start-to-finish software development process. For instance, writing a detailed, formal user-requirements document happens after The Bridge, if at all. Such a document that dictates the developers’ coding is the best way to get efficient coding, traceability, maintainability, and extensibility. However, The Bridge will successfully output an excellent GUI design and paper prototype even if the project as a whole fails to quickly produce a corresponding formal requirements document or software product.

The Bridge can be used with great effect even if the system requirements are already written. Of course, The Bridge should be done before the system requirements are decided, since Bridge sessions always address the software product’s deep functionality in addition to its GUI look and feel. For example, the underlying database and the contracts between the GUI and that underlying system should be designed to quickly return all the data that will appear in the same GUI window. You don’t want half of the data in the window to appear instantly and the rest 5 minutes later! However, if the system requirements and underlying system code have already been set, The Bridge is still very useful. In this example, the system engineer and developer participating in the Bridge session would warn the team as soon as those fast- and slow-returning data were hand drawn into the same paper window. The team would then immediately redesign and reprototype so that the different data were displayed separately, such as in different views, different notebook pages, or different Include settings. All of those activities would happen within minutes, inthe same Bridge session, without any resources being wasted in writing up or coding the poor design.

The above is an illustration that The Bridge is not the type of user-centered design process that just records whatever users say they want. Instead, The Bridge’s resulting design realistically can be developed, with usability compromised as needed to get the GUI delivered on time. The Bridge has an advantage over many competing approaches, in its provision of excellent support for making those tradeoffs rationally and with minimum expenditure of resources on infeasible or poorly usable designs. Not just users are present in the session; various management camps are represented in the persons of the usability engineer, developer, system engineer, and perhaps others. Those participants are selected partly for their knowledge of management perspectives and for their power to represent management in making at least rough commitments.

Another important support for management is that not all decisions need be made finally during The Bridge session. The session outputs priorities on portions of the task flows, on portions of the GUI, and on the issues that are documented during the session. There is even a Blue Sky version of the task flows that is acknowledged by everyone to be infeasible, but that is publicly documented as an ideal goal of the project. All this information guides the development team during the months or years after the session, as the teams adjusts the design to suit the unfolding practical realities of the software development project.

This chapter does not explain any of the methodologies in the above list other than The Bridge. Before we delve into details of The Bridge, here is a brief overview of its three major, explicit steps.


Previous Table of Contents Next