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

web| Process | design | Problems creating a good web site can be challenging, from design to database integration, so many different parts leave a lot of room for mistakes. To reduce the risk of Web project failure, we need to have a process model to guide the development process. Unfortunately, many web designers have adopted a development approach that might be called N I K e-they just do it, and they rarely think about prospects and plans. The process of building a website is not in line with methodology; The site's goals are loosely defined, and the process relies on intuition, without rigorous process definitions and lack of predictability. Sites developed in this way, like plants, naturally grow and occasionally become beautiful flowers, but more often than not they are a mess of grass. Complex web design needs to be carefully planned. Appropriate process models or methodologies should be used to guide the design and development of the Web.

2.1 Process Requirements

Similar to the "software Crisis" of the 2 No. 0 Century 6 0 years also appeared in Web development today. A few years ago, most Web sites were simply digital brochures or referred to as "brochure software." The development of such a site does not require a lot of planning-often a simple development of a good interface, and then fill the content is enough. Today's site is becoming more complex and more massive. With the introduction of E-commerce and Dynamic Web pages. The site has changed from "brochure Software" to full software applications. However, many developers still do not adopt a robust development approach and continue to rely on specific methods.

Note that "software crisis" means that over time, in the area of software development, improved hardware capabilities allow for more complex programs to be built. However, developing and maintaining new programs is extremely challenging. Because in the past almost no methodology, resulting in many projects failed, leading to experts declared "software crisis" occurred. The introduction of structured development method and "Top-down" design method can solve this kind of crisis.

The crisis of web development practice exists widely. Unlike the previous internal client/server project being kept secret, many of the failed Web projects are now being watched. The number of pages that are always in development or about to be developed shows the poor design of the Web site. Unfortunately, the yellow-black is still building the logo as well as the animated hand-held drill is rarely removed. If judging from their content and the date of last modification, some sites seem to have been under construction for several years. Some half-dead sites, flooded with stale content and outdated web pages, outdated technology, disconnected links, and poorly run scripts, are like ghost towns online. Do not simply attribute these errors to negligence and typographical errors. A broken link is a serious mistake, imagine what it would be like if there was a menu of missing features in the software.

There are a variety of reasons why sites have these problems. Some sites are getting worse because the site designer is tired of getting out. Other sites are abandoned or the funds are withdrawn. Some sites fail to complete, because the site is too complex to drag down the designer. Sometimes, developers fail to understand the tools they use, or do not fully understand the limitations of the media. The reasons for the failure of the project are varied, and many websites are closed because the project is too risky.

2.2 Special web Processes

Usually the Web site development method is simple: to implement the Web site, the browser to complete the appearance test and release. This is very similar to the process of developing and testing in small software projects. Not surprisingly, developing a site in an informal way can be a problem. Today's web development is so fast that it's only two phases: implementation and publishing. It is noteworthy that many web development tools encourage this online design approach. Some tools encourage developers to start directly from building the user interface and gradually add functionality with automated tools. Others write the code before adding the user interface. It's not to be doubted that the speed of web development is very important, given the time requirements of the web. But publishing a crappy, poorly designed site can also be a problem, especially if users are frustrated with the problems that appear in the site.

In the software industry, many professionals tend to think that informal methods are only suitable for small projects, usually only one programmer, and that future software maintenance is very small. Often using this lack of planning method to develop the program will produce bad programming logic-so-called "spaghetti Code". This code is extremely difficult to maintain because no one can undo the knot except the original designer. Even the original programmer will forget the meaning of the code over time. The web site has the same problem. A small web site with a very short life cycle is typically designed by one person with little methodology. By looking at the H T l pages of these sites, the J a V a S C R I p T and the navigation structure, "Spaghetti Code" is also adopted, but it adds a non-staple food called "messy h t M l labeled salad".

Planning can solve a number of problems in a Web development project. Unfortunately, for a particular web process, the plan is limited to a brief communication, a simple and incomplete collection of potential content, or some hastily written flowcharts that spend less time on planning than on the time spent on implementation. Of course, there may be too much planning and "analysis of paralysis", which hinders the construction of the website, but this is not common. It is important to remember that the amount of time planned is proportional to the complexity of the plan, and the key to meeting the challenge of project management is to create a formal process, plan, test, and configure the site in a structured way.

2.3 Basic Web Process models

