This page discusses the use of the web as an implementation environment that supports linked design rationale. We provided students with (1) a prototype application (an online course regisration system), and (2) the design rationale that lead to the prototype. In this way, each application page included both the functions of the application (e.g., find a course, add a course) and links to the requirements engineering and design steps that lead to that page (e.g., a client/student discussing what her needs were in regards to searching, a design compromise made to resolve conflicting requirements).
Below is one piece of the prototype. Note the rationale links (represented as diamonds within a box) embedded in the working prototype. There are three links in this figure, with the first one highlighted.
The figures below show the result of clicking on the rationale link highlighted in the previous figure, i.e., the link attached to "Your Current Schedule". We will go through each figure separately.
The design rationale is structured using the Issue/Position/Argument (IPA) style. Issues are design questions. Positions are alternative answers to the question. Arguments add supporting information to positions. On this page, the issue is whether the student needs a course planner in the online system. In other words, should the planner from the hardcopy schedule of classes be carried over to the online version? In the figure below, one can see the format we have chosen for IPA: The issue is stated at the top of the page; A summary is provided to give a synopsis of what follows; Each position is stated (here the "yes" position is given first and a note that it was the position eventually chosen as the design decision); Supporting arguments are mustered for that position. In the case for the "yes" position, we include interviews with clients (students) who supported the position plus contextual information, e.g., documents that reflect the current way the process is handled manually. One can argue that the manual process is important to automation if disruption to the client's mode of operation is to be minimized.
The next figure looks further down the page. The interview with the client has been edited (using Adobe Priemere) into smaller clips. Text transcripts have also been made, as well as audio only clips. Finally, supporting material for the "yes" position is given.
The next figure shows a piece of the text transcript with a link back to a corresponding video clip. We have found this type of "transcript indexing" into a large body of video material to be quite effective.
The last figure shows the two clients who show little interest in an online planner (they have little need for a planner given their courses are fixed and hence have little flexibility in their schedules).
At the bottom of the page is the final design decision which was taken: to include a simple online planner. This is a compromise between the elaborate planner the undergrad client wanted and the lack of interest by the graduate student clients. The video, audio and text transcripts can be used to look in more detail at the arguments put forth by all the clients.
