This article describes a method to decouple responsive design and localisation rules from numerous page instances, and instead apply them to a small set of screen classifications. By doing this, it should provide you with the following benefits:

  1. A predictable, consistent UI layout;
  2. A UI layout ready for responsive design;
  3. A UI layout ready for optimisation for different markets, such as transitioning a LTR page to RTL;
  4. Less documentation needed to explain how page layout should change for a particular context (market, device), allowing for a 'leaner' deliverable process;
  5. Promotes code reuse, and improved maintainability.

Object Orientated Analysis and Design principals are used in this post, which will resonate with the developers who are implementing the framework.


Each product screen should be looked in terms of the following:

  • What is shared across the majority of screens;
  • How does the layout differ across screens;
  • What is the relationship between areas of the screen;

Items often found on a page, such as a composite like a Footer, are not very interesting as  the majority, if not all pages have one. Pieces like these should be ignored, as they get defined once within the Abstract Screen (discussed later).

What is most interesting are the the last two bullets. Whilst ignoring the common page assets, look at the screens for what makes them unique. Focusing on this uniqueness, start classifying them based on the kind of relationship they have with each other.

As you continue to move through the product(s) screens, you should begin to notice that some pages have things in common with regards to layout and page zone relationship. This should be an iterative process, and each time you should try to normalise the classifications you have found. Tell-tale classifications will often have very few members.

The resulting set of screens you identify then make up your set of Meta Screens, which will contain zones ready for creating responsive localisation rules.

Abstract Screen

All application screens start with the abstract screen. It is heavily generalised, with it specifying only the essential structure that each page must possess. For a web application, this being the header, some kind of content area, and a footer.

The abstract page is used as a foundation for all product screen types.

The abstract screen is used as a foundation for all product screen types.

The "Abstract Screen" allows rules shared for all screen instances to be specified in one place, and then inherited by all subsequent screens. The content of the screen zones do change based on factors such as component state, and device medium; this article focuses only on layout, but component variance is a topic I plan to blog about at a later date.

Meta Screen

The sole focus of "Meta Screens" is to define content area variance; we no longer need to focus on the Header or Footer zones, as that is handled by the Abstract Screen. What is within the content area is the reason the user is looking at that screen in the first place.

When viewing a web page on a large screen device, such as a desktop PC, it is common to see the content area divided up into 2 or more sections. This is to make full use of the available screen estate. These sections typically have a relationship, but these relationships are not always the same. Below is an example of SkyDrive, which uses a very common screen layout:

SkyDrive has a Master / Detail layout

SkyDrive has a Master / Detail layout

In the annotated screenshot above, the content area has been divided up into a Master and Detail zone. Choosing an option from the Master menu, such as "Shared" will make the Detail zone update to show all shared files.


Small screen devices like a smart phone do not have the luxury of a large screen estate, and so the desktop screen layout will not suit. However, now that we have defined zones for a screen layout, we can now create rules for other devices.

Master detail screen layout in the context of a mobile device.

Master detail screen layout in the context of a mobile device.

In the SkyDrive example, one would expect that having the Master displayed before Detail would be most helpful; it tells the user where they are, and where the files listed belong. In this approach, the component responsible for listing folders would need to change. But, what this layout does is give a clear sign posting as to where the user is, and a quick and direct means to change that location.


The layout used by SkyDrive is very much driven towards a Left to Right language (LTR) such as English. Right to Left languages (RTL), such as Arabic, often requires a different layout.

BBC Arabic (top) layout compared with BBC (UK).

BBC Arabic (top) layout compared with BBC UK (bottom).

Both of the above examples are of the BBC's news site, and when looking closely both are very similar. Both have a logo, main heading, navigation, and news ticker, to name a few. What differs is their placement. In the most case, it seems to be a mirror image.

The Meta Screens you identified earlier can also be utilised for these kinds of layout changes. Just like the responsive rules you write for its zones, the same can be done for a different writing system.

Master Detail screen layout for a right to left language.

Master Detail right to left language screen layout.

Relating this back to SkyDrive, when a user who is used to a RTL writing system looks at the application using the above layout, they will first see what folder they are in, and then the files belonging to this. Please note I have not tested this hypothesis, and it ought to be validated.

In terms of implementing this, CSS3 Flexboxes looks to be the ideal solution for this. However its support is still quite sketchy at the time of writing this article.

This method is still very much in its infancy. I have not found anything quite like this yet within the User Interface domain. Please feel free to contact me either through the comments feature of this post, or via email.