Archive for the ‘Architecture’ 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.

Who builds software?

Tuesday, March 31st, 2009

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

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

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

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

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

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

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

Problems in user generated code and content

Here are some examples where semantic web solutions are jeopardized:

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

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

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

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

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

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

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

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

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

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

Web site types

Sunday, March 8th, 2009

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

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

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

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

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

Some examples of web site types are outlined below:

A simple ’5 pager’

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

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

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

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

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

Small CMS and blogs

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

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

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

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

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

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

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

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

Web applications

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

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

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

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

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

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

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

E-commerce

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

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

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

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

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

Social tools

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

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

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

Multimedia sites

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

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

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

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

Expert business tools

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

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

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

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

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

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.