12.1.3 软件服务应该以何种方式记住用户的选择到何种程度？

[GreyZeng]

章节：12.1.3，页码：263
用户使用任何软件来解决问题，软件从头到尾的各个部件要结合起来把用户的问题给解决了。用户在第一步已经告诉系统——我要用英文！负责“发短信”的模块知道这一点么？这样的问题，可以通过“基于场景的设计”来强化成员对用户体验连贯性的理解。

《构建之法》作者在这一部分中强调了“软件服务始终都要记住用户的选择”，但不知各位读者是否遇到过，访问某个网站的特定内容后，访问其它网站时被推荐相关内容，或搜索某类商品后，回到主页被推荐相关商品。在这些情景下软件服务的确记住了用户的选择，但笔者对此感到不适，不惜注销相关账号并避免使用相关软件服务，或编写脚本搜索随机内容来冲淡软件的记忆。

笔者认为，上述情况之所以发生，原因可能在于，这些软件服务的目标群体大多处于位于《构建之法》第374页下方的神奇小学，这样做有利于提升这些用户的体验而不会引起这些用户的不适，且服务端收集到的用户选择可能被用来以某种方式盈利。但无限制的记忆和使用用户的选择真的不违背软件工程师的职业道德吗？

原文地址

[GreyZeng]

学期初，针对软件服务记住用户选择的问题，笔者的观点如下：

• 功能方面：

  • 允许客户端记录未登录用户的选择，这是基本要求。
  • 允许客户端记录已经登录用户的选择，这样记忆可以与用户绑定，在多用户的情况下便于切换和区分。
  • 允许服务端记录已经登录用户的选择，这样可以通过服务端在多客户端同步记忆，也可以避免客户端损坏导致记忆丢失。
  • 对用户选择的记录应该以加密的形式妥善存储，尽可能避免被第三方掌握和破解。

• 用户交互方面：

  • 允许用户关闭或开启任何记录行为，允许用户删除现有的记忆，这些是属于用户的，用户有权支配它们。
  • 告知用户软件将如何使用其选择，允许用户关闭任何使用途径。
  • 上述设置应处于明显、易到达的位置，可提供设置向导帮助用户完成设置。

笔者在软件工程课程中进行了实践，认为上述内容可以进行一些调整和补充，如下：

• 在讨论客户端记录已经登录用户的选择时，未考虑用户退出登录后的处理，用户退出登录后，对于未存储到服务端的部分，可能的处理包括：

  • 保留这部分内容，这种处理多出现在本地客户端，例如(QQ)。
  • 删除这部分内容，这种处理多出现在(Web)应用，在团队项目的前端中，我们主要采用了这种处理。

• 对用户选择的记录是否加密可依据其是否敏感进行区分，无需全部加密：

  • 对于敏感的记录，如剪贴板记录等，应加密存储。
  • 对于无关紧要的记录，例如在团队项目的前端中，是否显示已读通知、优先显示题目页面还是显示提交页面等，并不敏感，明文存储未尝不可。

• 对于(Web)应用，在用户交互方面的要求可以适当弱化：

  • 对于允许用户关闭或开启任何记录行为，允许用户删除现有的记忆，如果采取了退出登录即删除的策略，笔者认为可以适当简化实现这一功能。
  • 对于告知用户软件将如何使用其选择，允许用户关闭任何使用途径，如果采取了纯客户端记录的策略，笔者认为可以适当简化实现这一功能。

原文地址