Process |
|
Development Process
The development process for the PIE interface was composed of several stages. Following the initial decision to create an information and entertainment center for bedridden, hospitalized patients, the designers went through various design possibilities, both in terms of external appearance and internal design (i.e. code and code structure). Upon deciding on a method of implementation, the next steps were construction of a prototype and usability testing, followed by an analysis of those results and decisions for further change to the design and implementation of PIE.
The designers began the development process by analyzing, as a group, the needs of the interface. This in itself had two steps, the first being an analysis of what potential users would desire in such an interface, and the second being an analysis of the interface design itself. After careful consideration, it was decided that the focus would be on long-term patients who are in good enough medical condition to use any sort of remote which is decided upon for the interface. These patients include (but are not limited to) patients recovering from a serious illness or injury, patients receiving therapy (such as chemo therapy), or patients recovering from a surgery. Upon reaching this decision, the designers set a goal for what the system was to accomplish: to keep these bedridden patients informed and entertained.
The designers further analyzed what the system would be expected to do through several case studies. Sample scenarios of potential users were created and what that user would desire of the system was determined.
Case studies used include:
These studies aided particularly in helping to determine what further requirements the system would have.
The designers needed to consider requirements for the actual interface design. After reading studies on similar operating systems, the designers decided to include the following eight features in the interface, separated into two categories, information and entertainment. The information section was to be comprised of Doctors’ Orders, Medication, Room Controls, and a Walkthrough. The entertainment section included Games, Movies, Music, and Internet. Specific interaction requirements which were decided upon included: visibility from 10 feet away on a small (12 inch) monitor, ease of use when given a remote limited to only a few buttons, the number of buttons such a remote would require, the difficulty in implementing the system graphically, and how well the designs conform to the Eight Golden Rules of interface design (Shneiderman, p. 74-75).
A wireless remote and/or keyboard was decided upon due to the fact that cords not only have maximum ranges on how far they can stretch, but it would be quite easy for them to become tangled in any number of other wires or tubes near to the patient’s bed. Headphones was an additional hardware possibility so that one patient’s noise from video or music would not disturb others in the same room. Similar technology can be found in systems such as Skylight.
The next stage was consideration of various designs of final products. Some options which were analyzed were tabbed screens (a user would be able to select a tab at any point to transfer themselves to a different screen, all the while saving the condition of each other screen), a DVD-style interface (all categories available from the main menu, but upon selecting a category, a user must go back before changing), an actual pie menu (the user could select each screen from a wheel-type interface), and a sliding bar interface (similar to the tabbed interface in that all screens are selectable from any other, but instead they would be selectable from length-wise bars on the sides of the page). The choices were narrowed down to either the tabbed screens or the DVD-style interface, and broke into teams of two to create low-fidelity designs of each.
The first design presented in the report is the tabbed design. The designers made only a hand-drawn copy of the main screen and the tabs (Figure 1). The main screen for this PIE interface consists of 8 options for the current user to choose from. The user would already be logged into the system by the nurse or doctor prior to their arrival and stay in the room, and the remote for browsing through the system waits on or near their bed.
The remote control would have the eight possible options from which the patient can choose, a joystick, an "enter"/"select" button next to the joystick, and four arrow keys (i.e. up, down, left and right). Whenever the user selects one of the eight options on the remote, that option is highlighted on the screen by inverting the colors of that button and bringing the selected option to the center of the screen. Despite the screen being changed, the states of all the tabs are stored so that a user does not lose information by switching from one to the next. Throughout the entire browsing process, the border (with all the different selections such as games, music, doctors’ notes, etc.) stays on the screen, and the only changes are the heading and what appears in-between the frames. This border can be seen in Figure 1.
The text size would be large enough to be legible on our screen size, but it is not necessary that it be too big because the remote will also be labeled with all the selections available on the main screen. The colors would be warm and friendly, accompanied by pictures that promote this sense as well (such as blue buttons and white backgrounds with semi-transparent background pictures).
Figure 1 - Main interface for the first (tabbed) design.
Examples of the Internet and Room Controls sub-screen designs for the tabbed design can be seen below in Figures 2 and 3.
Figure 2 - Prototype design of the Internet page for the tabbed design.
Figure 3 - Design of Room Controls screen for the tabbed design.
The second design is the DVD-style one. The main page (Figure 4) would be accessible through the use of back buttons on each of the sub-screens, examples of which can be seen in Figures 5, 6, and 7. Users would have access to a seven button remote: four arrow keys for navigation, a selection key for selecting an event, a button for returning to the main menu from any screen, and a help button for accessing the help features at any time. The title bar at the top of the page would change depending on which menu the user had selected.
Figure 4 - Main screen for the second (DVD-style) design.
Figure 5 - Prototype of Games screen for second design style.
Figure 6 - Room Controls screen for second design.
Figure 7 - Doctor's Orders screen for second design. Upon completion of these preliminary, low-fidelity prototypes, the designers needed to decide on which to choose. This involved a detailed analysis of the benefits and costs of both interfaces, detailed below. These advantage/disadvantage relations considered such aspects as hardware and software requirements of the end machines, potential coding interface (i.e. Java, Flash, JavaScript, etc.), difficulty for patient use, and difficulty to draw graphically.
The tabbed interface would require at least 13 keys for access to the various features of the system. What the designers did not consider, though, was the scenario that users would not perhaps press the keys for each menu straight from the remote, but would prefer selecting each choice with arrow keys. The tabbed interface does not allow for that in a simple method, as the keys would be expected to be necessary for interaction with the various sub-screens.
The DVD-style interface, on the other hand, seemed to have a minimum of six keys and none of the issues with selection between the interface menu and the information on each sub-screen. The only exception to this would be scrolling menus, and how to move from the scrolling menu with the arrow keys to the buttons for help and backing up to the previous screen. The DVD-style interface would clearly have a simpler controller, which, if the designers were to actually produce this system, would have a lower cost. In addition, a simpler controller means that the user can more easily navigate, and the system can appeal more to those not technically savvy.
An additional item which both interfaces seemed like they might require would be an actual keyboard. This is due to the idea of having sub-screens for Internet surfing and possibly chatting with nurses and/or other patients. The designers decided that it would make more sense to have two separate means of interfacing, the keyboard and the remote. The keyboard would only need to be used in those cases of browsing or chatting. Furthermore, both interfaces would require a television screen, a computer, a video cable for connecting the computer to the television, a remote as described above, and a microphone for recording voices or speaking in to.
The next consideration is the software requirements on the end machines. The designers decided that none of the technology used in the project should be particularly high-end or graphics intensive, both due to the lower machine prerequisites and the difficult in implementation. It was determined that the machines that PIE would be used on should have basic software capabilities (i.e. Flash, Java, etc., depending on the language of implementation), a speaker system for playing back movies and/or music, ethernet support, and possibly a voice recording for features like doctors’ orders.
The designers proceeded to consider what language(s) the interface would be coded in, and which would support the most features. The desired language would be one which was easy to use and easy to create graphic images, while at the same time providing access to a plethora of features so that P.I.E. could be coded as the designers intended it to be. Various programming languages were considered, and advantages and disadvantages of each were weighed. Languages and implementation styles under consideration included Flash, Java, Ajax, Web 2.0 technologies, and JavaScript.
Language choice was narrowed down to Flash and Java relatively easily due to the experience of the group as a whole, but beyond that point, the options were carefully weighed. Flash provided an easy to use method of graphical manipulation and the entire group had about the same skill level in its use. The language itself was relatively easy to learn, but it lacked adequate documentation and past experience showed that it did not always react the way it was expected to. In addition, sources revealed that Flash could not, at the current time, provide an integrated web browsing interface.
Java, on the other hand, provides built in methods of creating the entire interface, including web browsing. The main difficulty with Java, though, was that the designers did not want to deal with the more complex methods of graphical creation in the Java programming language (i.e. coordinate plotting).
The end decision was to use Flash. Although Java provides more of the features the designers wished to implement, the Flash environment was more conducive to a completely graphical interface, especially one which included a very limited amount of actual algorithm programming as opposed to locate and orientation of graphics. The designers decided to create screen shots of parts of the interface which could not or would not be coded in the preliminary version of the interface (i.e. internet, chatting).
At this juncture, the designers had a clear picture of the interface which was desired, as well as what language to code in and what features to make accessibly to the end users. The next step in the completion of P.I.E. was the actual building of the project. The team met to determine the general layout for each page and then split off to each create two pages given the guidelines that were decided upon. Coding tasks were delegated, as well as the graphical interfaces. Within a few days, the designers had put together the pieces for the product.
Bringing it all together followed the creation of the individual pieces, and although the designers had guidelines for the pages, the interfaces were not all completely alike, nor were the programming methods behind each page. Working as a team once more, the designers created the high-fidelity prototype. The next part of the process was usability testing.
The designers needed to determine who their users would need to role-play as, what questions to ask them, and what method of evaluating answers to those questions would be used. In addition, concerns such as privacy and consent to testing would need to be addressed for each user. The designers required each of the subjects to sign a paper stating that each person had freely volunteered for the experiment, knew what tasks would need to be completed, and were aware that withdrawal at any time was allowed.
An introduction to the experiment was created for each of the subjects to read through in order to provide an overview of the goals of the system and what each subject would be required to do. This also aided the subject in getting into the proper mindset as a patient so that the interface could be more easily evaluated as if the environment was where the final product would be located. Unfortunately, the designers did not have access to actual hospital patients, so, in their place, acquaintances took on the desired roles.
The subjects were first asked to answer a set of five questions concerning themselves so that the experimenters could have a better feel for what background each user had. The first question was gender. This was asked to determine if males or females had an easier time operating the system. It is common knowledge that males and females have differences in their thought processes, and it was important for the designers to keep track of any variables which would affect the results. The second question was age. This is important because the younger generation is more computer literate, in general, than the older generation. If the interface designed was confusing to the older generation but not confusing to those younger, then it was poorly designed and would require reworking.
The third question was how many hours per day the subject uses a computer. This is important because although age has a large factor in computer literacy and experience, how much the subject uses a computer is even more relevant. The next question concerned any color blindness the subject may have. This is extremely important in any sort of graphical interface due to the fact that in order to be visually appealing, certain color combinations were used. In addition, other combinations were used to highlight selected text or the like. Should a user not be able to view these as the designers intended, it would be advantageous to gain their insight as to what colors would make the interface more visually effective. The final question was whether or not the subject had experience with video systems such as Tivo, a DVR, or Media Center PCs. This is again a means of determining how experienced the user is with modern technology, especially because the interface the designers created was similar to those found in DVD menus.
Several tasks were decided upon to give to the users to complete. Following these tasks, the user was to answer a series of questions in an effort for the experimenters to gain insight into where improvements could be made and how easy the interface was to use. The tasks given to the subjects can be seen below. The users were instructed to complete these tasks using only six keys, as if using the remote (i.e. not the whole keyboard that the testing was done on due to a lack of a hardware prototype).
Tasks:
· Both listen to, and read your doctor(s) recommendations in order to hasten the healing process. · You’re bored and don’t want to think much. Find a cool action movie to watch, then fast forward to the action scene. Once you’re done, exit the movie. · Your doctor just prescribed to you some new medications; find out what these new meds do and what effect they have on your body. · You have a question about your condition. Save the doctor some time, and read about your condition using the PIE system! · Your pillow smells like chicken soup; call a nurse and ask her for a new pillow. · You’re in the mood to play some good old-fashioned arcade games. Try to beat Roger’s high score!
The tasks were decided upon as a means of analyzing many parts of the interface and allowing the subjects to view and interact with many different options. The designers wished to determine any flaws in the fully implemented parts of the system so that those could be addressed efficiently and accurately. In order to gain the information required to determine improvements to the prototype, the designers had a series of questions which the subjects were asked to answer following the testing. These questions (below) were designed to allow the subject to provide feedback to the testers in a meaningful fashion.
Post-test questions:
· Was there any confusion in determining what menu choices to make to access the desired feature? Please list any questions which arose. · Please describe, on a scale of 1 to 9, the effectiveness of the color contrast used on the page visited. (Use 1 as highly effective and pleasing to the eye, and 9 as incredibly difficult to focus on). Please describe any issues you had with the color display. · On a scale of 1 to 9, 1 being simple and 9 being near impossible, how easy was it to access the desired feature after the correct menu was selected? Was it clear what needed to be selected? · On a scale of 1 to 9, 1 being very readable and 9 being illegible, how readable was the text (considering the t.v. screen is small and a fair distance away)? · On a scale of 1 to 9, 1 being intuitive and 9 being confusing, how effective where the icons for the menu system? · On a scale of 1 to 9, 1 being extremely easy and 9 being extremely difficult, how easy was it to use the remote/keyboard to navigate around in the menu system? List any issues you had, if any. · Which feature did you enjoy most? What feature do you think should be expounded upon more and how so?
Other suggestions included:
· Implement some music device · Implement index search for diseases · Implement help for each screen (text and voiceover) · Have play button for Dr. Orders screen · More games · Show some kind of reaction on room controls screen (make interactive). · Perhaps show some possible play/fast forward buttons while video is playing · Make "call nurse" visible on front screen (where back usually is). Show indication that nurse is called. · Make a way to quit the walkthrough. · For the walkthrough, go through most if not all of the screens showing the functionality of PIE Following the completion of the usability testing phase, the designers reconvened to discuss the results and determine future additions and improvements to the interface in the following versions. |
|
University of Maryland (College Park) |