Rishi Chopra
Amit Bakshi
Cynthia Prentice
Ben Hartshorne
CS160 Final Report
Problem
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 whatever episode of the show that happens to be playing 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 or she is looking for.
Solution
The Simpsons 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. This concept is to allow users to view all previously aired episodes of the
show, find information regarding specific episodes, and communicate with other fans
regarding the show. To accomplish this, the Simpsons Portal user is provided with
options for activities to participate in through a menu bar that sits at the bottom of the
computer screen. Using the navigation bar he can access any episode he wants at any
time. The screen in broken up into different frames, and the user can engage in different
activities in each frame, so as to customize the individual experience. The user can select
the number of available frames so that he can do one, two, or three things at once. Users
are provided with hierarchical contextual menus, allowing for deep browsing of
information, as well as broad information at-a-glance.
Tasks:
The three user tasks allow us to test the main functionality of the Simpsons Portal.
Our goal is to provide fast and easy ways of simultaneously accessing many forms of
information. The tasks cover the different ways that a user can retrieve the information
and episodes provided. The tasks also ask the user to experience the different view
modes. Our tasks do not cover the third view mode (full screen), as our prototype did not
fully implement full-screen functionality. The tasks were chosen to determine the
intuitiveness of our user-interface metaphors, as well as to test as many aspects of the
design as possible.
1) Browse for the episode in season 10 called “Viva Ned Flanders” and read its
plot summary. (EASY)
This requires the user to use the bottom menu bar and the browse screen. While looking
for the plot summary, the user while have to test the hierarchical menu expansion method
we use to compact information. We also initially used this task to test the labeling of our
buttons (browsing v/s searching).
2) Search for the episode where Bart uses a radio to fool the town into thinking
a little boy falls into a well. Now watch it. (MEDIUM)
This tests our search interface and requires the user to do two different kinds of things,
both searching for an episode as well as starting an episode. This provided feedback on
our search feature and our menu system. It was also interesting to see where users
intuitively sought out information (one particular subject already knew the season
number of the episode and went directly to the browse menu.)
3) Find out who does Lisa Simpson’s voice while watching a Simpsons episode
and having an open chat. You are a returning user. Your login is: Bartfan.
Your password is: itchy. (HARD)
This task requires the user to change the screen mode from standard to extended to do
three things at once. He also needs to use the pop-ups above the buttons on the bottom
menu bar to choose which frame the chat, video, and character information are sent to
(the other two tasks allowed the user to get away with sending information to the default
locations.) This task also tests the general info screen, when the user attempts to find out
who does Lisa Simpson’s voice. This task allowed us to truly test the site’s maximum
functionality in terms of concurrent access to information.
Design Evolution
We found ourselves modifying our site throughout the semester, fitting with the “iterative
design process.” To illustrate our design evolution, here we show the changes we made
to three different types of features. We found ourselves changing our pop-up buttons,
which appear in the bottom menu frame, at every step of the process. We made changes
to our Change Views frame largely because of our two testing phases. Changes to our
search screen were inspired by suggestions from our heuristic evaluators. Finally, we
implemented a help section as well as information on using the site to the front screen.
Pop-up buttons
The evolution of our pop-up buttons is particularly interesting because it involved distinct
changes throughout every phase of our iterative process. In our low-fidelity prototype,
the user was intended to actually pick up and move one of many draggable objects from
the bottom menu bar into the frame in which he wanted to view the content.
During our testing, however, when all three of our users had significant trouble with this
metaphor, it became clear that a revision was needed. At this point, we introduced popup buttons that appeared directly in front of the buttons upon mouseover to explicitly
show the user that he has a choice to make. But then, during our high-fidelity testing
phase, we discovered that users would often not notice the pop-ups at all. This led to two
problems. First, users would inadvertently send the content to one of the two frames
(depending on which pop-up they happened to select), causing existing information in the
screen to be erased. Second, in ignoring the pop-ups, the users would sometimes miss
them altogether, clicking somewhere else on the button. The system would respond by
doing nothing.
In our final prototype, we have corrected both of these problems with a few more
changes. The pop-up buttons now appear above the buttons upon mouseover in order to
make them more noticeable to the user. In addition, the buttons themselves would darken
upon mouseover and were given a default behavior (to send the content to the big frame
when clicked). Finally, we changed the appearance of the actual pop-up buttons as a
result of some suggestions we received from our heuristic evaluations. Now, the frame of
the pop-up buttons that is intended to receive the content is highlighted (instead of the
whole button), and the entire pop-up button is highlighted yellow upon mouseover.
Change Views Frame
Our third and most difficult task required the user to do three things at once. In the
course of performing this task, the user was supposed to notice that in the standard
(default) view mode, only two things could be done at once. At this point, the user
should notice the “Change Views” frame at the bottom-right corner of the site and switch
to extended view mode, in which three simultaneous activities are possible. During both
our low-fidelity and high-fidelity testing phases, users had significant trouble with this
part of the task. Users would not notice the “Change Views” frame at all, spending a
great deal of time on the task and ultimately getting frustrated.
We found that the problem was actually easy to fix – in our final prototype, we explicitly
labeled the frame “Change View.” Additionally, we have widened the frame, putting the
different views side-by-side. This helps the user understand that the three views are
actually three choices for them to make. Finally, for aesthetic reasons, we gave this
frame the same Simpsons cloud background as the rest of the site.
Search Screen
The search screen is an example of a feature of our site that changed largely because of
our heuristic evaluation phase. Our expert heuristic evaluators pointed out a discrepancy
between our fields and the universally accepted standard – our field labels appeared to the
right of the fields instead of to the left. Additionally, they suggested that instead of
requiring our users to type in a season number, we give them the option to choose a
season from a drop-down list, to minimize error. We incorporated these changes and
again added the Simpsons cloud background for our final prototype.
Help and Front screen
A help section was finally added to the site. Instead of displaying a “D’oh” image, a help
page is displayed that explains both the button bar and the various view modes. A brief
introduction to the site is also available on the front page, explaining the various frames
and their setup.
Scenarios:
See appendix B for storyboards of scenarios.
Final Interface
Functionality
The latest version of the Simpsons Portal allows a user to browse through popular
episodes and seasons of the series to find information about the episodes or to watch
episodes themselves. Only the information required to complete the tasks is filled in
completely. In the future, plot summaries, character information, quotes, movie
references, sight gags, and other interesting tidbits can be provided for each episode. The
user can watch the video in either the large right frame of Standard view mode, the small
top right frame of extended view, or in the full screen. If the actual episode is not
available an image of Windows Media Player will open to the appropriate size. The
search screen allows users to enter various search criteria, and returns results based upon
submission of this criteria. The results contain the same kind of information about each
episode that can be accessed through the browse menu. The General Info screen allows
the user to look up information about the characters, creators, and actors. Currently
information can be found on Lisa Simpson. The user can participate in multiple activities
at once or commit her entire screen space to watching an episode. Standard view mode
provides one large frame for the primary activity (most likely watching a video) and a
narrower left screen for a secondary activity (like reading a description of the sight gags
for the episode the user is watching). The extended view mode allows the user to do
three things at once. The video is played in a smaller frame in case the user is more
interested in reading information about the episode and therefore wants to dedicate more
screen space to that activity. In addition a small third frame is provided for additional
activity, such as participating in a chat about the episode that is being watched. These are
just examples of how the frames can be used. Other than the video, any activity can take
place in any of the frame for a fully customized user experience.
User Interface Design
 The user starts out in Standard view mode. This gives him the bottom menu bar with
