Archive for the ‘Visionary’ Category

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.

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.

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.

Emerging semantic web structure

Friday, June 27th, 2008

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.

Semantic Data Component Structure

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.