User interface battle
Getting the user interface right is probably one of the hardest step of development. Building an interface that looks good is easy enough. Building an interface that handles every possible action the user in front of the keyboard can think of combining is challenging, but good validation can save the day. Things get harder when the idea is to build an interface that the user will actually appreciate. One side, you have the managers with the idea of collecting a lot of data to produce all kinds of reports the world still has to invent. On the other end, you get to see the developper who’s greatest will is to spend as much time as possible not interacting with the software at all to perform some actual work. In the middle, you have the developers willing to keep things as simple and generic as possible. Of course, some companies developing software for an external client without a fix bid contract have the opposite objective of keeping things as complicated as possible in order to extract more money, but that’s an entire different topic.
Once again, technology is not really a problem. Even for a web based application, AJAX now allows to perform some dynamic transactions and get significant improvements on usability. The problem come from the fact that there are too many different objectives. Since not having any users is not realistic and not having managers is not likely to happen, we’re still stuck playing the middle man. Depending on the domain, the data requirements might not come from management, but that’s not really important as long as you know where the requirements are coming from. If you can’t trace a requirement, chances are you are collecting useless data and have a crowd of angry users.
Basically, what has to be done is attempt to collect all the information you need without having the user enter it. Work process is a good way to do it. Since most reporting-required information is related to entry time, making sure you application collects the information according to a process and keeps the workflow linear enough, you can probably manage to get all these dates without too much efforts. The problems that arise from this is that your application also becomes linear and unless you can find a way to tailor it to different needs, chances are the end users will end up feeling the process. Being driven by a static process instead of work requirements is not a good thing. It’s not so bad when they perform the actual work, but the training part gives them such a bad feeling that they end up hating it before ever using it.
The main issue I have is that I keep forgetting they actually make mistakes once in a while. Filling in the information ends up being not so bad, but correcting mistakes is a real pain. This is something you really need to think about. Even if the data collection is process-driven, it has to be possible to hack into the workflow to fix something afterwards. Might it be the need for freedom?
An other useful way to keep data entry low is to get the information straight from the source. It’s not uncommon for source information to be located somewhere else. Even if you can only partially import the data, half is better than zero. In the same way, filling fields with common values is a good way to reduce the burden. Even if the value makes no sense, if it’s the one that’s entered most often, it should be easy to enter it. The main inconvenient as a developer here is that you are likely not to know this information until the application has been in production for a long time.
Data disposition is also a very important aspect. You need to be able to make as much information as possible available on screen. Any information they are likely to need for decision making should be available quickly. For this aspect, web interfaces have a huge advantage, mostly due to the fact that people expect to see a scrollbar. Keep common information close, make less-common information available lower in the page. Of course, it will take more of these SQL queries, CPUs will spend more cycles rendering the page and network traffic will be higher. Who cares on a local network? Having the information a scroll away is much better than a few clicks away. Focus on relevant information and avoid printing useless data. Saving a few clicks won’t help if replaced by a long listing scan.
Knowing the objectives of the different stakeholders is the key to interface design. I’m far from a master in this discipline. In fact, a year ago I never thought I could formulate an actual idea about it.