Since the meeting, we’ve been collecting thoughts and integrating the suggestions of the group into the formalized language description of TourML.  In preparation for the next Museum Mobile Summit on Wed Oct 26 in Austin, TX, we’ve updated and reworked the TourML specification to address the results of the first meeting.

I’ll say that TourML is feeling much more complete and much more like the real-deal.  As always, we’d love a lot of comment and input from the community, and would love to hear about ways you would like to use mobile tours in your museum.  We’re already seeing a number of museums building and creating mobile tours using the early version of TourML and the vendor community has been very supportive of the effort as well.

For those technical and metadata experts in the crowd,  you can download a new version of the TourML XMLSchema or browse it from the source repository for the TAP project you can also check-out a sample instance of some valid XML for a tour.  In the rest of this blog post, I’ll detail the changes that have been made to the standard, and will enumerate the reasons for those changes and some questions that still remain for discussion at the next summit.

Stops and Assets:

Perhaps the biggest change in the spec as a result of the initial meeting is the addition of Assets along with Stops as the basic elements that hold content in TourML.  Originally, Stops of different types each held links to their own media assets.  An AudioStop contained a link to an audio file, and so on.  By separating Stops and Assets we achieve a number of important features in the spec that we weren’t able to before.

Each Stop may contain links to multiple Assets which may be of mixed type.  This lets us create new types of Stops that potentially mix different kinds of media together. (i.e. a slideshow with an audio narrative running)  Also, assets for a stop may be defined that relate primarily to the design and user experience of the tour and not just the content of that tour.  For example, header images, icons, backgrounds and sound effects can all be defined as Assets and attached to a particular stop.  In order to tell the difference between how each of these assets should be used, we’ve also added some additional attributes to those Assets that describe their use on the stop.  In addition we’ve added the ability to indicate that an asset should be automatically played when a stop is initiated (“autoplay”).  This would be a great way to start an audio file playing as soon as the visitor reaches the stop.  This removes the need for the old GOTO feature of the initial TourML specification, and is a much stronger way of moving forward.

No More StopGroups:

In the original spec, StopGroups were used as containers for stops and were the way we conceived of linking those stops together for the navigation of a tour.  It was pretty clear in the initial Museum Mobile Summit that this concept was confusing to many.  What we came up with instead, is the concept of a StopReference.  Similar to AssetReferences (described above), a Stop may define a number of StopReferences, or pointers to other stops that a user should be able to use for navigation from that Stop.  This allows the tour author to create a narrative path of stops through the tour, and to offer choices to the visitor about what they might want to do next.  Like the AssetReference, StopReferences have some hints included with them as well.  Using the “navhints” attribute on a StopReference allows the author to designate particular stops as the “first”, “last”, “next” and “previous” stops for navigation.  Therefore, if the tour author wanted a “book-like” experience on a tour where each “page” in the book is a Stop… they could use the navhints attribute of a StopReference to indicate what the next and previous pages are.

There is still some thinking to be done regarding the implementation of the “autoplay” and “navhints” attributes.  It would be great to get some feedback from the community on those ideas and what kinds of values we might want to include with those attributes.

Multi-lingual

An obvious area of interest in the first Mobile Summit was the ability to create multi-lingual tours without needing to completely segment and copy the tour for each different language.  To address this we’ve added a number of language specific elements to Assets and Stops which allow the author to create one or more versions of the content in a stop but using different languages.  We think this is a pretty clean and easily understood way of including multi-lingual content in your next mobile tour.  Take a look through the spec and let us know if we’ve missed any elements that should support multiple languages!

Object Collections

One thing that the original TourML specification never addressed was the ability to include links to objet collections in a tour.  I know this is an application that many people in the community are using right now, and it needs to be supported well in any successful specification.

After asking around a bit and doing some research on my own, it seems the that LIDO specification offers a pretty good solution for describing many different kinds of object collections.  Rather than invent something new ourselves that wouldn’t be nearly as good, or have nearly the amount of thought as LIDO, we think it would be a good idea to reference that specification in TourML, and use it as the default object specification for museum tours.

This is a point that we’ll really want to talk over at the next Mobile Summit, and I hope some folks who are interested in object description (and maybe LIDO) will join us and help us to integrate it correctly.

Rights

