程序设计删除无效数据（深度解析删除操作设计）
程序设计删除无效数据（深度解析删除操作设计）“移除”重点在“移” 转移其位置，而不会删除。例如收藏的联系人、收藏的歌曲、回收站里的文件等等。“移除”为将内容从某个空间移走，并不会删除。在可删除的内容上，通常用“删除”，例如删除记事、删除文字、删除录音文件。清除的意思是指全部去掉、扫除干净。应用的场景多为清除积雪、清除杂草等清扫性工作。在信息时代，清除多为去除数据、任务、缓存等，其宾语不是普通东西，而是更 “抽象的组合”。在数据和内容的去除上，“清除”与 “删除”更彻底。无法删除的进程、任务上，适合用 “清除”，例如清除缓存、清除通知、清除后台程序。
编辑导语：产品与交互区别之一在于，产品定义功能，交互完善体验。一个功能设计看似简单，实则不然。删除操作作为常见的交互功能，也是人们比较容易忽视的一个功能。本篇内容，作者将带领大家深度解析“删除操作”，大家快来看看吧！
删除操作是最常见也最广泛的一项交互功能，但也是互联网时代人们比较容易忽视的一项功能。本次深度解析系列，会从常见的功能开始分析，稳扎稳打，为体验的提升做出微薄的贡献。
一、明确“删除”的含义明确其含义是体验操作的基础，在见过不少终端和应用混用文字的情况后，我深知基础的重要性。做好文字的表达既是致敬伟大的中华文化，也是弘扬与发展的根基。
删除是指去掉不用的东西，原用于书信、政策等文事中表达。在信息时代，可以是删除短信、删除记录、删除联系人、删除图片等等。它的宾语应该是信息时代的某件“东西”。
1. “删除”与“清除”
清除的意思是指全部去掉、扫除干净。应用的场景多为清除积雪、清除杂草等清扫性工作。在信息时代，清除多为去除数据、任务、缓存等，其宾语不是普通东西，而是更 “抽象的组合”。
在数据和内容的去除上，“清除”与 “删除”更彻底。
无法删除的进程、任务上，适合用 “清除”，例如清除缓存、清除通知、清除后台程序。
在可删除的内容上，通常用“删除”，例如删除记事、删除文字、删除录音文件。
2. “删除”与“移除”
“移除”重点在“移” 转移其位置，而不会删除。例如收藏的联系人、收藏的歌曲、回收站里的文件等等。“移除”为将内容从某个空间移走，并不会删除。
3. “删除”与“取消”
“取消”多用于某个任务、进程等带有正在进行时属性的动作，例如取消订单、取消搜索等。“取消”也经常用于弹框中，与“确定”相反，用于中断某个即将开始的动作。
4. “删除”与“退出”
“退出”是指退离所在的场所。其含义一是主体在某个场所中，二是主体要与该场所断绝联系，三是离开这里。“退出”不会对这个场所的存在造成影响，“删除”则会使这个场所消失。
在信息时代，某个应用、群、组等都会是虚拟的场所。因此退出应用、退出群、退出小组等是指离开这里，而删除群则使群消失。 其中“删除应用”一般不会用到，是因为“应用”是个多重对象，请看第二部分。
二、明确删除的对象删除的对象看起来很简单，实际上学问很多。它的意义在于，设计删除时，我们能将不同属性的对象区分开，设计出更符合自身的流程体验。
1. 是否是独立个体？
删除对象有些是独立的，仅代表自身一方的存在；例如，一张图片、一个联系人、一个订单、一条动态等等，这些都是独立的。
有些是具备多重身份的，该对象是多重内容的组合体。
例如，一个群组，在删除时它既包含群属性，又包含组内成员。一般在其删除时，确认删除框中会说明删除的是哪部分，避免引起歧义。
例如，一个下载中的文件，其既包含下载进程，又包含已下载的那部分文件，因此在做删除设计时，应针对其包含的多重内容做针对化的设计。
例如，“应用”本身是个组合体，包含了很多安装文件、缓存文件，还有个安装过程，“删除”与之对应会比较局限，因此通常会用“卸载”应用，安卓6以后，卸载应用会包含删除文件的过程。
2. 产生来源
明确这一点，对于删除文件的重要性，有一个明确的认识。
第一类，用户意愿产生的，指用户在其中付出心血和努力的内容，例如用户的联系人、录音、帖子、日历、备忘录、图片等等一切都是用户主体为意愿做的。此为第一重要区。
第二类，用户辅助产生的，就是基于用户自身的意愿，非直接产出的内容。例如各类记录：通话记录、订单记录、播放记录、查看记录等。或者与用户生产有很强关联的，例如对方的回复信息。或者是虽为用户自主意愿生成，但是并未付出较多心血，例如新建的闹钟。此为第二重要区。
第三类 应用端或设备端产生的，用户未参与产生。
例如菜鸟裹裹应用是根据用户的订单，获取不同订单的物流信息列表，提供提醒相关的服务。例如应用推送内容、他人的直播等等，此为第三重要区。
三、删除的位置从全局看，区分内外的删除对象，删除的位置应该在文件外部，而非文件内部
关于删除的位置，很多年以前的一次设计故事，一直影响着我。
我在做记事本的应用设计，当时竞品上的删除功能大多放置在记事查看界面，当查看这个记事后，点击删除，这个记事就消失了，返回至列表界面。
这个感受很微妙-“我”这个主体，在这个应用的时空中突然没了根基，双脚离地，然后被安排去了其他地方。
我一直思考后发现，这个删除并没有考虑“我”这个主体的位置和感受，而让用户清晰判断所在位置和行为路径是交互流程中至关重要的。
后来，我也发现很多应用的“删除”这个操作慢慢都转移至列表上，而非文件的内部。
例如，iOS备忘录会把删除放在备忘录的内部，该备忘录删除后，自动显示下一条备忘录，其仍保持着原有的理念。
备注：
- 对于内和外区分不明显的删除对象，可不考虑此条。
- 编辑状态并非其内部，编辑状态时删除是合理的。
删除的相对位置：
对此项众说纷纭，有人说其是高频操作，放在显眼位置；有人说是危险操作，应以避免误触为主。“误触”也是在交互中比较多的词语，我之后会专门写一篇看法。
而删除的位置，我认为应该放置在比较明显的位置。其明显的程度需要取决于用户删除的频率和需求强弱。
例如用户的图库，每天产生大量内容，其删除需求很高，位置必须显眼，操作简单。
例如用户的群组，群是长远内容产出来源，删除需求并不高，可以末位显示，但仍需要显眼。
四、删除的操作
经过若干年的发展和沉淀，删除的操作通常为以下几种：
1. 隐藏式—长按要删除的条目，显示删除选项
安卓系统广泛应用，接受度较高，除设计删除，还可以做其他功能的设计。
2. 隐藏式—向左滑，展开删除选项
苹果手机中广泛应用，左滑显示删除，右滑恢复原有状态。
其优势：
- 不打断用户的操作
- 展开显示删除，相当于确认，点击后删除
- 滑动本身操作效率略高
3. 直接显示在界面中，这种最直观，适合应用在非列表的显示重要内容的位置
由于列表的删除属于一种编辑菜单，是每一个条目均具备的属性。其一，列表经常滑动/点击/长按，列表不适合放置操作按钮，其二，一排的删除按钮，由于其重复性，视觉上显得笨重。
五、删除的流程
删除的流程有几个关键步骤，自行去组合即可。
1. 确认弹框
这是最常见也最广泛的一个步骤，用于确认当前的操作。事实并非所有的操作均需要确认。
根据删除对象的重要程度，我认为第一重要区的对象一般需要确认，第二重要区的对象可不确认，第三重要区的对象无需确认。
以上也并非绝对，例如第一重要区的，用户拍摄的图片，由于其更新频率高且有回收站的情况下，可减少操作不必确认。
例如，菜鸟裹裹为例，左滑列表显示删除，点击删除弹出确认菜单，点击删除后即完成删除操作。
其删除的内容属于第三重要区，通过左滑显示删除的方式，再次弹框提示，过于繁琐。
2. 删除后提供撤销
撤销Toast形式适合于误删或删除后立刻后悔时，可在几秒内选择撤销。这种在安卓原生系统中比较常见。
文件类的应用提供回收站等撤销服务。这两种方案均未得到广泛应用，认知成本和开发成本较高，且并非解决根本问题。
机器永远是做机器即可，不必牵强附会。可以给用户容错的机会，容错是个无底洞，即使容错99次，总有用户犯第100次。因此撤销并不是一个优质需求。
其中在创作类和编辑类软件中，撤销仍是一个关键的功能，这并不冲突，反而是客观辩证的看待问题。
3. 已删除提示
当删除完毕，经常看到会有一些Toast提示“已删除”。“已XXX”这是汇报性性文字。Toast的形式对用户操作的打断相对弹框较弱一些，但是对于用户的高效生活来讲，仍会有一定干扰。
若删除操作和对象均在本界面可见范围内，删除内容界面会进行更新，则无需Toast汇报。
若某些操作和对象在本界面操作，却在其他部分产生影响，则需要Toast汇报。
例如，在微信中下载一张图片，保存的位置会通过Toast显示，这种情况，是将图片存在其他界面的某个文件夹中，告知详情有必要。
六、结语产品与交互区别之一在于，产品定义功能，交互完善体验。一个功能设计看似简单，实则不然。我希望当别人问我们为什么这样设计时，能有理有据。接下来我会把普通的功能，通过深度分析系列，逐一剖析展现，在体验路上能一步一个脚印前行。
本文由 @张宁宁 原创发布于人人都是产品经理。未经许可，禁止转载
题图来自Unsplash，基于CC0协议
