Components and/or widgets (in my view) already play and will play a major role in making up semantic web.

Components can be viewed as building blocks of future web ‘pages’ and are most likely (and already are to a great extend) reusable on any web page - with applications like iGoogle users are able to ‘build’ their own web pages by adding widgets to the page through various interactions including dragging and dropping.

Each component can encapsulate all its attributes (including meaning, structure, data, presentation and behaviour) and can exist on its own by being explicitly linked to various server resources such as pictures and style sheets.

Semantic component structure

Here is an overview of how I am looking at things at the moment and how things may (and already do to a great extent) work within semantic web environment.

Meaning

Outlines what the component means and is placed on the top of the stack because meaning is the most important aspect of semantic web.

Future pages are most likely to be ‘built’ out of components which may reside in any place on the web (i.e. ubiqutous web), hence if the two components on a single page have the same meaning confusion is most likely to arise.

Communicating the meaning of the data we are working with is today’s ultimate goal of good interface developers and generally software engineers.

Structure

HTML is the main (at least the most widely adopted and supported) language with which we can define the structure of a given web page.

There are obviously various ‘flavours’ of HTML we can opt for, but whichever version of HTML we choose to work with, it ought to validate against W3C specifications.

Furthermore, HTML strucuture can (and should) include (wherever possible) microformats.

They are machine readable aspects of semantic web and have already become part of the standards to a great extent and will be adopted more and more over time.

XHTML2 recommendation proposes the use of <section> tag to denote all sections on page.

This nicely leads into future structure of the web within which we could have standalone sections for various mash-up style web sites being developed by developers and integrated into the end system by users.

Data

Data layer is a slightly weird aspect of semantic web as it often contains meaning within it, but due to the fact that most data is not ‘formally’ structured that meaning is mostly lost, hence we need to use layers above to denote structure and meaning of data.

RSS is a good example of (fairly well) structured data which can carry within itself plenty of meaning (RSS used for news for example can be a very structured and semantic way of sharing data).

However, due to the fairly flexible structure of RSS specification, various developers have bastardised it and used it for sharing ‘everything’ through RSS, which, to a great extent, misses the semantic aspects of sharing data through XML feeds.

Plenty of data within web pages these days is also fairly loosely structured. Think about an average paragraph content within a <p> tag in an HTML page.

Presentation

CSS is the main technology we use these days in order to style pages.

They are a very simple technology, which offers massive scope for being misused to a great extent, and that misuse is to a large extent associated with many developers not understanding the nature of semantic web.

Good stylesheet structure and reusability is incredibly important for creating good quality and nice looking semantic interfaces today.

Behaviour

JavaScript is the final part of the current semantic technology layer cake.

It is interesting in its nature in so far that it can ‘dig’ into any of the so far described layers and is therefore subject to all those rules and some more, in order to make it work with less capable browsers.

In order to make the most of JavaScript and enhance the meaning of semantic components which are developed, JavaScript ought to be used in such a way as to add dynamic, behaviour based meaning to those components which help users better understand the purpose of the component and make its functionality more useful.

All of the above put together may make compound semantic web pieces of ‘data’ (semantic objects) which can be used and reused within any context and viewed through any type of browser.

Outlined below is what seems to be increasingly emerging as the most appropriate process for developing semantic web software.

The below process has been gathered by working alongside some of the leading UK design agencies and through having various conversations with (mostly design agency) managers.

It is also important to outline that this process is favoured by visual design agencies as well as other professional development companies on the market.

Many developers tend to believe this approach is favoured by semantic web developers as they have to ‘worry less about design’, but in my experience this is not the case at all.

Good designers tend to understand the intricacies related to web interfaces and are able to cater for them and design around them in order to make web design aid user experience and not hamper it.

The reason why I am outlining this process is because it could be dubbed the ’semantic web design process’, where the focus throughout the process is on the meaning, structure and overall needs of users and the business, which are the main purposes of existence of most web sites and applications.

1. Scope out

   Work out the key functional requirements for the system, without going into deep details - since most of them are likely not to be known at the early stages of system development.

   Write down keywords from the specification papers and start understanding which are the most important functionalities and features which need to be developed within the web site or the web application.

