2天时间,聊今年最热的 Agent、上下文工程、AI 产品创新等话题。2025 年最后一场~ 了解详情
写点什么

争论:为什么大多数社交软件会失败,又该如何避免

  • 2008-08-25
  • 本文字数:1655 字

    阅读完需:约 5 分钟

为什么一些社交站点取得了巨大的成功,而另外一些则招揽不到用户呢?Clay Shirky 在 Buzzwatch 的采访中表示,应注意这样一个事实——即在大多数情况下,“推出最少特性的软件往往大受欢迎”。顺应着同样的路线,比如几个作者主张Web 的简单性,Clay Shirky 认为社交软件成功的关键是“所有用户都共享的简单心智模型” 。

Michael Nielsen 称其为 Shirky 规律,他在博客中分析了为什么程序员总是违背这一规律。对于构建成功的社交软件需要提防的陷阱来说,他的论点及后续的讨论都提供了很有趣的见解。

首先 Nielsen 认为,程序员不能创建与共享用户模型相匹配的软件,是因为他们作出决定的依据——内隐的心智模型——往往是有缺陷的。他们日常的软件经验是一个两部分组成的、以软件和用户之间的交互为基础的系统,该系统能提供提升用户体验的更多能力。但这并没有考虑到用户和其他用户之间的交互这一重要问题,还有这一问题会对用户和软件之间的交互有怎样的影响:

真正的用户心智模型是大相径庭的。就是软件和其他用户的完整关系网。他们如何使用软件完全取决于其他用户如何使用的他们的心智模型。如果他们对心智模型缺乏信心,他们本身就会缺乏使用软件的动力 [……]。软件越社会化,这种效果越明显。

[……]

很容易就会陷入去做那些让单一用户的体验更好的事情,但这却会让用户关系网的体验更差。

简单是 Shirky 规律的另一个关键词。为了让大量用户共享,潜在的用户模型确实要够简单。据 Michael Nielsen 所说,事情往往并非如此的原因有两个。首先,程序员往往趋向于去做技术上让人印象深刻的事情,然而最成功的社交软件却是“将一个任务做到极致 ”。不过找到这样一个任务是非常困难的。它应该是有用、创新、并且简单的任务,应该是“不能减少、或不能用现有任务解释”的任务。发现这么一项任务更多的是一种社会性挑战,而不是技术性挑战,这正好解释了为什么很多成功的应用都是由来自于非纯粹技术背景的人创建的,要不然就是被“意外地”创造。举例来说,博客是项目管理系统中的一部分,Flickr 就出自于一个玩家可以分享照片的在线游戏的该项目,而第一个 Wiki 创建的原因是 Ward Cunningham“厌倦了对用户的请求做出响应,来更新他运营的网站”。

Michael Nielsen 强调道,简单的心智模型并不一定意味着技术上简单的软件。一些社交软件使用非常复杂的算法,比如 Gigg 或 FriendFeed 上那些用于排列提交条目重要性的算法,但这一技术复杂性应该对用户隐藏。

但是一些评论家认为,在用户模型级别以简单性为目标也有局限性。比如 Chris Granade 和 Pedro Beltrao 就警告试图运用 Shirky 规律导致的过度简单性。在 Chris Granade 看来,这可能会导致“妨碍共享理解的灵活性的欠缺”。举例来说,他指出,“将人添加为“好友”往往极不准确”,还可能会导致朋友网络的混乱和矛盾的元数据。轮到 Pedo Beltrao 时,他提到了另一个可能的混乱来源。在现实生活中,人们与不同的人分享时往往有不同的侧面,而在 FriendFeed 之类的朋友网络上,是不可能选择一个人的某一侧面的。因此,所有的侧面都会由差异巨大的人共享,而且“这可能会随着时间的流逝而增加无用数据”。

Michael Nielsen 认为,假如用户已经非常熟悉应用,并“对他们的共享理解非常有信心”,在心智模型级别引入更多的复杂性是行得通的。因此,这只能在软件存在的后期用 Facebook 进行的方式来完成,在它已经具备一定影响力之后再逐步增加复杂性。

