译者按：本文原题为《What to Expect From Marzipan》，是国外知名设计团队 Iconfactory 的博客文章。文章讨论了苹果预计将在今年 WWDC 上正式发布、用于将 iOS 应用迁移到 macOS 上的 Marzipan 框架，及其对开发者和设计师两个群体的潜在影响。文章指出，尽管 Marzipan 让从 iOS 到 macOS 的过渡看起来只是点开一个开关的功夫，但实际工作远没有那么简单。相反，优秀的应用必须针对 Mac 平台的键鼠操作、屏幕尺寸和多窗口等特性作出功能和设计上的适配，并考虑到更专业用户群体的需求。文章反复提及了苹果系统历史上的数次类似变迁，并对 Marzipan 在短期问题后的最终成功表达了乐观态度。文章最后以一段巧妙而应景的植入式广告结尾。
钟颖对译文的初稿提出了宝贵的专业意见，在此表示感谢。
今年的 WWDC 很显然会是不同寻常的一届。我们此前在本站写过关于黑暗模式的思考，现在该来谈谈即将走进 Mac 的 iOS 应用了。
我指的当然就是 …
Safari 阅读列表是 macOS 和 iOS 上一个比较容易被忽视的功能。该功能最初出现在 2011 年的 OS X Lion 和 iOS 5 系统中，但除了在次年加入了离线缓存，它基本就在这八年间一成不变，与 Pocket、Instapaper 等专职的稍后读服务相比显得十分简陋。
我自己之前也很少使用阅读列表功能，而是用 Pinboard 结合 Instapaper 解决稍后读的需求。这套组合虽然总体让我满意，但也不是尽善尽美，最明显的不足就在于添加链接时的繁琐。特别是在那些没有分享按钮的界面，每添加一个链接都要经历长按链接—选择「分享」—点击应用图标三个步骤。在需要连续保存很多链接时（例如阅读 newsletter 或播客的 show notes），重复这套繁琐的步骤接近一种折磨。另外，Instapaper 的同步也受到 iOS 对后台进程的限制，在信号不好时添加的链接，往往需要事后手动刷新一次才能反映在其他设备上。
相比之下，作为系统自带功能，Safari 阅读列表具有第三方应用难以企及的特权。「添加到阅读列表」的选项几乎无处不在，并且总是处于第一级菜单的显著位置，新增链接在任何时候不会需要超过两次点击。不仅如此，阅读列表作为一个系统服务，可以始终保持后台运行，并且通过 iCloud 近乎即时地在各设备间同步。
发现了这些优点后，我在近几个月试着更多地利用 Safari 阅读列表。为了扬长避短，我主要在两种场景下使用这一功能：其一，将阅读列表作为暂存空间，用来处理一些不需要长久保存的页面；其二，将阅读列表作为第三方工具的「前端」，利用它保存链接时的便捷，然后通过脚本将其内容自动同步到其他稍后读服务。…
我们每天都要浏览大量的网页，但不是每个网页的设计都能做到为读者着想。实际上，相当比例的网页设计十分糟糕，读起来非常费劲。对此，Safari 的阅读模式是一个不错的解决方案，但并不是在所有网页上都能成功启用、或是取得理想的效果。使用 Stylish、Tampermonkey 等浏览器插件也是一种途径，但不适用于 iOS，而桌面版 Safari 也对第三方插件越发不友好了。
上述问题可以通过使用小书签（bookmarklet）来解决。小书签的本质是一段 JavaScript 脚本，典型用途之一就是修改当前浏览器页面的外观，包括但不限于字体、字号、颜色等。相比于完整的浏览器插件，小书签尽管功能比较简陋，但优势在于通用性极强，可以用在包括 iOS 版 Safari 在内的任何浏览器上。
要将小书签添加到 Safari 中，最简单的方法是在桌面端操作，将下文给出的链接拖拽到书签栏即可；它们会随着 iCloud 同步到 iOS 端。如果要在 iOS 上操作，则可以先长按复制这些小书签的链接，然后任意将一个网页（例如本页）保存到收藏夹，再通过编辑功能将其链接改为前面复制的内容。
注：小书签是一个历史相当久远的功能，网上的资料也很丰富（少数派几年前有过一篇很详尽的文章），故本文不多赘述其原理和制作方法。
字体是网页设计中的重要环节。选用一个美观的字体组合，不仅能让用户阅读信息更加顺畅，也有利于增强网站的视觉辨识度。遗憾的是，很多网页设计者都忽略或者滥用了字体设计。有的不加考虑，放任系统调用 Arial、Times New Roman 等让人直翻白眼的回退字体；有的则矫枉过正，选择了一些乍看很有风格、实则根本不适合阅读的「个性」字体。遇到这类网页时，运行下面这个小书签，可以将页面字体统一为系统默认字体（San Francisco），获得更好的可读性。…
文件操作是 iOS 长久以来让人感到「别扭」的功能弱项。究其原因，很大程度上是 iOS 的文件操作逻辑与桌面系统截然不同：同样是打开一个文档，在桌面端，第一步通常是在文件管理器中找到文档本身，然后再考虑用什么程序打开它；而到了 iOS 上，操作顺序则完全相反——先是打开应用，然后才是找到需要的文档。
这种操作逻辑是 iOS「沙盒」机制的产物。在早期版本的 iOS 中，应用的读写权限被严格限制在其特定的文档目录内，因此打开应用就成了任何文件操作的必经步骤。较新版本的 iOS 略微放松了限制，允许应用读写 iCloud Drive、并通过 Document Provider 扩展相互访问文档，但仍然没有从根本上改变 iOS 的文件操作逻辑。观察 iOS 的「文件」应用的呈现方式，会发现每个应用仍然被赋予了一个独立的文件夹，并且和用户创建的其他文件夹是平级的。这体现的还是一种以应用为中心的思路。
问题在于，我们的工作很多时候不是以应用为起点，而是以项目为起点的。试想你正在撰写一篇文章或者复习一门课程——执行一个「项目」。在电脑上，我们会很自然地为这个项目建立一个文件夹，把相关文件都放入其中。工作时打开这个文件夹，就能很方便地随手调取各个文件。然而，这种顺理成章的操作在 iOS 上并没有对应的实现方式。即使相关文件都存放在同一个文件夹内，你仍然需要分头在各个应用中打开它们。且不论低下的效率，这也是对思路和注意力不必要的干扰。
能不能在 iOS 现有的框架内提高访问文件的效率呢？不妨考虑把主屏幕的空间利用起来。尽管 iOS 设备越做越大，它们的主屏幕却仍然只是个应用启动器，未免显得过于浪费。如果能把经常访问的文件放在主屏幕上，点击即可打开，就能省下很多打开应用—寻找文件的繁琐步骤；不仅如此，还可以像整理图标一样，将同属一个项目的文件放进一个文件夹里，从而在很大程度上模拟我们在电脑上的操作习惯。
在上图所示的效果中，我们将一个 iCloud Drive 中的 Numbers …
随着 iOS 设备的性能和功能日渐强大，越来越多的人选择将其作为主力工作设备使用。然而，相比于桌面操作系统，iOS 在办公应用上的一大缺失就是无法自由安装字体。如果说系统内建的西文字体数量尚可满足需求，中文字体仅靠一个苹方撑场面的现状，显然是远远不够的。
俗话说得好，苹果关上一扇门，就会打开一扇窗；在自定义字体上，这句话同样适用。利用苹果提供的 Configuration Profile（配置描述文件）功能，我们就可以方便地控制 iOS 设备的一些隐藏功能，包括自定义字体。
此前，少数派上已经有借助 Workflow 安装字体的教程，App Store 上还有一款名为 AnyFont 的 app 专门用于满足这一需求。可惜的是，它们只能安装体积较小的西文字体，而无法正常安装 CJK 字体。1
但这个问题其实并不难解决。其实，针对描述文件的制作和安装，苹果提供了一个官方工具——Apple Configurator，并通过 Mac App Store 免费提供。借助该工具，我们就能方便地生成包含自定义字体的描述文件并安装到设备上。
更重要的是，由于 Apple Configurator 的本意是为企业和学校等机构提供一个批量部署 iOS 设备的工具，它对于批量、重复操作是非常友好的，这也就意味着能用较少的时间一次性安装好常用字体。
下面，我们以安装开源的 Source …
在 iOS 的众多内置 app 中，「播客」应当算是资历尚浅的一个。比起筚路蓝缕时就陪伴 iOS 一起成长的 Safari、邮件和音乐这几个元老级 app，在 2012 年之前，播客一直都是以音乐 app 的一个子功能形式存在的。2012 年 6 月，苹果宣布发布独立的播客客户端，播客 app 这才以独立的身份示人，而作为内置 app 被整合到系统中，则更是要等到两年后的 iOS 8 时代了。
尽管如此，从诞生起，播客 app 已经经历了数次界面上的大改。1.0 版本的播客 app 充满了前 iOS 7 时代的重度拟物风格，播放界面更是直接致敬了博朗经典的录音机 TG 60。2013 年三月，1.2 版本的播客 app 虽然仍可被划入拟物界面之列，但界面控件已经被抽象符号取而代之，体现了 …
「收集」是 GTD 流程中的第一步，也是至关重要的一步。面对头脑中随时一闪而过的各种想法，能否准确而快速地将其收集到 Inbox 中，决定了任务管理是否有效。此外，在收集想法到 Inbox 中时，我们往往需要同时添加若干条新事项，而不希望被繁琐的「添加—保存」步骤拖慢效率、打断思路。
针对这种需求，主流任务管理 app 大多都提供一种「快速添加」的功能，即在界面上提供一个按钮（如 OmniFocus 中的「Save+」），当用户输入完一条任务信息并点击该按钮时，应用不会回到主界面，而是保存该条任务并清空输入框，让用户可以直接继续输入。
但这种功能的局限也是明显的，所谓的「快速添加」并没有那么快捷。用户不仅需要手动打开 app、点击添加按钮，而且如果想修改截止日期、备注等具体参数，仍然需要多次点击。
这不禁促使我们思考：是否存在这样一种方式，能够一步到位地批量收集任务并定义其具体参数呢？
事实上，这样的方法是存在的，那就是用文本来描述任务。
来看下面这段语句：
- Item 1 @due(+1d 10p)
- Item 2 @defer(tue)
即便不加说明，读者应该也能很容易猜出它的含义。这段语句描述了两个任务 Item 1 和 Item …
关于数字阅读流程的分析和分享，现有的讨论已经很充分了。不过，这些讨论主要关注阅读和处理两个阶段，而对收集阶段则着墨不多。这本身固然没错：一方面，收集阶段一个不可回避的话题是内容源，而这是一个很个人化的选择，并无对错和规律可言；另一方面，更多人在数字阅读中遇到的主要困难，在于如何有效消化已显过剩的内容，而过多的收集只会进一步加剧这一问题。
但在对数字阅读的实践中，我逐渐发现收集的意义并不亚于阅读和处理。下列情形相信各位都不陌生：你原本只是想浏览 RSS 中的新文章或 Twitter 上的新推文列表，但点进某个链接后，却发现其中的另一个链接也十分有趣，于是再次点击跳转。在反复的跳转中，你最终忘记了最初的目的只是读完一个列表，却花费了数倍于原本需要的时间。又或者，你在浏览中遇到一则希望进一步处理的内容，却因时间或场合的限制无法细看：它未必是长文，可能是视频、漫画或交互式网页，因此直接发送到传统的稍后读服务并不合适；只凭标题和匆匆一瞥，你也不能判断它是否值得仔细消化，因此存入笔记类 app 也无意义。这就造成了一种阅之无暇、存之无处、弃之可惜的尴尬局面。
之所以会出现上述困境，归根结底是因为网络本身是非线性的，这也是 HTML 的本质特征；但从提高效率、节约时间的角度出发，我们却希望自己的阅读尽可能是线性的，减少因不断跳转和思考如何处理信息带来的不必要干扰。
那么，如何将非线性的信息获取变成线性的呢？很简单，我们只需要引入一个列表：在收集阶段，遇到感兴趣的链接时，不去直接阅读、也不去细想怎样处理，而是直接将其投放到列表中；收集结束后，再查阅这个列表中的链接，逐一浏览、归类，从而与之后的阅读、处理两个步骤衔接起来。当然，为了更好地服务于上述目的，这个列表至少应当具备如下特性：
按：沃特·莫斯伯格（Walt Mossberg）是美国知名的资深科技记者，现在科技媒体 The Verge 担任执行编辑，兼任 Recode 的总编，并在两站上设有以自己名字命名的每周专栏，内容主要为科技评论和设备评测。本文译自他 2016 年 7 月 20 日发表在该专栏中的文章《I just deleted half my iPhone apps — you should too》。
Pokémon Go 也许算是引发了轰动，可 App Store 的新颖再也回不来了。
过去几天里，我有计划地从 iPhone 里删掉了 165 个应用——这占到我进行「围剿」前全部 305 个应用的 54%。完成这项工作后，手机一团乱麻的局面得到了明显改观：原来主界面的 15 屏现在只剩 8 …