基于标签云的SNS服务设计探讨

上传人:平*** 文档编号:18410752 上传时间:2017-11-14 格式:DOC 页数:11 大小:487.10KB
返回 下载 相关 举报
基于标签云的SNS服务设计探讨_第1页
第1页 / 共11页
基于标签云的SNS服务设计探讨_第2页
第2页 / 共11页
基于标签云的SNS服务设计探讨_第3页
第3页 / 共11页
基于标签云的SNS服务设计探讨_第4页
第4页 / 共11页
基于标签云的SNS服务设计探讨_第5页
第5页 / 共11页
点击查看更多>>
资源描述

《基于标签云的SNS服务设计探讨》由会员分享,可在线阅读,更多相关《基于标签云的SNS服务设计探讨(11页珍藏版)》请在金锄头文库上搜索。

1、基于标签云的 SNS 服务设计探讨在深入讨论之前,我们需要弄清楚一个问题,“我们为什么需要标签云?”之前的 web 时代的搜索普遍采用的是全文搜索模式,搜索的效率不高,同时,对于未出现在文章正文中的搜索词则不会返回任何的搜索结果。标签的出现,使得用户可以对信息元进行多层次的标识,或者说,对信息分类(Classification),从而使得用户可以从多个层次或视图对庞大的信息库进行浏览,如果再结合标签的搜索,则会将搜索的精准程度提高不少。另一方面,在目前多媒体数据的搜索尚处于起步阶段的大背景下,通过文字标签来标识多媒体数据,成为有效搜索/展示多媒体数据的折衷的解决方案。好了,我们有了标签云,是否

2、就可以一劳永逸了解决海量信息的呈现问题了呢?答案是否定的,当用户和共享的信息呈现几何级数的爆发式增长时,标签的数量将成为新的裸信息元,在缺乏一定的组织结构的情况下,海量的标签(标签云结构)对于用户快速获取信息将是灾难性的。所以注入花瓣网这样的直接将标签化的底层信息元不加任何组织地向客户展示出来将降低用户有效获与其意图相匹配信息的难度。从前两篇 log 的分析可以看出,目前通用的解决方案就一个:通过一个大目录对标签进行归类整理(麦库、堆糖、topitme、好看簿、v2ex 等都采用了这种方式)。这个大目录,实际上是一个组织整个社区标签云的视图。这个视图的设计与社区的定位、用户群设定、用户使用场景

3、导向是高度相关的。一个采用了标签云底层架构支持的互联网服务,必须考虑好如何将标签融入既有的服务流程体系,以一个或多个灵活而方便的视图,让用户在服务流程中,在合适的环节快速寻找到合适的信息,是服务设计的关键。通过对典型标签云 SNS 服务的研究,我们提取出了一个共性的设计框架,这给我们未来的教辅服务的设计及扩展提供了很好的理论支持。下面,我们首先提出设计的整体框架,然后将 topitme 及堆糖两个典型的标签云 SNS 网站的设计套到该框架中,最后,我们试图探讨一下传统论坛/空间与 SNS 分享之间的异同及设计取向问题 。(一)标签云 SNS 功能设计框架1、基本框架介绍(1)元信息管理模块(M

4、iMM,Meta-information Management Module)元信息(Meta-information)就是社区共享及用户操作的信息的片段单元。比如,topitme、堆糖和花瓣社区中的元信息就是图片,Qing 博客中的元信息就是包含了图片/文字的信息片段。MiMM 的主要作用有两个:元信息存储及元信息标签分类:元信息存储。功能简介:顾名思义,将整个社区产生的元信息存储下来。技术门槛:为了避免用户交互分布于同一份数据的多个副本上,也为了提高存储的效率,MiMM 往往需要对元数据进行签名索引,以有效去除冗余副本(比如,不同用户上传的相同的图片)。这一功能对于基于图片的 SNS 社区

5、尤为重要。如果用户发现其关注的的用户发的内容很多都是相同的,无疑会严重影响用户感知。如果由后台人员手工进行合并去重的话,海量的数据必然带来繁重的工作量,必然加大社区的运营成本。元信息标签分类。功能简介:在系统实现对于元信息的有效理解(比如直接识别图像的内容)之前,运用标签来对元信息进行分类,从而辅助信息的获取,成为 SNS 领域的一大主流方向,从而诞生了标签云的 SNS 服务。目前主流标签云 SNS 社区的 MiMM 通常采用二级的标签体系。第一级标签(底层标签)直接标识元信息,由用户自行设定和编辑;第二级标签则对第一级标签的分类标识,由社区设计者按照社区的定位、用户群设定、主功能设定等因素进

