One of my clients recently asked me to track changes they needed on their eCommerce website I've been maintaining over the last five years. Now, most of you will probably be going 'Hello? Brian has no issue tracking in place for his clients?', but let me defend myself: My client has a low tolerance for learning or being involved in anything that does not impact their business directly.
I know and understand the advantages of issue tracking and have used and installed a few over the years, almost all opens source (bugzilla, track, scarab et al) and I know the pain of working with any of these tools for the first time: its a big WTF with new terminology and lots of options. Its one of those areas where the domain is simple, but everybody likes it slightly differently: how does an issue start out, is it 'open' is 'started' etc and is it 'high' priority, is it a bug, a feature etc..
What was ironic about the request is that I had set up issue tracking for them at least a year previously with a system I thought simple enough for them to just start using (they are completely tech literate), but they never used it (they did login though).
I went back to the old stand by: A shared Google Docs Spreadsheet: it is simple and it works and it is better than the 'spreadsheet in a shared folder' pattern, or the 'lets email the spreadsheet around' pattern. We've all been down there before and it is hell. The main problem with spreadsheets is maintaining them for any length of time. They work for month long projects, but anything longer can get chaotic.
I then spoke with a business friend of mine who is also using a spreadsheet to manage his workers and was complaining about it getting messy and out of state (it might have been a word document). I asked him why he was not using any tools to do this and he said he had tried, but that they were too limiting: he did not care who was updating the system and had no time for confirming tasks etc..
I was taken aback and forced to think about it, of course he is right. He should not have to adjust the way he works for a tool and the other thing that struck me was that what most of these tools try and enforce should be enforced by other processes rather. If you can't trust your workers to update and maintain a tracking system, you have bigger issues within your business.
Back to user-interfaces: We need to find some balance between the complex and the simple, between overwhelming the user with options and leaving him to do everything manually.
Mostly, application development is about automating things people don't want to do. No need complicate it any more than that.
The next irony in the story is that people love buying complexity! Using Gmail for the first time was a revelation: no complexity, simple interface - less stressful. The interface made me think about interface design in a different way: how can I remove options and how can I streamline the most important tasks.