Finding things, and planning a trip

This guide covers the four ways the guide lets you get from "I want to do something" to "here it is": the search box, which reads what you typed rather than only matching it; browse, which walks the whole dataset as cascading columns along six different axes; the activity cloud on the home page, which asks what you feel like doing and opens up in place; and the trip planner, which starts you on a real Saturday instead of a blank form. It also covers the two things that make those surfaces personal — setting a home base so lists can sort by walking distance, and the offline pack that keeps your plan readable with no signal.

Updated: 2026-08-20

Contents

1. Searching — the box that reads intent
   1. What the parser understands
   2. Typos
   3. Seeing the guide's reading of your query
   4. Narrowing with filters
   5. Sharing a result set
2. When nothing matches
   1. The recovery panel
   2. "Those filters leave nothing" is a different wall
3. Browsing by path — the columns
   1. The six axes
   2. The Holdings Sunburst
   3. Keyboard and phone
   4. Deep links
4. The activity cloud — "What do you feel like doing?"
5. Setting a home base
6. Planning a trip
   1. The starter day
   2. Pinning places
   3. Times, meals, and split days
   4. The progress meter
   5. Sharing a plan
7. The offline pack
8. Working without JavaScript
9. What is stored on your device

1 · Searching — the box that reads intent

/search is one box over everything the guide holds. On the day this was written the index carried 549 entries: 343 places, 52 events, 43 Blue Line and Gold Line stations, 33 answer cards, 22 districts, 21 articles, 13 tours, 13 deals and 9 site sections. Typing searches all of them at once and groups the results by what they are.

Results appear as you type — the ranking runs on your own device, so there is no wait between a keystroke and a result.

What the parser understands

The box does not only look for your words in names. It reads a vocabulary of phrases real visitors type and turns them into constraints. Every example below was run against the live index:

Three kinds of word are recognised:

• What you want — breweries, museums, pizza, live music, greenway, run club, farmers market, whisky, cocktail bar, lake, chess. These map onto the categories places are actually tagged with, so a recognised word always changes the results rather than merely being noticed.
• When — tonight, this weekend, tomorrow, today, open now, right now. A time word also implies "and it should actually be running", so seasonally-shut places sink.
• What kind of thing — deals, specials, events, tours, guides, districts; and attributes: free, cheap, kid-friendly, indoor, rainy.

Station names are understood as places to be near. near stonewall, near woodlawn, near 36th street, near east west boulevard — the guide resolves the station on either rail line and searches its walkshed (that station plus the one either side). A leading near / around / by / on is absorbed, so dinner near woodlawn and woodlawn dinner ask the same question.

Neighbourhood names are not station names. breweries near south end works, but it works as a text search — "south" and "end" are matched against place records, not read as a rail anchor. The results are good (67 of them, Wooden Robot Brewery first) but the "Near …" chip does not appear. If you want the walkshed behaviour, name the station: breweries near new bern or breweries near east west boulevard.

Longer phrases win over shorter ones. mini golf is read as mini golf, not as "mini" plus "golf". crab cakes is read as seafood dining, and the word "crab" still earns Crab-named places a boost on top.

Typos

If a word is not recognised, it is matched against the text of every record with tolerance for one or two typos — thrashrs will still find Thrasher's. Tolerance kicks in from three letters up, so short words are matched strictly (this is what stops in from matching half the dataset).

Names are searched literally too, so optimist hall finds Optimist Hall and the answer card about it; noda brewing finds NoDa Brewing Company.

Seeing the guide's reading of your query

Under the box, a "Reading that as" row shows the chips the parser produced — Near East/West Boulevard · Sit-down dining, Events · Tonight. If the chips are not what you meant, that is your cue to rephrase. A search that silently reinterprets what you typed and says nothing about it is worse than one that does nothing, so the guide always shows its reading.

Two more lines can appear:

• "Nothing matched right by station — showing the nearest instead." A station is a hard constraint until it empties the results, at which point it is demoted to a preference and you are told so.
• "— the closest N of M" on the count line, when the list was capped.

