We recently launched the second version of the HTML5 FT Web App, and it was very much a ground-up redesign. Some of these changes are the result of editorial requirements, others pragmatic improvements that build on the original app, and others still are more speculative – new ideas that hopefully push forward the design to keep it fresh and innovative.
I’d like to run through some of the design thinking behind the new app and to illustrate some of the key differences and new features.
It’s quite long but there are pictures.
One of the most fundamental changes you notice when first opening the app is that the homepage no longer scrolls downwards; what you see it essentially what you get. As before, you can swipe the page left or right to load different sections, and there is a new version of the ‘carousel’ module along the bottom of the page that allows you to swipe horizontally to get more in-depth content from each page, but trying to swipe the page upwards as if to scroll down a webpage no longer exposes more stories.
In many ways, this is our riskiest change to the app. Where users of the old app could scroll down the homepage for example, to see previews of 10 articles and various other bits of content, they are now limited in the main body of the page to 5 previews. This could appear like we’re providing less content in the app than previously, although this isn’t the case, but what we’re actually trying to achieve is something quite specific.
Firstly, this view of the homepage more closely resembles the content displayed in the newspaper. We’ve got used to websites becoming larger and longer all the time, and many news websites show hundreds of story links on their home pages. Ours shows a much more modest 10 main previews and several dozen smaller text links, but the newspaper still shows between 3 and 5 main stories with a few others in a narrower column. The editorial agenda is clear and focussed, and readers can much more easily get a sense of the important stories of the day at a glance. It’s important that the web app follows the newspaper in being a product that can be browsed through, that can be read. We have the luxury of being able to call upon vast swathes of data and content that can be invaluable for readers wishing to use the app for research or deeper analysis, but it also has to be something that’s feasible and pleasurable to simply browse and read through as you can with a newspaper.
Secondly is the way that content is laid out on the page. Our old web app felt very much like the website, placed onto a tablet. And that’s because, in many ways, that’s exactly what it was. For this update, we’ve had the opportunity of being able to start again – to make an app that looks and feels as much like a native app as possible – an app designed for a specific tablet that takes full advantage of the device that it’s displayed on and that fits exactly to that screen size. Many native apps eschew scrolling on index pages because it provides a good user experience to fit the content exactly into the available view. When you think about it, this is again closer to a print experience; the main body of content is immediately in view and can be absorbed in one go. With a digital app we have the ability to add smaller sections that scroll within the page and so this is what we’ve chosen to do. Further relevant content is available in smaller scrolling modules within the page, and article text scrolls downwards until the end whilst the headline, main image and further links are kept in view the whole time.
But, I hear you cry, our app isn’t just for a single device. It can’t be laid out to fit one device such as the iPad while ignoring the differing sizes of other devices. And you’re absolutely right. One of the aims of the original web app was that (potentially at least) it was available to use on almost any tablet and smartphone, and the new app takes this much further still. I’ll go into more details further on, but the essential challenge is this – how do you make an app look like it’s been designed to perfectly fit the screen you’re viewing it on when that screen could in reality be one of many, many sizes? Even a single device has two orientations, landscape and portrait, which the user can switch between at any time by simply rotating the device.
FITTING IT ALL IN
With a website, and indeed with our old web app, the amount of space we allow for an element on the page, such as an article preview on the homepage, is pretty flexible. It’ll start with the first word of the headline and end with the last word of the teaser text, and it doesn’t matter too much how long either piece of text is. The next piece of content will simply sit below the first and as the page is built up and becomes longer, so the reader scrolls downwards to see it. By fixing the height of the page though, we essentially have to fix how much space is available to each piece of content on that page, and there’s no room for manoeuvre if it’s to look neat and polished.
There are a couple of ways of approaching this in layout terms. The first is to write text to exactly custom-fit each space available, essentially the traditional newspaper sub-editing process. Even if this were possible or desirable with a large team of people to lay out each page, it still wouldn’t work with the range of devices and screen sizes available, as mentioned above. The alternative is to fix the available space for a piece of content and then simply fill it with as much content as it can take.
This method, while pretty standard for news apps these days, does require a fairly sizeable change in editorial thinking. Rather than writing a brief and pithy description of an article of an approximately fixed length, we have to fill a space that is not only much longer than we currently use but can also vary fairly dramatically, and so two changes need to happen. Firstly, we have to take the intro text straight from the article itself rather than have something written specifically for the purpose. The article body text is always going to be long enough to fill whatever preview space we allot it on an index page, and so it provides an easy source of text for a long lead body. Secondly though, we can’t tell in advance at what point the text will be truncated when it reaches the end of its allotted preview space. This is fine technically as the CSS code can simply chop off the text for us at the right point and add a neat ellipsis, but it does need the editors to accept that the fine control of that lead body is lost and it’ll simply end mid-sentence, often even mid-word. Not ideal, but a necessary trade-off to allow flexibility in laying out the page.
This technique frees us up to allow the elements of the page to change size, vital for differing device screens and orientations. But we still have to go further than this and re-order the page layouts themselves, especially for the change between landscape and portrait orientations. A tall, thin page layout can’t simply be stretched sideways to fill the same screen turned onto its side.
The way we do this is to firstly divide a page into regions of content. The home page for example has 3 main content areas; the top story, the right column containing further stories and the advert, and the scrolling tabbed bar along the bottom that shows more stories again. Taking the iPad as an example, the screen has a ratio of 3:4 in portrait view, so when turned on its side a quarter of its height is effectively taken from the bottom and added to the right side of the device. And so this is the simplest thing for us to do too. The first two regions are left roughly where they are and the scrolling module that runs along the bottom is taken and displayed vertically down the right side of the page. It needs to be displayed differently to work in this position, so the text and images are shown at a different size and the tabs are changed to show as a list of sections, but we do as little as we have to make it work as similarly as possible in the two different positions.
The top and bottom of the page, the skyline region with the Financial Times masthead and promotional story and the menu bar of buttons that runs along the bottom of the app are merely stretched to accommodate their new size. We actually show two stories instead of one in the header to fill the space but otherwise nothing really changes.
For the individual sections themselves, we divide their contents into even percentages. So the 4 stories in the Top Stories module will be allotted 25% of that column each (allowing for some space between each story). As the device is rotated and the page re-formats, so the total height has to change slightly but the 4 stories continue to take 25% of the height each. In this example they lose a few characters of text each, but with the truncating technique mentioned above they just automatically absorb those changes and display however much text fits that new space. Other changes might take place too, depending on the page and the module, such as font size changes or the visibility of images. In the example of the homepage Top Stories module on iPad, the total height available drops from 394px to 348px when moving from portrait to landscape and so content has to be lost. A line of text is taken from each of the 4 stories and images are also dropped as there’s not the vertical room to display them.
There are added complexities with a web app such as ours in that it can be displayed within the device’s browser or saved to the home screen and subsequently run full-screen. This means that the browser’s chrome, the visible part of the browser app containing the address bar and icons may or may not be present and we have to ensure that the app works well in either situation where there’s a different height available for the app. There’s also an option to hide or display the bookmarks bar in Safari, so there are 3 different ways of viewing the app on an iPad and a portrait and landscape view for each, totalling 6 different combinations.
For each situation where the available height of a module changes, the display of the content will change. Fewer and fewer lines of text are shown as the module shrinks, images are removed and eventually, body text is removed leaving headline alone.
Ultimately what we’re striving for is a set of rules that are rigorous yet flexible enough to adapt to any set of dimensions rather than building multiple different designs, but each of these layout configurations have to be tested and tweaked to optimise the visual display of the app, and to ensure that everything works correctly and displays legibly.
There are further more complicated and subtle changes on this and other pages that decide the details of how they are laid out in the different views, and other techniques such as using consistent text leading (the height of an individual line of text) between headline and body copy to ensure things always line up regardless of how much text is shown in any position, but the essence is deciding where blocks of content sit on the page and allowing them to flex appropriately. This is essentially the key concept of Responsive design, the design buzz term of the last couple of years and means that we can roll out the design to any device of any screen size as we choose to. There’s a lot of hidden work in doing this and an awful lot of careful juggling of space to ensure things work as they should and look good, but the aim has been to build a design framework that’s entirely flexible and which can be moved across various mobile platforms.
A PICTURE PAINTS 1000 WORDS
We’ve since introduced a more intelligent system for the desktop called the Single Image Workflow whereby we’ve standardised on one single shape for the images. This is at a ratio of 16:9, the same as the shape of most modern TVs and monitors. One very large ‘master’ image is cropped and optimised by hand but then because the various images used are all the same ratio, no further manual cropping need take place and images of any size can be produced automatically.
One of the other big improvements also has tie-ins to responsiveness. The old app had plenty of photos to illustrate articles but these were generally rather small. For reasons of efficiency and workflow, we used the same images that appeared on the desktop FT.com website, and at the time these were produced in a series of fixed sizes of varying shapes to be used around the website. So for example, if an image was to be used on the site’s home page then an image was cropped and produced for that position, but a separate image of a different size and shape would then have to be made if that image was to be displayed on the article page. By re-using these images for the web app, we were only able to make use of the sizes provided and the the pages were then effectively designed around these images.
As well as optimising the workflow and enabling the use of larger and more varied image sizes around the desktop site, the master image is also part of the feed of data in the API that’s sent to the web app and again, images of any size can then be produced from this. Not only is this master image large enough that we can use it at significantly larger sizes than previously, but we’re not constrained by the dimensions set by the desktop site and so we now size the images to best work with the design as we see fit.slideshow-full.png
This then ties in to the responsiveness discussed earlier – the images can be re-sized for different devices and, once again, for the same device in either landscape or portrait orientation. Currently, only 3 image sizes are produced for the app and these are scaled down to the various sizes used. This helps loading speeds as the contents of the app are downloaded to the user’s device for offline usage but does cause a slight delay in the appearance of the images as the browser has to scale an image down before it can display it. A change may be made later to produce more sizes to speed this process up, but as ever there’s a delicate balance between performance and quality that has to be managed carefully.
The larger images come into play in other ways throughout the app too. We’ve introduced ‘standalone’ images that work in a way common to the newspaper. The top story of a section index page may not have an image that’s particularly good or, conversely, there may be a great picture story but not one worthy of the top story position. The editors now have the option of utilising a position at the top of the page that shows a photo with an overlaid caption that links off to an article but then displays the top story itself below this, sans image. This system can also kick in if a top story is published without an image, meaning that breaking news can be displayed effectively even if there’s not been the time yet to source an appropriate image.
Picture slideshows are another new photo feature, again possible because of the larger images and one of several new features carried over from the website. Graphics used to illustrate articles can also be brought over now and tapped to enlarge, a vital feature when displaying complicated infographics and charts.
Coming back to the topic of formatting for different devices and screen sizes, there’s been a related hardware improvement in recent tablet models whereby screens of much higher pixel resolution are used. Apple use the term ‘retina display’ for its iPad and other manufacturers have similar technology. Essentially this just means packing far more smaller pixels into the screens to produce higher-quality images but it again requires a degree of responsiveness to make sure everyone sees the app at the highest quality possible. Not only do the photos have to scale correctly depending on the display, but any other graphic image used has to as well. We keep these graphic elements to a minimum and rely where possible on producing shapes, boxes and gradients with CSS, the language that orders the elements of the app. As an example, the claret-coloured bar that runs along the top of the app isn’t a graphic file but is just a rectangular box defined by CSS and coloured appropriately. This makes it quick to load and fully scaleable so it’s always rendered perfectly, and this has been the standard approach to simple visual elements for many years.
With incremental improvements to the complexity of CSS, we can use the same techniques to produce elements such as buttons that have rounded shapes and coloured gradients to give them a textured look, but other more complicated elements like the icons used for search and settings and to illustrate Facebook and Twitter links need another approach.
There are graphic formats in use that allow vector images – images defined by the position and mathematical shape of curves rather than by the series of coloured pixels used to define graphics such as photos. They’re useful because the files are made up of a series of co-ordinates and number values that take up relatively little space and so load quickly, and they also scale perfectly to any size. They are ideal for the kind of elements on the app that aren’t photos, predominantly icons. The problem is one of support – there’s a file format we could use well enough on iPads and iPhones, but support on other platforms isn’t as good and we’d end up having to repeat the files in more than one format.
Instead, all the icons are stored in the perfect hiding place for vector files – a font. Text is also a vector format where the curves and shapes are used to describe letter shapes rather than icons, and yet all platforms support text perfectly well. It’s therefore a technique of growing popularity to make a custom font that contains only graphical shapes instead of letters and to load this into the app. The individual graphics can then be sized and coloured using CSS. Even the Financial Times masthead on the homepage is just a letter in the font, but it means that all the small icons and graphics can scale beautifully, and the app will display perfectly on a retina iPad at a much higher visual quality, as well as any other display or monitor at any other size and resolution.
An entirely new feature of the app is a section called ‘My FT’. This acts as a hub for content specific to the individual user and currently displays 3 lists of articles; recommended articles based on the user’s previous reading history within the app, recently read articles and any saved by the user with the Clippings tool, by which individual articles or entire Special Reports in the app can be saved and then accessed either on the My FT page or on the desktop FT.com site. A fourth section contains the headline figures from a user’s portfolio and links through to the full page in the Markets Data section.
Rather than sit within the app’s navigation, My FT is available from anywhere within the app via a button in the bar along the bottom of the screen – itself a new feature to enable ease of use more in line with a native app than a website.
The My FT page addresses specific issues in relation to grouping areas of content and allowing quick access, but it’s also ripe for growth as we incorporate more and more personalisation into the app.
Another button in this bar is the edition switcher which toggles the app between Live and Morning editions. In the default Live mode, the app will constantly update to show the latest stories, but the Morning mode effectively fixes the app to display the same stories as shown in that day’s newspaper. This means far fewer stories are downloaded and necessitates a slightly different layout to many of the pages. Some of the content that would otherwise have to be downloaded such as videos and blogs is also omitted. By doing this, users can choose to download an edition of the app that much more closely mirrors the newspaper and will stay the same throughout the day.
This is a feature much-requested by users who want to transition between newspaper and app through the day without content updating and consequently moving around within the app.
The layout of the article pages has changed fairly significantly in the new app. As well as gaining some of the new content features mentioned earlier, such as better and larger photos, enlargeable graphics and embedded slideshows and videos, the body copy itself has now changed direction. The old app had multiple columns of text and was navigated through by swiping to the right, but it now scrolls downwards. One of the reasons for this was to simplify the swiping gestures in the app and to introduce more conformity and efficiency of movement. Because of the fixed height of the main pages, swiping is now limited on these to the left and right, which (as before) takes you from section to section. Once in an article, the same left/right swipe moves you from article to article, and up/down now scrolls through the article itself. The old app necessitated swiping through the columns of the app to the far end before swiping again to the right to get to the next article. The new system means the articles can be browsed much more quickly and easily and the swiping metaphor is more consistent – left/right for different content, up/down for more within a specific page.
It also means we can leave space where the headline, byline and main story image are fixed so that you never lose sight of the article’s context, and then there’s space left in the bottom-left of the page for related content. This can take three forms and is displayed where relevant – more articles from the section you’re currently in, more articles related to the specific story you’re reading, and a list of any companies mentioned in that story which then link through to their company tearsheets. None of these links are new to the app but they were easily lost in the old design where they were positioned either within the columns of text or at the very end of the article, often out of sight initially. By bringing them all together into one place that’s in view at all times, we think readers will be able to make better use of them.
It’s always a little depressing when conducting user testing if users get excited by new features that actually aren’t new at all, as in the case of these related story and company links. But at least it shows we’ve solved an existing problem in terms of visibility and hopefully made a solid usability improvement, and one that’ll drive greater user engagement.
THE END, AT LAST
There are endless other changes of course. Many too small to notice on their own but when grouped together hopefully modernise the app in a meaningful way, and make it a more enjoyable, polished and efficient reading tool. But that’s enough for now. Suffice it to say that the new app isn’t finished as such, in the same way that the painting of the Forth Bridge is never finished. Except that that’s sadly a myth. About the Forth Bridge I mean, not the app. But either way, we have a long list of improvements still to come. Some that just couldn’t be finished in time for a first launch, and others that have always been scheduled for a future date.
I don’t want to give too much away, partly for the drama but mainly because our schedule will be dictated to a large degree by the launch of the app itself and the feedback from the users. Things will need to be fixed, improved and possibly even re-thought completely, and these things take time. But we’d like to add more content still to bring it in line with the desktop site.
But for now, do please play with the new app. There are links for feedback within it and we welcome all (constructive!) criticism. If you’ve not used it before then you’ll find it by pointing your mobile browser to app.ft.com. We also have native versions for Android and Windows 8.