标签: iOS

译文 | Marzipan 带来的期待

译者按:本文原题为《What to Expect From Marzipan》,是国外知名设计团队 Iconfactory 的博客文章。文章讨论了苹果预计将在今年 WWDC 上正式发布、用于将 iOS 应用迁移到 macOS 上的 Marzipan 框架,及其对开发者和设计师两个群体的潜在影响。文章指出,尽管 Marzipan 让从 iOS 到 macOS 的过渡看起来只是点开一个开关的功夫,但实际工作远没有那么简单。相反,优秀的应用必须针对 Mac 平台的键鼠操作、屏幕尺寸和多窗口等特性作出功能和设计上的适配,并考虑到更专业用户群体的需求。文章反复提及了苹果系统历史上的数次类似变迁,并对 Marzipan 在短期问题后的最终成功表达了乐观态度。文章最后以一段巧妙而应景的植入式广告结尾。

钟颖对译文的初稿提出了宝贵的专业意见,在此表示感谢。


今年的 WWDC 很显然会是不同寻常的一届。我们此前在本站写过关于黑暗模式的思考,现在该来谈谈即将走进 Mac 的 iOS 应用了。

我指的当然就是 …

挖掘 Safari 阅读列表的潜力

Safari 阅读列表是 macOS 和 iOS 上一个比较容易被忽视的功能。该功能最初出现在 2011 年的 OS X Lion 和 iOS 5 系统中,但除了在次年加入了离线缓存,它基本就在这八年间一成不变,与 Pocket、Instapaper 等专职的稍后读服务相比显得十分简陋。

我自己之前也很少使用阅读列表功能,而是用 Pinboard 结合 Instapaper 解决稍后读的需求。这套组合虽然总体让我满意,但也不是尽善尽美,最明显的不足就在于添加链接时的繁琐。特别是在那些没有分享按钮的界面,每添加一个链接都要经历长按链接—选择「分享」—点击应用图标三个步骤。在需要连续保存很多链接时(例如阅读 newsletter 或播客的 show notes),重复这套繁琐的步骤接近一种折磨。另外,Instapaper 的同步也受到 iOS 对后台进程的限制,在信号不好时添加的链接,往往需要事后手动刷新一次才能反映在其他设备上。

相比之下,作为系统自带功能,Safari 阅读列表具有第三方应用难以企及的特权。「添加到阅读列表」的选项几乎无处不在,并且总是处于第一级菜单的显著位置,新增链接在任何时候不会需要超过两次点击。不仅如此,阅读列表作为一个系统服务,可以始终保持后台运行,并且通过 iCloud 近乎即时地在各设备间同步。

发现了这些优点后,我在近几个月试着更多地利用 Safari 阅读列表。为了扬长避短,我主要在两种场景下使用这一功能:其一,将阅读列表作为暂存空间,用来处理一些不需要长久保存的页面;其二,将阅读列表作为第三方工具的「前端」,利用它保存链接时的便捷,然后通过脚本将其内容自动同步到其他稍后读服务。…

用小书签改善 Safari 网页阅读效果

我们每天都要浏览大量的网页,但不是每个网页的设计都能做到为读者着想。实际上,相当比例的网页设计十分糟糕,读起来非常费劲。对此,Safari 的阅读模式是一个不错的解决方案,但并不是在所有网页上都能成功启用、或是取得理想的效果。使用 Stylish、Tampermonkey 等浏览器插件也是一种途径,但不适用于 iOS,而桌面版 Safari 也对第三方插件越发不友好了。

上述问题可以通过使用小书签(bookmarklet)来解决。小书签的本质是一段 JavaScript 脚本,典型用途之一就是修改当前浏览器页面的外观,包括但不限于字体、字号、颜色等。相比于完整的浏览器插件,小书签尽管功能比较简陋,但优势在于通用性极强,可以用在包括 iOS 版 Safari 在内的任何浏览器上。

要将小书签添加到 Safari 中,最简单的方法是在桌面端操作,将下文给出的链接拖拽到书签栏即可;它们会随着 iCloud 同步到 iOS 端。如果要在 iOS 上操作,则可以先长按复制这些小书签的链接,然后任意将一个网页(例如本页)保存到收藏夹,再通过编辑功能将其链接改为前面复制的内容。

