|
|
|
he
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.
elow
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.
- 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!
- 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.
- 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!
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
Back to the Student
Projects Main Page...
|