When the news goes sideways
Things we learned from a UX proof-of-concept at BBC News
Recently we’ve been wondering about the future of article pages on the BBC News website. We publish around 500 new ones every day in 33 different languages, and more and more (especially for audiences outside the UK) they are the way people arrive on our site, whether via social shares or search results.
The thing is, their layout hasn’t changed much in 20 years, which in web terms is to say since the dawn of civilisation. As my colleague Jim pointed out, check out a story from 1997 and it looks spookily familiar. The long strip of vertical body text, the main image, the links to other stories on the right. Yes it got a bit wider, and yes we spiced things up with embedded videos and Tweets, but the basic concept is unchanged.
But a basic online news article is like that for a reason, you might say (you tired rhetorical device, you). The format is pretty much universal. It does exactly what it needs to — gives the reader the story as efficiently as possible. Its form perfectly follows its function. Why mess with a classic?
It has definitely served the web well. But it was born to a different age. The people who crafted those early HTMLs were steeped in the pixellated world of Ceefax where (long before Twitter) journalists would valiantly condense complex events into four short monospaced paragraphs.
That’s one reason why recently we’ve been trying out some new ideas. In my team we were asked to build some prototypes of a new type of article page built out of ‘cards’ that are swiped from right to left.
There are a few reasons why we decided to try this card-based style of interface, which we dubbed swipey-swipey. One is that we wanted to break apart the traditional text-dominated layout and experiment with presenting shorter, bite-sized units of different types, optimised for display on mobile. We could have a ‘photo’ card, a ‘quote’ card, and a ‘key points’ card, for example.
Another reason is that we wondered if some users would prefer swiping instead of scrolling. Swiping is everywhere in the native app world. Swipe left and right to categorise. Swipe down to refresh (or was that swipe down to search?). Swipe up to subscribe (or dismiss!).
The theory was that someone getting their news through a UI like Snapchat Discover might warm to swipey web articles too. And that perhaps they were users the BBC should be trying harder to reach.
There are several of our nu-article prototypes now dotted around the BBC site, for example this one from the UK and this from the Turkish service. Note that they only work as intended at narrow screen sizes; the proof-of-concept was targeted at mobile, so (for now) desktop users are redirected to a more traditional vertical layout. The plan is to make them fully responsive if we decide to move forward with the idea.
(By the way, we’re not the only ones experimenting with mobile-first web news formats. The New York Times’ interactives use Swiper to achieve a similar horizontal card-swiping effect, minus the social features, while The Guardian’s ‘Minute’ format offers full-height scrollable vertical cards, and also looks nice on desktop.)
So far we’ve learned a lot about what users (including our journalists) think about the format. That’s a subject for a whole different post. What I want to mention here are some of the things we’ve learned as web developers.
Responsiveness in three dimensions is tricky
Wait, how many dimensions? Let me explain. A basic tenet of responsive web design over the last few years has been that layouts adapt to different screen widths through CSS media queries.
In fact, the foundation of layout responsiveness has been built into browsers for a long time. Browsers generally assume that content overflows vertically by default. If something doesn’t fit in the available space — no problem! The browser hides the overflowing part and provides a scrollbar at the side for you to move the viewport down to see it.
Typical ‘responsive’ web pages vary their layout and typography based on the viewport width, and let the browser do its own thing in the other dimension. Sporadic obsessions about keeping content “above the fold†aside, we aren’t usually too worried about height. Even freakishly tall, thin viewports and wide shallow ones are easily accommodated by the natural flow of content downwards. We assume that users understand what a vertical scrollbar is and how to use it.
But the designs we were trying here break that principle.
There is nowhere for content to overflow to when it gets too big — all the text and images have to fit neatly on the screen, regardless of size or quantity. In an interface of individual cards that are swiped sideways, also showing a vertical scrollbar would be disorienting. The web’s natural form is continuous, like a scroll, and we were trying to make it a discrete, like a book of pages.
So, a responsive web design that adapts not only to device width but also device height and to the quantity of text being displayed — those are the three dimensions I alluded to. That kind of programmatic control is available to mobile app developers with tools like Auto Layout formulae but it’s somewhat challenging in pure CSS. Yes, height-based media queries are a thing, but can you reason about how they should interact with your width-based rules when determining font size, for example? We found it gets hairy pretty fast.
Full-height web interfaces are a headache
On top of the general problems with vertically-responsive layouts described above, making containers exactly fit the available vertical viewport is made even harder because of mobile browser address bar handling.
If you’re not into code don’t worry, this bit is short :-)
- Using CSS3’s
100vhwould seem to imply filling the viewport, but most browsers now take this to mean the size of the viewport with the address bar hidden (e.g. after scrolling). Jeremy Keith has suggested this makesvhpractically useless. - Using
height: 100%on the card deck and all ancestor blocks (up tohtml) is Bloaty McBloatface but seems to work for most browsers, except Facebook's WebView on iOS which superimposes controls at the bottom of the viewport, partially obscuring the bottom of the content (see image below). - Another suggested workaround of using
position: fixedwas not easily compatible with our choice of card-swiping implementation.
In the light of this, we had to abandon our pure-CSS full-height dream, using JavaScript to fix up the container height based on window.innerHeight, which does accurately reflect the available space (as seen on this test page). It’s hardly elegant but it works.
Swiping interactions don’t play nicely with social
For our prototypes we used the excellent Hammer.js library to save us from the nitty-gritty of handling touch gestures across a range of devices.
Unfortunately, we hit a snag when we wanted to embed social content such as Tweets and Instagram posts. We found that users got stuck if they tried to swipe inside the area of the social post.
The reason is simple — we were handling swipe events for our card-level container, but the social posts are mostly (of necessity) iframes and therefore any taps inside them are handled by Twitter or Instagram, not our code.
To mitigate this we reduced the size of embedded posts and moved them to the top half of the card, because we felt that most users hold their phone from the bottom and this would reduce the chance of them swiping inside the embed. But this is really just avoiding the problem. To solve it properly we would need a way to distinguish between touches we want to handle (like a swipe) and touches that should be delivered to the embed (like tapping ‘retweet’). We discussed adding a transparent layer on top of the embed which disappears once tapped, but we suspected this would also be a poor experience.
(We did also plan to add left and right buttons as a visual hint and an alternate way of advancing through the cards, but ultimately ran out of time.)
What do we really want the mobile web to be?
These challenges made me wonder if there’s something interesting going on with our expectations of mobile web interfaces. When I started building websites, many designers still took print as their ideal. Print layout is pure, rigid and allows a level of control unthinkable online. If the headline length changes, the font size can be tweaked each time to compensate. As developers we sometimes struggled to explain why something so easy in QuarkXPress could be such a nightmare to achieve in a browser (let alone in all browsers).
Later, the imaginative grip of print weakened as some started to see that the web is a medium in its own right, with its own virtues. Ideas like adaptability and flexibility (and accessibility) came to be appreciated. This is how John Allsop put it in 2000:
The web’s greatest strength, I believe, is often seen as a limitation, as a defect. It is the nature of the web to be flexible, and it should be our role as designers and developers to embrace this flexibility, and produce pages which, by being flexible, are accessible to all.
It would be a few more years before mobile web browsers offered a browsing (or even rendering) experience anything approaching desktop. Then came responsive web design, and everyone lived happily ever after.
Except… except the web was no longer the cool kid. Since mobile apps burst onto the scene in the late 2000s with their app stores and their fancy splash screens, they have increasingly influenced our ideas of how mobile user experiences should look and feel. Fast, smooth animations are a given. Interfaces can be an arbitrary tangle of cards, tabs and dialogs, with swipes, drags and pinches aplenty. Native apps are our new imaginative ideal, offering a return to a greater degree of control. In some ways, they are the new print.
Even the subtext of Google’s marketing push around Progressive Web Apps is that mobile websites must aspire to be more like native apps. While I’m as excited about getting access to previously native-only features such as offline support and push notifications as the next web dev, I’m not sure that the mobile web should only try to imitate the kind of user interfaces that we see on native.
Do mobile websites really dream of being native apps, any more than they dreamt of being magazines?
Learning through doing is fun
Despite these philosophical quibbles, the slides prototypes were hugely fun and challenging to work on. I got to switch from back-end to front-end code (and back). It was a small team, with a couple of developers working very closely with a designer and a tester in short iterations, and a business analyst helping to capture what we learned along the way. There was a lot of healthy debate, and as developers our views were listened to. It really did feel like a team effort.
We know the prototypes aren’t perfect. They were never intended to be viewed on desktop screen sizes, and there is more we could do to improve the accessibility of the markup. Discussions about where to take the ideas next are still ongoing.
But as a learning tool, they were a success. Using a combination of event tracking, online surveys and real-life lab sessions, we learned how far users progressed through the content, and what they thought about the user interface. We learned about the editorial challenges of writing bite-size content that fits the format and but allows users to dive into more detail if they want it.
And we learned a bit about what building article pages for 2017 instead of 1997 might be like.
Shameless plug: BBC News is hiring web developers at all levels. If you like the joy of building new types of front-end interface, the challenge of building systems that can handle millions of users per day, if you’re interested in internationalisation, in accessibility, in being in a supportive and inclusive workplace with great perks, drop us a line.
