Archive for April, 2009

Semantic uses of <h1>, <h2> ... <h6> HTML tags

Friday, April 24th, 2009

What is it for?

<h1><h6> tags are intended to mark up various levels of headings and subheadings.

<h1> carries the biggest importance, with each heading below carrying lesser importance.

Appropriate uses

Use only one <h1> per page

<h1> tag is intended to denote the highest level heading on a given web page.

It explains what the web page is about, and since a good web page ought to have one purpose, <h1> tag should therefore be used only once on each web page to avoid confusion.

This guideline is not in the HTML specification, but has been adopted by all good web developers I have met and worked with so far.

It is also a guideline accepted by SEO experts since Google and other search engines treat the <h1> tag with high level of importance.

Use <h1> tag on any given page only once and make sure it uniquely entitles what the page is about.

Use <h2> as component level headings

Take a look at an example of how to use <h2> tags as component level headings.

<div id="news">
   <h2>Latest News</h2>
   <ul>
      <li><a href="www.example.com">News item 1</a></li>
      <li><a href="www.example.com">News item 2</a></li>
   </ul>
</div>

If you needed subheadings within the scope of this component you would follow up with <h3> subheadings. For example:

<div id="news">
   <h2>Latest News</h2>
   <h3>Business</h3>
   <ul>
      <li><a href="www.example.com">News item 1</a></li>
      <li><a href="www.example.com">News item 2</a></li>
   </ul>
   <h3>Science</h3>
   <ul>
      <li><a href="www.example.com">News item 1</a></li>
      <li><a href="www.example.com">News item 2</a></li>
   </ul>
   <h3>Education</h3>
   <ul>
      <li><a href="www.example.com">News item 1</a></li>
      <li><a href="www.example.com">News item 2</a></li>
   </ul>
</div>

Inappropriate uses

Heading levels are seemingly simple tags to utilise within web pages, but even they have been somewhat abused by developers and tools which generate them.

Thinking about them in context of many different systems also makes the issue somewhat more complex and some lateral thinking is required to code them up most appropriately.

<h1> around the logo or company name

<h1> should not be used around the logo or the company name.

The simplest way to explain the reasons behind this is to take an example of BBC web site, which, if it had <h1> wrapped around it’s logo would have couple of million pages with ‘BBC’ as the main title on each page.

It is obvious from this example that it is not semantic to wrap an <h1> around the logo or company name on any web site, small or big.

Doing so decreases semantics of such web pages and is therefore bad practice.

It is also arguable that if there is no ‘cadidate content’ for an <h1> on a given page, then the Information Architecture of the given page is wrong and needs to be re-thought.

Essentially, good design should include a clean title and purpose for existence of each page and a developer should wrap that main title into <h1> level heading.

The only place where <h1> makes sense to be used around a logo is on the very homepage, just like it is the case with BBC web site.

The homepage represents an overview of what the organisation offers, hence on the homepage the main of ‘British Broadcasting Corporation’ makes sense for the BBC web site.

<h1> as heading for components

Once again, there should be only one <h1> heading on each web page.

Some developers (usually the ones from design backgrounds) have misinterpreted the purpose of <h1> and have decided to go along with the development practice of using an <h1> heading within each component.

This usually results in several <h1> tags being used across any given page, with <h2> tags and lower level tags getting either very little or no prominence.

<h2> tags are much more appropriate for component level headings and should be used for that purpose.

If a component is taken out of context from one page and placed into another page, the <h2> heading of that component will not confuse with the semantics of <h1> tag on the new page.

Repeating <h1> many times on one page

This should never be used as it dilutes the overall meaning (semantics) of the page and confuses screen reader users.

Misusing headings for visual display purposes

This misuse of heading tags is usually observed with amateur developers who do not understand semantics.

Under no circumstances should you use a given HTML tag just because it renders in a certain way in the browser.

You should always use CSS for look and feel and disregard the default rendering within the browser to achieve desired design effects.

Only pay attention to what the meaning (i.e. semantics) of the tags actually are.

