Archive for March, 2009

Who builds software?

Tuesday, March 31st, 2009

This is perhaps a strange title, which could have a simple answer: developers and/or engineers.

In reality, however, modern software solutions work in much more sophisticated and complicated ways, even though they may not be apparent or present on most web solutions as yet.

The overall trend in software engineering is heading towards user generated content, user generated layouts and even user generated functionality.

It is also true that software is built by some or all of the following too:

  • Business stake holders
  • Tools used by engineers to build software (see ‘Overview of Code Editors‘)
  • Software architects
  • Automated back end systems which spew out content (and code), etc.

All this is fine, but the ultimate aim of the web should be towards re-usability of everything that is created, by whatever means it was created.

All these methods of content and code generation are potential friends, but in most cases fierce enemies of semantic web.

Problems in user generated code and content

Here are some examples where semantic web solutions are jeopardized:

  • A back end engineer rarely produces a good piece of User Interface code
  • Microsoft Front Page will never create a good piece of User Interface code
  • A software architect may produce a prototype which is only semi-semantic, but ends up being used as-is in the final solution due to (perceived) time and money constraints on a given project
  • Automated back-end systems spew out content which, at the time of development, may have been considered great, but today is seen as semantically invalid
  • There are many examples where code and content are mixed together and virtually inseparable and does not conform to Emerging Semantic Web Structure

Many Java libraries for AJAX produce inline JavaScript code which works in a browser or two, but would fail every single semantic test thrown at it.

Why? Because it was produced by a Java back end developer, who likely never heard about unobtrusive JavaScript and will likely not hear about it for a while as ‘it’s outside of his area of expertise‘.

Internet is moving towards the age of user generated interfaces, while in many cases the basics have not yet been put into proper practice.

Often a time code is also generated directly by administrator users of systems, writing ‘content’ through a WYSIWYG interface.

I have witnessed those users put a whole web pages into sections of another page, because that’s the only way they knew how to copy content from one web page into a CMS.

Needless to say this practice creates a whole bunch of junk web pages which are not fit for any purposes whatsoever, let alone being semantic in nature and reusable.

Our aim as web professionals should be to create semantic solutions at all levels, no matter how content and code for those solutions is produced.

End user generated code and content will pose even bigger challenges to engineers, developers and architects who will really need to think hard how to create solutions which are truly ubiquitous.

Whatever or whoever ends up building your software, it or they need to be able to produce a reusable, semantic solution.

Semantic uses of <span> HTML tag

Tuesday, March 31st, 2009

W3C defines <span> tag in the same way as <div> tag. I would argue however that <span> has no semantic meaning associated with it, unlike <div>, which denotes some form of a division on a web page.

What is it for?

<span>s are great for adding ‘hooks’ into your HTML documents and lend themselves well to creating bigger aspects of semantic web (such as micro formats).

Unlike <div>, which is a block level element, a <span> is an in-line element, so it is really easy to use it inside the document ‘flow’ without affecting the layout and design.

<span>s are most often found within a bigger ‘soup’ of other HTML tags (see examples for better description).

Appropriate use

<span>s should be used for providing additional meaning to snippets of content which are below the description threshold of other (more semantic) tags.

Furthermore, <span>s provide us with an ability to further describe the content wrapped within otherwise semantic tag.

Example (good use of <span>):

<p class="message">
<span id="hcard-jason-grant" class="vcard">Jason</span> says: <span> is a great way to integrate microformats into bigger semantic document.
</p>

Inappropriate use

I have seen some developers use <span> tags in order to denote a component on a page. These are situations where <div> tag is much better suited for and should be used instead of <span>.

Example (bad use of <span>):

<span class="component">
<p><strong>Jason says:</strong> This is my message.</p>
<p class="reply"><strong>Grant says:</strong>This is a reply to a message.</p>
</span>

The above example is wrong for a number of reasons including:

  1. It does not validate because <p> (a block level element) is inside a <span> (inline element)
  2. Having more than just some straight snippet of content inside any given <span> block usually implies wrong coding of HTML. <span>s should therefore not contain any other tags within themselves, including nesting of <span>s.

Out of any element in HTML specification <span>s are the most semantically neutral.

Many developers claim that <span> and <div> are equivalent, with the only difference that <span> is inline, while <div> is a block-level element.

This, in my experience, is not true, since <div> contains semantic meaning and has been used for a long time now to add much semantic value to interfaces.

Although <span>s on their own are semantically neutral, they can be given much more semantic meaning by associating classes and ids with them.

This is regularly done when coding up micro-formats and works very well, as associating class names with a given <span> the layout of the given content can stay the same, while machines can pick up the exact meaning of the data within the tag perfectly.

Web site types

Sunday, March 8th, 2009

Common misconception about web development today is the idea that there is a ‘right approach’ for web development in general.

I have now worked on various size web sites, privately and through bigger companies, through agencies and on the client side.

My experience has taught me that web sites come in various types and sizes and usually require somewhat different development approach applied to them in order to achieve the optimal result.

There is no ‘one size fits all’ software solution out there.

