Patient Information and Entertainment (P.I.E.)
Jonathan Gasca
Mike Ball
Roger Kar
Aaron Hopp
jongasca@hotmail.com
mball3@umd.edu
darwyn@wam.umd.edu
ahopp@wam.umd.edu
November 28, 2005
1
Table of Contents
1. Introduction .................................................................................... 3
a. Abstract................................................................................ 3
b. Credits.................................................................................. 3
c. Intro...................................................................................... 4
d. Discussion of Previous Work............................................... 5
i. Commercial Systems................................................ 5.
ii. Academic Papers...................................................... 6
iii. Other Websites......................................................... 6
2. Presentation of Design..................................................................... 9
a. The Users............................................................................. 9
b. System Interaction............................................................... 9
c. Prototype Screenshots.......................................................... 11
i. Main Screen............................................................. 11
ii. Games...................................................................... 12
iii. Music....................................................................... 13
iv. Internet..................................................................... 14
v. Movies..................................................................... 15
vi. Dr.’s Orders............................................................. 16
vii. Medical Condition/Information............................... 17
viii. Room Controls......................................................... 18
ix. Walkthrough............................................................ 19
3. Report on Development Process...................................................... 20
a. Usability Testing.................................................................. 28
4. Conclusions...................................................................................... 31
a. Current Status....................................................................... 31
b. Future Improvements............................................................ 31
c. Acknowledgements............................................................... 31
d. References............................................................................. 32
2
Abstract
It is not rare that people have to stay in hospitals for long periods of time. Sadly, patients
do not like being stuck in hospitals because they complain that their hospital is boring
and sometimes smell bad. The truth is that hospitals will probably never be perfect, but
they can be improved to provide more entertainment and information for patients while
the patients do have to stay there. That was the idea behind the P.I.E. (Patient Information
and Entertainment) interface. It is a software program developed to enhance the quality of
a long term patients stay in a hospital. It does so by providing patients with information
and entertainment (thus the name).
Credits
Jonathan






Proposal write-up
Introduction and abstract (user needs and design report)
System requirements (user needs)
¼ References + reformatting
¼ User tests
Music, Doctors orders, and Medication screens of P.I.E. prototype.






½ DVD style prototype (low fidelity prototype)
2 case studies (user needs and design report)
Setup and General Results (Usability Test Results)
¼ References
¼ User tests
Games, Internet, and Room Control screens of P.I.E. prototype





½ Side-Menu style prototype (low fidelity prototype)
¼ References
¼ User tests
Movie and Main menu screens of P.I.E. prototype
Report of Development Processes







