Design

There are 3 posts filed in Design (this is page 1 of 1).

how not to develop websites

It amazes me time and time again how certain websites are designed/administered. In particular, government websites. Let it be known my rant starts here.

Laughing in the face of the credit crunch I recently booked a trip to Australia. As it turned out, it was almost as cheap to go via the US with a stopover in San Francisco, which I duly accepted. However, as I was now staying in the US for a day or two, I had to apply for a ESTA – this has to been done at least 72 hours before travel. Fair enough.

So off I trotted to Google and searched for “ESTA”. The searched showed that the most likely place to complete my ESTA was at the link https://esta.cbp.dhs.gov/esta. However, clicking on the link returned the page shown in the screenshot below. Hence, I thought the site must be down, and that I’d come back later. I then tried later that day and it still wasn’t working so I ended up leaving it for a while (by a while I mean a month or so).

ESTA website error screenshot

ESTA website error screenshot

Then last night I thought I’d better try again, but nothing, the same page. It was late, so I thought I would leave it again until the morning. However, the morning greeted me with the same error page once again. With my suspicions now raised and due to the departure date looming over me, I searched on Google to see if anyone else was getting this problem. Nothing, no mention of anything. Strange.

It then dawned on me that it might be the browser. So I loaded up the page in IE7 and bang it worked. I mean how shite is that? They should have at least have given a warning that my browser (Chrome) wasn’t supported. Instead I have wasted time trying to figure out what the hell was wrong.

Maybe I should have tried an alternative browser sooner but I was given no indication that this might be the problem. In my eyes this is a colossal FAIL. In fact, the only reason I decided to check in another browser was that the UK Government was considering a similar stance with browsers it did not believe it should support. The following excerpt is taking from the Boagworld podcast #135:

Apparently, the UK government believes we should test on the basis of popularity. In a draft document advising public sector websites, it suggests that if a browser appears in visitor logs as being below an arbitrary percentage of total “unique visitors”, then it should not be listed as being “fully supported”.

As the guys over at Boagworld stated, this may seem like a sensible move, but in fact it’s not, and I refer you to the comment quoted by Jon Hicks.

It isn’t clear how the supported browser list would be enforced, but I’m concerned that this approach will encourage browser sniffing, a move that will exclude browsers like Omniweb,Shiira and iCab, simply because their name isn’t ‘Safari’. They share the exact same rendering engine, and therefore require no further testing. You can be more inclusive without spending any extra resources.

So this brings us round to the issue of graceful degradation and progressive enhancement ([1][2]), as championed by Yahoo.  For those who don’t fancy following the links here are the definitions of each concept:
 

Graceful degradation: Providing an alternative version of your functionality or making the user aware of shortcomings of a product as a safety measure to ensure that the product is usable.

Progressive enhancement: Starting with a baseline of usable functionality, then increasing the richness of the user experience step by step by testing for support for enhancements before applying them.

Surely following either one of these approaches is the way forward?  Developing a website in this way will also improve the site in term of accessibility – the sooner someone gets prosecuted here under the disability discrimination act for this stuff the better. However, this methodology seems totally lost to the US government (and the UK government for that matter). Instead others will wonder why the hell they can’t get on the site from their “obscure” browsers. Hopefully this post may help them. Or maybe the US government will do the sensible thing and tell us why we can’t view the page, I won’t hold my breath though.

[1] http://dev.opera.com/articles/view/graceful-degradation-progressive-enhancement/

[2] http://accessites.org/site/2007/02/graceful-degradation-progressive-enhancement/

The S in SOLID

Right, I’m back onto the SOLID principles again, I apologise to those who are bored of this.

So the other day I was listening to the most recent Scott Hansleman podcast with Uncle Bob Martin where the conversation was about the recent handbag fight between Bob Martin and Joel Spolsky – as I discussed in a previous blog post. In this podcast Bob Martin talks about an issue Joel Spolsky raised with him on the StackOverflow podcast #41.  An extract from the discussion from the StackOverflow (SO) podcast #41 is given below:

