Assessing a maritime service website prototype in a ship bridge simulator: Navigatorsˇ experiences and perceptions of novel e-navigation solutions

The aim of this study was to assess proof of concept and usability of a maritime service website prototype in a full-mission ship bridge simulator through Swedish mariners’ experiences and perceptions. This test was part of the European Commission’s EfficienSea2 project for e-navigation. The prototype was intended as an aid to existing standard systems and methodologies for planning, executing and monitoring voyages. The study began with 5 days of simulator trials focused on today’s standard practices. This served as a baseline to compare to subsequent 4 days of simulator trials testing the prototype. For data collection, observations, video footage, interviews, and eye tracking were used. Data analysis included breaking apart the qualitative data to capture the perceptions of the participants, and a preliminary analysis of eye-tracking data as a complement. The results suggested that the prototype could be more suitable for a route planning stage, that the participants were familiar with similar existing solutions from other manufacturers, and that the contents of the tool would be most beneficial if integrated within the Electronic Chart Display and Information Systems (ECDIS). There is a pressing need for the novel solutions to be user needs-driven, integrated with the existing technologies, and standardized across the domain, and these processes must go hand-in-hand with accounting for all involved stakeholders, procedures, regulations, and training, as this will alter the course of shipping.


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, 2018Juhl 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.

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) 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.

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 NMs and NWs are provided separately today: NMs are commonly known already during voyage planning (through booklet PDFs) and NWs occur during navigation (transmitted via Navtex or VHF radio). In some cases, some NWs may already be found within the route planning software used by the mariners, depending on the software brand and version. MSIs are also not published immediately as occurred or reported. This information will go first through the designated authorities who may take a couple of hours processing and publishing this information to ships. In the new service, all MSIs (both NMs and NWs) are treated as one service. This is a standardized service for real-time promulgation and update, and for graphical portrayal of MSIs on electronic chart displays. A symbol is directly presented on the charts, indicating the geographical location of the event (see Fig. 1, purple dots). This is intended for route planning and navigation.

Route optimization
The mariners themselves may optimize their route plan according to own specifications or those of their shipping company, e.g., optimizing for fuel consumption or for weather using a calculation, a specific software for the purpose, or a purchased service from an external provider. The new service is standardized and easily accessible for acquiring a fuel-optimized route for a vessel. As of this moment, the route optimization algorithms require the navigators to lay out a route with waypoints before requesting an optimization. The algorithms will then take into account origin and destination, water resistance, fuel consumption according to length of voyage, and draught of the ship and shallow waters. The algorithms do not account for COLREGs a or traffic separation schemes, traffic density, local norms, weather (hydrographical and meteorological), distances to other ships, or maritime safety information. This is to be used during route planning.
No-go areas (under-keel clearance) Safety contours are specific depth contours set by the ECDIS. They demark the boundary between "safe water" and shallow water with an extra-wide isoline, and are used to trigger an alarm if the ship-within a time specified by the mariner-is going to cross the safety contour. The mariner sets the safeguard that the end product is user-friendly and usable (Costa 2016;Grech et al. 2008;ISO 2002ISO , 2010Maguire 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(ISO , 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 There is no standardized manner or platform to report to VTS centers across the globe. For each VTS, ships have to consult how to report (via e-mail, online form, VHF radio), when to report, as well as what to report and VHF radio channels to use. The new service proposes a way to standardize VTS reporting procedures for ships and delivery for VTS centers, making it possible to report to different VTS centers via a single platform, where standardized online forms for each VTS center are to be filled out and submitted directly on the BalticWeb, generating an automated and standardized e-mail that is received by the VTS. This is to be used mainly during route planning.
a COLREGs refer to anti-collision regulations (IMO 1972). This works similarly to road driving regulations in marking the waterways where ships are recommended to navigate. Ships going in opposite directions will then be separated by a line marked on the sea charts 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 (Hornbaek 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, criticalincident 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.

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.

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 inhouse 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).

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 betweensubjects 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.

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).

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).

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 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 prearranged 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.

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.
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 (email, 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.

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.

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).

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 The full extent of the simulator trials was observed (Patton 2002) by two human factors researchers, and hand-written notes were taken (Patton 2002). The think-aloud technique was encouraged throughout the sessions to get the participants' verbal descriptions of their tasks and decisions but without impacting their operations (Lewis 2014;Maguire 2001;Patton 2002;Stanton et al. 2013), and the observers could intervene to ask clarification questions with minimal impact to the exercises (Patton 2002).

