When it comes to "informing users of their location" in web design, the first control that comes to mind is the breadcrumb. It not only tells users where they are but also clearly displays the hierarchical level they are currently in. Of course, there's another control that can "inform users of their location"—the browser title. Both of these controls rely on—navigation. Typically, the design of a website combines these three controls to achieve the goal of "informing users of their location."
- Navigation: Provides an overview of the website structure.
- Title: Informs the user of the current page.
- Breadcrumb: Indicates the user's position within multiple levels.
An excellent product design should not have too many layers, much like the movie *Inception*, where too many layers can make people want to escape back to the first, simpler layer. Fortunately, one of the biggest advantages of PC-based internet is the abundance of space. So when all three controls are placed on a single page, we almost achieve the ability to jump around freely without getting lost, as shown in the following image:
When you first enter the subway, just by seeing the global map, you can choose your destination and board the correct train. Once you're inside the subway car of Line 1, the station light indicator can show the train's route, so you always know where you are.
Today, our main discussion focuses on how we can inform users of their location through design in mobile internet. We know that mobile devices have an inherent limitation—small screens. Despite the continuous increase in screen resolution (240x320, 480x320, 800x480, 960x480), the physical size of the screen hasn't changed much, with 3.5-inch screens being mainstream. Therefore, the three treasures from PC internet used to "inform users of their location" cannot all be fully utilized.
- What is the current page? The title must be retained.
- Navigation takes up too much space—just place it on the home page.
- Breadcrumbs? With too many levels, they simply don’t fit and take up valuable space. Do users really need breadcrumbs? This dependency depends on what?
1. **Simplify the requirements first.**
In a mobile state, do not port all the demands from PC internet to mobile devices. To some extent, this allows us to extract the most needed and useful demands for users. For example, consider the Baidu Knows product. On PC internet, you can search for answers, ask questions, answer questions, define problem categories, go to the Knows Mall to exchange items, complete Knows tasks, participate in Knows teams, and join the Knows community. However, when designing for mobile devices, the above demands need to be filtered. The core demands are searching for answers, asking, and answering. Satisfying these three core needs largely completes the majority of work involved in transplanting Knows to mobile devices.
2. **One interface for one task.**
This is the philosophy behind designing task flows—do not cram everything onto one interface. Interaction designers have found that the tab system commonly used in web design can solve this problem. Thus, content-focused applications, such as news apps, use similar tab controls, even allowing left-right swiping. Additionally, iPhone has a tab control in the title area, and Android has a similar tab control in its label bar. However, due to horizontal width limitations, tabs cannot be excessive. Therefore, we need to simplify and cleverly design the framework. Personally, for multi-level product structures, I recommend: 16-grid interface > label bar interface > title area tab interface > left-right swipe tab interface. From the overall to the details, if four tab levels cannot accommodate the content, then it can only be said that your application is too bloated.
3. **Find the way back.**
In iPhone interface design, there is a "back" control in the title bar area, allowing you to return along the same path at any time. Sometimes, developers also place a quick return-to-home button. On Android, the back physical button is typically used to return to the previous operation. However, through practical operations, we find that the Android back button differs somewhat from the iPhone "back" function. The Android back button not only records user operation paths but is also used to "cancel" certain actions. For instance, pressing the menu button brings out the menu, and pressing the back button retracts it. When users are unsure how to operate, they often press "back" to return to the previous step. On iPhones, the "back" button simply returns to the previous interface.
——(Personal opinion: The Android back button simultaneously handles undo and back functions, which can cause user confusion. Through design, we find that in some interfaces, it is difficult to prompt users to "return." That is, we must reach a consistent understanding with users—if you need to return or cancel, use the back button. However, some Android phones on the market now lack a back button, such as Lenovo's LePhone. But the LePhone supports full keyboard components. Another viewpoint exists that users should not switch between the application (touch interface) and the device (physical buttons). However, those who hold this view often struggle with inconsistency with system operation habits.)
Considering development costs, we adopt this solution—using mature interaction controls from iPhone, while matching "back" and "cancel" functions with the back button on Android, keeping them visible on the interface. Later, I will share more about the similarities and differences in the title area. ——Sorry for digressing into another topic.
Now returning to the point: actually, directly showing navigation and content to users on mobile devices is not a good experience, as navigation occupies too much space. Therefore, we only need to provide an entry point for users to view the navigation, such as Home or Menu. On iPhones, there is usually a dedicated toolbar to house this button. On Android, we simply use the physical Menu button.
Reflecting on designing applications for both iPhone and Android platforms, we've thought a lot about how to let users clearly know where they are. Summarizing in one sentence—it’s about skillfully using the TAB hierarchical structure and always giving users a quick way to return to the home page (or see the navigation).