Muddy areas

Should <h1> contain the same content as <title> tag?

Most SEO experts think so and it seems to make sense, but also throws up a question about purpose of having both <title> and <h1> tags if they are going to contain exactly the same content?

This is the reason why proposed <h> tag in XHTML2.0 makes much sense, as it makes the ‘level’ of a given heading less contextually sensitive.

It also allows page level as well as component level headings to be more ubiquitous and reusable from system to system, without developers having to change the code around to make every interface as semantic as possible when reusing the code.

What’s the purpose of low level headings?

It is also the case that tags <h4>, <h5> and <h6> are an overkill for most every day web sites, but can be too limiting for chunky, long, detailed PhD type dissertations which may require many more heading levels.

This is where it could be argued that HTML specification falls short, making the XHTML2.0 <h> proposal very viable in this respect.

Once again, using <h> would solve this problem enabling any number of nested headings, but I wonder how we would be able to style these in a meaningful manner using current CSS implementation and specification.

Social tools are not collaboration tools

Wednesday, April 22nd, 2009

With proliferation of social web, one big paradox has finally become apparent: social tools are not collaboration tools.

During my Master’s Degree in ‘Business Information Systems’ in 2003 at Royal Holloway College – University of London, we studied the topic of communication and covered various aspects of good and bad communication practices.

My end of year dissertation was entitled ‘Managing Virtual Teams in Entirely Virtual Environments‘ and I focused on trying to answer the question of how to manage people one has never met before by using interactive, web-based tools.

6 years on and various people are writing and talking about these technologies, now calling them ‘Enterprise 2.0′ and trying to push them onto corporations with little or no luck.

One of the main reasons why there is little or no luck in proliferation of social tools in corporate environment is because social tools are not collaboration tools.

Corporations require collaboration tools which help employees do their jobs faster, better and with less hassle, while, if at all possible narrowing down the amount of information which is generated, as more information usually means more clutter and eventual information overload.

Aspects of social tools

Social tools by and large help users generate content of various types.

Blogs, Twitter, Wikis and various other tools are there to enable quick and easy, but usually not very structured content.

Social tools also encourage ad-hoc content replication and sharing.

It’s a common place for a user to send their friend a link through FaceBook (usually to something not very productive or useful) and for people to talk about every day things through Blogs and Twitter.

Wikis are potentially great tools for ‘dumping’ information onto, but have proven not to be very social at all and any meaningful collaboration through a Wiki is virtually impossible.

The greatest aspect of Wikis, their ‘freedom to edit anything and everything’, proves to be their biggest enemy, as users to create totally messy, unstructured information resource which have little or no usability, leading to eventual certain death of any Wiki based resource.

This may well be one of the reasons why the whole of Wikipedia is basically edited by a group of not more than a 1000 regular, heavy-weight contributors, hence not representing ‘knowledge of the world’, but an extreme example of 80/20 principle in action.

Wikipedia is also maintained as a very well structured resource, making it essentially into a ‘CMS where every page can be edited’.

Aspects of collaboration tools

Social tools work very well in context where a number of people who know each other very well are loosely collaborating together on simple, well-known, social and unimportant matters.

Real life business environments are usually about ad-hok ‘teams’ (in reality these are groups, which is considerably different) of ‘experts’ who have never seen each other.

They usually have to immediately ‘hit the ground running’ working on complex systems which are hard to develop even through regular face to face collaboration.

If these projects are to be achieved, specific communication protocols and structured tools are required.

As a basic example think about doing simple accounts for a 5 man company.

Even this seemingly trivial task will not easily be done over a Wiki, Blog or anything ‘social’.

It will, however, be done quite nicely over a structured accounting tool, designed for collaboration on the given topic, which in this case is the company accounts.

A collaboration leads a user towards some form of closure and task completion, sets a framework of operation and aims at stopping unnecessary content production in order to move users onto the next stages of the project or business development.

This is the reason why we have started seeing proliferation of tools such as BaseCamp and Xero and those tools being relatively liked by their respective users.

