Virtual Reality on a Dime

Photo of a Google Cardboard viewer
“Assembled Google Cardboard VR mount” by othree – Google Cardboard

Google’s virtual reality efforts are getting a lot of press these days, so what’s all the commotion? For the past two years, Cardboard has been the flagship of Google VR. If you’re new to the world of virtual reality, Google Cardboard is essentially housing made of cardboard that turns your smartphone into a virtual reality viewer. Similar products include Oculus Rift and Samsung’s Gear VR, but they come with a hefty price tag. A Cardboard viewer, on the other hand, will run you about $20 or less; Google even provides the blueprints if you want to create your own from scratch.

Photo of a girl looking through a View-Master
“Black-Ta” image from Flickr user Steven River

If you’re still scratching your head, think back to the good ‘ole View-Master. With Cardboard, you’re also looking at images through a viewer, but the experience is more interactive. Instead of viewing stagnant images, you can watch 360-degree videos that respond to your movements. For instance, in Bjork’s 360-degree music video, you’ll see Bjork standing on a beach in front of you, but you can also look up at the sky, down at the sand, even behind you. Pretty impressive stuff, eh?

Unfortunately, creating a 360-degree video isn’t quite as affordable as viewing one. GoPro has a VR camera rig called Jump that can be yours for the low low price of $15,000. That said, you can create your own 360-degree still images for free with the Google Street View app! In Google terms, these images are called “photo spheres”, or a series of images stitched together to recreate a 360-degree experience. I took one of my office and the process was incredibly simple; the app prompts you to move your phone around as you take photos to capture your whole environment. The final product isn’t 100% seamless, but the price is right and sharing is remarkably easy. If you’re eager to try out Google Cardboard, check out the #360Video YouTube channel. Even without the viewer, this will give you an idea of what we mean when we say virtual reality.

In addition to Cardboard, Google recently announced a new virtual reality viewer platform called Daydream, set for release this November. Daydream is considered an upgrade to the existing Google Cardboard viewer at more than double the price ($80). If you’re curious about VR, Cardboard remains an excellent choice for beginners. Daydream may be the latest model, but it’s unlikely to rival the simplicity, DIY quality, and accessibility of Cardboard.

If you’re interested in emerging technologies and digital creativity, join us on Mondays this semester at the IQ-Wall for Maker Mondays workshops, presented as part of the Scholars’ Commons Workshop Series – yet to be covered are stop-motion animation, internet of things and logo design:

Maker Mondays series event information

You might also want to check out upcoming events in the Digital Tools and Visualization Methods for Humanists series, which will be covering a variety of topics from 3D Scanning and Printing to IQ-Tables to much more.

Making Mobile Meaningful: Digital Collections for Mobile Viewers

Julie Hardesty is the Metadata Analyst/Librarian at IUB Libraries.  She is interested in many aspects of digital libraries, particularly those pertaining to making it easier to find and do things on the Internet.  She is reachable at jlhardes at iu dot edu.

This blog post is based on a recent Digital Library Brown Bag presentation I gave, which is based on a poster I presented at the Digital Library Federation Fall Forum in 2012 in Denver, Colorado (and somewhere along the way, the old lady swallowed the fly and I don’t know why and… well, you get the idea).  Back when all of this started I was a User Interface Design Specialist at Indiana University so don’t judge based on my current Metadata Analyst/Librarian job title – this post really does contain mobile design info.  If you prefer to listen rather than read, you can review the Digital Library Brown Bag presentation recording (guaranteed to be less succinct and interspersed with a lot of “um”s and “where did my cursor go?”s).

There’s a lot of interest in how to deal with mobile and how much we should be considering mobile in our effort to provide online resources through the Indiana University Libraries.  I don’t have all of the stats but I do have the following: we’ve seen a steady increase in mobile use over the last 2 years, at least, for the web site that provides access to the IU Libraries digital collections and services.  The following charts reflect user agent strings that identified mobile devices (like iPhone, iPad, Samsung, Nokia) gathered from web server logs.

Mobile Browser Use Graph

And it’s a definite increase when compared to overall use of that same site (please ignore the October-November 2011 blip – our server administrator was using a monitoring program from his desktop that spiked our usage stats on the site for those months).

Mobile and Non-mobile Use

There are 2 things I would like to point out here: 1) overall use of this site over the same 2-year time period was steady or even declined a little and 2) everyone went on vacation in August 2012, regardless of the device they were using – congratulations, you’re doing it right!

So we have mobile users and it’s worth it to consider what those users are experiencing when they arrive at our digital collections and, more importantly, what they need.  And since this blog post is all about action, I’m just going to run with it and tell you what I did.

