I always think that the biggest influence on design decisions is the context which is usually the answer to combination of the questions

• What is the website about?
• Who will use the website?

It is a fact of life that you can never expect to normalize resolutions and browsers among the users. And this variety leads to a range of real estate available for a web page to use. The question of which layout to use boils down to need to optimally use the available real estate. However this comes up with giving up a bit of control on the design. Rather, that how the web page will look now depends not only on your design, but also on the user environment.

This is one of the issues where you might never be able to decide affirmatively. It can come out of a jugglery of various factors like the time, the effort, the cost and of course the requirements. Over time I have come up with my own way of trying to decide which one to use, they are listed here, not in any particular order:

• I usually consider the amount of information that has to be shown in a context. If the information tends to be on an increasing side, I tend towards the liquid or elastic layout. If it can be contained then a fixed layout might work.
• If it is a graphically oriented site, then I tend to go for the fixed width. It is not that the liquid layouts do not work, just that it gets more difficult to design. Of course, as a challenge it is one thing, but from the project’s perspective I tend to move from “Why not liquid” to “Why liquid”.
• The biggest disadvantage of the fixed width layout is that there is no single fixed width for all devices. So, if it is possible that the website readers are going to use various devices, then liquid layouts might help.

Designing liquid layouts cannot be said to be more difficult, but there are more precautions to take. More flexibility requires more attention! There are usability standards for length of readable text line. If proper care is not taken this can lead to designs difficult to read. There is also a possibility that, if the widths are not properly assigned, the design might differ a lot across various resolutions.

This is an issue where there cannot be recommendations or a single definitive answer. We will, or at least I will, always only tend to support one over the other. In such cases, it has been beneficial for me to observe as many designs as possible and analyze them in context of the web sites. While I cannot say that these observations have helped me learn, they have definitely helped in improving my judgements. What have been your experiences? How do you take these decisions? Which layouts do you prefer, both as a designer and a user?

Share This

XHTML has always been considered as a successor of HTML - a newer model, a new version that improves over the older. Which is what tempted a lot of web people, including yours truly, to start with XHTML. However, as we will see, using XHTML comes with additional responsibility and effort.

What Is XHTML?

You might have come across this question a zillion times before. However, at the cost of repetition, I would like to answer this question again.

XHTML is a family of current and future document types and modules that reproduce, subset, and extend HTML 4 [HTML4]. XHTML family document types are XML based, and ultimately are designed to work in conjunction with XML-based user agents. The details of this family and its evolution are discussed in more detail in [XHTMLMOD].

The X in XHTML stands for ability to extend HTML to make it more functional and interoperative with other markup languages. To be able to do this, XHTML has been based on XML as against SGML.

Pros of XHTML

XHTML derives all the benefits of XML. The important one is that it enforces separation of data and style. This can be done equally efficiently with HTML too. The difference is that XHTML enforces it since HTML is a presentational markup language, where presentational elements are part of the markup.

Another aspect of XML is extensibility. It can mashup with other XML-based markups, like MathML and SVG, and provide a single uniform document. This interoperability between different markups provides for easier automation.The requirement is, as it is with HTML, that it should be associated with the right DTD which can be used for validation.

XHTML has a benefit for developers for debugging. To parse a XHTML document it has to be well-formed XML, that is, it abides by all the rules of XML. This can be helpful for catching errors early in the cycle.

Responsibility with XHTML

XHTML sounds like one the best things to happen. It is true to some extent, but not without more responsibility and effort. The pros of XHTML mentioned will stand good only if

• The strict doctype is used
• It is served as appliction/xhtml+xml

Let me elaborate on both these points.

The Strict Doctype

This point is important even if you decide to use HTML. A doctype is a Document Type Declaration which declares type of the document it resides in. It is metadata about the document that can be used by softwares like browsers and validators to verify if your document is structured the way you have declared it to be. It does so by including path to the intended DTD. This is important because some softwares, like browsers, might change their behaviour depending on this.

Ideally, only the strict doctype would have been enough and it is what is recommended whenever a new web page is designed. An additional transitional doctype is supported for upgrading the legacy web pages to the new standard. Transitional is more lenient as it allows space for upgrades, is inherently temporary and so should not be used for new web designs. However, this has not been heeded well by the community. We have thousands of new web designs which declare themselves to be HTML/XHTML transitional compliant. Roger Johansson has explained nicely difference between the two doctypes.

The application/xhtml+xml media type

W3C has defined certain media types that should be used with corresponding documents in the XHTML family. They are text/html, application/xhtml+xml, application/xml and text/xml. The browser identifies the content type using these and treats the content accordingly. For example, text/html says that the content is html, application/xhtml+xml says that it is XHTMl and so on. text/html is recommended for using with HTML documents and not with XHTML family documents. The application/xhtml+xml is recommended for XHTML documents. So far so good!

The trouble here is that many browsers today, including the widely used Microsoft Internet Explorer do not support this content type. Meaning that if you try to load a XHTML document which is being served as application/xhtml+xml the browser will not understand it and may ask you to save the document. So a lot of XHTML documents today are served as text/html. This makes the browser treat your XHTML document as plain HTML with some incompatibilities. Ian Hickson elaborates on the dangers of serving XHTML documents as text/html.

For designers, XHTML documents that pass validity with being served as text/html can miserably fail when served as application/xhtml+xml. Which means that they are truly not XHTML.

Myths

I have come across certain myths about HTML, XHTMl and CSS.

• HTML does not work with CSS. This is one of the common reasons given for using XHTML. HTML can be used, just that it is easy to not use CSS too, which might break the data-style separation principle.
• XHTML Transitional is better than HTML. Any form of transitional doctype is not good for new web designs. Their intent is to be used with migrating legacy designs, not for anything else. In fact HTML Strict is much better than XHTML Transitional.
• XHTML is just HTML with closed tags. This is used a lot of times to convince others that migrating to XHTML is easy. Syntactially XHTML can be seen as XML applied on HTML, but it is not so. The allowed elements will depend on the doctype used, and the Strict doctype will not allow a lot of HTML elements and attributes. The browsers too treat parsing of CSS and JavaScript differently for HTML and XHTML documents.
• XHTML is stricter than HTML. This is true theoretically, but practially when XHTML is served as HTML this turns into a myth. The only strictness can apply in the well-formedness. Also using the Transitional doctype will allow you to use presentation markup in XHTML, overriding the purpose of XHTML.
• HTML is going to die. This has been busted by the recent news from W3C about parallel HTML and XHTML existence.

Epilogue

Your decision to go with HTML or XHTML should be justifiable. Each have their pros and cons, and migrating either way in the later stage can burn a hole in your client’s pocket. I have faced situations where I wanted to go with HTML, but also wanted to be ready to move to XHTML if required. The meta information can be updated then. However, to make a possible move to XHTML in future easier I have used HTML with closed tags.

Overall, this is a subjective topic and every designer has formed his/her own opinions and conclusions. Somehow I feel that there needs to be best practices or recommended practices for situations like these. Otherwise there might be cases when the standards might just be treated as preferences and make the Web incompatible.

Interesting reading:

• Ten Questions for Tommy Olsson
• Activating the Right Layout Mode
• Bulletproof HTML: 37 Steps to Perfect Markup

Share This

I imagine this scenario would be faced by a lot of designers and developers who work on projects which need to publish on both the media, like magazines, newspapers or books. The comforting fact is that there are some common objectives, the most important being that of communication with the reader. However the differences arise from the fact that the playground is different, the tools and technologies are different and so are some rules. You obey the law of land or get punished!

Resolution

In the print world, you can choose the best resolution for your images and text. The reader sees exactly what you have designed. Not so on the Web! The reader’s screen will dictate the dpi resolution, which is usually lower than the print world. Lower resolution might mean lower quality. If this is not considered during the design, the resulting output, though good on print, might ruin it for the Web reader.

