Mobile Content Standards Summit US 2010b

Notes from the gathering at MCN 2010, Austin, TX

1-5pm 27 October 2010

Three asks of all who attended and read this blog post:

1. Tell us if you are interested in using the spec/
2. Contribute your existing specs/documents so we can learn from them.
3. Comment on the spec and what we’re doing.

Attendees:

• Meeting led by Rob Stein, notes by Nancy Proctor
• 90% of attendees are from a museum or cultural institution
• rest are academics or vendors
• 15-20% have produced a mobile experience in the past
• 40-50% have a mobile experience in development
• 100% of attendees expect to work on mobile eventually

Main agenda items for today:

1. How can we link tour content to collection objects
2. Methods for extending the spec: versioning

NB:

• This effort and summit is focusing on tour content but not limited to objects collections. (Note tours are not the only mobile experiences, but they are the bulk of mobile today so will be the first focus for this standards effort.) Extensions will enable us to grow the spec to take account of mobile social media and more complex mobile experiences.
• Wherever possible, we’ll use existing standards (eg GML) rather than reinvent them all.
• Issues being addressed are both portability of mobile experiences to future platforms, and preservation of mobile experiences

Primary content types

1. Tours

2. Stops: can point to other stops, and/or to assets. Should stops be optional? See experience/logic discussion below.

• ID: a unique identifier for the stop, not meant to be read by humans; at this point, the only required field
• Code: either numeric or text, can be entered by visitors to access this stop
• TitleDesc: you guessed it! Stops potentially have multiple titles and descriptions, e.g. multi-lingual tours
• Point: A Geography Mark-up Language (GML) reference to a location for this stop (a widely used standard for this kind of data). Locations can be points on a floorplan, or points on a map. GML is a standards-based description for location data.
• Param: A placeholder for key-value pairs. This is a concession for application-specific needs not-yet-envisioned by the specification.
• AssetReference: Assets used by the Stop. These might be content assets like an audio narrative, or display assets like an icon or sound effect.
• StopReferences: Stops linked to this Stop. Linking stops via references provides a way to encode navigation and choice from within the TourML description. Can be linked one to many as well as many to one. (More about this later!)

3. Assets

• ID
• TitleDesc: One for each language
• AssetRights: Human and machine readable rights; credit line, expiration dates, watermark assets: NB we could use a rights management specialist to help with this part of the spec!
• Other types of assets: audio, image, object, polls, text/web, video

LIDO Schema:

TourML’s choice as object reference?