seven activity buttons (Now Playing, Browse for and Episode, Search for an Episode,
General Info, Chat, Trivia, Help) and three view modes (Standard, Extended, Full
Screen) and two frames to work with. The smaller left frame defaults to the Now
Playing screen. This screen intends to show the user the other episodes that are being
watching and who is watching them, so he can choose to join an episode in progress.
The larger right frame contains a welcome screen with brief instructions of how to
begin using the site. (See Figure 4 of Appendix A)
 The chat and trivia button present the user with images of how these two activities
may look when implemented. The help provides advice on use of the menu bar and
view modes. We hope that users will not need to use help feature and the site will be
intuitive and easy to navigate without complex instructions.
 If the user chooses to browse for an episode he can move his mouse to the “Browse
for an Episode”. When the user moves the mouse over a button, images of the current
screen layout pop-up vertically above the button. Each of these has one of the frames
highlighted in yellow. The highlighted frame indicates the location of the browse
menu when it appears. If the user does not click on any of the pop-ups, but instead
clicks on the button itself, the default behavior is for the browse menu to appear in the
left screen. This description applies to both Standard and Extended view mode. In
this example the browse screen will be sent to the left frame in Standard view mode.
All of the activity buttons use the same pop-up metaphor.
 The information in the browse screen itself is arranged in hierarchical +/-menus.
