Assessing the quality of a website

This blog is a starting guide, for business people, to help them get an understanding of whether their website is designed correctly.  It is not exhaustive but hopefully one in a series on this topic.

Note that this blog is my personal view, as are all my blogs, however they are based on nearly two decades of experience in the IT industry.

Although nearly every client I deal with has a need for a website it is interesting to observe that many of them do not have an understanding of whether their website is fundamentally “good”.

The problem is that most people are not familiar with what makes a website “good” or “bad”.  Some even believe that as long as it ticks all the boxes for what they wanted in a website then its a good website.  Some go by the wisdom of the HIPPO’s. (Highest Paid Person in the room’s Opinion) If they say it should have a purple background with yellow text then that’s the right way to build the website.  This is why we see a lot of websites talking about the technical details of a product which are hard to read and totally useless to consumers who simply are trying to find a solution to a problem or idea quickly and efficiently.

A great example was a salary packaging website I once reviewed that worked this way (NOT one of my current clients). The site was designed as what we call a “brochure-ware” website. Strictly useless to everyone unless you want a brochure or need to look up the company address and don’t use the yellow pages.  After studying each page of their site I gave up and could not find the answer to my basic question “What is this salary packaging thing you are selling and why on earth would I want one!”  It seemed impossible that they would miss the point that consumers hitting their site are looking for information not text descriptions of their product brochures.  The idea of explaining what salary packaging was and how it benefited a person had not occurred to them as being required for the website and when you stand in their shoes you can see its very easy to miss this point.  They thought all they had to do is put up technical details of their company and its salary packaging capabilities and their website would be fantastic.  After all the competitors are doing this right?. Worst of all the company that built their site did not see the mistake in thinking either because they themselves did not understand what drives traffic to a website and what constitutes a successful interaction with the website for a customer or because they didn’t feel it was their responsibility.  In this case the website (which was brand new) it had to be thrown out and a redesign of the site was necessary focusing on the consumers needs rather than the companies products.  The IT vendor was changed however I’m sure the previous vendor is still doing a great deal of work for other clients making the same mistakes.

This example highlights only one aspect of poor website design and that is a poor user experience.

Assessing a website for quality is similar in principle to say assessing a property for rental income.   You don’t ever look at it with your own views of what a home should be.  You look at it with a purely business mindset, thinking about what a renter would be looking for.  Key concerns then come out of this such as location, price, practicality of home design, etc etc.

The same is true of website design however as you would suspect its a lot more complex than real estate, which is why so few people actually ever really get their head around the problem.

Key challenges to a good website design:

1. The website must provide a user experience that meets the primary audiences.  This also implies the audience is well understood.

2. The website must pass certain technical requirements in order for it to function correctly under all conditions.

3. The website must be deployed in a manner that provides it with capability of handling the target audience in a timely manner.  That is it must be scaled correctly to the demand, handle peak loads well and be reliable.

4. The website must consider maintanance long term because approximately 80% of a systems cost is normally in maintenance.

5. The website must be SEO optimised without using black hat techniques and be marketed well

This is not an exhaustive list but covers some key criteria.  Just with real estate there are levels of depth here and expertise required to achieve deeper knowledge.

The first item, user experience, is the most complex.  There are guidelines and best practises for user experience (the term UX has recently started being used for this, but the term information architecture also applies here) I’ve encountered even experienced business people that have sent me textual site maps (which is a structured collection of website page names) and thought this was a full information architecture and covers their user experience therefore was enough to hand to a developer to build.  This is so not the definition of Information Architecture.  A user experience is about how the user engages with the site.  Its not only about the right information, it is about their experience from entering the site to exiting the site.   Are their mental concepts aligned with yours?, how many clicks until they reach what they needed?.  Its a very involved and complex topic and a topic for a dedicated series of blog articles. A lot of thought normally goes into the user experience prior to the site ever being built.

The next section item, technical requirements, is what I will focus on next.  Technical requirements are about how website is built. It may seem amazing to an non-IT person to think that a website can go live with technical faults, but its quite common particularly given the amount of “code borrowing” that occurs thanks to the wonderful double edged sword called “open source”.

These typical design faults include the following:

1. Incorrect use of web technology such as HTML, Javascript, CSS.  Serious programming errors can be placed into a website and get through a cursory review of the site.   I will demonstrate ways to confirm some of these key issues.

2. Non compliance with legal standards. This one is very common.   Generally known as accessibility rules, it deals with 20% of the population that have difficulty with websites due to various types of disabilities.   Breaches here are both legal matters as well as having serious consequences to the 20% of people that need your website to be compliant to the accessibly standards.

Validating your website

Although not all technical faults can be determined automatically a great deal of them can be.  When you can verify design faults automatically it means your website designer probably should start signing up for some IT training. Well if everyone like you were armed with this knowledge they would have to ensure their skills were more comprehensive.

