Email: anthony@handaweb.com

Go to Site Map

Return to HandaWeb Home

 

 

Learn more about Anthony

Go to Project Portfolio

Go to the Photo Gallery

Go to the Comedy Lounge

Read some of Anthony's Tales from the Rice Paddy

Read some articles from the Iwate Pre-Departure Handbook

Credit where due & some cool Links

 

U-M Player Project:
Introduction & Methodology
Winter 1999

 

The concept: Design the user interface for a media player application that could play any media regardless of the source: cable TV, broadcast TV, radio, streaming audio and video, CDs, DVDs, etc. The other two people in this project are Ying Cao and Amy Johnson.

Below we explain the project assumptions and methodology we used for the development process. Please also look at some screen shots from both our proposed interface and currently available players.

Project Assumptions

  • Home consumer, relatively sophisticated with usage of electronic devices
  • Broadband access to the home supporting TV/cable-on-demand via the Internet
  • A home network including data as well as digital TV drives (similar to the TiVo system)
  • Sophisticated search engine, perhaps supplied by the U-M Player maker and backed by a proprietary database (similar to Real Networks' Real Jukebox system). Also, perhaps built on a subscription service for premium content!

Methodology

  1. Determine the scope of the project.
    We did not come up with a precise definition, but decided on a general purpose and audience for our product.
  2. Evaluate existing hardware and software systems.
    We studied existing media player software, analyzing the set of features available with each, the styles implemented, the terminology used, and any interesting and unique aspects of each program. We did the same thing, to a lesser extent, with our home stereo components, as well as with VCRs, DVD players, and the new Rio MP3 player. This process not only gave us a general impression of the market, but also resulted in specific opinions which would later be incorporated into our design. For example, we found that although knobs may be easy to use on a hardware device, using a mouse to turn a knob on the screen can be very difficult!
  3. Categorize evaluated systems.
    At the end of our evaluations we discovered that most of the current systems fell into a number of categories, the most common being the home stereo look-alike style. We discussed what makes the different styles popular, and what distinguishes the programs that did not fit well into any category. This naturally led into a discussion of what style we should use for our system.
  4. Select the feature set and terminology.
    This included deciding what the system should do and what words best described the functionality. While we all agreed that the system should contain a multitude of features for the advanced user, we tried to focus on the primary functions - those that would be readily available for all users.
  5. Prototype components, overall style, icons, and functionality.
    The designs started not as complete systems but as small pieces that could later be fit together. We explored in depth how particular functions, like search, should work, what set of icons best described the available media, and which options were appropriate for each type of media the user might play.
  6. Iterate!
    Steps 4 and 5 actually happened simultaneously and involved a number of iterations. We typically would sketch out designs individually, have a working session where we shared, commented and revised ideas together, and then would work individually again to address questions which came out of the session and to design the next group of components and features.
  7. Develop the first complete prototype.
    Eventually the components started to come together into a complete system. We created an overall style for the system, and added in each of the features we had selected. We had to make some compromises (not just here, but throughout the project) and knew that parts of the design needed more work, but we wanted to have a complete prototype ready in time for testing.
  8. Test and revise.
    We used paper prototypes of our screens to have a number of individuals complete a series of tasks using our system. We revised numerous aspects of the prototype's interaction and the user interface.

 

Other Links in this Project Document

Back to the Student Projects Main Page...

 

 

 

About Me | Project Portfolio |
Photo Gallery | Comedy Lounge |
Rice Paddy Tales | Iwate Handbook | Credits & Links

Contact Me | Site Map | HandaWeb Home/Anthony

 

Images & Text ©1998-2000, Anthony Hand
Email:
anthony@handaweb.com