Category Archives: Industry

Building things for the One Web

Naga IT Services
Filed under: Industry, Reading, Responsive

There were a few articles doing the rounds recently that touch on some deep, fundamental, aspects of modern day web development. They had some common themes: the importance of being flexible and that this stuff is hard (developing for the multi-device world). We’re still finding our feet, and one area that’s seeing lots of change is deliverables.

Given the fluid nature of the web, what are the right deliverables for designing and building a web site? How can we show work in progress on a web site without showing the whole, fluid, web site? Whose job is it to decide what we show, how many deliverables there are, and to explain why they’re different from “traditional” deliverables?

Continuum

Jeremy Keith’s Continuum and Ethan Marcotte’s response: Platformed both discuss the squishiness and universality of the web. Jeremy pointed out that despite the fact that there are differences in browsers and operating systems we can still support every browser that can connect to the internet by using a strategy of Progressive Enhancement.

the unevenly-distributed nature of browser capabilities is not a bug, it’s a feature.



you can provide universal access to content and tasks without providing exactly the same experience for every single browser or device. That’s not a failing of the web—that’s its killer app.

He points out that it’s our responsibility to explain this diversity of consumption of the web, to educate clients who don’t understand.

Explaining your design work is part of your design work. It’s the same with web development.

Mike Monteiro often talks about this, too: What Clients Don’t Know (and Why It’s Your Fault). Ethan added to this, saying that because of the fluid, chaotic, nature of the web as a design medium:

we play the long game in this business.

The web is One Web, and it does (and will) go everywhere that it can. Designing and developing something that’s pixel-perfect across a small range of today’s browsers and devices already puts you behind the times. We need to play the long game and build for the unknown: well-formed and structured HTML with Progressively Enhanced CSS and JavaScript that lets our sites go anywhere.

Deliverables

The next day I picked up Laura Kalbag’s excellent article: Delivery Logistics, on A List Apart.

In web design, the deliverables we create are rarely the final product; they’re rarely the thing we’re going to “put live” to any users.



We need to stop acting as though deliverables are the be-all and end-all of web design, and treat them as the communication tool that they are.

This is really important. Style Tiles are an excellent example of this. They provide provide a catalyst for discussions: interface elements without layout, so that we can focus on pieces that make up the design and the layout. The deliverables along the way are essential to the process: we’d never make it to the end, or build the right thing, without things like Personas, Customer Journey Maps, Style Tiles, and so on. We should be treating them more like signposts to the end product than the end products in and of themselves, though.

Even the web site (the “real” deliverable), once it’s gone live, is in a state of flux: content gets updated and moves or breaks things; styles get updated for new branding elements.

Closing thoughts

It’s an ongoing process of discovery and learning. One thing I do know is that, as an industry, our tools need to keep changing to keep up.

Building a mobile and a desktop prototype and testing them extensively is great (and very practical), but it’s important to remember that these are just two very thin slices of how the site will be experienced: browsers accessing the web have a lot of dimensions to consider. More on that soon.

Of course there’s a balance to be had. It’s impossible to test across every configuration, and impractical to test across large numbers. It’s also true that many of the lessons learned at these two points on the spectrum can be applied widely. I think that it demonstrates the importance of getting into testing with browsers earlier rather than later, though.

Responsive Strategy

Naga IT Services
Filed under: Industry

A few days after I was thinking about frameworks, Brad Frost published an article about Responsive Strategy. It’s a solid summary of different approaches to building a responsive site. In it he pulls together the various ways and looks at the pros and cons of each.

Mobile First

My favourite (and how we do it at Flow) is Mobile First: build a new Front-end from scratch, and start with mobile. This approach is difficult and can be lengthy, but there are many benefits for the site, the business, and the developers. One important point is that it makes it easier to build a more Future Friendly site: preparing your site to go anywhere.

Second prize

