163
Supporting Consistent Design
and software components. Each component of the bridge affects navigators’ sensemaking and the totality of their user experience. Thus, the design of equipment can
be optimized for each of these components and ultimately extended to MBS integration of other equipment into a single working environment.
The OpenBridge Design Guideline is a component-oriented, prescriptive framework that seeks compatibility with existing prescriptive and goal-based regulations.
A core concept is that the OpenBridge Design Guideline is divided into a series of
independent components described through a user interface architecture ( Nordby,
Gernez & Mallam, 2019). The component structure draws upon the design guidelines as a hierarchy of elements that together make up OpenBridge-compatible user
interfaces. The user interface architecture includes components, such as palettes,
typography and layout patterns. Each element defined in the guideline follows current mandatory regulations to ensure that vendors following the OpenBridge Design
Guideline also adhere to industry standards.
When designing a new system, a developer may use every element from the
OpenBridge guideline or just a selection of them. In our perspective, designing for
consistency should be a l ong-term and gradual process. It is not a binary output
where a system is deemed “ consistent” or “ not consistent” but rather how many
and which consistent attributes a system possesses. In this perspective, we suggest that two different applications are marginally more consistent if they share
the same palettes, even though the rest of the applications may be completely
inconsistent.
Importantly, OpenBridge focuses on generic user interface components and some
core functions requiring consistency. Examples include a standard navigation menu
and alarm display that are shared across all bridge systems. However, a degree of
freedom is built into the OpenBridge Design Guideline in how to design the core
functions of an application. We argue these parts of a system are better served by
goal-based guidelines for generally “ acceptable” usability levels. Thus, developing
OpenBridge is a matter of balancing prescriptive generic user interface design with
goal-based functions. Different industry stakeholders will have varying needs and
apply the guideline partially or in its entirety ( see Table 10.1). For example, integrators and system developers that are dependent on each other have an immediate benefit of fully implementing the OpenBridge Design Guideline. OpenBridge-compatible
equipment can be sold to more ships without changes, and integrators can choose
between more equipment that is out- of- the-box ready to use without further need for
adaptation.
ECDIS CASE STUDY: APPLYING OPENBRIDGE
FOR ENHANCED SENSEMAKING
the DeSign ProceSS
In the following sections, we present how the OpenBridge Design Guideline was
used to design a version of an ECDIS user interface. The ECDIS design was developed in an iterative process that included analysis of prior art and in collaboration
with domain experts, including developers, equipment manufacturers and maritime
Supporting Consistent Design
and software components. Each component of the bridge affects navigators’ sensemaking and the totality of their user experience. Thus, the design of equipment can
be optimized for each of these components and ultimately extended to MBS integration of other equipment into a single working environment.
The OpenBridge Design Guideline is a component-oriented, prescriptive framework that seeks compatibility with existing prescriptive and goal-based regulations.
A core concept is that the OpenBridge Design Guideline is divided into a series of
independent components described through a user interface architecture ( Nordby,
Gernez & Mallam, 2019). The component structure draws upon the design guidelines as a hierarchy of elements that together make up OpenBridge-compatible user
interfaces. The user interface architecture includes components, such as palettes,
typography and layout patterns. Each element defined in the guideline follows current mandatory regulations to ensure that vendors following the OpenBridge Design
Guideline also adhere to industry standards.
When designing a new system, a developer may use every element from the
OpenBridge guideline or just a selection of them. In our perspective, designing for
consistency should be a l ong-term and gradual process. It is not a binary output
where a system is deemed “ consistent” or “ not consistent” but rather how many
and which consistent attributes a system possesses. In this perspective, we suggest that two different applications are marginally more consistent if they share
the same palettes, even though the rest of the applications may be completely
inconsistent.
Importantly, OpenBridge focuses on generic user interface components and some
core functions requiring consistency. Examples include a standard navigation menu
and alarm display that are shared across all bridge systems. However, a degree of
freedom is built into the OpenBridge Design Guideline in how to design the core
functions of an application. We argue these parts of a system are better served by
goal-based guidelines for generally “ acceptable” usability levels. Thus, developing
OpenBridge is a matter of balancing prescriptive generic user interface design with
goal-based functions. Different industry stakeholders will have varying needs and
apply the guideline partially or in its entirety ( see Table 10.1). For example, integrators and system developers that are dependent on each other have an immediate benefit of fully implementing the OpenBridge Design Guideline. OpenBridge-compatible
equipment can be sold to more ships without changes, and integrators can choose
between more equipment that is out- of- the-box ready to use without further need for
adaptation.
ECDIS CASE STUDY: APPLYING OPENBRIDGE
FOR ENHANCED SENSEMAKING
the DeSign ProceSS
In the following sections, we present how the OpenBridge Design Guideline was
used to design a version of an ECDIS user interface. The ECDIS design was developed in an iterative process that included analysis of prior art and in collaboration
with domain experts, including developers, equipment manufacturers and maritime