Archive for the ‘Advanced’ Category

8 reasons not to build your own CMS

Thursday, February 18th, 2010

As you work within software engineering environment, you will realise that a single software solution solving all business problems simply does not exist.

A typical Content Management System (CMS) tries to do exactly that and that’s why every single CMS sooner or later fails to deliver.

Here are some practical reasons why you should not attempt to develop your own CMS.

It won’t meet users’ needs

Chances are that the CMS you build will not work for the businesses you target, as you are unlikely to have a wide enough view upon the industry’s needs, unless you are very experienced.

Because of this reason you will find yourself all the time having to extend your solution to accommodate the needs of the new clients you find.

This defeats the purpose of owning an off-the-shelf solution which would automatically work for your next client and simply require an appropriate theme to make it look and feel right.

It’s too much work

The idea of having a pre-built CMS arose from the notion that it’s less work to be customising an existing solution, rather than building from scratch every time a customer needs a CMS.

In reality however, to build even a semi-appropriate CMS requires:

  • a substantial development effort
  • much thinking from User Experience point of view
  • significant amount of testing
  • catering for many different types of user flows and scenarios
  • dealing with all types of content publishing online
  • considerations about deployment and support
  • security concerns

It won’t be a standard solution

On top of the above difficulties, you are also going to come across various complications on how to make any working solution you come up with conform to various standards and guidelines such as the ones from W3C.

This is likely to be a fairly complicated matter to achieve and will require in-depth knowledge of all those standards.

Furthermore, your solution ought to be future proof in this respect and easy to change so that it can be made to be conforming with future emerging standards, such as HTML5.

It won’t be extendible fast enough

If you are building your own solution, it is unlikely to be easy to extend fast enough to satisfying your client’s requirements, even if it is using a plug-in architecture.

The reasons for this will be because you are unlikely to have enough resources available to develop, deploy, test and make components reusable for future needs.

You are also likely to be working on specific scenarios, rather than addressing a more generic problem, so your extensions are likely not to be easily reusable from client to client.

It won’t be tested well enough

A CMS which has been in use for 5 years is likely to have gone through very rigorous user scrutinisation and feedback by now.

Your new CMS will be fresh of  the boil, featuring many bugs which are hard to test, unearth, replicate and fix.

All these bugs will need to be fixed if your product is to see long term success.

This means more time spent on:

  • developing
  • regression testing
  • re-deploying
  • issuing out bug fixes and updates
  • dealing with feedback and bug reports
  • having unhappy customers who are slowly losing faith in your product

Do you really need to be spending time on this, or is your time better invested working with a well tested solution which you might be extending for a particular purpose?

It won’t be easily changeable

This is the main point that made me want to write this article, as I want to change my own CMS, but now have to come up with my own future proofing solution for it.

The main reason is the fact that some of the well ranked URLs on my site might have to change under the new solution.

This is a really bad idea from SEO point of view as the site is likely to lose out on some interesting Google ranking.

The only solution is to spend more time writing .htaccess rules to ensure that the old URLs are redirecting to new URLs in the most appropriate manner and making sure that Google does not see the two URLs as duplicated content.

It won’t add any value

Probably one of the most important points to make is that the work you might want to do on building your own CMS is likely to be a simple replication of already well developed functionality, existing for free out there on the web, and meeting all the above requirements.

So the main question to ask yourself is: ‘Why am I really trying to re-solve a problem that has already been solved before?’

If you can really find a good enough reason for this and think that you have the resources to do it better, then go-ahead and develop your own CMS.

Chances are that the invested effort will not produce anything significantly better than an already existing solution on the market.

Create content, not functionality

For most part you are better off using your valuable time creating valuable content, rather than invaluable functionality.

Using an existing platform, which is altered to suit a particular need is a much easier and saner approach than building something from scratch.

If you can populate an existing CMS with good content, it will be much better than building a new CMS with poor content inside it, as the time is likely to be dedicated to building the functionality, rather than writing the content.

Conclusion

If you are thinking of embarking on the road of custom building a software of any kind, you are best off thinking of a fairly simple, specific solution for a particular problem.

Building a functional CMS is actually one of the most complicated tasks in the arena of online tools, and by no means a good place to start from.

You are also going to be in direct competition with million and one other CMS solutions, including many excellent ones such as Word Press, all the time.

The real question is: ‘Is it worth it and how does your solution differ from already existing, well-tested and fully functioning CMSs on the market?’

Aspects of great web sites

Friday, July 10th, 2009

Web developers and web product designers should continuously be considering all of the following aspects of web sites and web applications at every stage of their work if they are aiming to produce high quality web presences.

Semantic

Be as meaningful as possible, utilising and leveraging all relevant aspects of semantic web as outlined in this resource and many others.

Standards compliant

Comply with the relevant W3C standards in order to meet the internationally recognised best coding practices, which work well across many different browsers.

Accessibility

Your solution will need to work on devices with minimal technological support, including screen readers and mobile devices.

If your main solution does not work with these devices, you should provide alternative solutions which do.

Aesthetic

Good looking and easy to use from the aesthetic point of view.

Well designed and well laid out for optimal visual impact and influence.

Functional

The solution should fulfill a particular purpose or functional for which it has been created.

There is nothing worse in the world than an unnecessary web site or something that duplicates already existing provision.

User centric

Every solution should be built based on well identified user needs and requirements.

Since users are those who ultimately use the web, their needs and wants need to be addressed with the solution.

Take all aspects of User Centered Design into account when trying to achieve this aspect.

Relevant to business

Businesses have their own, often opposing, processes compared to users’ needs.

These need to be addressed as well as users’ requirements, since without them, business processes will not be fulfilled and catered for properly.

Getting the right balance between user experience and business needs is often one of the sticking points when developing any web presence.

Maintainable

If the created solution is not maintainable, it will not be able to keep up with the inevitable on-going changes which happen in the world of Internet all the time.

MySpace.com is a great example of how a non-maintainable solution, which initially was a relative success, turned into the ultimate unmaintainable mess, which is now heading towards a total failure.

Maintenance is the aspect of Internet solutions which also tends to waste the highest amount of resources and this is the case with maintenance of any product of any type.

Inter-compatible

Increasingly it is becoming a common requirement that any web site or web application needs to work seamlessly in context of another web site or application.

This can on some level be achieved through use of RSS feeds, but on some deeper levels it can be achieved through APIs and to greater or lesser extent with proper, semantic code.

Future proof

A solution which only works for the given time it is written in is no good.

Good Internet resources ought to reside on-line forever and be easily accessible and usable non-stop.

If a solution needs a major re-work every time an upgrade is required, it is not considered to be future proof.

In front end coding terms, proper standards compliant, semantic user interfaces usually ensure that  the end solution will be future proof.

Usability

A solution can be accessible, but not necessarily usable.

In terms of usability, a solution can be barely usable or highly usable.

One needs to ensure that a web site or a web application can be used with a mouse, on a mobile device, using a keyboard only, when the interface size is increased by the user and so on.

Search Engine Optimised

Once again, following best practices for user interface development, should ensure high level of Search Engine Optimisation (SEO).

However, SEO is an aspect which ought to be addressed as a stand-alone issue too, as it is somewhat a subject to high levels of competition in many industries, so semantic coding will usually not be enough to achieve high SEO impact.

One of the subtle aspects of SEO which are related to this resource is the matter of URL structures, which can somewhat make or break an SEO strategy.

Relevant and useful content

Writing for web is somewhat of an art form.

Users do not read on-line.

They skim the text and randomly read in and out at certain points on the page.

Having a good quality content on each page can be a make or break of any web site or a web application.

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

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

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.

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