Personal view of the web design process
The web design process can be non-linear—we often come back to things later, which costs us additional time. This is why we need to have a clear process to minimize such round trips. Here I'll describe the sequence of steps I consider while designing a website. This model should serve as a base for future improvement.
Everything starts with an idea as a result of creative brainstorming. But ideas are worthless unless realized. People may have the same idea, but they'll act on it differently due to their different viewpoints—ideas can be copied, but not their execution. We could take a pen and paper and generate as many ideas as possible in the domain we've chosen, preferably working under time constraints. The more we practice, the more we improve our results.
Then, we decide if it's feasible to work on the idea, considering factors like available resources (money, time, workforce, motivation), available substitute products by the competition, customer's wants and needs and many others. It's better to discard our idea upfront than to realize it and find that noone cares about it. Before we work on it, we must ensure that it has as many roots as possible, so it can grow almost without water.
If we think that the idea is feasible, we can make initial sketches to see our understanding of where its contours fall. In the process, we learn more about the idea and how we can improve it. We can determine if the goal of the website supports our values, who the potential audience is and why should she care, what type of content will be provided. We can sketch the layout and navigation and think about the information architecture and the way the user interaction should happen. A sketch can be done quickly and serves as a discussion point among a larger group.
After we've created the sketch, it can be digitized, especially if we need to present our ideas to the customer. He can then approve or discard our idea. We start with the functional prototype as soon as the client is happy with the graphic layout. This step can be omitted if we work on our own project, have a clear idea of what we are going to do and want to save some valuable time.
HTML makes websites possible and hosts their content. There isn't a web browser that can't support even basic HTML. Even like Lynx, which don't have the means to display styles, behavior and multimedia support it. The HTML is important, because its DOM structure has a direct impact on other components of the site. The content is scanned by search engines and frequent updates in accordance to a long-term strategy can be rewarded. Most people hate to read long text, so we can diversify their experience with audio and video to make the content more interesting. We use hooks—like ids and classes—to bind the content with particular style or behavior. Sometimes we need to make a compromise using non-standard solutions. Once we are ready with the HTML, we should test it with the HTML validator to avoid early validation mistakes. We should keep both a minimal number of tags and a shallow tag hierarchy.
CSS is responsible for the style we apply to our HTML document. It can contain image resources that are for decoration purposes—like backgrounds or small icons—and not seen as content. On the other side, logos and photos should remain in the HTML as they are real content and should therefore be defined with their dimensions and "alt" attributes in order to validate. Keeping the least amount of selectors in the CSS ensures that pages render faster. A problem arises if we have a complex stylesheet that should work with multiple pages that have only slightly different layouts. We could create multiple stylesheets, but this would require code duplication. If we remain with one stylesheet, we have no easy way to find which selectors remain unused, once we modify existing HTML structure. This extention tries to tackle the problem. The cascade has some specificity rules we need to know, because they determine which styles have the highest precedence. The CSS validator ensures that we don't have errors, which lead to browser rendering inconsistencies. We should test together HTML and CSS, because this is the final interface users will see before they interact with it. It needs to look consistently in a variety of browsers, operating systems and devices. The goal is to cover all possible uses with a single version.
After we have finished working on both the HTML and CSS, we can start with the back-end development. We put our functionality on the server, so it works always and can't be disabled by users in any way. Everything that happens on the server and the way he responds to the client is completely transparent to the user, who doesn't even notice how his experience was affected. Before we accept the user's data through forms or links—for example to write it in a database—we must validate it very carefully. The server-side validation is the last layer that should protect us from malicious user, so it always needs to work correctly. To do it, we can rely on regular expressions. We need to test only the HTML in combination with the server-side language of our choice (Ruby, PHP, Java, C#, Python, Perl) to make sure that the functionality behaves as expected. Creating the styles and the back-end code can be developed independently of each other—each of them makes sense only in combination with the HTML. This is why the HTML must always precede them.
Most modern websites keep their data in databases consisting of multiple two-dimensional tables with many rows and columns. At the intersection of every row and column—the cell—is stored a single data unit. The most common operations on such relational databases are insert, select, update and delete, which can be performed once we have connected to them. After we have stored our content in the database, we can use a server-side language (see the last paragraph) to extract it from there and load it dynamically in the HTML, which gives us high flexibility. This is why we should text the database together with the sever-side language and the HTML. There are many databases and we must be aware of their advantages and disadvantages, before we choose a particular one. You can try the packages WAMP or XAMPP, which contain a web server like Apache, a database like MySQL and useful tools to operate on it, like phpMyAdmin.
Working with databases requires knowledge of things like:
- Data types—INT, DECIMAL, CHAR, VARCHAR, TEXT, DATETIME, TIMESTAMP, ENUM and others
- Primary and foreign keys—connect data in different database tables if they have a common name
- Storage engines (MyISAM, InnoDB, MEMORY and others), their advantages/disadvantages
- Indexes—speed up search in particular queries
- Triggers—take action when a condition is fulfilled
- Stored procedures—allow programming of complex tasks within the database
To find out more, use the MySQL reference.
Verification and validation
V&V are very important during all phases of the development process. Verification determines if we are building the product right and validation—if we are building the right product. If anything in the creation process was wrong, we may need to start over, which is very time consuming. This is why we need to be sure in the answer of these two questions at every step of what we do.
Optimization has many facets, but it shouldn't be made before everything is completed. We can optimize for: screen space; more intuitive interaction; usability and accessibility; search results; mobile devices; function execution time; database query speed; code size, maintainability, understandability, flexibility; more sales and others. But we need to determine our priorities first. And then be ready to make trade-offs
After the code was optimized, we can to save on storage space, bandwidth, load and parse time.
When a website is ready, it's very important promote it to increase it's visibility. Word-of-mouth, advertising and PR campaigns, brochures, social network presence, reviews and testimonials can further support this task. But we must remember that the best marketing comes from the amazing product we create, the fabulous service we offer or simply how we behave in relation to others.
The ultimate goal of a website is to be profitable, so we need to think about more successful ways for doing it. For this, a high degree of process automatisation is desirable, which is often costly. The possibility to make sales at scale determines on how big projects we could work later on. If we aren't profitable, we have failed.