Native or Not? Why a Mobile Web App Might Be Right for Your Museum

By Ted Forbes

Since 2008, we have seen an explosion of smartphone applications (apps) available from and about museums. A search using the word “museum” in the iTunes store returns literally hundreds of apps for both the iPhone and iPad. Having an app for your institution provides a service on many levels—it’s “cool and modern,” it provides information to visitors in a transparent manner without being intrusive to the physical gallery space, and it offers institutions a powerful marketing tool. Many museums, boards of directors and web teams have expressed that they feel compelled to “have an app” in order to be up-to-date with the latest technology revolution. But is that a good enough reason to pour time and resources into a mobile app? And do other alternatives provide a better return on the museum’s investment?

There are two types of apps that can be developed: “device-native” and “web-based.”

Device-native apps are designed to be installed directly on to the mobile device, and are found in Apple’s iTunes Store or the Android Market, for example. All of the leading smartphone operating systems provide a market where users can find apps and install them on their phones or tablets.

“Web-based” applications work inside the web browser. Rather than going to an online store to browse, download and install the application, the browser is used to navigate to a website that is optimized for use on the mobile device and offers app functionality.

While device-native apps have the market awareness and have been recognized as being more powerful in terms of technical features and options, web-based mobile applications offer many advantages as well. The Nelson-Atkins Museum of Art in Kansas City has built their mobile strategy around their web-based app, which is a mobile website that allows visitors to use any smartphone to access their mobile tour content. The tour makes nearly 300 audio and visual assets accessible for visitors, either during their visit or away from the museum. In order to use staff time and resources most efficiently, the museum’s mobile guide links directly to its collections management system, allowing real-time updates to content and data in the tour. Now that visitors can use their own smartphones in the museum, the requirement of maintaining and distributing mobile devices to those who don’t have them in the museum has been reduced. The museum has also included the mobile guide in their marketing materials, not only to increase visitor awareness, but also to simplify its use when visiting the museum. There is nothing to download in the iTunes store before you can use the tour: you just open the web browser and navigate to the mobile site’s URL.

Mobile Web vs. Apps: Pros and Cons
Web-based apps offer several advantages when compared to their device-native counterparts. The primary attraction is that a web-based app will work on a greater range of devices, since it is accessed through the mobile web browser, whereas device-native apps only work on the specific device and operating system for which it is designed. If you want your app accessible on the iPhone, Android and Windows mobile platforms, you’ll have to develop three different applications. Android is an open-source system and comes in many “flavors.” This makes it very labor-intensive to ensure its compatibility across all Android variations. In contrast, browsers are being designed to support standards-based technologies, so a web-based app will work on just about any device.

Web apps also allow institutions to leverage web-based technologies, which generally they already support. These applications are written on the front-end using HTML, CSS and Javascript, all technologies used in website development. On the backend, you’ll find a content management system that interacts with a database—again, no different from what museums are already doing with their own websites.

Because the app is accessed through the browser, there is nothing to download, purchase or install. The user simply connects to the website. This is also extremely useful in terms of accessibility outside the museum, as it provides the ability to revisit content from the visitor’s own device at a later date. This type of “post-visit enrichment” adds a potentially huge value to an institution and its interaction with visitors.

Another great advantage of the web-based app is that updates and changes to content or design take effect immediately; there is nothing to download. Changes on device-native apps have to be distributed, via iTunes, for instance, and users are responsible for installing the updates on their devices. This can be a time-consuming process, assuming that your users update their apps at all. Likewise, apps and content stored “natively” on devices owned or leased by the museum require staff resources and attention to maintain and update.
Web-based apps can be much cheaper than native apps. Initial development costs for a first generation device-native app can range from $10,000 to $60,000 [1][2]. This is for version 1.0. But then the institution will have ongoing issues of ensuring that the software is current and operates properly as new devices are introduced. For example, when the iPhone 4 was released last year, it included a major software update and a new screen resolution, requiring apps and their images and video to be updated to new, higher resolution versions to support these changes. There will indeed be improvements to processors and operating systems in the future, and basic updates to keep your software relevant are part of the ongoing commitment in time and resources that mobile programs require.