Spolsky: Bob, can you explain again the Single Responsibility principle? Because I don’t think I understand it right.

Martin: The Single Responsibility principle is actually a very old principle, I think it was coined by Bertrand Meyer a long time ago. The basic idea is simple, if you have a module or a function or anything it should have one reason to change. And by that I mean that if there is some other source of change… if there are sources of change out there one source of change should impact it. So a simple example, we have an employee, this is the one I use all the time…

Spolsky: Wait, wait, hold on, let me stop you for a second. Change, you mean like at run-time?

Martin: No. At development time.

Spolsky: You mean changes of code. There should be one source of entropy in the world which causes you to have to change the source code for that thing.

Martin: Yeah. That’s the idea. Do you ever achieve that? No. 

Martin: You try to get your modules so that if a feature changes a module might change but no other feature change will affect that module. You try and get your modules so partitioned that when a change occurs in the requirements the minimum possible number of modules are affected. So the example I always use is the employee class. Should an employee know how to write itself to the database, how to calculate it’s pay and how to write an employee report. And, if you had all of that functionality inside an employee class then when the accountants change the business rules for calculating pay you’d have to change the employee, you’d have to modify the code in the employee. If the bean counters change the format of the report you’d have to go in and change this class, or if the DBAs changed the schema you’d have to go in and change this class. I call classes like this dependency magnets, they change for too many reasons.

Spolsky: Is that… how is that bad?

I kind of feel the same as Joel with this one and I’m afraid that Bob is not really convincing me here. Why? Let’s pursue an example for a second.

Suppose that I’m creating a class that outputs a file. In this class I extract data from a database, convert various bits of the data, then output this data to a file. So how many reasons has my class got to change? Well it looks like 3: the database can change, how I convert the data can change, and how the file is output can change. Hence according to the S in SOLID, each of these operations should be contained in a separate class. Let’s just remind ourselves what the S in SOLID stands for:

A class should have one, and only one, reason to change. [1]

Now if I am forced into making changes to either the database, data conversion, and file format, I make the changes to my class. What is wrong with that? I just compile the project again and distribute the binary. Simple. I can’t see any benefit in breaking this class up into 4 separate classes, there just seems no point, but according to the SOLID principles there is. Arguments from Bob like “Yeah. That’s the idea. Do you ever achieve that? No” are nonsense. It clearly undermines the need for such rules in the first place. There is no point having rules if you are not going to stick to them. Fudging a rule every time it doesn’t fit your argument implies that the rule doesn’t make sense in general.

The discussion in SO #41 then moves on to the WordPress plugin system where Bob comments on how having independent plugins are a great example of the single point of responsibility (I must stress it was not Bob’s example, he just went with it). Eh NO. I think that it sometimes becomes easy to forget what the S means. Let me just state it again: A CLASS should have one, and only one, reason to change. The plugin itself, which is represented by a class, may have lots of reasons to change. Again in the subsequent Hansel Minutes podcast Bob uses the term module, in the sense of say a jar file in Java or a dll in .NET, to describe building a set of components that adhere to the S in the SOLID principles. This is once again deviating away from the actual meaning of S.

OK, am I being pedantic about the definition? I don’t think so. If it doesn’t mean what it says, then change it; there are people out there that will follow these rules blindly, and having such a specific definition only encourages this.

I think a far better rule would state that a class should only be responsible for a single task, in my example that task is creating the file. This is completely different from a class that has only one reason to change. OK, it’s a lot less specific, and maybe harder to judge, but any decent programmer will have a feel for what a task is. Not only does this seem like a more sensible option, it’s what the plugin and the module argument ostensibly encourage. It seems to me this is the only true generalisation you can extract from Bob’s arguments and I think it would be much better if this is what the rule suggested.

Don’t get me wrong, there are times when you want a class to only have one reason to change, this is especially true when you are developing a framework where the source code is essentially immutable to the outside world, in this case class design becomes far far more important. However the SOLID principles are intended as a set of rules for every programmer to use, and as it stands, I’m sure that the S is causing more confusion, code bloat, and misguidance than it is providing benefit to those adhering to these rules.