2. Sketch

   Firstly, in a very rapid process, the idea is to sketch out pages for a web site or web application in order to capture the most important aspects of the system as a whole in some sort of a visual manner.

   Even very experienced developers and architects can struggle to visualise systems before they are actually built.

   At this stage the most important factor is to capture all those obvious and easy to think of aspects of the system which can be sketched out and given to developers to prototype.

3. Build

   At this stage the idea is to build a wire frame like prototype of the system, based on the sketches drawn out on paper.

   This approach gives developers, as well as the business a solid insight into what features, structure and intricacies the system will contain.

   Prototype build is a tangible asset and can be seen, used and evaluated by the business in order to scope out and work out what is missing from the overall solution.

4. Test

   This step within the process rests almost entirely upon development of the prototype in flat HTML/CSS and maybe using some JavaScript.

   It is possible to test the system by getting users to point with their fingers to areas of the pages on sketched out paper based wire frames of each page, but this approach is much less precise.

   The reason why it is important to have users test the ‘real system’ is because those kind of tests tend to unearth real problems based on a solution which is as close as possible to the final build.

5. Refine

   Based on the user testing carried out in user testing stage, refinements to the overall system are made in order to improve usability and relevance of each page.

   It is incredibly important to base changes to the system upon real data and real findings.

   It also goes without saying that selection of users to test the system with is incredibly important, so there is not much point in (for example) testing an e-commerce system aimed at middle aged women with a group of young, tech savvy boys, since they are most likely not to use the system in the same manner as the target group.

6. Design

   Only at the point when the system as a whole has been developed should you start working on the design for the system.

   Some of the reasons for this are that designers need to know various states the pages can find themselves in.

   Designers also benefit greatly from knowing what kinds of content might be found within each section of each page, in order to design in a manner which works gracefully with all types of content required by the business.

   Another incredibly important reason why it is useful to do design as the very last stage of development is the fact that systems tend to take much longer to develop when every time a wire frame or prototype changes, design also needs to be changed.

   This fact adds no value to the system, but ’sucks up’ time and resources from the company developing the system greatly, creating impressions that software development is about ‘creating documentation’ rather than creating shipable code.

7. Deploy

   Deployment is not necessarily the ‘end’ stage of software development, but, if deployed as BETA or even ALPHA version of the system, can and should be treated as the first official live analysis of the system.

   We are really now only at the ‘Scope out’ stage of development, but this time the system is ‘in the wild’ and gathering more real world data and information about real life behaviours of the users on the system, which is incredibly important as it is ‘real’.

   Google and various other web sites have been deploying this approach for years now.

   They also use this approach in order to show their users that ’something is constantly being updated on their systems’ which users tend to appreciate as it gives them an impression of a ‘constantly improving and active organisation’.

What is it for?

W3C specification is fairly clear about what the purpose of <div> tag is.

The full quote from W3C HTML specification is:

The DIV and SPAN elements, in conjunction with the id and class attributes, offer a generic mechanism for adding structure to documents. These elements define content to be inline (SPAN) or block-level (DIV) but impose no other presentational idioms on the content. Thus, authors may use these elements in conjunction with style sheets, the lang attribute, etc., to tailor HTML to their own needs and tastes.

Some on-line references say that <div> tag is ‘semantically neutral‘, but I would strongly disagree with this statement. <div> is essentially there to be used for denoting sections of HTML documents.

<div> tag stands for ‘division’ on page, hence it has a semantic meaning to it which can be infered simply from its name.

Appropriate use

<div>, coupled with and id or a class attributes, is semantically very strong statement which gives a meaningful top level structure to any HTML document.

Structure and top level semantics of HTML pages are very important parts of creating web sites of any size these days.

This aspect of web pages not only helps organise the application for end users, but also helps developers organise the application from the developer perspective, aiding overall usability of software (it is commonly forgotten that usability does not only apply to application interfaces, but also to the back end, as well as general day-to-day life).

We need to think about usability all the time, as we are developing products which need to be maintained and upgraded (scaled) in future in the most meaningful (i.e. semantic) way all-round and not just from the interface point of view.

Web developers who know what they are doing, understand that <div> tag is a very powerful tool in web development and create ‘objects’ on screen which are completely encapsulated within their own <div> tags with a relevant id which uniquely identifies that ‘object’ within any page.

