| 
  • If you are citizen of an European Union member nation, you may not use this service unless you are at least 16 years old.

  • Stop wasting time looking for files and revisions. Connect your Gmail, DriveDropbox, and Slack accounts and in less than 2 minutes, Dokkio will automatically organize all your file attachments. Learn more and claim your free account.

View
 

Museums-to-Go Discussion

Page history last edited by Nancy Proctor 11 years, 3 months ago

Museums-to-Go Principles & Premises

 

Some notes to start the discussion from Ted Forbes, Dallas Museum of Art

 
Some of us have some tight deadlines for getting something functional, so I wanted to take a second and outline some of the issues and ideas we had discussed informally over lunch at Museums and the Web 2009 in Indianapolis.
 
This discussion took place with myself (Ted Forbes, Dallas Museum of Art), Nancy Proctor (Smithsonian American Art Museum), Steven Gemmel, Susan Edwards and Molly Callender (J. Paul Getty Museum), Paul Clifford (Museum of London). Sebastian Chan (Powerhouse Museum) was also in on the discussion and provided some wonderful input as they have a web based app they are using at the Powerhouse Museum.
 
Additional people have joined the group as well - Vicki Portway (National Air and Space Museum), Silvia Filippini Fantoni (British Museum), Allegra Burnette (MoMA), Koven Smith (Metropolitan Museum of Art), Chris Alexander (San Jose Museum of Art), Scott Guerin (4274 Design) and Marthe de Vet (the Van Gogh Museum).
 
There are two governing issues that we discussed. Is the Application a Web App (runs in a mobile phone web browser) or is it specifically an iPhone app?
 
There are a few realistic issues here. First - if you make it iPhone only, you'll leave out a great deal of your visitors. Yes, the iPhone is becoming increasingly more popular, but its still a relatively small percentage of mobile users. Second - if you have visitors from out of the country, they could be limited with data roaming charges. There are also distribution issues. You're museum will need to personalize the application and then apply for acceptance in the iTunes app store. There are fees associated with this ranging from $100 to $500 depending on your distribution model. And finally, users need to download this app. Size is a big issue here depending on the type of content in the app - I'll bring this back to the discussion in a minute.
 
A Web-Based application has a much broader accessibility, no required download and a bypass of the iTunes Store, but it comes with a few issues of its own. If you want your users to access content in-gallery, you'll ideally need to have WiFi in the building. We've done this in Dallas, but its untested for the most part for system stress with many users connected at once. If you don't have WiFi in-gallery and it is ultimately cost-prohibitive, you'll need to at least make sure that you get decent 3G reception. Older phone models use other networks - are they able to connect as well? This is all extremely important to planning the type of content that you wish to distribute. The bottom line in the end is the user experience. At what point is having phone content too much of a hassle for someone who came to your institution to see art work and not fiddle with tech problems? Video and audio require bandwidth as do images and text (although they are lighter). There's a big difference between downloading cell content verses a fast computer with a T1 connection. Think back to designing websites in the old days of dial-up internet. What we are talking about is only slightly faster.
 
Pre-loaded devices - Another solution would be to have devices available for rent at your visitor services desk. I don't consider this a smart option for the simple reason of tech support and maintenance. If you get iPod Touch units, lots of people will be touching them and they will need to be cleaned. They also need to be charged. They also need to be replaced at some point. Then what if there are technical issues? They can't connect. They crash or freeze. I think its unreasonable and unfair to expect visitor services to provide tech support. You'll need to consider staffing just to maintain this model. Otherwise you'll find yourself down on the floor spending your day seeing that things are running smoothly.
 
