Archive for the ‘Advanced’ Category

Newer Entries »

Semantic web design process

Wednesday, June 11th, 2008

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’.

Tags:
Posted in Advanced, Business | No Comments »

Semantic uses of <div> HTML tag

Friday, June 6th, 2008

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.

Inappropriate 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 circumstances) 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 these 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.

Name spacing 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.

Tags: ,
Posted in Advanced, Development, Intermediate | 14 Comments »

Pareto analysis of HTML

Wednesday, June 4th, 2008

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.

Tags: ,
Posted in Advanced, Development | 7 Comments »

Current situation and value of semantics

Tuesday, May 27th, 2008

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.

Tags: , ,
Posted in Advanced, Overview | No Comments »

Standards compliance

Monday, May 26th, 2008

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

Better standards compliance

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.

Tags: ,
Posted in Advanced, Overview | No Comments »

Newer Entries »