Drafts #iOS
如果你对 Drafts 还不了解，建议你阅读 AppSolution 曾经推过的一篇关于 Drafts 的文章
一款「文字生产力工具」应有的样子 – Drafts 4 评测 #iOS
引言
x-callback-url 就像情怀，虽然憧憬无限、愿望无限、深度无限，但在现实面前，一般人听不懂也看不懂，入点门的人为其鼓吹造势，真正懂得人，却明白它食之无味，弃之可惜，可能还没这么惨，还加了点盐。
今天，我们不谈情怀。
当我们说到 Drafts 的时候，我们都在谈什么？
从 Google 中随便翻出几篇关于 Drafts 的测评性质的文章，就会发现有这么三类：
- 第一类它只告诉了你 Drafts 的基本特性以及基本用法。看完它们，你知道了 Drafts 有 xxx 和 yyy 的功能，并且知道了这些功能的用法，比如你知道了怎么从网页剪辑内容存储到 Drafts，比如如何创建一个 Action，这就像告诉你如何使用铅笔写字一样；
- 第二类它会详细解剖 Drafts 中的 Action，尤其是关于 URL scheme 的 Action，会告诉你 Drafts 的 x-callback-url 有多么强大和好用。看完你觉得，Drafts 果然是个神器，但就像金箍棒一样，你知道它厉害，但太重，你搬不动，毕竟自己不是孙悟空；
- 第三类文，既不会简单介绍 Drafts 的基本功能，也不深入去研究 Action 或者 URL scheme，而是用实例告诉你 Drafts 能干嘛，比如能同时发微博和推特，能发一条微博并存储到印象笔记中，又或者一次性批量向 OmniFocus 添加任务等，看完你会发现自己仿佛掌握了 72 变，神通广大，但在关键时刻却陷入困境，不知道该变成老虎还是狮子。
Drafts 很厉害，很有用，大家都知道他很有用，每个人说起 Drafts，都是一脸崇拜的样子，当我问到，那你们都拿 Drafts 来干什么？有一部分人是这么说的：「它就在安静地躺在那里，具体能干什么，我也不知道，就让它在那吧」；还有一部分说：「笔记本！」；Power User 们各有各的答案，多数是与 URL scheme 有关。
URL scheme
要搞明白 Drafts 能干什么，就得先了解 Drafts 为什么那么厉害，Drafts 厉害在哪？很大程度上依赖于它的 Action，而 Action 中又以 URL scheme 最为值得称道。
那么什么是 URL scheme？
At the simplest level, a custom URL scheme allows users to open your app from other apps. But the true power of URL schemes is in the ability to perform specific actions as your app opens.
简单地说，URL scheme 是：一个应用为了让其他应用能快速访问自身的某些数据或者使用某项功能，而设立的一些以 URL 形式存在的命令。用另一个词语来表达，就是一个应用的外部控制器，这些 URL 可以直接对应用进行控制，形式简单，应用广泛，举个例子，你在 Safari 中打开 wechat://，会自动跳转到微信，这就是 URL scheme 所起的作用。当然 URL 并不仅仅是打开应用这么简单，例如微博的 URL scheme 就提供了通过 weibo://new=[] 的形式来发微博，[] 内的内容就是你所发的微博内容。
Drafts 就是通过这些 URL 来与其他 APP 沟通和串联的。
关于效率
但是为什么要把事情搞得这么复杂呢？想发个微博，直接发就是了，何必要用 URL scheme？
URL scheme 能做的事情很多，这取决于应用所支持的 URL 使用方式，但 URL 存在的真正目的，是为了简化操作，从 Launch Center Pro（以下简称 LCP）开始，出现了许许多多通过 URL scheme 来简化操作的效率软件。比如我们要在 Safari 中 Google 搜索剪贴板中的内容，常规的操作，需要退出当前应用，打开 Safari、点按地址栏、长按、粘贴、搜索；而通过 LCP，只需要退出当前应用，打开 LCP，点击预先设定的一个 Action，这比常规操作少了三步操作。
在效率层面，多按一下和少按一下，差别是很大的。
So what？
说了这么多，Drafts 到底能干什么？我们到底该如何利用它？为何有必要使用它？
在我还没用上 Drafts 之前，我用的是 LCP，LCP 是最早利用 URL scheme 来增进效率的软件之一。在 LCP 中的动作，我把他们分为两类，一类是直接产生作用的操作，比如获取截图并上传到 Dropbox；另一类则是需要输入信息（input）的操作，先弹出输入框，然后输入，最后 LCP 通过 URL scheme 将键入的信息传递给下一个操作。
然后我们再看 Drafts，Drafts 打开就是文本编辑界面，直接就可以键入文字，然后通过 Action，我们再对我们键入的文字进行分发。下图展现了 Drafts 与 LCP 的不同点。
从图中我们可以看出，LCP 以动作（Action）为导向，一般来讲，用户打开 LCP，有着很强的目的性，知道自己下一步要干什么，直接选择 Action 进行执行；而 Drafts 不同，Drafts 是以输入文字为导向，用户进入 Drafts 中输入一段文字，可能并没有想好要将这段文字发送到哪，大多数时候，Drafts 充当着一个笔记本的角色，但其重要性，则体现在对笔记的整理和分发上。Drafts 体现的是一种，先收集，再处理的理念，与以 OmniFocus 为代表的 GTD 软件，有几分相似之处。
Drafts 可以是一切需要文本键入的应用操作的入口。
得益于 URL scheme，Drafts 不仅能从其自带的 Action 中对文本进行处理——例如发送 Email、Message，分享到 Twitter、Weibo，上传到 Dropbox、Evernote 等——Drafts 还能与一切支持 URL scheme 的应用进行沟通和信息传递，就像 LCP 一样。
例如，通过以下 URL，可以将键入的文本输入到 SimpleNote 中：
simplenote://new?content=[[draft]]
与上面例子相同的，有许许多多的 APP 都可以通过 URL scheme 来进行输入和调用。
作为一个入口
从前文的示意图中，我们注意到，对于需要文本输入的应用，LCP 的逻辑，一开始就是分散的，先选择你要执行的动作，再进行键入。这在使用 LCP 的时候，往往在打开的时候，都要犹豫一会：「我到底要使用哪个 APP 进行操作？」。而对于 Drafts 而已，我们在开始的时候先进行键入，把关键信息保存住了（LCP 很多时候当你决定使用哪个 APP 的时候，已经忘了自己要记录什么了）。而在大多数时候，我们获取了信息，但却并没有马上处理信息的必要，那么就可以记录在 Drafts 中，为以后所用，而一般的笔记本软件，如果要调用记录的信息，也许你还需要一次复制粘贴操作。
用 GTD 的理念来理解 Drafts
GTD 的基本理念为，「记录 > 整理 > 分类 > 完成 > 反思」，是一套完整的任务管理体系，而作为类比的项目，Drafts 可以说也提供了一套完整的笔记管理体系。但你无需担心的是，这里以 GTD 理念来类比 Drafts，不代表 Drafts 在使用上需要遵循什么复杂的原则，或者在使用上有任何的需要深度学习的地方。Drafts 一切表现得非常自然，你在使用过程中自觉或不自觉地就参照着 GTD 的理念进行了。而造就这一现象的产生，是因为我们使用 Drafts，是因为我们确实有硬性需求要录入和处理笔记，而 GTD，更多地是作为一种强加性的限制，缓解拖延症患者发病的工具（开玩笑），主动和被动，一目了然。
传统的文本记录（或者称之为笔记）类软件，大概止步于记录，多迈出一步的涉及整理和分类，以 Evernote 为例，其提供的笔记本和标签功能以帮助我们分类笔记。更多的笔记类软件，仅仅止步于「记录 > 分类」，不给笔记们提供下一步的入口。
那么这个下一步是什么呢？我们之所以会收集和记录笔记，很大一部分原因是因为以后会用，传统的笔记调用，往往简历在复制粘贴的基础上。而Drafts 则提供了各种入口，让你将你记录的信息传递到下一个应用或者操作中，这对应的正式 GTD 中的完成步骤。
最后是反思，作为一款笔记应用，看起来并没有什么好反思的？这句话没什么不对，不需要的人往往不需要，但有需要的人总是希望能有这么一个功能的。Drafts 在进行完一系列的动作之后，你可以对笔记进行删除、归档等操作，这么做的一个好处就是，在日后反查笔记的时候，可以很快地知道哪些笔记被执行过操作，哪些没有。不过 Drafts 在这一步并没有做得很好，仅仅提供了归档、删除和不操作三种结束方式，甚至在旗标方面，也仅提供了旗标和非旗标的选项，并没有提供一套可供管理的标签系统，这点不足，有时候很致命。
说到这，我们好像还忘记了非常重要的一个步骤——整理，作为区别于 GTD 的整理，我把 Drafts 的整理划分到文本信息整理。在 GTD 中，整理意味着你要对你的进行规划，哪些是马上可以做的，哪些是在学校可以完成的，哪些是需要别人完成的，属于对所有任务的一个总体规划（也许我说的不对），GTD 中每一条项目都是一个明确的可执行的动作，因此整理关注的点并不是项目本身。但对于笔记和文本而言，其中蕴含着大量的信息，同时还涉及的可阅读性、排版、顺序等多方面的内容，对一手资料进行一系列操作，使其可读、美观、流畅，称为对笔记的整理。Drafts 正好满足了这一要求，不仅是编辑文本，调整顺序，还是插入内容，Drafts 都有着自己的一套完整的体系，同时，Drafts 提供的键盘扩展（Keyboard Extension）提供了良好的编辑体验，这也得益于 javascript 的实现。
以下我将通过我自身的例子来说明这一系列步骤的实施。
作为一个脑洞极大，每天不吐槽就不舒服的段子手，同时也是一个严谨的科研工作者，而且充当着编辑的角色，我每时每刻都要捕捉大量的信息，并把我认为重要的信息记录下来以便使用，比如突然迸发的灵感；突如其来的任务；网页上看到的一段喜欢的文字等。
从最基本的社交开始说起，每天收集起来的段子等会发往 Twitter、微博、朋友圈，不同的社交工具发的内容也不同，比如在 Twitter 发布日常段子，在微博发布八卦信息，在朋友圈发布学习和工作信息（这仅仅是个举例）。我们每天发布的许多内容，有时候并不是想到了看到了就马上发布到设计平台上，也许是网络不佳，也许是内容还需调整，也许是时间不允许，总之，基于各种原因，我们把看到的信息先汇聚到 Drafts。这里就不得不提到 Drafts 的 Safari 剪辑功能和通知中心的插件了：在 Safari 中看到某篇文章中的某段话甚是喜欢，于是选中后通过 iOS 8 的 Share Extension 保存到 Drafts 中；而在其他应用中复制一段文字后，可以直接由 Drafts 的通知中心插件保存至 Drafts 中。
到了晚上有了空闲时间，要开始在社交圈活跃了，于是开始翻看一天下来存在 Drafts 中的笔记。
首先第一条，这是一条在图书馆学习时灵光一闪想到的段子，于是通过 Twitter 的 Action，将其发送到 Twitter 上。Drafts 内置的 Twitter 动作，可以调用系统的 Twitter 分享，既不用打开应用，也不会弹窗（微博同）。
然后第二条，是关于爱范儿近期要招 Python 工程师的信息，这条是要发布到微信朋友圈的，由于微信并没有提供 URL scheme，Drafts 也不内置分享到微信的通道，因此这里要多走两步，通过曲线救国的方法，先复制文本，再打开微信，然后手动发送朋友圈。（这里不得不谴责一下微信不开放 URL scheme 以及 Share Extension 不支持获取文字信息。）
然后剩下几条，觉得没有发出去的必要，还是存到 Evernote 里吧，通过 Drafts 内置的 Evernote 动作，发送到 Evernote 中。
前面提到，由于 Drafts 本身不提供 tag 功能，因此对笔记的分类和管理，并不适合在 Drafts 中进行，Drafts 作为一个入口（inbox），应该尽可能地把笔记分发出去。Drafts 的每一个 Action，其实是由若干个子 Action 组成的，在核心动作完成后，例如发完 Twitter，我们可以再加一个 Action——保存到 Evernote 的 Twitter 笔记本中，最后在执行完该动作后删除该笔记。
当然，既然说 Drafts 是一切需要文本键入操作的入口，那么它的作用就不局限于社交、博文这种需要正经文字和笔记的地方。Drafts 强大的 Action 有许多其他不局限于此的应用，甚至有许多黑魔法产生。
拿任务管理来说，最负盛名的 OmniFocus 同样支持 URL scheme。通过 Drafts 向 OmniFocus 添加任务不过是小事一桩。不过对于我来说，在使用过一段时间 OmniFocus 之后，我还是喜欢用不同的软件搭配来完成 GTD 这种事情。
在任务管理方面，以我使用的为例，我使用的是 Due、Fantastical 和 todo.txt。简单地说明一下，Due 用于有明确时间点限制的任务，Fantastical 用于宏观日程安排，todo.txt 用于微观子任务的展示和提醒。
习惯上我会把每天收集到的任务写进 Drafts 中，就跟 OmniFocus 的 inbox 一样，基本上每天吃饭之前都会固定有一段时间（其实就是等饭的时间）用来整理这个「inbox」。整理的过程，就是在思考这个任务到底要发到哪，比如类似「五点下楼取资料」这种有明确时间点的事情，发送到 Due；类似「周六晚上班级聚餐」，则发送到 Fantastical；而对于某个特定任务中的子任务，比如「完成论文」中，包括「选题」、「查找资料」、「拟定初稿」等得操作，则发送到 todo.txt，而这些细小的项目，可以通过 Drafts 批量添加，比一个个添加效率不少。
通过 Drafts 的 x-callback-url，在添加完一个任务后，例如在 Fantastical 中点击完添加，可以直接跳转回 Drafts，进行下一个操作，比 Home 键返回要方便许多。
我还用 Drafts 作为一切搜索的入口，我们常用的搜索工具有很多：Google、Wikipedia、百度，甚至京东、淘宝、IMDB、知乎、App Store，甚至爱范儿搜索，都可以从 Drafts 入口中进入，相比起你还得用一段时间来思考打开什么工具进行搜索，或者打开浏览器切换搜索引擎（或应用），Drafts 要快和灵动地多，只需要你快速录入需要搜索的关键词，再根据需要直接打开某个搜索引擎的 Action。
当然，除了作为一切开始的地方，Drafts 还可以作为连接两个动作的枢纽。
例如，之前有一位仁兄，使用 Drafts、javascript 书签和 URL scheme，完成了这么一系列动作：在 Chrome 中看到一篇文章，通过书签跳转到 Drafts 把网址上传到 Dropbox，之后跳转到 Instapaper 存进去，再跳转到 Due 设置一个阅读时间，最后跳回 Chrome。
当然后来有了 workflow 之后，这些操作就变得很简单了，不过这仍然给我们提供了思路，通过 Drafts 来连接不同的操作。（在有了 LCP 和 workflow 之后，Drafts 在这方面的作为少了许多，不过它仍是存在的）
最后属于黑魔法类，可以参照 Lucifr 写的
用小书签和 Drafts 的 Dropbox Action 创建 Link Post
Drafts 和 Alfred
关于 Alfred，我们第一反应是一款启动器，其次是一个 workflow 的入口，例如我们通过 Alfred 可以快速在淘宝、京东搜索商品，以及其他一些操作，细细品味，你会发现 Drafts 其实是 iOS 版上的 Alfred。
总结
本篇文章，着重在于宣传一种理念，一种使用 Drafts 当入口的理念。Drafts 的设计初衷就是让你「先记录，再分发」，这样的好处在于，你不会因为需要考虑下一步该干什么，而丢失了自己原本想记录的东西
还有什么要说的
还有什么值得要说的呢？为什么我一直在提 URL scheme 而不提 javascript 呢？Drafts 是支持内建 javascript 的，但也仅限在 Drafts 内，本文旨在说明利用 Drafts 作为串联多个需要信息输入的应用的一个「入口」，而串联 APP 需要的是 URL scheme，而不是 javascript。
Boyux 