Guo Xiaoxing
Weibo: Guo Xiaoxing's Sina Weibo
Email:[email protected]
Blog: http://blog.csdn.net/allenwells
Github:https://github.com/allenwells
One of the first steps in designing and developing an app is deciding what users can see and do in the app, and once we know what the user is interacting with in the app, we can design the user to switch, enter, and rewind between different pieces of content on the app.
One more window layout
The small size screen is only suitable for each display of a single vertical content window, a list or list item specific information, on this device, the interface usually corresponds to a level of information level, such as: Category-List-details.
Large screens often have more usable interface space, and they can display multiple content windows, and we often use multiple windows to avoid the interface leaving too much space and some awkward interactions (for example, to fill in the blanks and design a very long or wide button).
Here's a look at some of the issues that often arise when migrating UI designs to large screen sizes:
Example 1
Problem description
Large horizontal screen using Single window resulting in blank and too long line
Solution Solutions
With a horizontal multi-window layout, this results in better visual balance, utility and readability.
When the decision is made to differentiate between a screen size baseline using a single Window layout and a multi-window layout, we can provide different layouts for different screen size bands (for example: Large/xlarge) or the lowest screen width (for example: SW600DP).
A single interface is implemented as a subclass of activity, and a separate content window can be implemented as a subclass of fragment. This maximizes code reuse across different structural factors and different screen content.
Two for different plate direction design
When you start to lay out UI components on the screen, a multi-window layout behaves well on a horizontal screen, because there is a lot of available horizontal space available, but the horizontal space is limited on the vertical screen, so you need to set a separate layout for the vertical screen.
2.1 Telescopic
The width of each window is scaled to fit the contents of the vertical screen, the window can be fixed width or a certain percentage of the usable interface width, as shown in:
2.2 Expand/collapse
When you collapse the contents of the left window in the vertical screen, the policy is effective when you encounter the left window in the total/Sub window that contains the collapsible list item, as shown in:
Example
Take a live chat app as an example. On the horizontal screen, the list on the left contains the photos, names and online status of the chat contacts. In the vertical screen, the horizontal space is folded in a hidden name, showing only the photo and the hint icon for the presence of the online status. Optionally provides an expanded control, which allows the user to expand the left window or the opposite operation.
2.3 Show/Hide
The left window is completely hidden in the vertical screen mode, in order to ensure the equivalence of the interface function, the left window function must be visible, for example: Add a button in Actionbar to display the left window.
2.4 Stacking
This strategy works well when the vertical screen is stacked vertically and horizontally, while the window is not a simple text list or there are multiple content modules running concurrently with the Basic Content window.
Three-combination interface 3.1 down navigation
Display level navigation is a way to view the overall application picture.
-Navigate down: Allows the user to enter the sub-interface.
Landscape navigation
Landscape navigation allows users to access the sibling interface.
There are two types of sibling interfaces, as follows:
- Container Association: The interface shows those items that are placed in the same container by the parent interface.
- Block Association: The interface displays information about different parts of the parent interface.
Dashboard mode
Dashboard mode is a kind of mode that usually takes button as main to get different application partition module. A dashboard is a large icon button table that represents most of the content of the parent interface. This table is usually 2 or 3 rows or columns, depending on the top level of the app. This mode shows a rich visual effect on all blocks. The huge touch controls also make the UI particularly handy. When each chunk is equally important, the dashboard pattern is best used. However, this model does not work well on the big screen, he lets the user directly obtains the APP content to take one more step detour.
Grid mode
Vertical Slide
List mode
Horizontal Slide
Stack mode
Card
tab mode
tab mode allows you to combine sibling interfaces, which can embed sub-interface content that could otherwise be a different interface, and tab mode is suitable for small chunks of the block-related interface.
Advantages of Tab Mode:
- There is only one selected Activity tab, and the user can immediately get the tab content from the interface.
- Users can quickly navigate within the relevant interface without having to revisit the parent interface.
Note :
- When you select tab is skipped, tab should remain intact, only the specified content area is changed, and tab is available at any time.
- tab switching does not count as history. For example: If the user switches from tab A to tab B, pressing the back button should not re-elect tab a. Tabs are usually arranged horizontally, but sometimes other tab representations, such as the drop-down menu for Action Bar, are also possible.
- The tab should correspond to the content at the top of the interface.
- When switching tab, it is important to make sure that the switch is immediate. Do not load a confirmation dialog box to block tab access.
Swipe view mode
Swipe view mode is the horizontal paging mode, which is best used on the sibling interface associated with the container, for example: Category List technology, finance, or news. This mode also allows the composition interface, the parent interface, to embed the content of the sub-interface within the layout.
In the horizontal paging UI, only one sub-interface is shown at a time, and each sub-interface is called a page. Users can navigate to the sibling interface by touching the screen and dragging in the direction they want to access the adjacent page. To supplement this gesture interaction is usually prompted by another UI symbol for the current page and accessible page. This helps the user to discover the content and also provides more contextual information to the user. This is necessary when the sibling module associated with the chunk uses horizontal navigation of this pattern. These hint elements are shown in the following way:
Time Navigation
Time navigation, or navigating between historical interfaces, is a long-standing Android system. Regardless of other status, all Android users expect the back button to take them to the previous interface. The historical interface set is all based on the user's launcher application (the "Home" key of the phone). That is, you should return to Launcher after pressing the back key enough times, and then you won't do anything.
Example
Enter the email app from the Contacts (contact) app and press the back key to act as shown:
The application itself usually does not have to consider managing the back button. The system automatically handles the task and back stack fallback stack itself, or is called the History interface list. The Back button defaults to the reverse access list, and then removes the current interface from the list when the button is pressed.
But there are always some examples where we may need to rewrite the back behavior. For example, the screen contains an embedded web browser in which your users can interact with the page elements to navigate between pages. We may want to trigger the default back action of the embedded browser when the user presses the back key of the device. When you reach the starting point of your browser's internal history, you should follow the default behavior of the system back button.
Navigate Up
Android 3.0 introduced the up notation, click Up and the user will be brought into the parent interface in the structure. This navigation usually goes to the previous interface (as described in the previous Back button discussion), but not always. Therefore, the developer must ensure that the up will navigate to a given father interface for each interface.
In some cases, up is suitable for performing a behavior rather than navigating to a parent node.
Take the Gmail app on the Android 3.0 tablet as an example. When you view the conversation of a message, the device is placed flat, and the conversation list and the conversation details are displayed side by side. This is a parent, sub-interface combination in the previous lesson. However, when the message dialog is viewed vertically, only the conversation details are displayed. The up button is used to slide the parent window into the screen display. When the left window is visible and then press the up button again, a single conversation goes back to the full-screen conversation list.
Example
Enter the email app from the Contacts app and then press up to navigate the behavior as follows:
Copyright NOTICE: When we seriously to do one thing, we can find the endless fun, colorful technology like the scenery on the road, while walking to appreciate.
Android App Development technology: User Interface interface navigation design