I’ll be posting “Judicium Dei – Trial by Coding (Part 3)” – the finale, soon enough, but here’s something else in between then and now.
Composition drives meaning and intention. Features by themselves lack meaning and intention. Selling software that lacks good composition is like sending a monkey with a bikini into a swimsuit contest, funny as it may look and including all the key “features”, it won’t win. While sales people love features (as they can be tangible points on a checklist), lots of nice features don’t make good software when they could code another feature instead.
A developer at work was showing me some neat CSS featurettes online. He was exclaiming how cool each was, and how nice they looked, and how we could throw something similar into our software. I definitely agree that many were cool, and some looked nice, but they definitely don’t deserve to be in our software just because they look neat on someone else’s website. Unless you’ve only got one pony pulling the carriage, you can’t drive development by any single or even group of features as they still all need to go in the same direction.
Unless you can put all of those features together, fluidly, coherently, and intuitively, you’re doing a disservice to those who use your software. Having software that’s been well composed means having someone who’s taken time tying together the bigger picture while also fine tuning the little details. You must be the curator for the art gallery, the editor for the writer, the PR manager for the monkey with a bikini. Software communicates in many small, almost silent, ways, and while no specific tweak will make or break a piece of software, a tide of small perfections that all have the right direction, through meaning and intention, will communicate tons of information, and that’s well worth a decent amount of time and effort.
For example, the main project I’m working on has two key users, managers and administrators. 95% of the users are company managers who have a relatively simple process in front of them. The administrators, however, are our only interface, they’re paying for the product, and they’re the ones giving us feedback as we customize the system for their processes. The admins understand the manager’s processes, and they’re basically super managers (no capes included). So, we have to build a system that’s on the surface simple and fast for the majority of users while being powerful and detailed for administrators. In essence, these are two different messages being communicated to two different users under one roof.
Both processes are data heavy, but the administrators require much more data that interacts in much more complex ways. The managers get a simplified version of this while still being data heavy itself. The first order of composition is providing a single point of interaction for the managers to do the bulk of their work. Now, there are some peripheral functions and pieces of data that support their process, and those need to be quickly accessible for them. However, if you just put those pieces on the page, then you’re distracting from the main function by eating up screen space and cluttering up the visual composition with more objects. Yet, if you hide these on separate pages, then you’re slowing down a simple process, and forcing users to do extra mental paging in order to flip between the key pieces of information.
My solution is a page with “drawers.” The middle section of the page contains the content where the work will get done. The top and bottom contain the extra features and information that will be used, but less often. When the user’s mouse is over the main section, the other sections hide themselves like closing drawers, but with handles showing that you can hover over to open them up. When you hover away from a drawer, they close again, or you can click to keep them open if you’re at a point in the process that you need them always accessible. At this point, the bulk of the users have what they need right in front of them without any extra clutter, but they also have a few other key pieces within arms reach.
Putting that one fine tuned aspect along side many others (highlighting user changes on the page, providing good contrast, giving proper emphasis from important to less important sections, etc.), you can get a smooth, friendly, and yet powerful application, but all that little detail work can add up to a decent amount of development time. If you don’t, then you’re left with lots of rough edges that detract from use, and inhibit the basic functions of the user. Additionally, add in the second layer of administrator functions where everything needs integrate smoothly without hindering the existing managers functions, and you’ve got a complex problem to solve. Without proper consideration for all the moving parts along with good attention to detail, you’ll end up with a monkey in a bikini when you want a beautiful babe with a sexy bod.