标签: App

Yoink for iOS 评测

Yoink 是上世纪随着《辛普森一家》(The Simpsons)动画的热播而进入英语词汇的拟声词。每当片中人物从别人那里一把抓来什么东西时,总是会喊一声「Yoink!」宣告得手。

iOS 11 中,随着 Drag and Drop(拖放)功能的加入,用户也终于可以随意地从各个 app 中「抓」走自己想要的内容,包括文字、图片、链接、文档等等。随之而来的问题是:抓来的东西该往哪放?实际操作中,我们往往并不能当即确定拖拽操作的目的地,或者想用来接收的 app 尚未打开,不方便一步拖动到位。一种解决思路是,给拖拽项目找一个临时的「停放地」,允许我们先把精力集中在收集上,事后再决定去向问题。

这正是 Yoink 要解决的需求。

在英文 app 圈中,Yoink 这类工具往往被统称为「shelf」(架子)类 app。顾名思义,它们的作用就是充当一个临时的「置物架」,临时存放我们想要收集却又未确定归属的内容。显然,它们的功能也就是围绕着项目从拖进到拖出的流程开发的。

Yoink 也不例外。如下图所示,其交互和功能可划分为输入—管理—输出三个前后相连的部分。下面,我们也按照这样的顺序介绍 Yoink 的使用。

Yoink 的功能和交互

输入

将外部数据导入 Yoink 有三种方法:拖拽、导入

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

播客客户端音频特效探微

修订

2017/05/27:加入了对 Castro 2.4 版中 Enhanced Audio 功能的测试。


问题的提出

播客可能已经迎来了自己最好的时代。随着聆听播客时间日渐延长,用户自然也会对播客传播流程中的最后一站——播客客户端提出更高的要求。因此,播客客户端市场的繁荣也是情理之中的了。

目前,市场上知名度和评价最高的播客客户端当数 CastroOvercastPocket Casts 三款。其中,Castro 凭借流畅的动效和独特的 RSS 式管理方法独树一帜;Overcast 背靠 Marco Arment 的个人影响力和技术实力、以及不断演进的收费策略,牢牢把控话题点;而 Pocket Casts 则有着精致的设计和少见的跨平台支持,同样吸引了大批拥趸。

然而,播客客户端其实并非一个功能复杂的应用形态。无论怎样创新,它的核心功能永远只有一个:播放。相对于其他热门应用类别,用户花在与其进行视觉交互上的时间是相当有限的。因此,要在激烈的竞争中脱颖而出,开发者就必须将眼光放在那些用户「看不见」的地方,靠提升播放体验的软实力聚集人气。事实上,Overcast 之所以能在早期吸引大批用户,一个重要原因就是它具有两个「杀手级」功能:Smart Speed 和 Voice Boost,前者能减少播客节目中的停顿,后者则能提高人声的音量。后来,Pocket Casts 在一次大版本更新中也增加了这两个功能,只不过名称对应地改为 Trim Silence …

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

问题的提出和需求分析

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

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

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

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

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