Scalable UIs, Scaling the Content

16.02.2015 Nuno Pinheiro 2 comments

So far we talked about the technical aspects of scaling your application, the dpi, the number of pixels, its nature, the nature of image formats and the implications of all that on the creation of visual elements for your UI.

But this is only a part of the problem, for although all this helps you to create answers to your scaling problems, it does not answer the problems that created the need for those answers: the fundamental part of the problem.

As we very well know, “Only when you know the question, will you know what the answer means”.  Luckily in this case the question is easy enough and it is: “How do I scale my application across many devices?” So we only have to answer it. Unfortunately, however, 42 does not work well enough in this case and the sad reality is that there is no single definitive answer.

Nonetheless, there are some “rules” or general concepts, that if taken into consideration when finding the answer, do improve the quality of it. These rules will be subject of this blogpost.

DESIGN once, evaluate every time.

So after we get to scale our elements in a meaningful correct way, as we discussed in the previous posts, one could think that it would be enough to just set some base position rules and be done with it. Truth is that changes in screen ratio when porting your application to a new device don’t always go hand in hand with resolution changes and require a repositioning of components rather than simple scaling of the said components.

This means that sometimes we have and should use a different ratio to reposition our assets. A clear example is portrait and landscape form factors. Portrait traditionally comes better with single column layout, where in landscape we can have multiple columns.

As we also talked about in earlier posts, the fundamental metric for objects in this space is the size of the user’s finger, so when a screen gets physically larger we get more space for more fingers, ergo we might want to use that in our app providing more explicit functionality in each screen.

Platform matters.

Porting your application to a specific platform does not occur in a vacuum. Most of the time each specific platform has extensive guidelines on how to tackle this, so even when we think we have a better answer, we have to understand that being right when everyone else is wrong is one of the worst experiences in this area. So try to comply with the user’s expectation in a specific platform.

It’s the principles that are meaningful not the pixels.

Your brand and experience concepts should stay regardless of screen/platform. This sentence is perpendicular to the previous point, and points out that as your application becomes available in multiple places you should not reinvent it at every turn. You should stay true with some predefined core image/interaction/experience principles that help define your brand and your application uniqueness across multiple points of interaction. You may need help – realise that this feels like and often resembles a perpetual exercise of “squaring the circle”. This space is evolving rapidly and the answers perpetually change, so seek help externally if you feel lost.

Start by not trying to make it perfect for all cases.

Android, iOS, Windows Phone, BB10, Tizen, Windows Desktops, Linux Desktops, OSX, embedded etc. – there are several hundreds of different screens out there. Group them into areas, don’t try to make it perfect for every case in every platform. Start by discovering the target group of your application and choose a widely adopted resolution and platform as your start point. Define some simple base rules for scaling the application on the chosen platform, expand on the core principles developed there as needed. And then scale into other platforms.

Test, Test and then Test again.

Development and testing of your application on the Desktop ≠ the Device. This is vastly different in terms of experience and the final result. Test as much as possible – some things only make sense in the real thing.

The context is part of it.

Each platform is used in a different context and user mindset. A phone is used with the user on a specific position, location and attitude towards the iteration than for example a desktop. An embedded device can be used in extremely specific situations for example in an industrial plant. Use this info to evaluate how to scale each feature of your application on the canvas. Weight the content creation vs content consumption or the decision pattern in each case so that in each context the user might find what he is looking for. Users look for different things in different contexts.

In the end, Scaling is only one part.

Scaling your app correctly and efficiently is only part of the story. In fact the quality of the referred scaling is in great measure the result of a previously well-crafted User Experience, well defined User Scope, efficient Branding and good Usability.

This Concludes the series on Scalable Uis. I hope you found here information that might be useful for your work. It is not by any means an exhaustive view on the subject nor a definitive answer. What I hope with this series is to make some of the issues a bit more present, so that you might avoid costly loops of unplanned revision and bitter surprises, and gain a bit more understanding about the several aspects of scaling multiple concepts. I might revisit this topic if some new aspect surfaces that is interesting to talk about and relevant enough.

So see you soon.

Nuno Pinheiro Senior Graphic Designer and Illustrator. Specialized in iconography, themes user interface design and Qml wire-framing/prototyping/implementation. Nuno's works include general illustrations, UI design, web design, corporate design as well as other works in creative areas. He is known for the Oxygen Project.