Mobile XPages: The Five Ws

01/03/2011 03:07 PM by Chris Toohey

In this series, you will be creating a multi-platform mobile device user interface and enhanced user experience for a Domino Server-hosted NotesDatabase app using the Personal Address Book Template.

The first step in creating an enterprise-level solution on any platform is to stay as far away from the actual development of said solution as possible... until you have a complete understanding of the goals of the project and how it will improve the efficiency of those who use it. In that spirit, our project build kicks off with considerations to be addressed and decisions that must be made before a single line of code is written.

We will use a modified version of the Five Ws technique to ensure that we consider all aspects of the project.

Who is the target audience?

Does your target audience consist of the corporate IT Department sporting 15 types of mobile devices, is it the Executive Board who often delegates tasks to their personal assistants, or are they comprised of warehouse staff working from kiosks? Knowing who your users are will greatly direct the project [and as a result the end-result], and it is absolutely critical that you understand both who they are as well as their day-to-day interaction with the organization.

From personal experience, I have discovered that asking, "So... who's gonna use this thing?" has saved me countless hours of re-writes and scope creep by virtue of it having the project champion re-think who will actually be using it daily.

I would recommend creating Role-based user profiles -- written bios, not to be confused with User Roles or Profile Documents in IBM Lotus Notes Domino Application Development -- for each of your potential user types, and submit them for review to your project champion. With these profiles in place [and reviewed by your project champion], you not only confirm your understanding of your solution user base but also proactively address any scope creep specific to who will use the app.

The discussion often has the project champion saying something like, "Well, of course the CEO will need to approve these while he's on the back nine, but he'll often just delegate that to James [his assistant]...". From this simple statement, you know you'll need to create a mobile device entry vector for -- at the very least -- business workflow.

You could also take away from that statement the potential for a "quick win" by providing the CEO with a mechanism to click-and-delegate a given request directly to "James"...

But this course leads us to our next question...

What is the goal?

Once you have established who will be using the solution, you'd better find out what they want out of it. If the goal is simply stated that they want to "mobilize [a given NotesDatabase]"... well, there needs to be more of a discussion on the topic.

Let's take our series build project and use it as an example. Forgetting all of the other parts and functions of the Personal Address Book Template (eg., Connection Documents, Locations, Accounts, et al) and focusing rather on the contact management features... we're left with a Contact form that has over 33 input fields enabled by default.

Size that down to a mobile device... and your users will -- trust me on this -- hate you with a passion.

The goal here should be to address their goals while ensuring that you create a user experience that lends itself to the target platform(s).

For example, I doubt that someone accessing a group Lotus Notes Personal Address Book via their iPhone or BlackBerry would care about a given contact's 2nd Personal Email Address...

There will be compromise, and the mobile user experience -- if done right -- will not simply be a port of the rich client [Lotus Notes or Web Browser] version of the solution to a 320x480 resolution screened mobile device.

Where will they use it?

"Everywhere!" I hear, and before you think this a simple question, keep in mind the following:

Not everyone has decent mobile device coverage. Think about the users in Finance that get the type of reception that could only result from lead-lined walls built for anti-kryptonian measures. Even Wi-fi can be problematic, and your super-l33t solution can fall flat on its face if people get connectivity errors when they click on that new icon on their BlackBerries. User perception is reality, and errors tell them simply that it don't work.

Will you need offline/local storage capabilities? Depends, honestly, on connectivity/coverage considerations and just how critical of a solution you are writing.

Is relying on a local data store that is potentially several minutes our of sync with the master database an issue? Does it pull down system-generated unique and/or numerically-sequenced IDs? Does it need to actively communicate to live systems to function?? Depends, honestly, on the application.

Once you have answered these questions, or at least brought them to the attention of the project champion who may not have considered that the warehouse staff could go "offline" when checking for realtime stocked inventory numbers for product substitutions, can you grasp the architectural considerations required to even make this solution work.

Simply put: you may be fine, or those lead-lined walls may need to come down.

When do they need it?

I'm reminded of an old consulting adage:

You can have it good, fast, or cheap -- pick two.

Understanding the delivery expectation for the given solution, as well as communicating just how long such a thing can take [whether that is shorter or longer than the project champion assumes...] will help everyone involved.

I have spoken with CFOs and informed them, "Sure, we can get you approving those requests from the back nine in time for your upcoming tournament this weekend, but we'll need to push back [this business critical project]". Haven't had a single one respond, "Yes, let's shoot our business in the foot in case someone submits a request that can't wait until Monday morning!".

This question is about establishing the delivery expectation as much as establishing phases.

The phases of the project should be broken down thus:

• Need to Have
• Like to Have
• Wouldn't it be cool if...

You need to ensure that phase 1 addresses the business critical goals which you previously established... and time willing deliver the low hanging fruit from phase 2.

It's also important -- not matter how tempting -- that you stay away from the Wouldn't it be cool if... phase [3] until you have delivered the first two phases.

And the first two phases on all of your projects.

Why would your users use it?

I believe that technology in the workplace should be like CGI in a movie: the better it is, the less you notice it. To this specific point, there is a huge consideration when answering the why:

Does the individual user receive a value from using your solution?

If the answer is no -- if the user has to do more work, if the process is now more complicated, and/or if this entire exercise is simply because someone told your boss at the company holiday party that it'd be really sweet if they could submit a request for $10 million in capital from the iPod Touch their spouse gave them for Christmas -- then it's one of those ill-fated projects.

Conclusion

The How -- often referred to as the Sixth W -- is the fruit of the first five and your knowledge of the platform.

The next article in this series, XPages Mobile: Architecture and Design Considerations, will discuss several options available to the IBM Lotus Notes Domino Application Developer.