When building an application, developers have to resolve more than just a business problem. Today's applications are requested to function on more than just one type of computer, one type of operating system, browser, or device. The way people work at their desktop computers is completely different from the way they work on mobile devices.
Each device type has its own benefits and limitations; however, you want to provide your application to a broad range of user types.
While classic Notes applications are only used by a Notes client, the modern applications have to serve a variety of client types. Often, the type of client is not even defined when the application design starts. However, development teams should give thoughts to the audience for whom they are trying to provide the application.
When design your Domino applications, always design with the audience in mind and consider the who, what, where, where, why, and how.
Who is the target audience?
Does your target audience consist of the IT Department with a small set of 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) to the right direction. It is extremely critical that you understand both who they are as well as their day-to-day interaction with the organization.
We recommend creating role-based user profiles -- written bios, not to be confused with the user roles or profile documents in the IBM Lotus Notes Domino Application Development -- for each of the potential user types. Submit those description for review to your project champion.
With these profiles in place, you not only confirm your understanding of your solution user base, but also proactively address any scope creep specific to who will use the application.
What is the goal?
Once the audiences of the application are clarified, find out the goal of the sponsor of the project. A goal should be described clearly. Too brief of a goal description, such as "mobilize a given Notes database" is not adequate and can lead many open questions in application functions required. The goal here should be to address the stakeholders’ goals while ensuring that a user experience that lends itself to the target platforms is created.
Take an example, a personal address book focuses on the contact management features only but left out the other functions such as connection documents, locations, accounts, and so on might be an application with a Contact form that has over 33 input fields enabled by default. When sizing that down to a mobile device, the users will not be happy with the result. Usually, someone accessing a group Personal Address Book using their iPhone or BlackBerry would not care about a given contact's second personal email address.
There will be compromise, and the mobile user experience, when 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?
The ideal is "Everywhere". However, this is not an easy task. Consider the following:
- Not everyone has decent mobile device coverage. Think about the users who has the type of reception that could only result from lead-lined walls built for anti-kryptonian measures. WiFi can also be problematic. Your high speed internet access solution can fall flat if people receive connectivity errors when they click on that new icon of your application on their mobile devices. User perception is reality, and errors tell them simply that it does not work.
- Will you need offline or local storage capabilities? This depends on connectivity and coverage considerations and just how critical of a solution you are requested to develop.
- Is relying on a local data store that is potentially several minutes out of sync with the master database an issue? Does it pull down system-generated unique and numerically-sequenced IDs? Does it need to actively communicate to live systems to function? The answer highly depends on the type of application you are focussing on.
Once you have answered these questions, or at least brought them to the attention of the project champion who might not have considered that the warehouse staff could go "offline" when checking for real-time stocked inventory numbers for product substitutions. Can you grasp the architectural considerations required to even make this solution work?
When do they need it?
Understanding the delivery expectation for your application, and communicating about the solution performance potential (whether that is shorter or longer than the project champion assumes) will help everyone involved. It is about establishing a realist delivery expectation by breaking the expectations into these categories:
- Need to have
- Like to have
- Nice to have
Make sure that the "Need to have" category addresses the business critical goals that you previously established. You can set the time line for delivering the items in the "Like to have" categories based on the available resources. The "Nice to have" items receive the lowest priority.
Why would your users use it?
When answering the "why", the major consideration is "Does the individual user receive a value from using the application?
If the answer is no -- if the user has to do more work, if the process is now more complicated, or if this entire exercise is simply because someone told to do so, then the project is highly possible to be one of the ill-fated projects. Should this be the case, think seriously about innovation that helps the user to gain some value out of it; or if even this is not possible: question the project existence.
How can it be done?
The final question of "How" is the result of the developers' knowledge of the platform -- using XPages technology.
Parent topic: 5.0 User interface considerations