Computer Software is so virtual that it is very hard to determine why one thing is "better" than another. Is it better to have buttons run along the button of a grid horizontally, or along the right of a grid vertically? What exactly does "better" even mean? Easier to read, easier to understand, better looking, more extensible, easier to code, ...? You can apply all the Theories of Software Usability you want to and its still going to be hard to determine.
The same issues come up in object oriented design. Should this be one object or two? Should it contain state or not? Should it use inheritance, or delegates, or dependency injection?
Its very difficult to prove that one way is better than another in cases like this. To combat this problem, programmers and designers use some common rules of thumb. One of these is that consistency is a good thing.
If you choose to lay out your UI in one way somewhere else, its a good idea to do it the same way here. If you've designed your objects to behave a certain way somewhere else, its a good idea to make them work similarly here. It makes sense. If everything is "consistent" users don't have to constantly learn new things. Learn it once and it applies all over. This was one of the things that impressed me about Windows Powershell. Its structure makes all its commands very consistent.
However, I've found that people all too often use Consistency as a convenient cop out. "We have to do it this way! Its more consistent!" Okay sure, rule of thumb, consistency is good, got it. Is it always true? Of course not! Sometimes the benefits of doing something a different way are better than the benefits of being consistent. Other times, being consistent can be down right bad. If you're forcing A, which isn't in any way similar to B, to behave similarly to B, you're probably doing something wrong. And of course, if the consistent way has problems, or if a better way has indeed been found, then forcing yourself to be consistent is just keeping you from making any forward progress.
I know, this seems obvious. But its such an easy trap to fall into and it happens all the time. Its just easier to say, "lets make it consistent," than it is to think about if that might actually be the best choice. After all, software is so virtual, its hard to determine if one thing is "better" than another.
At my company we have a modificatioon of the consistancy rule called "make it like claimstation" where CS is our biggest Claims application. Basically this mandates that 5 years ago when that team made all their design decisions they dictated the future direction of all of my group for ever (or until some strong willed person comes along, puts their career on the line in the name of better design.)
ReplyDeleteThe problem with this is that the team that wrote CS didn't really do a lot to evaluate usability or trainability. Sure they thought about it a bit but its obvious that it wasnt a big part of the culture of development back then. So we are redoing the same design mistakes because its consistant. Very much a pet peeve of mine.
My current client (and probably most big companies) has an unofficial policy of "do what we had been doing until it hurts (unless it goes against the current corporate push to do ___ everywhere, if thats the case, do that too)"
ReplyDeletePlus there is very little time budgeted to changing things to be what is "right" from our perspective, just "pretty right" to the business.