作者:Platy Hsu

译文 | Marzipan 带来的期待

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

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


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

我指的当然就是 …

「第一步」>「第二步」,还是「第一步 – 第二步」?

在写操作说明类文章时,经常需要描述包含多步的操作。这种场合,我个人倾向的用法是 「第一步」「第二步」。这个用法最初是从苹果那里学来的,中文的苹果说明书统一使用 “第一步” “第二步” 的体例,将其中的引号换成直角引号,就是我的用法。

不过,最近我发现少数派的编辑总是会把首页文章手工改成 「第一步 - 第二步」 的形式。经过沟通,得知那是他们的内部体例,理由是苹果早年的用法是 “第一步” - “第二步”,而他们一方面和我一样想换用直角引号,另一方面又嫌步步打引号太啰嗦,而且直角引号和连字符之间间距太大,所以简化成了现在的形式。

个人角度,我觉得这种用法在视觉上还算清晰,但语义上不太说得通。第一,如果给每个步骤单独打上引号,可以认为是在使用引号「表示特定称谓」的功能;但只在整个步骤的首尾打上引号,似乎在功能上找不出什么理由。如果只是为了和前后文作视觉区隔,用空格或者粗体会不会更简单有效呢?第二,如果选择用「横线」连接各个步骤,或许更规范的做法是选用 em dash()而不是连字符。

当然,体例问题很多时候无所谓对错,关键是统一,所以我只是建议他们把这些内部规范公布出来,以便用户参考。

借此机会,我还顺手查了一下几家主流系统厂商的内部规范:

《苹果体例指南》Apple Style Guide):

Pull-down menus: A pull-down menu is a menu in the menu

挖掘 Safari 阅读列表的潜力

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

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

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

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

钥匙找不到以后

星期四晚上从图书馆回来,发现钥匙找不到了。找公寓管理员借来备用钥匙进门以后,发现房间里也没有。摸着口袋里不知道什么时候多出来的一个洞,估计大概率是丢在外面的,找回来的希望比较渺茫。查了一下学校公寓的管理规定,钥匙丢失需要直接换门锁,收费 $200 不还价,毫无疑问会是一笔大出血。好在借我钥匙的宿管是个亚洲脸,看起来比较友善,跟我说一天之内还回去就行,于是多出来 24 个小时苟延残喘的时间。

如果是在国内,我大概会直接去附近超市配一把钥匙完事。但目前我第一不知道哪里可以配到钥匙,第二还不清楚在美国配钥匙是不是合法。不过毕竟 200 块损失就在眼前,先出门找配锁的地方再说。

从 Google Maps 的搜索结果看,情况似乎还比较乐观。有一家 2012 年成立的叫做 KeyMe 的公司,在 711、Raid Aid 等主要便利店都设置了自助售货机式的配锁机器,把钥匙插进去就能即时「打印」出来一把一样的。然而,找到最近的一家 711 里的 KeyMe 机器,发现没有办法复制我手上这把。界面提示这把钥匙属于「特殊型号」,必须将扫描结果传回总部制作,等三五天以后寄过来。且不论这是不是个套路,我也等不了三五天。然而天色已晚,只能天亮再找锁匠解决了。

第二天起来以后去了 Chinatown。实际上离学校更近的地方有 Latino 开的锁店,但考虑到沟通效率问题和潜在的法律风险,似乎还是找华人更好办事。到了以后,果然几家超市和五金店的门口都贴了配钥匙的招牌。但走了两三家,店主都是先说能配,但拿到钥匙端详以后就说没有这种型号。再走到附近一家外国人开的 locksmith,则更直接告诉我这种钥匙不能配。另外,虽然我没说钥匙的来源,几家店都直接建议我直接去找公寓管理员重新拿钥匙。

配钥匙的问题放在一边,这种一致的回应倒是比较令人好奇。从我作为外行的角度看,这把钥匙不能再普通了。黄铜外观,也看不出什么特殊的安全设计。既然这样,那几家店是从什么地方看出来这是公寓钥匙的?不能配钥匙是因为什么法律上的限制吗?

