Archive for the ‘Levels’ Category

« Older Entries
Newer Entries »

Progressive enhancement

Thursday, June 11th, 2009

So far I have touched on the topic of emerging semantic web structure, outlining the appropriate way in which we should layer web technologies.

This approach is often refered to as ‘progressive enhancement’.

It is the development approach designed to make sure that a web page works no matter which end user client it is accessed by.

When using progressive enhancement, you should make sure you code up your (X)HTML as semantically as possible first, then style things up with CSS and at the very end add JavaScript behaviours or AJAX enhancements.

This approach ensures that a web page is fully accessible even when JavaScript is not present or not fully supported by the client accessing the web page.

Progressive enhancement is more work?

Following progressive enhancement approach, however, can prove to be much more cumbersome and time consuming, compared to not following it.

This is especially the case when building web applications, such as GMail or Google Calendar.

Web applications can often require two parallel solutions to be engineered for circumstances where JavaScript is available and for circumstances where it is not.

This is one of the reasons why GMail, for example, has an ‘HTML only’ version available as a separate link, while the main version of GMail does not work with JavaScript switched off.

Another likely reason why GMail does not work without JavaScript is the fact that Google engineers use GWT (Google Web Toolkit written in Java) to create all their interfaces with.

GWT spews out user interface code which completely breaks the above outlined good practices, yet creates code which still works cross browser.

Since Google engineers tend to think about back end logic of applications as a matter of priority, their outlook on web application development can be described as graceful degradation.

Graceful degradation

Unlike progressive enhancement, graceful degradation approach assumes all technologies are supported and ensures that users have best possible experience when they are enabled.

Once this is achieved, the considerations are given towards circumstances where certain technologies are not supported and how to deal with them.

Graceful degradation is arguably more appropriate approach in the short term, as the main business objective is to create a working interface for the main user group as soon and as cheaply as possible, while serving the minority user group if and when possible.

This is how most of the very profitable web sites have been developed.

Hard to maintain software is dead software

In the long term, however, graceful degradation approach will more than likely mean that a given application is much harder to maintain and update, as the code is not developed according to semantic standards.

This can mean that future development and progress can only be achieved by completely re-writing a solution from scratch, which can lead to long down times, difficult migration processes, massive costs of re-development, stifled innovation and many other unwanted side-effects.

An extremely good example of this is MySpace, which is one of the worst applications ever developed, which has seen very little to no improvements in the last few years. This is more than likely due to the poor quality of the initial development and extremely bad User Interface code quality.

MySpace’s poor quality user interface code also means it is very tricky to create nice skins for MySpace profile pages using CSS, as the underpinning HTML code is very poor.

This means that MySpace’s very sales pitch of enabling users to customise their profiles however they like is flawed due to the inflexibility in the coding deployed by MySpace developers.

Using graceful degradation also creates a harder environment for developers of various skill sets to work within, as within Google setup any developer working on GMail will have to be a wizard in GWT.

In semantically developed interfaces (i.e. progressively enhanced) a company can employ a relatively cheap CSS developer to develop themes for their CMS or web application without ever needing to touch HTML or JavaScript.

In this environment the company developing the solution has the ultimate flexibility and control over their toolsets.

In progressively enhanced interfaces it is also much easier to delegate work amongst developers, as one person can work on CSS, another on HTML and the third on JavaScript, without developers stepping on each other’s toes all the time.

Posted in Development, Intermediate | 2 Comments »

Big corporations will kill the web

Tuesday, May 12th, 2009

The inception of web

In the initial days when ‘The Web’ was in its inception stages, there were a few people who were putting together the nuts and bolts of how the whole concept was going to work.

Tim Berners-Lee, of course, was a great visionary with much common sense, great ideas and a solid ability to put together simple concepts which were able to achieve relatively complex tasks (something that every great web standard ought to be able to do).

There were no ‘big players in the game’ such as Google, Microsoft, Yahoo, eBay, Skype and so on.

The mass media, capable of shooting down any idea through leveraging simple group think, was also much less influential at the time.

The emergence of the giants

Few decades later we live in the world where conglomerates are the ‘standards setters’ and play a crucial role in what is done on ‘The Web’.

Today we have Google, Yahoo, Microsoft and other big IT corporation proactively ‘contributing’ to the web standards at W3C.

They develop tools which render those standards relatively well and then implement solutions which do not follow those standards.

The situation created in real life is one where good developers follow standards as much as it is possible, while most others do not.