½ DVD style prototype (low fidelity prototype)
2 case studies (user needs and design report)
¼ References
¼ User tests
Walkthrough screen of P.I.E. prototype
Transitions for P.I.E. prototype
Roger
Aaron
Mike
3
*Each team member contributed equally to this projects development and documentation.
Introduction
When you think of staying in a hospital over a long period of time, what are the images
that come to mind? Perhaps it’s the busy hospital halls, white bed sheets, or colorful
curtains. If not, then maybe it’s the beeping blinking machinery that is strewn and
wheeled all over the hospital. Maybe it’s a combination of these things, but regardless of
exactly what images come to mind, they are probably not images that bring you immense
joy or comfort; in fact they probably make you a little depressed.
The P.I.E. (Patient Information and Entertainment) system will seek to change that.
Although we realize that a hospital stay will probably never be as comforting or luxurious
as a stay in a 5 star hotel, or a Caribbean cruise, the P.I.E. system will seek to make a
hospital stay more pleasant. Specifically speaking the P.I.E. system will seek to make a
long-term patients stay in a hospital, more informative and entertaining by providing
features that would cater to that patients desires.
Although the P.I.E. system could have a variety of benefits to any hospital patient, we
have chosen to focus on long term patients. These patients are ones who are in good
enough medical condition to use a remote and/or wireless keyboard to browse an
interface containing multiple information and entertainment options, but who may not be
well enough to get up and walk around. 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.
The main goal of our system is to keep these patients informed and entertained. P.I.E.
will accomplish this through a variety of options available to these users. Although there
are thousands of possible features we could implement we have chosen to focus on those
features that the patients would find either entertaining or informative and those that are
feasible while sitting and seeing a screen far away. These features include the ability for
the user to browse doctors’ orders, see information on their particular disease/condition,
and/or message a nurse with a question they may have. Entertainment features of the
system include games and music. In addition the system will allow users to adjust their
meal schedules and/or room temperature. These features are explained in more detail
below.
4
Our team utilized a variety of existing tools similar to the one we wanted to create, in
order to stir fresh ideas and also to borrow useful features that already exists in some of
these prototypes (listed under commercial systems below). In addition, our team
researched (by means of various academic papers) the usefulness of a system such as the
patient interface we wished to create. As a result we were able to better focus our project
scope and determine which features may/may not prove helpful. Overall, we found that
the combination of information and entertainment right at the patient’s fingertips was a
powerful combination indeed, and could prove very useful to a long-term hospital patient.
Below is a list of the existing work and research already done regarding user (and
specifically, patient) interfaces.
Commercial systems
Title: “Patient Power entertainment units”
Publisher and Date: BHR Hospitals 2005
Site: http://www.bhrhospitals.nhs.uk/hospital/patientpower.jsp
This is a brief article about a chain of British hospitals, BHR Trust, and their installation
of entertainment units for all their patients. Using entertainment systems from
Wandsworth Group, each patient will be able to watch TV, receive a talking books
channel, listen to hospital radio, and have internet access. Upon testing their system they
reported, “It was obvious from the feedback received from both nursing staff and patients,
that the entertainment systems enhanced the patient environment and patient stay while in
the hospital.” This motivated us to push forward and make an even more useful tool.
Title: Skylight Healthcare Systems
Publisher and Date: Skylight Healthcare System, Inc. 2004
Site: http://www.skylight.com/
This is the homepage for Skylight Healthcare Systems, Inc. They have developed a
product called ACCESS, an Interactive Patient System. What they have developed
incorporates many similar ideas to what we are planning on doing, including media and
communication technology.
Title: Patientline
Publisher and Date: Patientline UK Ltd 2005
Site: http://www.patientline.co.uk/
This is another patient entertainment system which allows patients to listen to the radio,
watch TV, and make phone calls all while laying in bed. Although the idea is good, our
project scope hopes to be larger. Although a phone may prove useful, most people
already have cell phones, and the idea of radio/TV is helpful, but should only be
considered starting points. What this interface lacks, and which we choose to include is
information that could prove useful for the patient, as well as interactive entertainment
such as arcade games or trivia.
Title: “Interactive Hospital Systems: The Hospital Network”
Publisher and Date: HCORP Inc 2003
5
Site: http://www.hcorp.com/products/Products.htm
Yet another entertainment system for patients, but what makes this one different is that it
includes both information and entertainment. This product gave us an idea of the broad
variety of features we could include, such as a radio pillow, satellite TV, or satellite radio
to name a few. It also encouraged our idea of including pertinent patient information as
well as entertainment.
Academic Papers
Title: “Inclusive design of an interface for a hospital system for information,
communication and entertainment.”
Publisher and date: Disability, Virtual Reality & Assoc. Tech., 2002
Author: R McCrindle, F Arnold, G Cook, J Barrett and D Booy
Site:
http://scholar.google.com/url?sa=U&q=http://www.cyber.rdg.ac.uk/ISRG/icdvrat/2002/p
apers/2002_19.pdf
This is a paper about features that a hospital system can offer which would be usable to
people of all ages, computer experience, native language, etc. It discusses design needs
and the like and is quite applicable.
Title: “Socio-Cultural Aspects of Hospital Design. The Patient Perspective.“
Publisher and Date: The Royal Institute of Technology, Stockholm, February 2002.
Author: Nord, Catharina
Site:
http://scholar.google.com/url?sa=U&q=http://www.infra.kth.se/bba/PDF/report_to_nami
bia.pdf
This report concerns the results of a study concerning the "socio-cultural" aspects of
hospital use, including, but not limited to, "Entertainment and Distraction," "Comfort,"
and "Health Enhancing Activities," all of which are applicable to our research.
Title: “Hospital check-ups”
Publisher and Date: Architects' Journal, October 1996
Site:http://www.childrens-express.org/dynamic/public/hospital_031096.htm
This is an article published by Children's Express, which explains the difficulties that
children experience in hospitals. It is of relevance because it also points out some
difficulties that adults would have as well, and possible solutions to those problems. We
might be able to incorporate some of the solutions using our system.
Other Relevant websites
Title: Department of Health and Human Services: Centers for Disease Control and
Prevention 2005.
Site:http://www.cdc.gov/
6
Department of Health and Human Resources Centers for Disease Control and Prevention
official website. This site has massive amounts of information on various diseases, and
conditions, including their symptoms, control, prevention, treatment, and more. It also
has the information available in different languages, and is for the most part easy for the
average adult to read.
Title: “GetWellNetwork: Healing Through Connectivity”
Publisher and Date: GetWellNetwork 2005
Site:http://www.getwellnetwork.com/
The Get well Network develops commercial fully customizable patient information and
entertainment systems. Their mission is to help patients get connected, get informed, and
get well. Their site includes case studies on the usage and effect of patient information
systems.
Title: “Using Windows XP Media Center Edition”
Publisher and Date: Microsoft 2005
Site:
http://www.microsoft.com/windowsxp/using/mce/expert/bridgman_02november25.mspx
This is an article by Microsoft talking about the user interface design of Windows Media
Center Edition. Additionally, it contains history about the move from a 2 ft viewing
experience to a 10 ft viewing experience.
Title: “Introduction to the 10-Foot Experience for Windows Game Developers”
Publisher and Date: Microsoft 2005
Site:
http://msdn.microsoft.com/library/default.asp?url=/library/enus/directx9_c/directx/TechnicalArticles/MCE.asp
This is another article by Microsoft that gives an introduction to the 10-foot experience
for game developers. It gives suggestions about what not to do when outputting to a
NTSC display (such as a TV) and some guidelines about user inputs.
Title: “Building a Linux PVR, Part 2: Microsoft's MCE 2004”
Author and Date: Purav Sanghani
Site: http://anandtech.com/linux/showdoc.aspx?i=2208&p=5
This is an in-depth technical comparison between Windows Media Center Edition and
MythTV (Linux). The hyperlink above is a link to the interface subsection which focuses
on the aesthetic and functional comparison of the two software interfaces.
Title: Flash Games
Publisher and Date: Varies
Sites:
http://www.addictinggames.com
http://www.flash-game.net/
http://www.shockwave.com/
All of these sites provide free flash games for download. Any one of these could be used
as fuel as the games in our entertainment station.
7
Title: “Designing User Interfaces”
Publisher and Date: HCIRN 2005
Site:http://www.hcirn.com/tutor/ui/index.php
This is another website which provides useful information on creating a successful user
interface. It gets specific about certain aspects of the user interface, such as combo boxes,
buttons, and labels.
Title: “Flash Interface Design Made Simple”
Author and Date: Steve Grosvenor, July 2004
Site:http://www.sitepoint.com/print/flash-interface-design
This site provides great tips and suggestions for creating user interfaces in flash.
Title: “User interfaces for digital television: a navigator case study”
Publisher and Date: ACM Press 2000
Authors: Eronen, Leena and Petri Vuorimaa
Site:
http://portal.acm.org/citation.cfm?id=345346&coll=GUIDE&dl=ACM&CFID=5632834
1&CFTOKEN=28877224
The link for the PDF of the full article is on the webpage given above. It contains a
discussion of user navigation through a digital TV menu system to accomplish such tasks
as: show time look ups and finding movie reviews.
8
We approached our design with two distinct thoughts, who are the users and how will
they interact with this system?
The Users
We were anticipating a broad set of users, essentially anyone staying at a hospital for two
or more days. We anticipated several possible scenarios where our system could greatly
improve the patient’s experience.
Possible scenarios include:
•Listen to what the doctor had to say about recommended actions to hasten the healing
process and then send them to your home email address.
•It feels a bit warm in the room; adjust the room temperature to a pleasant 73° F
•Your doctor just prescribed to you some new medications; find out what these new meds
do and what effect they have on your body
•Find something to do that will keep you entertained for at least 30 minutes (E.g. games,
music, web…)
•Your pillow smells like chicken soup; Call a nurse and ask her for a new pillow.
System Interaction
The other main thing we kept in mind was that the user would have to control this
interface from their bed, across the room. So we designed the interface to be controlled
by a simple remote or by an optional keyboard (see figure 1).
Figure 1 - Wireless keyboard and remote
9
We chose a remote because you can control the system without any additional surfaces
(like a table for a mouse). The primary controls would be the four directions an enter key
and a back button. On the keyboard these would be the arrow keys the return key and the
backspace/delete key. The keyboard is not really necessary to control the interface, but
we decided to include it as an optional controller because it would be essential for web
browsing.
In addition to the remote controller and keyboard, we also designed our screens to be
visible from the other side of the room with large fonts and resolutions matching standard
TV 4:3 aspect ratio. In our user testing we found the fonts were very visible. The simple
easy to use menu also resulted in user satisfaction.
Figure 2 – Transition Diagram
The menu structure is broad and shallow making it easy for users to navigate around. At
any point the user can just press the backspace key (or select the back button) to return
back to the main menu. This also minimizes the amount of information that the user has
to keep in their memory. The following is a list of screenshots and descriptions for each
menu item.
10
Main Screen
Figure 3 - P.I.E. main screen
Figure 3 shows P.I.E.’s main screen. The title would change depending on name of the
patient occupying the bed. There are nine different possible selections on this screen.
Eight of them take you to the various functions and the ninth gives you some audio help.
The user moves the cursor (the little gray box) with the arrows to highlight the item they
would like to select then pushes enter to select it. The interface works much the way a
DVD menu would, only much faster. The speed helps give the user the feeling that they
are in control of the system.
11
Games
Figure 2 - Games Menu
The Games menu lists the playable games in a list on the left side of the page. Pushing
enter with any of those selected moves the cursor to the Launch Application button which
when pressed opens the game. Selecting the back arrow takes you back to the main
screen. The help, although not implement, would play an audio file explaining how to use
the page. Once the user has opened the games they can play to their hearts content, when
they’d like to return to P.I.E. they have to push ESC, in a full implementation they’d be
able to push the backspace key or select a menu item from the game.
12
Music
Figure 3 - Music Screen
Although not implemented the music sections gives you an idea of how a music player
would be implemented in P.I.E. The controls would be selectable menu items and the
play lists would slide out on the right hand side. The user would be able to browse
various internet radio stations by genre, or could browse the hospital’s local music library
directly. As with all the screens the back button returns to the main menu.
13
Internet
Figure 4 - Internet Browser
The internet screen is only a screen shot but functionality is easy enough to visualize.
Internet functionality would require the use of a keyboard and possibly a mouse. This
would be the primary source for the user to get information about the world around
him/her. It could be used to read the morning paper or research further about a disease.
Unfortunately this screen was not implemented due to its complexity and the project time
constraint.
14
Movies
Figure 5 - Movies Screen
The Movies section allows the user to select and watch a movie from the list. In reality
these movies would be on a server provided by the hospital and could be accessed at any
time by the patients for free. In our prototype it only play’s trailers. Once the movies are
playing the user can fast-forward by pressing the right arrow rewind by pressing the left
arrow and return to this screen by pressing the backspace key.
Figure 6 - Movie Playing
15
Dr.’s Orders
Figure 7 - Dr.'s Orders
On the Dr.’s Orders screen the patient has access to any information their doctors have
told them; including a voice recording of their previous visit. When the doctor is selected
from the list on the left their picture shows underneath, this can be very helpful to
patients with multiple doctors. The text and voice recording, accessible by pressing the
enter key, help reduce the memory load on the patient while in the hospital. They no
longer have to stress out over trying to remember what the Doctor said the last time they
visited, they can simply access it at any time.
16
Medical Condition/ Information
Figure 8 - Medical Condition/Information Screen
On this screen the patient would be able to read information on the condition they are
being treated for as well as the medication used in the treatment. This allows the patients
to get a better idea what the doctors have prescribed and why. Also accessible from this
screen, but not implemented in our prototype, is a search, which would require the
keyboard for input, that allows the patient to search hospital’s entire medication and
condition database.
17
Room Controls
Figure 9 - Room Controls Screen
This screen allows the patient to control the lights, adjust the room’s thermostat, adjust
the bed, and call the nurse. None of these functions are implemented in our prototype, but
you get the sense of the possible scope of P.I.E. A patient could control their entire
environment with their thumb! The depth of control possible through this screen gives the
user a strong sense of control.
18
Walkthrough
Figure 10 - Walkthrough
This screen gives the user a video walkthrough of the P.I.E. interface with a commentary
to guide them along. Like all the other screens the walk through can be exited by pressing
backspace or navigating to the back button.
19
Development Process
The development process for the P.I.E. 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 P.I.E.
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:
 A patient is in the hospital with multiple doctors attending to him/her. That patient
