Memory can be ruthlessly selective, even with peak experiences. Digital artifacts are ruthlessly undiscerning and long lasting. My client had assembled over 400 photos, videos, diary entries, social networking posts which documented an extraordinary journey. The client wanted them all aggregated into one viewer which would not only display the digital artifacts, but geo-tag them so that the reader can follow along with the story and the location.
I observed six participants who fit the target market of aspirations to adventure travel. My testing was looking for any counfounding concepts or workflows that would prevent them from recognizing what the application was, and how to work with it. I used those observations with builds of the system to inform how the system behavior would evolve. The goal of the application is to allow the user to explore a particular geography within the context of a specific journey. I will continue user testing as I implement future functionality from the backlog.
The learning opportunity for me was working with the Google Map Javascript API and the Google Street View API, and working with JSON for the first time. The entire application is a single 'page', and all data is sourced from the JSON file by an index set by user interaction with the markers on the map or with the triangular controls which invoke the click event for the next or previous marker. The most gnarly problems were dealing with race conditions between the Google API callback and the availability of the full JSON data set. In case you like code, all of this is available at https://github.com/uxcourt/uxcourt.github.io/tree/master/ozbike.
The app initializes displaying the map, instructive text, and the user's digital media associated with that point in space.
Where available, Google Street view allows the user to explore the area themselves. Particularly impressive on a tablet because of Street View's awareness of the device accelerometer.
The user has controls to only display digital media.
The application supports video displays.
Street view allows for some spectacular surprises.
The choices of XMLHTTP for data and multiple panel display means the functional desktop solution won't ever work well on mobile.
One of the last usability tests on the desktop version suggested that initializing the application with a full screen map view might be useful.
When the user clicks on a marker, details about that marker are shown, along with a method for navigating back to the full screen map view or to previous or subsequent markers.
When the user expands any of the media associated with the marker, that media is displayed full screen, along with a method to contract the media back to the marker details page.
Since the overhaul to the tech stack is non-trivial, I've prototyped an interaction for further testing before committing to the engineering effort. That's exactly why UX design investments pay off! This prototype was in Axure RP 8 to explore the interaction model of the proposed mobile design. Note it is Axure, so you'll need to be patient after each touch on the screen. This prototype was built for use on iPhone 6. It does not support rotation, so view it in portrait mode. The purpose of this prototype is simply to validate the basic interaction model.