This approach isn’t possible for every project, though. Another viable option is to update an existing m dot site to responsive (like the team at the BBC are doing), with the goal of eventually “turning off” the desktop site. One of the pros that Brad lists (emphasis mine):

Learning to be flexible – Designers can learn how to think more fluidly. Developers learn about the myriad quirks of old Android devices. Management can learn to let go of pixel-perfection. A responsive m-dot can serve as an important sandbox for learning.

Achieving pixel perfection was always a myth, something that designers and developers forced on to the web, but it’s become obvious that the old ways of doing things are broken. Even across the desktop, the number of browser and operating system combinations make it impractical to have the design looking identical across them, even if it that were a desirable goal (Pro tip: it’s not).

Piecemeal

The trickiest way of doing a responsive site is bit by bit. Although it lets you get quick wins by making the most frequently visited pages better, the continuity problem breaks this approach for me. The flow from old to new pages runs the risk of confusing the user, at best making them wonder what’s going on, and at worst making them think they’ve left the site and gone somewhere else. This problem is exacerbated if the move to responsive is also accompanied by a design realignment (Good Designers Redesign, Great Designers Realign).

Conclusion

Doing things Mobile First, from scratch, is the the best way, but it’s not always possible. Legacy code and problematic Content Management Systems sometimes get in the way. Starting from an existing mobile site can be a good alternative, and will help you learn some important lessons along the way. Be wary of approaching a responsive redesign piece by piece: you might confuse your users.

Usability Testing

Naga IT Services
Filed under: Industry, Process

Recently I ran a day of usability testing for a client’s native application. It wasn’t the first time I’d taken part in testing, but it was the first time I’d run the tests myself. It was fun and exhilarating. The first one of the day was also pretty scary; at least it was until it started. I’m already sold on the benefits of usability testing, but the experience reinforced my feelings about it.

I asked for feedback from my colleagues afterwards, and tried to think critically about how I’d done, and how I could do better next time. I think that I established a rapport with the participants quite well. I found it easy to find interests that we had in common, and to chat to them about those.

In terms of improvement for the next one: I need to stop being so helpful. Part of testing is letting the users struggle for a bit, to see where the problems and sticking points are. I was a little too eager to help or to ask questions about what they were doing. It’s okay to let it get a bit awkward. Also, my questions were sometimes a little too leading, or I would finish their answers for them. I need to watch that, and just be more patient.

The best bit

My biggest take-away from the day was the same as the other tests I’ve been involved with: how great it is for the clients. Seeing users with the app is a real eye-opener. They’re very good at showing you that things aren’t as obvious as you think (or at all), and at helping you realise that what’s important to you may not be the same thing that’s important to the user.

Running through the results with the client the week after the test was also great. Together we came up with a laundry list of changes that they could make to their app, and discussed prioritising them. On the one hand this could be seen as bad: lots of work to do. But the flip side is more important: lots of ways to improve the app, and make a real difference to the user experience. I can’t wait to run my next set of tests!

Mobile stats for January 2014

Naga IT Services
Filed under: Industry, Responsive

As part of research for something I’m working on, I plucked out some statistics for mobile vs desktop for the world, and for South Africa. The numbers below are a guide to the state of play as at January 2014. The mobile / desktop split is a bit of a false dichotomy, but it’s a useful shorthand for small things vs big things, new things vs old things.

Worldwide web usage is about 24% mobile vs 76% desktop. In South Africa, it’s more like 63% mobile vs 37% desktop. The tipping point (when it was 50 / 50) was around October 2013. It’s important to remember that many users in SA are mobile-only: they don’t have access to a desktop computer with an internet connection.

In terms of the split of operating systems, the largest is BlackBerry with about 34%. Android is at about 20%, as is Series 40 (Nokia’s featurephone operating system). Symbian (Nokia’s newer OS) is about 6%, and Apple’s iOS is at about 4%.

Blackberry and Nokia are the handset leaders, but Samsung is also popular, taking around 15% of the handsets in SA.

Some sources: