Mode selection UX

1. Global 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). 1a user preferences are per-request parameters that ride along every query of a search, whatever the mode option, so they never add a query. 1b 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, which send nothing at all.

1a · 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. 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

1b · 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

2. Preset selector: main, show more, custom

One triple per preset, custom is one triple too. Car needs a second query because OTP drops the transit itineraries next to a direct car trip. Level 1: the main presets. Level 2: more nuanced presets behind "more options". Level 3: custom access / direct / egress (DIY), which is where asymmetric trips belong (walk one way, rental the other: the rental modes already fall back to walking when no vehicle is around). A preset is one modePreset id of the preset recipe; custom is the three slots of planner-v2-1. Car is the one two-query preset here; it pages with one cursor like the others, the car trip being a first page thing.ℹ see: one cursor for many queries, how the preset recipe pages

Try it in the demo app

2b. Multimodal presets: the transit provider's default

Same widget as view 2, other defaults. Here the bare vehicle name means "every way to combine that vehicle with transit": Bike runs own bike, own bike parked at the stop and rental bike; Car runs drive, park & ride and rental car. The narrow, single-query variants keep a qualified name (own, rental, parked, 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 view 2 where the preset is the same, so the two views 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

Try it in the demo app

3. One open dropdown with every preset

Same presets as view 2, same counts, flat "equal list" widget; the Car entry pages with one cursor as in view 2.ℹ see: one cursor for many queries, how the preset recipe pages

Try it in the demo app

4a. Main modes with a rent / park toggle beside each

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 4b where the switch replaces the shape instead.

Try it in the demo app

4b. Main modes plus one "vehicle" switch

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

1a · 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.

1b · 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.

2 · Presets, more, custom

• + One query per preset (Car excepted), one page cursor, results already sorted by OTP2: no merging or deduping client side.
• + Progressive disclosure: three choices for most users, nuance behind "more", full control behind "custom".
• + Presets are a table the customer owns; they can rename, reorder or drop them without an API change.
• – The "more" list is nine items long; each needs explaining, hence the model tables.
• – Custom with lists (several access modes) reintroduces the fan out; keep it single valued or cap it.

2b · 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 view 2, 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 · Open listbox

• + Everything visible at once, one click, easy to scan with the bracket notation.
• – Flat list treats "walk & transit" and "just drive" as equals; twelve presets is a lot to scan, tall on mobile.

4a · Rent / 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).

4b · Vehicle switch

• + 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, parked at the stop" is a mouthful and only exists for bike and car; asymmetric trips have no place here either (custom only).

Rule of thumb: options 2 and 4b keep planner-v2-1 at one query (two for car), which is the whole point of the recipe versus planner-v2. Option 1 belongs on top of them: 1a as parameters on every query, 1b as a filter. 4a 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).