Jake Herringbone

Inbox full? Not your fault!

I’ve never been good at managing my email. My inbox is very large; I have some folders but I don’t use them consistently. My OCD need to collect things makes it hard to delete, and GMail is teaching us not to anyway. Worse, I fail to reply to mail because it is quickly buried on a busy day, and I know there are some emails on page 43 of my inbox that I ought to have replied to. I’m pretty sure everyone has the same problems.

So, like most other people, I need to develop a better “system” for myself, using flags/stars and folders/labels, and I need to learn better discipline for using my system, and also gradually improve it. OR DO I?????

Maybe the fault here is not mine, or yours. This bold notion first occurred to me after reading The Design of Everyday Things. In the book, Donald A Norman writes that many people blame themselves for not being able to understand how to program their VCR. The author insists that we must point the blame at the designer of the device, it should be simple to use by emulating characteristics of physical things that we understand how to operate. One such characteristic is affordances, which are most easily explained by analogy to a doorknob: it provides a clear place to grasp and operate the device. Another is quick feedback, which helps you quickly learn if your actions are having the desired effect. The VCR doesn’t tell you if the programming was right until you check the contents of your videocassette (the book is a little old). This book is really good for tuning your ability to understand human interaction with design. I think most user experience professionals keep a copy on their nightstand.

So what of email? It’s a very old system, developed around the same time as the web, and based on “snail mail” as a paradigm. You could now use your computer to send letters, and they are delivered quickly. But you would never have imagined in each day getting hundreds of letters from the mailman, giving him dozens, and expecting him to carry it all! In terms of the user experience, email is very similar to writing letters.

As a result, there’s too much busy work in email. We have too little automation, and the basic paradigm is just wrong. I don’t want to deal with conversations on a single-reply basis – and GMail helped a lot by getting us used to conversations as the fundamental unit of email. But, there are still times when a text message conversation moves to IM or an email conversation turns into a meeting, and email doesn’t understand these other ways of communicating. The attachment paradigm is terrible for old-school offices that use it to transfer documents as work-in-progress – the messages may contain some comments about the work in progress, which aren’t in the document itself. My email doesn’t actually help me either – I want to know which friends I haven’t heard from in a long time.

I think a new way of doing things will come, and people will probably have trouble making a transition. They’ll stick to sending emails, just like they create lots of Word documents on their hard drive and try to collaborate with other authors, and they’ll continue to confuse babysitting their collections of mails with doing work. Please do your part to point out to these people that email was just an awkward transition period in communication, and that silly electronic equivalent of a mailbox never worked very well. I don’t want to get any more emails from them.

XML: configuration or code?

Seems like there’s a backlash against XML going on. Coding in XML is a code smell, and everyone is rethinking the overuse of XML in Spring configuration, for instance. Google Guice is the annotation-based IoC container, and now I see Spring 2.1 is doing the same.

I think there are two ways to look at the XML problem. One way is from the configuration management perspective – if you have a long process to build and deploy your software, you know how nice it can be to have a change be to configuration and not code. And maybe you’d deploy your software to many customers who configure it differently, if you’re writing Tomcat for instance. There are surely some situations where the configuration of your app isn’t simply key/value pairs, and XML is a nice way to structure your config files.

But of course this is abused, and Spring contexts are a good example. You don’t expect that the customer is going to change the files, they’re very long, and it’s likely that a change in the app is going to require compiled changes as well as the XML changes. And they’re really part of the code, wiring up objects in a specific way, such that changes to the context are likely to result in the app not working.

Annotations are the answer to this, it seems, since they put the configuration right there in the code. It’s a more concise way to express the intent, the compiler catches your typos, and should make for better tool support. But, I have one problem with this – thinking about the Dozer bean mapping framework as an example. Here, we have two JavaBeans and the XML configuration describes how to map properties from one to the other. It seems anachronistic to give either Javabean knowledge of the other.

Maybe the better way to think about it is that XML should hold data. Facts, unchanging in time, with no logic, no tie to the classes themselves and certainly no relation to a certain runtime context. Sometimes the data is obvious, like the input to a DBUnit test. It could be some wire-protocol data, like a web service request used in SoapUI. Maybe sometimes it’s configuration, like the servlet.xml file. Maybe it’s even the dozer mapping file, describing how two JavaBeans’ properties are related. Anything else, and yeah, XML is not a good place for it.