People do not socialise at work

How many times have you come across random people in an office saying to each other ‘let’s socialise’?

Well, this is what ‘social tools’ are asking of people to do and it is only natural that ‘let’s not socialise’ approach is only amplified on-line, where users have to battle other various obstacles in achieving their tasks.

Corporate environments are usually also politically charged, making digital collaboration best if the focus is purely on the task.

People who do not know each other have not gone through the team building processes of forming, norming, storming and performing.

They have usually jumped straight into the ‘performing’ part and therefore only task oriented communication leads towards successful task closure, which in turn leads towards satisfaction and progress of the overall projects and business.

Any socialisation at work is usually minimal, accidental and there to while away the time between employees, or caused just out of sheer politeness within the given culture.

What’s the real future?

It is becoming clearer every day that tools such as FaceBook are used by most people as their ‘personal spaces’, where people do not even want to ‘socialise’ with their work colleagues unless they get on well as friends at work – which are rare circumstances in most companies, especially the big ones.

Structured, collaborative tools which are designed to solve particular business purpose will see a big take up and are already arguably seeing it.

Various collaborative development tools such as Google Code and to even greater levels Assembla are a good example.

It will need to be possible to integrate these tools to work alongside other structured, collaborative business tools which will be solving another specific business problem.

Semantic web and modular approach will play crucial parts in this future along with the well structured system architectures which will enable easy data portability and reformatting.

Most business tools suffer from incredible usability issues, which is mostly caused by the fact that most businesses either completely disregard usability or try and retro fit it into their solutions at the very end of systems development processes (as opposed to at the very beginning and throughout the development processes).

With better usability engineering, utilisation of better, common standards and realisation that collaborative does not necessarily equal social, the world of digital business will successfully plunge into proper future where most employees will collaborate and not need to be co-located.

For now, we have ‘Enterprise 2.0′.

20 reasons why Twitter will fail

Monday, April 20th, 2009
  1. Twitter is not going to be highly profitable ever, as the ‘ad game’ will always be dominated by ‘clever algorithms’ which will always be owned by Google. Twitter will not be able to compete with this. Twitter’s earning potentials are not as wide as the earning potentials of FaceBook and Google who have the scope to expand their services to anything and everything they want to.
  2. Novelty factor will wear out and early adopters will become bored of using it. They already are in many cases
  3. Too many people will start spamming the posts. They already are, using automated tools to follow random people mentioning a target key word.
  4. Automated bots will take over the service (and have already done so) for SEO or other reasons, posting tweets in order to try and SEO their web sites through ‘organic’ means.
  5. People will move onto ‘cleverer’ ways of marketing and having ‘conversations’, just like they have moved on from blogging to twittering.
  6. Most people do not Twitter about one topic only, which will be confusing for those interested in following only serious discussions. This will create lots of useless and uninteresting tweets for the followers.
  7. When following many people it is virtually impossible to make any sense of the service as there are too many updates happening at any point in time and Twitter tends to take over one’s life totally and completely. Users will realise sooner or later this way of communicating is not maintainable and will start using the service less, which will in turn wear down the usefullness of the service which is mostly about semi-real-time conversations.
  8. It is impossible to have a proper, meaningful conversation over it on any semi-serious subject.
  9. Competition will take users elsewhere over time as it has done with many other social networks.
  10. ‘Clone services’ will offer companies a specific ‘Twitter clone solutions’ which suit the company behaviour and needs. An average user may find themselves having to Twitter in many different locations, which will become cumbersome and hard to keep track of. They are already twittering on Twitter and Facebook at least. ‘Twitter clone solutions’ are already available on the market and will be used by companies for internal communications purposes.
  11. Twitter is too simple and requires too many 3rd party services in order for anything more clever to be done with it. This means that users are potentially going to need to use two or three different Twitter applications installed on their machine in order to do everything they want to do with Twitter. This is asking too much of users and most users will not want to do this.
  12. Users will not want to Twitter in many places and FaceBook or similar service will take over the market share with time as they have a wider market appeal and people are more reliant on FaceBook and Google for example.
  13. Advanced capabilities will be too hard for average people to grasp (some users I have spoken to have problems adapting to service and I know other people who do not understand the concept at all and possibly never will).
  14. The whole concept is too far fetched for most people to understand and requires imagination in order for anyone to make use of it in any meaningful way. Most people do not have the required imagination and attention span in order to user Twitter for anything worth while for them, hence they will not ever see the point in using it.
  15. People will not want to share their day-to-day activities with the world in future and will feel that anything short they say in real time will be more than lost in the see of tweets which will polute the world in any second of any day. It will be very difficult to stand out.
  16. There are potentially major security risks associated with Twitter and as those risks become exploited over time, the brand will become less and less appealing to most people, leading to lesser popularity and slow death over time.
  17. Twitter’s exponential growth will mean that there is much of ‘junk information exchange’ from auto-bots and various other bolted on algorithms going on the site, not adding value to users, while adding an expensive overhead to Twitter’s bottom line. This will be almost completely unsustainable in a very short period of time.
  18. There is no specific Twitter microformat standard which would enable simpler aggregation of Twitter content from across the web.
  19. Twitter will find it virtually impossible to provide users with tweets which are relevant to their needs and interests as algorithms for these requirements will be far to complex and will use up too many server side resources to be run on daily basis
  20. Company behind Twitter does not have the intellectual and corporate capacity to expand fast enough to serve the demand, making their success and popularity eventually lead to their own destruction with time.

