2.0 KiB
Executable File
Markdown Editor UX Findings & Proposed Improvements
1. Core Goal Misalignment (The Primary UX Defect)
Current State: The user inputs markdown (via paste, URL, file, or typing), and the primary editing experience happens in a raw text editor (CodeMirror) where they edit markdown syntax. The "rendered" version is read-only (Preview). The Gap: As a developer tool, the goal is often to translate system language (markdown) into human language (rich text) and vice-versa. Humans expect a WYSIWYG (What You See Is What You Get) document editor experience. The Proposed Fix: The "Preview" should actually be an interactive, editable Rich Text interface. A user should be able to input raw markdown, see the rich text, edit the rich text visually like a Word document, and then export the result back to raw markdown.
2. File Import Format Limitations
Current State: The UI implies users can open files.
The Gap: .html and .docx imports require external libraries (turndown, mammoth.js) which are not yet fully implemented according to the Phase 2 roadmap.
The Proposed Fix: Restrict the <input type="file"> to .md and .txt until the conversion logic is built, preventing users from loading raw binary/HTML into the text editor.
3. View Mode Toggles & Workflow
Current State: Defaults to 'split' on desktop and 'editor' on mobile. After importing data, it jumps to the raw editor. The Gap: Similar to the Object Editor, jumping straight to raw code isn't ideal. The Proposed Fix: After data is provided, default to the (newly proposed) Rich Text / Preview mode first.
4. PDF Export Styling
Current State: Uses html2pdf.js for export.
The Gap: Long code blocks in markdown often overflow the page boundaries when converted to PDF because CSS print media rules for white-space: pre-wrap or break-inside are missing.
The Proposed Fix: Inject print-specific CSS rules before triggering the PDF export to ensure code blocks wrap gracefully.