The blue button never says "Search". It says what you will get: "Show 34 places · 6 events". The number on the button is the number you will see.

Narrowing with filters

With a query on screen, a filter bar appears above the results. Groups are Kind, Category, District, Station and Open now, and every option carries the count it will leave on screen after you click it. An option that would leave zero results is never offered.

Two things are worth knowing:

• A filter that your query already applied is shown as a fact, not a control. Search breweries and the Category group reads "Breweries — from your search" rather than offering a toggle. Switching it off could not widen anything, so there is nothing to switch.
• "Open now" means "open now, among the places we have hours for." The label says "(places with hours)" out loud. A place with no published hours is not claimed to be closed — it is simply not in that filtered set.

Sharing a result set

The address bar keeps up with what is on screen: /search?q=breweries&district=NoDa&open=1. Send that link and the recipient opens the same filtered list. The parameters are q, kind, category, district, stop and open=1.

A filter value the guide no longer recognises is dropped quietly rather than throwing an error — an old link loses one chip, not the results.

2 · When nothing matches

The recovery panel

A zero-result search is the sharpest dead end a guide can have: you typed the only thing you knew how to type and it said no. So /search never just says no.

When the ranking comes back empty you get a panel headed "Nothing matches '…' yet." — the dataset's limit, stated plainly, with no "did you mean" guess — followed by a short list of moves. Every move on that list was run before it was offered. The guide loosens the query in several ways (drop one word, keep one word, take the plain category, drop the station, drop the time, drop an attribute), ranks each loosened query for real, throws away any that also returns zero, and shows you what survives with its true count.

A real example: searching chili mac — which happens to be the placeholder text in the box — returns nothing, and the panel offers:

• Search without "mac" — 19 places · 2 events · 1 article
• Search without "chili" — 3 answers · 2 articles · 1 section

A promise on one of those buttons is a promise the next screen keeps. Nothing in this panel can land you back on this panel.

When nothing about the query loosens — a single unknown word like xyzzy, or an emoji — there is nothing to drop, so instead you get three queries that are known to work right now, each with its real count:

• breakfast — 17 places · 1 tour
• food near east west boulevard — 4 places · 1 deal
• what's on tonight — 52 events

Below the moves is a short list of rooms to walk into: the hub that owns this kind of question (Nightlife, Breweries guide, Events calendar, the museum guide, the lakes guide, the map…) and, always last, Browse everything, A–Z as the floor.

The tone is deliberate. "Nothing matches X yet" states the guide's limit, not your spelling. When the guide did understand the question but has nothing filed under it, it says so: "The guide understood the question — it just has nothing filed under it."

Zero-result searches are counted (the query text, a count, and a date) on your own device so the editors can see what the guide is missing. Nothing about you is recorded with it.

"Those filters leave nothing" is a different wall

If the search found results and your filters removed all of them, you get a different panel: "Those filters leave nothing." — "The search found results — the filters removed all of them. Any of these puts them back:" followed by the narrowings you can drop, each with the count it restores, biggest first, and Clear all filters as the floor.

The distinction matters. The first wall is a gap in the guide's coverage and is logged as one. The second is a control that went too far — the query was fine — and is not logged as a gap.

3 · Browsing by path — the columns

/browse is for the question search cannot phrase: show me everything of this kind, arranged. It is a Finder-style column browser over the whole dataset — all 346 place records, 2,184 rows, 866 cards. Pick a column on the left, each choice opens the next column to its right, and the rightmost panel is always a card you can read.

The card's Connections list is the real payoff. Every entry on it re-roots the entire browser somewhere else — from NoDa Brewing Company you can jump to everything else in NoDa, everything in the same cuisine, everything in the same category, the district card, any tour it is a stop on, and the people and eras the history corpus connects it to.

The six axes

A place calling itself "Seafood & steak" appears under both Seafood and Steak & Chops — it genuinely belongs in both, and filing it once would hide it from half the people looking. Categories work the same way: they are tags, not homes.

