User analysis

Users we're targeting

are primarily of two types:

1. Musical amateurs

  • Enjoy listening to music and know what sounds good to them, but definitely aren't music majors. May not even be familiar with Western musical notation.
  • As such, don't own and don't see the point in investing a great deal of time or money in composition software. Discussions with users of advanced software showed that they would be reluctant and see no reason to use something less powerful.

Details:

  • Age: Ages at which one can use a computer effectively. So, not so young that you wouldn't buy them a laptop, and not so old that they refuse to touch technology.
  • Gender: Either.
  • Motivation: Want to compose because they like how music sounds, not music theory. 
  • Technology: Own a laptop and a smartphone
  • Musical experience: either avid music listeners with no theory (learning the notation), or people who've learned a bit of theory (the typical "quit piano in middle school" crowd)
  • Technological experience: Know how to use a computer, but not how to use composition software, or very little experience with composition software.

2. Maestros

  • You don't always have your USB keyboard midi recorder, computer, and Finale on you.
  • Specifically, people who do own powerful tools and software, but don't necessarily have it available when they are struck by inspiration right this instant omg. pen. now.
  • This would be useful as a sort of musical notebook to bring home and start hacking on when one's busy schedule allows.

Details:

  • Age: As above. You'd think they'd be older but you'd be surprised.
  • Gender: Either
  • Motivation: "I am brilliant and I need to write this down before I forget it"
  • Technology: Own a laptop and smartphone
  • Musical experience: Arbitrarily high.
  • Technological experience: Know how to use a computer and composition software.

Users we surveyed

on the other hand, had:

  • 5+ years of music experience from elementary and middle school
  • College level education (probably not relevant)
  • High technical level (probably not relevant)
  • Own a laptop + microphone
  • Don’t necessarily own a smartphone
  • Casual composer (produce a piece over a long time)
  • Either gender
  • No expensive composing software or electronic music hardware (although they have access to it through MIT)

Task analysis

For all tasks:

  • Where is the task performed?
    • At home or wherever the resources they need are available
    • Potentially constrained by presence of piano, given current tools
  • What is the environment like?
    • Whatever the user feels comfortable with
  • What are the time or resource constraints?
    • People would do this in their free time, no time pressure
    • Within this, there’s not really any time constraints on tasks
    • Maybe paper is a resource constraint if you’re printing from music SW
  • Who else is involved in the task?
    • No one (performers / listeners will get the music, but they aren’t really involved in creating or exporting it)

0. Composing in the first place (i.e., more on the problem)

  • Why is the task being done?
    • Composing for own amusement (also might want to compose / choreograph a piece for skating)
    • Arranging for a capella
  • What does the user need to know or have before doing the task?
    • Music for the piece the a capella is based on
    • A tune in mind if it’s made up
  • How often is the task performed?
    • For our users, rarely, perhaps no more than once a month
    • May work on a piece occasionally in spurts over the course of weeks or months
  • How is the task learned?
    • In 21M.301
    • By trying it
  • What can go wrong?
    • The tune is recorded in such a way that it’s not readable later on
    • The tune isn’t recorded at all and is forgotten
    • User has a melody in mind but doesn’t know how to write the accompaniment
    • User doesn’t have enough skill with an instrument to record with it
    • Often the task is left unfinished because of laziness/lack of spare time/the user doesn’t think it turned out well/ran out of ideas

1. Putting in notes

  • Why is the task being done?
    • to record a melody someone came up with for future listening to/editing
  • What does the user need to know or have before doing the task?
    • what melody they want to write down
  • How often is the task performed?
    • While composing, quite frequently. Speed depends on input method; one user might quickly write the gist of the melody on paper, without caring much about the specific notes, another might play around on a piano between each pair of notes, another might find the note by trial and error in composing software.
  • How is the task learned?
    • by making up a shorthand for writing the melody on paper (dots and lines/letters)
    • In software, you might have to look it up, or just try clicking around until notes appear
    • Less likely, by watching or being taught by someone else how software works
  • What can go wrong? (Exceptions, errors, emergencies)
    • enter wrong value of note, enter wrong length of note

2. Changing notes

  • Why is the task being done?
    • to fix errors
    • to change things as part of the composing process
  • What does the user need to know or have before doing the task?
    • the user has to have notes already entered
  • How often is the task performed?
    • Extremely frequently -- writing music is an iterative process, and blocks of notes, harmonies, etc will be moved around a lot throughout the entire process. For many users, this will be more frequent than inserting new notes.
    • Depends on the precision that the user desires; in one form of shorthand on paper the user simply indicated where the melody went up and down/was fast with very little editing, but mentioned that this was a lot harder to read later on than properly written notes
  • How is the task learned?
    • On paper, same as adding notes -- editing is, in that case, just removing (via eraser or scribbling) and re-adding notes.
    • On software, probably by trying. Some users may be taught how to use the software.
  • What can go wrong? (Exceptions, errors, emergencies)
    • Can potentially move a note to the wrong place -- this would be fixed by moving it again
    • In software, using the wrong shortcut could result in changes the user didn’t want (e.g. a user tried to change a set of 8th notes to 16th notes and ended up with a bunch of 16ths with rests in between)