Since web-based apps use existing technologies already installed in your museum, you can likely incorporate a mobile site into your current activities and budgeting processes. In some cases, a web app can be developed by an in-house web team at minimal cost.

Despite the many advantages of web-based apps, there are some downsides to consider as well. Web-based apps live online, so they require Internet connectivity to transmit the content to the device. This could be a serious issue if your institution doesn’t have Wi-Fi access with good coverage and bandwidth in the galleries and other areas where you want the web app to be used. Cellular connections may not provide enough bandwidth or stability to support a media-rich web app experience, and visitors on roaming or “pay-as-you-go” data plans will not want to use their own devices unless Wi-Fi is available.
There is a marketing challenge in offering web apps, as well. Apple has an ongoing marketing campaign for iTunes that includes television commercials. People who don’t even own an iPhone still understand you can get “an app for that.” Web-based apps have to be accessed directly through a URL like a website, so it’s up to the institution to do its own marking and search engine optimization to ensure that people find the web app and know that it is available. Web apps can be “bookmarked” to the device’s home screen to create the look and feel of a device-native app, but not all users will understand how to do this. That requires more education and marketing from the institution.

Dallas Museum of Art
Drawing from our own experiences with the changing trends of technology and emergence of new devices, the Dallas Museum of Art opted to go with a web-based application to deliver our tour content.

Several years ago, we considered implementing cellphone-based tours in the galleries and throughout the museum. Many museums had adopted this technology as a way of allowing visitors to utilize personal cell phones to access audio tour content. However, the Dallas Museum of Art resides in a building that unfortunately blocks out most phone reception. As we investigated the option of purchasing repeaters to solve this issue, it became apparent that we were looking at a multi-million dollar investment.

Therefore, we decided the smarter solution was to invest in an in-house Wi-Fi network. In 2007 Apple introduced the first iPhone, which profoundly changed the definition of a “smartphone” across the entire industry. Seeing the ensuing frenzy of competition to produce the next “iPhone killer,” it became clear that mobile devices were not only going to get cheaper but also more powerful. More importantly, the technology would be changing rapidly. We are an art museum, not a phone provider, so a major concern was that we didn’t want to design our entire program around one particular device. Developing an iPhone app, for instance, leaves out Blackberry and Android users. So considering our Wi-Fi commitment and the evolving technology in both the mobile space and the implementation of web standards, we decided the web-based app would give us the most flexibility. The user could use his or her own device. Even for the devices the museum owns and makes available to visitors, the brand is irrelevant and uncommitted. We can change these without affecting the way the content is produced and delivered.

Examining the Needs of Your Own Institution
As you can see, web-based applications come with a few challenges of their own. It is important to ask what kind of app is right for your institution.

In the commercial world, with substantial budget and options, Pizza Hut developed both web-based and device-native apps. After analyzing app use across both platforms, they found that native apps were popular with loyalists, and the mobile web worked well for customer acquisition [3]. So in choosing the right app approach for your institution, the first question is, who is the important target audience?

Is your audience particularly tech-savvy? Most institutions are a mix of tech- and non-tech-oriented people, but does your constituency lean towards one over the other? If your visitors lean in the non-tech-savvy direction and won’t bring their own smartphones to the museum, this can mean you have to stock a higher number of devices to hand out, with all the additional costs that entails. And how many visitors do you have in the door, particularly at high-traffic events or openings? Both of these questions will impact the number of devices you’ll have to offer on-site in order to provide comprehensive access to your mobile program.

If you are providing your own devices, even in small numbers, you will have to consider staff training issues (or even dedicated staff) for distributing and maintaining the devices. If you have high door traffic, your institution may be required to keep and maintain several hundred devices. What if your visitors have never used an iPod touch and are unfamiliar with the technology? Your visitor services staff might not be equipped to handle long ticket lines while having to stop and provide basic training on how to use the device. You will also have to consider training security guards. When visitors have technical problems, they will not walk all the way back to visitor services; they will more than likely go to the closest museum employee. These are logistical issues to consider that have nothing to do with the web team developing a great app.