Having rules are a great idea, but they also encourage people to follow them word-for-word. It’s easy to say they should not be followed religiously, but I’m sure that is what is expected. This coupled with the developer with poor judgement, little experience and lots of blind faith, can leave us all wondering why we are even entertaining all this.

References

[1] http://butunclebob.com/ArticleS.UncleBob.PrinciplesOfOod

the importance of thoughtful design in web applications

When I think back to around 5 years ago, it was commonplace to use web apps that looked awful, but provided content and services that we couldn’t find elsewhere. In those days it was seen as less desirable to create a website that relied heavily on graphics, and as a result, a “dressed down” website was almost still cool. However, with the rapid increase in bandwidth available to the average user, and the rise in competition between online services and retailers, there is far more to loose having a website whose design sucks.

Now fast-forward to the present day, and we are using the internet more and more as part of our everyday lives. The reality of this is that we programmers can no longer get away with designs that make you cry! This is especially important when a website sells a product or commodities of some form. There is literally nothing that will send me running away from a site faster than poor design. I would rather pay more from a site that has:

  1.  A sensible domain name – this can be hard to find; just how annoying on a scale of 1-10 are those who squat on domain names?
  2. (Up-to-date) contact information, namely: an address; history of the company; a phone number; names and possibly a short biography of the key people running the website – even if you are working in your own in a garage, put your name and tell me who you are.
  3. A well thought out design – it doesn’t have to be fancy, just look as if it was not designed in a day. Basically I just want to know you ain’t going to steal my money.
  4. Copyright dates that are current – this is a small thing, but attention to detail!
  5. Fresh content – a company blog can help here; ideally you want to avoid the web equivalent of the sun bleached items in a corner shop window.
  6. Good spelling and grammar – I’m no expert on this (as you may have noticed) but getting this correct is very important. Spelling in particular.
  7. Secure account login – you may look cheap if you have not coughed out for an SSL certificate; they ain’t that expensive (although being an SSL certificate distributor seems like a licence to print money if you ask me).
  8. The ability to NOT send me a password reminder – I almost cry when I see a site that offers to send me my password via email, as I then know they are storing my password as text in their database somewhere. I can then only imagine what they will do with my credit card details.
  9. A payment system that I don’t have to navigate away from the site to hand over my money, if I don’t want to – some folk are happy with PayPal, I’m still suspicious!
  10. Easy to access help, specifically on: delivery, customer service, and returns.
  11. No links into your site from pop-up ads on external websites.

Focusing on point 3 above in more detail. I understand an innovative website design can cost you a fair bit of money, as graphic designers are not cheap.  As an alternative to expensive design, at least avoid the following:

  1. Pop-ups – a no brainer.
  2. Free hosting – especially hosting supported by ads of any kind.
  3. Poor font choice.
  4. A template based design that several of your competitors are also using – you need to stand out, not blend in.
  5. Writing company biographies in the third-person narrative – LAME.
  6. An entry page with no purpose – it’s rare these days but you still see it.
  7. Using Flash, but not fixing the back button to work as expected.
  8. Input fields that are not long enough to take a typical string, i.e. a credit card box that you can’t fit all the numbers of your card in without scrolling, WTF, how can you double check your number?
  9. Items that are not aligned on the page, but should be – c’mon this doesn’t take long to fix.

The days of amateur design are numbered for those wishing to make a living online.  As more companies make online services available, and give the consumer a choice, then the less likely anyone is going to trust a site that lacks attention to detail.  In my eyes the design does not have to be innovative, it just has to appear safe and trustworthy – obviously eye catching design brings with it attention, that I’m not denying, but it does wear off.  So what key factors do you look for in the design of a website and what is likely to send you running in the opposite direction?

(Update: I was just listening to the boagworld podcast and it happens to mention something that ties in with this quite nicely. So check out the link to find out ways to make your site feel safe).