答鲁鹏

鲁鹏提及:
MarkEditor 在移动文章的时候,会把文章下面的图片一同复制到新的目录下,然后删掉旧目录下的文章,这个功能很赞。
如果把旧文章对应的图片也删掉就更好了,反正都复制了一份,没必要再留着吧。

答:会误删,存在一图多用的情况。


我非常追求完整的表达,或者说是尽可能的完整,不然意味着偏离了真正的思考。
假设实际估值为 100,即使试图完整,结果也只能输出 10。恐怖的是,或许只有输出值达到 1,才能正确地表达。

正确完整,似乎是冲突的。
对此,自己有很大的感触,完整是不需要的,即使已经有了这样的结论,在文字表达的过程中,仍然会偏离这个定论。
这种不断的偏离,或许对他人也会带来些许思考吧。我认为,思考的方式是很难改变的,脑内的操作系统可不容易被替换,除非太弱了;而表达的方法,却是我们都需要改变的,读万物本多数不求甚解,表达者又何必甚答呢?属于你的那一部分,就是无论如何表达,都是不充备的。

好了,接下来都可以当做是原始答案废话的扩充了...

Markdown 与图片

当我们使用 Word 或者 Pages (苹果软件) 的时候,不会产生文章与图片的割裂感,因为图片就在文章内,图片越多,意味着一个 Word 文档的尺寸也就越大。
对于 Markdown 来说,文章中的图片,本质上只是一行文本,图片的本体并不在文章中。或者说,只是建立了一个映射的关系。这个关系,很大程度上又是依赖于路径的,所以,当一篇文章被移动(改变了路径),非常可能原来的路径关系就被破坏了。

用户的层面

最开始的时候,Markdown 之类的 App,是没有插图、图片直接可见这种概念的,都是文本语法。
对于普通用户而言,这是很难理解的。普通用户不需要使用 Markdown?不是的,Markdown 抛开语法的层面,它所表达的是一种简单、人性化。换句话说,我们作为一个普通的用户,需要的可能就是一个可以输入文字,拖入图片就能插入的写作软件。

逐渐地,很多 Markdown 的 App,支持图片直接显示在文本中。
对于赢得普通用户的心而言,本是要如此做的。
所有的易用性,都会带来更大的复杂性问题。比如这个场景下,就会产生一个冲突: 视觉上图片是隶属于文章的,而技术逻辑来讲,图片是独立于文章的。
为了调和这个矛盾,特别是 Mac 的平台上,一个 App 的沙盒环境下数据的存储目录,或者表现为 Library,或者是一个 根目录,于是一个简单粗暴的方法就出现了,就是强制所有的图片都存储于某个固定目录下,那么文章内的图片路径就会相对固定,不会因为文章的位置移动图片就无法显示了。

冲突

用户层面和技术层面的冲突,一旦产生,是极难解决的。
比如我们习以为常的 登录、注册 的逻辑,就是一例。看似多数人不会因为这个,而受到阻碍,是因为已经长期被技术逻辑教育了。

弥合

冲突无法解决,但是可以弥合。
以 MarkEditor 为例,就是文章移动的时候,会同时复制图片到更合适的路径,如此一来文章的图片仍然可以继续可见。
但这个机制也仅限于 MarkEditor 内的操作,如果是 Finder (操作系统的文件管理器) 的操作,那么只是文章的位置改变而已。

用户体验是没有底的
以上面这段为例,即使 Finder 对文件的操作,我们也能实现去多复制一次图片,避免文章的路径变更导致的问题。怎么实现呢?也是简单的, 操作系统提供文件变化监控的 API,即使没有系统 API,那么定时去遍历一次文件夹,获得路径变动,有必要再多复制一次文章包含的图片就可以了。
所以说,体验是没有底线的。只是,真的要这么做吗?有必要吗?

干净与冗余

如果把旧文章对应的图片也删掉就更好了,反正都复制了一份,没必要再留着吧。

这是很好的想法,可以让用户的数据保持干净。多数的用户,也肯定会认为是一个好建议。

产品设计师要避免产生毁灭性的自动操作。自动操作,都是为了更好的体验,但它一旦产生毁灭性的副作用,那么,易用性就会成为缺点。
就这个例子中,我们考虑另外一个问题: 如果被自动删除的图片,在另外文章中被使用呢?

继续优化解决方案,比如『自动删除没有被其它文章引用的图片』。但也有问题,如果临时未用,后续有用的呢?


边界问题,一般是小概率问题。如果接近『不可能』,那么忽略掉边界问题的副作用,也不是不可以的。
而且,有些时候,看似问题已经到达边界,但有可能问题本身就是一个伪命题。伪命题的出现并不奇怪,就像曾经头部的某厂,让盲人在视觉上找到某个为盲人设计的非视觉辅助。
继续以 MarkEditor 为例,一张图片被多篇文章引用 是不是伪命题?其实不是,MarkEditor 有图片管理器这个功能,真正用得好的,通过图片管理器来插入图片,那么很大概率就会出现一图多用的情况。

不会无解

我们要相信,不会无解的。

或者提供多一个选择『移动文章并清空不必要的图片』的操作?
但是也有问题:

  1. 交互操作上明显多了一个逻辑,繁杂而不利落了;
  2. 怎么描述这个命令?对它的描述非常容易让用户产生更大的费解。

我们即使相信不会无解,但有时候,冗余本身就是一个解决方案。对于有重度清洁癖的,使用 Markdown 进行图文写的时候,本身就应该管理好图片;而对于普通用户而言,几张图片的冗余,几乎不造成任何的影响,毕竟磁盘占的尺寸也是非常有限的。
冗余,站在用户层面,就是多出了无用的数据碎片。它是一种解决办法,却只是停留在 it works 的层面。

其实,也有另外一个简单的办法,我们在一个不起眼的地方,提供一个 清空所有未被文章使用的图片 类似的操作,然后找到它们,将其放入到系统的回收站就可以了。
用户很懒很矛盾,不会好好整理文档结构,但总会去整理。表面上是排斥当前操作不必要冗余图片的产生,但本质上是需要一个干净的数据,而且这个数据不是针对单篇文章,而是针对整个目录的。

最后

坐而论道,最容易。

我们要练习获得的能力,是这将近两千字的内容,在一瞬间完成判断。
既要识别到一个意见的问题本身,也看到它存在的合理性,并能找到一个中间地带的平衡。

@2019-12-22 00:09