HTML Validation Service – Checking the structure of your website

The link below is to the W3C validation service. This is a free tool that allows you to pass in a URL to a website page and it automatically checks a page for HTML specific errors and warnings.   By the way HTML is the core technology used to build websites.

In simple terms this tool looks for mistakes that could and will cause your website to function incorrectly on certain browsers and which may result in your site not working at all for certain users.   Be warned though that fixing the site to completely pass all the tests run by this tool is not a silver bullet solution.  A site can pass all these tests and still be poorly designed, however if it passes these tests you have a reasonable chance that your website was developed by someone with reasonably good knowledge. If this is the case there will be a great deal less issues with browser compatibility.

If your site has more than a couple failures detected with this tool it might be time to get another web development firm involved or consult with an Architect, depending on the error and the reason the error was not address.  Often the errors are there because the developer isn’t experienced enough with HTML and the standards that needs to be followed and in this case your potentially dealing with the wrong people.  Sometimes its because they used a tool such as a open source (free) CMS or a framework to build the site, however again its not an excuse if a developer picks an inappropriate CMS platform or framework for business use as how the CMS generates pages is critical to your sites quality.  I often hear the line “the CMS has the problem and we cannot change this” however if you engage an architect or a solution designer you should be able to come up with a better architectural design to solve those issues.  Remember open source is a double edged sword, pick the wrong open source technology and you’ll be in a world of pain, pick the right one and you’ll save money and have a great solution, however you need someone with “experience” across the technology spectrum to work out the best options and how to apply the technologies together correctly.

Below is an image showing how the validator works.  Remember this is for one page only, each page of the site needs to be checked.  The information below is produced from publicly available data on an unnamed website.

HTML Validator
HTML Validator

CSS Validation – Checking the styles used on your website

CSS is the next most important technology used on the web.  CSS is short for Cascading Style Sheets and is a way of specifying style information for a website.  i.e. CSS can be used to specify consistent use of fonts, colours, padding and so on for your website.  If no CSS specification exists your website is either very very old or not designed by a web developer.  The use of CSS is controlled by standards which need to be followed in order for the website to function correctly on each browser.  This is extremely important as invalid CSS has amplified negative effects on on the user experience because it controls style.

Here is a link to a CSS validator.  This is also a free service.  Beware that if your website is not publically available this tool will not be able to access it and you may need to upload the website page directly which is more complex.

Again we are looking for zero or a couple errors or warnings.  There might be a reason or two for some errors but generally aim for no errors.

Below is an example of the CSS validator in action.  This is an unidentified Australia site as before using only publicly available data, no private or confidential data is used.

CSS Validator
CSS Validator


Ok, now the most important topic.  Accessibility is a term used to describe how broad an audience can access your website.  The assessibility guidelines for Australian can be found here:

The most important standard here is called the Web Content Accessibility Guidelines (WCAG) with version 2.0 being the current specification.

There are some automatic checkers for accessibility however they aren’t great and its possible to read the standard and get a feel for what you site needs to achieve to meet the requirements.

This includes two primary types of problem areas for the web. They are as follows:

1) Low powered or restricted computing users.

Examples include government workers who’s IT departments have locked down their work computers or families with old computers that cannot afford to upgrade to the latest technology.   Government users are a huge portion of the browsing audience so don’t underestimate this one.

2) Disabled people and even less-able people such as the elderly.

Not just physically but those that are partially impaired such as having learning difficulties.  About 20% of the population is technically classified as disabled so if your thinking… I can live without addressing the disabled community then please think again.  Apart from the moral implications of ignoring this audience the size of that community is something no business can afford to ignore. There are also legal issues that you must consider if you are building a website for Australians.  Under Australian law and under certain conditions it is illegal to create a situation where disabled people cannot get to information that able people are able to get to.  If you do this, you may find yourself in court being challenged for discrimination.   A great example was the Sydney Olympics.   Please see this information below.   The court found that the organising committee had created a website that was discriminatory and were ordered to take action to rectify it.

Many Australian websites don’t comply with these standards leaving them open to potential legal action.  Its quite a unfortunately situation but reflective unfortunately on how little some web development firms are aware of these laws and end up putting their clients in a legally ambiguous if not outright discriminatory position by simple lack of knowledge.

Keep in mind also that even if you don’t care about the 20%, and you are willing to risk the court challenge, you have one other thing to think about.  What if your competitor is fully compliant and realise you are not.  Could your competitors sink your business by organising someone to take you to court and making it public knowledge that they are not discriminatory and you are.   Could this be enough to break the back of your company?   Think about it.

Meeting accessibility requirements comes in three levels of committment.  Namely A compliant, AA compliant and strangely AAA compliant!

