The premise of mobile web development theory is to keep one code base across multiple platforms. Still, it is important to look at different design aesthetics that power the differences between each device. By paying attention to the details and designing your app to look and feel like a native app on a platform, you provide a much better experience for your users.
When designing for mobile web, you need to account for the bandwidth limitations of cellular networks. Certain processes may take no time at all to complete on a desktop web browser, but everything is different on a mobile device. As a best practice, always display the progress of some action on the screen. This can be done with a loading symbol or other methodologies. Without seeing this loading box, users may get discouraged with your app if they do not know whether it is currently loading.
IOS DESIGN PATTERNS
With iOS, typically most applications have two navigation bars: one at the top indicating the page you’re currently on, and a navigation bar at the bottom, which has links to different pages. Prior to iOS5, there was no way to keep your top and bottom navigation bars static when the user scrolled the inner content between them. Now, by using the CSS3 property, overflow-scroll: touch, developers have the option to create native-like scrolling within their web applications.
ANDROID DESIGN PATTERNS
On Android devices, the general design pattern is to have an action bar at the top of the screen followed by a navigation bar immediately below it. Android devices typically lack a bottom navigation bar like those on iOS. This is because most Android devices have native buttons on the bottom part of their devices. When the navigation bar is placed on the bottom of the screen, Android users tend to hit them by mistake when pressing the native buttons on the actual device.
Typically with a webpage on a mobile device, users are going to pinch and zoom to their heart’s delight. When developing mobile applications, you use an HTML meta tag called viewport. This enables you to set a maximum or minimum width, depending on screen resolution, so the user cannot pinch and zoom on your web app. The viewport is set at the <HEAD> in an HTML document and supports the properties discussed in the following list:
- Width: The pixel width of your web application. The default value is 980. (Example: width=320)
- Height: The pixel height of your web application. (Example: height=320)
- Maximum-scale: A floating-point number between 0 and 10 to which defined that largest scale on your web application. The default value is 0.25. (Example: maximum-scale=0.25)
- Minimum-scale: A floating-point number between 0 and 10 to which defined that smallest scale on your web application. The default value is 1.6. (Example: minimum-scale=1.6)
- Initial-scale: A floating-point number between the minimum-scale and maximum-scale. (Example: initial-scale=1.0)
- User-saleable: A Boolean result that defines if the user is able to scale the size of the screen (for example, by pinch or zoom). The default value is True. (Example: user-saleable=False)
It’s important to note that all width and height settings can be defined by device-width, which enables the HTML5 to adapt the width to the device’s screen size. Following is an example of a viewpoint tag that can be used in a mobile web application.
content=”width=device-width; initial-scale=1.0; maximum-scale=1.0;
The preceding code sets the document’s width to be the device’s screen resolution. This is useful because users may decide to load the application onto a device such as a tablet, which has a large screen resolution. The scale is set to 1, which means it will scale to the device width. A good way to visualize scale is to consider it a multiplier against your width. (See Figure 1-1.)
Figure 1-1: If you set your initial scale to 2.0, your app is increased by two.
The user-saleable property, by default, is set to True. For most web applications, you don’t want the user to be able to pinch and zoom the content. This is because most native applications do not use this particular property; and their interface design scales to the current device. After all, if you correctly set your initial-scale, there is no need for a user to pinch and zoom on the app: Everything scales to the screen width. It’s important to note that this viewport applies only to the initial page load, and can be changed by the user. Once the user reloads the device it returns to the last-known zoom.