On the big screen, navigation or navigation is the two typical design patterns, but these two patterns are challenged on a small screen. In the increasingly popular response design today (Translator Note: In fact, has been popular for several years), we need to re-examine the small screen environment for navigation design patterns. These page navigation through mobile devices must be convenient for users to quickly access, but not too prominent.
Below, I have listed 7 common design patterns for response navigation, namely:
Top (or "drift")
Footer Anchor Point
Each of the above design patterns have advantages and disadvantages, everyone in the selection of navigation design plan, we need to judge according to the actual situation of the project.
Top (or "drift")
Navigating the top of the navigation or letting the navigation flow with the layout is one of the simplest ways to achieve navigation. Thanks to this easy to implement approach, it has also become "standard" for many of today's responsive web pages.
Easy to implement: consistent implementation on large and small screens
No need to break the original CSS style
There is no need to disrupt the original order of the content: this way it ensures that it is completely fluid, without the slightest human intervention.
Occupy Space: Height problem is the core problem on the mobile end. Luke's "content first, navigation second" in his book is a typical mobile-end Web experience. We all expect users to get content as quickly as possible, which means that we need to remove the navigation to ensure that the user's focus remains on the core information. And when the navigation height is too large, resulting in the screen of the core information can not be displayed, it will cause users confusion. As shown in the following figure, when we open a page, the entire screen is occupied by navigation, the user can not get valid information. [Top Navigation on small screen automatically folded line display] 
Poor scalability: What happens when you add a chapter when your navigation is displayed just in one row? What if a customer suddenly asks for an additional navigation category called "Products and services"? Or does translating a navigation title into another language result in a change in character length? All of these things will destroy the original design plan.
Coarse finger: Navigation all crowded together, thick finger is anxious, how point also can't point to oneself want to visit the navigation chain, this increases the chance of misoperation (not suitable for small screen through the finger to click operation)
Cross-device issues: Different devices are rendered differently, and great pages on the IPhone may be poorly performed on other platforms. [Differences in rendering on different devices] 
Footer Anchor Point
Leaving only one anchor point to the bottom of the page, it's a flattering way to place the navigation in the footer. It saves valuable space in the head while satisfying the need for access to navigation.
Disadvantage: User confusion: Quick jump to footer This action is easy to confuse the user with lack of elegance: this is strange to say (the translator also has the same feeling), but I (the author) think the interaction of similar switches is more sexy. This approach to anchor-point jumps is practical, but not elegant, and is too rough to interact with carefully designed mobile-end applications.
It's a good way to include navigation in a control that selects the menu. It avoids the screen space occupied by the navigation.
To free up enough space: a choice menu is either horizontal or vertical in a special province space to conform to user habits: compared to the bottom of the way, users more accustomed to navigation is placed in the head of the page is easy to identify: Drop-down Menu control style is very conspicuous, and easy to find support for localization of the interaction: because of the standard control Makes the operation very localized, which refers to the device's own properties of support, such as on the touch device can be clicked, and on the trackball support rolling operation;
The implementation of the switch is similar to the footer anchor point, but not click to jump to the footer, but click on the menu area to expand. It is also easier to implement design patterns.
Easy to understand: compared to the footer anchor point jumps Suddenly, switch this is the position of the same interactive way easier to allow users to accept the interactive more elegant (compared to the jump) strong scalability: The only thing you have to do is to hide the switch on the PC side, at the appropriate breakpoint at the show it, all of this can be achieved through CSS.
The sideslip was popular with Facebook's big push. The reason the drawer comes from its interactive effect, when the menu button is clicked, the navigation module slides from the edge of the page like a drawer.
Ample space: because it slides out of the edge, it is understood to look good in an infinite area at the bottom or outside the screen: Simplicity is beauty and animation is stunning.
Small audience: Compared with other simple design patterns, the effect of sliding the navigation bar from the side requires a number of complex animations to achieve, so that some low-end equipment in the doorway. Therefore, if your project is designed for the general public, you need to be cautious. Poor adaptability: This model is only suitable for mobile devices and is not performing well (and not necessary) on a large screen. There may be confusion: when I first saw Facebook adopt this design, I thought the page was wrong! Exposing some information on the right side of the screen it's strange to me (purely the author's personal opinion).
Position navigation only in footer
Just place the navigation and footer anchor points in the footer, except that it does not place anchor points in the header. The concept of this model is content first, navigation second. This way, you need the user to slide the page to the bottom to see the navigation
Disadvantage: Difficult to find: whether in large or small screen is difficult to find the footer will have navigation; Difficult to use: mobile end users need to constantly scroll the page to the bottom to use the footer navigation, very inconvenient
Related cases: Pears fray
Hide the navigation and get the maximum space.
This design pattern follows this rule: do not punish users who visit your site via the mobile end. It's still a mystery what the mobile end user wants or doesn't want. Mobile-end users do what any desktop user does, so it is necessary to provide some core functionality only for mobile-end users.
Advantage: Cock Burst (original Sexy as hell to seek great God letter of the translation)
The perfect use of limited screen space
For mobile devices, there is a great advantage, just slide down to see more.
Disadvantage: It is not good to remove links or content from the core features or content of mobile-end users. Response advocates argue that this can lead to differences in content between mobile-end pages and desktops, as well as experience disasters.
Add extra cost to the page using the command Display:none only hides the element on the page. The page's code, pictures, or other files are still downloaded in the background, which eventually leads to slow page access.
It is difficult to maintain two completely separated navigation system will become the burden of later maintenance.
There may be a confusing move-side user sliding down the page to refresh the list without realizing that when I first saw Facebook adopt this design, I thought the page was wrong! Revealing some information on the right side of the screen is still strange to me (purely the author's personal opinion)
Mobile navigation just like your real friends: need each other, but give each other space; and those who pretend to be close to you always disappear when you need it (when you need navigation) or occupy your personal space to make you crazy (such as: wipe, roll from my bed); therefore, design for responsive navigation , you need to balance the portability and space of your access.