编辑:[db:作者] 时间:2024-08-25 05:48:20
不过,这篇文章我不想先谈「大师条记究竟是不是一个好的条记运用」。相反地,我想更多地从「理念」的角度谈谈:我们在用 Markdown 写作时,到底在追求什么?
(首先我想声明,这篇文章会包含很多主不雅观不雅观点和感性体验。鉴于我个人懂的不多,很可能会造成偏颇或缺点,烦请示正。同时,阅读这篇文章也须要你对这方面的软件知识有一定理解。欢迎大家与我互换分享、增广见识。感激!
)
无论是 Markdown 措辞本身,还是各种支持 Markdown 的条记软件,对我而言都不过是写尴尬刁难象而已。也便是说:不是我去适应它,而是它本身就应是得心应手的。
当然,每个人的利用需求不同,心中精良的条记运用的样子容貌也不同。以是在基本功能完好、能够知足我的日常利用需求的情形下,能够供应直不雅观、大量可调选项的条记运用,才是我心目中的精良的条记运用。
市情上已经有太多的条记运用,但找到一个适宜自己的真的很难。下面我通过对自己利用需求的阐发,力求一探大家对 Markdown 条记运用常见的需求、喜好与缺憾。
我的需求
我是一个软件工程系的大一学生,日常的装备只有一台 Windows 系统的条记本和一部 iPhone。我的条记运用利用场景按利用频次可以归纳如下。
桌面端:
各种课上快速记录条记为公众年夜众号撰写定期或不定期的推送为程序设计作业撰写开拓文档等手机端:
快速记录一些灵感进行一些短篇创作、大纲撰写等修正已经完成的文稿中的小缺点很明显地,我的需求按主要性从高到低排序应是:
写作效率:Markdown 语法的易用性同步与格式:多平台、多用场、多格式简便、快速:特殊是 iOS 真个利用体验文档系统:多特性、多维度我相信对付很多学生,又或是不承担大量项目管理事情的朋友,对付条记运用的需求该当和我以上四点非常类似。总结为一句话便是:好写好查好改。
Markdown 语法与写作手感
支持 Markdown 语法的条记软件,总是喜好对 Markdown 语法本身进行一些「魔改」,乃至干脆不支持部分格式。这是一个非常奇怪的趋势。
Markdown 是一种 标记措辞。我们喜好利用它,便是为了在双手不离开键盘的情形下,能够快速地使正在编辑的文本具有一定的格式。如果一个标记措辞的标记语法都难以确定,其目的——效率就很难表示了。
如今的 Markdown 语法就像十多年前的 Web 设计一样:不同厂商出于自己对实用性的考量,制订了大量的规则,却没有一个机构或组织能够真正把它确定下来。
在这样的环境下,我认为:一个精良的条记运用该当放下自己的偏执,而去拥抱不同用户的习气。如果利用过火歧种类的 Markdown 条记运用的用户,都能在这个运用中找到舒畅的写作体验,那么它的用户群体自然会越来越宽广。
落实到实际操作,我认为:一个精良的条记运用该当给用户选择 Markdown 语法风格的权利。它该当可以选择或变动:
厂商改进过的语法方案或通用语法方案个别格式的语法方案用户自定义的语法方案一个灵巧的、可定制化的条记运用就像一把瑞士军刀,从开快递箱的数码科技博主,到在密林里行军的特种兵,都能在这把轻巧的工具中找到适宜自己的功能。
更有趣的是,一个条记运用不会由于它支持 Markdown 语法而高等或易用很多。关于 Markdown 到底能提升多少效率,实在网上也有许多辩论,这里我不展开说了。但我认为问题的关键不在于是富文本还是 Markdown,反而在于细枝末节处:
回车是换行还是换段落?无序、有序列表能缩进多少层?列表什么时候结束,什么时候开始?引用、代码、表明、加粗、斜体的相互嵌套怎么办理?插入图片是本地引用还是自动上传图床?快捷键怎么安排?……许许多多这样的细枝末节的问题累加起来,才构成了一个条记运用终极的利用手感。
一个好的条记运用,该当十分符合人的输入直觉,能够聪慧地感知你每一次操作的目的。你一上手,很快就能适应。而一个差的条记运用,用户纵然再努力地去适应所谓「优化过的 Markdown 语法」,也只会一贯磕磕绊绊。
这让我想到在学习 Java 时,老师提到过它的一个特点:
鲁棒性 (Robust) : 鲁棒是 Robust 的音译,也便是健壮和强壮的意思。它是在非常和危险情形下系统生存的关键。比如说,打算机软件在输入缺点、磁盘故障、网络过载或故意攻击情形下,能否不去世机、不崩溃,便是该软件的鲁棒性。所谓「鲁棒性」,是指掌握系统在一定(构造,大小)的参数摄动下,坚持其它某些性能的特性。
总结下来,我想,条记软件的写作效率,归根结底也是「鲁棒性」。它有多能容忍用户的无意识和习气做法,它就会有多强大、稳定、易用。
「全平台同步」的迷思
在谈论「支持 Markdown 的条记运用」时,我避开了桌面端和移动真个界线。
就像我需求中提到的一样,「一个精良的条记运用」的定义,在桌面端和移动端是不同的。桌面端重效率、功能、稳定性,移动端重便捷、体验、易用性,二者的利用场景造成了这样巨大的差异。
但「全平台同步」 在我看来,反而是非常主要的一个功能。这哀求一款运用在文档、特性、功能同步的根本上,桌面端和移动端有各自不同的调性和巧思。而这正好是很难做到的,它须要开拓职员对桌面端和移动端有着同样深刻的理解,并能把二者的体验打磨得十分连贯。
这种「连贯性」表示在何处?
UI 设计的连贯性: 如何将桌面真个设计元素下放到移动端?实在这一点是比较好达成的,目前的一些产品(如 Notion) 已经在这一点上做的很好了。当然,这和它 Web 运用的实质是分不开的。利用逻辑的连贯性: 桌面真个条记运用为了功能的强大,利用逻辑常常十分繁杂。移动端该当在若何的程度上保留功能、简化流程,而又不失落连贯性,这是十分值得探究的。文档撰写的连贯性: 即在一台设备上编辑后,同步到所有平台上的速率。当然,同步速率是一个比较繁芜的问题,用户的数量、公司的体量等等都可以影响到同步的速率。这一点上许多厂商已经做得很好了。Notion 桌面端
Notion 移动端
除此之外,一篇文稿写成后,并不总是只留在条记运用中。相反地,很多时候都是要派其他用场的:
公众号文章:导出 HTML 文件,须要细致地排版(可能用到 CSS)论文、文章、谈论稿:须要导出多种格式,如 PDF、Word 等留作复习条记:需保存在本地或云端上台做 pre 时的大纲:针对移动端同步……我想指出的是「同步」不但是自己与自己同步,却常常是要与别人「同步」。md 这样一个相对小众的文件格式并不适宜分享,因此支持导出其他文件格式也是相比拟较主要的。更有甚者连导出本地 md 文件都不支持,这一点的弊端我在后文将提到。
轻量化的移动端
如果说手机是碎片韶光的入口,那么移动端条记运用便是碎片化写作的入口。
移动端条记运用
通过日常的利用我创造,绝大多数的手机写作场景都是:
碎片化的记录灵感记录大略信息进行短篇创作它不须要多么强大的生产力或者多么强力的功能,为数不多的哀求是:
利用简洁软件轻量分享、同步、查看便捷在这方面,我觉得 iOS 上的 Drafts 可以说是做的比较好的,纵然它是一款「非范例条记运用」。分开运用实际体验,这一点实在是很难讲的,以是我们稍后再谈。
被遗忘的文档系统
作为一个条记运用,在「好写」、「好改」的根本上,「好查」也是十分主要的,这就哀求运用供应一个高效、简洁、功能性强的文档系统。
但目前的很多条记运用(特殊是从移动端起身的一些运用),少有文档系统的观点。它们要不但是大略地用所谓「标签」来归类,要不在桌面端完备无法导出为文件,再或者干脆利用体验极差。
那么为什么会形成这样的情形呢?我想这一点和我之条件到的移动端条记运用「轻量、快速」 的需求是分不开的。试想,如果厂商做一个「即开即用」的移动端条记运用,那一定不会优先考虑文档系统,这是由「快速记录、大略修正」的利用场景决定的。但在条记运用桌面化的本日,也有越来越多的厂商开始看重文档系统的培植。
我认为,文档系统的设计模式大致可以概括如下:
传统的「文件夹 - 文档」模式标签分类模式本地泛文档模式前两点都很好理解,第三点我想详细解释一下。
我们知道利用 Markdown 措辞撰写条记、查看条记,在本日依然是一个非常个人化的行为,由于你很难直接用 md 格式的文稿和他人分享。同样地,他人分享来的文稿也常常会是 Word、PDF、Pages 等格式,更不用谈我们日常的项目中还会有许多其他类型的文件,例如图片、视频、代码、表格等等。
如果仅是把自己撰写的条记分类得整整洁齐,而无法方便地管理其他格式的文件,这样的文档系统也是相对无意义的。条记文稿被从其归属的文件堆中剥离出来,是不符合利用逻辑的。
这就引出了一个关键的问题:文档管理究竟该当只勾留在运用内部,还是该当依赖于环境的文档系统?
事实上通过以上的论述你可以创造,我更方向于后者。虽然目前有这样设计思路的运用我所知甚少,VS Code 勉强可以算一个。
VS Code
如果不强求在软件内完成所有资料的归类和查看,那么实在只要运器具备导出 md 格式的功能就已经可以基本知足这一点需求了。
要多强大才算精良
以上我列举了四个我最重视,也可能是大家最关注的条记运用的常见需求。
一个精良的条记运用是否该当完美地覆盖以上所有的需求?这个问题就像写代码该当用 IDE 还是用像 VS Code 这样轻量化的代码编辑器一样,我认为是难以产生定论的。
要多强大才算精良?我想说的强大并不是事无年夜小地涵盖所有可能的需求,而是如文章开头所言,我们该当找到得当自己的、得心应手的条记运用。下面我想通过剖析市场上已经存在的、具有一定质量的条记运用在以上四个维度的利用特点,做一些非常大略且主不雅观的归纳和参考。
末了一个条记运用少数派一贯是一个关注 Markdown、支持 Markdown 的网站,在少数派我也认识了许多支持 Markdown 的条记运用。期间我体会到,由于各个公司的设计理念、目标人群,甚年夜公司体量的不同,市场上的条记运用的风格也大相径庭。
例如:
Bear (iOS、Mac):一个小型条记运用,主打都雅和效率并行,并对 Markdown 语法做了一定的改动。Drafts (iOS、Mac) :一个草稿运用,主打快速记录,是笔墨信息的收发站,有许多 Action 可与其他 App 联动。(在我写这篇文章的期间它已经出了 Mac 上的正式版。)Typora (Windows、Mac、Linux):一个桌面真个条记运用,合营 Pandoc 可以非常好地支持导出各种格式的文件,功能强大。Notion (iOS、Android、Mac、Windows):一个全平台的 Web 运用,界面都雅,利用逻辑有新意,但在利用体验上还有待改进。再加上正在体验的大师条记,以上便是我长期利用过的一些条记运用。但由于大师条记的分外性,我想之后再单独谈谈。
Windows 用户的困境
正如我之前反复提到的,条记运用非常主要、核心的功能是全平台同步(至少是你所拥有的设备的全平台同步)。但出于各类缘故原由,Windows 上高质量、有特色的 Markdown 条记运用少之又少。我前文提到的 Typora、Notion 和大师条记是为数不多我认为拿得脱手且有特色的条记运用。
纠结再三,我决定在以下的运用剖析部分中,仅以一个 Windows 用户的视角来写,而不对不理解的 Mac 平台的运用选择妄加评论。如果你是 Mac 用户,可以直接从我关于大师条记的第三部分连续看起。
Bear
Bear 是我第一个打仗的支持 Markdown 措辞的条记运用。实在以它为 Markdown 入门并不是一个很好的选择,由于它修正了一些 Markdown 的基本语法——虽然这是可在软件内变动的(你可以在「设置 - 通用」中选择是否开启「Markdown 兼容模式」)。写作手感称不上出色,常常可能碰到无序、有序列表呈现的状态和想象中不一样的情形。
Bear
Bear 目前只支持 iOS 和 Mac 的同步,以是并不在我的主力条记运用的行列中。但由于它都雅、直接、优雅的 UI 设计,有时我还是会用一两次。我认为 Bear 的 UI 设计是它的亮点之一,虽然不可调的页边距很大程度地影响了手机真个写作体验。
Bear 在移动真个设计还是相对轻量的,但该有的功能都打磨得相称精细,这里就不细说了。
此外,「可以设置多层标签」是一个文档系统方面的功能亮点。这样的做法既保留了标签系统的整体性,又不会让搜索变得非常呆板。
举例来说,如果许多文档都有名字相同的 #未完成 的标签,却属于不同的大类标签,比如一个是 #程序设计 ,另一个是 #少数派 。那么我在全局搜索未完成的少数派文章时也会得到很多未完成的程序设计文档,这使得利用体验很差。加入标签归属就可以快速定位想要的内容,也可以供应类似于文件夹一样的利用体验。
那为什么我们不直接用「文件夹 - 文件」的模式呢?标签模式的设计初衷便是一篇文稿可以有多个标签, 从而供应多元、直不雅观的归类方案,而不是单一的、有指向性的方案。
Drafts
前文提到,我认为 Drafts 是一款「非范例条记运用」。诚然,它最低限度地具备很多条记运用该有的基本功能:支持 Markdown、标签系统、同步系统(仅 iCloud),但我认为 Drafts 与其说是一款「条记运用」,倒不如说是一个移动端文本入口。(他们官网的 Slogan 便是 Drafts. Where Text Starts.)
Drafts
Drafts 最大的特点便是「即开即用」,写好后再考虑这份文稿的用场。是要复制到别的运用?还是只是记录一瞬间的灵感?还是要通过 Action 进行其他更繁芜的处理?在输入完最主要的文本之后,你大可再逐步考虑这方面的事情。这对付手机上的碎片化利用场景实在是非常适用的。
这一点让它成为我心目中移动端条记运用的典范:不喧宾夺主,默默地网络所有的笔墨碎片,并给你最快捷的处理他们的办法。
从此你再也不用在各个软件之间「专事专办」了,面对的只有 Drafts 克制自由的蓝白色界面。事实上,合营 Action、URL Scheme、Workspace 这些特性,Drafts 简约直白的外表下藏着一个功能亘古未有强大的效率工具的内核。
Typora
我想开门见山地直言,Typora 是我在桌面端最喜好的生产力运用。它的功能之强大、设计之镇静、体验之美妙、理念之前辈,我认为值得所有条记运用厂商学习。
Typora
打开软件,界面只有菜单栏多少几个选项和一个空缺的输入区域。但这个简约的软件所支持的功能之多,却令人叹为不雅观止。
实时预览 Markdown 格式效果,而不是常见的旁边分栏的设计。但同时还保留了「源代码模式」,让你在显示格式不符合预期时可以进行微调。(它的 Markdown 输入手感真是一流!除此以外,它还拥有一些「浏览器」干系的功能:
支持对界面套用 CSS 并实时显示,仅需在本地主题文件夹中加入你的 CSS 文件即可。支持 DevTools,也便是浏览器的审查元素。支持一键复制 HTML 代码。我常用 Typora 写微信"大众号推文:撰写文稿,套用固定 CSS,一键复制 HTML 代码。这样就完成了从撰写到基本排版的事情,我只需将 HTML 代码粘贴到微信公众年夜众号后台,再进行一些微调即可。大幅节省了事情量的同时,还担保了每次推送的格式基本相同,阅读体验更好。
当然它也不是没有缺点的。没有移动端运用,不支持云端同步,乃至没有运用内部的文件管理,导致利用模式基本是在文件夹中直接打开 md 文件。它是一款将生产效率发挥到极致的条记运用,能够包办你生产过程中的绝大部分内容,但任何一点无关「产出文稿」的事它都不会去做。
Notion
少数派有 文章 提到 Notion 是一款「来自未来的条记协尴尬刁难象」,我十分赞许这一不雅观点。无论是它 Web 运用的实质,还是它创新的「模块化」利用逻辑,都仿佛是来自未来的条记运用办理方案。
Notion
文档系统一贯是各种条记运用的老大难问题。做大略了没有分类的意义和效果,做繁芜了又会摧残浪费蹂躏太多韶光在无意义的打标签、建目录上。
Notion 仅用一个「模块化」的观点就办理了这一问题。 任何文章(Page)下都可以再插入许多模块(Block):其他文章、段落、列表、链接、图片、视频、代码、看板,乃至 PDF、谷歌舆图……
因此,一篇文章(Page)可能不是一篇实际意义上的文稿,却是许多文章的父集(或者说,一个条记本)。再合营文章链接等模块,一个极简理念下的文档系统就出身了。
对付 Notion 来说,Web 运用的实质是一把双刃剑。
优点:
全平台的运用开拓和掩护更新不是难事。可以很轻松地做到多平台利用体验的连贯。运用占用存储空间很少。各种各样的模块可以很方便地下放到移动端,使 Notion 的移动端功能十分强大。缺陷:
性能低下,笔墨量多或内容繁芜时,会占用一定内存。在线和离线状态的利用体验有一定差距,有时还须要梯子。利用手感不好,常常难以达成想要的格式。目前对 Markdown 的支持(特殊是中文内容)也不足好。和桌面端险些相同的界面设计使得 Notion 的移动端编辑体验称不上简洁快速。Notion 的模块化设计使其成为一个天马行空的产品,用户可以在多种多样(并且持续更新)的模块之上,搭建出属于自己的功能强大的条记。
末了「一个」条记运用
每个运用有每个运用的好,但如果为了达到自己的需求而反复在各个条记运用中切换,其实是一件很麻烦的事。一篇文稿在多少运用间奔波,不说适应软件不同语法的问题,你的文档系统终极也会变得一团糟。
我相信每个用 Markdown 写作的朋友,都在等那「末了一个条记运用」。如果能有一个运用能知足你的所有需求,却又不显得臃肿繁芜,那该多好!
但很可惜,就我个人履历而言,到现在我还没找到最适宜我的条记运用,包括接下来将着重讲的大师条记。
大师条记 的英文名是 Masterway,直译「大师之路」。Markdown 条记运用经历了好几年的发展,在不同设计理念的引领下产生了许多不同的形态。一个运用成为「精良的条记运用」,要走过多长的「大师之路」?
大师条记
在体验大师条记的过程中,我创造大师条记实在吸纳了许多其他条记运用精良的设计思路。下面我想连续以前文强调的四个维度来剖析大师条记的功能亮点。
(截止到初稿完成,我的大师条记 Windows 端版本号为 0.5.3,iOS 端版本号为 1.2.4。)
Markdown 语法
大师条记在对 Markdown 语法做一定修正、扩展的根本上,推出了自家的 mmd 语法(也包括 mmd 格式的文件)。它的开拓者是这样描述 mmd 的设计理念的:
mmd 是 Masterway 在根本 Markdown 之上,为应对图片,音视频等等多媒体场景而创建的一个大略扩展。mmd 对绝大部分的根本 Markdown 语法,如标题,字体风格,网页链接,图片链接等等,mmd 都供应了支持。同时,在根本语法和扩展两方面做了一些谨慎的考试测验。
mmd
详细的改动内容你可以在 这篇文章 中查看。
兼容性问题
任何企图对 Markdown 语法进行改进的厂商都面临着兼容性的问题。个中又可被分为两点:
该当怎么兼容用户之前的利用习气?该当如何担保自己的改进语法能被其他平台兼容?前者便是我之条件到的,「条记运用厂商该当拥抱用户的习气」。但很遗憾,目前大师条记并不支持在各种 Markdown 语法风格之间进行任何的切换。
不过在后者上,大师条记还是做得比较好的。它在支持导出为自家 mmd 格式文件的同时,也支持广泛利用的 md 格式文件。软件会自动帮你将 mmd 有所改动的语法更换为 Markdown 的通用语法。
为此,我专门测试了所有 mmd 与通用 md 格式中不同或增广的语法格式,把它们写成一个文档,并导出成 md 格式。
mmd格式测试 - mmd
mmd分外格式 - md
除了运用内部的条记链接,基本所有的扩展语法都能被比较好地改动。实在我认为不把条记链接转化为共享的网页链接,一定程度上是出于对用户隐私的考虑。如果我一欠妥心忘却文稿中链接了其他文稿,又把这篇文稿导出为 md 格式分享给了别人,实在可能带来很大的不便。
多媒体的野心
开拓者在 mmd 中扩展了插入视频的功能。你可以在条记中插入:
普通视频链接Youtube 视频链接Bilibili 视频链接mmd 视频链接
虽然只是很大略的功能,但我从中看出了大师条记开拓者的「多媒体的野心」。这让我想到 Notion——一个条记运用的手究竟该当伸多远?
对付这个问题 Notion 大概已经给出了自己的答案,就像 沨沄极客 说的,他们想做一个「电子手账」。你可以在 Notion 中完成任务管理、多媒体展示、待办事项、日程方案……
那大师条记呢?目前我还不得而知。但很显然地,视频也可以是条记中非常主要的一部分。我认为这至少是电子化条记探索路上的一步。
写作手感
写作手感一贯是一个比较玄学的东西,它由很多方面的成分决定(也包含很多的个人喜好),因此在前文中我也很少用到这个评价标准。而且在谈到一个条记运用的「写作手感」的时候,我们常常会想到一些负面的印象,却很难描述这个「手感」好在哪里。
大师条记编辑界面
你正在阅读的这篇文章的初稿是我全程在大师条记中撰写的。期间我和朋友抱怨过:「如果不是要测评这个软件,我真想用 Typora 来写!
」我只能说它并没能给我带来比较好的写作体验。这个毛病在比较新的运用上都有所表示,例如 Notion 的写作体验也很糟糕。下面我将逐一列举一些让我感到不满的问题(但这不代表你一定会不喜好它。请下载后亲自考试测验一番再做评价!
):
运用其他方面也多多少少有一些影响我利用体验的地方,在此我就不一一列举了。
不过我想说的是,作为一个比较新的运用,有一些小毛小病是非常正常的事情,特殊是在想布局一个新观点的运用时。期待开拓者能将其打磨得更精细。
移动真个利用体验
可能是由于移动真个开拓晚于桌面真个缘故原由,目前大师条记的移动端仍旧是一个非常简陋的状态。(请许可我用这样一个比较严重的词。)
iOS 上的大师条记运用基本可以用四页来概括:首页、文件夹分类、浏览界面、编辑界面。
个中首页和文件分类页面做得还是比较精细都雅的,也和桌面上的利用逻辑很像。浏览界面是我认为做得最好看的。 没有恼人的状态栏,笔墨内容填满全面屏的每一寸,让人看得赏心悦目。字体大小、行间距、段落间距等也做得很得当。
大师条记移动端
但编辑界面可以说险些是不可用的:
虽然有格式快捷按钮,但是其粗糙程度让我很难承认它是「按钮」。笔墨部分没有任何格式实时预览,也没有 Markdown 语法高亮等等,利用体验很差。字体大小、行间距、段落间距和浏览界面完备不同,虽然有预览功能不至于不知道自己在写什么,但视觉感想熏染十分拥挤。可以说,大师条记的移动端目前只能修正文稿中的一些小缺点,还很难进行任何创作。
同时,移动端逼迫先写标签、再写标题和正文的设定也让我用得很不舒畅(你不能点击下一行直接开始写标题或正文)。保存时你也只能存到某个项目中(我将不才一部分先容大师条记的文档系统),没有一个暂存处。这一点实在是和之条件到的「快速记录灵感」的需求完备相悖的。
文档系统
大师条记的文档系统吸纳了许多条记软件的优点。
大师条记文档系统
首先,它以传统的「文件夹 - 文件」的形式作为根本:文件夹对应的是项目,文件对应的是条记(Line)。
其次,每个条记的第一行固定为标签行。你可以在个中加上这篇条记干系的标签。如果你不作任何改动,则这篇条记的标签为 #默认标签 。在条记最下方有一个LineId,它表示了这篇条记在这个项目中的创建顺序,因此每个 LineId 在项目内部都是独一无二的,你可以在软件内链接文稿时用到它。
我认为最特殊的属看板功能。每个项目会自带一个默认看板,个中包含你所有的条记(以标签的分类办法呈现)。你也可以在看板界面直接添加新标签列,并向个中添加条记。
除此以外,看板还有一个公共标签的功能。在创建新看板时,你可以选择是否添加公共标签。如果你设定某个标签为这个看板的公共标签,那么在此看板中只会显示有公共标签的条记。这时你添加新标签列,则会显示同时有新标签和公共标签的条记。
大师条记希望通过这样的「项目 - 看板 - 标签 - 条记 - LineId」 系统来管理文档。
搜索功能方面,目前大师条记仅支持通过标签或 LineId 在特定项目内搜索条记,不支持任何的关键词搜索。
那么这样一个看起来有些繁芜的文档系统利用体验究竟如何呢?
我认为,看板功能有些鸡肋。目前大师条记的看板功能仅仅局限于根据一个或多个标签对条记分类、展示,而这样的功能用搜索实在已经可以实现。任务进度管理、任务到期查询、职员分配、团队互助等等看板更主要的功能,在大师条记上实在是缺失落的。
如果大师条记希望做一个团队协作软件,这一方面该当跟进开拓。但如果只是为了让用户更直不雅观地查看自己的条记,我认为把搜索界面做得更明朗一些即可,不必再额外增加一个看板功能。
同时,大师条记的项目和看板的显示是有很大差异的。
项目视图下: 所有条记被集中摆放在中间列,能显示出的条记数量很少。界面右侧是文档编辑和浏览区域。但我感到这种倾向屏幕一侧的编辑界面并不适宜永劫光的撰写,而更适宜一边写一边查阅项目中的其他资料。
大师条记项目视图
看板视图下: 所有条记以看板的形式陈设出来,可以一眼就看到每个标签下的条记有哪些。编辑界面则是位于画面中心的。我认为这样的视图更适宜须要集中把稳力的永劫光、长篇撰写。
大师条记看板
此外,在两个视图下你都可以按 F11 进入全屏浏览 / 编辑模式。
而 LineId 链接我认为是比较失落败的部分。试想这样一个场景:当我想要在条记中链接到另一篇条记时,我要先保存,然后跳出编辑界面去找那篇条记的 LineId 并记住,如果我想要给这个链接加一个标题我还要同时记住那篇条记的标题。然后回到原条记的编辑界面,用# 标记 LineId,再切换英文用半角符号 ,、\"大众 加标题。这个功能如果在界面上能提示项目或特定标签中的所有条记,直接交给用户挑选,利用体验会好得多。
大师条记内链
虽然没有关键词搜索,但我认为大师条记的「仅在项目内部搜索标签」的设计理念是很合理的。这一点在之前 Bear 的部分提到过,就不再赘述了。
木桶事理
如果你读到这,你该当会创造我对大师条记有许多的不满,这些不满很多都出自一些由于开拓履历不敷导致的小问题。但我目前还是打算把大师条记用作主力条记运用,只是在移动端用 Drafts 赞助,这是为什么呢?
就像木桶事理所说的,我认为条记运用作为一个工具,其易用性不是由其亮点功能所撑起的,而是由底线的功能支持决定的。
例如我的底线需求是 Windows 和 iOS 平台同步,而后是写作手感有所担保。这两点实在已经可以刷掉许多市情上的条记运用了:
没有 Windows 真个 Bear 和 Drafts 首先就不在我的考虑范围内了。Typora 手感很好,但没有 iOS 端,也没有一个好的文档系统。Notion 有许多新奇的功能,但写作手感和利用体验过于粗糙。你会创造只管它们都有许多显眼的功能和精良的体验,但终极是需求短板让我选择了大师条记。或者说,只管大师条记有许许多多令民气烦的毛病,但它是为数不多的能知足我个人需求的条记运用,因此我才会去利用它。
虽然这是一篇纯粹从个人需求角度出发的文章,但我希望通过我的一些剖析过程,给大家在选择条记运用时带来一些启示:
我的需求有哪些?我的底线需求是什么?XX 功能对我来说真的主要吗?XX 功能真的有用吗?写在末了大师条记实在不能算一个新运用,它的开拓者早在 2017 年底就在少数派上发过先容文章。但我还是在利用过程中碰着了很多小毛小病,有些乃至极大地影响了我的体验。我不想在此逐一列举,由于这对付一个还在 beta 版本的运用是不公正的。但我想大略解释两个比较严重的问题:
无法自动保存,只好手动按完成键,但这样又会退出编辑状态。这导致我不常有点击「完成」的意识,直到我有一次按到 F6 从看板进入到项目界面,创造我刚才写的一大段笔墨都没了。和手机真个同步也有一些问题,会有延迟同步乃至桌面端笔墨丢失的问题。运用退出不完备,导致下次利用时可能无法打开,须要开任务管理器杀进程。我很欣赏开拓者做全平台功能性条记运用的决心,我也认为他们知道这意味着多大的事情量。我希望开拓者在构思新功能时也可以兼顾到一些利用体验上的问题,毕竟这才是一个条记运用的灵魂。令人欣喜的是开拓者们也在培植大师条记的 社区,提交 bug 的反馈很迅速,基本在一到二个事情日内可以得到答复。
一个小学徒要经由多少磨砺才能成为大师? 正如 Masterway 这个名字一样,我想这是用户和开拓者可以共勉的。
祝大师条记 Masterway 开拓顺利!
本文部分图片来自:Bear 官网 、Drafts 官网 、Notion 官网、大师条记官网、Unsplash
本站所发布的文字与图片素材为非商业目的改编或整理,版权归原作者所有,如侵权或涉及违法,请联系我们删除,如需转载请保留原文地址:http://www.baanla.com/xyj/143762.html
下一篇:返回列表
Copyright 2005-20203 www.baidu.com 版权所有 | 琼ICP备2023011765号-4 | 统计代码
声明:本站所有内容均只可用于学习参考,信息与图片素材来源于互联网,如内容侵权与违规,请与本站联系,将在三个工作日内处理,联系邮箱:123456789@qq.com