The technique I chose to apply was the single CSS media query.  This technique causes devices up to a certain screen size to display our collection sites differently then everything else.  I focused on handheld mobile phone-sized devices (iPhone size and smaller).  The digital collections to which I applied mobile optimization worked well with tablet-sized screens already so I made the call to treat tablets and desktop browsers similarly and smaller handheld devices differently.

There are multiple techniques for providing a different mobile experience:

  1. Mobile application (think Angry Birds or Bejeweled) – mobile device-specific applications that are downloaded through an app store and are installed to run on your iPhone/Android/Windows phone/whatever.

    Yes, this is me killing it at Bejeweled with a super-gem on Level 2. I’m that good.
  2. Mobile version of a web site – this involves creating a separate site with different programming (and a different URL) to provide a mobile user experience.  Out in the world, examples include Best Buy’s mobile site and Amazon’s mobile site.  Within IU, you can find examples such as IU Mobile and IUB Libraries Mobile.  I do not guarantee that these examples will stay valid for very long as mobile delivery changes quite often, but for the most part you can notice these by a different URL (with m.domain or domain/mobile) and the fact that you can often view these mobile versions in a desktop browser.

    IUB Libraries Mobile
    You can see this same IUB Libraries Mobile site in your desktop browser.
  3. Responsive Design – What I consider the ultimate goal in mobile optimization, this technique takes a single site and uses CSS to change the design as the screen size changes (from full desktop browser to mid-size tablet to small-screen mobile phone).  Many implementations of this technique allow you to see its effect just by changing the size of the browser window on your desktop browser: is an oft-cited responsive design from “out there,” A List Apart provided an early example of how this can work to show text and images, and here at IU, the IU Communications department has implemented a responsive design for its site.  Templates with a grid-style layout are available to help create this type of design.

    IU Communication
    IU Communications shown on a desktop browser and on a handheld mobile device.
  4. CSS Media Query – This technique could be thought of as the first step towards Responsive Design or a single view of a responsive-ly designed site.  It involves checking for a certain device size and then applying a set of pre-defined styles or an additional external style sheet.  This is the method I can really talk about since this is what I did.

The mechanics to apply a CSS media query are pretty easy, in HTML/CSS terms.  The first necessary part is the <meta name=”viewport”> in the HTML header:

<meta name=”viewport” content=”width=320, initial-scale=1.0, user-scalable=yes”/>

