Editorial: Progressive Enhancement in IBM Lotus Notes Domino Development

04/15/2010 12:09 PM by Chris Toohey

I was listening to Boagworld -- specifically the Web Design News segment for February 23, 2010 -- where Paul describes progressive enhancement specific to website development.

For those of you not familiar with the term, they explain -- and feel free to click thru to the above article for more details -- that progressive enhancement in game consoles will give a game like Star Wars: The Force Unleashed a home on both XBox 360 and Wii, where the XBox 360 version has better graphics (playing to the console's higher-specs) vs. the ability to use the Wii nunchuk and the remote in tandem to unleash all sorts of Jedi fury. The game developers didn't change the overall game per se, but rather enhanced the game specific to the featureset of the given target platform.

... so where am I going with this?

Well, apply that same concept to software and application development. A typical IBM Lotus Notes Domino Application Developer may find themselves writing an app that will be used on desktops/laptops (read: Lotus Notes Client), web browsers, and various mobile devices. Most of the time - for some reason - the developer is convinced that they must deliver an absolute 100% identical user experience to every client type. You can imagine, by my phrasing, that I think this is a flawed approach.

While the app should, of course, maintain core functionality, you should be evolving the app UX and feature functionality to leverage those of the given target client.

Let's say we have a simple task management application.

The core functionality of this task management app is to allow a project manager/lead to define a list of tasks, assign those tasks to various team members, and track their completion. The project manager will run reports from the system, track team member progress, etc.

Sounds pretty basic, right?

Let's say that the fat client version of this has our Project Manager using Lotus Notes, and accessing project task data via an XPages-based Dashboard. This Dashboard will allow you to drill down to the specific task, team member, run various reports/exports of aggregated information (perhaps taking that content into a productivity suite like Microsoft Excel or Symphony Spreadsheet).

Now, our team members could be given two options for maintaining their tasks: a fat client version accessible via the Web Browser Client, or a thin client that allows them to update their tasks en route or in the field.

The mass-updates, planner printing, and such could easily be done from the Web Browser Client, where the team member can sit down and slam through their workload. This is their desktop-away-from-their-desktop, and it's something that we can rather easily deliver via XPages.

The team member more than likely will never need to export their tasks to a spreadsheet, nor will they need to run productivity reports for management. In fact, even getting to the Web Browser Client itself might be an event...

The Mobile Device Client component of this app, which we could deliver rather easily via XPages (of course!), should be the most straight-forward, no-nonsense version of the app... but can also be one of the most productive and data-driven.

See, not only will a given team member be filling out some simple task information. I mean full KISS-UX here or you might as well not even bother.

Where the Web Browser Client had perhaps 20 different fields to capture various metrics, I can really only see the need for one on the Mobile Device Client version: status.

This, of course, isn't saying that the team member will only be delivering updates on their status, but at the UX layer that's all they'll be doing.

The mobile device app could interact with GPS, giving you the location of the team member at the time of the task update.

The mobile device app could interact with the on-device camera, allowing the team member to upload updates on-scene.

All of this, of course, is not considering that you're getting the team member information, activity timestamps, and all of the other Session-specific information that you can track with their status update.

I say mobile device app, as while the app will be written in the given SDK and platform appropriate to the target devices, they could interact with XPage XAgents that maintain the Mobile Device Client API (of course!!).

And all of that information could be delivered to the Project Manager, who can view status updates and work the critical path along side the team members, making adjustments after seeing that there's no way Bill will be able to handle the next task since their latest update included GPS data that puts him out of range... but Bob should be able to handle it. Of course, the Project Manager can see all of this via their Dashboard, which has an embedded Google Maps widget which shows the last updates from the team.

See, the team member doesn't need to see where they've been. Just like the Project Manager won't need to export data via their iPhone. Sounds like a silly (if not unnecessary) statement, but most developers don't think specific to the need of the user type, let alone the specific functionality of the target platforms.

The idea of progressive enhancement really hit home for me with it's potential application to software development. Hopefully, this editorial had the same effect on you.