Inapropriate use

How ‘granular’ should we go with <div> tag and what is the smallest amount of code we could surround with a <div>?

I tend to implement standards as strictly as possible, since I have found (over years) that approach to be the wisest approach (least error prone and most scalable).

‘Sections’ or ‘components’ on a page should contain at least 3 tags in order to be considered candidates for being surrounded by <div> tag. (I am sure someone will be able to come up with examples of where this does not stand).

It is important to avoid divitis in order to keep interfaces lean, fast performing and avoid code bloat (and therefore decrease maintainability of the application).

There are many examples within which a <span> will work as well as <div>, but semantically will not be as ’strong’ as <div> and the code will still work, validate and make more sense.

There are also frequent circumstances within which other elements can be treated as a <div> and therefore use of <div> avoided, while achieving the same results.

Great examples of this situation are usually presented wherever ordered or unordered lists are used, in which cases <li> can (in most circustances) act as a <div>.

A look into future

An HTML construct such as <div id="news" class="component">Component content goes here<div> means a lot and creates a very good structure on a modern web page.

Future automated semantic tools could potentially understand this conventions and be able to ‘pick up’ complete components from pages and create mash-ups which can work with content directly pulled in from any web site.

Treating user interface as an API and standardising HTML mark-up (in a similar way in which Microformats community does it) can enable any portion of any interface to become reusable anywhere.

Namespacing CSS files according to the structure of the <div> component based mark-up also leads to better CSS development, leading towards faster performing and much more scalable and easily re-skinable interfaces and generally smaller and leaner implementations.

Example

Good example of using <div> tag and utilising its full semantic power.

HTML stands for Hyper Text Markup Language. It is a language and it is intended mainly for text. Its initial purpose was to provide meaning to text documents which reside on the World Wide Web.

This initial intention of HTML got somewhat lost in the last 10 years of web development and large majority of web developers are only now waking up to this fact.

I would like to provide Pareto Analysis of HTML as it is used on semantic web development projects on day-to-day basis. Without fully understanding these tags, you are most likely not to be able to create a proper, semantic web site today.

There are around 100 HTML elements which have been made part of the W3C specification. However, only a portion of those tend to be used by developers on day-to-day basis.

Highlighted in the list are those elements which I deem to contain some amount of semantic ambiguity. In other words, developers tends to misunderstand the meaning behind these tags, which tends to lead to their lesser or greater misuse.

I will explain separately the reasons why I think these tags are misused and how they ought to be used.

1. <div>
2. <span>
3. <p>
4. <a>
5. <table>
6. <tr>
7. <thead>
8. <tbody>
9. <td>
10. <th>
11. <caption>
12. <img>
13. <form>
14. <input>
15. <label>
16. <fieldset>
17. <textarea>
18. <select>
19. <style>
20. <option>
21. <legend>
22. <html>
23. <head>
24. <title>
25. <link>
26. <meta>
27. <script>
28. <body>
29. <em>
30. <strong>
31. <abbr>
32. <address>
33. <h1>
34. <h2>
35. <h3>
36. <ul>
37. <ol>
38. <li>
39. <dl>
40. <dd>
41. <dt>
42. <object>
43. <embed>

With the above list of HTML elements you should be able to semantically mark up pretty much 90% of any small or large web site today.

It is interesting to observe that less than half of the overall HTML specification is used on most web sites today.

This fact suggests that almost half of HTML tag set is obsolete as well as that HTML specification is arguably sufficient for the purposes it was developed for.

Some web developers may disagree with this statement, feeling that HTML is missing elements which could be introduced into HTML5/XHTML2 to make some common tasks easier and faster to complete.

However, in conversations with developers, I have rarely met one who was able to suggest any new tag, letalone one that was meaningful and did not only cover requirements of an average blog site.

All said, here is another piece of observation. There is no such thing as a ‘perfect code editor’. They all tend to have their own advantages and also lack certain functionality which would be useful to have. At the end of the day, one needs to settle on a code editor and use the tool to the best of their ability in order to write good quality code consistently.

Free HTML editors

HTML-Kit