Level A is fairly easy to achieve.  It consists of using appropriate tags and is mostly about technical concerns.   Level AA is more difficult to achieve but still not rocket science.  Expect to add between 5% to 30% to the cost of your website build in order to meet these levels of compliance.

Now level AAA is much more difficult to achieve but it is possible.   I have recently designed a government site to reach this level and it was quite challenging.  I believe mainly government organisations and people specifically targeting the disabled with go for this level.

Level AA really should be the target for everyone else.  I’ve been told that by next year (2012) all government departments should be using this as the default standard in Australia because of not only the cost but also the drawbacks of designing a site to AAA.

Now checking for accessibility is more difficult, but it includes simple things like the concepts discussed below.

From a human limitations viewpoint

Here is a brief list of topic areas that the accessibility guidelines discuss:
  • All images must have alternative text tags.  This is particularly important for images used as buttons.
  • All non-text sources should be reproduced in text somehow (for screen readers).  If your site is all videos then you might have a lot of issues here to ensure the content is accessible in alternative ways.
  • How problematic CAPTCHA solutions need to be used on a site.
  • Ensuring CSS files are written according to proper guidelines. (margins, padding, etc)
  • Considerations around colour contrasts and flashing images.
  • Issues with tabular data and similarly the need to avoid structural markup to represent content relationships.
  • Need for a site to be navigated via keyboard not just the mouse. (this is also a technology issue)
  • Need to be careful of time limits on pages where the user is expected to act in a certain time frame.
  • The dynamic nature of the site can be an issue.  This is a changing problem because the standards were written a while back and screen reader technology is improving.  PDF documents were originally marked as inappropriate for accessibility but now days things are different.  It also use to be that anything using AJAX or JavaScript was out for accessibility but its not so clear cut as technologies improve.  Its possible to use AJAX / JavaScript without confusing all of the screen readers if your careful. You can perhaps see now why an automatic checking capability of the standards is tricky to get right.

My advise right at this minute is to read the guidelines and become familar with the WCAG 2.0 standard.  If there is interest I may write a blog outlining this standard in simplified terms.  Although it not a big document and will give you a feel for the kind of things that need to be checked.  Remember also that the more technically valid the site is the easier it will be to ensure its also meeting accessibility guidelines.

From a technical viewpoint

From the point of view of accessing the site from government sites or low powered computing it is all about technical correctness of the site and being aware of limitations of past technologies that you need to consider as well as imposed limitations.  A site that runs nothing but Flash code is not going to work in a great deal of places, but similarly a site that runs the latest HTML5 is going to be useless to a government department running IE 5.0 or IE 6.0.  These browsers were built before the standard was even dreamt up and yes some of these old browsers are still around and being used in large numbers and for real reasons.

My thinking here is always “find the best compromise that meets your target audience”.   I’m not a fan of technologies like Flash anyway, so I’d always recommend something based on core web standards.  Where you want to do something with a more advanced technology try to provide alternative pages to give as much information to the audience that cannot access the more advanced interface.

The challenge for mobile devices

Although worthy of a complete article in itself poor website design has a very large impact on users of mobile devices.

There are two key issues:

  • Firstly many website owners actually believe that either no one will access their website via mobile or if its accessed it won’t be a problem as mobile isn’t much different.  This point of view is not accurate.  In the case of very simple websites it may be possible for them to display reasonably ok on a mobile however most of the time this is not the case.  A mobile web browser is a very different target than a desktop web browser as we will see.
  • The other thing is most mobile users are now expecting mobile applications (those that you get from the App Store or from the Android Market Place) for any websites they take seriously. Australia is one of the fastest adaptors in the world of mobile app technology.  It also has a massive slice of the market and its only been a short time that the killer mobile platforms, iPhone and android have been around.  The growth rate of this market is incredible and MUST be considered by anyone who expected repeat business from an online client base.  Mobile apps also have to be treated with respect as there is a great trust relationship in place and it is a two-way market place where user feedback impacts your place in the market very directly.

So what are the issue to consider here?

Ok, firstly why doesn’t a website work automatically on a mobile?

Here are a handful of reasons to get you thinking:

1) CSS not tailored to mobile including default desktop resolution being far too big for mobile and visual workable area being so much more restrictive for mobile

Very few mobiles have a resolution of 1024 x 768 yet most websites are tested at this resolution and sometimes even higher depending on the mindset of the web developer.  Simply put if you design a website for a minimum resolution it will be unsuable on a lower resolution. Navigational elements will drop off the screen, input areas won’t be usable, even menus won’t navigate.  CSS can be tailored to control this better but its involved work and typically not done by many web developers unless you specifically request it plus because the mobile device is some much different (so much smaller) most sites cannot be “forced” to work correctly at both the higher resolution formats and mobile formats (you to consider the user experience of the mobile separately to ordinary web users).   There are some interesting technologies around to help with this but that is a whole new topic.

