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

Planning the Future of Museum Mobile Experiences @ Tate

Many of you may know that the IMA has been really active in building mobile content for our main website, our special exhibitions, and 100 Acres.  One of the things I love about working at the IMA is that we always try to give a little love back to our museum buddies when we undertake new projects.  That’s why we’ve made all the software for these mobile experiences available for free to anyone who’d like to play around with them.

While I’m happy that many museums can pick these tools up and use them for their own content, it won’t be the right solution for everyone.  In fact, it only solves just part of the problem.

One of the things we talked a lot about this year at the conference was the need for a common standard for the mobile tours that so many museums are creating.  The danger with such a quickly changing technical playing field is that the choices we make today will certainly be different this time next year.  We risk losing the investment in content we are making today if we don’t anticipate and plan for the changes that we know are coming.

That’s why a group of us (museums, vendors, and other experts) met together after the conference was over to begin to plan and document a potential standard for the mobile content we’re creating.  We had some great conversation and have a good start on some common language that will be really useful as we move forward together.

To keep the fire burning a bit and to hopefully engage all of you – dear reader – in some useful conversation, I’ve put together what I think are:

5 Ingredients Required for a Successful Mobile Standard

1. Simplicity – Let’s face it, there are a lot of standards proposed in the world that are rarely used to solve real problems.  I’m a firm believer in fact that a standard is only “standard” in as much as people use it.  Keeping it simple is important to ensure that the standard can be easily understood in one sitting, can be easily implemented by museums and vendors, and can easily integrate with museums’ existing tools.
2. 80% Rule – Not that we’re underachievers, but shooting for a comprehensive standard is the quickest way to ensure failure.  With technology changing so quickly, seeking to cover only 80% of the most common types of content and tours might allow us to actually finish and put this standard to use (see rule #1)
3. Extensibility – If we are not going to shoot for 100% coverage in our standard, then it will be important that users have some easy way to add their own “secret sauce” to the mix without breaking the rules.  All the successful standards efforts I know of include some way to grow and adapt to changes. Think about the ways we’ve seen the HTML and CSS standards grow and change over time. As we get smarter and smarter about the ways we want to create mobile content, we’ll certainly need to adapt our initial version of a standard to be smarter too.
4. Smart People – Speaking of smart… team work and contributions from  really smart people will certainly be the make-or-break ingredient that determines whether we can succeed in creating this standard.  Would you please consider being involved with us? Don’t feel that you have to be a standards expert in order to contribute something valuable to the mix.  In fact, very few of us are standards experts, and we could really use your best ideas to make this thing work!  I’ll share some specific ways you can help at the end of this article.
5. Determination – Success in this area will require some real commitment on the part of museums and vendors to make it all work.  The standard will require some early adopters to take the plunge and use this standard in practice to sort out all the kinks.  The IMA is willing to do this, and I hope that a lot of you will be too. It may take us a little while to see the fruits of our labor, but it would seem silly to keep investing the amount of money and effort we are already pouring in without at least giving it our best attempt.

How can you get involved?

If you’re interested in learning more, you can track our progress on the Museum Mobile Wiki here: http://wiki.museummobile.info/standards.  You can also read the notes from our first meeting in London.  We’ll be updating and refining those notes as we go, so stay tuned for more information.  Please add comments or thoughts to those pages with any questions or ideas you might have.  You can also track the current version of the TourML XML Standard here: http://wiki.museummobile.info/museums-to-go/products-services/tourml.  Those schema documents will be changing soon to reflect the initial conversations from the London meeting.

Most of All

Come to the next edition of the Museum Mobile Summit to be held on October 27, 2010 in Austin, TX.  This meeting is free and we hope you will attend.  Please let me know if you plan to be there so we can have enough chairs!  The US version of this meeting will continue where the UK summit left off and will align nicely with the MCN Annual Conference that week as well!

Thanks! -Rob

• A slight twist on Isaac Asimov‘s 3 laws of robotics.

Type 'about:robots' into Mozilla Firefox

• An excerpt of the book of Mozilla.

Type 'about:mozilla' into Mozilla Firefox

• Google’s ode to the “bushism“.

Type 'about:internets' into Google Chrome

• A close relative to the easter egg is ASCII art.  Sit back and enjoy the big screen like never before.  In windows, go to “Start” -> “Run” and type in “cmd”.  In the command line type, “telnet towel.blinkenlights.nl” and then hit enter twice.

Type 'telnet towel.blinkenlights.nl' into the Windows Command Prompt

Do you have any favorite easter eggs I might have missed?

Student using Global Origins

If you find yourself wandering through the Asian Art Galleries here at the IMA, take a quiet moment to follow the sounds of the Qin music. You will be led to a giant LCD display with a touch panel overlay and a hair dryer-esque sound dome above your head. Global Origins represents one of the first applications developed in-house by the IMA and marks a pivotal point in how the museum approaches technology.

I’ll step back a moment now and introduce myself. My name is Charlie Moad and I am an Applications Developer (a.k.a software developer) here at the museum. Now before you conjure up thoughts of suspenders and lisps, let me assure you I am quite the contrary. I have never played Dungeons and Dragons and I was only addicted to World of Warcraft for 6 months! I started at the museum 2 years ago and we have since hired another software developer and a graphics designer. Together we form what we call, the Applications Team. Traditionally museums outsource their technology which can be very expensive and time consuming. Each project requires bringing a new consultant up to speed on the basic operations of the institution. We allow the museum to retain knowledge and be more flexible when approaching technology.

Now back to Global Origins (GO). GO is an add-on to the NASA developed 3D world viewer, World Wind. Visitors are presented with a spinning globe and a series of stamps with works of art on them. Touching a stamp spins and zooms the globe to the respective origin and provides more information on the work and the culture. The application is meant to provide users with a visual orientation of where some of these works originated.

Global Origins using World Wind by NASA

We have been secretly collecting stats on this application since it was placed in the galleries almost two years ago. I pulled these stats a few days ago and found some impressive numbers. From October, 17^th 2006 to August, 28^th 2008 we have recorded 372,366 individual touches of the display. This averages almost 550 clicks per day with single day totals peaking over 3000. The graphic below represents where on the screen people have been clicking. The “hot spots” are in the expected places with one exception. People have a tendency to touch in the middle of the screen where the red and white target is located once a work is selected. While touching these targets has no effect, it definitely indicates the user wants more information about these geographic locations.

Click Heat overlay of Global Origins

Now let’s take a look at what works of art the users are interested in.  Below is a table which contains the 11 works that appear in GO.  Following that table is a chart containing the number of times a work has been selected by a visitor.  The spread seems fairly even except for two standouts.  It’s somewhat refreshing to see that the bright woodblock print of Mt. Fuji has a slight lead, and I suspect that the shar pei dog came in a strong number two because people like pictures of funny animals.

woman’s ceremonial skirt (33.682)	ritual wine server (guang) (60.43)
vase (maebyeong) (2001.223)	head of Buddha (1994.1)
Buddha of the Future (1995.1)	bull-shaped vessel (75.301)
seated shar pei dog (1999.2)	Fine Wind, Clear Morning (60.12)
storage jar (81.378)	Ichikawa Kakitsu as Ishidome Busuke and Arashi Kichirodku as Sagihira (72.47.271)
vase with dragon and cloud design (60.82)

Number of Views by Work

This post will be followed by similar ones that offer the outsider a peek into the technology operations of the IMA.  There is a common theme that allows us to be productive.  Open source software allows us to create a wide array of applications varying from the in-gallery interactive mentioned above to the blog you are reading right now.