As we all know too well, securing the appropriate rights and permissions for media we use in the tours can be a bit of a process.  To make sure that none of that information gets lost, we’ve added some elements to the TourML specification that seek to describe rights information and how it is represented in the tour.  We’ve even added the ability to assign a watermark to different assets on the tour.  Like many new things in the spec, AssetRights can be defined once and reused across many different assets in the tour.

Positions

As more and more of us create tours which rely on the location of users to correctly experience the content, it’s becoming more and more critical to correctly indicate the place of a stop during the tour.  We’ve added a Position element to the spec which exists on every Stop.  This position element can be used to record the x, y, and z position of the stop which can then, in turn, be rendered to a map or some other user interface for the visitor.  So whether you want to locate the new gallery on the third floor of the museum, or the latitude and longitude of where that artifact came from, you can now encode that information in TourML.  We’re also experimenting with the GML specification from the Open Geospatial Consortium to see if that will provide a nice way to tie museum experiences into other location based experiences.

Next Steps

While we’ve taken some great strides towards a more usable specification, we’ve still got a long way to go.  We really need the input of museums and vendors who will look at the descriptions and let us know where it works and where it doesn’t for their particular application.  Again, we’re shooting for a very practical 80% rule at this point in the game (see the previous blog posting), and also to be flexible enough to make TourML work for describing your next tour. Want to help?  Here are some things you can do to help move the process along!

1. Read The Spec: It would be great to get a lot of eyes on this version of the specification as it incorporates a lot of the input from the first meeting.  For those that are not as comfortable looking at XML, we will soon update the text description of all the Elements and Fields on the Museum Mobile Wiki
2. Attend the Meeting: While it might not be possible for everyone who’s interested to attend the next meeting, we really hope that lots of you will join us.  The meeting is FREE and takes place during the pre-conference workshops at the MCN Conference in Austin.  Thanks to the Museum Computer Network Board and Program Committee for agreeing to host this meeting for us!
3. Give us Your Two Cents: Don’t be shy!  Speak up and ask your questions, give us your suggestions about how we can improve what we’re doing.  We completely re-wrote our first version based on the input for those who attended the London meeting.  If we need to, we’ll do it again, and again until we get it right.  We need input from museums, software vendors, academics and enthusiasts to attempt to synthesize something that represents the majority of what we need.  We’ll do our best to smooth out the wrinkles and we promise not to bite!
4. Give us Your Examples: I know that many of you (vendors in particular) have your own XMLSchemas that you’re already using to build your tours with.  We’d really like to see examples of those and how they’re constructed.  This might be a shortcut to figuring out hard problems, finding consistency, and ensuring that the features you need make it into the final spec.  Please post any sample files or schemas to the Museum Mobile Wiki, or mail them to me directly and I’ll put them up for you.

Thanks, and see you in Austin!  -Rob

We’ve promised this for a while, and today I’m pleased to announce that we have released ALL of the materials and source code we’ve used to make TAP as open-source, and freely available to the museum community.  I think it’s clear to many of us that mobile content and interpretation is an incredible opportunity for cultural organizations and the role we play in engaging and educating audiences about our collections and programming. Our hope is that the contribution of TAP might spur collaboration and contribution from other museums to further develop a tool – owned by the community – that can power and deliver those mobile experiences to the public.

I think it’s important for us to explain some of the foundational ideas behind TAP, and why museums might choose this direction over so many of the other options.  In that light here are:

5 reasons why TAP should be your museum’s next mobile platform

1. First-Class Content Management
2. Open-Source, community owned, freely available
3. Open Standards (TourML)
4. Multi-Platform
5. Intuitive and Tested Mobile Client

1. First-Class Content Management

The task of creating mobile tours for museums is an art form in and of itself.  I’m not sure that we’ve  nailed it yet, and we’re certainly still learning a whole lot from our peers about what works and what doesn’t when engaging audiences on a mobile device.  One thing I know for certain is that creating these experiences is a lot of work, and the results are pieces of content that we would be well advised to preserve and reuse over a long period of time.  Along those lines, it is incredibly important that we treat the mobile content we create as a first-class citizen with respect to the other content our museums care for.  If we take this content seriously, we will necessarily store and manage it professionally and for the long term.  A proper content management system is critical in this effort.

The Homepage of the TAP CMS Showing Two Different Tours