wishes to review what each doctor said after the visit so as not to forget
instructions or other important information.
 A patient wishes to have more information concerning an affliction.
 A patient wishes for entertainment while lying in the hospital bed with a broken
leg.
 A patient is recovering from surgery and needs something to do.
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
20
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 were 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
P.I.E. 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).
21
Figure 113 - 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 14 and 15.
Figure 14 - Prototype design of the Internet page for the tabbed design.
22
Figure 15 - Design of Room Controls screen for the tabbed design.
The second design is the DVD-style one. The main page would be accessible through the
use of back buttons on each of the sub-screens, examples of which can be seen in Figures
16, 17, and 18. 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.
23
Figure 16 - Main screen for the second (DVD-style) design.
Figure 17 - Prototype of Games screen for second design style.
24
Figure 18 - Room Controls screen for second design.
Figure 19 - Doctor's Orders screen for second design.
25
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 P.I.E. 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
26
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.
27
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).
28
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 P.I.E. 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.
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 TV 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?
The Subjects:


21 year old male Journalism student
21 year old male Biology student
29






23 year old male who has been hospitalized twice
21 year old CS major
22 year old male Math major at GMU
19 year old male IT major at GMU
21 year old male CS major
20 year old male Economics major
At first glance, from the results of the usability testing, the project was well-received and
easy to use. Eight subjects were tested, all college students. For each of the categories
which requested a numeric response, the averages were between 1 and 2. A score of 1 is
the best and 9 the worst.
There were some issues which were brought up by the subjects, though, which the testers
compiled into a list of needs and possible modifications for future versions of the
interface. There were some parts of the interface which the designers knew were flawed
as the subjects entered into the experimental phase, and receiving negative input
concerning those aspects of P.I.E. was expected. There were a few unexpected responses,
though, some quite useful such as the choice in colors and view-ability from a distance,
and others not so useful such as the choice in song title for the unimplemented Music
page.
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 P.I.E.
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.
30
In conclusion we will look at where the prototype is currently and future improvements to
be made.
Current Status