注:小书签是一个历史相当久远的功能,网上的资料也很丰富(少数派几年前有过一篇很详尽的文章),故本文不多赘述其原理和制作方法。

修改网页字体

字体是网页设计中的重要环节。选用一个美观的字体组合,不仅能让用户阅读信息更加顺畅,也有利于增强网站的视觉辨识度。遗憾的是,很多网页设计者都忽略或者滥用了字体设计。有的不加考虑,放任系统调用 Arial、Times New Roman 等让人直翻白眼的回退字体;有的则矫枉过正,选择了一些乍看很有风格、实则根本不适合阅读的「个性」字体。遇到这类网页时,运行下面这个小书签,可以将页面字体统一为系统默认字体(San Francisco),获得更好的可读性。…

在 iOS 主屏幕上添加 iCloud 文件快捷方式

文件操作是 iOS 长久以来让人感到「别扭」的功能弱项。究其原因,很大程度上是 iOS 的文件操作逻辑与桌面系统截然不同:同样是打开一个文档,在桌面端,第一步通常是在文件管理器中找到文档本身,然后再考虑用什么程序打开它;而到了 iOS 上,操作顺序则完全相反——先是打开应用,然后才是找到需要的文档。

这种操作逻辑是 iOS「沙盒」机制的产物。在早期版本的 iOS 中,应用的读写权限被严格限制在其特定的文档目录内,因此打开应用就成了任何文件操作的必经步骤。较新版本的 iOS 略微放松了限制,允许应用读写 iCloud Drive、并通过 Document Provider 扩展相互访问文档,但仍然没有从根本上改变 iOS 的文件操作逻辑。观察 iOS 的「文件」应用的呈现方式,会发现每个应用仍然被赋予了一个独立的文件夹,并且和用户创建的其他文件夹是平级的。这体现的还是一种以应用为中心的思路。

问题在于,我们的工作很多时候不是以应用为起点,而是以项目为起点的。试想你正在撰写一篇文章或者复习一门课程——执行一个「项目」。在电脑上,我们会很自然地为这个项目建立一个文件夹,把相关文件都放入其中。工作时打开这个文件夹,就能很方便地随手调取各个文件。然而,这种顺理成章的操作在 iOS 上并没有对应的实现方式。即使相关文件都存放在同一个文件夹内,你仍然需要分头在各个应用中打开它们。且不论低下的效率,这也是对思路和注意力不必要的干扰。

能不能在 iOS 现有的框架内提高访问文件的效率呢?不妨考虑把主屏幕的空间利用起来。尽管 iOS 设备越做越大,它们的主屏幕却仍然只是个应用启动器,未免显得过于浪费。如果能把经常访问的文件放在主屏幕上,点击即可打开,就能省下很多打开应用—寻找文件的繁琐步骤;不仅如此,还可以像整理图标一样,将同属一个项目的文件放进一个文件夹里,从而在很大程度上模拟我们在电脑上的操作习惯。

本文方法实现的效果

在上图所示的效果中,我们将一个 iCloud Drive 中的 Numbers …

用 Apple Configurator 给 iOS 设备安装中文字体

随着 iOS 设备的性能和功能日渐强大,越来越多的人选择将其作为主力工作设备使用。然而,相比于桌面操作系统,iOS 在办公应用上的一大缺失就是无法自由安装字体。如果说系统内建的西文字体数量尚可满足需求,中文字体仅靠一个苹方撑场面的现状,显然是远远不够的。

俗话说得好,苹果关上一扇门,就会打开一扇窗;在自定义字体上,这句话同样适用。利用苹果提供的 Configuration Profile(配置描述文件)功能,我们就可以方便地控制 iOS 设备的一些隐藏功能,包括自定义字体。

此前,少数派上已经有借助 Workflow 安装字体的教程,App Store 上还有一款名为 AnyFont 的 app 专门用于满足这一需求。可惜的是,它们只能安装体积较小的西文字体,而无法正常安装 CJK 字体。1

但这个问题其实并不难解决。其实,针对描述文件的制作和安装,苹果提供了一个官方工具——Apple Configurator,并通过 Mac App Store 免费提供。借助该工具,我们就能方便地生成包含自定义字体的描述文件并安装到设备上。

