Mobile Web Design: Suggestions and taboos in web design

Article Description: If you are preparing a mobile device version for your site, this article will be quite useful to you, in this article, will explore the mobile Web page coding design of the various techniques and considerations.

If you are preparing a mobile device version for your site, this article will be quite useful to you, and in this article you will explore the techniques and considerations of Mobile Web page coding design:

• For the user experience on the mobile device to be accepted, how the code is designed.
• What's the difference between a "Mobile Web" and a regular web site?
• Basic skills to make your site run successfully on mobile devices and desktop browsers
• Some suggestions and taboos in mobile web design, and a lot of resources

What's the difference between a Mobile web and a regular web site?

That's a good question – first, maybe we should start with the "What's mobile Web" question. After all, the mobile Web that users use to access on their devices is a separate part of the Web site they visit at home with their desktops. When I say "mobile web," I mean "web sites accessed through mobile devices."

In opera, our dedicated and created browsers allow you to view the entire network, regardless of whether the device is capable of browsing. As long as you're building a site with a little bit of detail, respect and web standards, you can create only one version of the site for all the devices – the only site. However, there are some exceptions – in some cases only a partial version of the site will work, and you'll see that in a few minutes.

The competitive environment in the mobile world is not balanced

In the desktop arena, the format is improving for our front-end developers – most modern browsers are already very well supported by Web standards, whether it's opera, Firefox (and other gecko kernel browsers) or Safari (and other WebKit kernel browsers), Even IE brings us less pain than it used to be. Although the number of IE6 users is still very good, but this should be due to the majority of the closed use habits and other factors. However, the mobile device sector is unusual in this regard:

• You have browsers that provide support for the full Web, like Opera Mobile and Safari on the iphone. Opera Mobile uses the same rendering engine as the desktop version, so it supports a similar standard.
• You have less-than-cool browsers, such as IE, which provide limited support for web standards. Some of them only support WAP (for example, Winwap), others support standards such as cHTML or HTML-MP (such as Imode browsers in Japan's NTT DoCoMo), and some support only limited subsets of web standards (such as NetFront, Pocket IE, and blazer).
• Finally, you have Operamini, as well as other browsers through the proxy mechanism. It is primarily a client interface for connecting users and a large server farm. When a user submits a URL, the client lets the server find the page. It then converts the page into a lightweight binary markup language, formatting it into a mobile device view, and sending it back to the client for display. The main advantage of this approach is that the page volume can be reduced by about 90%, helping users save a lot of bandwidth costs. This markup language indicates that Web standards do not perform well on mobile devices, because in this way of service, Operamini will not support ajax/javascript in some ways-there is a more detailed explanation here.

Note: Don't expect your super Ajax and Dom script animation sites to perform well on mobile devices. The degree to which JavaScript supports mobile devices varies widely. Offer graceful demotion at all times. One example of this approach is called Hijax.

As we can see, there are a lot of things you need to think about cross-browser compatibility in mobile devices. But don't be afraid – my subsequent suggestions will give you the right direction, and over time, the support of mobile browsers for standards will improve, and our front-end developers really don't need to worry about them anymore. When did you ask me when it would come true? Who knows!

Other restrictions on mobile browsers and those?

Of course, when developing a Web site on a mobile device, there are a number of other constraints beyond the browser's support for standards. The limitations of the device itself, you also have to consider. For example:

• Limited Control -don't just assume that your users will use the mouse to control everything on the page, and you should also provide keyboard choices. Some mobile phone users may not have something like the mouse, so a structure like this : hover and OnClick are useless to them (this is also very important for usability – some handicapped users may have some drawbacks with their hands). It's also important to design your form for your users – you may have felt the discomfort of using your phone to fill out the smelly, long, mandatory form. To solve this problem, try to show that lump of content in a Drop-down menu, which is more reliable than waiting for a word to be manually entered by a user: There are some local Shanzhai browsers that support Pull-down menus that may have varying degrees of problem. For example, based on the MTK system of Lenovo I61, by default, all options will be displayed, and in some cases will be distorted and "drift", you need to be more cautious when used. Also, it is a good idea to set a form with the most likely initial value.
• Limited Screen Size – Imagine what your wonderful 1024x768 design would look like in the 240x320 screen, or even the smaller screen, and what its usability would be. There are ways to deal with this – you can deliberately design the page in a very concise and fluent way, or you can provide a different page for your mobile device by using functional testing or media type detection (and so on). In addition to screen size, some phones may not need such trouble, they may provide "scaling mode" such a mechanism, but you can not guarantee this.
• limited memory and bandwidth -mobile devices provide significantly less available memory than desktops. Therefore, when you design your site, you need to be particularly careful about the large volume of photo albums, as well as the interactive streaming media video applications. In addition, some mobile browsers offer the option to turn off image display, but you can't be sure of that either.
• Limited Typography -I am, are you very infatuated with the typography on the desktop? You don't see the performance on your mobile device! Although there are many exceptions to this rule, most mobile devices have very limited choice of fonts, only one or two (like 1 or 2). This restriction is determined by the system or the browser.
• Limited Colors -some mobile devices also have very limited color support. Consider how much of your page experience needs to depend on the color and confirm that the contrast colors are still supported on the mobile device.

These constraints are the real reasons for the difference between the mobile Web experience and the PC Web experience. Do not deceive yourself, feel that your site on the mobile device user experience and desktop will be consistent-this is pure yy. Of course, it's still worth affirming that you're leaving the browser and doing everything you could to confirm the user experience.

The real way to ensure that your site provides a good experience for mobile users is to test, test, and then test! Some web designers have come to realize that in addition to their own mobile phones, desktops, and game consoles, a lot of mobile devices need to be ready on hand.

Different ways to solve problems

It is widely recognized that there are three ways to solve the problem of mobile development (which has been confirmed by Cameron Moll-look for his book). If possible, I suggest you try these three ways – as mentioned earlier, in opera, we stick to the idea of one web-but I also said that in some cases it is difficult or unnecessary. Here are the three methods:

1. Be sure to adhere to the Web standards
2. Create a completely independent mobile web site
3. Create only one site (a web), but add optimized code based on the devices and browsers that browse it.

Now, let's start by explaining these points one by one.

Adherence to web standards and best practices

The foundation of a good website is to have a good HTML structure, as well as wonderful CSS (performance) and JavaScript (behavior). If you follow the Web standards carefully, most mobile browsers will at least be well parsed and at least basically usable, which is very likely. For example:

• A web site that has a good HTML structure and no decorative images in the HTML, and is logically present in the mobile browser's single-column mode or mobile mode.
• If your form element contains a "label" element, the browser will render it more comfortable with the form area.
• If you use graceful demotion/incremental enhancements for CSS and JavaScript, the usability of the site can increase dramatically if browsers don't support, simplify, and ignore certain attributes.

If you devote your time and energy to research, there is more to be done to improve the mobile user experience. If your target audience includes users who use a large number of non-HTML browsers (such as some Japanese browsers that support WAP or cHTML), you may have to test the device and provide the appropriate content.

Provide a completely independent mobile web site

As mentioned earlier, I think we should try to avoid using this approach if possible. You can do device detection and automatically redirect to avoid causing trouble to users, but that means you have to maintain two sets of websites. The most important method is to identify the browser through UA sniffing, or perform device function detection on the server, and then provide the corresponding site to the user. In dev.opera.com, there are a lot of good articles about how to do it-see the final resource section.

But there are exceptions, for a completely independent web site – you have to always consider the user experience. Some types of browsing devices may not be compatible with specific Web sites or specific features. For example, there is a university campus network, with the department phone number of the search function, but also contains a lot of campus history pages. If you want to meet someone and you can't find them, you probably want to use the search feature on your mobile device, but you're not likely to want to sit down and read as many words as you go out there.

In this case, you can use some of the techniques mentioned below to provide a part of a feature in your Web site for your mobile device, or simply create a completely separate Web site for your mobile device. You just need to check the type of device the user is using and automatically provide it to the appropriate site, and the process is completely open to the user, but a lot of people do not want this function to put them completely limited, so if you want to do so, you have to provide users with a link to the full site, Users can choose whether or not to use it to access the full site.

A word of warning – device detection can easily be abused. You may often see a website with a desktop version of very cow B, while its mobile site is very rubbish. Because developers simply put mobile sites in a very low standard location. In fact, the target audience's device level is not balanced, now many mobile browsers have the ability to handle a complete Web page! You should try to get the equipment to do their maximum processing power, and play the special advantage of mobile devices, such as location-based Services (LBS), and Tel: protocol – It allows the device to dial a phone number when the hyperlink is clicked.

Provide only one Web site (a web)

It started to get interesting when you got here. You can again rely on server-side functionality to detect, but this time it is optimized on a single Web site, not redirected to another standalone site. There are a number of functions supported by the mobile phone database can refer to, such as WURFL. It is open in the form of an XML file that you can use to query the capabilities supported by the device before you design the optimized content. You can also query the UA string of your mobile device to find out the other details of these devices, such as whether there is a camera, how much screen size, and what kind of language it is.

On the client side, you've got two conditions required to optimize content for mobile devices – media types and media queries.

Media type (types)

As you know, you can specify different CSS for different purposes, such as:

<link href= "Main.css" type= "text/css" media= "screen" rel= "stylesheet" > <link href= "print.css" type= "
Text/css "media=" print "rel=" stylesheet "> <link href=" mobile.css "type=" Text/css "media="
handheld "rel=" Stylesheet ">

The handheld class's media type allows you to use an optimized version of the style (such as streamlined layouts and typography) for mobile devices. This is a very well supported mechanism and it is simple to implement, but it does have its drawbacks. As has been said before, it is often abused by developers to provide a crappy minimum standard layout for the site. In fact, Operamini recently changed the default type by using the handheld style sheet (handheld stylesheet) as the default for the screen style sheet stylesheet. Operamini can handle most complete Web sites, so it doesn't really need to use hand-held style sheets (handheld stylesheet). If you like, you can manually set back the move view in the Operamini browser option.

Media inquiries (queries)

A media query is an idea of CSS3 that is very similar to a conditional annotation-you can encapsulate a bunch of CSS rules into a media query and apply it to your tag structure, depending on a condition like "is the screen size less than 480px?" "Then put the code in, and the code looks like this:

img {
  margin:0 0 10px 10px;
  float:right;
}

@media all and (max-width:480px) {
  img {
    margin:10px auto;
    Float:none;
    Display:block
  }
}

You can even use multiple media queries, as follows:

body {
  max-width:800px;
  Font-family:georgia, serif;
}

IMG {
  margin:0 0 10px 10px;
  Float:right
}

. info {
  Position:absolute;
  left:8000px;
}

@media all and (max-width:480px) {
  img {
    margin:10px auto;
    Float:none;
    Display:block
  }
}

@media all and (max-width:240px) {
  img {
    display:none
  }
  . info {
    position:static;
  }
}

OK, in this example (the source code clicks here), the picture in the browser floats to the right when the screen is larger than 480px, the text wraps around the picture and leaves a bit of a comfortable distance through the outside (another information is hidden in the p element, and a class is named) Call Info -look at the HTML code. Text flow may seem a bit lame in some small screens because there is not enough room for the picture and quantitative text to be placed on the same line, so when the screen is less than 480px, the picture needs to be changed so that the text no longer surrounds it, but with Display:block let them show up in the middle of the walk. And so on-there's something more wonderful! If the screen is so small that you can't effectively show the picture, so let them disappear, and then let the hidden information show up in the picture, instead of the picture showing the text description-it's an alternative technique for conveying information to the reader, and it can also be used to provide the original text for those blind users who use screen readers, So that they can browse the website smoothly. Figure 1 shows three different browsing views, which are presented in different forms in browsers that support media queries (such as Opera 9.5).

Figure 1: Three different browsing modes in the example

Sounds good, but is there any shortage? Well, the browser's support for media queries is very limited at this point. Opera browsers support them, and Safari 3 can (as well as other modern browsers based on the WebKit kernel), but the Firefox 3 version is not supported, IE or other browsers do not. One way to solve the problem is to use a combination of media types and media queries. This method has been explained in my article. This is a workaround, but certainly not ideal. This should be improved in the future.

Summary Summary

That's all for now. I hope my mobile development world tour will help you. I am here to make a remark, if you want to study in depth, you can view the following resources.

Resources

• Mobile Web Design book, by Cameron Moll
• Designing and developing mobile Web sites in the real world-An instance study by Brian Suda
• Server-side capability detection for mobile devices by Brian Suda (contains information such as WURFL, UA strings, etc.)
• Ajax/javascript support in Opera Mini 4, by me
• Kristian von Streng Hã¦hre ' s Opera Mini request Header Reference
• How to serve the true content to mobile browsers, same by Cow B me-contains media types and media queries
• Creating safe media queries that work cross browser
• Web Design and Opera Mobile in mind, again by me
• The WURFL homepage
• The Opera Mobile homepage
• The Opera Mini homepage

English Original: Coding for the Mobile Web