This allows an abundance of information about the episodes to be compacted into a
small amount of screen space. This common information organization method allows
the user to click on + signs to expand a heading that is interesting to them to find for
information. The – sign indicates an already expanded topic. This allows
presentation of both breadth and depth of information. . (See figure 8 of Appendix A)
 The “Search for an Episode” button displays a page that allows the user to search
through the Simpsons episodes by keywords, lines of dialogue, episode title, episode
number, and season number. The search results can be navigated in the same manner
as the browse.
 The “General Info” button leads to info on the characters, actors, and creators that is
arranged in the same format as the browse.
 Chat, Trivia, and Help give an idea of how these features may look when
implemented. The help gives a summary of the functions of the Simpsons Portal and
provides links to browse the help topics and search for a keyword. We hope that
users will not need to use help and the site will be intuitive and easy to navigate
without complex instructions.
 The “Change Views” section of the bottom menu bar provides images of the three
possible screen layouts. By clicking on either the picture or the name of a view
mode, the user can work in that view mode. The size of the frames in the different
view modes is fixed based on the dimensions required for the video. One of goals was
to eliminate the problem of resizing and relocating windows that covered each other.
By fixing the size of the frames, we guarantee a perfect fit.
What was left unimplemented
 Most of the detailed content of the browse, search results, and general info screens is
not included. The +/- menus that are related to our tasks are fully implemented, and
an outline of the general form of the menus are provided to give the user a sense of
how the information is arranged. This allows the concept and implementation to be
tested without spending tedious hours of data entry for extraneous content. It would
also be much more efficient to have this information dynamically generated for
presentation with content stored in a database.
 State information is not retained. This means that, if a user is watching an episode,
and the view mode is changed from extended view to standard view, the episode in
progress is lost and so is the information selected within the frames. Retention of
state information was not implemented due to the technical complexity of
implementation. Given adequate financial and temporal budgets, this could be
implemented.
 Forward and Backward buttons for the left content frame were not implemented.
This feature could allow a user to backup in case they made a mistake, without
relying on the web-browsers forward and backward buttons (which can be unreliable
when using multiple frames.)
 Default link for menu information is the welcome screen. Due to limitations of the
tree-menu system we are using, it is not possible to easily create “dummy links”. If
we were to continue to develop the site, we would probably implement a menu with
dynamic content generation and information stored in a database backend.
 The Chat and Trivia are not yet implemented. When they are clicked an image of
what the screens may look like appears in the desired frame. We are trying to test the
ease at which the user can do multiple things at one time, rather than the design of the
chat or style of the trivia. These features give a clue as to the potential for community
interaction within the site. Upon hitting “submit,” the search screen brings up the
results that are requested for completion of task 2 no matter what is entered in any of
the boxes.
 Adding personalized favorites to the browse menu would add a more customized
touch to the users visit and may be added in a future version.
 The site is design to be displayed with a 1024x768 screen resolution. Most of our
users will be using this level of resolution. If they are using a lower resolution, some
functions may be cut off; a higher resolution will not maximize the use of screen
space. In the future the site could accommodate a wider range of screen settings.
Any wizard of oz techniques
 Menus that contain links to episodes not on the server (top 5 episodes, last 5 episodes
viewed) show a windows media player image instead of the actual episode.
 The login screen for the chat and trivia has been designed, but it is not fully
functional. Any login and password will be approved. The new user and password
reminder functions are not implemented. This could be implemented with cookies,
but would require additional unnecessary complexity.
Tools you used
 Microsoft Image Composer: We used this to modify Simpsons pictures we found on
the web and to create buttons. This is on our laptops, so we hade easy access to it.
We were able to find the functions like cropping, resizing, and adding text that we
needed to make the buttons, although this was difficult to use (Ben really didn't like
this tool).
 Microsoft Paint: We used this to draw pictures of the screen layout options. It was
simple to learn to use, but did not have sufficient functionality. We could not create
the images we needed. The work we did in Paint was redone in Adobe Photoshop
using a Wacom tablet. Paint was useful for saving screenshots into .bmp format.
 Adobe Photoshop: It would have been nice to do all of our imaging in Photoshop, but
not everyone had access to it. Photoshop allowed us to both create and modify
images easily. While providing advanced functionality, it's not too complicated to
learn to use.
 Microsoft FrontPage: We began our web page development using this tool because it