Since a web-based application is dependent on an Internet connection, you must also consider your Wi-Fi and bandwidth capabilities. We haven’t had any major issues at the DMA, but we have also invested heavily in our wireless connectivity over the last few years. It is important to note that in-gallery Wi-Fi is not possible for all museums, for reasons ranging from cost to having a historically designated building that prevents the staff from making the alterations needed to install Wi-Fi. Smartphones often come with 3G or 4G wireless Internet capabilities, but use of these services can result in expensive roaming fees for international visitors.

So what do you give up in terms of features when choosing a web-based app over a device-native app? Considering both have been developed to run on modern smartphones, really very little. When their app was banned from iTunes for “competing with the phone’s native functionality,” Google used HTML5 to create a web-based version of their popular Google Voice phone service, successfully circumventing Apple’s restrictions.

HTML5 is an emerging web standard that offers many of the features and functions that until now have been possible only in native apps. Device-native apps can take full advantage of access to the core layers of technology the device provides. These include things like a built-in ability to play audio and video, storing data, use of built-in device buttons controls, animations, etc. Web-based applications have more restricted and limited access to these core functions, but HTML5 now includes many of these features (media playback, geo-location, etc.) in its own frameworks and systems; indeed most of these are already supported on modern phone browsers. HTML5 also allows you to create a fall-back if the browser doesn’t support a particular feature that you want to build into your web app. Javascript is commonly used to work around certain features that aren’t fully supported at this point. It is estimated that HTML5 will be supported across all major browsers by 2014, and it is designed to be backwards compatible, so you can certainly start using it now in the knowledge that it provides fallbacks, meaning if a browser doesn’t yet support a feature, you can assign a “backup plan” of either reduced functionality or an alternative feature. [4]

In Conclusion…
In developing their mobile strategies, it is extremely important that museums consider the full range of mobile platforms available to them, and not limit themselves either first or foremost to device-native apps just because they are “cool and sexy.”

Ultimately your primary concerns are user experience and the quality of the content that you offer. It is extremely important not to let your mobile strategy get in the way of this. Technology changes, and visitors don’t come to your museum to use iPods. They come for a much deeper experience. It is our job to deliver that.

An iOS app (developed for use on the Apple operating systems) is a tempting solution on many levels: iPhones, iPod Touches and iPads are very popular and give the impression that your institution is using the most current available technology. It is a marketing tool that rides right on the back of the millions of dollars being spent to promote the iTunes store. But pull back and look at this from a 20,000-foot view. What are the costs associated? Do the development costs create a program that is sustainable and able to evolve? What about future devices that haven’t been conceived yet? What other devices will be relevant in the coming years? What is necessary to have Wi-Fi in-gallery at your museum? How does this affect the user’s experience? Will visitors be frustrated and distracted, or will they find the content useful? These are all important things to consider. A mobile strategy is a serious and ongoing commitment, not a one-off project.

The mobile web can offer museums cost-effective and sustainable solutions for many of their needs, without the two-week-plus wait for Apple to vet the app and possibly even reject it. Nor are web applications limited to creating traditional tour guide experiences. Tours are obviously a priority for most institutions, but there are worlds of possibilities of projects that would encourage participation and interaction with visitors, and the interactivity of the web supports these. I honestly believe we are only limited by our imaginations and the risks we are willing to take.

Ted Forbes, multimedia producer, Dallas Museum of Art


1. “What does it cost to make an iPhone app?” Toy Lounge, 2010,  (17 September 2010).

2. “How much does it cost to make an app?” London Smartphone, 2009, (8 April 2009).

3. Giselle Tsirulnik, “Pizza Hut exec reveals how branded app achieved 2 million downloads,” The Mobile Xperience, 2010,  (2 November 2010).

4. If you are interested in reading more of the technical specifications, I highly recommend Mark Pilgram’s wonderful web manual, “Dive into HTML5,” as well as Erik Wilde’s dretblog featuring his wonderful HTML5 Landscape Overview.

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s