更重要的是,由于 Apple Configurator 的本意是为企业和学校等机构提供一个批量部署 iOS 设备的工具,它对于批量、重复操作是非常友好的,这也就意味着能用较少的时间一次性安装好常用字体。

下面,我们以安装开源的 Source

iOS 11 中的新播客 App

在 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 虽然仍可被划入拟物界面之列,但界面控件已经被抽象符号取而代之,体现了 …

用 Drafts 优化 OmniFocus 的批量任务收集

一、文本化的任务收集

「收集」是 GTD 流程中的第一步,也是至关重要的一步。面对头脑中随时一闪而过的各种想法,能否准确而快速地将其收集到 Inbox 中,决定了任务管理是否有效。此外,在收集想法到 Inbox 中时,我们往往需要同时添加若干条新事项,而不希望被繁琐的「添加—保存」步骤拖慢效率、打断思路。

针对这种需求,主流任务管理 app 大多都提供一种「快速添加」的功能,即在界面上提供一个按钮(如 OmniFocus 中的「Save+」),当用户输入完一条任务信息并点击该按钮时,应用不会回到主界面,而是保存该条任务并清空输入框,让用户可以直接继续输入。

OmniFocus 中的快捷输入功能

但这种功能的局限也是明显的,所谓的「快速添加」并没有那么快捷。用户不仅需要手动打开 app、点击添加按钮,而且如果想修改截止日期、备注等具体参数,仍然需要多次点击。

这不禁促使我们思考:是否存在这样一种方式,能够一步到位地批量收集任务并定义其具体参数呢?

事实上,这样的方法是存在的,那就是用文本来描述任务。

来看下面这段语句:

- Item 1 @due(+1d 10p)
- Item 2 @defer(tue)

即便不加说明,读者应该也能很容易猜出它的含义。这段语句描述了两个任务 Item 1Item

记构建阅读列表的几次尝试

问题的提出和需求分析

关于数字阅读流程的分析和分享,现有的讨论已经很充分了。不过,这些讨论主要关注阅读和处理两个阶段,而对收集阶段则着墨不多。这本身固然没错:一方面,收集阶段一个不可回避的话题是内容源,而这是一个很个人化的选择,并无对错和规律可言;另一方面,更多人在数字阅读中遇到的主要困难,在于如何有效消化已显过剩的内容,而过多的收集只会进一步加剧这一问题。

但在对数字阅读的实践中,我逐渐发现收集的意义并不亚于阅读和处理。下列情形相信各位都不陌生:你原本只是想浏览 RSS 中的新文章或 Twitter 上的新推文列表,但点进某个链接后,却发现其中的另一个链接也十分有趣,于是再次点击跳转。在反复的跳转中,你最终忘记了最初的目的只是读完一个列表,却花费了数倍于原本需要的时间。又或者,你在浏览中遇到一则希望进一步处理的内容,却因时间或场合的限制无法细看:它未必是长文,可能是视频、漫画交互式网页,因此直接发送到传统的稍后读服务并不合适;只凭标题和匆匆一瞥,你也不能判断它是否值得仔细消化,因此存入笔记类 app 也无意义。这就造成了一种阅之无暇、存之无处、弃之可惜的尴尬局面

之所以会出现上述困境,归根结底是因为网络本身是非线性的,这也是 HTML 的本质特征;但从提高效率、节约时间的角度出发,我们却希望自己的阅读尽可能是线性的,减少因不断跳转和思考如何处理信息带来的不必要干扰。

那么,如何将非线性的信息获取变成线性的呢?很简单,我们只需要引入一个列表:在收集阶段,遇到感兴趣的链接时,不去直接阅读、也不去细想怎样处理,而是直接将其投放到列表中;收集结束后,再查阅这个列表中的链接,逐一浏览、归类,从而与之后的阅读、处理两个步骤衔接起来。当然,为了更好地服务于上述目的,这个列表至少应当具备如下特性

  1. 高效:保存链接的体验应当尽可能迅速、无干扰,保存功能应当在系统的各个位置都可调用,且只需要较少的步骤;
  2. 同步:阅读列表应当尽可能地跨平台,并且无缝地在后台同步

译文 | 我刚删了 iPhone 里一半的应用——你也该删

按:沃特·莫斯伯格(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 …