To mitigate the difficulties of site construction, a process model should be used to describe the different stages involved in Web site development. Ensure that each step is completed successfully by using guidelines, documentation, and identifying development steps. The ideal Web process model can help users solve the complexity of the site, reduce the risk of project failure, deal with almost inevitable changes in the project, quickly publish the site during the development process and get timely feedback. Of course, the ideal process model should also be easy to learn and operate, which is a fairly demanding requirement that no single model can accommodate all the specific requirements of the project.

The most basic process model used in Web site development is familiar to most people, at least intellectually, because it is deductive. The basic model is gradually refined from a large background to a specific step to complete the design of the entire site. In software engineering, this model is called a waterfall model, or sometimes called a software life cycle model. Because it describes the different stages of the software lifecycle, each phase is phased out to the end. The first stage of the model is the planning phase, followed by design, implementation, testing, and finally the maintenance phase. Each phase has unique steps, but the boundaries of the connected phase are not obvious. Further, each stage does not always have a fixed goal. Sometimes, the previous phase may be modified as a result of unexpected changes in the project. The actual number and name of the steps vary from person to person, but the idea of a waterfall model is shown in Figure 2-1.

Note Although the Web development model may be the same, there are still many web developers who think they have created a new model. They put it on their site as a patent for an uncertain attribution, and there is no new thing in fact.

Whether it's five steps or seven steps, or if the name is complex or simple, it's important to remember that the real thing is whether the model accelerates the development of the site or improves the quality of the end result.

The advantage of a simple waterfall model is that it allows users to plan everything on the front end, which is at the same time its biggest weakness. In a Web project, there is a lot of uncertainty about what needs to be done to accomplish a project, especially if the web developer doesn't have much experience. Another problem associated with this model is that, like software development, every process of web development overlaps, interacts, and often has to be repeated. Unfortunately, the waterfall model is too strict. If too many changes occur, the developer may be asked to stop the project and repeat the original process. In short, this process does not adapt well to change. However, for Web sites, the waterfall model continues to be used for ease of understanding and implementation. Further, the separation of each stage in the process model facilitates management, as they facilitate supervision and step-by-step implementation.

2.3.1 Modified Waterfall Model

One important aspect of the waterfall model is that it requires planning at the front end. However, because of all the steps required in the process, the developer hastily skipped each step in the early stages, and later had to repeat it, or continue to build a defective site. The process is also too restrictive and does not support further exploration, leading to unnecessary risks. One possible improvement is to spend more time in the early stages of the waterfall model and repeat it several times, repeatedly digging goals and requirements after entering the design and implementation phases. Because of the cyclical nature of the process, it is often found that a modified waterfall model with vortices is more natural. When you solve a project with high uncertainties, the modified waterfall model with the scroll shown in Figure 2-2 is a good idea.

2.3.2 Joint Application development model

The last mentioned software development process model for site development is very meaningful, it is the joint application development design, referred to as JAD (joint application Development), also known as the Evolutionary prototype method, the prototype system through a series of evolution to get the final form. Instead of creating a mock site to test the theory, the prototype was created for the user. Direct feedback from the user will be used to guide the production of the new version of the site, repeatedly, until the system is finalized. The basic concepts of JAD are shown in Figure 2-3.

Many aspects of J a D are ideal for web development, especially when it is very difficult to determine the specification of a project. Compared with the waterfall development model, the J a D model is progressive, so it also appears very fast. However, J A D also has a serious flaw. First, letting users see unfinished sites can jeopardize the relationship between developers and users. Even if the user is involved in the mentoring project, we must remember that the user is not the designer, as noted in chapter 1th, this web design guideline will deviate from the user's unreasonable demands. Web projects that work with J A D are difficult to budget because the number of revisions is difficult to predict. If the user is fickle, the cost will spiral up and out of control. Keep in mind that the core concept behind J A D is to experiment repeatedly before getting the right design. Without its flaws, J a D has its place in web development, especially in software maintenance projects. However, the initial development of the J A D project is best for experienced developers-especially those who can communicate well with the user.

Other ways to guide web development have been discussed. There are also some ways to serve the user. Remember, building a site is to identify the problem to be resolved or to achieve the goal, and in a consistent and inspired way to obtain results. The development of the site should be critical and deliberate, not casual and passive. A picky approach does not mean abandoning opportunity and inspiration altogether, but it offers opportunities. Designers should not consider some of the concepts of site engineering as a limiting factor, but rather as guidelines.