3. Adding a new track or voice

  • Why is the task being done?
    • to allow notating more than one note at a time
    • to include different instruments or performers
  • What does the user need to know or have before doing the task?
    • Musical theory: some of the users thought more carefully about theory when adding the harmony than the melody.
    • Generally, users would have written the melody first
  • How often is the task performed?
    • somewhat rarely, a few times per piece
    • (we asked them to insert a harmony line, which doesn’t really test this)
  • How is the task learned?
    • On paper, by adding a new line
    • In software, by searching through menus with the goal in mind, or googling
  • What can go wrong? (Exceptions, errors, emergencies)
    • in SW: add a track with the wrong instrument / clef / whatever
    • on paper: didn’t leave enough room (either horizontally or vertically)
    • in SW: accidentally delete a track

4. Exporting and distributing music

  • Why is the task being done?
    • Put music in a format usable by others/self
  • What does the user need to know or have before doing the task?
    • Must have finished writing the music first
    • Must know what format to export to (pdf, paper, midi, mp3, etc)
  • How often is the task performed?
    • Usually several times when a piece is close to being finished
  • How is the task learned?
    • by writing it up in a program, if it was written by hand, then printing
    • if you don’t know your software, google or search help, or ask someone who knows about the software
  • What can go wrong? (Exceptions, errors, emergencies)
    • Printer problems?
    • Audio codec problems?
    • Export wrong subset of the music?
    • Out of mechanical pencil lead?

Existing methods

  • People generally had a choice between using music software (they owned, or free online) and paper (since it’s pretty easy to use and readily available, though not specifically made for the task)
  • Some users needed access to a piano (or similar) to play notes before writing them down
  • Below we list pros and cons of currently-existing methods of music writing, as learned from our user observations and interviews
  • Paper, but not “proper” music notation
    • Pros:
      • Quick to write down
      • The faster it is to write down, the more likely it is to be the melody the person was thinking of; one user said every time she thought about the melody again, it changed
      • Easier to play around with when thinking up a melody
      • One user said music in her head was more about speed and ups and downs than specific notes, and that is much more easily and quickly represented in shorthand than picking out notes on a piano/in a program
    • Cons:
      • May not record important information like rhythm, register, etc.
      • Composer may forget these if not copied to another format quickly
  • Manuscript paper w/ music notation
    • Pros:
      • More faithful representation than above
      • Standardized, unambiguous format (mostly)
    • Cons:
      • Slightly harder to edit individual notes
      • Much harder to edit large-scale structure
      • May be difficult to translate something in your head into the exact notation needed to reproduce it
  • Music software
    • Pros:
      • Easy to put in notes
      • Immediate playback
      • Easy to change a few notes around
      • Easy to export nicely to multiple formats
    • Cons:
      • Clumsy to change things, especially inserting notes
      • Hard to mess with larger-scale structure of piece
      • Synthesized music sounds unrealistic
      • Requires entering all notes in harmony, not just name of chord
    • Note:
      • With the slow input and the propensity for mistakes, a user is unlikely to end up writing down the melody they were first thinking of, because mistakes are kept when they sound okay. Con if a user forgets what they were originally thinking of because the immediate playback feature makes them forget their melody, but pro if it turns out for the better.

Our project

  • What our users want:
    • Be able to input and play back notes
    • Be able to save
    • Lots of features available
    • But not crowded UI
    • Ideally, configurable UI (choose which tools appear in the default view)
    • Recognize sung notes
    • Recognize piano notes played one at a time
    • Recognizing multiple notes at once would be awesome but not essential
    • Easy to change both large-scale and small-scale parts of the piece
    • Export separate instruments separately
    • Export sheet music
  • No labels

1 Comment

  1. Unknown User (juhokim@mit.edu)

    Problem Statement
    This is a very interesting domain with non-trivial UI challenges. Interaction design for music has to bridge the gap between the auditory model a user creates and the visual model your system creates. Looking forward to seeing how it develops!

    User Analysis
    A more thorough analysis of user classes, roles, and characteristics is missing. Also not clear is what you learned from either observing potential users or thinking about their problems. A mere list of characteristics doesn't provide you with enough lessons and insights.

    Task Analysis
    The tasks are quite functional rather than goal-oriented. Generally well-written, but need to think more about 1) what high-level tasks users have when using the system and 2) their usage process in achieving that end goal. Good job on analyzing the existing methods. Always useful to think why current methods break down.