TAP is based on an open-source content management system called Drupal (http://www.drupal.org) that the IMA (and many other museums) have used successfully over the years to drive all sorts of online experiences.  This means that any museum adopting TAP as their mobile platform will immediately benefit from the depth of experience in the Drupal community and from the possibilities for expandability and enhancement that come from an active open-source platform.

Because creating the tour content can be time consuming, we need to be sure that the tools we give content authors are as easy to use as possible.  TAP features a very simple user interface, and takes all of the guess-work out of creating a tour that is properly formatted for the web.

TAP's User Interface for Adding Tour Stops

For those of you who have authored these tours in other platforms, there is nothing worse than pushing content to your device platform only to realize that you missed some small little detail or that tour stops were mis-labeled, mis-linked or otherwise incorrect.  TAP’s CMS offers the ability to preview and view media and connections between tour-stops so that authors can be sure all the content is correct prior to publishing to a device.

TAP's Stop Preview Pop-Up for Video

2. Open-Source, Community Owned, Freely Available

If you’ve been paying attention to the mobile tour space over the past few years, you’ll already know that we are seeing an incredible growth in the number of options available to museums who want to create mobile tour content.  Many of these systems offer very nice interfaces for authors to create engaging content and offer very attractive pricing options and incentives for museums who want to publish tours on those platforms.

I can’t help but think we’ve seen this movie before…

In the past 5-10 years many museums adopted proprietary CMS tools to drive their websites too with varying levels of success.  To me, many of the available options for mobile tours today seem very similar to the kinds of options museums pursued to get collections and content on the web to begin with.

At the end of the day, I think we’ve seen now that only a few of those proprietary solutions have been successful over the long term.  Museums bear a responsibility for the preservation of collections and content as our primary and core business service to the public.  Certainly this is possible within a proprietary context, but I would argue that open-source platforms and solutions put museums in the driver’s seat with regard to their own success and content preservation issues.

We are releasing TAP so that others can take advantage of the work we’ve done in this area, and can extend and enhance it to meet their needs as well.  I think we’re all still learning all the features we want and need as a part of a mobile solution.  Our requirements will continue to evolve over the next several years as mobile computing cements itself into our audience’s expectations.  I’m hoping that those who use TAP will also contribute their changes back so that we can build a suite of tools and help each other succeed in this area.

Google Code Project Hosting for TAP

Source code and documentation for TAP can be downloaded from a Google Code Project (http://code.google.com/p/tap-tours).  Instructions for installing the CMS and configuring the iPod Client can be found there as well.  There’s also an email list that we will monitor to answer questions about using the tool.  While we’ve made the process of authoring tours very simple at this point, it will still take someone familiar with web and mobile development some time to correctly setup and configure the CMS and particularly the Apple Development environment.  We’re happy to help with this as we can and continue to document the process.

3. Open Standards (TourML)

As we think about ways that mobile tours are different than web pages, and more so, how we might encode these tours in a way that’s portable and future proof…  We eventually end up needing some standard description of a Tour, its content and its structure.

We’ve floated a proposed meta-data standard for mobile tours called TourML (pronounced Turmoil)  and have published this for comment on the Museum Mobile Wiki.  We’ve successfully used TourML on a few production tours now, and have shown how it can be used to drive many types of tours.  We’re certainly not saying that TourML is perfect, and would really love to receive input from the community on ways that it could be improved, but it serves as a useful (and functional) straw-man as we try to settle on a good standard.

4. Multi-Platform

5. Intuitive and Tested Mobile Client

In addition to the back-end CMS and authoring infrastructure, we are also releasing an iPod-Touch application client that we’ve used at the IMA for public tours.  The keypad based tour is not the only type of tour museums will want to offer based on the TAP platform, but offers a multipurpose and easy-to-use interface that is a great starting point.

We’re working on several different kinds of clients for future versions of TAP including web-based and outdoor versions of TAP tours.

The future of TAP

For our part, we’re working on a new set of tools for an outdoor tour for our 100 Acres Art and Nature Park which will include an HTML5 web client that visitors will use on their own devices.  We’re also going to add some support for GPS and mapping features so that visitors can locate themselves on trails throughout the park.  As a teaser, here are some mockups of our ideas so far.

I’m going to let the images do most the talking, but please note that none of the design or content is completely finalized below.