I have been using HTML-Kit for a long time now and it is by no means perfect, but it caters for the usual colour coding needs. It works fine with XHTML, CSS, JavaScript and PHP, which is a frequent mix of technologies I work with.

It also has an integrated FTP client which is nice for direct editing of files on a remote server, which is not an approach you want to take often, unless you are making quick tweaks to the content or simple changes. It works nicely on XP and Vista machines and is pretty fast.

The downside to it is the fact that it can be a bit messy with regards to indenting. It does not look particularly pleasing to the eye and it does not auto-complete code very well at all. It is suitable to those who do not like auto-complete (like me) and want a simple enough tool to do quick, high-quality work in it.

NotePad++

One of the biggest advantages of NotePad++ is that it doesn’t require installation - it runs off one small .exe file.

It is a nice editor, which handles HTML very well, but does not colour all types of code you are likely to work with.

I have also find this one to work slightly unreliably on Windows Vista machines (i.e. throwing up weird errors), which can be annoying.

Aptana

An editor much preferred by many interface developers for its auto-complete feature and the fact that it is a ’sister’ of Eclipse, arguably one of those ‘industry standard’ editors liked by developers at Google and many big consultancies.

Aptana works pretty well on most machines and writing code in it is most of the time pretty nice experience.

It has AJAX library plug-ins which can help develop AJAX code faster. It handles code indentation pretty consistently and nicely and works very well for XHTML, CSS and Javascript.

It disadvantage is that its upgrades can cause constant hassles to developers as sometimes they do not work properly, so for every session you might find yourself having to ‘battle’ with an update that Aptana wants you to install, but it never can be done fully. Very annoying.

Apatana also does not work very well with PHP as it requires another extension for it (or another version of the tool). So it won’t colour PHP code nicely, which is annoying when you are intending to style up a Word Press blog or another system you might have developed using Code Igniter or PHP in general.

Eclipse

I find Eclipse to be a nice tool (sometimes more suitable than Aptana), but it is not one that was designed for HTML (hence it does not offer auto-completion - which can be perceived as an advantage by those who do not like auto-completion like myself).

Eclipse is nice and clean looking and tends to work pretty good. Also does not require installation so it can work nicely in those environments and circumstances where as a developer you do not have a permission to install a tool onto a machine you are developing on.

I have been in this circumstance many times before and Eclipse saved my life.

NotePad

Old, dirty and rudimentary, Notepad’s best feature is that it is featured on all Windows machines and it is simply there.

It can be a good tool for quick analysis of code problems and writing some quick proofs of concepts or testing a particular feature for cross-browser compatibility.

NotePad, of course, does not colour code, which is not usable for working on bigger and more complex projects, but for a long time I developed code using only NotePad and it is a tool which one can rely on to a great extent.

In some cases you will be asked to develop code in environment where you will not only be disallowed from installing tools on the machine you are working on, but also be disallowed from downloading new tools (like Eclipse).

You might find, in this case, that NotePad is the only option you have, hence it does no harm to be familiar with coding in it as well!

Other HTML editors

Oxygen

I have heard from a few developers that Oxygen 8 (the last version I heard of) is a nice tool to work with.

It is an advanced tool which only costs $40 and offers nice tools and features for working with XSLT, XML and various transformation languages.

It allows you to create object oriented hierarchies of code and preview them in a usable manner. It also offers some useful transformation and testing features which make XSLT development much faster and more reliable.

XMLSpy

XMLSpy is a very good editor also, but much uglier than Oxygen and it is harder to use Oxygen’s features in it from what I have heard.

It is a nice and strict tool, which imposes development within UTF-8 character encoding and flags up all the XML non-compliance issues up front, forcing developer to be very precise and strict with their coding.

XMLSpy also is not a free tool, but it does not break the bank to buy of copy of it as I think it costs around the same amount as Oxygen.

One of the most important tools within web developer’s arsenal is the text editor.

It is a widely recognised and adopted convention among standards compliant, semantic web developers not to use tools which auto-generate HTML or CSS code.

I would strongly recommend to anyone not to use Dreamweaver or FrontPage to develop web pages.

These tools tend to create code which is either one or all of the following:

1. Non-standards compliant
2. Unnecessarily bloated
3. Not cross-browser compliant
4. Will not be sufficient when it comes to integration into larger systems (with PHP, Java, CFM or .NET back ends)

Use a plain text editor which does not write code automatically for you. It is OK if the text editor you use auto-suggests code to be used, but it is not good if the tool automatically writes code for you during your development process as you will never be 100% sure on whether the code the tool is generating is the code you want in the final web site.

I have been misfortunate enough to use early versions of tools like Dreamweaver and FrontPage and they have left such a sour taste in my mouth that I have (rightly so) made a decision never to go back to them again.

On a trial site I tried to build using Dreamweaver (probably somewhere around year 2001), the tool tended to inject so much unnecessary table related HTML that most of my time was spend taking out the code which the tool was putting in for me (even though I was in editor mode and not in visual design mode).

I got so annoyed with all this that I made a decision only to use straight, simple and free code editors, which only helped me with matters like code colouring, nice indentation, maybe some auto-suggestion and that’s it!

It has been one of the best development and process-related decisions I have ever made as a web developer.

If you are not able to write ‘hand coded’ HTML/CSS, then you really need to learn how to do it.

It is one of the big ways in which professionals are differentiated from amateurs within the industry and this is reflected within good web developer job ads, which will usually specify that ‘hand coding’ is an apsolute requirement.

Further to arguments against semantics, there are also viable and strong value-adding arguments for semantics. These are:

Semantics give meaning to interfaces

This is by far the most important argument for semantics.

Using semantic mark-up on web pages gives web pages meaning!

Many web developers today still misunderstand the basic definition of semantics and can tend towards thinking that it is somehow about ‘the look of a page with style sheets turned off’, but, in fact, semantics are all about meaning of web pages.

The ‘meaning’ is important for both users (end users and developers of interfaces) as well as machines (which are just another form of users) such as search engine robots and (in future) various semantic interface harnessing tools and languages.

Semantics add value to interfaces

Semantics add value for all types of users.

Chances are not all users of a web site have a big screens, a mouse, a powerful PC, know what they are doing and see very well.

In fact, it is 100% certain that your web site has at least 1 very disabled user, but one that plays (perhaps) the most important role in your web site - Google search robot (also known as indexer).

Semantics aid usability and scalability

Properly developed semantic interfaces are very easy to scale up, re-style and re-organise (all positive and preferable features of any IT system).

Usability of semantic web sites is usually present both from end user perspective as well as from web site developer perspective.

Usability usually saves and earns more money. One example would be the fact that an easy to understand interface is easier for maintenance and upgrading, which saves developer time, which in turn saves money for an organisation.

As an example of usability feature presented by semantic interface would be ability to call a telephone number on a web page directly from Skype, if that telephone number has been marked up as a micro format.

One click and the end user is directly in a telephone conversation with your company’s sales department, generating business for your organisation.

Increases ROI by increasing findability and re-findability

One of the most important aspects of any web sites is that it needs to be findable and re-findable.

Semantic interfaces by their very nature and the fact that they are standards compliant tend to be naturally easier to find, analyse, understand and index for search robots.

The very fact that your interfaces are standards compliant tell search robots that you know what you are doing when it comes to web development and search engines tend to treat this factor very favourably.

In future it may be the case that only standards compliant web sites will be considered ‘valid’ solutions for showing up in search engine result pages.

The very fact that (for example) your e-commerce web site can be easily found will mean that you will obtain more visitors to your site, which ought to convert into more sales for your business.

This way, semantic interfaces become direct mechanisms through which ROI of a business can be increased, without implementing anything other than the standards which have been set out for us in order to make our lives simpler and faster, while increasing quality.

Semantics enable data sharing between applications

W3C standards are not enough in order to provide semantic interfaces.

Semantic interfaces are extensions to W3C standards and can provide much more meaning than just POSH (Plain Old Semantic HTML).

With emergence of de-facto standards like micro formats, it has become possible to ’share’ data from one site with another site without much problems.

RSS feeds are also there to aid similar functionality, but micro formats create ‘interfaces as APIs’, meaning that any machine from anywhere could harvest useful data from your web site (such as your product offers) and make it available in the relevant section of their web site.

