Web Design Core issues 2:web design process (3)

web| Process | design | problems

2.9 Design phase of the split

The prototype design phase is most interesting for most web designers, as it starts to make the project take shape. At this stage, both the appearance and the technical prototype system should be developed at the same time. In any case, you should gather as much content as possible before you build a prototype system. The content itself can affect the site and help guide its formation. If the tone of the content is very serious and the appearance is very interesting and casual, the site will be very strange to users. Pre-viewing content helps unify technology and content. Also, consider that collecting content is one of the slowest aspects of site design. Participants in Web projects are actively involved in group meetings, but they are hard to find when they need to work on content. Missing content is definitely a big problem in Web projects. You should be prepared to deal with this problem in advance.

Recommendation: Collect the content of your site as much as possible before you design it.

2.9.1-Block combination

The design should be carried out from top to bottom. First consider how the user is accessing the site and how to end the visit. In most cases, this means designing the home page first, then designing the child pages, and finally the content page. Rule: The design should take a top-down approach, from the homepage to the child page, and finally the content page. First, create a mock Web page in block form on paper, as shown in Figure 2-5. The combination of blocks allows the designer to focus on the type of object and the organization that does not have to consider exact locations and details on the Web page. Block partitioning can help designers create page templates, which make subsequent implementations easier. Make sure that you create a composite block that satisfies the constraints of the Web browser window. The impact of browser boundaries is a very important factor. The combined effect of the page block is shown in h t T P://w W. Web d e S i g N r E F. C o m. /c h a P T e r 2/can be found. Once the combination of page blocks is well designed, other types of Web pages can be designed in the same way. If the complete scenario is already in detail, be sure that the path to each page block is logical. This way, you can proceed to the next stage.

2.9.2 screen and paper combination diagram

The next design phase is the paper or screen prototype phase. At this stage, the designer should draw a sketch or implement a combination of a typical web page. Whether on paper or on screen, be sure to consider the size of the browser window or screen. A piece of paper with a browser window outline used in the block combination phase can be used for sketching. Recommendation: When developing a composition chart, be sure to consider the border effect of the browser window. Sketch the buttons, headings, and feature pages for a variety of effects, and if possible, provide some textual explanations in the Web page, abbreviated text, or real text. Note that many designers use only some text-like objects in their screen combinations. While this approach is more useful for designers to focus on the elements of designing a Web page, if you can get real text, try to use it as much as possible to help emulate the final effect.

The combination phase provides a great space for creation, however, designers should be reminded of the possible limitations of the web to create, and also consider the requirements of the appearance of the Web specification, taking into account the size of the file, color support, and the H T M L style may be limited, which avoids the designer to come up with a very good looking but unable to implement the Web Especially to prevent the redesign of the site structure in pursuit of art. Remember, site planning clearly illustrates the appearance requirements, including marketing constraints. The 1th chapter has discussed the difficulty of balancing form, function, goal and content, and the difficulty becomes more apparent when designers attempt to satisfy their creative desires under constraints such as Web technology, user capabilities, and site requirements. A typical Web page combination diagram is shown in Figure 2-6.

When you create a prototype, you create a single image that displays the entire screen, including buttons, images, and text. Save this image in the image format of G I F or J P E G, and use the browser to load and test its effect in a typical environment. At this stage, you should try to avoid completely using H T M l to implement Web pages. You may have to discard the design and it will be wasteful to realize it again. Once the prototype on the paper or on the screen is complete, it should be tested with the user. Ask some users which buttons will be selected in order to accomplish which parts of a particular task will be clicked. Be sure not to show the prototype system to only one user because the individual's taste is an important factor in determining the acceptance of the prototype. If users have too many negative comments about the page, they should consider returning to the original design stage. In the prototype phase, you can't focus too much on your work. If so, the site will not be user-centric, but rather developer-centric. Keep in mind the following design rules:

Rule: Keep a distance from the prototype system. Listen to the user and refine the design.

Once you have an acceptable home page design, continue with the page design and content Web design. A typical sub-page combination diagram is shown in Figure 2-7.