Microsoft creates a browser which handles most of the junk UI code pretty well, which institutes bad practices across most of the web as ‘stuff just works’, even though it is poorly coded.

Since most developers do not know about, or simply do not care about standards, majority of the web content is published with very poor code.

Do not lead by example

Google’s home page could be a great example of a web page developed according to standards and best practices, but it is arguably and example of the worst practices all in one, short, simple HTML 4.01 page.

Leading by example is obviously not something that Google care about at all and therefore I question their contributions to W3C altogether.

Most mega popular web pages still contain masses of in-line code (CSS and JavaScript) stewed together with non standards-compliant HTML 4.01.

The main IT corporations are extreme examples of very bad practices in real world while we are lead to believe that Google engineers are ‘the best of the best’.

I have no doubt that Google’s engineers are the best Java developers in the world, but their front end skills are certainly somewhat to be desired!

In fact I still have not come across a single Google page which follows User Interface Best Practices and it is incredible to think that they do not really care, or know, about simplest aspects of accessibility within their interfaces.

I shall be covering more concrete examples of how Google break the web by breaking some of the simplest to implement best practices in their own web pages.

The doomsday is coming

One of the most concerning aspects of the influences conglomerates exert onto ‘The Web’ as a whole is that they all have to aim towards a monopoly.

Monopoly and oligopoly is what ultimately every corporation aims towards achieving as publicly traded corporations are forced to grow all the time in order to increase their share price.

By definition, monopoly is always bad for the end user, as it forces people into having to buy one particular brand or solution and it discourages or even purposely kills innovation.

In the case of Microsoft, they tried to monopolise through use of their own proprietary solutions and their strategy is still the same, largely based around the Windows Operating System platform.

Google ‘changed’ the rules by adopting open source technologies, only to start playing the same proprietary game like Microsoft in recent years, through development of their own APIs and their own protocols for application development in the cloud.

This approach leads to the same monopolistic outcome of lack of innovation over long term, just like Microsoft caused.

This is because it locks developers into having to work within a very closed ‘standard’, which is not really a standard as it only works on Google platform and is only relevant to Google’s APIs and architecture.

Adobe pitched in with the AIR concept in order to try and grab the ‘bridge market’ between cloud and the web, with relative success, but the outcome is still that AIR is a proprietary platform solution which belongs to one, commercial company and tries to lead to monopoly at all times.

Apple, arguably the biggest ‘standards criminals’ of all, have for a very long time openly deployed an approach of locking users in and always developing entirely proprietary solutions, which they then monetised heavily once the users got used to the initial devices they bought and realised they could not port to other platforms.

Apple are extending the same approach to the web with iTunes and the iPhone platform with significant success and many developers are more than happy to ‘buy into’ the whole concept as they might make money out of it, just like many people bought into Google’s ‘free’ solutions which meant giving all the data away for free, leading to a heavy potential long term ‘lock in’, as shifting massive amounts of data from one provider to another is always likely to be a massive hassle.

Last but not least, various mobile phone corporations have, in recent years, jumped in on the act and, through their leverage of various mobile devices, started creating their own platforms, which implement their own APIs, their own ‘lock-in protocols’ and their own ways of thinking about application development.

Nokia spring to mind with their own proprietary ‘mobile web services plaform’, while BlackBerry’s browser does not support many of the typically used web standards on regular pages, leading to ‘broken Web’ when browsing many web sites through a BlackBerry.

With mobile devices so versatile in nature, a day of a ‘standard mobile device’ looks virtually impossible to achieve, which may mean that generic mobile web solutions will always be impossible to develop.

The breakdown

As Tim Berners-Lee points out in almost every single one of his presentations, interoperability is the ultimate goal of the Internet and that interoperability is achieved through wide, commonly adopted, open and non-proprietary standards.

Since corporations aim to monopolise, Tim’s vision becomes the enemy of the corporate strategy and the web becomes broken.

Big corporations will therefore kill the web over time, since they will always be happier with monopolising one piece of the global pie, rather than playing an ‘open game’ in an interoperable, standards enabled, free-for-all, mega information playground, which has absolutely wonderful potential.

Posted in Business, Visionary | No Comments »

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

Posted in Advanced, Social web | 4 Comments »

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.

Tags: , ,
Posted in Social web, Visionary | 7 Comments »

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

Posted in Advanced, Development | 3 Comments »

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.

Posted in Beginner, Development, Visionary | 2 Comments »

« Older Entries
Newer Entries »