6、行预先设定,或只能由社区设计者进行更新。为了给用户一个清晰的浏览界面,通常第二级标签被固化成为这些社区首页的导航栏。技术门槛:一级标签与二级标签的关联工作量浩大,只能通过机器自动文本分类、强制用户指定及运营人员手工添加实现。机器自动分类方式需要引入 AI 领域的文本分类算法,技术门槛高,一旦实现,可以大幅降低运营成本;强制用户指定方式则是指用户每创建一个一级标签,就要强制用户指定其标签归类,此方式用户门槛很高,并未被主流服务商采用;运营人员手工添加方式必然导致运营成本高企,而且随着社区用户的增多,工作量会呈几何级数增加。(2)用户管理模块(UMM,User Management Module)

7、UMM 管理用户的档案信息(包括各种特征信息、更新历史等)以及用户级别控制。其中,简单的社区一般只包含前者,若社区需要建立用户身份级别体系,则 UMM 需要管理每一个用户身份级别对应的权限。(3)事件管理模块(EMM,Event Management Module)由于社区的共享实际上都是事件信息的共享,因此 EMM 是整个社区的核心模块。所谓事件,一般包括【用户】【操作类型】【操作对象】三个因素,随着社区功能的扩张,会加入一些“状语”元素,如【时间】(如时间线应用)、【地点】(如社区工具类/游戏类的应用)。 (4)功能视图管理模块(VMM,View Management Module) EM

8、M 模块管理下,形成了一张事件的完整数据表(在附加状语出现的情况下,不一定是一张表,有可能通过别的数据表来表达状语信息并与主事件表进行逻辑关联,以达到社区功能的可扩展性)。筛选该表的某几个元素,即可形成对应的筛选数据视图。举几个例子:在【用户】筛选“用户 A”,【操作类型】筛选“关注好友”后,即可得到 A 用户所有关注的用户列表;在【操作类型】筛选“关注好友”,【操作对象】筛选“用户 A”,即可得到所有关注 A 用户的用户列表;在【操作类型】筛选“做错”,则可得到社区内所有用户做错的题目的列表;VMM 模块是社区设计者综合考虑用户场景、核心用户卖点等因素,选择向用户进行展示的视图组合的管理者。

9、VMM 决定了在整个社区系统的什么板块,配置什么视图,所以是整个系统的用户交互中心。(5)社区交互管理模块(SiMM,SNS-interaction Management Module)SiMM 设定了用户交互的 SNS 规则,比如:微博式的单向关注+群发类的交互规则;交互认证成为好友后,才能接收到好友的各项事件。一般来说,规则可以分为鉴权规则和信息流规则。鉴权规则规定了好友关系的形成规则,而信息流规则则规定了信息流动的方向和权限。上述五个功能模块的角色分工如下:信息生产者:元信息管理模块、用户管理模块、事件管理模块;信息传播者:社区交互管理模块;信息展示者:功能视图管理模块;2、社区功能扩展

10、设计在上述框架当中,社区的功能扩展主要体现在事件类型的扩充以及视图的扩充两个方面。前者实质上就是扩充了系统中事件描述的元素,进而提供了更多的事件数据表的筛选条件,从而形成了更多的视图。可以看到,在这个框架下,社区是具备高度的可扩展性的。(二)典型标签云 SNS 应用功能分析1、Topit.me 功能设计分析 元信息管理模块设计:元信息设计:图片、图片的集合(专辑)、小组;标签体系设计:图片标签及专辑标签均为一级标签;小组栏目标签为二级标签,且一般用户建立小组都无法进入二级标签。所以,严格意义上说,在公共 SNS 服务层面上,Topitme 网站是一个单级标签体系的设计(如果考虑照片和专辑相互独

11、立的标签体系,应该说这个网站是双单级标签体系);用户管理模块设计:用户信息仅包含用户头像、帐号密码等信息,非常简单。暂时未加入用户层级体系。事件管理模块设计:事件设计:【事件类型编号】【用户】【操作类型】 【操作对象】 【附属对象】【事件类型 1】 【用户】【收录】 【图片】 无【事件类型 2】 【用户】【收录】 【专辑】 无【事件类型 3】 【用户】【收录】 【用户】 无【事件类型 4】 【用户】【收录】 【小组】 无【事件类型 5】 【用户】【打标签】 【图片】 【标签】功能视图管理模块设计:默认首页视图:事件类型 1,筛选【收录】元素;用户收录图片视图:事件类型 1,筛选【用户】【收录】