For highly interactive sites, you may have to design a prototype Web page for a specific task such as the purchase or download of each step. This type of Web page must be designed in more detail and should include other very useful details such as the title of the form's input box. An example of a more interactive paper composition is shown in Figure 2-8.

Although not all sites require technical prototypes, highly interactive sites should not only consider interface prototypes, but should include conceptual prototypes that show how database queries, personalization, and e-commerce work. Unfortunately, in most cases, technical prototypes are not considered until the interface finishes, which usually results in duplication of effort.

2.9.3 Analog Site

Once all the prototypes have been completed, it's time to create a mock site or a l P H site. The implementation of the simulation site began with the combination of splitting and then using the H T M l to combine the pages together, or cascading style sheets. Use the template as much as possible, so the whole site will be a faster combination. Try to use symbols instead of text, unless there are some places where you need to use authentic text test scenarios. Once the mock up site is assembled, the site should be fully browsable, although it contains only empty content and empty interactions. An example of an analog site can be in h t T P://w W. Web d e S i g N r E F. c o m/m o C k S i t e found. In this sense, it is a good idea for some users to try this simulation site. See if the site is easy to browse and respond quickly. If users are having difficulty accomplishing some tasks, it is a good idea to consider discarding the design and return to the previous phase of software development. In general, this does not happen unless the site's security design or site rarely accepts user feedback.

2.10 Beta release Site implementation

Once the simulation site is acceptable, you can begin to implement the real site. The real content should be on the Web page, and the backend components and interaction elements should also be integrated with the final design set. There are too many techniques and implementation issues to discuss here, and 1th 0 chapters to 1th 3 will discuss these issues separately. Although implementation seems to be the most time-consuming aspect of the project, if all the artifacts have been collected and the prototype is implemented, the actual site implementation will be faster.

2. 11 Test

For most programmers, testing may be one of the least favorite aspects of web development. After all the hard tasks such as spec, design and implementation are completed, most programmers are just ready to release. This impulse should be prevented. Testing is critical to a positive user's overall impression. After publishing, do not push users to test the site. If they encounter a problem on a good site, they will not be forgiven. Be sure to remember the following design rules: rules: There must be some problems in the site, you must test your site well.

Unfortunately, testing a Web site is often simply a simple way to use a browser to quickly access a site, or to check the link body of a site. The problem will certainly exist in the site, no matter what. Unfortunately, most developers think that as long as the site looks fine, it's not a problem. Remember that in chapter 1th, site design is not just about design: you must test other aspects of the site at the same time, as summarized in the following rules:

Rule: Testing should involve all aspects of the site, including content, appearance, functionality, and goals.

　　Appendix B discusses the evaluation and testing of the site in detail, especially for the completed site. Here is a brief overview of Web testing. 1. Appearance acceptability test the appearance acceptability test can ensure that the web looks the same as the idea. Browse each page of the site to make sure they are consistent in style, color, and style. Browse the Web with different browsers and resolutions or a consistent browsing environment with the real user. Use the browser to quickly access the site to see if the style is consistent. While browsing the site, look for places where the style is irregular. The appearance acceptability test may require that each page be printed. Remember not to focus on print test pages designed for online consumption. 2. Functional testing Since most Web pages have the basic function of displaying themselves on the screen, functional tests and appearance tests often overlap in a sense. However, most sites include at least basic functionality such as navigation. Be sure to check each of the link bodies on the site and correct each disconnected link body. Broken link bodies should be treated as a very serious error. Be sure to test interactive elements such as forms. These two test conditions are usually based on reality and extreme conditions. Test the form by entering an obvious error. Keep in mind that users do not act as you think, and try to consider unpredictable situations. 3. Content Validation Site content details are important. Make sure all the content is appropriate and the usage of the word is consistent. Check for details such as product name, copyright date and trademark. Be sure to remember to check the spelling of the word. Customers and users will think the entire site is bad just because of a typographical error. This importance cannot be overemphasized. The best way to test is to print each page out and read each line carefully. 4. System and browser compatibility tests may be developed with system and browser limitations in mind, but must be validated when testing. When browsing the site, be sure to use the same type of system and browser that the user will use. Unfortunately, most of the testing systems are more powerful than the systems that users use. Project planning should have detailed browser requirements, make sure that the site with the specified browser access is very smooth. 5. Send a test to check if the site is sent adequately. Browsing the site under the real conditions of the user. If the site is designed for the "AOL" Modem user, create an AOL user account and test the speed of the site with a modem. To simulate site traffic, consider using test software to create a virtual user click Site. This simulates the response speed of the site. Be sure to use a real server and roughly the same system when testing. You must not underestimate the impact of site delivery. When designing a specification, the entire project may deviate from the track if it is not considered adequately. Refer to Chapter 1th 4 for more information on sending conditions. User acceptance test User acceptance test should be done after the site looks normal. For software, this test usually becomes B e t a test. Let the user use the site, andMake one last comment. Don't go through this test until the obvious error is corrected, as the following rules say.

