What if you don’t use the basics of UI and usability? The smaller the window the harder it is to get an overall view. It follows that the less space you have, the harder it is to be oriented to what the options are, and to which one you are looking at, at any point on time.

To overcome the challenge, you need to meet user expectations.

This means an intuitive overview of the options, also consistent for the variety of tasks in a particular application. Applications that navigate in different ways for each feature, without a consistent articulation, are very hard for users to learn. If, moreover, users handle many handheld applications this becomes a showstopper.

Once consistency of orientation has been achieved, the rest is understanding and accommodating exactly what the user expects. Let’s start with articulation.

How do you meet user expectations and how do you articulate consistently?

This depends on the application. A navigation device on a car is not the same as a reporting application for inspections on a ship. So, the world around the application needs to be understood. Let’s say, for example, that the world is about co-ordinating work on a ship. What are the ways that people expect to find features used in co-ordination? Grouped in ways that people naturally use on ships. There is a pattern, and this pattern is based on what shipping people are trying to achieve. There is a generic part to the grouping and a ship or job specific part. 

Every computer scientist may know that people have goals and that goals converge. That there are processes assigned to goals and these processes have steps. And that people are assigned steps in these processes to achieve common goals. Also, that many processes have common components that need to be accessed from many use cases. And that these processes are most often quite general and then break down into specific processes that have different outcomes although the processes are the same. Then, that there are many process variations, and each process can have a different path depending on the circumstances of the process.

But knowing this is not enough. The entire software platform has to articulate in a way to satisfy this. Otherwise, the navigation is inconsistent. For example, each user has a set of steps in several processes. A safety officer may report on a finding on deck and prepare an enclosed space entry form. The second officer does not approve the enclosed space entry form nor investigate the finding. However, unless the system articulates properly the safety officer may be confronted with options far beyond his responsibilities. If the system does not break down the processes so that navigation applies to the person using the device and not all other people as well, it will be impossible to use.

Similarly, if the system does not delineate the paths the user is expected to take in the process step and circumstances, the user is confronted with options that do not apply or withchoices at inopportune times, when something else is expected. These considerations need to apply to all features that come under a group of enterprise interconnected applications. The articulation for co-ordination software, and other breakdown that need to work in handheld devices, is different than for navigational devices on cars.

To conclude, there is a need to articulate related processes in a consistent way and thought out throughout the system and the system, to understand user expectations, must cover much more than the immediate exchange.