Essentially, making a small site usually requires radically different approach and architecture to making a massive web site.

Some examples of web site types are outlined below:

A simple ’5 pager’

Typically, a simple, static web site will contain no more than 5 pages of HTML/CSS code to represent the very basic information about a company or an individual.

These types of web sites usually require a simple 1-2 templates, a nice design, simple 1-level navigation (such as a horizontal navigation strip) and a few pages outlining information about the subject at hand.

There is usually not much scope for code reuse on these types of web sites, but you might find an odd microformat will suit some pages (like ‘contacts’ and ‘about’ pages).

These solutions should be implemented as simply as possible from the front and back end point of view and should work very fast.

Static HTML will often suffice, although some reuse of common snippets may be helpful in the case you want to quickly add another couple of pages to the site.

Small CMS and blogs

Often a time people will want to start with a ’5 pager’ and ‘grow’ the site into a bigger web presence.

In order to achieve this, we would need to use a CMS (Content Management System) or a Blog tool (such as this Word Press blog I am writing), both of which will enable us to add pages through a WYSIWYG (What You See Is What You Get) interface.

I have found that ‘growing’ a ’5 pager’ to a larger web presence is often impossible, as the overall structure for each solution can be quite radically different (e.g. how large is the web site going to become?).

Semantics of the web site may be impacted in a negative way and the solution will not be optimal, unless you are really clever in the approach and can envisage exactly what the client may want to do in future (usually requires the client to know what they want, which is often a far fetched wish in my experience).

Within these types of web sites we may come across ‘common components’ which can be subject to heavy semantic treatment and we may be able to build some very clever and scalable data components which can go a long way.

Creating context independent widgets is another possibility with CMSs and Blogs, so the solution is usually radically different from a simple ’5 pager’.

CMSs and Blogs also lend themselves towards being integrated into ‘greater web’ via RSS, so that latest news pieces from a given CMS web site can be found at Google News search for example.

Blog posts could be submitted to Blog Search engines for more visibility and relevant traffic building.

Web applications

These are the types of systems which behave similar to Desktop Software and require heavier presence of the behaviour layer (usually in form of JavaScript and/or AJAX) in order to enable users to carry out richer and more complex interactions through the interface.

A great example of a web application is Google’s GMail, however one could argue that it is not implemented at all in a semantic way, as the solution does not work at all with JavaScript switched off.

Real semantic solutions should not need two version of the system being built in order to cater for different types of users, but this is somewhat of a holy grail which most companies still have not fully grasped (at the time of writing).

Web applications are usually much more complex to implement and require much deeper analysis and understanding of user behaviours, as well as a better insight into the overall technical solution which will underpin the required user needs.

Scalability of web applications is also another aspect which plays a big part in their success, relevance and performance, all of which impact on users and the semantics of the solution.

I also think of collaboration tools, such as BaseCamp, under the web application banner.

They are not social tools in my view as they are there to help enable dispersed groups of users achieve something common together (I define social tools as different in purpose to collaboration software).

E-commerce

E-commerce web sites are basically portals which sells goods of various types.

Having worked on many large and small e-commerce projects by now, I have realised that an entire typical e-commerce web site is on giant pattern.

Each e-commerce web site usually has: product lists, product individual view, product search, basket, ordering process, address management, special offers, etc.

These options, which we can quite easily map as thought processes, very much lend themselves towards standard semantic thinking and implementation.

I would not be surprised to see a standardised e-commerce semantic solution at some point very soon provided by a consortium of developers.

Social tools

Much of the social ‘software’ nowadays is not really software, but rather ‘tools’ with which the users can carry out some simple action (i.e. Twitter allows posting of 144 character long messages to the internet).

Social tools enable users to socialise online and promote their causes (great for marketing), but do not enable people to achieve a common goal together (this is the difference in my view between social software and collaboration software).

Due to their specific nature, social tools lend themselves to different kind of semantic treatments, with lots of RSS and various other social micro formats like XFN and XOXO.

Multimedia sites

Web sites such as YouTube in my view come under the banner of ‘multimedia sites’, since they are entirely about multimedia content, which is nowadays best served through Flash movies, as Flash plugin is most widely installed extra browser feature.

The key aspect of the multimedia web site is the ‘widgetising’ of the content so it can be included in any other web site by users with very little or no technical knowledge.

Multimedia sites today usually have various accessibility related issues, which are still being worked on by and large.

Making videos accessible is fairly tricky and requires quite a bit of work, but it is still semantically possible to do it.

Expert business tools

Custom business tools, such as bespoke software for financial products management, are increasingly being developed with utilisation of web interfaces.

These types of systems are often very complex, contain dense information on screen and require expert user understanding of the products in order to be used.

These systems are equivalent to a Boeing dashboard, which usually only makes sense to a qualified pilot who has gone through rigorous training in order to learn how to use the system.

These kinds of systems are a completely different type of an animal and to lesser extents are affected by common web usability guidelines and best practices.

These systems require very careful development approach as well as people who have very good domain knowledge of the underpinning industry and its relevant standards.