5 tips for designing interactive touch experiences

On a recent project, Richard Askew built a touchscreen experience that moved away from traditional web principles. Here’s what he learnt

Recently, my company — Askew Brook — and another local design company won a contract to work on an interactive touchscreen installation. Although it wasn’t something we’d had a lot of experience of, I was keen to take the project on as it used my web development skills to solve a different kind of problem, in a different environment to what I was used to.

First of all a bit of background: our client was a theatre in Leeds that had a very strong and rich history of attracting the leading acts of their time to the theatre. We decided to create a variety show experience that could be built by the user, who in doing so would unlock the theatre’s history. You can take a look at the final installation in action at http://www.askewbrook.com/city-varieties.

The build was different from a traditional website project in a number of ways:

  • It wouldn’t be available outside of the theatre
  • The kiosk had a fixed screen resolution
  • The kiosk could be moved, so an internet connection may not always be available

Was it possible to still build this thing as we would a website? Here’s a few things we learnt about designing for touch …

1 Consider the placement and size of contact points

As anyone who has designed and subsequently viewed their website on a mobile device knows, the placement and size of contact points is important. And — contrary to what you might expect — bigger isn’t always best.

After the first round of testing we made each contact point bigger. We included controls that managed the overall experience and gave the user the ability to start, clear or even end the show. These were placed around the edge of the screen and made large enough to easily identify and touch — not only making the installation simpler to use and helping the user feel like they knew what they were doing.

The interesting part was at a lower level. There are a number of interactions the user needs to complete in order to build the acts, click through timelines and so on. We found that the contact points for these functions could remain smaller as long as any other actions the user needed to take were close by. Making them large and moving them away from that specific area made everything more difficult. That’s Fitts’ Law in practice!

2 Manage expectations

These days, when someone says ‘touchscreen’ , you automatically picture a tablet or a smartphone. We weren’t dealing with those types of touchscreens in this project, but — crucially — people were expecting our creation to react in the same way. Tablets and smartphones are so ingrained in our thought process, and feel so natural, we automatically apply those mental models to every touchscreen device we interact with.

There are plenty of JavaScript libraries that provide these types of functionality, but we found they were never quite as good as the real thing. So we didn’t give the user an infuriating experience, we decided to just use what was available with the hardware: they could tap. That was it — no swipe or pinch and zoom. We made sure that contact points looked like buttons and highlighted them when we needed an action from the user.

3 Keep things practical

Our final solution relied heavily on animations, in a Monty Python style, of the variety performers. One of the reasons I really wanted to take the job on in the first instance was the opportunity to work with complicated CSS3 animation in an environment that we could 100 per cent control. As time went on though, a much simpler and more obvious solution presented itself — a good old GIF. It isn’t as sexy, but from a practical point of view it was a great help.

The decision to use GIFs suddenly meant that each member of the team, be they design or development, could create and manipulate the animations quickly, dramatically speeding up the project. It also helped when creating prototypes, as we could complete the most visually interesting parts first, and use these to help communicate our final vision to the client.

4 Make it public-proof

We still needed to load resources, but the fact that the touchscreen unit could move meant that we couldn’t rely on an internet connection. If you’re in a similar situation, make sure you don’t rely on any online service — load all JavaScript, font libraries and whatever else you need locally. This is an obvious one, but one I profess caught me out and caused unnecessary panic on the morning of delivery!

At this point we had completed the build, but our solution was effectively still a browser on a PC — we had to make it public-proof. There are a number of options available for Kiosk software, but we decided to look to other alternatives.

We essentially needed the following:

  • A local website to open when the touchscreen unit is turned on
  • A fullscreen web page
  • To stop users from accessing the system or the address bar to visit unsavoury websites

We found we could create a batch file that would start Apache and launch Google Chrome in Kiosk and incognito mode on startup. It meant we could keep costs down and that there wasn’t another layer of complexity for the client’s IT team.

5 Use desktop sharing services for remote troubleshooting

We needed a way to access the touchscreen remotely so we could troubleshoot and fix bugs during the testing period. Obviously, we need the touchscreen to be networked to achieve this, and there are a number of options available. We opted for Chrome Remote Desktop to keep things contained, but any desktop sharing service would work.

Reflections

There are always things that could be improved upon, but the biggest lesson we learned from this project was to embrace the unknown. We don’t take on projects if we aren’t convinced we can deliver. Although we hadn’t done this before, we utilised what we knew and pushed it to new areas — there is always a first time for everything.

Richard Askew is director of Askew Brook, a web design, consultancy and training company based in Scarborough and London. He also teaches web design at the University of Hull, speaks at web and design events and is Chair of the East Coast Branch of the Federation of Small Business.


This article originally appeared in issue 265 (April 2015) of net magazine.