| 软工个人作业 2 | 您所在的位置：网站首页 › typora文件管理 › 软工个人作业 2 |
软工个人作业 2
|
软工个人作业 2 - 软件案例分析：免费开源 Markdown 编辑器
项目内容这个作业属于哪个课程2023年北航敏捷软件工程社区这个作业的要求在哪里个人作业-软件案例分析我在这个课程的目标是熟悉并在实践中体会软件开发流程，学习软件构建思维，提升编码能力这个作业在哪个具体方面帮助我实现目标通过评测与分析软件体会到了软件构建思维；通过 Bug 测试和 PM 模拟等环节，从多个视角体验到了软件开发进程；
文章目录
软工个人作业 2 - 软件案例分析：免费开源 Markdown 编辑器零. 选题综述：免费开源 Markdown 编辑器Background为什么定位”免费开源“？面包与水仙花：对 Markdown 编辑器的基本要求Markdown 语言的应用需求分析Markdown 编辑器的功能要求分析
小径分岔的花园：桌面端与浏览器端生态的选择
一. 软件调研与评测评测环境设备环境软件版本
软件评测评测标准量化指标语言应用需求满足表 (4 / 10)编辑器功能满足表 (4 / 10)其他量化评测标准 (2 / 10)
具体分析内容MarkText软件基本页面展示指标量化表评分：7.2 / 10用户采访调研综合评价
Zettlr软件基本页面展示指标量化表评分：6.26 / 10用户采访调研综合评价
披榛采兰：与 Typora 对比
Bug 分析与提交Bug 严重星级量化指标Bug 具体情况MarkTextBug1：⭐⭐⭐⭐可能成因Bug 修改建议
Bug2~6：⭐⭐⭐可能成因Bug 修改建议
Bug7：⭐⭐可能成因Bug 修改建议
未能稳定复现的 Bug8~10
ZettlrBug1~5：⭐⭐⭐可能成因不修复的可能原因Bug 修改建议
Bug6~8：⭐⭐可能成因不修复的可能原因Bug 修改建议
Bug 反馈
二. 开发分析工作量分析软件质量分析分析这个软件目前的优劣（和类似软件相比），这个产品的质量在同类产品中估计名列第几？从各方面的问题，推理出这个软件团队在软件工程方面可以提高的一个重要方面
三. 建议与规划市场概况分析市场现状市场与产品生态核心用户群侧写用户生态分析
产品规划NABCD 分析功能 1：支持分屏预览的源代码写作模式功能 2：支持基于 YAML Front Matter 的标签系统可能提升用户体验的细节功能
团队开发角色配置规划团队开发工期安排（16 周）
零. 选题综述：免费开源 Markdown 编辑器
Background
以团队作业的调研开发倾向为基础，我选择了 免费开源的所见即所得 Markdown 编辑器 作为软件案例分析个人作业的主题（以 MarkText 1 、 Zettlr 2 为例）。所见即所得的 Markdown 编辑器是一种适合当下时代需求的工具，它可以帮助用户（尤其是开发人员）更专注于内容而非格式，进而更快捷、优雅地编写具有强兼容性、美观性与版本管理便利性的 Markdown 文档。 为什么定位”免费开源“？或许最为人所知的 Markdown 编辑器是 Typora ，支付 14.99 美元的一次性费用就可以让开发者终身使用它的全部强大功能。在每一位 Markdown 语言使用者的漫长技术生涯里，这点小数目不过分厘，为什么我们依旧执着一款免费开源的 Markdown 编辑器软件？Zettlr 开发者的一席话 3 在深深打动了我的同时帮助我给出了这个问题的答案： 从开发者的角度，开源软件对科学的完整性、透明度、协作和创新都至关重要——如果缺少开源的资讯，我们很难通过研究源代码的技术栈和具体实现帮助自己学习如何开发一款类似（乃至更好）的软件，对于我们的软工项目如此，对今后的个人兴趣或者职业发展更是如此；而从用户的角度，开源软件的优势在于免费和强大的可扩展性，后者使其比专有软件更加安全、可靠和具有强适应性——有不符合自己心意的地方？改就是了！而且，免费开源并不意味着软件不能给开发者带来收益，来自用户的捐款、衍生社区的活跃度与质量都可以化作开发者的物质与精神食粮。 最后我想谈一个私心，就是我一直以来对开源精神的无条件推崇：共享、协作、创新……我看到，一切互联网世界的美好品质都与之重叠。 注：本文在作者本地环境下由 MarkText 书写完成。 面包与水仙花：对 Markdown 编辑器的基本要求免费开源不意味着质量品控上的肆意妄为。保证开源软件的质量，既有利于提高用户的满意度和信任度，进而增强软件的竞争力和影响力，促进软件的持续改进和发展，也有助于维护开源社区的声誉和凝聚力，激发更多的人参与到开源项目中来，形成良性循环。因此，我在此先通过需求分析，对 Markdown 编辑器类软件提出一些 基本要求 ，后文中的软件评测标准也将以此为基础。 Markdown 语言的应用需求分析根据日常生活实践与网络上的简单资源4，我们可以将不同用户类型及他们对 Markdown 语言的需求总结如下表： 用户类型对 Markdown 语言的应用需求技术开发者编写网站；撰写技术文档或技术博客；编写 Gitbook；编写电子邮件；……学生记录学习笔记；撰写对格式无严格要求的文本作业；技术开发者的应用需求；写作者撰写对格式无严格要求的文本材料；编写电子邮件；可以看到人们的使用需求涵盖了 Markdown 的几乎所有语法特性，甚至对高级的扩展功能有所要求（比如绘制 Mermaid 图、五线谱等），而且很多时候这三种类型的用户身份是存在 重叠 的。因此总结而言，从基础语法到拓展语法，我们希望一款 Markdown 编辑器能够支持的语言特性 越全面越好 ，因而才能“一骑当千”，用一款软件满足几乎所有类型用户的几乎所有需求。经调研，我打算直接使用 MarkdownGuide Tools 页 5 中对编辑器语言支持的分析表格 Markdown Support ，作为基础的语言需求评估标准。 下图为 Typora 软件的表格分析结果，权作示例。
有很多我们对”语言“的要求，实际上是对编辑器的要求，譬如： 所见即所得，支持即时渲染 当然，也要支持合适的 Markdown 源代码 + 预览编辑模式（这一点属于交互逻辑的讨论范畴）支持 LaTeX 语法数学公式的渲染 绝大部分技术文章都需要支持数学公式渲染支持 Mermaid 或其他绘图语言的图例渲染 写文章时需要不断切换软件去画图着实比较烦人支持导出文件为 XHTML、HTML、PDF 等格式 舒适的交互逻辑 …… 但我认为我们也不应该对一款 编辑器 有过多冗余的要求，事实上，我们应当拿来与之对标的更像是 Microsoft Word 而非 Notion ，所以我们不应该在以下这些角度上进行评测： 支持文件的云存储 支持本地备份已经足够 支持与版本管理工具的协同运作，可以直接上传仓库或者博客网站（大多数浏览器端 Markdown 编辑器的一大卖点） 开发者对文档根目录自主部署远程仓库已经足够 支持文件树的无限嵌套 这一点通过自建文件夹就可以解决 支持移动端和多人在线协作 😅 …… ……因此我仿照上节中的语言支持表，基于对编辑器功能需求的调查分析 6 ，列出了一个分析表格 Editor Support ，以服务后面的软件评测打分环节。 功能描述备注语言支持相关代码高亮渲染能支持的语言类型应当尽可能多基于 LaTeX 语法的数学公式渲染能渲染的类型应当尽可能多使用 Mermaid 等语法编写和显示甘特图等图表支持定制写作偏好定制缩进样式；自动匹配成对的 Markdown 字符、半角 & 全角括号和引号；拼写检查；修改不同风格的换行符；应用交互相关支持多窗口 / 多标签页和分屏模式能在多个窗口 / 标签页上同时查看和编辑多个 Markdown 文档，形成合适的分栏或分页（类似一般的 IDE）；支持文件的本地保存与定时备份同时支持即时渲染模式和源代码模式对于源代码模式，最好能够左右分屏：左侧写作，右侧预览效果，实时查看最终呈现焦点写作模式能在写作时专注于当前文件 / 行 / 段落，隐藏其他内容或干扰元素丰富的导出选项支持 HTML、Word、PDF、Epub 等多种格式（应当尽可能多），并保持原有的排版效果主题风格自定义可以通过编写 CSS 主题文件等自定义当前编辑器的主题和渲染模式；支持对不同的文件应用不同的渲染主题；支持标签系统（包括标签的检索与统计等）通过在文件的 YAML 中添加 tag 信息完成位置合理的工具栏快捷操作能够通过工具栏来快速插入常用的 Markdown 语法元素（如标题、列表、链接、图片等），并且能够调整字体大小、颜色、对齐方式等样式属性；支持字数统计文档的文字规模比较大时不应该出现明显卡顿新手用户友好型的 Tutorials尤其是没有技术背景的用户多语言支持应当尽可能多图文插入相关支持图片拖拽上传支持自定义图片保存路径支持修改图片的位置和大小等便捷的复制行为复制文本时复制 Markdown 源码；粘贴表格等文本时能够成功渲染成 Markdown；平台兼容相关支持 Windows、MacOS 、Linux 等系统其他软件的独特 Features此选项可酌情加减分 小径分岔的花园：桌面端与浏览器端生态的选择类似本地编写 LaTeX 文档和 Overleaf 的存在， Markdown 编辑器也存在着桌面端和浏览器端两种生态，如小径分岔的花园一般，对不同平台的选择实际上迈向了完全不同的使用体验。只不过我更倾向于选择并分析桌面端软件，原因如下： 桌面端软件可以离线使用，不需要网络连接，更适合在没有网络或网络不稳定的情况下独立工作 试想一下，你是否很难接受一旦没网就无法使用 Microsoft Word 的体验？ 对于开源软件而言，桌面端软件可以更方便地进行改写源码或者安装插件等操作，进而增强 / 定制化编辑器功能桌面端软件更安全可靠，不会受到浏览器或网站的限制或干扰，在备份措施完善的情况下也更不容易泄露或丢失数据当然，并不是说浏览器端没有优点，它也有一些值得用户考虑的高光，比如跨平台、易于分享与同步、易于进行版本管理、一般会集成云存储功能、社区用户之间可以分享开箱即用的模板或者主题（但我调研的两款浏览器端编辑器 StackEdit 和 Vditor 似乎都没有在这方面上做文章）等。 但总体来说，从功能与使用场景多样性、软件性能、安全等方面考虑，我个人认为还是桌面端更胜一筹。 一. 软件调研与评测 评测环境 设备环境
MarkText : v0.17.1 Zettlr : v2.3.0 软件评测 评测标准量化指标软件评测分满分 10 分，评测标准由语言应用需求、编辑器功能和杂项标准组成，评分比例为 4 : 4 : 2 。基于此评分，我会酌情给出推荐或不推荐的评价。 语言应用需求满足表 (4 / 10)针对下表所述的 25 种 Markdown 语法特性，考虑其中的某一特性：如若编辑器软件能够全部支持，得 10 分；部分支持，得 5 分；不支持，得 0 分。最终对 25 个评分取算术平均，作为语言应用需求项的最终得分。该项得分占最终得分的 40% 。 每一项语法特性的具体介绍见 Markdown 官方描述 7 。 ElementScoreHeadings10 / 5 / 0ParagraphsLine BreaksBoldItalicBlockquotesOrdered ListsUnordered ListsCodeHorizontal RulesLinksImagesTablesFenced Code BlocksSyntax HighlightingFootnotesHeading IDsDefinition ListsStrikethroughTask ListsEmoji (copy and paste)Emoji (shortcodes)Automatic URL LinkingDisabling Automatic URL LinkingHTML最终算术平均得分 编辑器功能满足表 (4 / 10)针对下表提到的 21 种选项：前 20 项为打分制，单项满分为 10 分，最后对 20 项评分取算术平均；最后一项是偏主观的加减分选项（针对编辑器功能部分的总分），我会在加减分之后给出具体的理由。 该项得分占最终得分的 40% 。 功能描述备注Score语言支持相关代码高亮渲染能支持的语言类型应当尽可能多基于 LaTeX 语法的数学公式渲染能渲染的类型应当尽可能多使用 Mermaid 等语法编写和显示甘特图等图表支持定制写作偏好定制缩进样式；自动匹配成对的 Markdown 字符、半角 & 全角括号和引号；拼写检查；修改不同风格的换行符；应用交互相关支持多窗口 / 多标签页和分屏模式能在多个窗口 / 标签页上同时查看和编辑多个 Markdown 文档，形成合适的分栏或分页（类似一般的 IDE）；支持文件的本地保存与定时备份同时支持即时渲染模式和源代码模式对于源代码模式，最好能够左右分屏：左侧写作，右侧预览效果，实时查看最终呈现焦点写作模式能在写作时专注于当前文件 / 行 / 段落，隐藏其他内容或干扰元素丰富的导出选项支持 HTML、Word、PDF、Epub 等多种格式（应当尽可能多），并保持原有的排版效果主题风格自定义可以通过编写 CSS 主题文件等自定义当前编辑器的主题和渲染模式；支持对不同的文件应用不同的渲染主题；支持标签系统（包括标签的检索与统计等）通过在文件的 YAML 中添加 tag 信息完成位置合理的工具栏快捷操作能够通过工具栏来快速插入常用的 Markdown 语法元素（如标题、列表、链接、图片等），并且能够调整字体大小、颜色、对齐方式等样式属性；支持字数统计文档规模比较大时不应该出现明显卡顿新手用户友好型的 Tutorials尤其是没有技术背景的用户多语言支持应当尽可能多图文插入相关支持图片拖拽上传支持自定义图片保存路径支持修改图片的位置和大小等便捷的复制行为复制文本时复制 Markdown 源码；粘贴表格等文本时能够成功渲染成 Markdown；平台兼容相关支持 Windows、OS X、Linux 等系统前项算术平均分——其他软件的独特 Features根据此选项酌情加减分最终得分—— 其他量化评测标准 (2 / 10)本项主要从开源项目的角度出发进行讨论，基于以下几个标准，以加分制评估软件的质量： 评估标准Score开源项目热度最新版本发布后的单日下载量Github Stars & Forks 数量开源项目活跃度项目的 Issue 和 Commit 数量项目的 Contributors 数量是否具有完善的社区生态，以及社区的活跃度开源项目代码质量项目报告的 Bug 数量及其修复率在具体的评测环节，我会借助一些工具对这些标准进行量化。该项得分占最终得分的 20% 。 具体分析内容基本步骤是：展示软件基本页面、按照指标量化表进行逐一评测并打分。 MarkText 软件基本页面展示软件的基础页面如下图所示。
点击左上角的 “W 4853” 处可以查看文本规模统计并切换单位（字 / 词 / 段落），点击三条横杠的图标可以召出工具栏。
点击左下角的设置图标则可以召出设置页面。
点击左侧边栏可以切换文件树、搜索和文档大纲视图。 指标量化表评分：7.2 / 10 第一部分：语言应用需求满足表此处直接引用官方文档中的分析表格 Markdown Support 作为评分标准（经过笔者亲自测试）：
得分: 9.2 / 10 。 第二部分：编辑器功能满足表 功能描述具体表现Score语言支持相关代码高亮渲染能够正常渲染代码块高亮效果，并提供了复制代码块选项，不支持行号显示； 代码块内不支持成对括号和引号等的自动匹配；支持的代码语言数量很多，虽然没有官方和民间的具体统计数目，但直觉上覆盖了大部分的代码语言7基于 LaTeX 语法的数学公式渲染可以正常渲染内联数学公式和公式块； 不像 Typora 那样会对公式块内的公式进行自动编号，而是需要使用 \begin...\end 语法（对笔者而言，这是一个好处）； 基于 KaTeX 而非 MathJax 实现渲染，因此对 LaTeX 语法的支持不够完备7使用 Mermaid 等语法编写和显示甘特图等图表支持使用 js-sequence-diagrams 、mermaid 、vega chart 、flow chart 和 plant-uml-diagrams 5 种代码绘图语言的代码块绘制不同风格的图表（手绘风和简约风）；  支持右键直接插入上述语言的图表段落，但需要对相应的语法有预先了解 9支持定制写作偏好支持定制缩进样式、编码格式、字体样式及大小（正文与代码块分别设置）、行高、编辑器宽度、窗口缩放规格、自动保存时间、书写方向等偏好设置；（划线部分是 Typora 所没有做到的重要功能） 只在段首支持自动匹配成对的 Markdown 字符、半角括号和引号；（题外话：笔者见过唯一一个支持全角括号引号匹配的编辑软件是中国的幕布）只支持英语的拼写检查；不能像 Typora 和 Visual Studio Code 那样，选定了一段文字再按单侧成对符号将整段文字括起来；选择文字后可以召出一些基本的文本样式编辑选项 9应用交互相关支持多窗口 / 多标签页和分屏模式支持 Tab 栏，也是笔者对 Typora 最不满意的一点； 侧边栏的排版非常舒适，但内容顶格，穿过字数统计组件的时候看起来略显丑陋； 不支持单窗口内的左右分屏，也无法右键单击文件树中的文件选择”在新窗口中 / 在新标签页中打开“的选项，想要完成分屏只能另开新窗口重新打开文件 7支持文件的本地保存与定时备份支持定时自动保存 10同时支持即时渲染模式和源代码模式需要在工具栏中找到 View 选项或者按快捷键才能切换源代码模式，不够方便； 源代码模式不支持一边是源代码一边是预览的左右分屏，且高亮配色方案非常丑陋 4焦点写作模式支持打字机模式和专注模式10丰富的导出选项仅支持导出为 HTML 和 PDF 格式，导出的定制化选项较多但都是些无关紧要的内容（如字体、页眉页脚等）； 导出后的文档样式默认支持 3 种主题，且与编辑器内简洁漂亮的视图基本上没什么相关，脚注与标题样式均失效，无法自动形成目录，体验非常差（导出文件能保持编辑器内样式是笔者一直在电脑里留着 Typora 的原因）； 可以通过修改对应的 CSS 样式代码修改导出效果，明显很麻烦2主题风格自定义只能使用默认的 6 种主题样式，不支持用户自定义，但还好默认样式比较漂亮；主题是全局设置，不支持不同文件不同主题3支持标签系统（包括标签的检索与统计等）不支持标签系统；0位置合理的工具栏快捷操作能够通过左上角工具栏、段首提示符、选择文字后的悬浮窗等来快速插入常用的 Markdown 语法元素（如标题、列表、链接、图片等）和段落，能够调整对齐方式等样式属性，排版布局都比较合理；支持字数统计；操作表格的逻辑（选择不同列的单元格、增删行列、修改内容位置等）非常舒服  7文档规模比较大时不应该出现明显卡顿打开 100 万字中文文档在 Windows 系统下测试时存在滑动侧边栏轻微卡顿、框选文字轻微卡顿的情况8新手用户友好型的 Tutorials没有内置的 Tutorials 文档或者演示动画，需要自行查看 Github 库内的官方文档，但官方文档的内容十分详尽5多语言支持软件本身只支持英文，但可以进行多语言编辑5图文插入相关支持图片拖拽上传√10支持自定义图片保存路径√10支持修改图片的位置和大小等√，交互非常人性化 10便捷的复制行为复制文本时可以复制 Markdown 源码；粘贴表格等外来文本时能够成功渲染成 Markdown，但前面会谜之带上一个 CSS 样式代码块，需要手动删除，这种情况在 Typora 里没遇到过 7平台兼容相关支持 Windows、macOS、Linux 系统√10前项算术平均分——7其他软件的独特 Features包含自动设置的图床上传，支持 sm.ms ，picgo 以及 github ；快捷键绑定和插入不同样式新段落的设计做得比较人性化，可惜实现上瘸腿，涉及数字的快捷键基本都不凑效；文件大纲支持展开与折叠；部分不兼容传统 Markdown 语法，如 ==text== 无法高亮，高亮语法是 ；不支持 Typora 那样直接插入 HTML 块，严重影响博客用户体验；很多体验上的问题可以通过自主修改源码解决，但这样对非技术类型的用户很不友好- 0.5最终得分——6.5
第三部分：其他量化评测标准
在评估开源项目质量之前，还有一个需要描述的问题：在打开同样的工作区和文件的情况下，MarkText 的内存占用情况是 Zettlr 的五倍多，略高于 Typora ，可能与软件性能漏洞有关。 本项得分 5 / 10 。 评估标准具体表现开源项目热度最新版本发布后的单日下载量MarkText 的最新版本（0.17.1）在发布后的两个月内有 7,000 多次下载Github Stars & Forks 数量 开源项目活跃度项目的 Issue 和 Commit 数量 过去一个月内的活跃度： 项目的 Contributors 数量 项目的贡献活跃度（可以看到近年来逐渐变少）： 是否具有完善的社区生态，以及社区的活跃度未有找到官方的讨论 / 分享站点开源项目代码质量项目报告的 Bug 数量及其修复率 笔者认为该项目的问题修复情况比较复杂，作为一个开源软件，它依旧存在许多繁杂的问题。例如前面提到的导出文件无法生成 TOC 目录问题 2018 年就已经有人提出，至今未被修复
用户采访调研
采访调研部分录入的是被采访对象撰写的体验文档原文。 采访对象背景 个人背景 向恩达 ，北京航空航天大学 20 级计算机科学与技术专业学生，在吴际老师班级学习软件工程课程，试用目标软件半小时评测环境 设备名称 LAPTOP-IM014EEH 处理器 Intel® Core™ i7-8750H CPU @ 2.20GHz 2.21 GHz 内存 8.00 GB (7.88 GB 可用) 系统类型 64 位操作系统, 基于 x64 的处理器 版本 Windows 10 家庭中文版 版本号 20H2 安装日期 2021/3/19 操作系统内部版本 19042.1466 MarkText: v0.17.1 采访实证  实际使用的产品功能 文档编辑 各类快捷键使用 公式块插入 代码块插入 图片插入 导出 HTML 与 PDF 文件 切换不同编辑模式 切换不同主题 上手使用过程的难易评价 作为使用过 typora 的用户，MarkText 的上手是较为容易的，半小时足以熟悉常用的大部分功能使用过程中遇到的亮点 笔者点评：其实有一些功能在 Typora 中也有，而用户却没有发现，因此也是交互设计上的一些优势体现吧！ 实时渲染流畅，未出现崩溃或明显 bug 能够分开显示总字符数和文字数量 能够切换 source code mode 和 typewriter mode 等不同的模式，而 focus mode 之前未曾在其它编辑器见到过，是一个有趣的尝试 增加了一些可以直接插入使用的小模块（Order list、Bullet list 等），可能对新手比较友好 支持插入图片的滑动缩放和居左 \ 中 \ 右（typora 好像不行？） 代码高亮相当醒目（typora 的像一坨 shit ） 使用过程中遇到的问题 标题快捷键（ctrl+1、ctrl+2…）似乎无法奏效 输入文本后的快捷键不够方便。比如输入一小行文本后 ctrl+B ，不能将已有的文本加粗 切换编辑模式后字符统计会发生变化，字数统计有微小误差（在一句话的末尾添加第一个符号时会增加一个文字数量） 采访对象觉得从用户体验的角度来说需要改进的地方 考虑添加一个启动弹出的简单新手教程左上角的字符、段落数量功能显示可以更人性化菜单栏稍显朴素，外观和位置都欠缺打磨 综合评价虽然 MarkText 在量化评分里得到了还不错的中庸分数，但事实上，光导出样式这一项的巨大问题已经足以使我 不推荐 这款编辑器软件（我至今需要保留 Typora 作为一个合乎常理的导出工具）。但综合考虑其余的可取之处，我只会将这款软件推荐给同时具备以下特性的用户： 有技术基础（尤其是前端基础），具备修改源码能力和阅读技术文档的良好习惯 有英语基础 对编辑器软件的布局和操作逻辑有比较高的审美要求 经过这么多工作，你一定有充分的理由给这个软件下一个评价: a) 非常不推荐 b) 不推荐 c) 一般 d) 好，不错 e) 非常推荐 我的答案是 c) 一般 。 Zettlr 软件基本页面展示软件的基础页面如下图所示。（开启软件后后台会频繁出现系统通知，有点烦人）
工具栏和设置页面等如一般软件设置，布局于页面正上方。 Zettlr 的使用定位 偏学术 ，因此支持标签系统、参考文献导入、通过为每个文件生成 ID 来支持文件之间的相互链接、查看当前文件夹下的非 MD 文件等功能。这些部分可以在右侧边栏查看。 指标量化表评分：6.26 / 10 第一部分：语言应用需求满足表此处直接引用官方文档中的分析表格 Markdown Support 作为评分标准（经过笔者亲自测试，HTML 和 HighLight 两个选项是支持的）：
由于不支持很多关键语法特性的渲染，我几乎没法使用 Zettlr 正常打开任意一篇电脑中的 MD 文档，所以我认为要在算术平均分上再减分。 得分: 5.4 / 10 。 第二部分：编辑器功能满足表 功能描述具体表现Score语言支持相关代码高亮渲染能够正常渲染代码块高亮效果，但 ```前缀无法取消，不支持行号显示，渲染外形上有些丑陋； 代码块内输入代码支持括号和引号等的自动补全，可以将分支结构折叠起来（见左侧的灰色小箭头），书写体验较好；支持的代码语言数量不是太多 7基于 LaTeX 语法的数学公式渲染可以正常渲染内联数学公式和普通样式的公式块，不像 Typora 那样会对公式块内的公式进行自动编号，而是需要使用 \begin...\end 语法，且如果本机没有安装 LaTeX 的话，会出现包括编号渲染在内的多种形式错乱，导出 PDF 中的公式也没法正常显示，应该是渲染引擎的选择问题（其他两个软件没有这种现象）； 输入公式的时候不会提供任何预览，甚至会输着输着失去高亮，体验极差；基于 KaTeX 而非 MathJax 实现渲染，因此对 LaTeX 语法的支持不够完备3使用 Mermaid 等语法编写和显示甘特图等图表支持通过 Mermaid 代码块生成图表 7支持定制写作偏好支持缩进样式定制等基础的偏好设置；支持改变字体大小；支持自定义特殊字符串的替换； 6应用交互相关支持多窗口 / 多标签页和分屏模式支持 Tab 栏； 在 Windows 环境下，左侧工作区和文件树的使用逻辑非常反人类（只有支持多文件夹这一点比较人性化），譬如：只通过颜色区分文件夹和文件 工作区里只显示文件夹，想查看文件得直接点进去 样式丑陋，图标含义不明所以； 2支持文件的本地保存与定时备份支持自动保存，但描述很奇怪 5同时支持即时渲染模式和源代码模式不支持源代码模式0焦点写作模式支持专注模式打字机模式10丰富的导出选项基于 Pandoc ，可以导出文档的格式比较丰富； 导出文件的默认样式是这种学术文章风格的，目录和脚注不会失效，但反人性的一点是无法指定导出目录，只能选择导出到临时目录或者当前目录； 有丰富的导入导出选项供修改，但使用起来需要查看文档； 6主题风格自定义只能选择 5 种自带的应用主题，且都非常丑陋 3支持标签系统（包括标签的检索与统计等）√ 有完善的标签统计与检索系统（通过在 YAML 中添加 tag 字段实现，可以定制标签颜色），可以通过标签查看相关文件，并形成关系图  8位置合理的工具栏快捷操作模仿代码 IDE 的工作区想法是很出彩的；默认三栏视图，侧栏可关闭，可在设置页选择三种排版方案，但个人认为都 非常丑陋 且存在功能冗余（如两个字数统计、两个设置召出键、两个工作区召出键和一个不明所以的内置番茄钟按钮）； 支持通过选择文字后的悬浮窗快速插入常用的 Markdown 语法元素（如标题、列表、链接、图片等）； 4文档规模比较大时不应该出现明显卡顿打开 100 万字中文文档在 Windows 系统下测试时无渲染卡顿情况10新手用户友好型的 Tutorials工作区长期停靠官方英文文档，内容还算详尽 8多语言支持不论是软件本体还是拼写检查都支持多语言  10图文插入相关支持图片拖拽上传√10支持自定义图片保存路径√ （但指引比较模糊，比如没有给 ${filename} 这样的格式提示）8支持修改图片的位置和大小等均不支持随意修改，仅在插入剪贴板图像时会弹出这样一个弹窗要求定制化； 且图片预览模式奇怪 5便捷的复制行为复制文本时可以复制 Markdown 源码；粘贴表格等外来文本时不能够成功渲染成 Markdown，会被渲染成图片进行粘贴5平台兼容相关支持 Windows、macOS、Linux 系统 8前项算术平均分——6.25其他软件的独特 Features强大的引文系统； 书写统计功能丰富；  提供基于标签系统和自定义链接语法 [[File]] 的本地文件链接功能，可以形成文档关系图和方便的文件跳转； 可以导入多种类型的文本文件，简单渲染成 Markdown； 意义不明的内置番茄钟，个人认为是冗余功能+ 0.5最终得分——6.75
第三部分：其他量化评测标准
本项得分 8 / 10 。 评估标准具体表现开源项目热度最新版本发布后的单日下载量根据 GitHub 的 release 页面，Zettlr 的最新版本（2.3.0）在发布后的一个月内有 10,000 多次下载Github Stars & Forks 数量 开源项目活跃度项目的 Issue 和 Commit 数量 过去一个月内的活跃度： 项目的 Contributors 数量 项目的贡献活跃度（和 MarkText 差不多的创建时间，热度一直比较高）： 是否具有完善的社区生态，以及社区的活跃度有完善的官方网站和社区（且支持多语言访问）：zettlr；获得了许多院校的支持： 开源项目代码质量项目报告的 Bug 数量及其修复率 Bug 数量远远多于 MarkText （使用过程中小问题数不胜数），但开发者方解决问题的态度比较积极
用户采访调研
采访对象背景 个人背景 杨恩源 ，北京航空航天大学 20 级计算机科学与技术专业学生，在欧阳元新老师班级学习软件工程课程，试用目标软件半小时评测环境 设备名称 DESKTOP-VD3O4GQ 处理器 11th Gen Intel® Core™ i7-11390H @ 3.40GHz 2.92 GHz 机带 RAM 16.0 GB (15.7 GB 可用) 系统类型 64 位操作系统, 基于 x64 的处理器 版本 Windows 10 家庭中文版 版本号 21H2 安装日期 2021/12/9 操作系统内部版本 19044.2604 Zettlr : v2.3.0 采访实证 实际使用的产品功能 文档编辑 各类快捷键使用 公式块插入 代码块插入 图片插入 导出html与PDF文件 切换不同编辑模式 切换不同主题 上手使用过程的难易评价 Zettlr 的上手较为容易，在有过其他 markdown 软件使用经验的基础上，可以在短时间内掌握基本的使用方法使用过程中遇到的亮点 能够显示总字数，同时显示当前光标的行列位置拥有工作区的工作模式，侧边栏显示多个文件标题，能够同时进行多个文件的编辑下载插件后支持 LaTeX ，相比于 typora ，更适合进行论文编辑等更为专业的操作可以在插入代码块的同时选择代码语言，提高了编辑效率选择字块后弹出编辑栏，可以快速对选中字块进行加粗、超链接、设置为图片标题等编辑，操作方便大部分快捷键与其他软件相同，可以快速上手虽然并不是完全的所见即所得，但有检视模式，可以查看有无语法错误情况使用过程中遇到的问题 重命名文件时容易因误触而出现失败的情况打开设置时，上方选择栏显示在屏幕之外且无法调整位置导出文件需要 Pandoc ，但是没有内置或者提供 Pandoc 的下载方式采访对象觉得从用户体验的角度来说需要改进的地方 可以增加预览模式，查看实际效果修正设置显示的bug 综合评价个人认为，语言支持的不完备性和交互逻辑 / 界面审美的落后使得 Zettlr 作为一款 Markdown 编辑器（至少其主页自称为 Markdown editor of 21st century ）而言是不够合格的，即使其以学术写作导向为理由也好（以学术写作为宣传噱头，公式渲染支持上居然有严重的交互硬伤），因此我目前不会向用户推荐这款编辑器。但用它来进行参考文献管理等工作可能会比较方便，它的标签系统和工作区设计思路也是值得借鉴的。 经过这么多工作，你一定有充分的理由给这个软件下一个评价: a) 非常不推荐 b) 不推荐 c) 一般 d) 好，不错 e) 非常推荐 我的答案是 c) 一般 。 披榛采兰：与 Typora 对比不管怎么说， Typora 应该都是用户们心中那款 Markdown 编辑器界的“白月光”，这里简单从用户的角度谈谈它与本次分析的免费开源软件相比有哪些超然之处： 选择文字后再按单侧成对符号（如括号、引号、撇号等）都可以自动将文字包括起来，非常方便 主题样式丰富又漂亮，有完整的主题社区，在有前端基础的前提下自定义主题也非常容易，最重要的是文件导出效果与编辑器内视图一致——我实在不明白为什么两个开源软件都没有做这一点 支持段落的首行缩进、编辑位置记忆和选中部分的字数统计等，交互细节很丰富 支持导出的样式丰富 完备的数学公式渲染 完备的成对半角符号自动匹配模式 编辑器视图内正常渲染脚注 在内容大纲和 TOC 处支持 Markdown 语法的渲染（该功能从这两个开源软件到 CSDN 文章编辑器都不支持，目前只用过 Typora 是支持的） 支持插入 HTML 块和 CSS 样式，非常方便博客作者自定义文章内的组件 支持软件内使用开发者工具调试 Bug 分析与提交 Bug 严重星级量化指标五星级 Bug 软件闪退、卡顿、无法启动 文件数据丢失或损坏 可能存在信息安全隐患的软件漏洞 四星级 Bug 因大数据等压力测试导致的渲染失败或软件崩溃等问题三星级 Bug Markdown 语法元素渲染失败：针对官方宣布可支持的语法元素二星级 Bug 未成功实现官方宣布可实现的非 Markdown 编辑核心功能，如图床上传等 影响体验的细微语法元素或软件 UI 的渲染错位 一星级 Bug 无伤大雅的细微语法元素或软件 UI 的渲染错位 Bug 具体情况提前说明： 关于 MarkText 导出的 PDF 文件无法根据标题生成 TOC 目录和脚注失效的问题（包括文档内无法渲染 TOC 的问题），原作者已经在 Issue 中回答过是技术栈限制，因此不再算作 Bug 处理。这两个软件都是基于 Electron 框架开发的，我们知道该框架存在着一些安全性漏洞 8 ，可能允许恶意的 HTML 文档访问用户的电脑，因此可以认为“ Electron 框架的 Bug 就是它们的五星级 Bug ”，后文不再详细提及。 MarkText针对 MarkText 软件，据笔者调研，作者因为个人原因已经很久没有维护过该项目9，因此不对 Bug 的”可能不修复的原因“做出具体讨论。 Bug1：⭐⭐⭐⭐笔者生成了一个 100000 行的 Markdown 表格数据，将其粘贴到软件中时，软件会持续卡死无响应，只能从任务管理器强制关闭。该情况稳定可复现，且在 Typora 和 Zettlr 中都不会出现。 拓展测试：生成 100000 行的无序列表数据、纯文本数据粘贴到软件中依旧卡死，在其他两款软件中不会出现这种情况 可能成因 软件本身不支持处理超过一定行数或列数的数据，类似 XLS 格式的 Excel软件本身的性能或者内存存在问题 没考虑到剪贴板中的数据量和内存占用没处理好剪贴板中的数据格式，没有使用合适的方法或接口来读取数据 Bug 修改建议 进一步检查软件性能上的漏洞，尤其是读取剪贴板数据接口的选择 Bug2~6：⭐⭐⭐主要为以下几个 语法元素渲染错误 问题： 在文档大纲中无法正确渲染官方宣布支持的 Markdown 语法，也即：对标题使用 Markdown 语法后无法在大纲中也渲染出来，像 Typora 那样 正文： 大纲： Typora 中的表现是正常渲染： 使用 $$MATH BLOCK$$ 语法插入数学公式时，总是会错误地多生成一对 $$ 号
与源代码的对照： 在 Typora 和 Zettlr 中都正常： 导出 PDF 文件无法正确渲染 Mermaid 图 视图内正常显示： 导出为 PDF 后： typora 的表现（正常渲染）： 拓展测试：测试软件内支持的 5 种绘图语言和 PDF、HTML 两种导出格式，结果是除了 PDF 格式下的 Mermaid 图都能正确渲染出图像，HTML 格式下的 Mermaid 图还存在渲染错位的问题。
所有与数字键组合的快捷键均不凑效，例如 ctrl + 1 、ctrl + 2 插入标题 对脚注的识别与渲染不稳定
其中，关于可复现性： 在多文档、多级目录、不同种类语法中都稳定可复现在不同文档中、插入多条公式块都稳定可复现插入不同类型的 Mermaid 图（流程图、甘特图、时序图）导出为 PDF 和 HTML 都稳定可复现在同学的设备上也稳定可复现，应该跟自己的键盘无关复现情况不稳定，大部分时候后接半角 / 全角标点符号的脚注可以识别，也偶有识别失败；大部分时候句中 / 脚注内容非纯数字的脚注不可以识别，也偶有识别成功。识别失败的脚注本身是稳定的，即渲染失败的脚注会恒定识别失败，在其他机器上测试依旧渲染失败。 可能成因 大纲部分的渲染没有完全引入 Markdown 语法，而是直接使用了纯文本当在一对双 $ 号之间插入公式时，会错误地基于前一个双 $ 号自动生成一个匹配的代码块，把后一个给忽略了软件本身对 Mermaid 图绘图语法的支持存在漏洞识别热键出现漏洞，测试人员不够上心脚注语法匹配逻辑存在问题，测试人员不够上心 Bug 修改建议渲染文档大纲时支持 Markdown 语法 检测到双 $ 号插入数学公式块时先对文档中的双 $ 号做匹配，如无匹配结果再自动生成 加强对 Mermaid 图的支持 或者放弃对 Mermaid 图的支持…… Bug7：⭐⭐会自动删除文件内的空行。具体情况是：在文件中插入空行后关闭，如果用 MarkText 再打开就会自动将空行删去，后面再用 Typora 打开也是无空行的版本；如果持续使用 Typora 操作则不会对空行产生影响。 Typora 下的场景： 用 MarkText 再打开：
创建有空行的文件，按照上节的描述操作稳定可复现。 可能成因软件对文档采用了某些奇怪的 formatting 规则，没太考虑用户的感受。 Bug 修改建议取消可能存在的 formatting 规则。 未能稳定复现的 Bug8~10在文本量比较大的文件（测试用例：100000 词中文文档）内使用 Ctrl+A 全选不定时失效（忘了记录次数），一般重新打开文件后又正常 测试把关不严，结合前面提到的大数据卡顿问题，怀疑跟软件本身性能有关在任意一种主题配色下收起侧边栏都会导致页面的右侧出现一大块空白和左侧字数统计 UI 错位（暗色模式比较明显），如下图所示。
初始时检测不到电脑上已安装的 Picgo 图床，重复选择了 4 次之后可以检测，后续再打开软件都可以检测
个人感觉因为这款软件还不太成熟（因此现在相关的 Contribute 也很活跃），所以使用的过程中明显的 Bug 非常多，这里只挑一部分跟编辑体验强相关的讲。 据作者说，在 3.0.0 beta 版中修复了大部分琐碎的 Bug ，而且软件的界面也大改了，笔者评测的版本是最新稳定版。 Bug1~5：⭐⭐⭐主要为以下几个 元素渲染错误 问题： 在导出的 PDF 中无法正确渲染 Mermaid 图（编辑器内的样式也不是 Mermaid 的默认导出样式，很奇怪），可稳定复现
使用 1/2 屏幕宽度的子窗口模式时左上角工具栏、中侧 Tab 栏（中间那个无法再往左移完整显示文件名了）和右侧导航栏（无法移动，只能部分显示）均错位，可稳定复现
高亮语法渲染错误（会把那一对等号也渲染进去）+ 在高亮语法外包裹其他 Markdown 样式语法后高亮失效，可稳定复现
Typora 正常显示： 使用形如 | a | b | 的 Markdown 语法无法成功渲染出一个含内容的表格，只能将形如 | | | 的语法渲染成空白表格，可稳定复现
偶发不能正确识别本地 MD 文档的 tag 标签，如下图中的例子没有成功识别 “C 语言” 标签，原封不动地将该标签重新输入一遍之后问题得到解决。在笔者的博客文件夹工作区中，标签的正确识别率只有 10 / 17 . 但如果在软件内创建并编写文档，则不会出现该问题。
点击右上角的按钮关闭 / 打开侧边栏时，单击关闭侧边栏后再单击无法重新打开侧边栏，需要再双击，多次打开软件都稳定可复现 文件规模较大时（以 100 万字文档为例），滚动条和选择文字的操作会延迟，使用 Ctrl+A 全选文件内容时会有明显延迟（2 s 左右）， Typora 和 MarkText 没有这个问题，可以稳定复现 不知道算不算 Bug ：一直会将文档中所有形如 #text 的内容都识别成标签，而不是只识别 YAML 中的 tag field，导致标签系统产生混乱
关于标签识别错误的 Bug 已经提交到 Issue 中。
由于这两款免费开源 Markdown 编辑器软件都基于类似的框架和技术栈开发，所以在这一节一并讨论。 笔者认为，使用此服务的所有功能，团队人数 6 人左右（计算机大学毕业生，并有专业 UI 支持），可能需要四至五个月时间完成满足量化定义的开发： 需要半个月时间熟悉基于 Electron 框架和 JS 插件等的软件开发，以及 Markdown 编辑器的基础工作逻辑，还需要设计合理的 UX/UI （下图是 MarkText 源码的结构示例）
需要一周的时间细化功能需求，完善文档 需要半个月时间调研 MathJaX 等支持渲染的插件的使用 需要半个月时间设计编辑器界面，以及交互逻辑 当然，针对 Zettlr 这种程度的编辑器界面和交互可能只需要不到一个星期进行设计需要一个月进行具体的编码工作 笔者的实践经验不足，针对开发这块的时间估计很有可能非常不准确需要一个月进行集成功能测试、压力测试、最终的部署与上线 可能还需要时间准备一个官方的宣传站点，后续扩展成社区 软件质量分析 分析这个软件目前的优劣（和类似软件相比），这个产品的质量在同类产品中估计名列第几？ MarkText 优势 免费开源，可以在 Github 上获取最新版本并参与到项目开发中界面简洁美观，支持 Tab 栏，布局排版舒适支持的图表语言类型丰富对图片和表格的操作逻辑非常舒服 劣势 不支持方便地自定义诸如编辑器主题之类的一些高级功能或设置，缺少完善的分享社区 但软件本身的样式设计挺漂亮，把前端的一些自适应错误修复一下的话，无法定制主题是完全可以接受的 对导出样式等的自定义逻辑设计太不合理，导出样式与编辑器视图样式不一致本身就是反直觉的支持导出的格式过少存在不少未修复的 Bug ，但项目活跃度很低，作者本人似乎也对项目不太上心了 排名估计 根据前面笔者的亲身体验分析和相关网站的数据排名参考10，大约在 第 4 名 左右，仅次于 Typora 、使用基数庞大的 Visual Studio Code 和 Joplin 。 Zettlr 优势 学术写作特色 支持标签系统和多种格式参考文献的导入内置多种工作量统计支持本地文本文件之间的链接索引（不限 Markdown 格式） 免费开源，可以在 Github 上获取最新版本并参与到项目开发中，而且作者本身非常热情，开源社区活力满满，未来可期文件树和工作区的设计思路很好，感觉只是前端没跟上支持的语言和相关的拼写检查 / 翻译功能很丰富 劣势 不支持方便地自定义诸如编辑器主题之类的一些高级功能或设置不支持源代码编辑模式从低级的组件自适应到核心的学术写作功能都存在不少未修复的 Bug界面设计和交互逻辑过于丑陋对 Markdown 语法的支持仍存在不小的缺陷对不同平台的兼容性存在缺憾11 排名估计 根据前面笔者的亲身体验分析和相关网站的数据排名参考10，大约在 第 5 名 左右。 从各方面的问题，推理出这个软件团队在软件工程方面可以提高的一个重要方面 MarkText：修复导出样式与视图样式不一致的问题，支持更多的导出格式Zettlr：提高界面和交互逻辑设计的审美水平，优先修复主打的标签系统中存在的重大 Bug 三. 建议与规划分析主题：免费开源 Markdown 编辑器 市场概况分析目前，市场上有很多不同类型和功能的 Markdown 编辑器软件，例如 Typora、本文提到的两款开源软件、基于浏览器生态的 StackEdit 和 Vditor 、包括不能忽视的一众代码 IDE 等。这些软件各有优势和缺点，适合不同的用户需求和场景。例如，对非技术用户友好的即时渲染功能、利于定制化、推广化和促进开发的免费开源项目、通过强化对拓展语法的支持集成标签系统等功能的编辑器等。 从用户群角度考虑， 直接用户 自然是规模逐年增长 12 的程序员、计算机和软件相关专业的学生、极客等 IT 行业相关的群体，而可以预见的是，广大对自动排版、快速成书、网站快捷开发、专业文档快速成型等有要求的非 IT 行业文字撰写者（包括文科专业学生、编辑、教师、公司管理层等）都是 Markdown 编辑器的 潜在用户 ——随着用户群体深度和广度的扩展，Markdown 编辑器对免费、开源、高拓展性和定制化的要求会更高，我们可能要求一个更成熟的类 Zettlr 应用服务专业的学术写作和文献整理，也有可能期望一个真正集成了无代码门槛撰文和分屏编辑源代码功能的便捷工具；现在有使用 Markdown 语言制作排版精美的 PPT 的应用13，那么一个适于该领域的 Markdown 编辑器或者插件是不是也势在必行了呢？——免费开源的 Markdown 编辑器软件事实上有很大的市场潜力和需求。 市场现状目前市场上有什么样的产品了？ 笔者罗列出了以下四类具有代表性的开源 Markdown 编辑软件： MarkText：界面优雅简单、操作逻辑舒适的开源 Markdown 编辑器Zettlr：专为学术写作者设计的开源 Markdown 编辑器，支持文献引用和标签管理等功能Notable：集成了强大的搜索功能和标签系统的开源 Markdown 编辑器，更类似一个支持部分 Markdown 语法的笔记软件浏览器端的开源 Markdown 编辑器 StackEdit 和 Vditor上述产品的定位、优势与劣势在哪里？ MarkTextZettlrNotable浏览器端开源编辑器定位一款简约而优雅、支持多系统的开源 Markdown 编辑器一款专为学术写作而设计、支持多系统的开源 Markdown 编辑器一款简洁而高效的笔记型开源应用，具有很好的 Markdown 支持基于浏览器的在线 Markdown 编辑器优势界面美观；操作逻辑舒适；支持实时预览和所见即所得渲染模式；支持多种 Markdown 扩展语法和丰富的图表绘制语法提供了强大的文献管理、引用、标签、目录、文件链接等功能；支持多种格式的导出，包括PDF、HTML、Word、LaTeX 等；支持 Zettelkasten 方法和丰富的图表统计，可以帮助用户构建知识体系；开源社区活力较高，一定程度上保证了产品质量的可持续发展程度与一般的类 Markdown 笔记软件相比，直接使用本地文件系统存储笔记，方便同步和备份；提供了强大的搜索、标签、附件等功能，可以帮助用户组织和管理 Markdown 笔记无需安装任何软件，随时随地都可以使用；语法扩展功能和各种插件丰富（基于浏览器渲染）；有完整独立的用户社区；支持文档一站式发布到支持的博客平台上，无需自主配置仓库等；源代码模式支持分屏编辑预览！可以与 Google Drive 或 Dropbox 等云存储服务同步数据 （中性：不好评判是优势还是劣势）劣势导出功能太少，且导出样式不够美观；开源社区活力较低，产品质量与可持续发展程度难保证交互形式扭捏，前端界面丑陋，不符合时代审美；主打功能存在比较严重的 Bug；支持的语法类型太少；渲染存在比较严重的本地库依赖（如 LaTeX ），软件独立性不够不支持实时预览和所见即所得模式；不支持导出功能需要网络连接才能使用，无法离线保存数据上述产品之间呈现什么样的关系，哪些为竞品关系？以及竞争中的各方态势如何？ 首先，不可否认的是这几款开源软件的共同竞争对手都是不可忽视的非开源编辑器 Typora 和一众仍受技术人员追捧的代码 IDE （ Visual Studio Code 、 Atom 等），为了竞争出彩，它们都把发展重点投在了与源代码低相关的领域——开拓学术写作功能、集成笔记系统、设计对没有技术背景的用户而言也简洁易用的美观界面……Zettlr 和 Notable 等更关注“管理”功能的软件互为竞品关系，而浏览器端的编辑器更倾向于与关注“编辑”功能的 MarkText 产生竞争 市场与产品生态 核心用户群侧写A，35岁，中国人，计算机科学与技术专业硕士毕业，专职软件开发程序员 爱好：编程（尤其是尝试各种各样的 Toy 项目），阅读与编写技术博客，游戏收入水平：中高对开源 Markdown 编辑器的使用场景 编写代码文档、技术博客、演示文稿等 对开源 Markdown 编辑器的表面需求 支持尽可能多种编程语言的代码高亮、自动补全和预览等功能支持通过修改源码完成主题定制化，或者具有相关的分享社区支持源代码模式支持美观的自动排版 对开源 Markdown 编辑器的潜在需求 支持跨平台支持文档的加密和自动备份存储支持代码片段的文档内运行（如渲染简单的前端代码块）内置命令行终端或者开发者模式B，19 岁，阿联酋人，软件工程专业本科在读，学生 爱好：数学，撰写并分享课堂笔记与学习心得收入水平：低对开源 Markdown 编辑器的使用场景 编写作业、报告、论文、学习笔记等 对开源 Markdown 编辑器的表面需求 免费支持阿拉伯语的正确渲染与导出（也即要求编辑器支持多语言格式的渲染） 编辑器本身最好也支持阿语，且有相关语言的 Tutorials 支持数学公式、代码块的渲染，并且能支持的格式越多越好支持图表嵌入具有比较清晰的文件树 / 标签系统 / 引文管理系统 对开源 Markdown 编辑器的潜在需求 支持多文件格式的导入导出功能了解并参与开源生态，学习如何开发类似的编辑器软件C，28 岁，美国人，交互设计专业硕士毕业，自由职业写作者 爱好：写作，平面艺术，交互心理学收入水平：不固定，平均水平在中等对开源 Markdown 编辑器的使用场景 业余时间编写小说、博文等，工作时间编写相关的报告和文档 对开源 Markdown 编辑器的表面需求 界面简洁美观，交互逻辑舒适最好免费，或者收取比较少的一次性费用支持美观的内置排版、格式化、导出等功能支持所见即所得式的渲染 对开源 Markdown 编辑器的潜在需求 支持创意模式、灵感触发器、写作统计等功能 用户生态分析产品的用户群体之间是否存在一定的关系？是否有利用其相互作用二次构成特定用户生态的可能性？ 我认为他们之间存在着一定的关系，例如： 程序员可以吸取写作者对软件排版样式等的美学要求，开发丰富且开箱即用的自定义主题样式，为没有技术背景但对美术有需求的用户提供下载，进而促生软件的自定义主题生态社群，如 Typora Themes Gallery程序员和学生可以通过开源项目达成合作与协助，既能够帮助学生接触开源生态、提高计算机水平，又能够利用学生的创意与相对在职程序员而言的空闲时间促进开源产品发展产品的子产品，以及其他相关产品之间是否存在一定的关系？是否有利用各个产品特性之间的相互关系二次构成产品生态的可能性？ 免费开源 Markdown 编辑器的子产品，以及其他相关产品之间可能存在一定的关系，比如： 开源 Markdown 编辑器的子产品可能包括不同的主题、渲染插件、语法扩展等（比如支持渲染色盘、乐谱、多媒体14、更专业的学术论文格式等），从不同的角度为用户提供更多的个性化和功能化的选择，增加用户的使用体验和满意度其他相关产品可能包括更多 Markdown 语言的衍生生态，比如学术写作、对排版格式要求更高的文字写作、支持多种格式的导出、笔记管理、更专业的工作文档写作等，相信它们的开发都需要基于开源的生态 利用各个产品特性之间的相互关系二次构成产品生态的可能性也是存在的，比如开发集成了多种功能的编辑器，让用户在单一平台上完成从编写到发布的全流程，并且可以根据自己的需求和喜好选择不同的子产品和相关产品；或者建立产品相关的社区与分享平台，让用户可以在一个平台上分享自己使用或开发的子产品和相关产品，并且可以获取其他用户的反馈和建议，促进开源生态的繁荣，让更多人了解和使用 Markdown// 但事实上笔者本人不太支持这种集成式的产品生态，一款 “小而美” 的、专注于文本编辑功能的类 Microsoft Word 型文本编辑软件更贴近我对开源 Markdown 编辑器的期许。 产品规划 NABCD 分析你要在 当前软件的基础上 设计什么样的新功能？为何要做这个功能，而不是其他功能？为什么用户会用你的产品/功能？你的创新在哪里？可以用 NABCD 分析 。 功能 1：支持分屏预览的源代码写作模式Need（需求） Markdown 编辑器的用户通常是需要编写文档或博客的程序员或者其他 IT 专业人士，他们中的一部分人习惯了代码编辑器中的分屏预览模式包括强大的 Typora 和本文关注的两款软件在内的许多所见即所得型 Markdown 编辑器，都存在着即时渲染上的 Bug ，很多时候需要依靠切换源代码模式调整 Markdown 源码才能得到合适的效果。此时需要在编写源代码的同时实时地看到预览效果，以便调整格式和排版，而这些编辑器都没有做到这一点Approach（做法） 按下相关快捷键或组件切换到源代码写作模式后，在编辑器界面上将屏幕分为两部分，一部分显示源代码，另一部分显示预览效果。用户可以根据自己的喜好调整两部分的大小和位置 （以 Visual Studio Code 为例）
如有可能，我们还应该在 Tab 栏的基础上支持单窗口内多文件的分屏编辑模式 （以 Visual Studio Code 为例）
Benefit（好处） 可以让有需求的用户在编写源代码的过程中，随时检查预览效果，避免出现格式错误或者不符合预期的结果Competitors（竞争） 几乎所有支持 Markdown 语法的代码 IDE ，如 Visual Studio Code 、Atom 等 它们并非专注 Markdown 语言的编辑器，在用户专注度上有欠缺它们的分屏预览编辑模式已经非常成熟，界面和性能等都值得借鉴Delivery（推广） 通过 IT 专业人员占比高的博客网站和技术论坛等平台推广 功能 2：支持基于 YAML Front Matter 的标签系统Need（需求） 几乎所有用户群体都需要使用一种方便快捷的方式来组织、管理和查找他们的文件15，而不是仅仅依赖于文件树或搜索功能。标签系统可以让用户给文件添加多个标签，从而实现多维度的分类和筛选，并且基于标签系统，一个编辑器就具备了笔记工具和思维管理工具的功能——并且不需要为其扩展许多臃肿的功能让它背离文本编辑器的初心！只需要利用 YAML 中的 tag field 就可以。Approach（做法） 让用户可以给文件添加或删除任意数量和内容的标签，通过在 YAML Front Matter 中编写形如 tag: -tag1; - tag2; ... 的文字实现，基于 tag 信息的缩进，甚至可以支持标签的嵌套 让用户可以按照标签进行文件的浏览和搜索 集成一个标签管理选项，让用户可以在其中自定义标签的颜色和图标，以便于区分和识别 或者定义一种语法解析模式，通过解析标签前的颜色和 emoji 关键字，使用纯代码编辑标签属性，例如 （笔者瞎编的） ： tag: - [yellow][:joy:]Happy-Face - [Blue][:plane:]BUAA让用户可以导出或导入带有标签信息的文件 一般的博客文章 Markdown 源码都已经带有我们要求的标签信息，非常方便Benefit（好处） 提高用户的工作效率和体验，让用户可以更灵活地管理他们的文件符合大多数笔记用户的需求和习惯，增加用户对 Markdown 编辑器的黏性和忠诚度扩大 Markdown 编辑器的应用场景和目标人群，让更多不同领域和背景的人使用 Markdown 编辑器Competitors（竞争） 目前市场上已经有的一些支持标签系统管理文件的文献整理 / 笔记平台，比如 Evernote 、 Notion 等 它们主要是笔记类软件或平台，而我们的 Markdown 编辑器主要是文本编辑类软件，定位不同它们使用自己定义的格式 / 语法 / 操作逻辑来编写标签内容，如果想要导入之前的 Markdown 文档很可能需要重新手动设置标签信息，而我们直接利用大部分 Markdown 博客文章都已经具备的 tag field 信息，对于未设置相关信息的文章，再次添加标签也很方便它们提供了很多其他冗杂的功能和服务，例如协作、分享、模板等，而我们的 Markdown 编辑器则专注于提供最优质的 Markdown 写作体验Delivery（推广） 在官网上展示这一特点，并提供相关教程和案例在社交媒体上发布相关内容，并邀请技术型 / 文字型 / 学习型分享博主进行试用和评测在相关论坛或社区上发表文章或评论，并回答潜在用户的问题在各大应用商店上更新应用介绍，并鼓励现有用户给予好评 可能提升用户体验的细节功能 支持成对全角符号的自动匹配简化内嵌图表的绘图语言，如支持无序列表渲染为思维导图16 团队开发角色配置规划如果你是项目经理，可以招聘 6 个人 ，并且有 4 个月 的时间，你认为应该 如何配置角色 （开发，测试，美工等等）才能在第 16 周如期发布软件的改进版本，并取得预想中的成绩。 美工与 UX/UI 设计：1 人 此人同样需要参与前端开发与测试的代码工作 软件架构设计师：1 人 此人同样需要参与后端开发与测试的代码工作 专职后端开发与测试：1 人专职前端开发与测试：1人专职测试与 QA ：2 人 团队开发工期安排（16 周）请为你的团队设计 16 个周期每周的详细规划。 周数任务1完成需求分析；制定开发规范的文档细节；调研技术栈2后端和架构师：学习相关软件源码，设计软件架构，集成插件环境；美工：进行 UX/UI 设计，制定前端页面规范3【Alpha 阶段开发】 实现 Markdown 语法的即时渲染和分屏的源代码写作模式，进行语言渲染模块的单元测试并修复 Bug；初步构建编辑器界面前端架构4实现扩展语法、代码块和数学公式的渲染功能；完成语言渲染模块的单元测试并修复 Bug5实现基于 YAML Front Matter 的标签系统，完成相关单元测试并修复 Bug6细化软件交互功能：实现成对符号匹配、字数统计、划词悬浮窗、多格式文件导出等，完成相关单元测试并修复 Bug；完成软件偏好设置相关选项7完成多设备、多系统匹配功能及相关测试并修复 Bug ，进一步细化前端设计；进行高并发测试并修复 Bug8对所有的单元测试做回归分析，并修复 Bug9【中期总结】 进行 Alpha 测试并修复 Bug ；总结项目完成情况并给出具体反馈，制定 Beta 阶段具体计划10 ~ 14【Beta 阶段开发】 进行 Beta 测试并修复 Bug：测试人员对软件功能做具体功能测试、回归测试、集成测试和压力测试15开启内测，通过内测用户的反馈做进一步整改与 Bug 修复16部署简单的宣传站点，发布正式版本MarkText ↩︎ Zettlr ↩︎ Why is Zettlr Open Source? | Zettlr ↩︎ Why-use-markdown ↩︎ MarkdownGuide/Tools ↩︎ 主要来源是知乎、技术博客等平台上搜索得到的 MD 编辑器评测文章，以及 Typora 、Zettlr 和 MarkText 软件下载页面的评论区。 ↩︎ Markdown-syntax-lements ↩︎ Postmortem: Zettlr’s first Security Incident | Zettlr ↩︎ Issues · marktext/marktext (github.com) ↩︎ 排名参考网站 ↩︎ ↩︎ No longer supported · Zettlr/Zettlr ↩︎ 2022 年开发人员规模数据分析 ↩︎ Slidev 官网 ↩︎ 以 Vditor 的具体实现为例 ↩︎ 文本编辑器哪个好用？ ↩︎ 幕布，基于无序列表大纲生成思维导图的软件 ↩︎ |
大块空白在重新打开软件之后会消失（不定时再次出现），但 UI 错位的问题可以稳定复现，应该是前端设计的漏洞 
【本文地址】