FormalPara Introduction

We find ourselves in a fast-changing era of global and exponential propagation of automation and information digitalization. In this historic and revolutionary context, the international shipping industry is no exception to the rule (Bhardwaj 2013), even if deployment and regulatory changes can be generally slow. Shipping, responsible for approximately 90% of all world trade (International Chamber of Shipping 2015; Stopford 2009), is a self-organizing network where each ship has been its own principal decision-maker and responsible for maintaining own safe operations. In other words, the domain has generally speaking been a loosely coupled (Orton and Weick 1990) sociotechnical system with distributed control (Hollnagel et al. 2006; Praetorius 2014) to each ship. Voyage planning and close monitoring of the voyage are crucial activities for all vessels to avoid risk and maintain safety, efficiency, and marine environmental protection (IMO 2000). Voyage planning is regulated by the International Maritime Organization’s (IMO) resolution A.893(21), and accordingly this is an activity that requires—among other guidelines—the collection of official information such as the charts and lists of lights, as well as of local information such as the traffic volumes likely to be encountered (IMO 2000). For vessels passing through the Vessel Traffic Service (VTS) areas, appropriate voyage planning and navigation are progressively more involving information exchange between ships and shore operators such as the VTS, seeing that decision making about anti-collision and anti-grounding strategies is based on communication between ships and shore operators, and on local information integration for preparation and prediction (de Vries 2015). Safe navigation and maneuvering of large vessels within VTS areas is an activity that requires coordination between the bridge officers of the ship, the VTS (Praetorius 2014), and often the coastal pilots (de Vries 2015). The stakeholders, who are mostly not co-located (Bruno and Lützhöft 2010), are now increasingly linked and aided by information communication technology devices (Bhardwaj 2013) (e.g., Electronic Chart Display and Information System (ECDIS), Automatic Identification System (AIS), Very High Frequency (VHF) radio, Navigational Telex (Navtex)).

Currently, the domain is suffering the demands and challenges for emission reduction, more information and interconnectivity between ships and shore (de Vries 2015; Graff 2009). These are usual motives to introduce new automation on ship bridges, yet new technology—rather than aid the operators at work—can create negative consequences or not be adopted if not perceived usable, useful and an added value (Chen and Huang 2016; Grech et al. 2008; Ma et al. 2016; Mallam et al. 2017; Schepers and Wetzels 2007).

1 e-Navigation

