Four screens between a saved place and turn-by-turn navigation

The choice hidden behind a destination tap

A driver opens a recent place and sees two ways to get there. One route is quicker; the other is described as less busy. Should tapping the place start the fastest route, or should the driver choose first? That decision changes the meaning of every subsequent control, including Back.

Google's sample flow reserves a screen for choosing the route before guidance begins. It uses four views: a category menu, a place list, route alternatives and active navigation. [1] The useful design question is whether a person who has chosen a destination has also agreed to a particular route. In this example, those are separate commitments.

For a familiar commute, an extra choice may add little value. For an unfamiliar destination, a driver may prefer a different road despite a longer estimate. A product team therefore needs to decide which tasks justify route comparison. Removing the comparison screen is a product decision, not just a way to make a flow diagram shorter.

1. Choose a collection, before choosing a place

The first image offers collections rather than destinations. A map occupies the rest of the display, but it cannot yet explain which destination the driver will choose. This is orientation, not route confirmation.

That distinction matters when comparing a menu-led design with a nearby-results design. Collections favour someone returning to a known place. Nearby results favour someone who needs an option now. Neither can be called faster without defining the task. Counting the number of visible rows misses the more consequential choice: what knowledge does the interface expect the driver to bring?

In a charging search, for example, a familiar station and a suitable station are not necessarily the same thing. That is an application scenario, not a claim about the sample's charging data. A recents shortcut would still need a policy for unavailable or incompatible results.

2. Preserve the place, not its row number

The second image puts availability beside the choices. That information can affect whether a location is worth selecting, but a static screen does not tell us whether an unavailable item is disabled, opens details, or remains navigable. Those behaviours cannot be inferred from text colour or a label.

Consider a refresh that moves the second place to the top while the driver is opening it. A selection stored as 'row 2' could now refer to a different place. A stable place identifier avoids that ambiguity: use it for the selected row, the map marker and the destination passed to route calculation. This is a recommended implementation rule, not a defect demonstrated by the image.

Android's Map + Content guidance recommends corresponding map markers for listed places and route highlighting after a selection. [2] The practical consequence is to update the list and map from the same selected object. Two individually plausible views can otherwise disagree about the destination.

3. Make the route commitment explicit

At route selection, the driver is choosing how to reach an already selected place. Putting the action beside the route helps associate the commitment with that alternative. A single global action would need another equally clear indication of which route it will start.

The important implementation boundary is the Navigate action. Before it, an alternative is under consideration. After a successful start, one route should own guidance. Merely changing a map highlight must not silently change the committed route. If the route engine rejects or replaces the candidate, the interface needs to show that outcome instead of assuming that a button press succeeded.

A second asynchronous race is possible here. The driver selects a different destination before an earlier route request finishes. A late response for the old place must not replace the new preview. Associate results with both the destination and the request that produced them. The exact mechanism depends on the app, but the user-facing requirement is concrete: route choices must still belong to the place named on screen.

4. Guidance changes what cancellation means

Once guidance is active, the driver needs an instruction rather than another catalogue of places. In the sample, the next manoeuvre takes the prominent position previously used for browsing. [1] A review should now distinguish returning to a browsing view from stopping the trip. Those actions may coexist, but they should not be represented as the same state change.

There is also an evidence trap. The route-choice image shows estimates of 10 and 6 minutes; this guidance image shows 1 hour 55 minutes. These are educational illustrations, not a reliable recording of a single journey. They cannot demonstrate that the selected alternative produced the displayed arrival estimate, that traffic changed, or that a particular route engine made an error.

That limitation does not make the example useless. It tells us what we can compare: the role of the controls and the sequence of decisions. Measured task time, glance duration and route consistency would require a recording or an instrumented test on a specified build.

Why the same layout can consume another step

Android separates template quota from the number of Screen objects. Sending additional templates from one Screen can consume the quota; reusing a screen instance is not an exemption. The host also gives particular templates task-ending semantics. NavigationTemplate can reset the count because guidance begins a new task. [4]

The sample's published counts are 1, 2, 3 and then 1 for navigation. [1] Treat them as template-task accounting, not as a measurement of taps or seconds. In particular, opening the place list introduces different content even though the map-and-list composition stays familiar.

Refresh rules depend on the template and on Adaptive task limits. The latter changes which updates qualify, and availability varies by vehicle and platform context. [3] A design review that simply labels every list update 'refresh' can therefore underestimate the task budget.

The distinction becomes useful when somebody proposes another filter screen or a mandatory confirmation. Check where that screen enters the task, whether it adds a template and what type would land at the limit. Do not approve the flow because its visual design reuses the previous page.

Back should restore a decision, not just a screen

The library supplies a screen stack and a standard Back action that pops it. [5] That solves a navigation mechanism. It does not define the product's policy for retaining a filter, a map viewport or a selected destination.

An application can restore the correct screen class and still make the driver start over. In the route-selection example, returning to the place list should preserve enough context to compare another place without reconstructing the original search. Our recommended default is to retain the collection and search context, keep any still-valid place selection, and make changed availability visible.

The library also places requirements on the template returned after a pop: its type must match what that screen last returned. [4] Product state restoration and valid template restoration need to be tested together, especially if one screen can return several kinds of content.

Updating the data model alone is not a rendered update. Screen.invalidate requests another template, which the host obtains through onGetTemplate. [6] A stale route result can therefore cause trouble even if the visible screen appears unchanged. Cancel or disregard obsolete requests before allowing them to update the state used by the next template.

A concrete failure review

The following cases are proposed tests derived from the state transitions above, not failures observed in Google's sample.

Where this leaves the product decision

For this task, I would retain an explicit route choice when meaningful alternatives exist, and make the accepted route a separate state from the destination being examined. I would test return-to-list and late route responses before treating the happy-path screenshots as a finished interaction.

That recommendation is about this decision structure, not a universal demand for four screens. A product with one suitable route may combine steps; a point-of-interest app may hand navigation to another application. The comparison still needs to identify where the user commits, what remains reversible and how the system reports success.

The sample does not establish which design is safest or quickest. It does expose a review mistake that screenshots alone invite: confusing a familiar-looking map with continuity of the driver's decision. The evidence to request from a working implementation is the selected place, the candidate route and the accepted route across forward, back and failed transitions.