Help us design a kiosk solution for the Smithsonian’s traveling exhibitions (and more…)

2007 walk-off home run celebration at home plate

The Gulf Coast Cardinals celebrate a victory, Lake Jackson, Texas, 2009. “Hometown Glory” by Brenda Read Photography.

The Smithsonian Institution Traveling Exhibition Service (SITES) is considering the development of a mobile website and/or tablet application for visitors to its upcoming exhibition, Hometown Teams: How Sports Shape America. The exhibition explores the importance of sports in American life and the impact of sports on culture, communities, and on American character and values.

The website and/or application would allow visitors to the exhibition galleries to navigate through text, images and video of game-day experiences at athletic events. The website and/or application would be required to operate in kiosk mode for continued use, work without continuous network access (as not all exhibition venues will have wifi or cellular data network coverage), and allow SITES staff to make content changes and reload a new version of the website or app to the device on an annual basis. SITES plans to reuse and build on this solution for the kiosk requirements of future traveling exhibitions as well.

The project must be completed by January 15, 2014 and will be used throughout the life of the exhibition, Hometown Teams, which will travel to up to 180 communities in 30 states before retiring in 2020. Hometown Teams is a project of the Museum on Main Street program, a special collaboration between the Smithsonian and state humanities councils to provide exhibitions and programmatic expertise for small and rural cultural organizations.

Here are some of our draft functional requirements; we’d love to hear your suggestions on these and others!

  • a web-based, user friendly content management system interface that allows the Smithsonian to change content easily, publish a new version of the app or website, and load it on to the devices that will be installed in the exhibition, either individually or en masse, via wifi or a cellular data network – when Internet access is available!
  • open source technology and/or reusable components are preferred.
  • a fun and colorful interface inspired by the exhibition design, but developed in a template-driven way so that the kiosk’s look and feel can be customize for use with for other projects and devices in future.
  • ability to collect analytics on kiosk use, even if just partial. Please note that Internet connectivity will not be continuous, so the analytics solution should be able to store usage data locally on the device until it can synch with a web-based analytics collection and reporting tool.
  • compliance with W3C web accessibility standards, supporting resizing of text, Voice Over or similar text to speech functionality, and video captioning as well as navigational buttons that are usable by people with reduced mobility in their hands and fingers.

How Would You Do It?

Here are some of our questions about the developing the solution; what else should we be asking? Please add your comments and suggestions below.

  • Would you propose that the Smithsonian develop a mobile website or standalone application to achieve its goals?
  • Would you suggest we utilize open source programming and reusable components?
  • How long would it take to develop the initial kiosk product?
  • What methods and tools would you suggest for collecting usage metrics, especially given that the kiosks can’t be always connected to the Internet?
  • What kind of content management system would allow the Smithsonian to alter content each year most efficiently?
  • What standards should the project employ to ensure future portability of the product and content to other platforms and uses?

We hope to issue a request for proposals (RFP) for this project in the next few weeks and will include a link to it here when it is published.

