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.
Layers definition
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 first and main layer is the top layer (TL). It’s an opaque layer, either white or black;
- The second is the mid layer (ML). This one uses acrylic tool from theFluent Design System, and the transparency is set to 80%;
- The third is the bottom layer (BL). This one also use acrylic and the transparency is set to 60%.
The 3 kinds of layers
Content 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:
- Primary-content (ex: a conversation in a messaging app, or videos in a YouTube app). This is the main part of each screen;
- Navigation controls. This part displays the different elements to navigate, e.g. a list like in hamburger menu, tabs, or pivot controls;
- Elements about content, which are elements or controls that impact the content or are related to it (refresh, create a new message, details about the content.)
- Home controls, which allows going to the account menu or the settings menu;
The 4 kinds of elements
Purpose of layers
Now that we’ve named and defined each layer, and the different content they can display, we can establish the purpose of each layer.
- The TL is used for the content area, and will always display the primary-content of the screen;
- The ML is used either for navigation area or content-aware areas. So it displays either navigation controls or elements about content;
- The BL is used either for navigation area or home areas. So it displays either navigation controls or home controls
Summarize that using a picture:
Areas — purpose of each layer
Another way to think about it:
- Primary-Content area (TL + primary content) is all about what the user is looking for. In each screen there should be a designated primary-content, so in each screen you need to have a primary-content area.
- Context-aware area (ML + elements about content) is the place where the user can find the elements to interact with the content area or are related to it;
- Navigation area (ML/BL + navigation controls) is the place where the user discovers how to navigate through the app;
- Home area (BL + home controls) is the place where the user can be confident, and find the roots of the app (account, settings, search, etc.).
Principles
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:
- Areas are surfaces that display the content;
- Areas are living elements: they can move and resize;
- Areas transform themselves to adapt to the content they display;
- Each area has a purpose, and it sticks to it;
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:
- from the home-page (with a primary-content area which displays a grid of videos; a navigation area with a list; and a home area with a home-button, account-button and search textbox),
- to the detail-page (with a primary-content area which displays the video and it’s details; a context-aware area with a list of comments about the video; and the same for the home-area)
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.
Example case
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):
- A search textbox
- Navigations controls (Explore, My Music, Recommendations, etc.)
- Account button
- Settings button
- A right part with the artist and its content (picture, bio, albums)
- A bottom bar with controls of the current playing song (play/pause, next, volume, etc.)
This case is pretty simple, based on the areas we’ve defined before. We can set four groups:
- Home area, with the search box, the account button and settings button
- Navigation area, with all the navigation controls (Explore, My Music, Recommandations, etc.)
- Primary-content area for the artist-related content
- Context-based area for the controls of the current playing song (play/pause, next, volume, etc.)
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
- The home area (at the top — in red)
- The navigation area (on the left — in blue)
- The primary content area (on the right — in green)
- The context aware area (at the bottom — in yellow)
Conclusion
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.
What’s next?
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.