# 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.