用户体验案例研究:Markdown标题 #
在 Markdown (opens new window) 中创建标题,只需在行首放置一个井号 # 后跟一个空格:
要创建二级标题,使用两个井号,以此类推:
我可以看到我的斜体文本是...斜体的,但我仍然看不到我的H1标题。肯定不能和我的正文文本大小一样吧?
嗯,... 鼓声...
这就是分割窗格!
有了分割窗格,我终于可以看到我那个超大的H1标题了!
分割窗格无处不在:
(opens new window)(Dillinger编辑器 (opens new window))
(opens new window)(iA Writer (opens new window))
(opens new window)(Inkdrop (opens new window))
(VSCode)
然而,在这种设置下,我需要在编辑器的左侧和分割窗格的右侧之间来回切换。这将会很累人。
如果我们去掉分割窗格,但仍然可以在写作时预览内容怎么办?当然可以!
在 TOAST UI editor (opens new window) 中可以看到这方面的一小步:
(Inkdrop)
你可以随时添加或删除井号,以达到你期望的标题级别。最酷的部分是:你可以实时看到标题的大小调整!
非常好!
然而,一些编辑器似乎没有完全实现这种实时视觉反馈。以下示例显示编辑器中标题的斜体文本会实时格式化,但标题本身不会:
(opens new window)(iA Writer) 无论如何,我不禁注意到即使在我们已经处于预览模式的情况下,Markdown语法字符**#和***仍然突出显示。换句话说,尽管我们在写作时已经不是所见即所得。
现在,让我们看看一些可能带我们到目标的编辑器:以纯粹的所见即所得方式编写Markdown,而无需分割窗格。
这是Notion (opens new window)的方式:
没有更多的**#和***突出显示!我们终于进入了所见即所得的领域!
在Atlassian的Confluence (opens new window)中也是一样:
在这两个编辑器中,用户可以轻松地通过输入各自的Markdown语法字符来创建标题和斜体文本。这是我们到目前为止在每个提到的编辑器中习惯的用户流程和心智模型。
但在编辑方面,用户被迫切换到完全不同的流程和心智模型。
例如,在Notion中更改标题级别,您必须双击以选择文本,从而弹出一个浮动工具栏,在那里您会找到并选择您想要的标题类型:
同样,在Confluence中:
当然,键盘快捷键是可用的。但它们也是一个相反的用户流程和心智模型。它们可以补充主要流程,但不能取代它。
在这一点上,我们可以为Markdown编辑器制定一个首要原则:添加和删除Markdown语法字符是彼此紧密联系的因果关系。
我们可以在分割窗格世界中观察到这一原则:
自从个人计算机问世以来,输入和删除字符一直是在线写作和编辑的重要部分。如果可以输入某些字符来创建特定的UI元素,那么同样也应该能够反向操作 - 编辑您输入的字符 - 以编辑所述UI元素。
截至目前,只有少数编辑器似乎遵循这一原则。让我们来看看。
Marktext (opens new window)编辑器:
但这一原则不适用于只能通过键盘快捷键更改的标题。
这里是Typora (opens new window)编辑器:
与斜体文本不同,用户在创建标题时没有即时的视觉反馈。而且像Marktext一样,只能通过键盘快捷键来编辑标题。
最接近遵循我们首要原则的编辑器是Obsidian (opens new window)编辑器:
这才是我说的!
需要指出的一小点是,当您删除标题中斜体文本的闭合星号时,正文文本也会变成斜体。
最后这是我正在开发的Markdown编辑器 (opens new window):
结论 #
所有现代的Markdown编辑器都让我们采用一种用户流程和心智模型,其中我们可以输入Markdown语法来创建UI元素,例如标题和斜体文本。但是,在几乎所有编辑器中,反向操作是不可能的 - 要编辑UI元素,您被迫采用完全不同的流程和模型。
本文是在寻找我理想编辑器的旅程:一个地方,从一个如输入和删除字符这样的单一操作中立即获得视觉反馈,并且您可以看到并感受到您书写思想的每一个脉冲。