Handheld 2013: the web's structure, expectations and data poetry

In this post I’m going to go through some highlights of Handheld 2013, which started of with the Welsh anthem being played on an electric guitar.

The conference

Generally, I much enjoyed Handheld. If I’m right, it was meant for people who make things for handheld devices. This year, it seemed, the speakers were mostly talking about the web. Which is good, and important. I can imagine some people missed talks about app development, but I didn’t.

A common theme of this year’s Handheld was communication with clients. These days, to make sure our sites work on a big range of devices, most web designers have started using responsive web design (RWD) in some way or another. With RWD, the uncertainty of what a web design is going to look like has become more apparent than ever. It was always the case that websites could not look the same in every browser, but now that we attempt to optimise for more than just a few desktop browsers, we have to come up with ways to explain this to our clients. This is a lot about building trust, confidence and that sort of thing, in addition to crafting great designs.

Having just recovered from co-organising my own conference , I may have had a biased view here, but there were some things I did not like about the practical side of things, including the waiting at registration and the somewhat too visible sponsor involvement.

Some talks I loved

The long web

Jeremy Keith talked about the web, a medium which he clearly loves (and who doesn’t?) He loves it for reasons such as its backwards compatible design, allowing for websites to be built in layers of structure, style and functionality. He also loves it for its URL system, providing a great and multi-purpose way for developers to make content available.

The biggest change in working on the web recently must have been the ‘mobile first’ paradigm, or ’content first’. According to Jeremy, you could work URL first, so that you start thinking about how to address the content before you even think about navigation. A clever way he mentioned to create a website from content is to break it into bits of content, components. Creating a library of components can help a lot. Jeremy created Pattern Primer as a handy way to show patterns and their HTML. And there is of course Anna Debenham’s book on style guides.

Content first also works through in code. You could put the content as (one of) the first thing(s) in your code, and the navigation at the very end.

Jeremy pleaded for progressive enhancement and rightly so. It almost ‘follows’ from working starting with (structured) content first. Progressive enhancement is often thought of being there for users that ‘have their JavaScript turned of‘. Although it does probably help those people, progressive enhancement has more to it. It helps anticipating those things that you did not expect, like a bug in one of your JavaScript files. It is about dealing with technology failing, rather than it not being supported.

Do not outsource your [website’s] performance to a third party.

A great example Jeremy mentioned is that of the social sharing button thingies that many sites use these days. The social media sites often offer those as a <script>-element that they ask you to drop in the middle of a page. Now if you imagine a Twitter widget in the middle of a page: if a user in China opens that page, it may stop loading when it gets to the Twitter widget, because Twitter is blocked in China so its script is never found. Your website’s speed is its most important UX feature, Jeremy warned, “do not outsource your performance to a third party.”

How to call your client an idiot without being fired

Andy Clarke’s talk was about how to communicate about design with clients.

We should avoid setting the wrong expectations

Old-fashioned ways of wireframing and design comps is that they might cause us to set the wrong expectations. When a client is shown a wireframe that already has some basic lay-out, as wireframes often do, they might expect the visual design to look like that lay-out. If the client is shown static design comps, they may assume that the final website will look exactly like them on any browser or device ever used.

What we design, Andy says, is not how we design, but how we communicate our designs. It does not matter which tool you like to create designs, as long as you make sure you set the right expectations.

According to Andy, the waterfall method is one of the main causes to problems related to expectations. To be able to set expectations right, we should start working in agile teams. That way, designers, developers and clients work together. In the process, everyone involved will know what is being worked on, and big surprises at the end are avoided. Working together, team members will feel more accountable.

To improve the way we design websites, we could improve the way we ask for our client’s feedback. If they work alongside designers and developers, we already avoided ‘the big reveal’. There are some other ways to improve the feedback process. At Andy’s company, they try to make it easier to control the feedback conversation, by insisting on face-to-face feedback, not allowing feedback by phone or email. They also try to control the environment in which the design is presented, by making sure everyone who can decide about it is in the meeting. They also find it important to leave their personality at the door: it is about the integrity of the design, not about that of the person who made it or gives feedback about it.

Data poetry

Brendan Dawes had a great talk about data. Now data can have two appearances, Brendan showed. There is the ‘raw’ format of just plain csv of JSON files in a text editor. They look boring and do not invite people to interact with them. They don’t look sexy. But when using data as an input for graphic design, it can come to life. Data represented in a graphical way can show give us new insights. It can help us see connections that we would not have noticed in the csv, although technically they were in there.

Data needs poetry

In his talk, Brendan showed heaps of examples of cool things he had done with data, including many new ways of representing data that was already there. These examples really nderlined his point that data ultimately comes to life when it is put in a graphical form. “Data needs poetry,” Brendan concluded.

And more…

And there were other talks I did not mention.

Syd Lawrence opened up with an entertaining live show, which involved people texting details to a phone number that were later used for playing ‘Guess who?’.

Ling Valentine argued that for information-rich web sites like her own it makes sense to stay away from responsive web design and use a simple, yet annoying mobile page to get people to your desktop site asap.

The prophet of web standards Jeffrey Zeldman gave his ‘ten commandments of web design’, often using his own A List Apart as an example. He loves the web as much as Jeremy does.

Mark Boulton explained how as a designer of RWD projects, you have to worry about content as it is such an integral part of what the design is made of. He illustrated this with stories about some projects he did, like Al Jazeera, CERN, UCL and World Skills London.

Jon Hicks talked about the pros and cons of icon fonts and showed how to make one. He also briefly discussed some alternatives to using icon fonts, like SVG sprites.

Eddie Machado made the Handheld site and explained how. I found he brought a lot of tools in that, imho, he could have done without (eg Sass for icon fonts), and ‘dirty’ tricks like </code>-elements inside a <div> instead of a <video> so that he could conditionally load them in a video.

There were not only talks at Handheld. There was also Bruce singing web standard classics such as ‘Like a rounded corner’ and a new (?) song callde ‘Living standard’, and Aral who announced the next phase of his Project Prometheus, now known as Indie.

Handheld conference was a great and varied day. There will be no Handheld next year, but the organisers have plans for another event. I’m going to keep an eye on this.