If a district has not yet been assigned to a neighbourhood area, it shows up under Elsewhere rather than disappearing. A browser with a hole in it is worse than one that says plainly where the hole is.

The Holdings Sunburst

Above the columns sits a ring diagram of the whole collection — every district as a wedge, every category within it as an inner cell. Each wedge is a plain link that seeds the columns below: clicking a district opens /browse?path=district/noda, clicking a cell opens /browse?path=district/noda/brewery. It is the map above the door; the columns are where the browsing happens.

Keyboard and phone

On a screen 768px wide or more you get true cascading columns with full Finder keyboard semantics:

• ↑ / ↓ move within a column
• → or Enter step into the next column
• ← step back
• Home / End jump to the first or last row

On a phone it becomes an iOS-Settings drill-in: one list at a time, with a ‹ Back button, a Top button, and a breadcrumb trail. Both presentations share one piece of state, so a link works either way.

Deep links

The path is the URL. /browse?path=district/noda, /browse?path=street/mill-north/noda, /browse?path=food/breakfast, /browse?path=tour/{slug} — all bookmarkable and shareable. The browser walks your path as far as it resolves and stops there, so a link written against an older version of the dataset opens as deep as it still can rather than erroring.

Below the columns is a second, coarser browse: Browse everything, a flat list of every section of the guide grouped under the four top-rail hubs, with your own recent destinations on top. Columns are for records; that list is for rooms.

4 · The activity cloud — "What do you feel like doing?"

On the home page, under the heading "What do you feel like doing?", is a keyword cloud in the mid-2000s sense: words at different sizes, size meaning how much sits behind each one.

It opens up in place. Clicking a verb does not navigate anywhere — the categories under it appear right where the verb sits, and clicking a category opens its narrowings the same way. The cloud re-forms around your click instead of growing indented rows underneath. Picking a different verb collapses everything under the old one, because two open drills is two questions at once and the point of a cloud is that it only asks one.

The eight verbs are Eat, Drink, Play, Hear, See, Outdoors, Shop and Stay. Under a verb you get its categories; under a category you get narrowings — cuisine first where it exists ("somewhere for barbecue" is a sharper question than "somewhere in NoDa"), then tags, then districts. Every term carries its count.

Every word you can click has something behind it. Counts are computed against what you have already picked, not globally, and a term whose count is zero is not rendered at all. The cloud can never offer you "Diner" under Coffee and then show an empty list. Tags need at least two places in the current selection to appear — a one-place tag is the same click as the place itself, dressed as a category.

Below the terms are the places. A small enough set renders as its own little cloud (the landmark in a set of six is visibly the landmark before you read it); a larger one becomes a plain list of 24 with a "Show the other N" link. Clicking a place opens it in a panel over the cloud, so your drill is exactly where you left it when you close it.

Permanently closed places, demolished sites and unconfirmed listings are left out of the cloud — a browse surface for places you can go should not answer "where shall we eat" with a building that is gone. Those records still have pages, and the history surfaces still link to them.

5 · Setting a home base

Tell the guide which LYNX Blue Line station you are staying near, and lists across the site can sort themselves by walking distance from it.

The control is a pill labelled "Set where you're staying" (on /trip it reads "Add your address or hotel"). Opening it drops your cursor straight into a search field over the line's 26 stations, listed south to north. Pick one and the pill becomes "Staying near 36th Street", with a Clear button beside it.

What it changes:

• /places — the A–Z directory sorts within each category by walking distance.
• /search — your station becomes a gentle default anchor. Results near it float up and wear a reason chip like "~6 min walk from 36th Street". It is never a filter: the far end of town is still in the results. A station you type always overrides the one you saved, for that one search.
• /trip — every stop row shows the walk from your base.

Three things it is not:

• It never asks for your location. There is no geolocation prompt. You tell the guide; the guide never asks the browser.
• It needs no account. It is one setting saved in your browser.
• The times are estimates and are always marked as such. They are walking estimates from station coordinates, not routed directions.