One of the shipping domain’s ongoing engagements is the e-Navigation program by the IMO, who recently approved an e-Navigation implementation strategy to be accomplished by 2019 (IMO 2014a). The main objective of this program is to collect, digitalize, process, integrate, harmonize, display, and exchange nautical information by electronic means across ships and shore to optimize the safety and efficiency of navigation and promote environmental protection (Graff 2009; Grech et al. 2008; IMO 2014a; Patraiko 2007). An example of digitalization onboard is the ECDIS, which made possible replacing the traditional paper charts with electronic nautical charts (ENC) (Graff 2009) and displaying a voyage and traffic on screens with real-time information, on ships and shore-based centers. In the meantime, many publications have circled around the e-Navigation concept, understanding operations, developing and testing new technologies (Amato et al. 2011; Baldauf et al. 2011; Hahn 2014; Jonas and Oltmann 2013; Kim et al. 2014; Lee et al. 2015; Motz et al. 2011; Patraiko 2007; Patraiko et al. 2010; Rødseth 2011; Weintrit 2011; Weintrit et al. 2007), including the concept of unmanned vessels and how it is proposed to contribute to e-Navigation principles/goals (Burmeister et al. 2014). In support of the e-Navigation initiative, the European commission project EfficienSea2 [http://efficiensea2.org/], within which this study was conducted, aims to identify, develop, test, and launch updated, smart, and open-source e-Navigation solutions that aim for standardization at a global level and that will help further comply with emission regulations and improve connectivity and information obtainability, reducing communication limitations and the risk of accidents (Billesø 2016; Danish Maritime Authority 2016, 2018; Juhl et al. 2016). Within this context, a testbed/demonstrator for the Baltic Sea—the BalticWeb—was developed consisting of a website prototype of navigational and administrative services intended to assist navigators and shore operators (bridge officers, pilots, and VTS operators) with administrative duties, navigational information retrieval, and decision making during route planning and navigation in the Baltic Sea. The testbed and services were tested as proof of concept and from a usability perspective, described in this paper.

2 Developing the BalticWeb testbed and maritime services

A number of service prototypes (see Table 1) was developed and implemented into the BalticWeb (see Fig. 1), and tested in this study. The point of the BalticWeb testbed was to serve as a unique and accessible platform where to find the services. The testbed and services tested here for the Baltic context are imagined for future deployment on a global, broader geographical scale. Conceptually, services would be made available by international certified service providers and accessed by all registered maritime stakeholders through a common Maritime Connectivity Platform (MCP)Footnote 1 (Danish Maritime Authority 2017b). This was intended to increase the opportunities for standardization across the shipping industry. Due to existing regulatory restrictions, it was not possible to integrate the tool in an existing ECDIS and instead a stand-alone 13-inch 360-degree touch-screen laptop/tablet that could be moved around the bridge for both route planning and navigation was used to display the BalticWeb.

Fig. 1
figure 1

BalticWeb homepage

Full size image
Table 1 Services embedded in the BalticWeb prototype assessed in this study (Danish Maritime Authority 2017a)
Full size table

3 Usability assessment

The e-Navigation program promotes a human-centered approach to design and development (IMO 2014b), being one of the ultimate goals to make “maritime navigation and communications more reliable and user friendly” (IMO 2014b, p.1). Patraiko et al. (2010) reinforced this message with regard to the importance of making e-Navigation “user needs led” rather than led by technology or regulation. The integration of human-centered design principles can help safeguard that the end product is user-friendly and usable (Costa 2016; Grech et al. 2008; ISO 2002, 2010; Maguire 2001). Usability is defined as the extent with which a product, service, or system can be used by a targeted user group in their context to achieve its desired goals with effectiveness, efficiency, and satisfaction (ISO 2002, 2010). The efforts of making a product usable can help avoid use problems and safety risks (Jordan 1998); it can promote increased productivity when users are able to concentrate on the task rather than on the complexity or ambiguity of the technology; reduce propensity for errors when dealing with well-designed interfaces and accessible information (Maguire 2001); and reduce training and support needs and costs by improved learnability while using the technology (ISO 2002; Maguire 2001; Norman 2013). The same benefits apply in the context of maritime technology (Costa 2016; Costa et al. 2015; Costa and Lützhöft 2014; Grech et al. 2008; Österman 2012).

The implementation of usability evaluation methods is about having subject-matter experts examine the usability-related aspects of a design/user interface (Hornbæk 2006; Jordan 1998; Lewis 2014; Nielsen and Mack 1994), fostering a human-centered design process (Holden et al. 2013; Jordan 1998; Maguire 2001). A lack of user involvement might implicate the risk that the new technology does not fit the user, the purpose and context of use in actual practice, that adaptation from the operator is required (Grech et al. 2008) and user acceptance is diminished (Norman 2013). This can be avoided by applying a series of usability methods that call for the active participation of users in the iterative design process, the thorough analysis of user and context requirements, the appropriate distribution of functions between technology and user, and the input of multiple experts (ISO 2002; Maguire 2001). Usability tests can resort to a number of methods for quantitative and qualitative data collection directly with the users to support the human-centered process. These can range from observations, performance-related measurements, critical-incident analyses, questionnaires, interviews, thinking aloud, and model-based approaches to expert evaluations (ISO 2002). Eye tracking has been considered an added value in this context, including testing in simulated environments, to complement traditional usability methods with objective data on visual attention, and to inform the design of improved interfaces (Poole and Ball 2006; Schiessl et al. 2003). There is no one optimal participant sample size that fits all usability tests, but in most cases the first five participants will already identify 80–85% of the usability issues (Lewis 2014; Turner et al. 2006). It is essential that human factors specialists are involved in this process (Costa 2016; Grech et al. 2008; ISO 2002; Man et al. 2018) along with the developers and users.

4 Aim of this study

The aim of this study was to assess proof of concept and usability of the maritime service website prototype BalticWeb in a full-mission ship bridge simulator at Chalmers University of Technology through Swedish mariners’ experiences and feedback by using a mixed-methods approach, to provide direction on ongoing and future e-Navigation solutions. The website prototype and its four services were tested for a given route planning and navigation exercise and scenario. As the website was meant as an aid to existing bridge systems, it was important to have a good comparative understanding of standard operating procedures and used systems, without the intervention of the prototype. Hence, this study involved a control/baseline and an experimental/intervention condition. It is important to note that this research was not intended as an evaluation of the different voyage plans or navigation performances of the participants.

5 Methods

5.1 Study design

This study had a quasi-experimental design (Shaughnessy and Zechmeister 1994) consisting of 5 days of a control/baseline condition and 4 days of an experimental/intervention condition. The control condition ran the test scenario utilizing solely existing bridge equipment and publications needed for voyage planning and navigation. The experimental condition had the same equipment complemented with a 360-degree touch-screen laptop/tablet for BalticWeb prototype usage through voyage planning and navigation. Before the study with test participants, a 2-day pilot study with two in-house experienced mariners involved in the project was performed as preparation (Lewis 2014) (at this time, only three of the services could be tested—the maritime safety information service, the no-go areas service, and the route optimization service).

5.2 Sample

The recruitment process could render a total of 18 participants: 10 for the control condition and 8 for the experimental condition, dependent on the participants’ own availability to participate. They were not selected at random. The purposeful sampling (Creswell and Clark 2011) consisted of a recruitment and triage process to ensure participants with the relevant background and experience were selected and distributed into the control and experimental conditions to balance out the groups and not pair up co-workers. Each applicant filled out in advance an individual informed consent form and a demographics form electronically. There were no repeated measures (a between-subjects design was used). On each day, two participants played the roles of captain and officer of the watch (OOW) for the voyage planning and navigation sessions. In-house bridge simulator instructors/managers played the role of other vessels as needed, and a local VTS operator was invited for the role of VTS during the simulations. When not available, the bridge simulator manager would also play the role of VTS operator.

The 18 test participants were active or recently active bridge officers of Swedish nationality, between 25 and 58 years of age (with a mean of 38 years). Among them, 13 were ship bridge personnel, 2 were pilots, 1 a VTS operator, 1 an in-house simulator instructor (not otherwise involved in the project), and 1 a nautical editor of notices to mariners. Of the participants, 1 had less than a year of seagoing experience and of navigational experience, otherwise they ranged from 1 to 28 or more years of navigational experience (with a mean range of 7–9 years). Regarding ranks, there were 6 captains, 6 first mates, 5-s mates, and 1 cadet. Of the participants, 83.3% reported to have had prior experience passing through the Sound VTS area between Sweden and Denmark, although none of them claimed to be extremely familiar with the area.

5.3 Test scenario

The test scenario was planned for the strait between Helsingborg Sweden and Helsingør Denmark, passing through the Sound VTS area. The simulated ship was a Ro-Ro passenger ferry with 182.6 m of length, 25.5 m of beam (displacement 21,104,0 tons), a draught of 7 m even keel, and maximum speed of 21 knots. The simulated day was April 21st of 2017 (day time navigation scenario), with medium dense traffic and typical weather conditions (good weather, no tides).

5.3.1 Briefing and familiarization sessions

For both test conditions, a short briefing was held every morning, complemented with a familiarization session with the BalticWeb and services for the experimental condition, where the participants were given a chance to try it out following a number of short predefined exercises (Stanton et al. 2013).

5.3.2 Voyage planning exercise

For both conditions, the participants were instructed to plan a route from anchoring area Charlie/Bravo outside Gothenburg Sweden to berth Basen IV of Gdynia Poland (see Fig. 2), with estimated time of departure 21st of April of 2017 at 08:30/45 UTC, and estimated time of arrival 22nd of April of 2017 at 08:00 UTC. How to plan the voyage and choice of route through the Sound VTS area was up to the participants based on their knowledge and information available and used. The voyage planning session was allocated approximately two and a half hours to complete.

Fig. 2
figure 2

Complete route Gothenburg-Gdynia, going through the strait between Sweden and Denmark, for both control and experimental conditions (chart screenshot authorized by TRANSAS)

Full size image

The groups used the available route planning software on one desktop computer, the TRANSAS Marine Navi-Planner Software, otherwise used at the university for student and professional training. Since it could not be assumed that the participants were used to this particular brand and version, the bridge simulator manager accompanied them through the route planning exercise to provide hands-on support with regard to the technicalities of the software as needed. The groups also had access to printed resources, such as the Pilot Card, Wheel House Poster, applicable Admiralty Sailing Directions, Tide Tables, List of Lights, Radio Stations, Pilots, VTS and Ports, Sound VTS pdf, and the weather forecast for the simulated day, notices to mariners from Sweden and Denmark, Navtex (both printed and on ECDIS on a separate screen) that included cable work west of the island of Ven, and Danish guidelines for navigation in their area. Paper and pencil and internet access were also provided. The experimental condition had the additional 360-degree touch-screen laptop/tablet for the BalticWeb (see Fig. 3). In this case, the participants were requested to test the route optimization service on the BalticWeb by uploading their original route onto the BalticWeb and requesting the optimization. After receiving the optimized version of their route (a pre-arranged default optimized route was used to mimic the real process), the participants chose which one they preferred to proceed with, and continued to adjust parameters as needed. They were also requested to test the VTS reporting service if/when they wanted to do the reporting activity. The Maritime Safety Information (MSI) and no-go areas services could be used at will.

Fig. 3
figure 3

A participant group of the experimental condition running the voyage planning exercise, with the voyage planning software, BalticWeb laptop, printed resources and an additional ECDIS screen with integrated Navtex

Full size image

5.3.3 Navigation exercise

The groups were manning one bridge in the Full Mission Bridge Simulator with a cylindrical visual projection of 270° and modern integrated bridge equipment, such as Multi-Functional Displays (MFD), Radar/ARPA, ECDIS, conning, autopilot, etc. The groups could bring the printed or written papers onto the bridge as desired. The experimental condition had access to the BalticWeb laptop (see Fig. 4). During navigation, the VTS operator also had with him another 360-degree touch-screen laptop/tablet with the BalticWeb in the instructor room as the purpose of the EfficienSea2 project is to provide all relevant stakeholders access to the same information.

Fig. 4
figure 4

A participant group of the experimental condition during the navigation exercise, with two conning stations and one BalticWeb laptop

Full size image

Due to time constraints, a section of the planned voyage was chosen to be executed in the navigation session, with the duration of approximately 2 h. With the start of the simulator exercise at 13:15 UTC simulator time, the vessel was expected to enter the Sound VTS area at 13:30 and report. Figure 5 specifies the approximate VTS reporting location as well as MSIs created for the test scenario to see how the participants would work with this information and if they would find use in the MSI service of the BalticWeb. Regardless of the VTS reporting method used during voyage planning (e-mail, online report), a VHF radio call was mandatory when entering the Sound VTS area; hence, this was performed by the participants as per Fig. 5. Of the MSIs (cable work, missing buoy, and drifting container), the navigation exercise only allowed time for the participants to pass the missing buoy location (announced with printed Navtex at the start of the navigation session), and see the cable work (already known since the route planning exercise) and vessel coming ahead on the ECDIS depending on speed, whereas it did not allow time to pass the drifting container (announced via VHF radio warning during navigation session). Nevertheless, the intention with the cable work and drifting container was that they would still need to plan ahead and integrate them in their voyage.

Fig. 5
figure 5

Navigation scenario with VTS reporting and MSIs’ approximate locations (chart screenshot authorized by TRANSAS)

Full size image

5.4 Assessment protocol and data collection

A mixed-methods approach to data collection and analysis (Creswell 2014; Creswell and Clark 2011) was chosen, where qualitative and quantitative (eye-tracking) data complemented each other (see Table 2). The assessment protocol of the control condition was divided into four stages: (1) the voyage planning exercise, (2) a collective interview session, (3) the navigation exercise, and (4) a final collective interview session. For the experimental condition, there was the additional BalticWeb familiarization session starting off the day.

Table 2 Data collection methods used in both test conditions
Full size table

5.5 Data analysis

The data collection methods produced extensive audio-visual material (Patton 2002; Silverman 2014) from which detailed notes were taken and participant statements highlighted. Along with the hand-written field notes, the data were analyzed with memos and clustered to grasp and describe how the participants performed the activities and perceived each service, as well as more general aspects of the BalticWeb and e-navigation (Creswell and Poth 2018; Patton 2002). The eye-tracking data were analyzed using the appropriate software to measure time intervals and consolidated with the qualitative data to enable more complete meta-inferences (Creswell and Clark 2011).

6 Results

6.1 Eye tracking

The eye-tracking data indicated, as per Table 3, that the BalticWeb was given more use during a voyage planning stage than a voyage execution and monitoring stage, as was expected by the participants (“It’s more a planning tool”; “It will be too much to go to the computer and check that from time to time (…) I wouldn’t use it when I’m navigating”). VTS reporting activities during route planning and navigation were reduced by approximately half when using the VTS online report on the BalticWeb. The MSI service, on the other hand, did not significantly increase efficiency compared to typical MSI activities and identification when planning. Yet, seeing MSI symbols directly on the charts and along the voyage was perceived positively by the participants (“It’s always good to see it on a map, the navigational warnings. Then you can forget a lot of them because you know you will not go there anyway”). During navigation, new MSI coordinates were always first looked up on the ECDIS before checking the BalticWeb if at all (the BalticWeb was used to double-check in three out of eight cases) (“That would be too much to go around and monitor and check. As much input into the ECDIS is actually the best way”) and Navtex reception and coordination was frequently interrupted by competing responsibilities linked to traffic monitoring and maneuvering. Hence, in this case, the eye-tracking values presented in Table 3 are not conclusive in comparing the test conditions.

Table 3 Mean time spent (minutes) on activities during planning and navigation by the control and experimental groups
Full size table

6.2 Participants’ perceptions

There was a general preference for having new services/functions IMO-approved and integrated within the existing ECDIS compared to adding more screens and devices to the bridge (“As much into the ECDIS as possible”; “We would prefer that there were only one system – the ECDIS – with everything”). Especially when less familiar with a geographical area, having integrated information in one place was suggested to be the most convenient option rather than managing multiple information sources (“You can’t have that many sources”). In this context, a participant stated that the BalticWeb “will maybe be even one more source to find the information. There is actually a risk today that you have the information in too many ways”. It was, however, emphasized that too much ECDIS screen clutter would not be helpful and could represent a safety concern; hence, it is important to be able to separate functions for route planning from those for navigation (“For me, it’s always – do I need it for navigation or for planning?”) or to generally be able to turn overlays on and off to simplify the screen as is done in the existing ECDIS today. Not being IMO-approved compromised the reliability of the BalticWeb even when introduced and recognized as only an aid to existing systems, since it would signify not being able to base decisions solely on it (“Will it be some kind of certified system? Are we actually allowed and can use this one? Because they sometimes can be very picky about where we find our sources”; “You have to check official sources”; “Not approved is a limitation to use it as a decision-making tool”). Being dependent on functioning internet was also deemed problematic as this is a common limitation onboard.

6.2.1 MSI service

The MSI service on the BalticWeb was prominent (“We used it [the BalticWeb] more like a Navtex almost”) and seeing the MSI symbols immediately on the chart was expected by the participants to be a benefit regarding “Time!” (even though the eye-tracking results did not conclusively corroborate this). Nonetheless, having the MSI symbols on the charts on the BalticWeb did not keep the participants from having to integrate the same information into their voyage on the ECDIS. Although the MSI symbol function is available on some ECDIS systems, it is not available or known to everyone (“Where you can see the map with the warnings is an incredible option… I’d never seen anything like this!”). The ECDIS brand and version available in this simulator study included a Navtex function presented as both text and chart symbol, yet the symbols were not always noticed by the participants, since they were not expected, even when manually inserting the coordinates for an MSI that was already integrated. It was observed that the MSIs were not always communicated between participants, and that transferring MSI information into the ECDIS could cause confusion. For example, during baseline planning, a participant assumed the geographical position of the cable work was the same as of a similar recent real-life MSI, but these were in fact different MSIs. During intervention navigation, a group wrongly assumed an unlit buoy MSI on the BalticWeb was the same as the received paper Navtex of a missing buoy, which thereby indicates that adding the BalticWeb as another source of MSI information did not help to enhance situational awareness in this case.

6.2.2 VTS reporting service

VTS reporting information was something commonly found outside the route planning software, using sources such as the Admiralty books, Swedish Maritime Authority website, or Sound VTS website. The participants were also provided with the printed Sound VTS pdf taken from the Sound VTS website. Reporting information was repeated through these sources but not necessarily consistent or updated everywhere. The written information available did not specify how much time in advance to report and there seemed to be no full agreement on this among the participants. It was not realized by all participants that the Sound VTS had created templates for the e-mail and online reporting. This triggered mariners to talk about creating their own e-mail or calling the VHF radio instead. Finding the reporting line or the buoy Disken (buoy which mariners were required to report going east or west of) on the maps, speed restrictions in the area, or whether reporting leaving Gothenburg or exiting the VTS area was mandatory was not always straightforward either. The participants would always type in a note in the planning software indicating the reporting point and what VHF radio channels to call on, but with regard to what to report they commonly preferred to write it down on paper, although some participants reported that in a real-life case they would have printed out this list and highlighted the main reporting details. Even after taking notes during voyage planning, confusion remained during navigation as to what VHF radio channel to use, reporting details were still forgotten (e.g., air draught), and there was even ambivalence about how to refer to the VTS over the radio—Sound VTS or Sound Traffic.

The participants found that having an online reporting template could spare them from looking elsewhere for what they were required to report. The online report was preferred compared to the e-mail template, as the online report should have the receiver’s address and contents always updated from the source. Although a participant suggested that reporting via VHF radio can have the advantage that everyone is informed and gets an overview of the situation (“I would still like to hear them on the VHF, because that gives me a quick picture of who they are (…) The level of competence (…) If everybody were following regulations, there would never be any collisions, but there are”), the participants generally agreed that it was important to shorten VHF radio calls (“Usually when you enter these areas, it’s dense traffic, and you’re going to call up and answer all these questions… You lose the sight of the navigation, and that’s a very dangerous time”).

Participants mentioned having to report (mandatory and voluntary) to a number of authorities (e.g., VTS, ports, pilots, Amber US coast guard) in the same voyage. Due to this issue, VTS reporting was discussed for its standardization potential (“The thing is it’s different systems all over the world. Most ports you have to send in a lot of e-mail reports before you go there, and some VTS areas as well – you send e-mails. And then you go to another system and they have an online-based system, so you log into the webpage, like the whole Norway you have to upload your route and everything before you go into coastal navigation in Norway. The problem is there is no standard. Every place has their own system. And when a new system is coming they just add it (...) you end up sending like ten e-mails (...) They’re just stacking up. It doesn’t get any easier”; “If you could get one system for all, that would be fantastic!”). This was not only discussed with regard to the potential of having worldwide VTS reporting templates be as homogenized as possible and found on the same platform, but also of having automated options (e.g., pre-filled with AIS information) or sharing a route with all authorities to reduce the workload and redundancy of reports to different authorities.

6.2.3 Route optimization service

The route optimization service was criticized for not accounting for COLREGs or routing recommendations/guidelines (“Practically, it’s not usable”; “My captain would never allow us to go here on Bornholm”; “They don’t even use the lane, they go outside the lane, and that’s…you should never do that!”; “You have to follow the TSS”). One group adopted the optimized route early in the planning process and refined it to follow the traffic separation schemes (TSS), two groups had gone too far into planning their original routes to adopt the optimized route but still took advice from it and managed to shorten their routes and save fuel, and the remaining group rejected the optimized route. Another critique that did not promote adoption was the fact that the mariners needed to delineate waypoints first for the algorithm to calculate the shortest distance for that voyage. The mariners felt that this service should have been possible as an optimal route maker rather than an optimizer of an existing voyage with just inserting origin and destination and ship characteristics. As with VTS reporting, route sharing was seen as an opportunity in uploading a voyage to send for optimization, which could as well be used to demonstrate the route on the BalticWeb for other ship and shore users to see (see also Costa et al. 2018b).

6.2.4 No-go area service

The no-go area service was not fully matured for this study, although the website provided an animation to exemplify this concept service. After the familiarization session, this was tested by only one group. Although when referring to a location with tides, currents, winds, or bad visibility having weather-dynamic safety contours was deemed interesting, for a voyage planning purpose having dynamic safety contours based on a weather forecast was considered unreliable, as some locations will have shifted weather conditions by the time of navigation (“(…) taking into account changes in water depth due to high and low pressure is on the edge of not really professional (…) Usually if you make a route plan, open waters should have under-keel clearance on the draught plus 30% - and then a 10 cm-change due to high or low pressure, I wouldn’t like to sail on that because your margin of error is too small (…) I have to be able to trust my plan whether or not it’s windy (…) or high or low pressure”).

The participants were familiar with the term no-go areas or no-go zones, used widely in the maritime domain (see for example The Nautical Institute 2017). However, some participants interpreted the term no-go areas/zones as non-navigable waters considering draught and safety depth, whereas some mentioned MSIs or restricted areas as temporary no-go areas (e.g., military exercise areas, regattas, environmentally protected sulfur emission control areas (SECAs)). There was also an understanding of static no-go areas as those that remain the same for a particular ship with a particular draught, and dynamic no-go areas as those that may change over time and hence need to be rechecked and updated into the system for every single voyage and during navigation. Navtex, navigational warnings (NWs), notices to mariners (NMs), and MSIs were also common terminology in the domain, and these terms refer to the same type of information. Although the differences may be known and participants emphasized the importance of distinguishing navigational warnings from notices to mariners in the symbolism used on the BalticWeb, the nomenclature was often used interchangeably, and the acronym MSI for maritime safety information was not recognized by one of the participants when presented as a chart symbol on the ECDIS screen.

7 Discussion

The BalticWeb was intended as an aid to existing standard systems and methodologies, and proved comparably more relevant during planning than navigation. In most cases, the participants pointed out that they had previously heard of or had experience with similar services/concepts to those tested in this study. Such services/concepts are, however, not yet deployed or widespread in the maritime domain. There is an opportunity with the automated and standardized reporting functions (see also Burmeister et al. 2014; Patraiko et al. 2010), and with the suggestions to consider route sharing with other ships and shore-based organizations (see also Costa et al. 2018b). This should help to reduce voyage planning workload and redundancy, and minimize VHF radio communications when navigators need to turn their full attention to navigation. There is also an opportunity to automate and optimize voyage plans according to numerous parameters. With regard to the MSI service, there is instead a chance that it may add to the workload rather than help reduce it, as it was not IMO-approved or integrated with existing systems, and added to the existing number of MSI information sources. The participants could not use this service as a stand-alone decision-support tool and still needed to rely on existing MSI information sources simultaneously, and integrate MSI coordinates into the existing ECDIS. A standardized simplified ECDIS mode like the proposed S-Mode (see also Bhardwaj 2013; Graff 2009; Patraiko 2007; Patraiko et al. 2010) and dynamic weather and tidal contours (see also Graff 2009) should be further looked into.

Even though the creation of an open-source BalticWeb platform for web-based services may be an important step towards standardization and e-Navigation, the participants’ experiences and feedback defended that similar solutions may not be taken full advantage of or be as useful without IMO approval and integration within the existing ECDIS. The results suggest that the participants fear that systems and information sources are instead becoming too many and too spread out, and that they are thus forced to play catch-up in this digitalization transitional phase. Information, especially in route planning activities, proved to be compartmentalized, repeated in different sources, not always consistent, and cumbersome to access (see also Costa et al. 2018b), even if the situation has reportedly improved since the Admiralty books have been made available in electronic format (which were not available in this study). Alike the participants’ opinion to integrate the new BalticWeb services within the ECDIS, Porathe et al. (2014) proposed having a more advanced ECDIS and not adding yet another display to the bridge. Integration within ECDIS can be considered in line with the principles of the e-Navigation initiative to collect, integrate, and standardize digital solutions across the domain. The better use of existing and novel capabilities for real-time information delivery across the industry and the convergence of information sources into one platform should facilitate information gathering, exchange and decision making, and provide a baseline to geographically distributed stakeholders (Costa et al. 2018b; Patraiko et al. 2010). Yet, interface usability is not guaranteed and human factors considerations need further attention on how to best bring information together into one system.

Information overload, operator overreliance and resistance to the integration of new technologies, and automation in the work environment are some of the potential threats that e-Navigation must avoid in order to be useful (Grech et al. 2008). Important human factors requirements for this are to (a) ensure stakeholder involvement in the design of e-Navigation technologies and that operator needs are driving the development; (b) design intuitive and usable systems; (c) consider aspects of how the technology will influence skills, career development, and job satisfaction; (d) integrate e-Navigation tools with existing equipment and procedures; and (e) standardize, especially considering the plurality of manufacturers and suppliers (Grech et al. 2008). The increased acceptance and adoption of new technologies are influenced by factors such as usability (Costa 2016; Grech et al. 2008; Maguire 2001; Mallam et al. 2017). Yet, usability is mediated by attitude (Chen and Huang 2016; Mallam et al. 2017) and the participants did not feel comfortable to have to use yet one more tool or base decisions on a tool that was not IMO-approved. Thus, in order to increase the likelihood of accepting similar tools, the navigators need some form of organizational support or directive. This is supported by Ma et al. (2016) who identified that facilitating conditions, such as having the support of organizational and technical infrastructures have an impact on actual usage behavior. In this sense, communication about the newly introduced technology, like manuals, training, and technical support are also important to increase proficiency and acceptance (Grech et al. 2008; Schepers and Wetzels 2007), especially considering the growing complexity and information flow of bridge automation, such as with the ECDIS (Costa et al. 2018b; Graff 2009). It is also relevant to consider the impact of the “ironies of automation” in new e-Navigation developments, and how the operators may potentially be affected negatively being left with only the monitoring tasks that the machines do not do (Bainbridge 1987; Grech et al. 2008) or being led to automation-induced errors (Bhardwaj 2013; Lützhöft and Dekker 2002).

The expansion of technology is tied with the notion of societal progress and development (Bhardwaj 2013), and Information Technology (IT) service providers may naturally perceive that digitalization brings value to the maritime domain. Yet, it does not necessarily advance safety, especially if it continues to perpetuate the technology-driven mindset that has been reported to dominate IT applications in the sector (Man et al. 2018). Safety enhancement may undoubtedly take advantage of cutting-edge technologies, but new maritime technology for the sake of mere novelty and modernization should not be developed and deployed without the fundamental acknowledgement of the human element and operator needs (Patraiko 2007; Patraiko et al. 2010), especially in safety-critical work environments where the workers are not generally offered alternatives to the available systems (Jordan 1998).

It is expected that the implementation of new e-Navigation solutions in the maritime industry will have an impact on human decision making and behavioral processes on the bridge (e.g., some tasks and actions will be replaced, others changed or adjusted, while some will remain unmodified), and on ship and shore stakeholder roles and communication networks (Bhardwaj 2013). For instance, the VTS might gain capabilities in their role, or in some ways become redundant in the current way of assisting and coordinating ships from ashore (Costa et al. 2018b; van Westrenen and Praetorius 2012). Hence, it is important to rethink procedures, education, and training programs, policies and regulations, and together with the further development and implementation of new e-Navigation technology (Costa et al. 2018a, b; de Vries 2017) “in a holistic and systematic manner” (Graff 2009, p.181). In this context, and from a human-centered perspective promoted in the e-Navigation strategy, the whole human element spectrum needs to be considered.

8 Conclusions

In this quasi-experimental study, a BalticWeb prototype and its four services were tested in a simulated route planning and navigation exercise with navigators. It is of relevance for future studies to investigate what should be standardized and how, as well as capture the empirical experiences and perceptions of—and the interaction dynamics between—bridge officers, pilots, VTS operators, and other relevant stakeholders. This study was intended as proof of concept and a usability assessment to provide direction on ongoing and future e-Navigation solutions according to user responses. The results suggested that technical systems and sources may be becoming too many and too spread out, and that the operators, educators, authorities, and regulators need to play catch-up in this transitional phase. Especially in this safety-critical domain, there is a need to simplify and bring the new and the existing solutions together towards a one-model-fits-all that considers the human element. From a human-centered perspective promoted in the e-Navigation strategy, adapting everything a posteriori around the technology may be leading the maritime domain into a path where it needs to quickly find a way to adapt to technology rather than having the time to identify the industry’s and operators’ needs and have the technology adapted to them.