How Karoo helps you get around — and why it can be easy to lose the trail
The promise of superior GPS navigation is one that many riders have heard from the various brands that offer cycling computers. As cyclists ourselves, our assessment was that no one had yet properly delivered on this promise, which in large part, inspired our development of Karoo.
One basic question we had to ask was: what would “superior” navigation actually be? Does it mean navigational instructions are faultless, and that rerouting is instant? Does it mean the map design is the easiest to read? Does it mean the most intuitive and flexible route planning? Does it mean bike shops, cafés, and other relevant destinations are indicated on the map? If it all just “works” properly and gets us from one place to another, do the little details even matter?
Yes. Superior cycling navigation would wholly encompass all of these things. Laying out our approach to Karoo, and how we solve each of these problems, is something we’d like to do in time. But today, we want to simply showcase how the device renders the instructions for you when you’re using it for navigation — because this alone is a surprisingly intricate process.
Navigating Navigation
Karoo, and virtually any other device that provides navigational instructions, uses third-party, cloud-based software for things like mapping data, creating routes, and other functions. Why third-party? Several reasons. Developing our own software for these functions is technically possible, but would take far longer to do properly than would be economically feasible. It would make little sense, given that companies which specialize in these sorts of programs have (nearly) perfected them over many years and iterations.
Karoo’s earliest routing cue design
Some devices on the market use static, native data, which is easier from an architecture standpoint, but not always optimal for the user, because it’s not as efficient to update or integrate into other systems, such as non-native apps. Third-party programs are sometimes simply better and more efficient for these purposes.
Karoo’s Routes app relies on two of these third-party programs. They are sourced from two different vendors, because no single vendor was able to supply the variety of data and functions that our design for Karoo requires: fully integrated cycling navigation, training, and data management.
One of these programs is the mapping data client. The data client provides Karoo with “tiles” of mapping info. Each tile presents a tiny patch of the world, and each has dozens of points of data, usually called “layers” — elevation, terrain type, address info, whether there is a route on that tile, info about that route (directionality, type, etc.), how that tile is connected to others, and many more. Karoo takes all this raw data and, thanks to much design work, renders it in the colors, lines, and symbols you see on the screen.
The second program that Karoo’s Routes app uses is the routing client. The routing client takes location points provided by the user and figures out how to connect the two (or three, or four, or dozens). In a flurry of calculations, the routing client analyzes the many thousands of tiles that are implicated between the points, and determines the best route to connect them. This route optimization is a process that must be tailored to each product. Karoo’s has been designed specifically over many months to route the user based on either road or off-road cycling mapping data (which is still relatively limited globally, but constantly growing).
A simplified representation of Karoo’s navigation rendering process. (How does offline routing work? That’s a subject for a different day.)
The client/service relationship is far from plug-and-play. The adjoining and tailoring of compatible systems to one another takes months of dialogue and refinement. Many questions must be asked along the way, from the deeply technical to the nuanced and almost philosophical.
For example, how should road or trail grade be factored into routing or re-routing? Should Karoo avoid very steep terrain, even if it’s technically on the best route? If a steep grade is an option, should it preface this option as such for the user? If so, where do we draw the line between “standard” steepness and “severe” steepness? Do we risk insulting a customer by implying a route may be too steep for them? Should we allow them to determine for themselves what grade, and for what distance that grade, is considered “severe?” Can we quantify and systemize this? What would that matrix look like? What would the UI look like? Should we create road andoff-road grade matrices? Etc…
And these musings are limited to one topic: route grade. There are hundreds of others to consider. Answers to each question impact what we ask of our designers, data, and routing clients. They, in turn, respond with what’s technically possible or practical.
Some members of the software team doing their own navigating. Answering some questions often just exposes many more.
And from a programming standpoint, the process of creating the navigation experience on Karoo is different for routes created on the device, routes created on the Dashboard, and routes created on other services and then imported onto Karoo. Each route type is coded differently, and provides Karoo with variations in the types of data it needs to create a route. Implementing different route types may seem to involve indistinguishable processes from the user’s standpoint, but internally, Karoo may be doing very different tasks to render each. This is why some routes seem to generate with no issue, whereas other seemingly similar rides can occasionally generate error messages.
Karoo’s ability to render a consistent navigation experience for routes derived from virtually any source is an ambitious and unprecedented goal, even beyond the realm of cycling. It has presented a myriad of challenges for our team, but progress is constantly being made. The result – a seamless user experience – is always ever-closer to full realization.
The Margin(s) of Error
Of course, there are many junctions within this process in which something can go wrong.
The “Waiting for instruction” message some Karoo users were seeing, instead of turn-by-turn navigation, belied a deep web of potential issues. Photo by user Sjors Robben.
One example of this that impacted some Karoo users recently was a persistent error message reading simply “Waiting for instruction.” In the case of this issue, one particular step in Karoo’s routing process was the source of the device’s struggles.
Historically, when prompted to generate turn-by-turn (TbT) instructions, the routing client comes back with either an affirmative message or a negative message — the affirmative message being the typical “green light” that instructions can and will be generated, while the negative message would indicate that some sort of failure has occurred (invalid address, no internet connection, route provided by mapping client doesn’t correspond with routing client data, etc.).
Karoo’s issue was occurring specifically here. In response to some routing requests, rather than receiving an affirmative or negative message back from the routing client, Karoo was getting… nothing. Not a negative message, which Karoo could then render in the form of an error message that would explain the problem, but simply digital silence. With no response at all from the routing client, Karoo could only wait — hence, the “Waiting for instruction” message.
A simplified version of the failure that was occurring in Karoo as it tried to provide users with navigation cues. Weeks of communication with our routing partners, examination of code, and testing of countless variables helped us resolve the issue.
Identifying the origin of bugs in navigation rendering can be an especially time-consuming process. Often, it requires two large phases: Scrutinizing our work, and scrutinizing the work of our third-party program providers. Our ever-improving software QA (quality assurance) processes and our newly formed Advanced Testing Group help with the former, while the latter can only be addressed with copious communication, diligence, and patience. Our partners are, after all, making changes to their systems as often as we are. In short, there are many moving targets — and there are no “undo” buttons.
A more accurate illustration of Karoo’s routing process, although this diagram is still a simplified one. It portrays only one of many routing workflows the device must perform, depending on ride type and route source. Each section, and each connection between the sections, represents anywhere from dozens to tens of thousands of lines of code. By the time you read this, we’ll likely have already made some updates. Redactions used to protect proprietary process information.
Blazing a New Trail
The scope of the challenge of revolutionizing bicycle navigation is hard to overstate. Even juggernauts within the world of cycling tech have yet to master a comprehensive integration of routing, training, social connectivity, and optimized hardware.
Hammerhead’s goal is to prove that it is possible. Through thoughtful design, appropriate feedback, and constant refinement, the way we all imagine it should work, will work.
And thanks to the support of our community, we’re making it happen.
Thank you for reading along. More to come.
Cheers,
<H>