Context is king in mobile optimisation

There’s a war going on for the mobile web.

“War” is probably a bit dramatic though. To be honest, it’s probably more of a playground squabble. Always nice to start with a bit of exciting conflict though, eh? Anyway: to business!

How do you make a site suitable for mobile devices? Do you make your site responsive, so it changes layout as the browser window size changes, or make a separate mobile website that’s entirely optimised for mobile browsers?

Here’s an interesting article here that compares the two different approaches, using US presidential candidates as examples.

Image from Smashing Mag

So evangelising about different technologies and comparing implementations is all well and good – but decision about which solution to go with needs to be led by content and UX rather than design or technology. The article points at a super-long page on Obama’s site as an example of where things can fall down – but there’s nothing inherently wrong with long pages with mixed content on mobile; whether they’re appropriate depends on the content and the users.

Mobile technology is something the rest of the team may well have an opinion on too – as shown by the statement “the Web design world is entrenched in its own debate about how to address the mobile Web” – but they may or may not be aware of it. Without an objective overview you might end up with one or the other by default just because no-one thought about it properly.

I’ve seen a lot of stuff like this before, where someone has heard about the big new thing in web design and wants to build something with it – regardless of whether it’s actually the right tool for the job. That’s how you end up with mobile mega-menus that replicate a load of content that already exists on the page in a mobile-friendly format, and that’s likely why Obama’s site has that humongous page: no-one considered the impact of the technical decisions on the user experience.

These are some of the hardest decisions to get involved with as a UX person – partly because designers and developers like making their own decisions, but also because a lot of these kinds of decisions get made unconsciously. People often have an unconscious bias towards certain technologies or solutions and will make any number of strange decisions without really thinking about it if left to their own devices.

And how do you get involved at the right time? Well, that’s something I’m still trying to work out. I get asked about whether buttons should be red or green or blue or whatever all the time, when frankly I don’t really care. What I do care about is the hidden decisions that are being made, the small discussions within the team that affect whole pages – the ones that are decided before anyone realises and shut off discussion by virtue of being the “obvious” choice for people who prefer one technology over another.

So how do you keep tabs on what’s going on and stay involved without smothering the rest of the team? Where does the middle ground lie? I’ll let you know when I find out.

Abstraction and Wireframing

Before my current incarnation as a UX Architect I was a Flash developer. I spent five years coding all kind of games, sites, and apps, and gradually progressed from simple bits of script to full-on applications and fully abstracted object-oriented code.

My day job now is focused on less technical work like research and wireframes, but I think during those years of coding I learnt some interesting concepts that I’ve carried through to this new role.

I recently wireframed a few simple online art activities for children which involve adding shapes to a canvas, animating a simple figure, making a postcard and so on. None of the activities are very complicated, but as we discussed time estimates and functionality my old developer habits started kicking in.

I found I’ve been thinking about how I’d go about building these apps, which led on to thinking about how that affects the how I wireframe things. As I did so, I found some interesting parallels and insights – so I thought I’d share them here.

Continue reading