Rishi ChopraAmit Bakshi

Cynthia PrenticeBen 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 buttonsThe 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 pop-up 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 FrameOur 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 ScreenThe 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 screenA 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

FunctionalityThe 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 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.

Figure 2: Button Bar with cursor over the browse button. (A pop-up menu appears, selected button is grayed out)

Figure 1: Button Bar at bottom of site

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 7: The “Change Views” frame located at the bottom-right of the screen

Figure 6: Fullscreen View will use the entire screen for video viewing

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.)