Set it in one tab and other open tabs pick it up. Clearing it removes it everywhere and hands keyboard focus back to the pill.

The Miller-column browser at /browse deliberately does not re-sort by distance: its columns have a published order (south→north, or a fixed taxonomy) that the arrow-key model depends on. Near-sorting belongs on flat lists.

6 · Planning a trip

/trip is the planner. It needs no account and nothing leaves your device.

The starter day

You do not land on a blank form. The page opens on a real Saturday — the next upcoming weekend, with today counting if today is a Saturday, and a Sunday resolving to today rather than pointing at yesterday — pre-loaded with three real stops along the Blue Line, ordered south→north so the day walks in one direction.

The three are chosen deterministically: places in the Blue Line districts (South End, the four Uptown wards, NoDa) that are not seasonally or temporarily shut and have coordinates on file, preferring places whose hours are published (a landmark that cannot say whether it is open makes a worse first stop than a notable place that can), then by tier, then alphabetically. One of the three is somewhere to eat.

The starter is never written to your device. It is what renders until you touch something; your first real edit is what commits a plan you own — including owning the decision to empty it. That is why "clear my trip" actually clears.

The trip's default name is derived, not typed: "CLT weekend" for two or three days that touch a Saturday or Sunday, "CLT trip" otherwise, "CLT day trip" for a single day. Delete the name entirely and the default comes back rather than leaving the page nameless.

Pinning places

Three ways in:

1. From a place page — the "Add to trip" action on any /poi/… page.
2. From the planner — the "Add a place" picker on any day.
3. From a shared link — see below.

Days match your dates. Say you arrive Saturday and leave Sunday and Sunday appears as a real, empty, picker-bearing day; you should not have to press a button to create a day you have already declared. Day cards are capped at 14, beyond which extra days are added by hand.

The same place cannot be added twice to one day.

If a place you pinned later leaves the guide — it closed, or the record was withdrawn — the row does not vanish silently. It reads "This place is no longer in the guide" in its slot, keeping the shape of your day intact so you can decide what to do with it.

Times, meals, and split days

Every stop can carry a time, and the model is deliberately loose about what counts as one:

• a start — "we'll get there at 10"
• a start and an end — "10 to 12"; the duration is derived, never stored twice
• a duration alone — "about an hour at the museum", which is often the truest thing you can say

Nothing is required. An untimed plan is a complete plan and never warns about anything.

A time on a stop is your plan. It is never a claim about the venue. Where the two meet, the guide says so in both directions — "The hours we have on file say 11am–10pm on Saturdays — your 9am sits outside that" — and it is advisory, inline, and cannot stop you doing anything. Where the guide has no hours for a place, it says nothing at all rather than hedging.

Three other advisories, all sentences and never vetoes:

• Overlap — "Overlaps Optimist Hall by 30 min." Only the worst overlap on a day is reported; three warnings about one afternoon is nagging.
• The walk doesn't fit — "It's a ~15 min walk from Optimist Hall and you've left 5 min." Every travel sentence says the word walk, because the guide has no car routing and will not invent one. Past walking distance the claim changes shape: "It's ~4.2 mi from X — farther than a walk, so plan a drive or the train."
• We can't say — when a stop has no coordinates on file, "Travel time unknown … so there is no walk to measure." Never a zero, never a guess. It goes quiet once you have left more than 45 minutes, because at that point it is not news.

Each day has four meal slots — Breakfast, Lunch, Dinner, Evening treat. A slot holds either a place from the guide or your own words ("Pack a lunch", "Hotel breakfast"), never both. Freeform text is rendered as your words — no link, no hours, no walk time — because it is not a venue. The planner points the meal slots out gently once, ever, and then leaves them alone.

A day can split. Give two stops different group labels — "Dad + son", "Mom + the girls" — and the planner lays them out as parallel lanes that rejoin afterwards. Two stops in different groups may overlap without complaint: that is the entire point of branching. An unlabelled stop is the whole party by definition, so it does conflict with everything, including a named group.