Colours

The inherent colour systems involved the print and Web worlds are completely opposite to each other. The way colours are displayed on the paper is through absorption of certain wavelenghts of light, which is called subtractive model. Whereas the computer screens and monitors emit light and the colours are formed by combination of the colours, called additive model.

This is the reason CMYK colour model is used on print, whereas the RGB colour model is used on screens.

This was one of the early warnings a print designer must heed to. Although there are colour model converters, the designer should test the colours with the intended model.

Typography

This is probably the most affected aspect of design while migrating from paper to pixels. It is not only about selecting the appropriate typefaces, they also have to be renderable by the reader’s computer. Unlike in the print medium, where publishing is same as rendering, if a font is not available on the computer, it is not rendered. That is why a designer should offer a family of fonts which usually includes at least one most common fonts.

The two basic categories of typefaces are Serif and Sans-Serif. Though there is no strong argument against any of them, Serifs have been more popular in the print world and the Sans-Serifs in the Web.

Dynamism and Richness

Web has been more dynamic medium than the print. Not only is the content more frequently updated, the user has various other ways of interacting through the software. A very common example is that readers can comment on articles on the Web. If the comments thread is not accounted for in the design it can make the entire web site unusable.

The interaction now allows the readers to do much more than just read. In addition to participation, they can print the article or email it to someone or bookmark it. If a web site expects its readers to print out articles, then the designer should design for the print medium too.

While designing sites for newspapers, the frequency with which the news is updated and the number of articles that are updated have to be considered for considering how many articles to show and where. Whether full content should be shown or only introductions. All these design decisions stem from the fact that Web is inherently a more dynamic medium.

Not only is it dynamic, but also rich enough to host multimedia content. A web page can contain text, images, movies or all of them together. This means that the designer has to design for more content types as compared to the print. The web designer should be more aware of the different technologies, like Flash.

Standards, Accessibility and Usability

A lot has been said about these already on this site. However, this is something very important that the designer should be aware of. A fantastic design which does not load in a browser is of no value, or rather harmful. The designer can follow the standards to make sure that the web site looks and behaves the same way across multiple browsers and multiple platforms.

In the world of software standards keep evolving as more and more experiments are carried out. The designer needs to keep up with them, e.g., using CSS is a preferred technology for web design.

The rules of readability differ a lot. While on print, black on white is considered golden, it comes in the unreadable category on the Web because of the luminosity.

Performance

This is something that is completely missing in the print world, and this has been the worst aspect for me to convince a print designer about. The concept of a runtime is difficult to explain. In the print world, the content and design is rendered when it is printed. However, in the Web, the different components of the design start getting loaded when the user visits the website. During this time, a web page with heavy components, like big sized images, can take either too long to load or not load at all.

The performance is of higher importance because of the scalability that web publishing possesses. Unlike the physical material, once published on the web, thousands of readers can visit the site. Maybe the designer cannot always account for the overall performance, but he/she should be aware as the design definitely contributes to it.

Epilogue

Print and Web publishing both involve technologies, albeit they are different. Not only are the technologies different, but the freedom that the designers and readers have is also different. In the print world, the designer can choose the specifics whether it is the paper type, the resolution, the colours or the typography. Whereas, on the web, the reader has more freedom with exactly these factors. The reader can use his/her personal preferences to select the tools, the technology, the colour depth or the resolution. The fact that a web design will depend on what the reader uses is something that the web designer has to design for.

The website should not only look the same, but also behave the same across the wide variety of the tools that the reader can use. In general, a print designer has better freedom and control than the web designer. But the web designer has a richer platform for better communication.

There are many more differences in the way the design is implemented. For example, on the Web, background images are preferred as they can provide a good visual effect and load easily. However, I have tried to summarise the fundamental differences, probably each of the aspects deserve their own spaces of discussion. Feel free to add to the list if you find it incomplete.