Rule: User testing is the most important form of testing, not at the end.

Because the user test is closest to the real user, it is the most important test form. If the problem is not found, you may not immediately correct the error. If the problem is not very large, you can still publish the site, and later corrected. However, if serious problems are found, it is best to postpone the release until the problem is corrected.

2.12 Release and later questions

If the site is ready to release, don't Relax-you haven't released it yet. In fact, your job is just the beginning. Now is the time to observe the actual operation of the site. Does the site meet user expectations? Has the site's development goals been met? Do you need any other corrections? The bottom line is that the site must continue to run. New features may be required, and upgrades are unavoidable in order to accommodate technical updates. Changing the appearance is also very likely to meet the needs of the market. This begins the ongoing development process that is being maintained. Once the final phase of the waterfall model is complete, you should return to the initial phase, as described in the following rules:

Rule: Site development is an ongoing process: planning, design, development, and publishing, and so on.

2.13 Welcome to the real world

Although the site development process looks very intuitive, it is not always smooth. There are too many changes in the real world. For example, consider designing a site for someone such as a boss or customer. If someone pays for creating a site, you might want to mix his ideas, regardless of whether the requirement is consistent with the user's ideas. Be sure to persuade others to consider the user's ideas when making a decision. Be sure to show the superiority of design theory rather than the rules of advocacy. Be prepared to give some examples of your ideas. However, you must be prepared to accept that your ideas have been discarded by others.

Note that experienced designers will prepare a number of site combinations for discussion. As with the hairstyle books prepared for customers, what users think is difficult to describe with words.

Most site projects are prone to dispute issues. Don't expect anyone to agree. The company's departments compete for control, often between the technical and marketing sectors. There will be countless people who call themselves web experts to give advice, which will stir up more trouble. Don't be surprised if someone's brother's friend claims to build a site in an hour with Microsoft's F R o N T P a G e automation tool. The only way to settle a dispute is to be patient and try to convince others. Without a proper and clear specification, developers will find themselves in an unstable position vulnerable to attack.

Be sure to keep in mind that the purpose of following a process model is to reduce the problems that occur in Web projects. However, a process model does not take into account all the problems in the real world, especially about people. Experience is the only teacher dealing with many problems. Inexperienced developers in WEB projects are encouraged to touch beating to gain experience in overcoming obstacles.

2.14 Summary

Building a modern site is challenging, so site developers should use a methodology or process model to guide the development process, which hopefully reduces the risk and management complexity and improves the end result. The software engineering process model, such as the modified waterfall model, is easy to apply in most Web projects. Sometimes, however, a prototype-driven approach or a joint application should be used for lack of project management experience or clear objectives. Typically, a prototype based approach is better suited to the nature of the site, reduces unnecessary risk, and evolves over time before developing the right site. Planning at the early stages of site development can reduce risk and improve the final development quality. You should write a content design document that includes site goals, audiences, task analysis, content requirements, site structure, technology requirements, and management considerations. The design document should guide the implementation of the site. When you implement a site, you should use block charts, paper simulations, storyboards, and even mock sites to reduce the likelihood of later redesigning your site. When planning is detailed and the prototype is implemented, the implementation should be fast and the amount of work that needs to be repeated is minimal. However, once completed, do not rush to achieve online access-full testing is necessary. Long-time maintenance is necessary, continuous vigilance is necessary, otherwise your site will start to deteriorate.