The progress meter

Four steps, and each is a fact about the trip, not about us: Dates set, Walk times (a home base is set), Somewhere to eat (at least one food stop), Things to do (at least two non-food stops). The meter opens at 25% and never lower, because your dates are already picked — and it opens higher on a first visit because the starter day really does put a meal and two things on Saturday. Clearing your trip drops it back to 25%, which is correct.

Sharing is not a rung on this ladder. A visitor who reads their plan aloud in the car has not failed anything.

Sharing a plan

Get my share link encodes the whole itinerary — days, stops, times, groups and meal slots — into the URL itself as /trip?trip=…. No account, no server-side save, nothing to expire. Opening that link loads the plan into the recipient's planner as their own working copy.

The link is read once, on arrival. Editing afterwards never re-reads it, so your edits are never undone by a stale address bar.

7 · The offline pack

Charlotte has dead zones, and a plan you cannot read is not a plan.

Every time you pin a place, and every time you open /trip with a connection, the guide writes a small snapshot of your pinned places to your own device. /offline renders it with the radio off, under the heading "Your trip — offline copy", and it states plainly how many places it holds and when the copy was taken.

What it carries: name, neighbourhood, category, address, phone number, and a season-scoped hours line ("Daily 11am–1am · summer").

What it deliberately does not carry: "Open now · closes 10pm". That answer is true for minutes, and a cached one is a confident lie you have no way to check. The offline copy labels itself as a copy and prints its date, because an offline page that does not say how old it is has withheld the most important part.

Addresses and phone numbers are live links, chosen for what still works with no signal:

• The phone number dials. This is the one action on the page guaranteed to complete with no data connection.
• The address opens as a geo: link where the guide has real coordinates — your handset's own GPS and map app take over with no network round trip. Where it does not have coordinates, the link is an ordinary map search that plainly waits for signal. It will never drop a pin in the wrong ocean to look confident.

If nothing is saved yet, the panel does not render at all — the static offline page stands on its own.

One nuance worth knowing: pinning a place from its own page banks that page's facts, which is what the offline copy is built from. Pinning from a shared link a place you have never opened means there is nothing true to say about it offline until you open /trip with a connection, which rebuilds the whole copy from the live dataset.

8 · Working without JavaScript

The guide degrades honestly rather than pretending.

Search works. The search box in the top navigation bar (and in the mobile drawer) is a plain GET form pointed at /search, so pressing Enter lands you on a real results page. The results page renders its list on the server, so you see ranked results, the "Reading that as" chips, and the recovery panel if there are none — all without JavaScript.

What does not work without JavaScript on that page: typing to re-search from the results page itself. That box re-runs the query live in your browser rather than submitting a form, so with scripting off it does nothing when you press Enter. Two ways round it, both of which work: use the search box in the navigation bar (or the mobile drawer) — those are ordinary forms and submit fine — or edit the ?q= value in the address bar directly. This is the one search box on the site that behaves this way, and it is a rough edge rather than a decision.

The trip planner shows a real plan. With JavaScript off you get the starter Saturday as prose — the date named, the three places listed, each linked to its own page — plus a line saying plainly that reordering, times, meals and the offline copy need JavaScript. It is not a skeleton and it is not four grey boxes; it is the same starter day the interactive planner hydrates with.

Browse and the activity cloud need JavaScript. Both are interactive by nature. /places — the full A–Z directory — is the static route to the same records, and the offline page and every place page work without it.

9 · What is stored on your device

Everything below lives in your own browser. Nothing is sent anywhere, nothing needs an account, and clearing your browser storage clears all of it.

Every one of these is re-checked on read, because a stored value outlives site updates. A home base naming a station that no longer exists resolves to "no home base", never to a wrong walk time; an unreadable trip resolves to an empty one rather than a broken screen. Where storage is unavailable at all — private browsing, a full quota, storage disabled — everything still works for the session; it simply does not persist.

See also: the user guide index · FAQ · troubleshooting · glossary