Archive for February, 2010

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

Mobile interfaces – the main considerations

Friday, February 5th, 2010

Aspects of good mobile solutions

Good mobile solutions of today are preferably developed for optimal user experience on user’s target devices.

Before we do anything with our mobile solution we should be able to server-side detect the mobile device in use and redirect the user to relevant mobile solution for that device.

Mobile solutions are much different from desktop solutions, so providing the same web site on mobile as on desktop will usually result in deteriorated user experience for mobile users.

This is one of the reasons why most big web sites now provide mobile specific solutions for mobile users (e.g. FaceBook, Google, BBC, etc.).

Small page weight

Mobile connections are still relatively slow and it takes a fairly long time to load up even a relatively small web page weighing in at 26KB on a typical mobile connection.

This is one of the main reasons why I would discourage use of JQuery and heavy CSS web pages on mobile platforms.

Aiming to achieve as small a page weight as possible on a mobile interface is a must.

It  enables mobile users to download pages within 1-4 seconds, rather than half a minute, which is usually the case when loading desktop web sites on a typical BlackBerry today for example.

One column layout

Mobile interfaces are small and best suited for a one column layout, which can fit nicely across most mobile devices.

It’s worth considering how the one column layout will stretch across a mobile interface so experimenting with percentage based widths might be a good idea.

However, there is an issue around how compatible this may be across different mobile devices with varied CSS support.

Simple navigation

Within one column layout there is little or no room for navigation, so keep the number of navigation links well below 7 and make them available on top and bottom of all your mobile pages.

This is done to increase usability and offer quick access points to various pages from any page within the mobile application.

Screen and font sizes

Due to having much smaller screens, mobile devices are more difficult to read from.

This means that it’s a good idea to increase the default font size for increased readability.

I have found it to be the case that font size of 18 pixels is not too large for my BlackBerry device and makes text on screen much easier to read.

Font size is also important in context of selecting links as having  larger area for clicking onto improves usability significantly.

Form layouts

The main observation regarding forms on mobile devices is that the label for the given field is probably better off being placed above the form field, rather than to the left of it (which is traditional for desktop applications).

This approach allows creation of reasonably large enough form input and text area fields for viewing the input while keying it in.

The downside is that for even slightly longer forms, the user will have to scroll down to the submit button on the given form page.

JavaScript support (iPhone vs. BlackBerry)

This is arguably the most interesting aspect of mobile application development at the moment.

JavaScript support on BlackBerry devices for example is erratic, even when using JQuery.

If we take iPhone and BlackBerry Bold as examples of advanced mobile devices, their interaction methods are rather different.

iPhone is a touch based devices which supports dragging and dropping, while on a ‘nipple’ based BlackBerry this is impossible.

This means that many JavaScript interactions will need to possibly be thought about in at least two different ways or not implemented at all.

The easiest development approach is probably to implement a solid solution based on Web 1.0 approach to web development (i.e. no JavaScript or minimal JavaScript use).

Native apps vs. internet solution

Modern mobile devices also support the concept of on-board applications which are native to the device and require to be developed using a specific SDK for that device.

Apart from learning overhead, native applications also need to go through approval process to be made available to end users on the mass market.

This process is usually slow and rigorous, which does not fit the work flow of modern, agile development.

Native applications offer better interaction integration, which is the main point I can see as an advantage.

Developing solutions which are internet based means mobile software developers can roll out updates many times per day seamlessly, still support majority of the functionality and reach the market much quicker than through some form of an app store.

Layout (CSS and HTML)

It is the case that BlackBerry Bold web browser supports web standards to much lesser extent than iPhone browser for example.

This means that often a time even the most common visual user interface development techniques fail miserably on BlackBerry.

As an example, CSS sprites do not work at all on BlackBerry as the background images all show at ones in every example I have seen so far.

This means that the use of CSS and HTML for mobile device development needs to be kept very simple.

Using only core CSS and HTML features will ensure that the solution works fine across many devices without major hacking for each device.

This approach, however, does sometimes feel like we are developing for Internet Explorer 5 on Windows 98 even in year 2010, but it reminds us that good coding practices are always a good idea.

References

Phil Archer‘s talk at London Web Standards

Mobile Web Best Practices

Detecting Mobile Browsers with PHP