Games screen is fully functional
Music screen is just a screenshot
Internet screen is just a screenshot
Movies screen is fully functional
Dr. Orders screen is fully functional
Med/Cond screen is fully functional
Room Controls screen is just a screenshot
Walkthrough is partially functional
Website available at www.wam.umd.edu/~darwyn/
Future Improvements


















Implement some music device
Implement index search for diseases
Implement help for each screen (text and voiceover)
Have play button for Dr. Orders screen
Make code for video playing consistent.
Include trivia and other mind stimulating games
Display dynamic time on all screens (include a clock)
Show some kind of reaction on room controls screen (make interactive).
Perhaps show some possible play/ff 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 prematurely.
For the walkthrough, go through most if not all of the screens showing the
functionality of P.I.E.
Make mouse invisible.
Implement Internet screen such that it uses both the keyboard and mouse
Fix Tetris bug (which causes most computers to crash)
Use an actual remote control instead of emulating it with 6 keys on the key board
Create an installer that will set the users name
Create text and voice recorder that doctors can use to issue Dr. Orders
Acknowledgements
Thanks to all the programmers that worked on Flash MX 8.0 without whom we would
not have been able to make a prototype so quickly. Thanks to Professor Ben Shneiderman
for being flexible with due dates and actually responding to our emails. And special
thanks to all our peers that took the time to read and critique our report.
31
References
Note: A description and/or summary of each reference is available at the Introduction
section.
Title: “Inclusive design of an interface for a hospital system for information,
communication and entertainment.”
Publisher and date: Disability, Virtual Reality & Assoc. Tech., 2002
Author: McCrindle R., F Arnold, G Cook, J Barrett and D Booy
Site:
http://scholar.google.com/url?sa=U&q=http://www.cyber.rdg.ac.uk/ISRG/icdvrat/2002/p
apers/2002_19.pdf
Title: “Socio-Cultural Aspects of Hospital Design. The Patient Perspective.“
Publisher and Date: The Royal Institute of Technology, Stockholm, February 2002.
Author: Nord, Catharina
Site:
http://scholar.google.com/url?sa=U&q=http://www.infra.kth.se/bba/PDF/report_to_nami
bia.pdf
Title: “Hospital check-ups”
Publisher and Date: Architects' Journal, October 1996
Site: http://www.childrens-express.org/dynamic/public/hospital_031096.htm
Title: “Using Windows XP Media Center Edition”
Publisher and Date: Microsoft 2005
Site:
http://www.microsoft.com/windowsxp/using/mce/expert/bridgman_02november25.mspx
Title: “Introduction to the 10-Foot Experience for Windows Game Developers”
Publisher and Date: Microsoft 2005
Site:
http://msdn.microsoft.com/library/default.asp?url=/library/enus/directx9_c/directx/TechnicalArticles/MCE.asp
Title: “Building a Linux PVR, Part 2: Microsoft's MCE 2004”
Author and Date: Purav Sanghani
Site:
http://anandtech.com/linux/showdoc.aspx?i=2208&p=5
Title: Flash Games
Publisher and Date: Varies
Sites:
http://www.addictinggames.com
http://www.flash-game.net/
http://www.shockwave.com/
32
Title: “Designing User Interfaces”
Publisher and Date: HCIRN 2005
Site:
http://www.hcirn.com/tutor/ui/index.php
Title: “Flash Interface Design Made Simple”
Author and Date: Steve Grosvenor, July 2004
Site:
http://www.sitepoint.com/print/flash-interface-design
Title: “User interfaces for digital television: a navigator case study”
Publisher and Date: ACM Press 2000
Authors: Eronen, Leena and Petri Vuorimaa
Site:
http://portal.acm.org/citation.cfm?id=345346&coll=GUIDE&dl=ACM&CFID=5632834
1&CFTOKEN=28877224
Title: “Patient Power entertainment units”
Publisher and Date: BHR Hospitals 2005
Site:
http://www.bhrhospitals.nhs.uk/hospital/patientpower.jsp
Title: Skylight Healthcare Systems
Publisher and Date: Skylight Healthcare System, Inc. 2004
Site:
http://www.skylight.com/
Title: Patientline
Publisher and Date: Patientline UK Ltd 2005
Site:
http://www.patientline.co.uk/
Title: “Interactive Hospital Systems: The Hospital Network”
Publisher and Date: HCORP Inc 2003
Site:
http://www.hcorp.com/products/Products.htm
Title: Department of Health and Human Services: Centers for Disease Control and
Prevention 2005.
Site:
http://www.cdc.gov/
Title: “GetWellNetwork: Healing Through Connectivity”
Publisher and Date: GetWellNetwork 2005
Site: http://www.getwellnetwork.com/
33