Generally referred to as the viewport, it was something that Apple came up with for Mobile Safari to allow developers to control the size of the window being viewed (very simplified short story here, follow the viewport link for a great explanation from  In the above example, the mobile browser sets  the window to a width of 320px, initial scale is full size, and the window is zoom-able by the user.  Most other mobile browsers have latched onto the viewport and it is now pretty much essential for mobile optimization.  Non-mobile browsers (i.e., desktop browsers) ignore the viewport because they don’t know what to do with it, so it doesn’t cause any problems and can be included in the header of a site without any concerns.

The viewport is also the easiest piece to forget because it just needs to be there and there’s nothing else to be done with it.  If you ever think you have everything in place and the mobile browser is still showing a screen that is way too zoomed out – 99% of the time you forgot the viewport.

The next necessary part is the actual media query and it can be included a couple of different ways – either in the call to an external style sheet or within the style definition itself.  Here is a media query within the style definition:

@media only screen and (max-device-width: 480px) { }

This can be used inside the <style> element in the HTML of a page or it can be used for a section of styles within an external CSS file.  Another way to accomplish this definition is to use the media attribute on a link to an external stylesheet:

<link type=”text/css” rel=”stylesheet” media=”only screen and (max-device-width: 480px)” href=”small_device.css” />

This only applies small_device.css in the event that the media attribute (the media query) is true.  This particular media query is checking that the media type is screen (as opposed to print, braille, or other media types that can interpret HTML and CSS) and that the width of the device is no larger than 480px.  Include this as your final CSS and it will effectively apply your mobile styles.

The combination of the above viewport and media query is to apply a particular set of styles to mobile devices up to a width of 480px.  Setting the initial width to 320px fits well in the portrait mode of most iPhone, Android, and Windows mobile smartphone devices.  Applying the mobile styles up to 480px then covers landscape mode.  Beyond those two pieces of HTML/CSS are a series of design and usability decisions that can turn a site into a functional thing (like Pinocchio, only completely different).

My first round of mobile optimization happened for a set of digital collections of TEI-encoded texts: Victorian Women Writers Project (VWWP), Brevier Legislative Reports, and Indiana Authors and Their Books.  Each of these sites is distinct, but all are based off of the same software (eXtensible Text Framework (XTF) from the California Digital Library) and all offer basically the same access (full text-encoded access with searching and browsing).  We combined the development of these sites as much as possible in a move to create an electronic text service at the IU Libraries for encoded collections such as these, and the mobile optimization worked the same way.  I figured out what worked for one collection site and then applied the same changes to the other two collection sites.

I also worked out mobile optimization using CSS media queries for Image Collections Online (ICO), an online exhibit site for library and archival image collections, and War of 1812 in the Collections of the Lilly Library, another online exhibit using Omeka to bring together various digital collections to accompany a physical exhibit of War of 1812 archival materials.  These are both sites with image-based content as opposed to text-based content.  Keep that in the back of your head for a sec.

Victorian Women Writers Project Mobile
Caption: Corelli, Marie. The Mighty Atom. London: Hutchinson and Co., 1896. Victorian Women Writers Project. Indiana University Libraries, Web. 15 March 2013. <
Brevier Legislative Reports Mobile
Caption: Brevier Legislative Reports. Vol. 5. Indianapolis, Ind.: W. H. Drapier, 1861. Brevier Legislative Reports Digitization Project. Indiana University Maurer School of Law Library and Indiana University Libraries, Web. 15 March 2013. <
Indiana Authors and Their Books Mobile
Caption: Stratton-Porter, Gene. A Girl of the Limberlost. New York: Doubleday, Page & Company, 1909. Indiana Authors and Their Books. Indiana University Libraries, Web. 15 March 2013. <
Image Collections Online Mobile
Caption: Image Collections Online, Indiana University Libraries, Web. 15 March 2013. <
War of 1812 Mobile
Caption: War of 1812 in the Collections of the Lilly Library. Indiana University Libraries, Web. 15 March 2013. <http://www.collections.libraries.iub.

My first thought when considering mobile is, “What do people want to do on this site from a mobile device?”  Mobile users aren’t in the same situation as someone sitting at a desk in front of a computer.  They are holding the device in one hand and either using the other hand or – if they are more digitally dexterous – the same hand to select and scroll and type.  These are skills that make creatures without opposable thumbs super-jealous, but it also means they have their hands full.  And it’s not just with the device either.  Mobile users on smartphones and smaller mobile devices are often on the move, possibly distracted, probably in a hurry.  Or bored and standing in a line.  Either way, they are not in a situation where they want to learn – they want to do.  They aren’t interested in research, they want access and quick answers (or quick entertainment).  This is supported by recent Pew Internet Research findings from December 2012 that report most mobile connections to libraries are to look for items, find basic information about the library, or renew, reserve, pay fines, and download e-books.

In terms of these digital collections, I think this translates to focusing on the content for mobile users, either the text or the images.  In the case of the electronic text collections, I considered what I was doing as the equivalent of making an e-reader – providing the full-text display in an easy-to-read font size and with simplified searching and browsing.  This meant no page images and making it easy to ignore things that are not the full-text (like the table of contents – I kept it there but it’s collapsible).

For ICO and War of 1812, my dream was to make them as easy to flip through as the photos on your phone.  I didn’t have quite that kind of time to devote to mobile optimization, but I did make a choice in ICO to push the facets menu below the images that display on search result and browse pages.  That keeps the images top and center on the mobile version of the site.  I also lucked out that our preset thumbnail size for image derivatives just happens to be 200px wide – big enough to be nicely viewable in portrait mode but not too big for my layout goal (320-480px).  My dream also didn’t take into account context, which is important for the War of 1812 site.  The likeliest mobile use case for that site is when patrons are in the Lilly Library walking through the physical exhibit.  A patron encounters an item on display among hundreds of, say, a map of New Jersey.  Jumping on a mobile phone and visiting the War of 1812 web site, one can potentially find more information about that map from the narratives presented on the site and the digitized version of the map than from standing directly in front of the physical object.

Since the narrative and text of the exhibit site are just as important as the images and information provided with them, the navigation for the War of 1812 remained above the main content.  Additionally, Omeka added some software wrinkles that I couldn’t iron out in time so the navigation menu does not collapse.  It’s better than not having a mobile-optimized version of the site, but it didn’t quite come together like I wanted.

Other design decisions that were common across all of these sites were removing features that were too cumbersome to use on small devices: multi-field search forms (Advanced Search) and the Simile timeline that we added to both VWWP and War of 1812.  Removing images can also improve performance over slower network connections, so home pages were simplified this way as much as possible.

So a single (somewhat determined) person with a good understanding of CSS can make mobile meaningful. But more is involved than just the technical details.  Understanding what mobile users need from a site makes the difference between a mobile site designed for a device and a mobile site designed for a person.

Web Accessibility in the Library, Part 2

Thanks for joining me again!  If you are just checking in, we’ve been discussing a lot about pie as well as some tools you can use to evaluate the accessibility of an online library resource you want to offer in your collection.  We covered heading structure, unique links, and color contrast in Part 1 and we’ll continue with 4 more accessibility issues that you can evaluate using Firefox plug-ins.

Alt Attributes on Images

Why Evaluate:  Providing alt attributes on images (literally, the alt=”something” inside of an <img> tag) puts text in place to describe the image.  This is useful for screen reader users who can’t see the image so they know why it’s included in the content.  Alt attributes on images are also useful for everyone.  In the case where something goes wrong on the Internet (I know, what could go wrong?) and images won’t or can’t load, the text from an alt attribute shows in the place of the image on the page, giving any user in this situation information about the image and why it is included in the content.

Tool to use: Web Accessibility Evaluation Tool (WAVE) (plugin for Firefox)

WAVE installs as a toolbar and is available under the Tools menu on your browser after installation (Firefox restart required).  This tool, from the WebAIM group, does a pretty good job of identifying multiple accessibility issues, including missing alt attributes on images.  Click the “Errors, Features, and Alerts” button in the toolbar and the page you are viewing in your browser will be reloaded showing various icons all over the page.  The ones you want to watch out for are icons in red.  Mouse over any of the icons and you will see information about the error (red icon), feature (green icon), or alert (yellow icon) that is indicated for the element the icon is near on the page.  Missing alt attributes are indicated by a red icon with a white diagonal slash.

Picture of pie from Wikipedia ‘pie’ entry showing WAVE icon for missing alt attribute.
This pie is sad because it has no alt attribute. Or whipped cream.

If you see these, you’re probably on a page that doesn’t even have valid HTML and the likelihood that the page is accessible has just plummeted.

Screenshot of Wikipedia ‘pie’ entry with WAVE icons.
This is your Wikipedia pie on WAVE. Any questions?

TIP:  To return to the original view of the web site without the lovely WAVE icons, use the “Reset Page” button in the toolbar (also available under the Tools menu for WAVE). Reset Page button from WAVE toolbar.

Continue reading “Web Accessibility in the Library, Part 2”

Web Accessibility in the Library, Part 1

Julie Hardesty is the User Interface Design Specialist in the Digital Library Program, a partnership between the Libraries and University Information Technology Services at Indiana University.  She is also located in Wells Library, but not within pie-throwing distance, unfortunately.  She does like pie, though.  Julie is a huge fan of web accessibility and generally making things on the Internet easy to understand and use.  She is reachable at

Would you know how to tell if an online resource offered in your library is accessible for screen reader users or keyboard-only users or users on mobile devices?  Many vended online library resources suffer from inaccessibility and, as a result, a lack of usability for anyone who tries to use them, regardless of the device used for access.  As the gatekeepers to scholarly information at Indiana University, we have the power to make choices and recommendations that will improve the access of our online resources as well as the overall experience that is discovering and using information at IU.  The following are seven ways to take stock of the accessibility of an online resource (and the tools to help you measure that stock).  Consider using these tools the next time you are reviewing a resource for purchase or recommending a resource to conduct scholarly research.  Disclaimer (or support): these tools are only suggestions – there are others available but these are the tools I like to use.

ALA Accessibility Challenge:  If you are going to ALA this month in Anaheim, California, ask a vendor or two on the exhibit floor about the accessibility of their products.  And don’t take a VPAT for an answer (it’s just a form, it does not guarantee that what they are currently trying to sell you is, in fact, accessible).  Ask about headers and unique links and form labels and color contrast for the site they have on display in the exhibit (see details below).  These are things that affect accessibility and anyone trying to sell you a web site should be able to discuss them.

Heading Structure

Why Evaluate: The list of headings (h1 – h6, in HTML lingo) is a shortcut that screen reader users can use to “scan” the page for content, similarly to how a sighted user would scan a page.  Arguably, a lack of heading structure on a page can make things difficult for a sighted user to make sense of the content as well.  If headings are considered within the content, the content is more likely to be broken up visually and the focus for the page will be more obvious.

Tool to use: HeadingsMap (plugin for Firefox)

HeadingsMap for Firefox will appear under your Tools menu in the browser once installed (Firefox restart required).  Triggering this plug-in will open a column on the left side of the browser window showing a hierarchical list of headings on the page.  Anything in red/pink indicates a heading that is out of order.  This tool makes it very easy to see the headings and their hierarchy and any potential problems.

Headings list shown in HeadingsMap for Wikipedia ‘pie’ entry.
Pie might be important here.

Continue reading “Web Accessibility in the Library, Part 1”