Mobile Web Front-end R & D process

I have been engaged in mobile Web Front-end development for nearly a year. In this short period of time, I learned from the experiences of previous generations, such as the circle center and yuyu, and made constant explorations and practices, summarize a set of mobile Web "R & D processes ". Why is "R & D" rather than "development"? It will be explained below. First, let's take a look at the flowchart of "R & D:

1. Why is it called the "R & D" process?

We know that for traditional Web Front-end development, we usually need to pay attention to the following operating system/browser situations:

Operating System: Windows/MACOs

Browser: IE (6, 7, 8)/Firefox/Safari/Opera/chrome

The basic information of these operating systems and browsers is as follows:

Relatively stable market share and use Distribution

Relatively open, vendor support for developers is better

Browser rendering varies slightly in different operating systems

After long-term research and summarization by front-end developers, their rendering features and standard support are widely known.

In the mobile Web Front-end development field, the situation is quite messy. What we need to pay attention to is much more complicated:

Operating System (Platform): Symbian (s40/s60/S80/S90)/iphoneos/Android/Wm (wince)/MTK/Linux/BB/palmos/maemo (meego )...

Built-in browsers: Symbian/chrome lite/iPhone Safari/MTK/ie mobile/BB Browser/Opera (OEM )/...

Third-party browsers: Opera mini/opera mobile/skyfire/netfront/ucweb/QQ Browser/go Browser /...

The basic conditions of these operating systems and browsers are:

The market share and use segment are unstable. New Models and browsers can easily occupy the market.

Most of the built-in browsers are not open enough, and the operating system and browser vendors do not provide adequate support for developers.

Different operating systems, different browsers, different browsers under the same system, the same browser under different operating systems, or even different versions of the same system or browser, these results may cause huge differences in the page effect (this is actually a form of arrangement and combination)

Due to the scarcity of compatibility research (especially in China), coupled with the closed and changing operating systems and browsers, our knowledge of their features is also basically blank.

After comparison, we can quickly find that we want to make our mobile Web perfect on more clients, we need a lot of time and effort to understand and master the features of various operating systems, platforms, and mobile browsers. We only have a certain understanding of them, we can further control mobile Web compatibility development.

Therefore, "R & D" includes "operating system, browser research" and "mobile Web development.

2. Gradual and periodic research

As mentioned above, it takes a lot of time and effort to study the operating systems and browsers of mobile devices. Rome was not built in one day, nor did it become a fat man. We need a step-by-step process, a long-term research, and a bit of experience to gradually understand these features. In addition, mobile devices are updated frequently, and new models and browsers are changing rapidly. We also need to follow up on the latest developments in stages. Therefore, this is the reason for periodic research:

Requires a lot of time and effort

Mobile device updates frequently

If there is only one mobile Web Front-end development, we recommend that you conduct a system study every six months to lay the foundation for compatibility development. In the next six months, the front-end development of mobile Web pages will be based on the results of this study. Generally, you do not need to perform compatibility tests on the pages. For compatibility testing, there are manyArticleAs mentioned in.

3. Compatibility testing

Compatibility testing is an essential step for both web development and mobile Web development. However, in terms of the process, the latter is very different from the former.

Web Front-end development tests browser compatibility after page development

Mobile Web Front-end development tests browser compatibility before page development.

Unlike a desktop browser, a mobile browser can easily view the page effect. Imagine that if the development process is the same as that of a Web browser, every time a mobile web page is completed, it is ridiculous to have a lot of testing machines to test and check the comparison results, find problems and modify them before testing!

Therefore, we need to use the compatibility test results to lead front-end development:

Test every common element of XHTML

Test every common attribute of CSS.

Test the basic features of JavaScript.

Test other mobile device-related points

After the test results are sorted out, we can use it to know what elements and attributes can be used, what can be avoided, and follow these usage conventions during development.

PS: for compatibility testing, you can also refer to the article about Shen Yu.

4. R & D process

(Note: If you are interested, you are advised to view the content in the flowchart)

The front-end development process of mobile Web is actually no different from the traditional front-end development process, as shown in the left-side section:

Product Design (PRD)-> prototype/mockup-> front-end (DEMO)-> backend

For the "R & D" process, the research process is added on the basis of conventional front-end development. The middle and Right sections are divided into five steps:

Data collection-> compatibility research-> General Front-end development process-> demo test-> Summary

Note that the "R & D process" and the general process are executed concurrently. That is to say, when we start the R & D process, we can generate the project requirements at hand without affecting the development cycle, we can also use projects to practice our research results.

Next, let's take a look at our main tasks and expected results in various R & D stages:

Stage 1: Data collection

The data referred here mainly refers to the access statistics of the Operating System/browser. Why do we need to obtain the data?

There are countless mobile devices in the world, and it is impossible for us to research the devices. Therefore, the purpose of data collection is to let us know the current situation of device shares, let's clarify which devices should be studied and which devices should be abandoned. Just like in web development, we still need to explore IE6, but we don't need to care about ie5 any more. As for information, it should mainly include the following areas:

Website access statistics

Domestic Market Share Data

International Market Share Data

