Every now and then, I get the opportunity to unleash my designs in the general direction of real users. This is usually done outside the technological comfort-zone of the office, giving no guarantee of a consistent internet connection, which led to some previous exploration of offline caching.
While obtaining feedback on flat, static mockups is often quite useful, I’ve found watching users directly interact with a working prototype to be far more revealing. HTML, CSS and Javascript can go a fair way to simulating an experience on a single page, but as soon as you introduce a multi-page experience, holding data from page to page can prove tricky without a reliable server connection.
Bridging the gap with Web Storage
Recently I have been working with a large membership organisation to improve their signup process (the results of which should be live in the Autumn). Part of this work involved testing a variety of multiple-step forms, in an attempt to gauge which gave the most pleasant overall user experience but also whether some of the more complex interactions we were proposing were clear to users.
To ensure that the final summary step was relevant to the users testing the interface, we wanted to capture their input throughout the process and serve it to them to double check, instead of relying on irrelevant placeholder data that could be subject to less thorough scrutiny.
The Web Storage API provides two ways to store simple data which are ideal for this. Both localStorage and sessionStorage allow you to hold strings of text, which can be recalled later on. In the case of localStorage, the data lasts as long as the user doesn’t clear their cache, but sessionStorage only lasts as long as the current window or tab is open – perfect for testing a process with lots of different users.
Scripting a solution
To implement this, I wrote a simple bit of Javascript to drop into a prototype which captures the data on each page, saves it to sessionStorage, recalls it on the summary page and can clear the cache when the process is restarted.
For the more technically inclined, I’ve since tidied everything up a bit, expanded the list of supported fields, added a few configuration options and popped it up on Github as a micro-library of sorts for user testing forms (although this could arguably extend to other forms of user input like search fields).
Ones to watch
Data types
It’s worth noting that Web Storage stores all data as strings, so even if you have numerical data from a range or number input, Web Storage will return it as what is essentially text. While you’re testing, this is probably not a huge issue, as the data will most likely be used for confirming user input later in a process, but for production use or calculations, a level of conversion will need to be done.
Passwords
In a way, this is linked to the last point. Any data from password fields handed to Web Storage will be stored as easily visible strings of text. The script I’ve written replaces them with asterisks by default before storing, so your users passwords (if they choose to use real data) are a little safer, but storing passwords in this way is by no means recommended for anything other than quick testing. In an ideal scenario, you would validate the data entered before it is submitted, then ignore it completely. Wouldn’t it be nice if I had an option which did that…
Food for thought
In what is becoming somewhat of a common theme, this was mainly a personal learning exercise, and there are, in fact, people who are already tackling this in they own ways.
Mozilla have released localForage, a far more fully-featured library for working with not only Web Storage, but IndexedDB and WebSQL for the browsers that support it.
If you’re even more daring, Javascript frameworks like Ember, Angular, or Backbone can be extended to use localStorage, but they lean more towards production-ready web app territory.