The Definitive Classical Music Experience, Part 2: Works

Scroll Down

The image is Jieshi Diao Youlan, the oldest surviving piece of written music in the Far East.


How a metadata engine defines the concept of works (musical compositions) affects the classical music experience a lot. Some newcomers still have no explicit modelling of that concept, what a pity!

Classical music compositions modelling and the related UX considerations is the focus of this 2nd post in the definitive classical music experience series.

For a dead simple one-sentence definition:

Music is composed by composers and performed (or recorded, multiple times maybe) for the majority to appreciate.

Our end-user should feel even simpler than the above sentence! But there're complexities for us to absorb:

Metadata Describes a Work

Some common fields describing a work (to name a few) are:

  1. Title
  2. Sub-Title
  3. Non-canonical (alternative) titles
  4. Key
  5. Tempo
  6. Opus Numbers
  7. Genre / Form
  8. Composed Date
  9. Publisher and Published Date
  10. Some others fields are only applicable to special genres:
    • how many acts / scenes does an opera have?
    • In which (religious) occasion a sacred music is often performed?

Some styling guide defines the (too-many-fields) problem as a styling problem: metadata authors should take care of assembling above fields with preferred order, punctuation and typographical treatment, among other preferences into song names like Symphony No. 3 in E-Flat Major, Op. 55 “Eroica”. That's true if we still have to use traditional metadata engines to power classical music experience in the following decades.

The truth is: above fields (and more) are highly structured. A domain-aware platform designed for classical music should take care of the styling problem and uniforms (automates) the overall metadata styling process.

Don't take me wrong, I'm not saying metadata curators' role is less important with the help of a well designed engine. Quite the contrary: It's experienced metadata curators who are dedicated to shaping the modern classical music experience can find the holy-grail styling standard.

The (metadata) engine serves (metadata) curators, not the opposite.

Structures

Some structures related to classical music works are:

  1. Multiple catalogues of a same composer;
  2. Transcriptions, completion, and orchestration;
  3. Root - sub work relationships;
  4. Groups of works (Book I / Volume 1 / etc.);
  5. Movements;
  6. Versions / Editions (associated with performances);
  7. Instrumentation;
  8. and more…

The first 3 types of structures makes the problem harder to solve (at least for newcomers).

UX Considerations

The context defines the optimal shape (presentation) of the content.

Congratulations if a classical music database can meet above criteria. But there're evil traps waiting for us. These traps comes from how the end users interact with the well-structured metadata. Let's list some:

Genre

Should a work be listed under Choral music, Sacred music, or Oratorio depends on the context, rather than fixed unchanged. That's the art of designing a classical music experience.

Actually, if you're familiar with any famous music dictionary, the Bakers, the Oxford, or the new Grove, you can see musicologists have been using this techniques for 100+ years already: they designed different genre-based classification system for different composers. User centered design in the 1900s!

If an app cannot beat the paper-based experience in the 1900s, why should I keep it in 2015?

Super-Long List

As prolific composers can have thousands of works in their catalogue, it's overwhelming for the users to digest a list of thousands of entries.

Cognitive scientists didn't provide a magic number indicating the maximum length of a list, as a UX designer, I don't recommend a list spanning more than double the fullscreen height / width.

The API

We proposed several endpoints describe the list of works of a composer (the plural works) and one endpoint for the singular work.

List of Works by a Composer

Users should be able to browse works in different ways, that's why the below endpoints exist:

  • api.icmd.org/Bach/Works/by/Genre
  • api.icmd.org/Bach/Works/by/Year
  • api.icmd.org/Bach/Works/by/BWV (Yes, it's K and K6 for Mozart)
  • api.icmd.org/Bach/Works/by/BC
  • api.icmd.org/Bach/Works (redirects to the first endpoint currently).

In year 2008, I also designed an alphabetical ordered list, which have been proven wrong from an UX perspective and should be replaced by a search inside feature:

  • /Bach/Works?q=St%20Matthew%20Passion

The Magic

Above endpoints provide a flat list, which is 1000+ for Johann Sebastian Bach! For a better experience for the upcoming tonal app, there's a magic parameter optimize which groups the works into meaningful groups.

For example:

  • /Bach/Works/by/Genre?optimize will group the 1000+ works into genres, and,
  • /Bach/Works/by/Years?optimize will group them into decades,
  • If you're familiar with the BWV catalogue, you should know the BWV catalogue can also be grouped into parts.

Wonderful!

View Comments