The website's internal access statistics can be obtained through the company's relevant business intelligence departments; the domestic and international markets are external data and require some effort to search. In addition to making good use of search engines, you must keep an eye on some authoritative statistical stations. This is a few of my frequently used reliable/authoritative statistical sites:

CNNIC Internet research

Skynet Research

Yiguan International

Statcounter

IResearch Consulting Network

...... (PS. If you have a better statistics site, please share it with me)

When we get the information we need, the really challenging task comes: we need to put the raw data, analyze, compare, merge, and organize documents by appropriate scientific means to obtain a ranking document for brands, platforms, built-in browsers, and third-party browsers, provide reference for other data analysis in the future. Then, through this document, we will further sort out the model and browser Basic Plan for compatibility research. In this task, our identity seems to have been transferred from front-end engineers to data analysts :)

OK. Let's take a look at the deliverables after this task is completed:

Statistical analysis and summary of user devices-that is, Comprehensive Ranking documents

Recommended Solution for compatibility research-a basic solution for compatibility research

Stage 1: compatibility research

Before proceeding to this step, pay special attention to the following:

Are there any devices listed in our document in the company model library for our research?

Other people may be needed to help us with the test, so we need to make a comprehensive test plan.

OK. These two problems should be overcome. Generally speaking, the top-ranking mainstream mobile phones, even if not in the company's mobile phone library, should be better lent to other colleagues. The second problem is not a problem. Therefore, the power of the masses is infinite. We must learn to be good at scheduling available human resources. The three task flows in this step are as follows:

Design/update Test Point Set

Schedule compatibility tests

Record/sort test results

The test point package is the compatibility test page in general. We mentioned it at the beginning of this article, so we will not repeat it again. It is worth mentioning that, with the continuous update of devices and browsers, the update of the test set must also be a periodic task. At ordinary times, we should record some new features and omissions to be tested at any time, and update them during Compatibility studies.

When designing the test suite, we can refer to the resources provided by our predecessors:

W3C MWI Test Set workgroup

PPK mobile test suite

...... (PS. If you have better resources, please share with us)

The compatibility testing process is actually a very interesting process. During the test, in addition to recording the test results, we can also learn about other features of the mobile phone platform, operating system, and browser, and feel some settings, operations, interactive feedback, and other features, after a period of contact, you can even find a mobile phone to know which series of Symbian are available! Interesting.

After finishing the test results, we can further analyze and prepare a dangerlist document, which is specifically provided to interaction/visual designers. In this document, we will convert high-risk points to easy-to-understand text for designers to tell them what design elements should be avoided and how to do them.

For example, "designers and engineers should pay attention to avoiding disable (unavailable controls. If you want to implement a control that is not available, we recommend that you use the image representation or simply hide it ."

Delivery results of this phase:

Original Test Result table

Test result analysis and summary-visual/interactive guidance Solution

Stage 1: General frontend Development Process

There is nothing to say at this stage. The front-end development of the page is based on the research foundation in the previous step. For front-end development specifications and technical documents of mobile Web, refer to oma, W3C mobile web best practices, and developer's home basic tutorials. The deliverable of this step is the legendary demo.

If this project involves changes to the front-end architecture level (such as major revisions), you need to update the front-end architecture of the website and remember to update the standard DPL in the last phase.

Stage 1: Demo Testing

In this phase, we will make a final confirmation of the page and research results. Note that the nature of the test here is completely different from that of the previous compatibility test. In this step, you only need to select several most important models and open our demo page in a browser for visual comparison to see if the expected results have been achieved. If a problem is found, you must first locate the problem and return to the previous step for bugfix. If the problem is due to a problem missing from the compatibility test, you can immediately record it, and the next update of the test suite.

If no problem is found, it is transferred to the last stage.

Stage 1: Summary

This last stage is often a stage that best reflects the value of our research. We must calm down and repeat and summarize the research processes and results of all previous stages, and classify them in different categories. Generally, there may be the following aspects:

Specification (DPL) Update (if specification changes are involved)

Interaction and visual specifications

Frontend specifications

Knowledge Accumulation and summary-you can try to build a knowledge base or Wiki

Share

Of course, these are just some personal suggestions. In fact, there are still many meaningful precipitation methods waiting for us to try.

5. Others

If you insist on seeing this, admire your willpower.

Based on the descriptions of all these processes, we may also find the following points to note:

The data collection process seems simple, but is actually the most tedious and important step. It is the original basis of the entire R & D process. If this step is not completed or incorrect, the quality and value of the entire R & D result will be affected.

Compatibility research is the most important step and the core of the entire process.

How long does the process take? According to my previous experience, it may take at least one month.

The entire process is based on the fact that there is only one mobile Web Front-end engineer. If there are multiple engineers, the research process does not require periodic setup, and many difficult details can be solved.

Finally, I think the best combination of front-end human resources of mobile Web is two people. One person leads compatibility research, and the other person leads daily and project development. Two people can also switch jobs cyclically. In this way, research and development can go hand in hand, and the best state of concurrency can be achieved to maximize the value. Of course, this also needs to first check whether the company has such high compatibility requirements and whether it is willing to invest in this cost.