尽管这需要一个相当细致的方式,但简单似乎是社交应用成功的一个关键因素。Nielsen 在对一条评论进行回复时,强调遵守 Shirky 规律的简单思想对构建成功应用来说是必要的,但并不是充分的。人们能有伟大的构想,但仍然不能施行。除了考虑大量纯技术和纯商务的问题之外,人们还应该持续确认软件和用户模型之间的匹配自始至终都保持着发展进程,而不要因开发人员对用户模型认知中可能的缺陷而停止。这就是为什么 Michael Nielsen 断定尽早增多测试用户,以及尽早、频繁发布的重要性。

查看英文原文: Opinions: Why Most Social Software Fail and how to Avoid it

2008-08-25 04:291896
用户头像

发布了 151 篇内容, 共 69.1 次阅读, 收获喜欢 18 次。

关注

评论

发布
暂无评论
发现更多内容

面向快速反应的工程团队--QRF团队模型

俞凡

管理 研发效能

DDD实战(9):冲刺1战术之服务设计(上)

深清秋

DDD 软件架构 生鲜电商系统

linux之登录式shell和非登录式shell

入门小站

Linux

[Day32-02]-[二叉树]在二叉树中增加一行

方勇(gopher)

LeetCode 二叉树 数据结构和算法

深度学习之解构卷积

AIWeker

人工智能 深度学习 卷积 convolution

关于“运放“这些知识点

謓泽

5月月更

前端食堂技术周刊第 35 期:Vitest v0.10.0、Jest 28、Ant Design v4.20.0、Lerna 官宣停止维护、UnoCSS 交互式

童欧巴

JavaScript web前端 前端工程师

maven构建docker镜像三部曲之一:准备环境

程序员欣宸

Java Docker 5月月更

[Day32-03]-[二叉树]不同的二叉搜索树

方勇(gopher)

LeetCode 二叉树 动态规划 数据结构和算法 卡特兰数

深度学习之解构基础网络结构

AIWeker

人工智能 深度学习 基础网络

一、何为应用系统高可用

穿过生命散发芬芳

5月月更

软件架构的23个基本原则

俞凡

架构

M4: 设计千万级学生管理系统的考试试卷存储方案

Jadedev

架构实战营

Hadoop全分布式部署

芝士味的椒盐

Java 大数据 hadoop 5月月更

Kubernetes 如何将 Pod 分配给节点

玄月九

Kubernetes 污点 亲和 反亲和 容忍

千万级学生管理系统的考试试卷存储方案

鱼恨水

nginx配置系列(四)请求限制

乌龟哥哥

5月月更

运营好公众号需要具备的能力/技能

源字节1号

软件开发

[Day32-04]-[二叉树]二叉树的最近公共祖先

方勇(gopher)

LeetCode 二叉树 数据结构和算法

使用PIL.Image库极简生成含冬奥会元素头像

芝士味的椒盐

Python 冬奥会 5月月更

Kotlin 中的泛型:协变与逆变

如浴春风

5月月更

这个页面效果看起来真恶心,怎么解?

石云升

团队管理 项目管理 职场经验 5月月更

模块四作业(试卷存储设计)

天琪实刚亮

千万级学生管理系统的考试试卷存储方案

CityAnimal

架构实战营 #架构实战营 架构师实战营 「架构实战营」

[Day32-05]-[BST] BST最近公共祖先

方勇(gopher)

LeetCode 二叉树 数据结构和算法

2022必会的前端手写面试题

buchila11

前端面试

在线Excel转XML工具

入门小站

工具

设计千万级学生管理系统的考试试卷存储方案

唐诗宋词

这是一篇关于哈希表的爽文

武师叔

5月月更

【愚公系列】2022 年 05月 二十三种设计模式(一)-工厂方法模式(Factory Method Pattern)

愚公搬代码

5月月更

今天是第几周

入门小站

工具

争论:为什么大多数社交软件会失败,又该如何避免_架构_Sadek Drobi_InfoQ精选文章