Reverse the View Switcher button in the title bar

Feature requests
1

TLDR: the View Switcher button toggles the reading/editing view state. It is not navigation as previous solutions to this ongoing issue have concluded.

The view switcher ( lucide-book-icon.svg > icon ), in the upper-right corner of the editor within a note’s inline status bar, is incorrectly displayed. The lucide-book-icon.svg should display when in Reading Mode, and the lucide-pencil-line-icon.svg should display when in Editing Mode.

I know this has been cited previously, but the resolution logic is incorrect and it persists as an interface error.

UI/UX Logic

  • The view switcher is a button that toggles a view state.
  • The view switcher button lives in the inline title bar. This bar contains two left-justified buttons for note navigation with arrows for “previous note” with lucide-arrow-left-icon.svg and “next note” with lucide-arrow-right-icon.svg, then the center-justified current note’s title, then the view switcher button with lucide-pencil-line-icon.svg right-justified along with the note’s menu button to it’s right.
    • The arrow UI elements trigger an action to navigate to another file, and do not represent state—they are navigation elements.
    • The inline title UI element represents the current note’s file name state along with it’s path, which when clicked, triggers the UI to reveal it’s location in the File Explorer.
    • The view switcher toggles between two note views, meaning it navigates the user’s view to the next view state
    • and the menu button UI interaction reveals more commands, which trigger their respective events.
  • The entire bar consists of a blend of navigation, state change, and command execution.

Why the view switcher button should be reversed

  • Navigation UI is inherently understood by the user by convention — arrows mean navigation
  • Menu UI (displayed here as an ellipsis) is also inherently understood by convention—this is a commonly used UI icon for revealing “more options”.
  • The inline title is used for state — it’s shows the currently displayed note’s file name.
  • Lastly, the view switcher UI icon also represents a state—the state of the viewing mode, either Reading view or Editing view, as presented in Views and editing mode - Obsidian Help.

Recommendation
The view switcher UI element toggles state, and is not navigation, and is currently displaying its reciprocal icon. It should be reversed, as it is a native UI element rather than corrected by additional CSS repair.

The documentation article reinforces the button’s intention:

[!Website Text]
To switch to Source mode:

Click the interactive status icon ( lucide-book-icon.svg > icon or lucide-edit-3.svg > icon ) in the status bar and select Source mode.

Note

By default, editing view is set to Live Preview. Change this to Source mode under Settings → Editor → Default editing mode.

To switch to Source mode, now additionally you can:

Click the view switcher ( lucide-edit-3.svg > icon ) in the upper right corner of your note.

Or press Ctrl+E (Cmd+E on macOS).
Or use the command Toggle Reading view.

Here are former references to this issue, but each time the solution is incorrectly saying that this button is navigation. But this is only navigation if you believe all buttons are navigation, and they’re not. This button is a switch, and it’s currently displaying the reverse of it’s state.

Thanks!

(AI was not used to write this post. All em-dashes are my own.)
Edited to include TLDR

2 Likes
4

I completely agree with you. I’m expecting to see, atop a panel with two (or more, in fact) states, in which state the panel is currently, not the state it will eventually be when and if I click this button.

It is because of this weird behaviour that, in the theme I designed (Olivier’s Theme), I managed to put an icon in the top right of the panel signalling when the panel is in editing mode. (Moreover, the theme gives the possibility to have different backgrounds and or text colors, as well as different fonts between Edit and Reading modes to alleviate any ambiguity.)

My two cents.

5

Renamed for clarity

1 Like
7

The Editing Mode switcher. It typically looks like a pencil (when you are in reading mode) or a page/book (when you are in editing mode). It confuses me in its normal way of working.

It would be nice if there was an option to change it so that it reads the opposite way, ie: a pencil to me suggests editing mode and a book suggests reading mode. I know that some appearance themes change it like this, but it would be nice if it appeared in the setting such that a theme change was not required.

8

Workaround: A CSS snippet can reverse the button’s indicated state: Button to switch view in tab title bar reflects current view.