Share This

What Is Semantic HTML

Semantic Markup is a way of writing your markup so that the reader understands what the data is about. The term reader includes machines like the search engine bots or parsers along with the humans.

Semantic HTML is a way of writing your HTML code such that the HTML tags express what the data is that is enclosed between them. It is about using HTML tags for what they stand for. For example, using h1 instead of div for the title of an article indicates that it is a heading. Ofcourse you can always use <div class="heading"> to make it more expressive, however there two problems to it:

• h1 is globally known as a tag for heading, as a standard, rather than our custom tag. If each of us created custom tags, there would be no common software programs that we would work for us.
• h1 is still more expressive and space-saving than the div

Some of the other examples are using div for block elements which are usually rendered on a new line, cite to cite source of information, p for paragraphs, code for source code and so on. The HTML tags are named such that their meaning is quite apparent.

To be able to follow Semantic HTML, the underlying markup has to be extensible. This is one of the reasons we are slowly migrating to XHTML from HTML. HTML is inherently presentational, i.e., it provides information of how to present the data. Whereas Semantic HTML should convey what is the data about.

Benefits

The two points mentioned earlier are the basic benefits of using semantic code. If we use globally known tags, others understand without any additional effort. Any software program that uses the globally known tags will not be able to understand our page.

A working example of this is that search engines weigh keyword importance according to what they are. For example, and article title enclosed in one of the headings (h1 and its hierarchy) would get higher importance and hence visibility than spans. Semantic HTML enables effective Search Engine Optimization (SEO).

The semantic data extractor is a good demonstration of the possibilities of using Semantic HTML and software automation.

The semantic data extractor is a good demonstration of what can be achieved by Semantic HTML and software automation.

A side effect of excluding presentational information from the semantic markup is that now data and its presentation can be decoupled in implementation. Which means that you can change presentation without touching the data, or apply the presentation to multiple types of data. This is exactly what technologies like CSS and XHTML together achieve. Of course Semantic HTML is not necessary for this decoupling, but provides for by being semantic it enforces exclusion of presentational information.

Benefit To Developers/Designers

Another unintended benefit of Semantic HTML that I have realised is that it can be used for communication between developers and designers in a project. When I, as a content engineer, want to design a page, I first try to realise all the content that has to be in there. Somewhere the content priorities also have to be decided, e.g., primary, secondary, …. Then I prepare pure markup, without thinking about the styles or the presentation. This markup contains two important pieces of information - structure of different content types and different content types to include in the page. If this markup is semantic, then the designer can understand it better, reducing requirements for documentation. I might end up playing both the roles, but it gives me an opportunity to focus on the two different things exclusively.

Nate Koechley talks about Layered Semantic Markup (LSM). LSM is a framework of web technologies with the philosophy of structured semantic markup as core of web development. By building layers of presentation and behavior above the core of semantic markup, the framework builds flexible and future-ready web pages.

The XFN and FOAF projects are extensions of the Semantic HTML that use semantics not only in the tags but also in the attributes. In my opinion they are just a tip of the iceberg of possibilities with Semantic Web.

Epilogue

Semantic HTML is a way of building and participating in the semantic Web. This will ensure higher visibility and future readiness. Semantic HTML also makes your web pages open to automation. However, Semantic HTML is not mandatory, it is a best practice, a code of conduct. The beginning might be a little tough, but the advantages are many, if you follow the Semantic Code.

Share This

The realisation is that function and form both support each other to make the product or solution usable. The question then is what precedes what! Should the function be designed first and then the form? Or the other way round?

Form Follows Function

This is a shorter version of the original dictum - Form ever follows function which was coined by the American architect Louis Sullivan. It was set as a pervading law that

in nature, all shapes express the inner life, the native quality, of the animal, tree, bird, fish, that they present to us; they are so characteristic, so recognizable, that we say, simply, it is ‘natural’ it should be so.

