Introduction
Modern racing yachts are equipped with several sensors and monitors that provide a wealth of information to their crews. Sensed or computed data range& GPS-related information (position, speed, geographic course, position on a map), to boat-related information (magnetic heading, speed over water, heelng angle), and to wind and water information (direction and speed of apparent wind, water depth). Sail racing, even for club and amateur racing, has become more and more technological: for example, most of the crew members use polar diagrams of the boat which indicate, for several points of sailing and wind speeds, the optimal speed and heading that the boat is capable of. Such data is used to continuously fine tuning boat steering and sails trimming, to achive performances that go beyond the level that the average crew can reach based only on the “seats-of-the-pants” experience.
While large sailing teams (such as America’s Cup or Volvo Ocean Race teams) can rely on high tech solutions, either on-board or on-the-ground, this is not the case for teams with much smaller budgets. Less sophisticated IT applications to be used on board of yachts do exist, but software developers face a number of challenges because of the particular context in which these applications are used, namely sail racing.
The context is characterized by the fact that crew members, while racing, are under intense cognitive stress due to the need of making the right decision at the right time, performing corresponding actions with precision, and in strict coordination with other members. This can be complicated further by challenging weather or marine conditions, and the aggressive behavior of competitors (see Fig. 1).
For these reasons the user interface (UI) of such applications needs to be crafted with attention. The first law of usability of Steve Krug, “Don’t make me think” [Kru00], applies very well to this context: users, which often are non professional sailors and hence not professionally trained, cannot spend time and attention on guring out how to use the UI. They have to be fully concentrated on their sailing tasks and do not have extra cognitive bandwidth to spare. Therefore screens of the UI should present the minimal information that surce to the task at hand in order to avoid information overloading. Manual navigation between screens should be kept at the minimum to avoid distractions.
Furthermore, this kind of applications needs to provide support to different crew roles: the helmsman needs data to optimize boat steering, sail trimmers need data to fine tune sail shapes, and the tactician needs support for figuring out strategic opportunities.
Development of suitable applications is made even more complex when we consider that environmental conditions under which the applications are used are generally quite demanding: in addition to running on devices being reasonably waterproof, other requirements come from the need to cope with strong solar illumination at daytime, nighttime use that preserves night vision, low energy consumption especially for mobile devices.
In the market there are mobile applications that can be used in these situations. However, they have limitations. They require installation of software on one own’s devices, that sometimes might not be compatible. Different crew members need to install it on their own devices. Such target devices might not be appropriate for the context because they do not meet the requirements mentioned above. Furthermore, they are neither extensible nor customizable, in order to adapt to new or specific scenarios. As a consequence, the UI is often quite complex, as the application is not targeted to specific usages. Because if the generality of the application, context awareness is seldom implemented, in spite of the important role it can play in simplifying the UI. For example, context awareness can be exploited to limit the amount of shown information to only what is relevant to the specific context; context awareness can help in reducing controls made available in the UI to only what is needed at a giventime.
In this paper we present Oceanus, a hardware and software platform designed to explore and develop intelligent features aimed at supporting yacht racing crews. Oceanus encompasses a frontend system (Neptune) and a backend system (Argos); it is a web mobile application based on low cost hardware (Raspberry Pi and Amazon’s Kindle) and provides a UI that is tailored to a racing yacht crew. We show how and why Oceanus was developed in a certain way, how it satisfies most of the crucial requirements suggested above, how it features context awareness as a key to simplify the UI, and how adoption of a “LeanUX” and agile approach [Got13, Coh10] was beneficial to obtain a successful result.
The application has been developed by the Uniud Sailing Lab, and has been used in training and during club sailing races and more important championships (namely, the 2017 Italian Offshore Sail Race and the 2017 ORCWorlds Trieste).
The contribution of this work lies in showing how such an application can be developed as a client-server architecture, which has not been done before on low cost hardware. We show how this decoupling leads to benefits such as ability to use multiple clients for different crew members, ability to use different UI platforms and extendability of the platform. The frontend is a rich Internet application that can be modified independently from the server. The server can be easily extended with modules that exploit new sensors (such as Inertial Motion Units, IMUs), and can be developed in such a way that each sensor is monitored in a concurrent way, to avoid low latency issues due to the presence of sensors with differing response rate. We show how context awareness can be conceived as an intelligent way to simplify usage of the UI that becomes thus adaptive, based on inferences made on data provided by sensors. By design, we adopted the stance that context-aware features should be as reliable and useful; as possible to maximize acceptability of Oceanus by the crews. For this reason their design has been particularly conservative.
At this stage, Neptune is the first frontend included in Oceanus and it relies on a context-aware module which has been implemented server-side, in order to support clients that are as thin as possible. Finally we explain how the software development process was organized, especially in relation to the inability to frequently test the application in the actual situation for which it was conceived, namely during races.
If you want to know more read the PDF.