Académique Documents
Professionnel Documents
Culture Documents
http://ratbert.bmrc.berkeley.edu/courseware/cs160/fall01/
Rishi Chopra, cs160-ar
Amit Bakshi, cs160-aq
Cynthia Prentice, cs160-au
Ben Hartshorne, cs160-bn
The goal of the Simpsons Portal is to demonstrate the value of integration of two forms of media,
television and the internet, for a user community that currently uses both. Both mediums
provide users with valuable content, but in different forms. For example, the options given
to fans of The Simpsons via television are limited. Users are forced to watch whichever
episode of the show happens to be playing at the time with little opportunity to acquire
additional, supplemental information about the show or interact with others (besides those
who happen to be watching the show in the same room). The internet, on the other hand,
offers users a vast array of services. Fans of the Simpsons can locate and download
episodes of the show, find general information, and interact with others. However, being
inherently decentralized and disorganized, the internet forces the user to spend a
considerable amount of time finding information that he is looking for. The Simpson’s
portal aims to combine the advantages of “push” (television) and “pull” (internet) to provide
its user community with the ultimate Simpsons experience, all in one place.
Prototype Description
Our low-fidelity prototype is essentially paper taped around the edges of a laptop screen to
simulate frames, and stacks of sticky notes to simulate the information that pops up onto the
frames as a result of the users’ actions. Along the bottom of the screen is a tool bar that features
a combination of buttons that the user can press and draggable objects that the user can drag and
drop onto the various frames to obtain desired information. An episode is actually played during
the test, through a window cut out from our paper prototype, allowing the user to actually watch
the show while using the site. This allowed for a nice combination of paper prototype and
simulation of end-user experience.
Our paper prototype implements two out of the three intended view modes. The user starts at a
website, where he logs into the system. This login will eventually be optional to access most of
the site, but necessary to access areas of the site where the user must be identified (such as a
chat). At this stage, for simplicity, we simply require the user to log in at the beginning. Once he
logs in, the user is confronted with our default 3-frame view mode. In the 3-frame mode, there is
a side bar down on the left of the screen, a main viewing window on the top right, and a tool bar
across the bottom. The 4-frame view features the main window on the left, two frames stacked
vertically on the right (viewing window on top), and the tool bar across the bottom. Finally, the
1-frame mode offers full-screen video. We have not implemented the 1-frame mode at this time.
There are four main buttons towards the left side of the tool bar, two draggable objects to the
right of these buttons, and two more, smaller buttons on the right side of the bar. When clicked,
each of the four main buttons brings up content in the sidebar on the left in the 3-frame mode,
and in the main screen in the 4-frame mode. The two draggable objects, representing chat and
trivia, can be dragged and dropped into any of the frames to activate their feature in the desired
location. The final two buttons allow the user to change between view modes different modes,
and to get system help. For a better understanding of our prototype, see the appendices at:
http://ratbert.bmrc.berkeley.edu/courseware/cs160/fall01/
Participants
We interviewed three men in their 20s, all who watch the Simpsons and who have used the
internet as a resource to obtain information on the show. Subject #1 claims to have seen almost
all episodes of the show, and is extremely computer-savvy. He has occasionally used the internet
to get additional information. Of the three, Subject #2, although a huge Simpsons fan, was the
least computer savvy. He doesn’t usually use the internet to get information about the Simpsons.
Finally, Subject #3 fits our user community the best – he not only uses online Simpson’s guides
like www.snpp.com, but actually collects episodes (both on his computer and on video). It is
interesting to note that our three subjects often watch TV together, with a laptop connected to the
internet in the same room. As they watch the news, sports, or most other types of programming,
they frequently use their laptops to get any additional information that satisfies their curiosities.
Environment
We conducted our testing in User #1’s bedroom, setting up our laptop and paper prototype on his
bed. After being greeted, the users would sit down on a chair facing the prototype, which was
seated on the bed. The facilitator remained to the side of the user, looking over his shoulder,
aiding him if necessary. The two observers sat on both sides of the prototype so they could see
both the user and the prototype at all times. The computer sat on the bed, behind the prototype.
Cindy played the role of greeter, Amit was the facilitator, Ben was the computer, and Rishi (and
Cindy) took notes. We took care to emphasize to the user that is was the prototype, NOT the
user that was being tested. We placed emphasis on making the user feel at ease and comfortable
in exploring the user interface.
Tasks/Procedure
We had three tasks. They are attached as appendix B. The first was of moderate difficulty, the
second was easy, and the third was hard. The difference between the first and the second is that
for the first task, the user had not yet explored the interface.
The goal of the first task is to get the user to use the buttons at the bottom to bring up the search
screen, and discover the basic operations of the site. The goal was that the user would click on
"Find an Episode to Watch" at the bottom. This will bring up the search screen. When they enter
“monorail" into the keywords box and hit submit, the engine returns their episode. Clicking on
the arrow to the right of the episode will then watch it. When they come across the search
screen, they may notice the two buttons at the top, labeled "search" and "browse". This will help
them in the second task.
The second task was to use the other main navigation method, browse, to find the same episode.
Our goal was to get the user to navigate through the data on the site using the browsing method.
Given that they are searching for the same episode, they do not really discover anything new
except another part of the interface. It was fairly easy for all our users, since they had already
explored a very similar part of the interface.
The third task was much more difficult than either of the first two. We wanted the user to switch
views to the 3-frame mode, so as to have both the chat and the episode information section
(either general info or episode guide) on the screen at the same time, while keeping the episode
playing in the corner. Nobody did this correctly at first. We did not explicitly describe the
functions of the various buttons, as we wanted the user to explore the interface; this also allowed
us the opportunity to see what was intuitive to the user.
Test Measures/Results
We tested five different aspects of our interface: search screens, ways to find episodes and
episode information, the “Change views button”, button design (clickable and draggable) objects,
and the +/- context-menu metaphor.
Discussion
Our user testing sessions were very effective. We identified some aspects of the interface that
work well, some that worked poorly, and some of our tests were inconclusive. We have a clear
winner in the choice between the search screens; every tester preferred the more exposed search.
The different buttons at the bottom, although similar, do serve a different method of locating
data, and different users preferred different methods. We learned that our labeling of buttons is
not entirely clear, and could be refined. Our tests indicated that we should have several
alternative methods for arriving at the same data, so that people may use the method they prefer
(arriving at episode information through search and browse). Our initial reasoning regarding the
buttons was to have one button to find an episode to watch and another button to look for
information about any given episode. Our testing showed that users are constantly doing those
two things at the same time, and it would be better to either split the buttons into a search and a
browse, or to have both functions available under one button. The idea of different modes for
varying the number of frames needs more work before it becomes intuitive. The method of
switching between modes and how to interact with them is unclear. This is possibly because it is
different from existing applications, or possibly a limitation of the paper prototype. We also must
differentiate between novice and expert users, and expect our interface to satisfy both groups.
We could add concise instruction to a few parts of the site to describe novel conventions to new
users, if the design proves to be desirable once a user becomes familiar with it. The solution
might also be to use more pre-existing conventions in our site. The draggable objects test was not
conclusive; the paper aspect of the prototype introduced confusion that would not be present in a
hi-fi prototype. Finally, the +/- metaphor worked quite well.