Last week's post on sidebar sections had a section called What the plan review cut, and one of the items was a Configure sidebar link: hover-revealed, sitting under the sections, opening the properties dialog. We removed it and wrote that "a control that only appears on hover, at the bottom of a scrolling region, is a control nobody finds."
That was right as far as it went. This release puts a version of it back anyway, and the difference is worth spelling out, because it is about the one case the argument did not cover.
The empty sidebar
Every section header in the sidebar has a settings button that appears on hover, and until now the menu behind it had exactly one item: Remove from sidebar. Tags is on by default, so a new workspace has one section. Remove it — reasonable, if you do not use tags — and the middle of the sidebar is blank. New note and Home at the top, Files and Bin and Settings at the bottom, nothing in between.
Nothing in between is the problem. The way to get a section back is More → Custom properties, then the property, then Show in sidebar. That path exists, and the previous post argued it was one click away. It is one click away only if you already know the blank space is a configurable space. A blank region does not say that. The nearest thing that looks like it might is Settings, which is the wrong dialog.
So the rule the review got right — hover-only controls at the bottom of a list are invisible — needs a caveat. When the list is empty there is no bottom, and there is nothing else in that region for the eye to land on. The empty state is the one place a hover affordance works, because there is nothing for it to compete with.
What shipped
Configure sidebar appears in the sections area only when the sidebar has no sections at all: Tags removed, and no property switched on that has anything to list. Move the pointer over the sidebar and it fades in; click it and the properties dialog opens. Switch any section on, close the dialog, and it is gone. It is drawn as a dashed, muted row rather than a solid button, on purpose: it is not an action you take often, it is a hint that the space can hold something.
The condition is stricter than "no properties in the sidebar". A relation property that is switched on but that nobody has linked to yet renders nothing, and from where you sit that is an empty sidebar. The button keys off what is actually on screen, not off the flags.
Edit property, from where you are
The section menu grew a second item, and it is the one we should have shipped first: Edit property. Hover a section header, click the settings button, choose it, and the properties dialog opens with that property already selected — its options, its colours, its Show in sidebar switch, right there. For Tags and Board it opens their locked built-in pane, where the sidebar switch is the only setting.
Before this, editing a property you could see in the sidebar meant More → Custom properties, then finding it in the list. With three properties that is nothing. With fifteen it is a search, for something the sidebar already knew, because you were hovering it.
Opening a dialog on a thing
The small engineering point under both changes is that the properties dialog can now be told which property to open on. That sounds trivial and was not quite.
The dialog already had rules for its selection: pick the first user property when it opens; jump to a property the moment it is created, once the refetch that includes it lands; recover if the selected one disappears from the list. Those rules live in one effect, and the new one had to slot in without disturbing them.
The wrinkle is timing. The dialog fetches its list only while open, and that list shares a cache with the sidebar, so it is usually already there — but not always, and a request to select a property that is not in the list yet has to wait for the list rather than give up. A just-created property has the same shape of problem, and it was solved by holding the id and retrying when data arrives. The requested property reuses that idea with one difference. A created property is guaranteed to turn up, so waiting is correct. A requested one might have been deleted by a teammate between your hover and your click, so if the list arrives without it, the dialog falls back to its normal default instead of sitting on nothing forever.
That distinction is a few lines, and the whole reason the feature is not flaky.
Testing a thing that is invisible
The end-to-end suite for sidebar sections gained two tests. One opens Stage from its section menu and checks that the dialog's name field already reads Stage and its switch is checked, then does the same for Tags and checks it lands on the built-in pane. The other removes Tags, asserts the configure button exists but is fully transparent, moves the pointer over the sidebar, asserts it is opaque, clicks through, switches Tags back on, and asserts the button is gone from the page.
The second is fussier than it looks. Playwright counts a transparent element as visible — it has a box and is not hidden — so a plain "is visible" check would pass whether or not the hover reveal works. The test reads the computed opacity instead, before and after the hover. If you ship a control whose entire point is when it shows, assert the when.
In one place
The section menu is now Edit property / Remove from sidebar.
A sidebar with no sections shows Configure sidebar on hover.
The properties dialog can open on a chosen property, and falls back sensibly if it is gone.
Help: The sidebar · Custom properties · Changelog v0.8.1
Continue reading
Every property, one click away — the v0.8.0 post this one revisits: which property types get a sidebar section, and what the plan review cut.
Beyond folders: how Notez organizes notes — tags, sub-notes, boards and eleven custom property types, and why Notez has no folders.
The list you lose every time you open a note — a note opens in a side panel over the list, so the scroll position and filters stay where they were.