In my last post, I’ve talked about different kinds of layouts that can be used for apps using acrylic and depth from the Fluent Design System.
I’ve shown 8 different layouts, from the tree-column layout to the _vertical
layout_.In those two opposite layouts, the hierarchy of layers was structured differently: the first one was horizontal-lyoriented and the second one was vertically-oriented.I’ve tried to mix those two different orientations to create different layouts which allow more complexity in the structure of apps.
In this post I want to explain where those layers came from, why they are used in that way, and how they interact and work.
Each app needs to have at least 2 layers displayed on one screen, and a maximum of 4 layers (taking into account the number of opacity variations that MS gives to the acrylic tool: 60%, 70%, 80% — even if I find that 3 layers is the right number).
From top to bottom:
The 3 kinds of layers
Before talking about the purpose of each layer, we need to define which kinds of elements can be displayed in layers.
Following the precedent article, we can define 4 different types of elements:
The 4 kinds of elements
Now that we’ve named and defined each layer, and the different content they can display, we can establish the purpose of each layer.
Summarize that using a picture:
Areas — purpose of each layer
Another way to think about it:
Now that we’ve set the main tools, we can talk about how the architecture works. The layering and the rules for it are important to help the user understand how the app is built, and how to use it. This is why each area has a purpose.
Before, we’ve used the z-axis (layering) to structure the hierarchy of the content, and now we will use x/y-axis to make the interface come to life.
First, lets define some characteristics of areas:
So here is a quick example of a moving content-area when navigating through the app:
YouTube app example
This example is a YouTube-app (layout inspired by the myTube app), navigating:
In this example, only the primary-content area moves and resizes to adapt to the new content (reducing its size to display just one video and giving more space to the context-aware area; and moving to the left to hide the navigation area and reveal the new content of the context-aware area).
So, even if there is no brutal transition-animation, by changing the layout, the app helps the user to understand that he’s moving into the app and gives to him a better suited layout to enjoy watching the video.
Because changing the layout when navigating through the app isn’t always necessary, here is another example of a transition without moving the content area:
Groove Music Concept
In this last example, as you can see, the primary-content area stays at the same place, and only the primary content is changing on this area, from the list-view of the recommendation-page to the detail-view of an artist.
So areas are living elements that display the content, but they are not constraigned to move when navigating.Only the content impose to the area to change in size or placement.
This last example also gives me the opportunity to talk about the layering in a concrete example: the Groove Music app (and its redesign concept).
Current look of the Groove Music app
From this screen, it is possible to distinguish (from top to bottom, and from left to right):
This case is pretty simple, based on the areas we’ve defined before. We can set four groups:
So here is the concept based on the guidelines we’ve created:
Groove Music app concept
In this concept we can clearly distinguish the four areas:
The different areas made visible
This post was a bit longer than the first, but I hope not too long.
After showing some examples of layout in the precedent post, I wanted to explain how I’ve came to those layouts and help to create some design consistency for Windows 10 applications using the Fluent Design System.
Of course if you want consistency, rules are needed (tacit or explicit). This is what I’ve tried to begin here: creating some rules to use the new tools from the Fluent Design System (acrylic and depth) to structure the design of applications.
As I’ve said earlier, those rules are guides to help developers, not to constrain anyone to use them.
In the next post I will try to build some other rules to work with the “scale” part of the Fluent Design System and showing how this layering structure can work from desktop sized windows to small windows and mobile screens.
Thanks for reading!I would be glad to know what are your thoughts, and how you think this system can be improved.