[MUSIC] Hello, this lecture continues the discussion started in the previous one. I'd like to start it from the pattern that is called differently onto platforms. A more familiar name for iOS is tab bars. For Android, bottom navigation bars. Further in the discussion I will use the second name, since the name tab bars intersects with another pattern and can introduce confusion. This solution allows users to quickly navigate between categories of content or functionality. The number of tabs can vary, but in this respect, the behavior of this pattern in Android and iOS, varies. In iOS the number of visible tabs varies depending on the type of the device, smartphone or tablet, and screen orientation. If some of them do not fit horizontally, more tab appears, where the remaining items go. If the user selects more tab, the items are displayed as a list. On Android this behavior is not provided, I mean the standard Android control. Of course, the more tab can be implemented on Android, but you need to understand that this is an unusual solution for users of this operating system. On android the bottom navigation bar has another feature. If on iOS, all tabs should be represented by icons with labels or just icons at the same time. Android has a standard solution where only the highlighted tab has a label. On both platforms the bar is hidden when the keyboard appears. It is recommended to use the bottom navigation bar only as a top level navigation. Another important point is the presentation of tabs. Do not remove them from the bar if the functionality that is in this tab is currently unavailable for some reason. Missing tabs will make navigation for your app less predictable. As a solution, you can allow the user to drill down to the tab, but inside explain why there is nothings here and what needs to be done to make the functionality available. The next pattern is called Taps on Android, and segmented controls on iOS. iOS guidelines recommend using this solution only to display different categories of the same content. For example, in the Mailbox application for iOS, a mail client from Dropbox, which, to my regret, is shut down at the moment, the segmented control was used to display snooze, current and achieved emails. In iOS Maps, a segmented control lets users switch between Map, Transit and Satellite views. In Android the use of tabs is somewhat wider. In addition to displaying several categories of the same content, on this platform tabs can be used as an analog of bottom navigation bars. For example, in the YouTube app, the first tab contains a customized user's feed. The fourth tab contains information from the profile, the browsing history, modification settings and so on. Unlike iOS, Android have scrollable tabs if their number is large. On iOS it's recommended to use tabs with text or icons. On Android a combined version is also available. Embedded in tabs in-action bar, which allows you to save screen space, is now not recommended for Android. When you scroll further content, action bars goes up and the tabs remain on the screen. Navigation drawers, also known as hamburger menus, are quite popular on the Android platform. The use of this pattern is advisable when key user scenarios are implemented through the main screen, and other scenarios are significantly less important or rarely used. The reason is simple, since all menu items are hidden in a side bar, user does not see where they can go yet. Note that if your app uses this solution, the side bar must be open when the user first enters the app. Firstly, it will allow the user to understand how this menu works, if she hasn't previously encountered it yet. And secondly, it will show all features of your app, that will increase engagement. The behavior of the menu button when navigating a child screen may vary. Some applications, such as Dropbox, leave the menu button visible. To return to the previous screen in this case, users can tap on the system button back on Android, or use swipe gesture on iOS. This solution allows users to quickly move between the top level categories of content. Don't forget to save the state of a user interface in each category. The second option is to hide the menu button and display the up button, as in Play Store. Recall that the behavior of the button up and the system button back, on Android, is different. It should be understood that both options demand more effort from users to be able to navigate between top level categories than when using the bottom navigation bars. However, bottom navigation bars consume a lot of screen space compared to drawers. I will tell you about different variants of navigation drawers on tablets a little later. The next navigational solution is content-driven navigation. An example is drill down navigation of the iOS system settings app. When a user goes to a child screen, in the top panel, which on iOS is called navigation bar, and on Android app bar, the bottom with the arrow appears. On iOS it's often provided with the title of the previous screen. Content-driven navigation can be implemented with a variety of layout patterns and various UI controls. Float, in-action buttons, images, list items and dashboards, cards, different kinds of menus, etc. All these can lead to opening a child or sibling screen. Child screens can be linked, for example, screens of accounts in mobile banking app, or can be independent, as screens of iOS. All the previously described patterns can be applied to both tablets and smart phones, but the palette of navigational solutions for tablet is slightly wider. For example, on tablets permanent navigation drawer can be used. It's always visible and pinned to the left edge of the screen. It can be attached to the left of or under the app bar, as well as displayed on the floating card if the number of items is small. The persistent drawer can be minimized, in which case it will look just like the solution we discussed for smart phones. In the expanded state, if tabbed to the right of the menu, the drawer will not disappear. The mini variant inquire that icons of all menu items are displayed in the minimize state. The advantage in comparison with the previous option is the possibility of a faster transition between screens. And at the same time, the mini variant takes up less screen space. It should be noted that there is non-standard version of this solution, which can not be expanded, it's constantly displayed on the screen. Icons with labels below them or simply icons can be used. In many mobile apps, solutions that we've discussed are combined. In order to successfully combine the solution, you need to understand which of them do not get along well with the other. Firstly, it's tabs and bottom navigation bars on Android. Since tabs are used on this platform as an alternative to bottom navigation bar, applying both patterns on the same screen can mislead users. Which one is the first level navigation and which is the second one? I do not recommend that you combine these two solutions. Secondly, despite the fact that it seems obvious, if you cannot find a section in bottom navigation bar, you should go and check out a drawer. I would not recommend to use these two patterns together, it's too much navigation on the screen. Thirdly, persistent and permanent navigation drawers are not recommended for apps with multiple levels of hierarchy that require using the button up for navigation. Of course I did not list all the existent solutions. The design of navigation is no exception, it's extremely important to consider as many alternative solutions as possible. Hamburger menu to the right, screen cartons, different variations of cover flows, tabs, in-action bars, etc. When designing, do not be lazy to take a run at mobile UI catalogs like inspired-ui.com and design communities like Dribbble, Behance, etc. These can help you find the best suitable solution. In this lecture we have discussed two ways to represent the structure of user interface and have discussed a number navigational patterns that you can use in your app. Thank you, see you in the next lecture. [MUSIC]