Monday, March 24, 2008

In Which I Say "Hallelujah" To Simplicity

By now many of you have probably seen the great little comic on the "It's Just a Bunch of Stuff That Happens" site about Simplicity, but if not follow the link then come right back...

Pretty true to life, eh? I recognized the bottom example in many, many (many, many, MANY) Notes applications I have seen through the years and I'm sure you did too, which is why we all thought it was so funny in a sad sort of way. But I tell you what my friends, the idea of simplicity is sorely lacking in the enterprise software world and this causes an undue amount of headaches for our customers, for our bosses and for ourselves. Is there something we can do about it? Absolutely. We can say no to complexity in the applications that we design.

To be fair, although the comic is funny, it's not really being equitable as it compares Google and Apple to an enterprise application, but the idea is not so bad. One of the tenants I've tried to instill in younger developers as I've mentored them is that complex business rules do not necessitate complex interfaces. In fact, I think the opposite is true. We need to work even harder to streamline and simplify the interface when the complexity of the business world rears its ugly head. We're all overwhelmed with the amount of data we have to deal with on a daily basis, so we appreciate (and even long for) those things that are easy to use. If we're trying to delight our customers and make their experience in our applications a pleasant one, what better way to achieve this than to employ our skills to craft a simple solution.

Here's an example from my own experience. Some of you have seen this in my talks at Lotusphere or the View conference, but it bears repeating. I worked for a few years for a "global tire manufacturer headquartered in Akron, OH". They had a pretty mature Notes infrastructure that had been around for quite a few years and some pretty complex systems were developed in Notes by IBM consultants there. One of these was a beast of an application called Vendor Billing, but I affectionately called it the Hellspawn. (OK...I didn't really call it that at the time, but in thinking back I should have!). The Hellspan was one of those systems that you dread to come across when you're a consultant. A multi-tentacled, multi-NSF monstrosity that had become more and more bloated over time, since developers just added new features without refactoring or thinking about what future consequences their design choices might make. I don't believe anyone did this out of lack of skill or with any ill will toward future developers, but rather the reality of a complex business process coupled with a desire to make changes quickly and cheaply provided the perfect environment for such a system to come into being.

Vendor Billing...excuse me...Hellspawn, was a system designed to gather up information about all the various IT services an employee at Great Big Tire Company made use of. This was managed through a series of documents that basically captured the services a given person was "subscribed" to. In addition, other databases in the Hellspawn suite stored employee department information, billing codes, rates, etc. It also interfaced with some of the company financial systems that were not in Notes. At the end of each month, some *really* nasty and complex agents gathered up the information from the various databases, determined how large each user's mail file was, spun around twice and sacrificed a chicken to the Gods of Complexity and spit out a document for each user that listed their costs for the various services. All of this was pretty much backend stuff and this far was hidden from the eyes of the users (thank goodness!). Unfortunately, the final result, that cost document, was used in a series of views that the end users would interact with.

For a good 29 or 30 days out of the month, the users were blissfully unaware of the evils that were going on within the Hellspawn, but when it came time to for managers to review their charges for that month, there was no escaping the task to be done. At this time, a manager would open the database and navigate to the main billing view. Within this huge, *horizontally-scrolling* view, the manager could see the totals for each subscription for each of his employees. On average, each manager spent about 30 minutes figuring out their IT charges and it certainly wasn't a fun or efficient way to spend half an hour.

I was first introduced to the Hellspawn shortly after I started at Great Big Tire Company and I'll admit that I was a bit scared of it at first. Certainly the idea of Simplicity was far from the minds of the people that developed it. I've no doubt that they were smart folks. There were custom LotusScript classes to perform operations on linked lists and the like. I'm quite convinced that some programmers make things more complex than they need to be simply to show off their "mad skilz". There's certainly a place for that, but in my opinion it's not in enterprise applications. Thus, my first thought as I looked at this beast was that it needed to be simplified...greatly!

I started, as I often do, by building some quick prototypes that distilled the basic essence of the application down to a single question: "What were the charges for my department?" Once I determined that this was what this system was really trying to tell the end user, the interface became quite obvious and instead of a massive view with the ability to navigate to other massive views, it was just a single field to enter the department number a la the Google search box. When a manager entered their department (which was of course remembered for the next time) and clicked the button, the new code I wrote went out and gathered up the required numbers and showed them on a new document which functioned as the "monthly report". This was formatted in a clean and simple way, such that they really needed to spend no more than 30 seconds checking their numbers. That's a pretty decent time savings per month per manager, eh?

As I worked on the new UI, I also spent a great deal of time under the hood, trimming things, refactoring code to make it easier to read and hopefully more efficient. Even though the business rules were still complex, I strove to make the managing of those business rules as simple as possible. This is our challenge as application developers and is as much an art as it is a science. Based on the hundreds of Notes apps I've seen in my career, here are some ideas to get you started:

1. Not every database needs a three pane UI. As Nathan is fond of saying, "It doesn't all have to look like mail!". Pick the UI layout that makes the most sense for the task at hand.

2. Skinny down your forms and pages. Most developers try to cram too much into a single screen. Instead of this approach, try a more fluid design that brings the most important information for the current task to the forefront of the user's attention.

3. Use views wisely. Not only are views one of the biggest performance hogs, but it's not necessarily efficient to use a view to find what you are looking for. Provide other mechanisms to getting at the data in your app, such as a document search like in my example above.

4. Examine other apps that you find easy to use and try to determine the reason why you like them. See if you can bring some of these themes into your own applications. A great example of this is an ajax-type ahead feature. It was immediately evident when we first saw examples of this technique that it would be useful, but I really feel now that it is almost a must have. It's such a great device for simplifying data entry in many situations and I try to incorporate it into my designs whenever I can.

5. Think outside the box. Yep, it's a cliché but it's still true. Sit down with a piece of paper and make your design as simple as you can, trying to forget the bounds of what you can do within the client. Then, once your design is done, jump in and figure out how the heck you are going to do it. For me, this has been a powerful technique, as I've come up with some great interface tricks by "drawing myself into a corner". :-)

As my life and work gets busier and busier by the day, I am more convinced than ever that simplicity is one of the greatest gifts a designer, engineer, boss or politician can give us. I'm sure many of you feel the same, so strive to make the idea of Simplicity an integral concept in all of your designs and save your users (and yourself) from the Hellspawn.


Ganapathiram Natarajan said...

I have seen similar cases where multi-NSF notes applications get feature enhancements without any thought for refactoring. Even the developers who know its wrong, watch it happen helplessly. Finally it becomes a big monster with too many views, big forms and often results in poor performance.

Then, Lotus Notes gets all the blame (interesting part is, the blame is generalized to Lotus Notes not just that particular application)and the solution: Migrate away from Notes.

Joanne said...

LOL at "sacrificed a chicken to the Gods of Complexity" - probably shoulda thrown in a cockroach or 2... there were plenty in the cafeteria to spare :-D

Great post!

Anonymous said...

Excellent post. I work for a multi-national corporation and have inherited support for several Hellspawns. As Ganapathiram said - Notes gets the blame. I won't be redesigning the apps since the powers that be have already decided to replace their functionality with vendor (non-Domino)web based products soon. My current challenge is to have enough time left over after day to day support of these monsters (in their final hours) to work on a few Notes apps that will look nothing like mail :-)