was provided for us on our laptops. Using FrontPage was faster and easier than
writing all of our own code. It provided us with ready-made frame-layouts and
various forms. For some of the mouse-over buttons, FrontPage created java applets
instead of using simple JavaScript. Additionally, FrontPage's code does not work as
well with Netscape. It does not allow for layers, which were needed for the pop-up
screen layouts that accompany the button mouse-overs. Because of these problems
with FrontPage, we switched to using Dreamweaver. Finally, the code output by
FrontPage is often convoluted and ugly. It puts in extraneous information that only
makes the site less compatible.
 Macromedia Dreamweaver: Dreamweaver provides a central place for viewing
images and managing the site. It has an elegant, easy-to-use UI. It contains an
O'Reilly reference guide that explains aspects of the language for CSS, JavaScript,
and HTML. It is both extensible and expandable. We installed an add-on module
from ProjectSeven.com called AutoLayers to help create our popup layers.
 Emacs, vi, Notepad: Despite the excellent tools we had to create the pages, there was
still a lot of work to do by hand, fine tuning the site. Besides all the extra useless
stuff that FrontPage put in, there were some mass adjustments that were easier to do
in a simple text editor than in Dreamweaver. Also, small changes to the site while it
is on a server are easy with vi, instead of making the change locally and then copying
up a new file to the server.
 HTML, Javascript, PHP: Our site is written in HTML. We make extensive use of
Javascript to create our popup button bar, as well as the menus used to browse the
content of our site. We did not use very much PHP at this stage, since we hard coded
much of the content of the site. However, if this site were to be developed to
completion, we would make extensive use of PHP to provide much of the
functionality of the site. Using simple PHP instead of multiple pages would allow us
to keep information in one place and pass it to different modules instead of creating
each episode-specific page.
Appendix A
Button Bar
Figure 1: Button Bar at bottom of site
Figure 2: Button Bar with cursor over the browse button. (A
pop-up menu appears, selected button is grayed out)
Figure 3: One of the two frames from the pop-up menu
is selected and turns yellow, specifying that this is
where the user wants to send the content. Destination
frame is darkened in black.
Changing Views
Figure 4: Standard View allows the
user to do two things at once
Figure 5: Extended View allows the
user to do three things at once
Figure 6: Fullscreen View will use
the entire screen for video viewing
Figure 7: The “Change Views” frame
located at the bottom-right of the screen
OTHER
Figure 8: The Browse for an episode
screen, expanded to show the plot
summary for Radio Bart
Appendix B
Task 1 Storyboard
Task: Browse for the episode in season 10 called “Viva Ned Flanders” and read its plot
summary. (EASY)
(1. The original homepage)
(2. The user moves the mouse over the “browse for an episode”
button and chooses to send it to one of the two available frames,
or just clicks on the button)
(3. The “browse for an episode” page
appears in the specified frame)
(4. The user navigates through the +/- menu bars
to find the desired information)
Task 2 Storyboard
Task: Search for the episode where Bart uses a radio to fool the town into thinking a
little boy falls into a well. Now watch it. (MEDIUM)
(1. This is where the user left off from the last task)
(2. The user moves the mouse over the “search for an episode”
button and chooses to send it to one of the two available frames,
or just clicks on the button to send it to the left (default) frame.)
(3. The “search for an episode” page
appears in the specified frame)
(4. The user uses fills in fields of the search
page to try to find the desired episode)
(5. The results of the search show up and the user clicks on “watch this episode”
to send the streaming video of the episode to the main frame.)
Task 3 Storyboard
Task: Find out who does Lisa Simpson’s voice while watching a Simpsons episode and
having an open chat. You are a returning user. Your login is: Bartfan. Your password
is: itchy. (HARD)
(1. From the end of the last task, the user still has an episode playing)
(2. Realizing that they are trying to do three things at once,
the user chooses the “extended view” mode from the
“change views” frame at the bottom right of the screen.)
(3. The page is now in “extended view” mode.
The playing episode has moved to the top-right frame.)
(4. By expanding the episode “Lisa the Vegetarian, and clicking on “Watch this episode”
the user can play the episode in the top right frame.)
(5. The user mouses over the Chat button on the bottom menu bar to send a Chat to the
bottom left frame.)
(6. The user types in the login information provided in the task instructions and clicks on
Submit)
(7. The user moves the mouse over the “general info”
button and sends the content to the left frame.)
(8. The “general info” page appears in the specified frame, and the user uses the +/- menu
interface to find out what actor does Lisa Simpson’s voice.)
(9. Now the user is doing all three things at once.)