简单检索以后发现,美国对配钥匙的限制,在法律层面并不比中国严格多少。联邦层面,法律只规制邮局(18 U.S.C. § 1704)和国防部(18 U.S.C. § 1386)钥匙的复制。大多数州也没有类似立法,只有个别如加州(CA BUS & PROF § …

Apple News+ 一周体验

虽然今年苹果春季发布会的阵容与人们预期的一样强大,但最终发布的「现货」只有 Apple News+ 这一项。关于该服务的优势和亮点,现有的报道已经很充分了。简单概括,就是每月 9.99 美元无限阅读数百种杂志(目前总数为 251 种)、专门为屏幕阅读设计的排版、推荐内容来自真人编辑、比其他平台更好的隐私保护、支持离线阅读及家人共享等。

尽管在之前很少使用系统自带的 News 应用,但作为一个喜欢翻阅各种外刊的读者,我很难不对 Apple News+ 产生浓厚的兴趣。由于今年恰好有地理位置上的便利,我在发布会结束后的第一时间便升级了系统、开启了该服务的免费试用,并在这近一周的时间内花了很多时间在 News 应用中阅读。本文将介绍我这段时间的使用体验,并尝试探讨 Apple News+ 对用户的价值。

惊艳的第一印象

点进新增的 News+ 页面后,居于最上方的是杂志的分类目录和近期阅读的杂志封面。如果关注了特定杂志的频道,该杂志的新刊会自动出现在「我的杂志」书架上。点按杂志标题右侧的下载图标,可以将整本杂志缓存到本机,以供没有网络连接时阅读(但有 30 天的有效期限制)。不过,杂志一旦下载就不能手动删除,只能等待 News 应用在 30 天后或设备容量不足时自行清理。

Apple News+ 在 iPhone 和 iPad 上的界面
Apple News+ 在 iPhone 和 iPad 上的界面

向下滑动,就能看到 News+ …

信息消费——从入门到放弃

本文参加少数派 2019 年度征文。(链接


我一直认为自己是一个喜欢被信息包裹的人。对我来说,「网上冲浪」不是一种比喻,而更像是真实的感受。信息的浸泡能让我感到和游泳一般的满足和愉快。

我也一直对自己掌握了不少获取信息的门路感到自豪。或许是因为长期上网锻炼的直觉,即使面对不熟悉的话题,我也经常能辗转找到有用的信息。如果被问到信息检索和管理的工具,我可以如数家珍地列出一大把,并且点评一番它们各自的长短优劣。

在之前的几年中,「发现信息」构成了我数字生活的主题。一些契机让我将主要目光转移到英文内容上,进而发现了大量有趣、高质量的信息来源;播客成为了我生活的重要部分,让我得以在更多场景下接受信息的输入。我还花了很多精力钻研工具和方法,试图给自己的信息消费规划出最优的「食谱」。尽管知道还有改善的空间,但我仍然觉得自己走在正确的轨道上。

这种自我认同在过去的一年遇到了挑战。随着每天在各种信息源上花费的时间越来越多,我却没有感到自己的收获成比例地增长。相反,获取资讯很多时候成为了一种例行公事,驱使我阅读的似乎是某种不得不完成的义务,而不是最开始纯粹的好奇心。实习、升学等带有诸多变数的事项,更让我意识到之前所习惯的那套获取信息的方式,很大程度上是宽松的学校生活赋予的「特权」,不可能一直持续下去。那些看似严密的规划和流程,在生活的变化面前反而会变成一种束缚。哪怕时间精力允许,我也忽略了一些更为根本的问题:每天「勤勉」地阅读、收听、观看这么多信息,究竟是为了什么?消费这些内容让我在某种程度上变得更好了吗?还是像那些精加工但没有营养的食物一样,只是满足了感官一时的乐趣?

于是,我在去年决定暂时停下来,对之前积攒的信息源和工具方法做一番反思。在实现了信息消费的入门后,「放弃」成为了我 2018 年数字生活的主题。

碎片信息——以定时实现定量

碎片信息给现代人带来的问题已经被翻来覆去地讨论很久了,但它却是以一种比较反讽的方式对我产生影响的。或许是因为看多了相关的批判,我过去在管理碎片信息时颇有些矫枉过正,花了很多功夫研究减少碎片的工具和方法,包括在 RSS 中设定复杂的屏蔽规则,用分组和列表管理在微博/推特上关注的账号,等等。尽管具体做法各不相同,但其思路都是基于过滤和分类。

事实证明,这些方法的收益与投入是不成比例的。碎片信息之所以为「碎片」,就是因为它们在性质上是反过滤、反归类的。无论我的过滤、分组规则制定得多么严密、对现有内容多么有效,都无法保证能适用于之后新加入的内容。而我花在纠结正则表达式写法和 RSS 分组上的精力,反而可能超过了它们为我节省的时间。

因此,我去年「放弃」的对象并不是碎片信息本身,而是之前那套根据内容来过滤和分类的复杂做法。取而代之的,是靠定时来实现定量。我发现,尽管碎片信息的产生从微观层面看是没有规律的,但如果将其放在稍长一些的时间尺度观察,其数量就是有迹可循的。这就好像虽然不能预报一个区域何时降雨,也能根据其气候特征预测月间降水量一样。

例如,我微博和 Twitter 上关注的账号都在 100 个左右,这些账号什么时候会发微博/推文,是我无法预测的。但如果先设定一个目标——例如每次阅读不超过 100 条微博/推文——然后反推,就能发现积累这个数量的未读消息一般需要六个小时左右。类似地,我觉得每次处理三四十条 RSS 是负担较小的,而 NewsBlur 的统计数据告诉我积累这个数目的时间一般也在六个小时。

使用 NewsBlur 查看站点的发文频次
使用 NewsBlur 查看站点的发文频次

实体笔记本启发的 iPad 笔记模板小改进

前段时间偶尔逛到键盘保护套 Canopy 的官网,发现它的厂商是一家挺有意思的设计工作室。除了苹果设备配件,这家名叫 Studio Neat 的工作室还设计了一些文具,包括一款叫做 Panobook 的笔记本。

从介绍看,Panobook 最主要的卖点在于其特殊的尺寸。不同于一般以纵向为默认方向的笔记本,Panobook 是一个狭长的横向矩形(288 mm x 160 mm 或 11.34 in x 6.30 in),它的名字大概也是因此而来。之所以要设计成横过来,应该主要是考虑到在电脑桌上使用的场景:摆着键盘的桌面很难再有空间容纳下一个竖向的本子,水平摆放是让两者和平共处的合理选择。

Panobook 的横向设计便于摆在键盘下面使用(来源:Studio Neat)
Panobook 的横向设计便于摆在键盘下面使用(来源:Studio Neat)

Panobook 在纸张设计上也有一些巧思。除了在背景里印上了非常实用的点阵,Panobook 还在水平方向等分出了三个矩形,并在这些矩形的顶点位置用细微的直角标记加以提示。根据 Studio Neat 的说法,这是为了方便徒手画出线框图、故事板等设计从业者常用的布局。

Panobook 的三等分设计
Panobook 的三等分设计

尽管 Panobook 的定价非常情怀(20 美元一本;我猜主要是产量小,价格谈不下来),而且我也很少用实体纸笔,这个产品倒是给了我改进 iPad 记笔记的方式一些启发。之前在用 GoodNotes …

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

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

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

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

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

修改网页字体

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

PDF 复制中的文字重复问题

前两天,编辑 @⽂⼑漢三 在 Slack 上发给我一个 PDF 文件,问我知不知道为什么从里面复制出的中文会出现「重字」现象。他还提到,这个问题只在用系统自带的预览 app 打开时会出现,用其他 PDF 阅读器复制文字是正常的。

用预览 app 复制出的「结巴」文字

文刀拿这个问题来问我,恐怕是因为我之前写过一篇解释 PDF 格式的文章,觉得我大概会知道答案。不过他其实高估了我的知识水平——我刚开始也不知道这是怎么回事。不过,经过一番搜索,我最终初步搞清楚了问题成因。因为这个问题涉及到一些很有意思的细节,这里把探索的过程写出来,供有类似疑问的朋友参考。


出现问题的 PDF 文档是由一篇少数派文章导出而得的。首先尝试复现问题:用预览 app 打开并随手复制一段,确实出现了很多重复的文字,看起来就像是「结巴」了一样,有一种莫名的喜感。换用 PDF Expert 打开再尝试复制,则没有这样的问题。

虽然不知道问题的具体成因,但根据经验,文字复制中的故障往往与编码有关,而 PDF 格式正是编码问题的大户。

我在之前的文章中提到,PDF 格式是「不识字」的。在显示文字时,阅读器只是机械地根据 PDF 语句的指令,将字体资源中特定码位的字形绘制在坐标指定的位置,而并不关心自己画出来的到底是什么字。只有在进行复制、搜索等操作时,PDF 才会根据内嵌的 CMap,将内部字体的编码和 Unicode 编码对应起来。因此,如果 CMap …

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

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

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

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

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

本文方法实现的效果

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