Critique your plugin #1 — Obsidian October 2024

Obligator’s settings UI needs to match Obsidian’s own design conventions, and the fastest wins come from small, concrete changes: removing redundant headings, using the API’s “setting heading” styling, and restructuring the page so related options sit together and appear only when they’re relevant. The critique zeroes in on how the settings tab currently feels “off” compared with the rest of Obsidian, then walks through a set of edits that bring the plugin into alignment—starting with the settings layout and then moving into the logic that decides what shows up.

The first round of fixes targets visual consistency. Obvious problems include large HTML H1 headings labeled “basic settings,” plus oversized “Archive” and “Advanced” headings created with H1 tags. The recommended approach is to remove redundant section titles entirely and replace custom headings with Obsidian’s standard setting-heading treatment via the API (using a “set heading” call rather than manually creating H1 elements). The critique also calls out naming redundancy—since the UI already lives inside the settings tab, repeating the word “settings” in labels wastes space.

Beyond styling, the settings page should behave intelligently. Two options—“initial heading” and “terminal heading”—are treated as always visible, even though they only make sense when a template file is configured. The suggested fix is to hide these settings unless the template path exists, by gating their rendering inside the display function behind a check for template path presence. The critique further notes that the UI must refresh when the template path changes: the code currently refreshes headings only when the path points to a file, but it should also re-render when the template is cleared or becomes invalid so the settings appear/disappear immediately.

Once the UI is cleaner, attention shifts to wording and toggle semantics in the “Advanced” section. Two toggles—“delete empty headings” and “don’t delete headings from template”—are both defaulted to on, but their phrasing creates cognitive friction because one toggle’s “on” means delete, while the other’s “on” means don’t delete. The critique recommends making toggle names affirmative so “on” consistently corresponds to the action being performed, either by renaming and inverting the toggle value or by changing the label to reflect the preserved behavior.

The review then moves from UI to code structure. The plugin class is relatively small, with most logic inside an onload routine that loads settings, defines a ribbon icon to open today’s daily note, and conditionally runs a “run obligator” function on startup. The critique suggests naming improvements (e.g., aligning the ribbon action name with what it actually opens) and highlights that validation is a strong point: the run function checks for missing note paths, verifies folders exist, and validates initial/terminal heading configuration.

Still, several improvements are proposed. Notices should include the plugin name to help users debug which plugin triggered them. For folder/file existence, newer Vault helpers (get file by path / get folder by path) can reduce type ambiguity. The code currently saves settings even when no changes occur, and it performs risky markdown parsing to confirm headings exist—an approach the critique flags as error-prone compared with using Obsidian’s metadata cache. Finally, there’s a feature request: open the daily note in a new tab when the ribbon is clicked with a modifier key. That would require passing a leaf type into getLeaf, derived from the click’s modifier state via keymap event handling, so behavior matches how users interact with Obsidian.

Overall, the critique frames plugin quality as a mix of UI conformity, correct reactive rendering, clear toggle semantics, and robust validation—plus small interaction upgrades that respect Obsidian’s navigation patterns.