docs(editor): document writing ergonomics findings
This commit is contained in:
parent
9b13766359
commit
ce55b9a2ce
1 changed files with 58 additions and 0 deletions
|
|
@ -201,6 +201,64 @@ Result:
|
|||
|
||||
The app now survives launch, typing, arrow-key movement, and select-all smoke testing without re-entering the selection loop.
|
||||
|
||||
## Finding #2 — Writing Comfort Matters More Than Features
|
||||
|
||||
Root cause:
|
||||
|
||||
After the selection recursion fix, the editor was technically functional but still uncomfortable. The three-column layout left the editor fighting for space, the inspector panel kept Git-oriented information visible during writing, and the text column was too close to the window edges.
|
||||
|
||||
Milestone 1 needs to validate whether a person wants to keep writing in Sapling. That requires layout and typography work even before advanced Markdown behavior exists.
|
||||
|
||||
Layout experiments:
|
||||
|
||||
- The three-column split view made the editor feel secondary.
|
||||
- Removing the inspector from the default writing surface immediately improved focus.
|
||||
- A two-column sidebar/detail split gives the editor roughly 70-80% of the default window.
|
||||
- The sidebar remains collapsible for focused writing.
|
||||
- The editor should be the detail column, not the middle column in a sidebar/content/inspector arrangement.
|
||||
|
||||
Sidebar impact:
|
||||
|
||||
The workspace sidebar is useful for opening documents, but it should not dominate Milestone 1. Git status and project inspection are distractions during editor validation and should stay hidden until later milestones.
|
||||
|
||||
Cursor behavior:
|
||||
|
||||
Native `NSTextView` keyboard behavior remains the right default. Arrow keys, Shift-selection, Option-arrow word navigation, Home, End, Page Up, and Page Down should be allowed to flow through AppKit instead of being reimplemented in SwiftUI.
|
||||
|
||||
Smoke testing after the layout and typography changes covered:
|
||||
|
||||
- Basic typing.
|
||||
- Left and right arrow movement.
|
||||
- Home and End.
|
||||
- Page Up and Page Down.
|
||||
- Option + Arrow movement.
|
||||
- Shift + Arrow selection.
|
||||
|
||||
No selection recursion or immediate cursor instability appeared during the smoke pass.
|
||||
|
||||
Typography observations:
|
||||
|
||||
- A 14-point editor made the prototype feel cramped.
|
||||
- A 16-point base font with more line and paragraph spacing is more comfortable for writing.
|
||||
- A readable-width text column is more important than using all available horizontal space.
|
||||
- Generous document padding makes the editor feel like a writing surface instead of a debug widget.
|
||||
- The active-line highlight should stay subtle; it is there to orient the writer, not decorate the page.
|
||||
|
||||
Status bar observations:
|
||||
|
||||
The status bar should remain quiet. Line number, column number, total line count, and saved/modified state are enough for Milestone 1. Showing rendered previews in the status bar added visual noise without improving writing flow.
|
||||
|
||||
Architecture impact:
|
||||
|
||||
- Editor usability depends on app layout, not only text view internals.
|
||||
- The native text view bridge can support comfortable writing if it controls text insets, readable width, and cursor visibility.
|
||||
- Keyboard navigation should be validated through native behavior first.
|
||||
- More features should wait until the writing surface itself feels calm.
|
||||
|
||||
Result:
|
||||
|
||||
The prototype now opens into a focused writing layout with a larger text area, collapsible sidebar, readable line width, generous padding, a subtle current-line treatment, and a realistic sample document for testing.
|
||||
|
||||
## AttributedString and NSAttributedString
|
||||
|
||||
Swift `AttributedString` is useful for renderer-facing APIs and SwiftUI previews.
|
||||
|
|
|
|||
Loading…
Add table
Reference in a new issue