For the first time in my work, I had the opportunity participate of a responsive design project, with an amazing team, building a framework. So, this post is about the challenges of this project and the process. Before reading this article, I invite you to check out the app :) Write in your browser from your mobile device or tablet and have fun!

The briefing
It seemed to be a short briefing in the beginning, but it was bigger than we thought. The client is a newspaper in Rio de Janeiro: Jornal OGLOBO. I work for this company since 2011 and this was a big challenge for me, as an interface designer.

As you can see, that’s a big website with massive content. The newspaper asked us to build a framework, that could be used for different topics like elections, carnival, festivals, etc. For this project, we started with this year elections. Basically, this web app should be a feed of news, filtered by this topic, but with special features and optimized for different devices.

Why choosing a web app?
It took some time to understand why they wanted a web app and not just make some list in the mobile website. Why choosing a web app if it will work as a list? Mobile devices are designed for special tasks. The reason why you use a tablet or mobile will depend on your context.

In our scenario, we are working with a website that has a massive content. So, it should adapt to any device and bring flexibility for all users devices.

We must also considerate, that the web app should look as a native app, according to mobile patterns, because we are using the same device.

Good points

We can build a quick comparison between native app and web apps, but the choice will depend on the business objective, target audience and strategy.

It’s all about the context
“First the devices implies a context”. When you design for different devices you can’t know all the user’s context. So that explains what kind of content are you going to emphasize. If it is a mobile user, he/she must want to know more about the new numbers of the elections rather than the news, for example, because he/she won’t have time to read a big article about it or just understand a massive graphic. The information should appear simply and directly. That doesn’t mean that mobile users don’t want to access all the information of the desktop.

Mobile first
Mobile web growth has outpaced desktop web growth, that means that this is a good opportunity of innovation and to focus in what the user really needs.
Web organization, actions, input and layout should bring curated and focused content for every device. This amazing design philosophy, built by Luke Wroblewski, suggests that we need to focus in the simplicity and relevant experience of content in mobile. We need to strip down to the essentials. Less is more. Always. Offering too many choices for the users tend to create confusion and the user won’t make a choice at all.

Different devices areas

Responsive Design
The challenge is delivering fluid content to each screen size. That means that we need to create a consistent and connected GRID to each device.

Devices OS Portrait Landscape
iPhone iOS 320 480
iPod Touch iOS 320 480
iPad iOS 768 1024
SonyEricsson LT15i Xperia Arc Android 480 854
Samsung GT-I9100 Galaxy S II Android 480 800
Samsung GT-I9000B Galaxy S Vibrant Android 480 800
Samsung Galaxy Tab P1000 Android 600 1024
Samsung GT-N7000 Galaxy Note Android 800 1280
RIM BlackBerry 9300 Curve 3G Blackberry 320 240

Table 1. – List of devices

This means that we need to work with a responsive design workflow, using structure, content, typography, mood boards, UI pattern library, asset management, native considerations.

The magic tool for this task and all the layout was Adobe Fireworks. You can ask me why, but I prefer to answer in another post!
White space is about exploration, so the wireframes were built based on responsive design patterns.

  • Footer anchor
  • Fluid images
  • Image GRID
  • GRID blocks
  • Lists
  • 3-up carousel
  • Fluid video

Elements change size and position in each device

That’s not only about visual. “Interfaces exist to enable interaction.” How do you envision this photo gallery in a touch interface? What about the different experiences between tablet / mobile / desktop?
If it is a mobile, scrolling can be the main interactive way to get the information. If it is an iPad, the experience can be more about swiping the pages and not having too much scroll. That was an important point in our project. The tasks are different, so we need to plan how the user will interact with the interface.

The size of the text should bring hierarchy. That means that the most important article must have a bigger type. Of course, the behaviour of the font-size in each device and different orientations should be different, but maintaining the same proportion. We should also verify behaviour of the blocks of type in the devices.

As the same in the typography problem, the images should be fluid. And in our scenario, the images must have the same size of the crops in the web site, to avoid ‘cutting the head’ of someone in a photo.

Colors and texture
The color palette should follow the identity of the main website. We decided to use textures in the background of our layout to create a comfort for the user while reading a massive text and also because this is part of the identity of the OGLOBO website.

Navigation header

Again, it should be fluid. I had some difficulties while designing it:

  • Behaviour of the header in different devices

In this project we don’t have a menu, but some other elements like: time, date, logo and name of the special topic. [we had to take out the time, because it was a problem: some users thought they were reading an old content, instead of the updated one]

  • The challenge of the ‘add to home screen’ button

One question in this project is the bookmark button, that will save the link in the desktop of the user. We designed this for androids and iPhones, but they have different elements that represent this action. In androids (not all of them) it is a star (bookmark), and this action has a different behaviour. DIFFICULT. The icon of SHARE is descendant from Safari. So, should we delete it when the user is accessing from a different browser? Or create another one?

Mobile patterns
We had to work with some primary and secondary navigation patterns and invitation patterns, like tip/discoverable window.
This is very important because the user is not conversant with the action of saving the shortcut in the home screen. That’s why we created the icon on the top.

Hummm Icon mismatch? Anti-pattern?

Well, we already know that using a familiar icon in an unfamiliar way will cause confusion.
Offering a standard icon would make this application more intuitive, and probably result in higher adoption of the “favorite”. But, again, this is a web app and not a native app. [we decided to take out the bookmark and use the tip before the user navigates in the web app.]

Navigation ‘sandwich’
In the content page, we forgot to bring it more like an app. I had a feedback that I won’t forget and I made the changes in the layout:

Collaborative team work
We worked in system of collaboration between developers and designers, trying to get the best result of the project. The good thing about this kind of work is sharing experiences and knowledge, like the viability of the framework and its particularities. The developers could give recommendations of how the project should adapt to each device.

Testing with different devices
While testing in different devices we needed to revise our design. In iPad some fonts were very small for readability.

Small feedback and tests
The team was small, but even with this we got some feedback from other amazing designers, that helped in some changes that I’ve made in the layout.
We had also some feedback while testing in the devices. The layout is not always the same as you see in the screen of your computer: you must test every detail. We discovered, for example, that we needed to fix the size of the typography. Sometimes you can’t use only proportional font-sizes, because the behaviour is different.

Review, design, build and repeat. That’s what we do. And of course, we need to keep it simple. We are still working in the perfection of this framework and I’m sure we will be working on it everyday. We must ensure a progressive enhancement always. I think everything is very new, including the technology that is changing everyday. This means that there aren’t right or wrong answers, but patterns of experiences and behaviours that must be respected first.

Boston Globe case
Separate mobile – presidential smackdown
A informação ubíqua
Making BBC One’s website responsive
Could A Redesign Really Rescue USA Today?

» Read this post in portuguese: Desafios da criação de um framework para notícias

photo credit: via photopin (license)

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.