There isn’t a clear cut UX argument for reversing the button’s state indicator. From what I can tell, this kind of setup is inherently unclear and it is better to use something different altogether. Suggested improvements boil down to separating the state indicator from the button (examples: checkbox, radio button, switch with state names on either side), but that’s not very feasible in the small space available. I don’t know if there’s a feasible improvement to be made other than adding a setting, which strikes me as plugin territory.

Here are some resources about the issue.

9

TL;DR: A workaround is not a solve. The button still displays the opposite of its current state, and it’s the only state-bearing element in its UI row that does. The CSS snippet asks every user to fix a default the app ships broken. And the Stack Exchange thread cited above doesn’t support the dismissal — read in full, it argues against the current behavior, not for it.

Following up on my OP from November.

A workaround is not a solve, and I want to push back on the reframe in this thread.

The CSS snippet linked above doesn’t fix the bug — it asks every user, on every install, on every device, to repair a default state the application is shipping incorrectly. That’s not a workaround being offered, that’s the cost of the bug being transferred. The bug still exists. Every user who doesn’t know about the snippet still hits it. Every fresh install resets to the broken default. A workaround that requires every individual user to discover, install, and maintain a fix is the application choosing not to fix the application.

The framing that “there isn’t a clear-cut UX argument for reversing the button’s state indicator” misrepresents the original post. The post wasn’t a preference about what the button should look like. It was an analysis of what category of UI element this is — a state indicator inside a row of mixed navigation, state, and command elements — and the observation that it currently displays the opposite of its own state. That’s not a flip-flop-button taste argument. The arrows trigger navigation, the menu triggers commands, the title is a state indicator showing the current note. Of the two elements in the row that bear persistent state — the title and the view switcher — the title displays the current state correctly, and the view switcher displays the opposite of the current state. The two state-bearing elements in the same UI row use opposite conventions.

A possible objection: this is a toolbar element, and toolbars show actions or modes rather than states. But comparable mode-toolbar elements in other applications — Photoshop’s tool palette, Figma’s tools, VS Code’s view switchers — keep the icon constant and indicate the active mode through highlighting or active styling on the same button. They don’t swap the icon. Obsidian’s view switcher does swap the icon, which means in Obsidian’s case the icon itself is functioning as the state indicator. Once that’s true, the convention question collapses: a state indicator should indicate the current state, the same way Obsidian’s note title indicates the current note’s path. The current behavior makes the icon contradict the only other state-bearing element in the row, and contradicts the standard mode-toolbar convention from comparable applications.

The Stack Exchange thread linked above is worth reading in full, because it doesn’t conclude what it’s being cited for. Its top-voted answer (Cooper & Reimann, About Face) categorically rejects flip-flop buttons — “Don’t use them. Not on buttons and not on menus.” Its second-highest-voted answer argues for moving state indication off the button entirely, onto a persistent label or active-state styling. Its third explicitly distinguishes action-toggles (Play/Pause, where target-state display is acceptable) from option/mode-toggles (Shuffle, mode switches, where current-state display is correct). The view switcher is unambiguously a mode toggle — it changes a persistent setting that sticks until changed — which by the linked thread’s own consensus should display its current state. The literature being cited to dismiss this thread is, when read carefully, the literature that supports it.

The other implicit dismissal — that the only feasible improvement would be a setting, which strikes the reply as “plugin territory” — should also be named. The fix being asked for is a default change, not a setting and not a plugin. The title is not solved by a setting. The menu is not solved by a setting. The arrows are not solved by a setting. Asking for the view switcher to indicate state correctly is asking for the same kind of native default the rest of the row already has. Routing this into the plugin ecosystem is routing core UI responsibility outside of core, which is a different conversation than whether the bug exists.

The thread has been open since November. It’s been closed once already. The pattern of “user makes a structural argument → reply offers a CSS snippet → reply cites general design literature → reply suggests a setting belongs in plugin territory → thread is closed” is the pattern. I’d ask the team to engage with the actual content of the original post — the row-consistency argument and the convention argument — rather than re-routing the conversation back to the well-trodden flip-flop debate that the OP explicitly addressed.

A toggle in a row of state-bearing elements that inverts its own state is a defect against its immediate context, not a stylistic preference. Workarounds don’t resolve defects. They postpone them, on the user’s time.