Excellent example is Google’s shopping section, which data mines product offers from various web sites on the web and then offers a comparison functionality to enable users of Google search engine to find the best deals across the web and shop from the related web sites.

Semantic interfaces can directly enable this type of functionality and is the reason why web sites like Amazon and Argos are the two most popular e-commerce web sites in UK.

Semantics enable leveraging of social networks

Apart from becoming more meaningful, the web is becoming more ‘personal’ and catered towards group of people with similar interests.

Social networks play a key role in creating these on-line communities and semantic mark-up is, once again, at the heart of enabling development and utilisation of meaningful social networks that work.

Micro formats, RSS and Atom feeds as well as RDF are just some of the examples of technologies which are making this functionality possible.

Less error prone interfaces

For a long time now I have believed in creating web sites without using browser specific hacks.

My latest development of Flexewebs CMS is a good example of how a nice web site can be created using valid (in this case XHTML1.0 Strict) HTML code and simple CSS rules in order to create a scalable and cross browser fast performing interface without any hacks.

Using XHTML1.0 Strict with W3C standards compliant mark up has always made my development life easier and created interfaces which are much easier to control using the usual development tools we have available to ourselves.

More ‘meaningful’ interfaces

Semantic interfaces are also able to communicate a corporate message in a much more meaningful manner than non-semantic interfaces.

Sharing your company’s contact details (for example) using micro formats is a much better approach than doing it in a proprietary, non-standard manner which cannot be easily found by various directories and search engines.

In our day-to-day work on creating good quality web interfaces, we inevitably come across various arguments against using semantic and proper markup in order to develop interfaces. Some of these arguments may be one or more of the following:

Semantic interfaces will not make more money for the organisation

There are many companies out there that do not know what semantics are all about. After all semantics are only now being taught at Universities.

From that lack of understanding stems the lack of belief that semantic interfaces will add more value to business and therefore make more money for the organisation.

It could be almost impossible bringing a client up-to-date with what is currently going on with Internet and where it is all heading towards.

Usually one of the best ways to show someone value of semantics is to demonstrate a working example of where they have made a difference, but often this does not work as clients can be sceptical about whether the same or similar approach would work for their business.

Semantics may only benefit Google and Yahoo

Some companies who are a little more insightful about web technologies, various activities taking place between various ‘big players’ (Google, Yahoo, Microsoft) may say that adding semantics to web pages is all about helping various data mining technologies do a quicker and better job of ’stealing’ data from various web sites and storing them in a very structured way into their own databases.

Later on, these big players will (one way or another) be making money through re-representing that data to their users in a way which, in the long term, may take users away from the initial web site where the data originated from.

This argument could potentially prove to be a very good one, but let’s wait and see what happens in the future.

An example here would be the situation of what happened with Google News, where many publishers were annoyed by the fact that their content was being harvested by Google to show a list of latest news headlines.

Publishers of news were annoyed about the fact that Google was comapring their content with competing newspapers’ content, as well as potentially stealing their advertising revenue, based on material which the newspapers wrote themselves in the first place.

Semantics are a (very) (fast) moving target

One day a micro format may look one way - another day it may change. Some clients may perceive things to be moving forward very fast, but in reality we all know this is not really the case.

If anything, things are moving too slowly forward (look at what happened with HTML5 vs. XHTML2.0 situation).

Clients may feel that constant changes which affect web user interfaces mean that ‘waiting for later’ in order to implement new features is a good idea. In reality this often proves to be a matter which loses the given company a competitive advantage.

Semantics are not really a standard

Semantics are at best a ‘tribally’ accepted set of ‘common practices’ and semantic developers disagree heavily amongst each other about what really constitutes proper semantic interfaces.

There is no be-all and end-all document which outlines all the possible situations which web developers could find themselves in from project to project. What should standard implementations then be?!

Yahoo may come up with some common patterns to use when developing for web, but may of these patterns in practice show to be an overkill or not fitting the purposes for whatever reason. Yahoo’s patterns are often suitable for ‘mega-sites’ like Yahoo itself, but not necessarily for smaller and medium sites.

Many companies simply do not care about semantics on their web sites

For most companies the age old approach of ‘just get it done’ still rules the business.

