洞察·流程
利用 Safari 构建基于 Web 的工作流
当 Safari 在 iOS 13 上迎来新生之后，过去的两个月里，我在思考回归 Web 工作的可能性，这一期的「iPad Power User」，我将汇报一些阶段性的进展，需要说明一下，这些记录只是我在这个夏天的总结，未来的工作流程或许还会有不少变化。
在开始之前，有必要先来回答一个问题：为什么要用浏览器工作？
我觉得最关键原因就是，当下绝大多数 iPad 上的应用不足以真正利用 iPad 的硬件条件，比如最基本的屏幕，除了 7.9 英寸的 iPad Mini，iPad 及 iPad Pro 产品线的屏幕尺寸都在 9.7 英寸及以上，但即便是像 Google 这样的公司，都没有针对 9.7 英寸以及之上的屏幕尺寸 iPad 做优化，比如 Gmail，到现在都无法在 iPad 上实现分屏操作。
其次，或许是为了考虑 iPad 的性能，很多应用在 iPad 上都是「阉割版」，或者文雅一点，叫「轻量版」。如果说过去使用阉割版应用是迫不得已，毕竟当时 Safari 根本无法实现桌面浏览器的效果，那么现在，当 Safari 具备了一定能力之后，用户自然而然要探索如何在 iPad 上体验到更好的应用。
当然，并不是所有应用都适合回归到 Safari，一方面，大量应用没有 Web 版，比如类似 Kindle 或 PDF Expert 这样的工具型应用，另一方面，对于大量有交互属性的应用，比如类似 Twitter、微博等社交媒体的产品，即便可以通过 Web 访问，但目前的 Safari 上还无法实现网页通知，这也意味着，你需要不断刷新才能看到有没有新的回复。
我将自己的三个工作场景迁移到了 Web。
邮件：Gmail 网页版
我每天大概会收到 100 封邮件，这 100 封邮件分为以下几类：
- 业务沟通：来自订阅会员、公关公司、科技媒体以及其他工作的邮件，每天大约 30 多封；
- 事件通知：包括信用卡消费、服务器邮件系统通知等等，每天 20 多封；
- 新闻订阅：付费或免费订阅的邮件通讯，这部分的内容每天都在 50 封左右；
过去很长一段时间里，我使用 Spark 处理邮件，我也在《iPad Pro 生产力指南》里多次推荐过这个产品。但对我来说，有几个痛点：其一，邮件提醒太频繁，尽管 Spark 提供了智能提醒，但这个机制非常模糊，我并不清楚其原理，所以每天还是会收到大量的邮件提醒；其二，Spark 的邮件过滤机制太过于简单，如下图所示，新建「智能文件夹」，输入关键词后能选择的筛选条件非常少，这对于像我这样每天收到如此多邮件的人来说，很明显无法满足我的需求。
另外一点，虽然我每天收到的的邮件很多，但绝大多数邮件并不需要实时回复，因此实时通知功能并不必要，我只需要每天拿出一个半小时集中处理就好。这也让我更坚定了回归 Web 的决心。在 iPadOS 的 Safari 上，我又体验到了久违的 Gmail 网页版的强大。
关于 Gmail 功能的介绍已经非常多了，我这里只提一个自己感觉最实用的功能，那就是过滤器，你可以建立无数个过滤器，让邮件自动归类，下图展示的这个过滤器，是处理来自「zhaosaipo@iois.me」的邮件，是选择直接归档？还是加注星标，你都可以自行定制。
通过一个个过滤器，邮件不再是堆叠，而实现了半自动化的归类处理，便于以后的查询。
办公文档：Google Drive
iOS 上的 Google Drive 只是一个能用的网盘，可以满足基本的上传下载以及在「三件套」（文档、表格、演示）里打开文件，是一个不扯不扣的「轻量级」应用，但事实上，Google Drive 的网页版非常强大。
如下图所示，你可以新建如此多格式的文档，而且还可以上传文件、文件夹。
我在之前曾利用 Drafts 的一个 Action 将很多记录发送到 Google Drive，这些 md 格式的文档在 Google Drive 的客户端里无法直接打开，而在网页版，利用 StackEdit，可以直接打开阅读并编辑，所有修改会实时保存。
工具箱：在线处理图片、管理云服务器、管理对象存储等
图片处理。图片处理一直是我内容创作的重要环节，就像这封会员通讯，每一张图片都涉及截图、压缩、上传多个环节。在图片处理中，我一直使用在线服务 iloveimg ，如下图所示，它可以满足几乎所有的图片处理需求。值得一提的是，每个服务都支持从 Google Drive 里获取图片并可以将处理好的图片直接保存到 Google Drive，实现了在线服务的协同。
如果你也需要经常使用云服务器，比如 AWS 或者 GCP 的产品，一定体验过如何在 MacBook 或 Windows 电脑上修改密码然后再去 iPad 上设置访问，但当手边没有笔记本怎么办呢？Safari 现在支持了 GCP 计算实例的直接访问，最好配置蓝牙键盘，便可以进行基本操作。
说明一下，我没有尝试 AWS EC2，不过 Safari 直接访问 AWS 的 Lightsail 主机是没有问题的。
对象存储。我目前使用两个对象存储服务，AWS S3 和又拍云，前者目前在 iOS 上只有 Coda 可以访问，而后者则通过 FTP 来快速访问。
但这两种方式也有一些问题。比如 Coda 虽然可以实现文件快速的上传下载，但没有对存储桶的管理功能，很多功能还是需要在网页上操作；而又拍云的访问方式看似简单直接，但它的 FTP 访问速度非常慢，相对于桌面端多样性的文件工具，留给 iPad 的选择也只有通过浏览器了。
下图是 S3 的上传界面，在我的测试中，你可以在「文件」应用或「照片」里拖动文件到浏览器，完成上传。
小结
如此使用 Safari，从某种意义上也是对于 iPad 应用生态的无奈，无数个「轻量级」的应用极大限制了这台设备的潜力，而利用 Web，可以有效补充大量应用缺失或功能被阉割的现实困境。但正如我在文中所言，并不是所有的应用都支持 web，而即便支持，有些产品的体验也非常差，比如 Notion，这也让我很期待 Safari 未来的演化之路。
|