• Couples CDWMA lite with MuseumDat; better to use an existing standard here: Dublin Core would be the other option
• Erin Coburn: LIDO preferable: quickly becoming an international standard for describing objects, covers all types, packaging a minimal amount of info needed for the object for dissemination; LIDO based on existing standards: CDWMA lite + MuseumDat, compliant with CDOC conceptual reference model – the only ISO standard for cultural heritage sector, adheres to Spectrum, allows multilingual use of thesauri, adheres to cataloguing of cultural objects; allows asset description not connected to an object
• Hesitation: how easy is it to use? Allows us to use events, but different to how N. Americans think about object data
• Rob Stein: looked at CDOC CRM but seemed too difficult to use – didn’t pass the viability test.
• Only 3 required elements in LIDO
• Titus Bicknell: do they need to be embedded in TourML? or can they just be referenced in the TourML doc?
• RS: if you need to access the object, would need a network connection to go get it if not embedded
• Requirement: Choice of embedding the LIDO object, or simply referencing it (already provided); need an end point for that repository, or a URI
• EC: object info can include the rights info – becomes redundant with TourML & implies a methodology – odd for a standard; don’t want to be redundant – have to repeat descriptive elements within this schema
• BW: why not just use LIDO? Do we need another standard
• RS: this is why I hesitate to call it a standard; we’re trying to preserve and port not just the objects/content/assets, but also the interaction among them; LIDO can’t model the narrative pathway through the assets – TourML is almost a storytelling model; use LIDO to describe assets
• Piotr Adamczyk: TourML is more a file specification
• Bert: TourML does not preclude use of any external standard: is not aiming to replace these, but add interaction model
• BW: Use TourML as a building tool
• John Gordy: how does context impact the definition of the asset/object? (EC thinks LIDO can accommodate this.)
• RS: most museums would find it pretty easy to get to CDWMA lite pretty easily; hope that vendors will pick up LIDO as an export option (Gallery Systems has)
• NP: do organizations have to be up to speed on other standards like LIDO or CDWMA lite before they can adopt TourML?
• TB: Should TourML be stand-alone? Should it provide all you need, even if you haven’t adopted TourML?
• BW: Can’t the extensibility allow people to start with the tour, and later adopt other standards
• EC: concern that TourML is locking you in to a certain way of doing things…
• RS: shouldn’t lock you in: gets you one step closer to a way of doing things that is standards compliant; we can’t preclude that your assets would be stored in LIDO, CDWMA lite or MuseumDat: the specification for TourML needs to be able to support all these different options; best practice would involve these but also possible to do a quick & dirty implementation of TourML alone; TourML can evolve in line with other standards
• Bert: holy grail is that you can feed TourML to another platform and out comes your tour; puts requirements on publishers
• RS: but more likely you’ll get 80%; whatever we require or support in TourML, we require the content producers and consumers (mobile clients) to support that specification); clear that we want to support more than one kind of object description; also multiple asset descriptions
• TB: aim is for the museum community to specify to mobile vendors the standards/schema we require, rather than have to adopt vendors’ specifications
• Bert: more flexibility = less interoperability
• RS: also why we don’t want to specify 100%: want to leave room for innovation, for vendors to distinguish their products (80/20 rule gives museums a choice)
• BW: there is also a business case for vendors: they can build premium products on the standards

We are modeling three elements:

1. Assets: belong to a single stop if meant to be experienced together. E.g. SFMOMA ‘stops’ include an audio track that can be listened to while either looking at an image or reading a description (text) label.
   • Do we need a logic to describe interactions among assets in a stop (transitions)? E.g. a preferred image – consistent with a usage hint. Tim said: “You press a button to see the object label” – what is that action described as? A: a design choice, should not be encoded into the specification. But the way/order in which assets are experienced in a stop does need to be described, is part of the experience design that we may want to port to other platforms or otherwise preserve: e.g. to specify that this audio file can be listened to with either this photo or that text but not that video; all of these assets are part of the same stop.
   • Trigger actions?
   • Assets can be aggregate or sequenced: e.g. a slideshow could be a single asset, or it could be an audio file + a number of images.
   • Maybe this schema should only express connectors among stops, not among assets. Use instead Smil, actionscript, javascript or other methods of describing the interaction among access.
   • Scripts: an asset that describes how assets interaction; alternative is behavior hints (see below). How to avoid this becoming a bucket for junk? May reduce portability if misused, but a smart tour designer would use the scripts to increase description/portability. Can’t prevent misuse, but worse case you still have the assets that go together and just need to reconstruct the presentation layer.
2. Stops: a collection of media/assets or other stops meant to be experienced together by a user.
3. Connections/connectors in the experience layer: logic/sequencing/connections among stops. You can trigger transitions among any order of stops, or among assets (to come back to asset transitions!). Other terms being floated for this: transitions, pathway, story, links, semantic connection… Path could be good to describe the connections (the path) that a user took through assets/stops: a set of connectors defines a linear path.

NB: there are interactive ‘stops’: e.g. quizzes, polls, touch & listen – these should be considered stops, not connectors. Although they involve activity, that activity is focused physically or conceptually on a point in space and time, therefore accurately described as a stop and different from the activity that ‘connects’ stops.

It should be possible to export just the assets without any of the experience layer.

Behavior hinting