Nike made billions out of it by rephrasing that into ‘Just do it’, but in IT domain this approach is incredibly dangerous and creates solutions which are virtually impossible to maintain even in the short term and take many times longer to develop in the first place, with many more people than really needed.

This is arguably one of the biggest problems web developers may come across today when trying to implement proper solutions.

Bottom line is that clients care about money and time and web developers (wrongly) jump to conclusions that implementing semantic and standards compliant solutions will take more money and more time for the client. In fact, in practice it ought to take less time and money! All it requires is a an appropriate enough approach.

Just like anything in life, semantics, and their impact, can be evaluated within a business and it is possible to work out whether they are ‘worth it’ in terms of implementation.

They will be worth it if they add more value than they consume in order to develop.

I suppose one of the most ‘expensive’ matters in semantic interfaces can be obtaining a bad quality ’semantic’ web site solution, which does not meet standards, expectations and it’s purpose.

I would estimate that within Greater London, United Kingdom, there exist around 1000 active truly semantic web developers, most of which are constantly tied up in roles working on various big web sites.

The question is then: ‘what do companies which do not have access to these developers do in order to create proper semantic interfaces?’. The answer is: ‘they obtain solutions which do not really comply with proper guidelines’.

Reality of life seems to be that most developers are either incapable of learning semantics properly, or simply do not care about semantics.

Both circumstances are bad for companies which are looking to obtain good quality, semantic solutions in order to reap the rewards Web 2.0 can bring to them.

It is also true that companies impose unrealistic deadlines on development of semantic interfaces, which are either impossible to meet or can only be met partially.

This is counter productive for everyone, as it creates a culture of ‘not caring’ amongst developers, while companies tend to blame developers for being incapable of creating solutions which work.

I am also acutely aware of the fact that search engines are valuing semantic features on interfaces much more than before and are awarding those solutions which are easily recognised by automated tools as containing set pieces of data (such as contact details, addresses, Geo locations, events, etc.)

Many companies also struggle with implementing pixel perfect cross browser solutions, spending many hours on them, while overlooking much more important semantic related factors of their interfaces.

SEO consultancy is implemented at the very end of the process, as opposed to from the very start.

SEO unaware developers work on creating solutions for which they believe are correct and will get well optimised, something that usually results in no Google rank whatsoever, as putting an h1 around logo is seen as ‘good practice’ as ‘logo is the most important aspect of every page’, which is, of course, so blatantly not true that it is arguably not even worth discussing.

In many discussions with various developers I have heard the term ’standards compliance’ used very loosely to, usually, denote the idea that (X)HTML code of web pages on a given web site validate against a W3C validator of some sort.

Unfortunately, I would not consider simply just a W3C (X)HTML compliant web site in any way standards compliant today at all. At best, (X)HTML code validity is a fairly good first step towards achieving ’standards compliance’.

Here is a quick insight into different grades of standards compliance which I would consider as required, relevant and highly recommended for implementation on every web based project.

Good standards compliance

• Validate (X)HTML
• Validate CSS

Better standards compliance

• Include the above steps, and also
• Ensure the site complies with accessibility guidelines to at least A
• Ensure that the basic usability guidelines are followed
• Use semantic HTML throughout the whole site

Much better

• Include all the above steps, and also
• Use microformats wherever possible
• Ensure at least AA accessibility compliance
• Ensure graceful degradation of the code (especially JavaScript)
• Make sure your pages are below 100Kb in size by all means

Best

• All of the above, but also
• Make sure the web site is usable (not just accessible) within a screen reader, which should also mean that the web site is easily usable for normal users without use of a mouse
• Create site architecture which is SEO ready from the outset (including pretty URLs)
• Ensure compatibility with future browsers/clients (mobile phones, playstations and small laptops)
• Ensure that the overall solution is very consistently implemented, including common approach to component coding, clear and concise reusable site portions, etc.
• Ensure (re)use of commonly recognised and well adopted UI design patterns
• Code with future compatibility in mind, so as to ensure forward compatibility with emerging technologies and new versions of web browsers

The above check list is by no means definite, final or full, but it is a good starting check point to ensure that the end product of a web site is of high quality and fit for the web of today and evenly reaches all types of users hitting your web site day to day.