12、两个元素;用户收录专辑视图:事件类型 2,筛选【用户】【收录】元素; 用户收录小组视图:事件类型 4,筛选【用户】【收录】元素;用户关注视图:事件类型 3,筛选【用户】【收录】元素;用户标签视图:事件类型 5,筛选【用户】元素;社区交互管理模块设计:鉴权规则:用户可不经鉴权单向关注另一用户(与微博相同);信息流规则 1:用户关注的其他用户的收录行为,不会 push 到本用户面板;信息流规则 2:用户可以向其关注的用户发私信,不能向其未关注的用户发私信;信息流规则 3:其他用户对于用户收录的图片的评论,会 push 到本用户的“动态”消息面板;2、堆糖功能设计分析元信息管理模块设计:元信息设计:

13、图片、图片专辑、小组(与 topitme 如出一辙);标签体系设计:图片标签及专辑的双单击标签体系作为一级标签;网站在“分类浏览”设定固定二级标签如下:用户管理模块设计:与 topitme 一样,用户信息仅包含用户头像、帐号密码等信息,非常简单。暂时未加入用户层级体系。事件管理模块设计:事件设计:【事件类型编号】【用户】【操作类型】 【操作对象】 【附属对象】【事件类型 1】 【用户】【收集】 【图片】 无【事件类型 2】 【用户】【喜欢】 【专辑】 无【事件类型 3】 【用户】【关注】 【用户】 无【事件类型 4】 【用户】【加入】 【小组】 无【事件类型 5】 【用户】【打标签】 【图片】

14、 【标签】【事件类型 6】 【用户】【创建】 【专辑】 无【事件类型 7】 【用户】【发布】 【图片】 【专辑】功能视图管理模块设计(主要视图):默认首页“发现”视图:事件类型 1,筛选【收集】元素; “TA/我的专辑”视图:事件类型 6,筛选【用户】【创建】两个元素;“TA/我喜欢的专辑”视图:事件类型 2,筛选【用户】【喜欢】元素;“TA/我的收集”视图:事件类型 1,筛选【用户】【收录】元素; “TA/我的发布”视图:事件类型 7,筛选【用户】【发布】元素;用户的“关注动态”视图:事件类型 3,筛选【用户】【关注】元素,联合查询相关视图用户的“小组动态”视图:事件类型 4,筛选【用户】【

15、加入】元素,联合查询相关视图;社区交互管理模块设计:与 topitme 类似;(三)社交类产品与传统空间类产品的差异探讨传统的空间类产品(代表产品如 QQ 空间),突出的是熟人网络之间的私有信息交互。其具备如下的特点:1)用户的发言往往对其好友(熟人)来说更有意义。毕竟,在你的页面看到一个完全陌生的人说,“我今天早上去了百佳购物,好爽”这样的留言,除非你是搭讪控,估计你不会对这种留言太有兴趣;但如果此人恰好是你的同事,你说不定很有兴趣来一句,“贱人,居然背着老板偷溜去百佳”,随后就有可能引起一堆同事乃至同学的讨论。可以看到,整个沟通的走向完全围绕熟人关系脉络进行,而对于外人来说,这种话茬与无关痛痒的唠叨无异;2)整个社区并无内容导向,是一个通用性的话题社区。在这种社区里面,讨论什么都可以,上到国家大事,下到鸡毛蒜皮,只要能引起大家兴趣的东西,在不违背国家法律的前提下,尽可大书特书,无限延伸;3)依托强势的人脉工具而诞生。要具备前两个特点,必须有一个汇聚熟人网络的

展开阅读全文
相关资源
相关搜索

当前位置:首页 > 行业资料 > 其它行业文档

电脑版 |金锄头文库版权所有
经营许可证:蜀ICP备13022795号 | 川公网安备 51140202000112号