User Interface (UI) Design for AM/FM Systems
Designing A User Interface for Modern AM/FM Applications
UI design is the process of analyzing both the functionality required by the application, and also
the processes involved in utilizing this functionality, and then providing a method for users to
access this functionality in a straightforward manner. For example, if wanting to design a UI to
enable users to plot a map, the first step would be to examine what functionality the UI would
have to provide. In this case, the UI would have to provide the ability to define an area to plot,
and then provide a method to plot this area. The next step would be to examine the actual
processes involved in creating the plot. These could involve accessing the area required;
defining a boundary for this area; choosing an appropriate plotter to use; and then plotting the
defined area. Using this information, a user interface can be designed which provides this
functionality, whilst also supporting the logical flow of the processes involved in the task.
A good user interface can be described as one that provides the following:
A unified look-and-feel
Consistent behavior to the users
A “unified Look and FeeZ” describes the concept of designing applications such that skills
developed in using one application are immediately transferable to another, different application.
A good example of this is applications developed for the Apple MacOS GUI. All applications
developed for this GUI share some common features (for example: window layout, menu layout)
which make the applications consistent. That is, a user who becomes proficient in using a word
processor will feel comfortable in using a spreadsheet, because the interfaces are very similar.
The keyword here is consistency. Applications that are designed to be consistent with a standard
that users are fhrniliar with, or that are designed to be consistent with another application that is
used on a regular basis, will inspire more confidence with the users, require less training and
support (as users will already be familiar with conducting simple operations), and will ultimately
be more successful than applications which are not designed to be consistent.
Consistency is relatively easy to achieve in office productivity applications, such as word
processors and spread sheets, where the user is effectively just editing or analyzing a document.
Geographic applications present a more difficult challenge, as the operations involved in these
applications don’t have a similar counterpart in many of the office productivity applications.
Geographical applications require the designers to often reach a compromise with their interface
design, designing interfaces that are consistent with other applications where possible, and which
offer a logical, consistent approach for operations that are unique to the application. For
example, to analyze an area, a boundary needs to be defined around the geographical data.
Although modern GUIS have no provision for the creation of a spatial area, they do have the
ability to define a boundary for graphical objects. This capability can be harnessed so that it
appears that a spatial area is being defined, when in fact only the boundary of a group of objects
is being defined. Because this action is not entirely different from actions that a user would be
expected to perform in other, non-Geographical applications, a degree of consistency is achieved.
Knowing the limitations of existing GUIS also helps in the design of UIS. By listing out all the
operations that a user might carry out whilst using an application, each operation can be analyzed
to see if the current GUI can support this operation. Otherwise the operation needs to be
modified such that it can be supported; or the GUI needs to be extended to handle this operation.
For example, most mapping software provides the capability to zoom in and out of the data
displayed. This sort of fimctionality is not supplied by most modern GUIS. To provide this
functionality, without changing the GUI, then a button or menu item can be supplied that
achieves the operation. This is what is most commonly seen in applications that support the
fimctionality. Alternatively, the operation can be performed by extending the GUI - the same
operation could be carried out by having the user use their mouse to fence (draw a boundary
around) the object and then select the object. This is not standard functionality for most GUIS,
but can be used as an extension to achieve the desired result.
Most AM/FM/GIS software supplied by vendors makes use of the built-in functionality supplied
by the host operating system. The design of UIS for AMIFM systems typically involves the
customization of the vendor’s software such that its functionality is more accessible by the users,
or such that it fits more consistently into the users’ environment.
Mercury Energy’s MERCCANO AM/FM system is an example of a system that customizes
vendor-supplied software. For MERCCANO, the AM/FM vendor’s software is Intergraph’s
FIL4M14E, and all the information is stored in a Microsoft SQL Server RDBMS. The
MERCCANO system’s scope was such that it would also store non-AM/FM data, such as
financial and asset data. This meant that we had to write our own application software to access
and manipulate this data. Because we wanted to provide a single, seamless environment to our
users, we decided to create our own UI for the system, and integrate the FRAMME sofiware into
this UI. We could see two types of UI that could be deployed: Static and Dynamic.
A Static user interface is the same every time a user accesses it. A Dynamic user interface
changes depending on the user, fimctionality required, or other factors. For example, a word
processor is an example of a static user interface - the interface fimctionality is the same for all
users; whereas Microsoft Windows NT is an example of a dynamic user interface because each
user can see a different set of functionality when they access the GUI.
Static user interfaces are usefid when all users need to share the same set of fimctionality in an
application. Dynamic user interfaces are useful when it is important to restrict certain operations
from some users, or when the amount of fimctionality available in an application isn’t necessary
for all users. In this case, dynamic user interfaces can actually simpli~ a GUI by providing a
user with only the functionality that they need to get their job done.
The decision to use one type of user interface over the other has to depend on both the user
group, and the functionality provided by the application. When security issues are involved (for
example, an operation that can only be performed by an authorized user), a dynamic user
interface can sometimes be the most feasible method of providing the appropriate level of
security.
Static user interfaces are relatively easy to design. The interface can be created at the time that
the application is developed, and deployed to all users.
Dynamic user interfaces provide more of a challenge. There area number of ways that they can
be designed, depending on the requirements. The most powerfi.d type of dynamic user interface
is one that is created entirely from scratch when it is requested - that is, no predefine user
interfaces exist for the application. Alternatively, dynamic user interfaces can be created that
have static components. Some examples are:
A number of static user interfaces can be designed, and then displayed to different users,
or in different situations. One advantage of this method is ease of design and
development - effectively, a number of sub-applications are being created that have
different interfaces. Conversely, one disadvantage is that in order to add new
functionality, the applications have to be modified, and then redeployed to the users.
The user interface can be created entirely from a central repository of rules, for
example a Database. Some of the advantages of this method are that it is possible to
give a different interface to each user and the user interfaces can be changed simply by
making a change in the central repository. The application doesn’t have to undergo
modification. One disadvantage is that this method increases the complexity of the
final applications, and hence the design process for the applications.
This latter approach for creating a dynamic user interface was used for the MERCCANO system,
as one of the requirements was that the MERCCANO system provide stringent security. The
system was designed to be deployed to a large number of users in the company, and would
provide a large amount of functionality. This fimctionality could be grouped together - for
example, field engineers would need to see maps indicating the location of plant, and also see
what this plant was connected to. They wouldn’t need the ability to modi~ plant, or place new
plant in the system.
As the MERCCANO system was designed to handle much more than just geographical
information, the system would have a lot of functionality, but not every user would need access
to this fimctionality. A static user interface approach was considered, but rejected because the
amount of functionality that would have to exist in one global user interface would make it
unusable, as it would provide too many options for a user.
A dynamic user interface consisting of a number of static interfaces was then considered.
Although it would reduce the complexity of the user interface seen by any one user, the idea was
rejected as it was too rigid. At the time the system was being designed, user roles in the
company were changing, and it was difficult (if not impossible) to tie fi.mctionality down to a
specific group of users.
