In my last , I’ve talked about different kinds of layouts that can be used for apps using and from the Fluent System. post acrylic depth Design I’ve shown 8 different layouts, from the to the _vertical tree-column layout layout_.In those two opposite layouts, the hierarchy of layers was structured differently: the first one was and the second one was .I’ve tried to mix those two different orientations to create different layouts which allow more complexity in the structure of apps. horizontal-lyoriented vertically-oriented 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 displayed on one screen, and a (taking into account the number of opacity variations that MS gives to the acrylic : 60%, 70%, 80% — even if I find that 3 layers is the right number). at least 2 layers maximum of 4 layers tool From top to bottom: The first and main layer is the ( ). It’s an , either white or black; top layer TL opaque layer The second is the ( ). This one uses tool from theFluent Design System, and the transparency is set to ; mid layer ML acrylic 80% The third is the ( ). This one also use and the transparency is set to bottom layer BL acrylic 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 different types of elements: 4 (ex: a conversation in a messaging app, or videos in a YouTube app). This is the main part of each screen; Primary-content . This part displays the different elements to navigate, e.g. a list like in hamburger menu, tabs, or pivot controls; Navigation controls , which are elements or controls that impact the content or are related to it (refresh, create a new message, details about the content.) Elements about content , which allows going to the account menu or the settings menu; Home controls 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 is used for the , and will always display the of the screen; TL content area primary-content The is used either for or . So it displays either s or ; ML navigation area content-aware areas navigation control elements about content The is used either for or . So it displays either or BL navigation area home areas navigation controls home controls Summarize that using a picture: Areas — purpose of each layer Another way to think about it: (TL + primary content) is all about what the user is looking for. In each screen there should be a , so in each screen you need to have a . Primary-Content area designated primary-content primary-content 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; Context-aware area (ML/BL + navigation controls) is the place where the user discovers how to navigate through the app; Navigation area (BL + home controls) is the place where the user can be confident, and find the roots of the app (account, settings, search, etc.). Home area 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 has a purpose. area 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 are surfaces that the content; Areas display are elements: they can move and resize; Areas living transform themselves to to the content they display; Areas adapt Each has a purpose, and it to it; area sticks 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 (with a which displays a grid of videos; a with a list; and a with a home-button, account-button and search textbox), home-page primary-content area navigation area home area to the (with a which displays the video and it’s details; a with a list of comments about the video; and the same for the ) detail-page primary-content area context-aware area home-area In this example, only the moves and resizes to to the new content (reducing its size to display just one video and giving more space to the ; and moving to the left to hide the and reveal the new content of the ). primary-content area adapt context-aware area navigation area 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 stays at the same place, and only the is changing on this , from the list-view of the recommendation-page to the detail-view of an artist. primary-content area primary content area So are living elements that display the content, but they are not constraigned to move when navigating. . areas 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: , with the , the and Home area search box account button settings button , with all the (Explore, My Music, Recommandations, etc.) Navigation area navigation controls for the Primary-content area artist-related content for the (play/pause, next, volume, etc.) Context-based area controls of the current playing song 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 , 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. post 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.
