John Topley's Weblog
January 2004 Article ArchiveDesign 102: Don't Punish The UserTuesday, 27 January 2004I wrote previously about how white space is just as important in good user interface design as the content itself. Whilst booking some concert tickets recently using the TicketMaster website, I came across another example of bad design. In this case all I had done was opt for standing tickets to be sent to me via normal post (not registered delivery). This is what happened:
—The problem here is that the user is being punished for making a perfectly legitimate choice. It's better to prevent the user from getting into trouble in the first place than berating them when they inevitably do so. If the website was clever enough to recognise that I'd made an invalid selection, why did it not only let me but also tell me how to correct the mistake, instead of just preventing it from happening in the first place? And there was really NO NEED TO SHOUT AT ME. Event Log ParanoiaSunday, 18 January 2004As a user of the Windows NT flavour of Windows since 1996, one of the things that I've got into the regular habit of doing is checking the event logs for anything untoward. I always felt smug knowing that I was running a proper operating system (unlike that flaky Windows 95); one that would log anything interesting in the background whilst allowing me to continue with my game of Freecell. I felt a duty of care to return the favour by looking to see what it was telling me, and I've never got out of the habit. I guess there must be a sysadmin lurking deep inside me and that means I should probably seek help from a health care professional. Those who've only just joined the Windows NT club by virtue of buying its grandson, Windows XP, may wonder what I'm talking about (hint: If you're running Windows XP Professional then log on as an Administrator and run eventvwr.msc). It was during one of these trawls through the logs the other day that I noticed that a lot of the entries are plain indecipherable (even to a nerd like me) but still worrying. Because I'm the sort of person who likes to run a tight ship, I get alarmed when I see entries such as: “RSM cannot manage library PhysicalDrive3. The database is corrupt.” I know that RSM is the Windows' Removable Storage Service but I have no idea what the implications of its database being corrupt are. Even more frightening is this message: “AMLI: ACPI BIOS is attempting to read from an illegal IO port address (0x75), which lies in the 0x74 - 0x76 protected address range. This could lead to system instability. Please contact your system vendor for technical assistance.” If I didn't know better, I'd think there was a problem with my computer's BIOS. I've written about backups before but I didn't tell you that when using the Backup program I always get a pair of event log entries: “Could not initialize the MS DTC XA Transaction Manager. MS DTC is being started but the XA Transaction Manager feature will be disabled.” —And its buddy: “Could not create the MS DTC TIP Gateway initialization object. MS DTC is being started but the TIP feature will be disabled.” I've learnt that these two messages always come as a set. Because I'm a programmer, I know what the Microsoft Distributed Transaction Co-ordinator (MSDTC) does but not what's going wrong in this instance that's causing an error to be logged. The odd thing is that in spite of all these scary–sounding messages everything works just fine, so who can tell what's really going on? Back in the pioneering Windows NT days, the only option we had for deciphering these technical messages was to apply for a job as a Windows programmer at Redmond. Failing that, we could probably find something out using the Windows NT Resource Kit. The kids today are spoon-fed help because Windows XP helpfully includes a hyperlink as part of the message. I clicked it out of curiousity and got this:
—It seems that even Microsoft don't know what the message means! It can't be anything to worry about then. Suitably reassured, I went back to my game of Freecell. Learning To K.I.S.S.Wednesday, 07 January 2004Do the best programmers know how to Keep It Simple, Stupid? Is simplicity itself a desirable goal? I didn't used to subscribe to the idea that simple was always best. I thought that sometimes complexity was the only answer. After a year spent learning Java enterprise programming, I'm beginning to change my mind. I think I'm suffering from J2EE fatigue. It's characterised by an inability to comprehend the myriad of XML configuration files, some of which override others, and by a weary indifference to whatever new open source whizz-bang designed to simplify J2EE development is. I came into the programming game by writing desktop applications using Delphi and Visual Basic. Sometimes I even called the Windows API directly! Quite often, actually. However, J2EE is a whole leap upwards in complexity and I'm not just talking about the straight programming either. Sure, there are the thousands of classes that form the Sun Microsystems' J2EE specification (easy to see how one might re-invent the wheel out of ignorance). There's also a whole plethora of design patterns over and above the regular Gang of Four pattern catalogue. In J2EE-land you're a nobody unless you know your Struts from your Hibernate, your JUnit from your JBoss or your Ant from your Maven. Reading TheServerSide, you might be forgiven for forgetting that most of this stuff can safely be ignored and that you really should just concentrate on the job at hand. “Computer science is the discipline that believes all problems can be solved with one more layer of indirection.” I'm no longer entirely convinced about the need to hide the database tier behind layers of abstraction and indirection. After all, how often do companies change their enterprise database? Once every five years? Every ten years? Fifteen years? By that time the rest of the code will almost certainly need to be rewritten anyway. A lot of modern development seems to be taking the time to go the extra mile initially and put code in that will make change less painful later on. Having to change and maintain the code is almost inevitable, but who can predict what form it will take? One of the philosophies behind Extreme Programming is that you should build as little as you can get away with and try not to anticipate and incorporate future enhancements. “…there are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies and the other way is to make it so complicated that there are no obvious deficiencies”. Weren't object-oriented programming, design patterns and frameworks supposed to make life simpler for the poor sod writing the code? Sometimes it seems that there's so much to think about and remember that the opposite seems true. I doubt that very few of us program as those who came before us did. Today, most of us use frameworks and classes created by people far cleverer than we are. “Everyone knows that debugging is twice as hard as writing a program in the first place. So if you're as clever as you can be when when you write it, how will you ever debug it?” There are some encouraging signs that things are changing for the better. I read today that Microsoft are aiming to reduce the Windows API set from the 76,000 APIs in Win32 to 8,000 .NET APIs in Windows Longhorn. Being nice shiny new .NET APIs, they should have some semblance of cohesion and consistency to them, so that knowledge gained can be gainfully exploited elsewhere. Let's hope so. Over on the other side of the dividing line between good and evil—I won't tell you which is which—Sun are making encouraging noises about simplifying J2EE development, which I welcome. That's in the future. Today, I'm still not sure where I stand on keeping it simple, stupid. I do think I've found a guiding principle though: “Things should be made as simple as possible, but no simpler.” |
 |
 |
 |
 |
 |
 |