Response from Nancy Proctor: I agree with your premises, but am not so worried about having to hand out devices in the museum. Some sites simply won't have the staff to do this, but there are solutions for the majority and there is lots of best practice from audio tours to overcome the challenges you mention. I don't think there is a single solution that will fit all, so having at least a small number of devices on-site will probably always be desirable if not essential to make sure that all visitors have equal access to your mobile interpretation. (Just as a side note: I used to think a purpose-built museum player would be best for this, because they are generally more robust and are built to do the very specific job that museums need. But I learned at M&W that the Whitney has run the numbers and it's cheaper for them to buy new iPods every year than lease players from an audio tour company. In a sense that makes the museum's life easier, as it eliminates one platform we'd have to develop the content for.)
 
iTunes Store iPhone App - I mentioned above the problem you'll have with limiting content to only those visitors with iPhones. This may not be as big an issue if you want people to connect with objects away from the museum, but it does limit the in-gallery audience. You can go one of two ways with this - you can develop an application that connects to online content. This is wonderful because you don't have to preload content, but if you don't have good 3G or WiFi reception, this is a major issue in gallery. The alternative is to preload all of your content into the app, but this creates issues for people downloading from the store. No one wants to download a 4gb application - its too big and cumbersome. You'll also be stuck with rewriting and redistributing the application each time you want to update.
 
And finally there is GPS which is simply not practical at this time. GPS might work if you have a large outdoor area with good coverage and good signal, but I've tested this indoors - you'll never get it down to the detail you'll want to use it inside a museum. This could and probably will change one day soon, but its out of the question at the moment. There are some new technologies for localizing GPS, but its not practical enough to fit within the scope of the project at this time.
 
Response from Nancy Proctor: I'm also not too worried about GPS or indoor location-based services. I think there are usually low-tech solutions for manual triggering of content (interactive maps, thumbnail icons, keypads with numbered wall labels) that work pretty well and are vastly cheaper than installing, maintaining, and getting LBS technologies to work reliably in the museum. Also, consumer devices are increasingly built with functions that will assist in wayfinding and location-based content triggering; I'm happy to leave this expensive problem to the big companies that have the R&D muscle and resources to solve them for us. In short, LBS should be part of our planning, but as an optional add-on, not a central requirement.
 
Having said all of this - 
 
Here is my proposal.
 
Right now several of us need something that works. We are going to see a huge tech push in this area over the next few years so its actually a good time to start developing this project. But I think its also important to put limits on expectations.
 
As I discussed with Nancy this probably needs to be both a web app and an iphone app. However, in the interest of time and accessibility, I think production should begin with the web app version for this summer and some type of iphone app later this year.
 
To keep this simple and keep the goal reachable, I think we should follow this model:
 
1) A web based app that features various CSS files for mobile browser support
 
2) An interface with a simple, clear and effective way of grouping "tours" in your museum. A "tour" would consist of a collection of works. Each of these works would have various assets tied to them. These assets could include additional text, images, audio and video files.
 
3) A administrative backend for collecting tours and adding assets. You could also control the design and layout (I've built AJAX backends like this before and they work really nicely). Think of this as sort of a Wordpress for mobile content. This way you can manage the online content from any computer connected to the internet.
 
Response from Nancy Proctor: The administrative back-end is critical and I see cross-platform content management and publishing tools as perhaps the biggest challenge we face, after good content and experience design. This was the biggest and loudest ask that came out of the 2008 Tate Handheld Conference. There are several potential partners and resources for this:
 
  • The Fluid Engage Project: http://wiki.fluidproject.org/display/fluid/Fluid+Engage I'm on the advisory board and had a great conversation with the Mellon representative backing this project and he & I want to make sure that Museums-to-Go is synchronized with their larger efforts.

 

  • Several museum vendors are working on or have developed CMS and authoring solutions for mobile platforms and may be interested in getting involved. In particular I'm aware of:
  1. Nousguide (launching their iPhone app with SFMOMA in Dec; see also their tour of the Austrian Cultural Center in NYC)
  2. Antenna Audio has just launched an iPhone app with the National Gallery in London that has a content assembly back-end.
  3. Guide by Cell is working on iPhone apps and wants to be involved.
  4. Ditto start-up MobileXpeditions.
  5. Ditto start-up Toura.
  6. Scott Guerin of 4272 Design (formerly Wivid & SI-Guide) has expressed interest, esp. in LBS apps (see his comment on front page of Museums-to-Go).

     

This would get us something useable by the summer. At that point we could look at additional features and the iPhone version of the application. But once again I think its most important to keep it simple for now.

Comments (3)

Scott Guerin said

at 12:52 pm on Apr 24, 2009

Would the group be interested in seeing a movie of the 2005 SIguide interface in action? If anything, it's a reminder of how complex a universal approach might have to be.

Ted Forbes said

at 8:31 pm on Apr 24, 2009

Scott - absolutely. I think anything would help.

Scott Guerin said

at 6:39 am on Apr 25, 2009

It's a 100MB post so I'll do it over the weekend. Equally relevant is the interface map which is a pdf I just put up.

You don't have permission to comment on this page.