Audio-visual data
During the familiarization, route planning and navigation exercises, screen-capturing software tools recorded the route planning software and the BalticWeb (with audio), the radars and the ECDIS (no audio). During navigation, a surveillance camera in the simulator room was also used (no audio).
Eye tracking During voyage planning and navigation, each participant of the control and experimental conditions wore a pair of eye-tracking glasses Tobii Pro Glasses 2. This equipment was used to (a) comparatively capture how the systems were utilized and time was divided among them, and how quickly certain services and functions could be found and used, (b) provide information on perceptual challenges and action barriers, and (c) record the participants' comments when interacting with the different systems and services. The glasses were streaming to software Imotions 6.4 for rendering and subsequent analyses.

Collective interviews
The collective debriefings (Patton 2002) after each exercise departed from a set of semi-structured questions regarding the advantages and disadvantages of the website and services, and how the participants experienced their usefulness during the two exercises. The questions also included discussing common procedures and systems, what was missing and how the new tool could or could not support that.
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.

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 systemthe ECDISwith everything"). Especially when less familiar with a geographical This calculation excluded two groups: one in which a Sound VTS operator was a participant, and one who was not certain whether it was mandatory to report to the Sound VTS and hence decided to execute the reporting via VHF radio during navigation and say they had submitted a report in advance even though they did not. Two of the three groups taken into this calculation chose to report via e-mail. Yet, the study was not prepared to mimic e-mail reporting, so it was assumed that the e-mails had been written, sent, and received. Had this really been mimicked, it may have taken more time. The remaining group chose to use the new online report via the Sound VTS' website and used less time than the other two groups (8.42 min). The online VTS report in use on the Sound VTS' website and the one in use on the BalticWeb were not at the time an exact replica of each other as the BalticWeb was under development, although they represented a similar concept and would have reached the Sound VTS center the same way b This calculation excluded one group that forgot to look for MSIs during the exercise. A participant for one of the remaining four groups misjudged the geographical location of the cable work for a similar real-life MSI that he knew of and this was not questioned or checked by his co-participant c One of the groups considered MSIs partially on the BalticWeb but the cable work remained unnoticed until the navigation exercise (where it was seen on the ECDIS). In one other group, the participant who identified the cable work on the BalticWeb failed to communicate it to his co-participant who only accidentally noticed it later on the ECDIS. The remaining two groups identified this MSI on the BalticWeb d One of the groups confused the missing buoy with another MSI of an unlit buoy and did not check the BalticWeb. The other groups identified the position on the ECDIS and one of them double-checked it on the BalticWeb e None of the groups used the BalticWeb at first, but two of them used it to double-check the MSI. One of the groups tried to see the drifting container on the BalticWeb but could not find it as they did not grasp that the BalticWeb interface required them to zoom in and out to see more or fewer MSIs. It was then assumed by the participants that the MSI was not there 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 alwaysdo 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.

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 eyetracking 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.

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 wellyou 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.

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).

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 cmchange 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 nonnavigable 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.

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.
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 onemodel-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.
Funding information The authors would like to thank the European Commission and its project EfficienSea2 [grant no. 636329] for financial support.
Open Access This article is distributed under the terms of the Creative Commons Attribution 4.0 International License (http://creativecommons.org/licenses/by/4.0/), which permits unrestricted use, distribution, and reproduction in any medium, provided you give appropriate credit to the original author(s) and the source, provide a link to the Creative Commons license, and indicate if changes were made.