I’m bringing this up from an exceptionally small thing I noticed while at work today. As I have previously stated, I work with SharePoint. Much of the time I am branding it (though not in my current project!) and so I have a rather intimate and abusive relationship with the program. I find myself constantly finding weird styling quirks put into the environment that prove that SharePoint was built by a large group of people.

There are many instances within SharePoint – and I’m sure within WSS as well – where certain styles that should be consistent end up being done completely different ways. I wish I had a screen shot as an example, but you’ll have to use your imagination here. Picture two dropdown buttons. When you hover over them, they glow, and a menu appears. No picture the HTML for both dropdown buttons being completely different, with no shared styles or markup whatsoever.

This happens all over the place. Hell, there is markup all over the place that is either broken, non-standard (don’t get me started on WSS/SharePoint and it’s default markup) and over 6 thousand lines of styles if you add up all the sheets. 6 thousand! There is no need for that, and yet it exists because of – say it with me now – the lack of consistency.This lack of consistency then cascades down to people like me, who are stuck styling the damned things. Had there been a discussion between the differing groups, or the markup left to a third group so that they could all be structured the same way other peoples lives would then be made easier.

Another example I can bring up is with code. My code, my co-workers code, random interweb code, it happens everywhere. It is far more frequent when you work on rapid products, or many projects that build off of their predecessor. I can speak from experience that unless you code with the future in mind you will end up patching things… usually more than once.

In a perfect world you’d be able to properly scope your work out, develop your use cases, figure out your flow, and develop in a modular, expandable way. This of course requires a couple things: Time, patience, and knowledge. I can assure you that even if you think you have all three you don’t. The only time this can ever happen is when you are developing something for yourself and even then more often than not you’re just throwing something together for your own use, and those tend to be the worst for patch jobs… at least from my experience.

In the end all I can say is plan things out. Figure out a system and stick to it; even if it’s not the best it will at least not be the best everywhere. This makes it much easier to upgrade/fix later on. If you come up with 5 different solutions for 5 different things when they could all share common attributes, you are just making more work for yourself.

Save your time, your brain, and your fellow workers from the agony of added work brought about by inconsistency. Get a game plan, stick with it, and for the love of god: be consistent.

P.S. I managed to spell consistency wrong every time in this post while writing it.

P.P.S. Except for the one in the first postscript.

Update:

Success! I have a screen shot of the dropdown menus in question!
(Technically this update happened before the post went public, but whatever)

Most people have no problem with following these rules, though I will say that my address will forever be 123 Fake St. unless something is getting shipped to me. The problem is not in the rules but in their explanation to us.

Sometimes websites are very clear about what they want by specifying it in clear, concise language: “Username must be between 5 and 11 characters and contain at least 1 number” or “Postal Code example: A1B 2C3“. This is a good practice because assuming your users are idiots will ironically result in a much lower screwup rate.

The point I’m getting to here is when you don’t state you’re rules, your users will default to basic behavior. Most people don’t know that usernames tend to have numbers in them now, and I’m sure even less know that because of your half-assed attempt at regex the postal code needs to be in capitals.

What does this mean? Well depending on how you set up the form users may be forced to fill it all out again. This is a pain in the ass to start, and when you throw in the fact that many websites do not include detailed error messages (error summaries people, error summaries) the users may -and in my case will- be forced to fill out the same form multiple times.

This is an example of CUE. Lazy programmers and lazy testing tend to be the main cause of form-based issues. I know this because I was a lazy programmer who submitted his stuff to a very thorough quality assurance person. He turned around and ripped my form apart. I learned quickly that by putting forth the additional effort into planning it all out and doing the job right, that two things would happen: the first thing is that I’d have less work coming back from the QA guys. The second was that I realized I was creating the same thing that annoyed me so often on the web. I’m a reformed man as a result.

What I’m trying to get at is that when you’re building something, no matter what it is, try and look at it from the end-users stand point. This can be a difficult task at time and believe me when I say that it takes some practice. You have to figure how users can screw things up that you find straight-forward and fix said things.

Once you know how they can screw them up, save yourself some time and tell them how not to screw them up. As long as you stop their input from decimating your server (sanitize your inputs, people) you can make your life easier by telling the user how to do things the right way.

That’s not lazy, that’s empowering.

Another step is to make sure that when they do screw up (which they will) make sure you tell them what they actually did wrong. DHTML and AJAX controls depending on your validation requirements, can be fantastic ways to validate on the fly… assuming you don’t make your error messages jarring (i.e. javascript popup messages are bad, don’t do them) or elusive (top of the page? I’m 15 inches down the form, I’m not going to see that) or cryptic “An error occurred.”

Once again, ask yourself what you would expect the user to see when they go through it. Do you really think big JavaScript popups are the best way to tell the user that their postal code can’t have spaces? Probably not, but I’m sure it made sense at the time.

I know I’m using submission forms heavily as my example here, but the idea is still the same. Once you’re done building your whateveritis, try it out yourself. Try drawing up some use-cases get some friends or colleagues to try it out. Pretend you’re a blathering idiot, and see how well you do then. Hell, find a blathering idiot and point him in your whatchimacallits direction. Do whatever you have to to get the sense of the users process. Find the problem areas with your thingimajigs before they become the bane of every end-users (which in turn will become the bane of your) life.

Don’t be lazy, and do it right the first time people.