Mode selection UX

Settings

The settings screen, not the planner form. Two sub-screens, both compatible with every option below: the planner form still carries one of the inline components (presets, listbox, toggles, switch). User preferences are per-request parameters that ride along every query of a search, whatever the mode option, so they never add a query. Routing settings restrict the modes: they trim what the inline components offer, and the transit checkboxes drive the transportModes column of every query list on this page. Done well, with the right defaults, most travellers never open this screen: the defaults below are the OTP 2 ones (or the recipe's, for the live rental availability), which send nothing at all, with one exception: the app caps walk-only trips at 20 min.

User preferences

The things a traveller sets once: pace, how far they accept to walk or cycle to a stop, transfers, accessibility. Each control maps to one OTP 2 parameter of both recipes, written straight into the snippet; defaults send nothing, but for one app default: walk-only trips are capped at 20 min (maxDirectDurationFoot=PT20M, seeded in the snippet with the trip), since OTP 2's 4 h cap would list hour-long walks next to the transit itineraries; the traveller can pick another cap or lift it. The "at most" caps are what OTP calls performance parameters: they can only lower the server caps (45 min to or from a stop, 4 h door to door; above that OTP answers with an error) and they are hard cut-offs (verified live: capping the walk to the stop at 5 min on a suburban origin left no itinerary at all, noTransitConnection). For a soft preference the lever is walkReluctance, not exposed here on purpose. Public transit and rental list the operators and the GBFS networks OTP 2 knows, all on by default; unticking one bans it (bannedAgencies, bannedRentalNetworks). OTP 2's trip query knows no "preferred" operator, so a subscription badge stays a client side concern.

Try the settings screen in the demo app

Routing settings: restrict modes

One global setting to allow options. Default is walk & transit only. Every extra street mode allowed is another vehicle kind the app has to query for, since this control alone carries no intent (the allowed list is ui state, not a parameter). Unchecked transit modes go to transportModes: try unticking one and look at the other views. Used as the only control it is a fan out, one query per allowed kind, with the paging caveat that comes with it.ℹ see: one cursor for many queries, how the preset recipe pages

1. Monomodal presets: main, show more, custom

One triple per preset, custom is one triple too, and every preset here is monomodal: one way of moving and nothing else. Walk is walk-only (foot / foot / foot, transportModes empty), public transit is transit-only (the direct slot left unset, so no door to door walk next to the transit itineraries) and the vehicle presets are the -only variants (transportModes empty), so an itinerary either carries the mode asked for or does not come back at all. OTP has no switch for that: with a rental mode next to transit it also returns transit itineraries reached on foot, since renting is optional in a rental search; the -only presets are the way to keep the promise (rental still walks when no scooter is around). Level 1: the five main presets. Level 2: on-demand behind "more options". Level 3: custom access / direct / egress (DIY), where asymmetric trips and vehicle + transit combinations belong (or option 2). A preset is one modePreset id of the preset recipe; custom is the three slots of planner-v2-1. No preset here runs more than one query.

Try it in the demo app

2. Multimodal presets: the transit provider's default

Same widget as option 1, other defaults. Here the bare vehicle name means "every way to combine that vehicle with transit": Bike runs own bike, bike Park&Ride and rental bike; Car runs drive, Park&Ride and rental car. The narrow, single-query variants keep a qualified name (own, rental, Park&Ride, just) and sit behind "more options": one list, the name says how wide the preset is, the table says what it costs. Same ids as option 1 where the preset is the same, so the two options stay in sync. Bike and Car are multi query presets: one cursor pages all their queries at once, so the cost of this option is the query count (latency), not the paging.ℹ see: one cursor for many queries, how the preset recipe pages The rental queries also return transit itineraries reached on foot (renting is optional in an OTP 2 rental search): both recipes mark every itinerary with matchesRequestedModes (at least one leg uses a vehicle of the preset, the root requestedModes lists them) and the demo greys the others out; hiding or sorting them last is the client's call, the paging is untouched.

Try it in the demo app

3. Simple select with progressive reveal

Same presets as option 1, same counts (see the table), one native select. In the demo app the list grows on demand: the main choices and "More…" first, the full list in groups once asked, custom last (the select rebuilds and reopens itself). Here the list is shown as the demo shows it once "More…" was picked: fully open, in groups. Picking "Custom…" reveals the three trip parts underneath, as in the demo.

Try it in the demo app

4. Rent and park toggles beside each main mode

Google style: pick the mode, then refine it in place. The toggles are additive, "enable on top of": own vehicle stays, rental and parked are extra shapes, each one another OTP 2 query. Scooter is rental only, so no toggle. Both toggles on = the multimodal preset (one call, three queries); one toggle = two presets, two calls. Every toggle adds a query, so it adds a page cursor to move along with the others.ℹ see: one cursor for many queries, how the preset recipe pages Compare with option 5 where the switch replaces the shape instead.

Try it in the demo app

5. Rent or park switches under the main modes

Variation: the mode list stays clean, one switch below applies to the chosen mode (greyed out for walk, rental only for scooter) and replaces the shape rather than adding one. "Own + rental at once" is what option 4 does, at the cost of extra queries. Every position is exactly one modePreset; only own car runs two queries and inherits their paging caveat.ℹ see: one cursor for many queries, how the preset recipe pages

Try it in the demo app

Pros & cons, by number of OTP2 queries

One planner-v2-1 query = one [access → transit → egress] + [direct] pair, both shapes come back together, unless the direct mode is fast enough to trigger the transit-vs-street filter (car, taxi): then the transit shapes need their own query. Several queries means merging, deduping and paging them together: the preset recipe does it server side behind one modePreset and one pageCursor (planner-v2 merges up to 9 queries too, but leaves one cursor per query to the client).

Settings · User preferences

• + Free: a preference is a parameter on the request, not a query; it composes with every mode option and both recipes.
• + Plain words map to one parameter each (pace → speed, "at most 10 min to the stop" → the per mode access/egress cap, "fewer transfers" → the transfer penalty), so a customer can pick which ones to show without an API change.
• – The caps are hard cut-offs that can only lower the server defaults: a tight cap on a suburban origin returns nothing rather than a longer walk, so the UI needs an empty-result fallback ("no trip within 5 min of walking, try 15").
• – The soft levers OTP has (walk, wait and transfer reluctances, the bike safety / slope / time triangle) do not translate into words a traveller understands; they stay API-only, for tuning by the integrator.

Settings · Restrict modes

• + Composes with every other option: a city hides cars, an operator hides scooters, the presets and custom selects shrink accordingly.
• + Transit part maps 1:1 to transportModes, no query multiplication there.
• – As the only control it does not express intent, so the app has to query every allowed vehicle kind: a fan out that grows with each box ticked.
• – Walk & transit as the default keeps it at one query, but then the setting alone never yields a bike or car trip unless the traveller opens it.

1 · Monomodal presets, more, custom

• + One query per preset, one page cursor, results already sorted by OTP2: no merging or deduping client side.
• + Progressive disclosure: four choices for most users, the rest behind "more", full control behind "custom".
• + Strict by construction: the -only presets never show a transit-only itinerary under "Scooter" (the complaint that started this), and they need no marking or filtering server side.
• + Presets are a table the customer owns; they can rename, reorder or drop them without an API change.
• – Monomodal means no vehicle + transit combination here: a traveller who wants "bike, then the train" has to go to custom or to option 2.
• – Rental scooter (and, when added, rental bike / car) still walks when no vehicle is around: "or nothing" is really "or a walk".
• – Custom with lists (several access modes) reintroduces the fan out; keep it single valued or cap it.

2 · Multimodal presets

• + One intent-level choice gives the traveller every transit combination for their vehicle: the transit provider's goal, without teaching them the slots.
• + Same widget and same naming rules as option 1, so a customer can move from one default to the other by relabelling.
• + Bounded fan out: never more than 3 queries, always known in advance per preset (planner-v2 runs up to 9 blind), and the preset recipe runs them in one document.
• – Merging, deduping and labelling itineraries by origin query is on the server (preset recipe) or the client, with one page cursor per preset call (the preset recipe) or per query (client side merge).
• – The rental car query has a fast direct mode; if the filter drops its transit shapes the "Car" preset silently loses park-and-ride-like rental trips (to verify with car-sharing data in range).

3 · Simple select with progressive reveal

• + One native select, no custom widget: the main choices first, the whole list only when asked.
• – The reveal is a trick (the select rebuilds and reopens itself); a flat list treats "walk & transit" and "car" as equals.

4 · Rent and park toggles beside each mode

• + Familiar (Google style), the mode row stays short: four modes, the nuance is a checkbox.
• + Own and rental can be compared on one screen.
• – Up to four queries: results must be merged and labelled ("this one is with a rental bike"); paging stays one cursor per call thanks to the preset recipe, the cost is latency.
• – Toggles are only meaningful for some modes, so they appear and disappear per row; asymmetric trips do not fit the model at all (custom only).

5 · Rent or park switches

• + Strict by construction: one query, one cursor (two for own car).
• + Clean mode row; the switch reads as a sentence ("Bike, rental").
• – No way to compare own vs rental in one screen; the user has to flip the switch and search again.
• – "Own, Park&Ride" only exists for bike and car; asymmetric trips have no place here either (custom only).

Rule of thumb: options 1, 3 and 5 keep planner-v2-1 at one query (two for own car in option 5), which is the whole point of the recipe versus planner-v2. The settings screen belongs on top of them: user preferences as parameters on every query, restrict modes as a filter. Option 4 and custom-with-lists are the two places where the fan out sneaks back in; if a customer wants that, the honest answer is the preset recipe, or a client that fires 2 to 4 planner-v2-1 calls in parallel and shows them as separate tabs rather than merging them. One api follow-up would remove the remaining exception: a product-grade way to keep transit next to a car trip in one query (a keepTransitAlternatives flag mapping to listAll with the notices stripped server side).