…

Whether it be the sweeping eagle in his flight or the open apple-blossom, the toiling work-horse, the blithe swan, the branching oak, the winding stream at its base, the drifting clouds, over all the coursing sun, form ever follows function, and this is the law.

There have been a lot of discussions whether this is a natural all pervading law or not. However, lets discuss this in the context of web design (which I think can be extended to generic software design).

Advantages as a Design Methodology

The biggest hurdle in designing is the starting point. There are simply so many options available that look equally merited that it gets difficult to choose any one of them and start. I believe, this paradigm can be employed as a design methodology to solve the problem.

What do you do when all information you have before you start designing is that you are supposed to design a piece of software? It gets a bit clearer when you are told that a corporate website has to be designed. More information regarding this - e.g., that it should give information about products, that it should host the quarterly results or that it should let the readers know about the news - brings in more clarity. The function serves as a guide to design the form. It guides the designer to narrow down the options and provide a starting point. The form now has a purpose or duty, if you will, of projecting the function that lies within. If the form does not honestly bind with the function then the function might end up being not usable.

The optimum benefits are derived through the combination of the best function design and the best form design. Form follows function, in fact, dictates that every function can have only one formal solution, and hence only one form.

The Oppositions

The disadvantage is that it is purely a functionalist approach and might lack aesthetic appeal. This is where a lot of designers have opposed this paradigm. The form design is not made to please anyone, it is made to use the function. This works fine if you catering to an wide range of audience. By not pandering to anyone’s taste, the design is acceptable to everyone. However, this can cause problems sometimes when you are catering to a closed group.

Another rant has been that designers felt bound by the rule of one form design per function. However website design, or for that matter even architectural design or industrial design is a combination of art and engineering both. The aspect of art always provides more than one option. Form follows function tended to kill the contribution of art in designs.

Form follows function?, actually no by Bruce Deitrick Price is one of the better ones I have come across. He provides some examples, but in the general domain.

Okay, you’re thinking, what is the point here? Explain yourself. Easy! In half the cases where this cliché is used, it’s a trivial and stupendously empty tautology. A knife or scissors is sharp by definition. A knife not sharp ceases to be a knife. Look in the dictionary–cutting will always be mentioned. Anyone saying that a sharp knife is an example of form following function is like somebody piously asserting a circle is round or a square has exactly four sides.

However, design of the knife for cutting will also include the shape and the material which is not part of the definition. The shape and material to use for the knife will be dependent on the fact that it is to be used for cutting.

This probably leads into another possible problem. That an object might have to perform multiple functions and not just one, which the article addresses next. Designing it based on isolated functions is going to harm the entire design. Which is where even my rant starts, that the design will have to be inclusive of all the functions, and more aspects. A modification of this, Form and Function follow Vision can attempt to solve this problem.

Form and Function follow Vision

Should form follow only the function is my doubt. I think the form design has to consider the usage, the users and to some extent even the context it will be used in. For example, Digg is a site where users submit and vote stories. It has resulted into a site which can be used to get all the top stories. It is however important for Digg designers to consider the skill level of the users who submit and vote for the stories. They also have to consider what technologies to support while designing the website. Digg can also be considered as a social networking site where a user can make friends. The form design will have to consider all this, none of them can be opted out.

One more observation regarding software is that more than often users use it in new innovative ways, like the XMHD (Gmail Hard Drive). Of course, these cannot be predicted, but a flexible design can help.

Which is why lets look at the vision with which the product or solution, in our case the website, is being designed. The function and form design both should use the vision as the guide. Form has to interact with the function, that not dependent only on it. The vision includes many factors - the multiple functions, the stakeholders, the target users and is inherently longterm. It also removes the mandate of only one form design because there are other aspects that affect the form design.

I have heard about many combinations of form and function - function follows form or form is function. What do you use? How do you start your design? Do you use a methodology or is it adhoc? Do contribute.

Share This