Designing the experience with Local Storage

Image courtesy of my sis

Design tooling for the internet is constantly changing. In 2010, an agency designer might have never left Photoshop during the course of their day, creating visual approximations of things later built with different materials. As we began to imbibe the premise that web design is product design, tools that don’t cater to this model became increasingly lacking. If we do aim to ‘design the experience’, then HTML5’s Web Storage could be a welcome addition to the toolkit.

The site I’m prototyping contains a login system. Once logged in, certain elements are exposed, certain elements are hidden, but most of it stays the same. Over the course of this project I had three approaches to how I handled communicating this part of the design.

Approach 1: That’s not my job.

Early on, with a bunch of other things to think about, I had just presumed this wasn’t my concern. Working login systems are usually built with some server-side manoeuvres, which is beyond the scope of my task and brain. This is a backend job so I‘ll leave it to the backend developer to handle this.

After a few iterations and a working prototype with the client, I received this within the feedback:

“Just to check, will the content of the website be accessible to non-logged in users with the exception of pricelist/pricelist download/advanced search?”

Although we were all in agreement about divisions of labour, the fact that this needed to be asked highlights a broken system. The client was forced to imagine how this feature would behave much further down the road or (even worse) when live. That sucks and we can do better.

Approach 2: I suppose it is actually my job to design views.

At this point I churned out two separate pages for those with alternate states (eg. browse.html and browse-auth.html).

I used Jade to hide and show partials depending on the variable. Whilst this helped my workflow, this was no help to those viewing it. A separate page was still complied and a separate page needed to be viewed, standing outside the user flow.

- var authorised = true
- var page = ‘browse’

Once implemented and on staging, I replied:

These pages are static files and a working login system hasn’t been implemented, so when clicking around, it’ll always be in the ‘logged-in’ state (apart from the sign-in / sign-up pages). Pages to outline how this would look when logged out [links to pages]

Apart from the run-on sentence, this is crummy for a number of reasons, but it took a few days of rumination for it to sink in fully why:

  • Clicking individual pages to check states of a page is a horrible and unnatural way to test a site.
  • It’s an unnecessary cognitive load for your client. There are better things for them to think about than understanding your model and divisions of labour within a web team (which changes with each group of people).
  • It’s full of jargon no-one cares about.
  • It’s an example of technology leading people, which leads to products that no-one wants.
  • Things can get missed. Websites are systems and the movement between pages (the flow) are as important as the pages themselves.
  • You might look a bit Mickey Mouse.

Approach 3: It is my job to design the experience.

I needed to figure out a way to mimic the behaviour of a working gateway without touching any server-side code.

The Web Storage API provides mechanisms by which browsers can securely store key/value pairs, in a much more intuitive fashion than using cookies…
Using the Web Storage API, MDN

There are two parts to Web Storage: Session Storage and Local Storage (check out that link above to get more details). Persistent states are closer to the behaviour of real login systems, so we’re going to make use of Local Storage. If you know your client is running a modern browser, you don’t even need to create any fallbacks.

function pageState(){
if (localStorage.auth === “true” && !== undefined ){
} else {
localStorage.auth = “true”;
localStorage.auth = “false”;

To explain this a little: when a link with the ID of ‘gate-signin’ is clicked, elements with the class of ‘authorised-hide’ is hidden and those with the class of ‘authorised-hide’ is displayed — on subsequent page loads.

If you are using a build tool, shove all of this into its own spoof.js to be scrapped when you hand it over.

It’s not how it looks, it’s how it works.

A lot designers (myself included) like to crow about how important what we do is. It’s not just how it looks, it’s how it works! If we dust or hands of important things like this then we can’t say we ‘designed the experience’.

Further reading

  1. Storing Data the Simple HTML5 Way (and a few tricks you might not have known) by Remy Sharp
  2. Local Storage has been around for such a long time that it was EPISODE 1 of the The Web Ahead!