6 thoughts on “Help us design a kiosk solution for the Smithsonian’s traveling exhibitions (and more…)

  1. Would you propose that the Smithsonian develop a mobile website or standalone application to achieve its goals?

    Either could work, though the semi connected use case you describe may be best suited to a mobile application. Some exploration of potential use cases and understanding the deployment environment a bit better will help get a more direct, definitive answer.

    Would you suggest we utilize open source programming and reusable components?

    There are many options for open source content management and mobile development frameworks. It would make sense to leverage ones that are scalable, mature and secure where appropriate. Responsive design should factor into this decision making process as it offers a good bridge to future web technologies and helps target the multiscreen world we now live in.

    How long would it take to develop the initial kiosk product?

    A variety of factors could affect this related to stakeholder input and fine scope details, but generally speaking we take about 3-6 months for design and development on decently sized mobile efforts.

    What methods and tools would you suggest for collecting usage metrics, especially given that the kiosks can’t be always connected to the Internet?
    There are ways to make even the “online” analytics packages like Google and Flurry analytics support offline via HTML and custom app development efforts, so this seems like a tricky, but not unsolvable problem even for products already existing in the marketplace. You could also couple something like the recently released Tin Can API (xAPI) with these platforms to store discrete session data in a semi-connected fashion and use learning records stores or learning management systems to report on the usage of the system.

    What kind of content management system would allow the Smithsonian to alter content each year most efficiently?
    I would favor a CMS with a strong webservices infrastructure available and a proven track record. I usually favor Drupal for large scale open source deployments, though there are other options out there also suited for work like this.

    What standards should the project employ to ensure future portability of the product and content to other platforms and uses?
    Thinking about data-portability, communication standards and true robust separation of content from presentation would be the biggest overall considerations to focus on at this time. Talking about exact specifications or data schema without fully understanding the use cases or final project requirements would be a little premature and maybe even counter productive to adequately scoping and planning the project. Focus on the desired outcomes and the solution (including standards) will come out of it.

  2. Hello Nancy,

    – Would you propose that the Smithsonian develop a mobile website or standalone application to achieve its goals?

    We believe that you should develop your content structure and database centrally but develop the various outputs/interfaces specific to your end use. A native App, a mobile site or a full screen kiosk interface can all be distinct but connected to the same system. Using just a mobile website on a kiosk will not create a very interesting user experience in our opinion.

    – Would you suggest we utilize open source programming and reusable components?

    For the content management system: absolutely. For the outputs most definitively. You may or may not need some specific programming to connect the whole together tough.

    – How long would it take to develop the initial kiosk product?

    If you use as a base existing solutions (open source tools coupled with what some companies or developers have cooked up over the last few years), more or less four/five months (the longest part is usually agreeing on the data structure, presentation and specification for deployment). If you develop everything from scratch, +/- 9 months/a year in our experience.

    – What methods and tools would you suggest for collecting usage metrics, especially given that the kiosks can’t be always connected to the Internet?

    The Web CMS may have its own tool (pretty much all of the ones we use have one). You can also use Google Analytics if you connect your kiosk to a local server (or the Web). You can connect periodically to gather the user metrics while they are stored locally when offline.

    – What kind of content management system would allow the Smithsonian to alter content each year most efficiently?

    That is a question of preference, but for an organization such as the Smithsonian, we would lean towards something like Drupal, combined with SQL, MySQL or Postgres. Powerful, flexible, sustainable and well integrated and supported into the museum community.

    – What standards should the project employ to ensure future portability of the product and content to other platforms and uses?

    Web standards are your safest bet for accessibility, structural integrity and portability. Also consider HTML5. It can give you interesting presentation and interactive possibilities for the kiosk interface.
    For native Apps, you have to rely on best practices in the use of the respective SDKs.

    Hope this helps,

    Regards,

    Daniel

  3. I agree with many of the points made by Ideeclic, Chad Udell and Matt Paheen. Drupal combined with MySQL or SQL, a mobile web site using HTML5 and Google analytics will address the needs of the project very well. In our experience you’d need 5-6 months of development time, but that really depends on the features and user experience envisioned by SITES.
    We noticed that SITES only plans to update the app annually. This indicates that local content won’t be included in the kiosk/website. I know local content can be uploaded to SITES’ Facebook et al, but wouldn’t it be gratifying for people to see their own teams/players on the site as part of
    the larger story? For places with wi-fi grabbing that content could be automated on a regular basis, and archived. Just a thought.

  4. Happy 4th of July
    • Would you propose that the Smithsonian develop a mobile website or standalone application to achieve its goals?
     As per Altimetrik’s observation, we would recommend going with a native application to cater different mobile platforms and utilize the hardware API (Camera, Etc) of the device and to achieve the best user interface and performance. However, we can affirm once we have detailed use cases to study.
    • Would you suggest we utilize open source programming and reusable components?
     CodeIgniter, MySQL and Google analytics to analyze the metrics at the sever end.
    • How long would it take to develop the initial kiosk product?
     Looking at the broad picture we can develop the kiosk product during a time frame of 6-8 months. However, this would definitely get changed when a clear requirement is put across.
    • What methods and tools would you suggest for collecting usage metrics, especially given that the kiosks can’t be always connected to the Internet?
     We can go for Excellent Analytics with Google Analytics for offline mode reports which involves customization on the local DB front. We can pitch in with more information if we have an insight of the offline reports required at the kiosk.
    • What kind of content management system would allow the Smithsonian to alter content each year most efficiently?
     We suggest opting Drupal with MySql to have smooth functioning and better performance. Customization is required based on the further requirements in addition to that of basic features of Drupal.
    • What standards should the project employ to ensure future portability of the product and content to other platforms and uses?
     With standard mobile SDK’s and any portability inclined towards HTML5 can be attained with a minimal effort. In addition, our architecture and UI in CMS and mobile devices will be designed keeping in view the future challenges of integration and compatibility with the upcoming platforms.
    Please let me know if there are any clarifications

  5. Pingback: Mobile Contracting | Smithsonian 2.0

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