TourML is not just modeling content and assets, but also interactions: logical connections, authoring decisions, sequencing of experiences and content – how do we preserve that?

1. Autoplay
2. Usage: mostly to do with assets, e.g. icons, such as thumbnails for images; background; headers and footers – presentation elements that are important for what the tour looks like, but not part of interpretive content
   • Possible to use spriting or coordinates?
3. Order
4. Duration: a connector specification, e.g. specifies in & out points for a video differently in different stops
5. Navhints: e.g. soundtracks & soundbites
   • Is this a storytelling layer instead?
   • Are the stops the logic that connects assets?
   • Should stops be optional??

There is nothing to stop people from adding fields to the spec.

What are we missing?

• BW: does this spec describe experiences without devices?

• NS: What about metrics, data on usage?
• NP: Or user-generated content? Kind of don’t want to go there yet as social media is too new to be described in a standard language yet…
• CM: would be good to specify analytics tool for tours; could do with Param file

• John Gordy: Where’s the front end?
• RS: see sample code in Google code

• RS: What about touch & listen?
• NP: Not sure we need to describe this; like describing a slideshow – this remains in asset layer, params etc.
• TS: But there is some kind of logic behind certain kinds of asset aggregates, e.g. slideshows, touch & listen – these are independent of the device. There is not technical hurtle in executing these on different platforms, but there is a logic that needs to be respected.

Other questions and discussion:

• Rob Stein: Can we use mobile initiatives to share content across institutions? We share exhibitions, catalogues already…

• Corey Timpson: How do we make mobile content findable as it proliferates & is shared?
• CT: Can we define controls in the language, e.g. for in/out points in video
• RS: yes, make it a reference attribute, like duration

• Bruce Wyman: What about assets that apply across a range of stops? E.g. a sound effect…

• David Klevan: Can assets point to stops, e.g. polls lead to different stops based on the way the user answers the poll?
• RS: We could use some help thinking through this; could use code attribute as a stop
• BW: this spec should only describe the ‘stuff’, not the actions: the sw does that; we are not modeling interaction, just defining buckets of objects
• NS: some kinds of interactions do need to be defined…
• RS: use ‘hints’ as what happens next
• BW: this is how html works

• DK: Can we add an author field to stops and assets?
• Nancy Proctor: Will be essential to enabling our sharing assets/content across institution’s mobile experiences.

• Titus Bicknell: What about situations where the file being referenced is an aggregate of assets? e.g. old multimedia tours, closed captioning; can we specify without limiting the number of authors etc?
• RS: this applies to rights and authorship of assets too: need to consider multiple points of origin for assets
• Susan Chun: the behavior will impact the rights status too

• Sheila Brennan (via Twitter): will the TourML standard only be applicable for stand-alone mobile apps? Any thoughts to how this affects mobile web? Or, separate design elements from content structure? “Tour” could call certain types of object metadata for a mobile site. Ex: a “tour” =DCMI items, “stop” =itm descrip. Or, is this to prevent locked down proprietary content from app makers?
• RS: a native app that can interpret TourML can also be interpreted by TourML; IMA mobile website seamlessly integrates with mobile tour in TAP to provide opening times, event info, etc.

• Nate Solas: What about VoiceXML schema? anything we can use from that?
• RS: is there a notion of automatic vs user-controlled actions?
• PA: isn’t linear action the kind of thing we want the software to define?

• Is Standard the right term for what we’re defining?
• Mia Green (via Twitter): But some rigour is needed for a standard to work so ok?
• CT: “framework”?

• Stylesheets wouldn’t be defined in TourML – in the authoring tool you’re using.
• Kyle Jaebker: Params define transitions among assets already
• Charlie Moad: Add an asset called a script/stylesheet – is presentation an asset? An option if these features are not defined in the params
• NS: is it the Hint document?
• TB: do we need to specify concurrency?
• Tim Svenonius: implied by order
• BW: don’t let the catch-all become an excuse for sloppy use of the spec