13 reasons why Twitter is so successful

Wednesday, April 15th, 2009

Here are some of the reasons why I think Twitter is so popular. These are written in no particular order and this is by no means an exhaustive list of reasons why Twitter might be so popular.

  1. It’s an extremely easy concept to pick up for anyone without any training whatsoever
  2. It’s highly usable through all types of web enabled devices
  3. It leverages existing, globally adopted content generation practices such as text messaging which is already incredibly popular
  4. It brings a novelty factor and a new arena within which marketeers and tech enthusiast can experiment in and inevitably end up viral marketing it due to their initial enthusiasm about the tool
  5. Most users today find blogging or web authoring cumbersome, but will happily Twitter away as it’s easy and quick
  6. Most users don’t posses serious writing skills and Twitter does not require serious writing skills
  7. Users don’t have time to write and read anymore and Twitter messages are well within the threshold of average user’s attention span
  8. Internet suffers from a massive problem of information overload and Twitter seems to offer a way out of it to some extent
  9. It is still virtually impossible to do more serious work (blogging and authoring) on modern portable devices today, even Net Books. The most that can really be done is an odd Twitter message here and there, so most users then spend time doing what they can with the tools that are available to them today
  10. Internet just wasn’t designed for big, lengthy, hard to read articles and books, so users are much more likely to read tweets and stick to reading them over longer period of time
  11. It’s a fairly immediate way of communicating and can be very personal, which beats most other forms of communication
  12. Users like trivia and nonsense as we live in the world of entertainment today and Twitter offers much light information, non-stop at every one’s easy disposal
  13. The curiosity and celebrity backing which has surrounded Twitter drives users towards experimenting with it and trying to work out what the hype is really all about

Please do comment with your own views and opinions on why you think Twitter is so successful.

Semantic uses of <a> HTML tag

Wednesday, April 15th, 2009

What is it for?

<a> tag in HTML stands for ‘anchor’ and is used for marking up hyper links to other web resources.

Links can reference another HTML page or point to a particular section of the current web page through use of id or name attributes.

Muddy areas

href attribute with in the <a> tag specifies the location of a web resource and (according to the HTML4.01 specification) can be left empty, so that a script of some sort can add this value.

The exact quote is:

Authors may also create an <a> element that specifies no anchors, i.e., that doesn’t specify href, name, or id. Values for these attributes may be set at a later time through scripts.

This is an interesting aspect of the specification as it leaves room for many different functional requirements which are often present in Web2.0 type interfaces which rely heavily on JavaScript.

