Darryl Booth

Dear Browser-Based Applications, "It's not you, it's me..."

I have to break up with my browser... but I swear I want to stay friends.

Oh sure, I'll keep Firefox's number handy for those brain-dead moments when I just want to review the Evolution of Dance or check the latest nerdy tech news at Slashdot.

But that's it. No more serious business applications in a browser. It's over.

I admire those solemn developer-soldiers who toil trying to build browser-based business applications. Their job is impossible and it's not their fault. My expectations are probably too high.

Consider the browser's poor marks on the following fronts:

• Spell Check (if available, implemented in a herky jerky kind of way)
• Keyboard Shortcuts (try pressing Ctrl+S for save some time)
• Performance (I'm tired of postbacks)
• Security Restrictions (more yellow bars prompting me to trust)
• Reporting Tools (uh... was that important?)
• Browser Compatibility

As a business community, we've come to accept these limitations as satisfactory trade-offs. Perhaps it was originally to avoid the disruption of installing an actual application on each desktop. Perhaps it was during the giddy dot-com carnival where everything was going to be done in a browser.

Considering that knowledge workers' continued productivity increases are key in most industries, why do we tend to tend shackle our best producers with sub-standard tools at the desktop?

Now, a quick side-trip for the inevitable AJAX discussion. Google Docs, for example, has done things previously thought impossible by using AJAX. Kudos! In my experience, this can be a fragile development environment and just isn't my first choice. I'm not convinced that this is the future of Internet-based applications.

As for me, I'll bounce back. I have a date with ClickOnce.

The Devil is in the Details

Peter Lucas, Decade's lead technical writer, recently announced an update to the EnvisionConnect Style Guide.

The EnvisionConnect Style Guide is our internal reference document (a PDF actually) that "puts in stone" all the seemingly inconsequential decisions that go into a consistent and well-thought-out user interface. An author might be more familiar with the term Manual of Style.

Here are some examples of the questions answered definitively by the EnvisionConnect Style Guide:

• The font, style, color, size, and case (e.g., title case, sentence case, or all caps) for all text areas in the system
• The alignment (e.g., left-justified, right-justified, or centered) of data and column headings in a list
• How to select the default action (what happens when you just press Enter) for each page
• Standard terms that shall be used to reference/brand unique elements in the interface (e.g., A grid showing search results shall be referenced as a "Lists")

Designers, developers, and users are passionate folks. The EnvisionConnect Style Guide is a constructive conduit for that passion. Here's why.

The debates on these small matters can quickly reach a religious fervor. Seriously, I'd rather debate the merits of death penalty with Mother Teresa before I suit up for another argument about whether labels for checkboxes should be aligned on the left or right of the checkbox. It turns out that the label belongs on the right. This debate is now dead.

Commissioning a style guide is one of those lessons hard learned. Now it's one of the first requirements of every new project.

I'm Feeling Lucky

Jeff Atwood of Coding Horror outlined last week his perspective on a question that has been plaguing me for years... what is up with the Google "I'm Feeling Lucky" button?

Tell the truth. Do you really know? If you know, how many times have you been asked to explain it to others?

According to Google, the button takes you directly to the page that best matches your search. Search for "EnvisionConnect" and click "I'm Feeling Lucky" and you'll find yourself at EnvisionConnect.com, having saved the effort of clicking on the first item in a normal list of results.

Jeff characterizes the feature as "Google's Number One UI Mistake." His perspective is that the button is superfluous.

My perspective is a little different... the button is not well labeled. Inside jokes aside, the button should really be labeled something like "Jump to First Match."

Tell it like it is. Say what the button (or menu item or link) does. Don't make the user guess. Users would rather be successful than knowledgeable.

A lot more Googlers would be feeling lucky if they knew what they were getting.

Users Would Rather be Successful than Knowledgeable

Allen Cooper's design guide About Face 2.0: The Essentials of Interaction and Design is sprinkled with axioms that serve as signposts. Here are my favorites:

• Significant change must be significantly better (chapter 2)
• Nobody wants to remain a beginner (chapter 3)
• Imagine users as very intelligent but very busy (chapter 3)
• Don't make the user feel stupid (chapter 5)
• An error may not be your fault, but it's your responsibility (chapter 17)
• Consistency doesn't imply rigidity (chapter 19)
• Users would rather be successful than knowledgeable (chapter 20)

Some of these points (obviously detailed in the book) hit me like a two-by-four. Re-reading these points ought to be a daily affirmation for designers.

I would respectfully add a couple more for consideration:

• Designers rarely (if ever) knows more than the user about how to do the user's job
• Every good design can be improved upon... but not always substantially so
• Seeing is believing... show your users prototypes, not descriptions of prototypes or promises
• Let the design stew a week or so before you lock it in
• Recall the spirit of the design over the literal design during implementation

Iterative Development, It's Kind of Like Painting Your Kitchen

When I train EnvisionConnect users on new features, I look forward to seeing the folks who earlier participated in the design phases of the project.

We've used prototypes and online meetings to get the designs in front of the customers very early. So, by the time the training is scheduled, the workflows should be very familiar, like an old friend.

As a general disclaimer before training begins, I usually try to say something like this:

Before we begin, a reminder that we develop iteratively. That means that the features of the workflow are delivered in smaller manageable segments. You may not see today all the features we discussed during design.

It's kind of like painting your kitchen. Coats of paints are added to the walls only after the previous coat has dried and we agree that we really do like the color, texture, etc...

Iterative Development has huge benefits for the developer and the customer. Key among them:

• The "Must Have" features get delivered first and get delivered early, because we're not waiting for all the "Should Haves" and "Could Haves" to be integrated.
• Poor design elements are exercised early, giving the designers and customers a chance to change course if necessary.
• Good design elements are embraced, clarified, and reused with greater confidence.
• And sometimes... just sometimes, the user community determines that the first iterations are sufficient. This is a well-informed decision since they've been using the working system all along.

Having painted a few kitchens, bedrooms, and bathrooms over the years, it's always a nice surprise when two coats does the job.

EnvisionConnect Dispatch Centers

I'm preparing this week to record a short training session (Decade password required) on the workflow known as Convert to a Regulated Facility. This time-saver takes the data-entry that was done during the plan check phase and instantly copies that information to a new permit (assuming the facility was approved, of course).

While preparing for the class, I re-discovered EnvisionConnect's Dispatch Centers. It is a pleasure working with data in the Dispatch Centers!

The default views and full text search are perfect for the casual user while the grid's Excel-style filters, grouping, and sorting are ideal for the increasingly sophisticated user.

This design, like all good designs, was formed iteratively by listening to the experts... the user community.

• Lorraine Lew coined the phrase "Dispatch Center" while describing how critical complaints are rapidly assigned (dispatched).
• Rich LaWarne advised us on the simple list design and the default views, underscoring the fact that he and his staff don't have time to learn how to design custom views.
• The search works because Raj Muthusamy crafted a search engine that examines the columns that are in view. This gives the user power over the search scope and makes it clear why each match is a good result.
• Runaway searches are impossible since the user can tweak (e.g., adding or changing search terms) and re-launch the search at any time... one does not have to wait for the first search to finish.
• Set your filter, columns, sort, grouping, etc. anyway you like it, the settings will be preserved between sessions based on your user name.

Post-Dialog Depression

My young son and I rented the video came Cars this weekend. We're big fans of the movie and the animated characters. 

 

In one facet of the game, you drive around the town of Radiator Springs looking for "Lizzy's postcards." The postcards, you see, were scattered around the town when Lightening McQueen accidentally turned on a fan. Find all twenty and you've accomplished your mission.

When you find a post card, the system saves your game… so you don't have to find that particular postcard again. That's good.

WARNING: Disturbing Content Below

Andrew finds a postcard and drives over it. Yeah!	The game bumps up his score!
	The game stops play and prompts you to save your game. That's like my bank prompting me… uh, do you want us to keep a record of this deposit?
Andrew chooses Yes, save the game.	The game prompts, do you want save the game to the internal memory? That's the only option on this system… good thing you asked or else I might have saved the game to the couch or the lamp!
Andrew chooses Yes, save to the internal memory.	The game detects that there is already a game saved to the memory card.
	The game asks, Do you want to overwrite the game previously saved in the internal memory card? The default is No! My four-year old is not great with reading professionally scripted instructions and every dialog looks like every other dialog!
Andrew (with my help) changes the response to Yes.	The system finally saves the game. Yeah!
	The game, so proud of itself, it displays another dialog stating that the game has been saved. Thank goodness somebody called me this morning to tell me that the sun came up or else I would have been totally surprised!
Andrew chooses OK, I'm proud of you too.	The game returns to play and now I'm catatonic.

You will notice that EnvisionConnect dialogs only appear when you are about to do something irreversible and not the norm (e.g., delete a permit) or when you absolutely must be stopped (e.g., an error condition)… and not when you're going about your daily work.

Why? Because dialogs disrupt flow. When they alert you to the obvious, it's just weak design.

One last note, we do not claim perfection on this point or any other… just an honest desire to continuously improve.