2) Finger not mouse

Most mobile devices are now operated by a finger motion, not a mouse motion.  Fine menu systems don’t consider this.  The majority of menu systems are based on CSS or simple Javascript and simply cannot be operated effectively on a mobile.   This needs to be designed up front.   The use user is forced to keep zooming in and out to move through menus assuming their mobile device even supports touch input of course.

3) Page weights to heavy

Many people miss this one.  A page weight is the sum of all the elements that are downloaded when you “hit” a web page.  It is amazing how different this weight can be between websites.  Under the covers the developer can chose to make a website highly efficient and download light weight images, minimal and compressed code logic, or they can be skim over the problem and do the opposite.  I’ve seen home pages with page weights of 5 megabytes or more for a single page, on a good ADSL2 connection you many not realise how much data is being passed back to your browser.  On a 3G connection its not only noticeable it will likely force you to give up and try another website.

4) Sensitive response times

AJAX logic and other elements are usually very time sensitive, plus may developers accidentally create time sensitive issues when they use javascript or even incorrectly use CSS (particularly sizing of sections on a page) On a mobile this can break the website or make it look terrible.  (The current JB Hifi website on a mobile web browser is “currently” a good example of a CSS design causing timing issues with their bottom navigational control)

There are dozens of other considerations but these will give you an indication of the effort that needs to be considered.

Basically if you design a website you should also design it to handle mobile.  Often it is easier to build a seperate website for mobile, however with enough care a reasonable job is sometimes achieved by using a specific CSS for mobile and some technical magic.   In short if your web developer says its designed for mobile and didn’t do a great deal of work specifically testing it for mobile they are probably not telling you the whole story.  If you engage an architect they will likely put together an architecture to “control” this problem to simplify the work web developers have to do.

Now, part of the reason mobile applications are becoming so popular is they get around the issues with mobile web (web browsers on a mobile)  A mobile application running directly on the device can be fast (if designed correctly) and can leverage the functionality of your device such as camera (scanning), microphone (voice commands) and GPS capabilities in particular.

Business to business use of mobile technology

I was asked recently whether it was possible to simply create a webpage and host it on a mobile device such as an iOS based iPad using a link.   This is one of those questions that seems like a good idea but can be used as another great example on why you should avoid taking short cuts.

Firstly, again the iPad’s navigational control is finger based not mouse and its resolution, although higher resolution than most mobile devices is still lower than a standard desktop screen.  The website therefore must be optimised to the iPad’s screen dimensions and also designed for navigation on the iPad (finger control without the fine mouse movements that are used to control a website navigation).

Next, for B2B systems there is always authentication and stateful information. i.e. users accounts are normal.  The iPad’s web browser, even in the new iOS 5.0 is a horrendous little beast and little if no thought has been put into it compared to modern web browsers like chrome or firefox.   The most fundamental issue here can be seen by using a the Google app for iOS (NOT the newly released gmail app).   When you use this older app to launch gmail, you will be prompted for your user name and password.  It doesn’t remember it from your last session if you close the session.  This is because the app is basically a fancy “link” to a webpage.  (Android users may not understand this because the solution for android is native to the operating system and very powerful against the iOS capability, of course given android is Google’s brainchild) Anyway this basically means using the device to manage the state of the application is taken away from you.  It is a dumb public web browser.

Also, although it may not be obvious, the web site won’t have access to the devices capabilities, no gps, no camera access and no directing the device to do anything that the built in browser cannot do.  This limits what the website can do significantly.

Also if you wish to store B2B security data or cached documents on the iPad then this cannot do it using the browser. Wish to leverage the higher quality viewing and graphical capability of this device from the browser.. also cannot do it.  Want to scan a barcode to display information on a product… you guessed it.. you cannot do it from the browser.

Basically a mobile app is how you build an application that leverages that devices capabilities and looks slick. (again if designed right)  Of course for B2B applications there is a slightly different process with the market place (particularly for apple) for deployment but otherwise conceptually its the same.

In Conclusion

That concludes this introduction to web site quality.  There are a lot of topics to cover and I’ve only focused on a small area, but that leaves more for future blogs.

In summary:

Be aware that there are both measurable ways to determine website quality as well as best practices that are harder to guage.  There are evolving tools to help which I will refer to in a later post.

Mobile must be dealt with independently and mobile applications (if built properly) are a worthwhile investment for many organisations

There are tools that can be used to gauge whether you have the right people working on your website or whether you need to organise training or get in consultants.  Use those tools if you are concerned about your web presence.  If there is interest I will expand on further tools and techniques later.