For accessibility purposes though, this aspect of the specification does not make much sense, as user interfaces ultimately ought to work without presence of any scripting whatsoever and this would leave anchors without an href useless and inaccessible.

I would therefore discourage developers from using empty anchors in their web sites.

Content as code

There were number of discussions on the web about the most appropriate ways of linking to web pages.

There are numerous usability guidelines on how to best write content to be displayed within links.

There are also those developers who believe that each link should have a title attribute present within it, which is wrong, as title attribute only ought to be used on links which do not have descriptive enough content within them.

However, if you follow usability guidelines and only use link text with descriptive content, then you should not need to use a title attribute along with your <a> tags.

Having written this, within Web2.0 context, it has become a de facto standard to use title attribute within a list of links containing a gallery of images, where title contains a caption for each main image to be displayed.

I don’t see anything particularly wrong with this approach and would therefore encourage it.

Link content is almost code within the reams of semantic web, as search engines like Google have been built upon following links and using their content in order to rank various web sites (of course this is only one of many aspects which Google takes into account and search engine optimisation deserves another whole book’s worth of explanations).

Jakob Nielsen has also come up with interesting research from usability perspective on how the first 11 characters of the anchor text are enough for users to work out where the given link is going to lead to (see: First 2 Words: A Signal for the Scanning Eye).

All of this is part of good, semantic coding practices.

Further considerations

With emergence of micro blogging, services such as TinyURL have become incredibly popular, creating shortened versions of a link to longer versions of the (original) link.

Best practice for dealing with these types of links is to use the rel attribute and give it a canoncial value.

For example:

<a href="http://tinyurl.com/d9oxbs" rel="canonical">http://tinyurl.com/d9oxbs</a>

It is also interesting to observe that the above outlined practices are not usually followed in these circumstances due to various system restrictions, hence canoncial is required in other to signify that the shortened link’s only purpose is to save some valuable space on a typical Twitter message for example.

This attribute can also be used in order to denote those web resources which have a different URL, but underneath are acutally the same resource.

Further reading

Official Google Webmaster Central Blog: Specify your canonical

Semantic uses of <p> HTML tag

Monday, April 13th, 2009

What is it for?

<p> tag is a very nice, semantic tag simply intended for marking up paragraphs of text and that is it’s only purpose.

Appropriate uses

In a code block like this:

<p>This is an article about paragraph tag in HTML.</p>
<p>When we are marking up paragraphs in HTML we should use it for actual paragraphs of text and not for anything else. Paragraphs are only intended to be used for this purpose.</p>

we currently have two equally weighing paragraphs of text in terms of semantics.

However, as an author of this text, I actually intended first paragaph to be a description of the second paragraph.

Semantically speaking, changing the above code to:

<p class="description">This is an article about paragraph tag in HTML.</p>
<p>When we are marking up paragraphs in HTML we should use it for actual paragraphs of text and not for anything else. Paragraphs are only intended to be used for this purpose.</p>

adds a layer of additional semantics to the code giving the first paragraph a little more meaning and implying that it is a description of some sort.

The reason why I used a class instead of an id is because I could have many different descriptions on one page in any given system.

Inappropriate uses

Empty line break

Wrapping text into a <p> tag creates a natural line break after the text and some developers are often tempted to use a <p> tag to wrap a non-paragraph text into it or even use a blank <p> for the purposes of creating a line break.

Using paragraphs instead of a list

Sometimes you will come across a list of some sort being implemented as a series of paragraphs.

Consider the following code block:

<p>Semantics are good.</p>
<p>Semantics help the world.</p>
<p>Semantics are good for Internet.</p>
<p>Semantics create better solutions.</p>

Each one of the points made in this list is not really a paragraph.

A paragraph is usually a longer piece of text, while here we are looking at a list of short points about semantics, which belong to a same ‘group’ of thoughts or points.

The above list of points would therefore much more apropriately be marked up as a <ul> block, an unordered list of points about semantics.