Multimedia Specification Design and Production 2012 / Semester 2 / week 4 Lecturer: Dr. Nikos Gazepidis [email protected]

Multimedia Specification Design and Production

2012 / Semester 2 / week 4Lecturer: Dr. Nikos [email protected]

2

Learning outcomes

1.Case Study 1: Rivier College Registration System

2.Case Study 2: MUSE – a digital music stand for symphony musicians

Case Studies in User-Centered Design

3

Important questions to ask yourself! (Designer-Evaluator)

1.What general and specific feedback is required?

2.What resources are available? People, expertise, facilities.

3.What constraints are operating? Time, access to users

4.How can the required feedback be gathered within the given resources?(Or how can the given resources best be used to produce the required feedback?)

5.What is the best sequence of activities?

6.Have all resources been utilised? (If not, why not?)

7.Does the proposed programme provide opportunities to gather the required feedback?


4

Case Study 1: Rivier College Registration System


An American college, where students choose the modules they wish to register for each semester

An example of the development of the interaction component using a typical evaluation-centred approach

An example of rapid prototyping using Visual Basic

An example of user involvement in the development of the interface to a system

5



The current system1.Students fill in a registration form by hand2.The information is transferred to the mainframe by administrative staff.

Problems1.Expensive in terms of time and effort2.Lack of checks on the student-supplied data leads to poor information in the database3.Forms get lost4.Errors in data entry5.The paper-based forms are not always up to date – e.g. if some modules are cancelled, or new ones introduced

6



Proposed solutionStudents should enter the information directly onto the computer

The data supplied should be subject to approval by academic advisers

As the database already exists on the mainframe, and the data-entry interface used by administrative staff is deemed unsuitable for student use, a new, Windows-based interface should be developed in Visual Basic, based on the paper form:

Windows is familiar to most studentsThe paper form is familiar to most studentsThe interface should be usable with little trainingThere should be fewer errors in the data

7



First prototypeTransferred the paper form to the screen, but on two separate screens linked by ‘continue’ and ‘back’ buttons (also available on one scrolling form)

Used grouped option buttons, e.g. ‘check one from the set of semesters

Used free-form text entry, e.g. for name

Used constrained/error-checked text entry, e.g. date of birth

Used combo boxes for limited responses, e.g. courses

No functionality linked in, but the buttons worked

8



Evaluating the first prototype evaluated with users – students (full and part time, old and young), adminintsrative staff and academic staff

Specific targets for feedback:

What did users think about the form split over two screens compared with one scrolling form?What did they think about defaults should any be supplied and, if so, what should they be?

9



FeedbackStudents were generally happy with the interface

Academic staff asked if the form would notice if essential information was missing

Administrative staff said that the course information was not in a suitable format to map onto the existing administrative database

All said they were happy with either format – two screens or scrolling.

10



Other issues/suggestionsApproval of the form would need some sort of electronic ‘signature’

Could information on selected courses be made available via ‘help’ or similar?

Is a paper form an appropriate model, or should there have been a more radical approach?

11



Response to feedback/suggestions in second prototypeThe first form was retained

The second form was split to improve the course choice

Course choice could be made by name, number, day or department

Scrolling was abandoned once it went to three screens-worth of data entry

Additional benefit added – on entry of student ID all details would be supplied by the system

Evaluation of the second prototypeAll who evaluated the second prototype were happy with the appearance, but were keen to see it linked to the functionality to see that it really worked!

12

Case Study 2: MUSE – a digital music stand for symphony musicians


Students from a range of disciplines – communication design, industrial design, computer science, anthropology, fine art, photography – entering an interaction design competition identified a problem that needed solving:

traditional music stands/paper music are not satisfactory for symphony musicians, especially during rehearsals.

Aim of the projectto design an easier, more effortless way for musicians to practice, rehearse and performi.e. to provide an interactive system which complements all aspects of the musicians’ work without adding complexity, and which makes a performance a more elegant demonstration of the musicians’ talent.

13



Getting startedThe initial survey (which received >100 responses via the internet) asked aboutpractice and rehearsal habitspreferences and problems

which producedan initial list of problems to be addressed: page-turning, making notes on sheet music, communication between conductor and musicians, availability of music/distribution/copyrightplenty of information e.g. re seating arrangements, body positions for different instruments, useful for physical featuressuggestions (some ok, e.g. automatic page turner, a built-in metronome for individual practice and some obscure, e.g. computer accompaniment, score arrangement, self-generating music)a “significant contact” – a horn player with the Pittsburgh Symphony Orchestra – who volunteered the orchestra to provide further feedbacka suggestion that musicians are open to change, but that there is no product yet which meets needs better than current traditional methods

14



Observation of the orchestra in practice – vital to the process

apparent lack of organisation and order while tuning up

conductor arrives and things settle down

the main purpose is not to learn the music but to co-ordinate the musicians with each other and the conductor

musicians practice/learn the music etc elsewhere

the job of the conductor is “traffic regulation” – directing musicians to play specific ways to create certain sounds. The conductor is very familiar with the score, which is used for reference. Often pages ahead/behind the orchestra

communication problems are obvious:

15



Observation of the orchestra in practice – vital to the process (cont.)

… between conductor and musicians, indicating which passage/bar/note being referred to

… when musicians try to describe problems with the music to peers, leader of section or conductor, they need to point to parts of the score

… audibility – hearing one another speak

page-turning – the effect on music, especially when sharing a stand

musicians make notes on sheet music – observations/feedback – useful to them but not to anyone else (illegible?) or to the next person issued with that copy

availability of music/distribution/copyright can be a problem

16



The iterative design process – for both software interface and the physical form

As product definition grew in detail, able to refine research techniques and so get better feedback from musicians. Went through several designs for different parts of the overall system – stand, metronome, tuner – i.e. vertical prototyping, and gained information along the way e.g. need a screen resolution of 300 dpi to represent music if it is to be readable.

The design team did not expect the users to be receptive, as they were trying to introduce technology to what they felt could be a technology-resistant group. They therefore took great care, documenting every step, so that when obstacles were encountered, they could return to previous idea. They started by showing users only the simplest, most basic ideas. When these were accepted, they moved on to more complex ones, building on what had gone before and removing anything that was objected to before moving on. By final presentations, they were getting more ideas than they could include.

17



The final, award winning design

a portable digital display and matching stand featuring

a pitch-generating tuner

stylus-based on-screen annotation

inter-symphony communication capabilities

music library

manual or automatic score progression (page turning) with indexing

a metronome with audio and visual feedback

18



What appealed to the judges

It met all the criteria, but in particular

it had good aesthetics grounded in real needs

It was achieved by way of an effective design process – iterative, good team dynamics, good use of observation of users at work

19

References


https://cloud.google.com/customers/

Documents

Multimedia Specification Design and Production 2012 / Semester 2 / week 4 Lecturer: Dr. Nikos Gazepidis [email protected]