设为首页
收藏本站
用户名
Email
自动登录
找回密码
密码
登录
立即注册
只需一步,快速开始
快捷导航
登录
注册
论坛首页
BBS
建站模版
微站设计
虚拟主机
企业邮箱
博客日志
Blog
搜索
搜索
搜索
热搜
长春
优惠
活动
做网站
本版
帖子
用户
本版
帖子
用户
请
登录
后使用快捷导航
没有帐号?
立即注册
道具
勋章
任务
留言板
设置
我的收藏
退出
时时商务社区
»
论坛首页
›
资讯分享
›
网站推荐
›
如何处理网站上多余、过时、杂项的内容 ...
返回列表
查看:
546
|
回复:
0
如何处理网站上多余、过时、杂项的内容
[复制链接]
xgnic
当前离线
积分
11142
3444
主题
3465
帖子
1万
积分
管理员
积分
11142
发消息
电梯直达
楼主
发表于 2018-2-14 17:44:55
|
只看该作者
|
倒序浏览
|
阅读模式
推荐语:网站上的历史遗留内容弃之可惜食之无味,该怎么办?本篇文章告诉你如何应对。
在网站上发布新内容成本是很高的。你可能会觉得“其实并没有,发布内容要什么成本啊,又不是要打印出来。”从某个角度来说,这么想也对。但其实问题正在于发布内容的成本低廉。正因为成本太低,人们才会不停地发不停地发。
实际上,很多公司因为不考虑成本,所以随便哪个员工都可以没事上去发点东西。这些公司往往会安装一套内容管理系统,然后所有员工都可以上去搞东搞西。甚至是负责控制内容一致性和准确性的人员也会在网站上大书特书。这些人的想法是:大水漫灌,用户总能找到对自己有用的内容。但是长此以往,你迟早会发现这里面所隐含的成本。这些隐含的成本有时甚至能让大型企业叫苦不堪。
内容的隐含成本创造内容固然是有成本的,但是随着时间推移,管理内容所需要的成本比创造内容要高的多。管理内容需要耗费大量资金和时间对内容进行定期审查以保证其准确性和相关性,对于在网上设有大量页面的企业来说,这一点尤其重要。而最后所带来的后果,就是很多公司扛不住,只好放弃。对于非关键的内容,我们往往会在点击完“发布”按钮后就忘了到底发了些什么东西,而这里所隐含的成本却不仅仅是维护成本这么简单了。其还会影响到网站的易用性。如果网站上内容过多,就会妨碍用户找到自己所需的内容。举例来说,微软的网站曾一度拥有过超过1000万个页面,其中有3百多万从来没有用户来看。这些没用的内容除了影响寻找内容的效率进而降低用户满意度之外没有任何用处。
Microsoft.com等大型网站往往会有数以百万计的页面,其中大部分是没用的。
除此之外,还有一个终极的隐含成本:也就是企业对网站更新迭代能力的影响。举例来说,有个公司想把网站改造成响应式网站。理论上我们只需要更新一下CSS,充其量也就是在内容管理系统里更新一下模板,但是如果我们随着时间累计攒下了上百万个页面,事情就没这么简单了。内容的出产方肯定曾经以各种各样的方式对内容进行了各种修饰,因而修改设计将变得难上加难。
很多数字团队就因为这一点放弃了修改网站的想法,并转而求其次:重新设计网站核心板块,不管历史遗留内容。这样一来就会造成用户在适应网站新界面时产生碎片化的体验情形。
那么,我们应该怎样应对这一巨大的难题呢?首先,我们要解决网站上的没用内容
哪些内容属于没用的内容?没用的内容是指多余、过时和杂项的内容。其实,我们网站上的内容有一大部分都属于这个范畴。这些没用的内容对于很多大型网站来说是个很头疼的问题。
欧盟委员会近期对网站进行了一次内容审查。审查结果就是删去了80%没用的网上内容。这一举措一方面改善了用户体验,另一方面也降低了成本。此外,还大大方便了他们对网站进行跟新迭代。
很多公司发布的许多内容其实都属于杂项内容,这些内容主要是为了照顾边缘化的问题,实际上大部分用户都碰不到这些问题。但正是这些内容需要花费大量时间和精力去维护,而且妨碍了重要内容的浏览。
然而,有时候即便是重要内容也会变成没用的内容。因为随着公司的进步,其网上内容也需要跟着进步,可实际上网上内容会停滞不前,直到变成多余。
最后要说的是,我们发布到网站的很多内容都存在有限的生命周期。比如曾经搞过的活动,很多年前的新段子等等,都会影响搜索结果。
这些没用的内容迟早都需要我们去面对,去解决。但是具体应该怎么做呢?
从头开始最好的解决方案,往往是从头开始。对于大型网站来说,哪怕仅仅是把现有内容梳理一遍也会耗去大量时间和资金。其实很多网站团队自己都不知道网站上有哪些内容。所以在这种情况下,最好的办法就是把内容迁移走。不过这就好比给猪画口红一样,解决不了根本问题。
与此相比,很多公司选择从零开始,从头再来。首先,他们会找出用户的首要任务,并围绕这些任务创造内容,进而满足用户需求。这样一来就只需要迁移相关的内容,并在迁移过程中对内容进行重新编译。
英国的Goverment Digital Service在做GOV.UK项目时就采取了这一方法。他们首先将现有政府网站上的内容转换成实际的用户需求,例如“我需要挂失护照。”然后通过一系列标准判定相关需求是否需要解决,如果是,就保留。在这一过程中,他们使用了自己开发的一款名为“Needotron”的应用。
但不幸的是,很多公司的网站团队无法做出如此彻底的改变。因为网站团队不是内容的所有人,因此没有权限做出删除的决定。虽然我个人认为这一情况并不普遍,不过我的个人看法并没有什么卵用。那么不如这样,我们来看看实际中比较可能存在的情形:
删除多余内容首先我们看多余的内容:已经下线的产品或服务;已经结束的活动。这些内容比较好发现,通常可以通过导航、搜索结果和分析技术找到。
这部分内容一般也比较好解决。一般没有人会在乎冗余的内容,所以即便删掉也不会有人找麻烦。此外,这部分内容量也不会太大,所以网站团队应该有能力解决。
不过,过时的内容如何解决就需要技巧了。
解决过时的内容过时的内容不好发现。比如已经不再使用的电话号码、涉及已离职员工的信息、已经结束的活动事件或者有关已下线产品的内容。这些内容往往深深隐藏在网站身处或小版块中。
相比多余的内容,过时内容的量会比较大,网站团队找起来会比较吃力。删除这部分内容需要采取自动化的方式,并需要和内容发布方进行跨部门合作。
这方面有一个办法就是在双方协商好的期限到期后,对新闻、活动进行存档处理。这样可以将内容从搜索和导航结果中删除,但是需要使用的人最终还是能找到。可是到期时限比较模糊的内容该怎么处理呢?
最好的方法就是建立起明确的内容审查制度。这样就可以迫使内容发布方检查内容,确认其是否过期。例如,可以让相关人员每六个月登陆一次内容管理系统检查内容时效性。
如果过期的内容无法删除,则应该至少将其标记为过期。
当然,还必须告诉内容发布方如果不照做需要承担什么后果,否则他们肯定不当回事。在这一过程中,我们需要将不需要的页面从主导航和搜索结果中删除,同时还需要给页面加一个banner告知用户这个内容已经过期。BBC就曾采用过这个技巧。
我们还可以在CMS中使用“上次更新日期”功能来发送邮件通知创建内容的人员登录检查。如果这个人已经离职,也没有其他人负责,那就直接标记为过期。
另外呢,还可以通知内容发布方,告知其内容无法达到预定的流量下限或已超过保留时间。总之方法多的是。不过要注意,一定不能选错指标。流量和保留时间有时候并不适用于所有内容。
杂项的内容怎么办呢?没用的内容中最为难的一部分就是杂项的内容这一块,因为到底什么样算杂项很难让各方达成共识。你觉得边缘化的内容对于另一个人来说可能是关键的业务信息。
要解决这个问题,就需要设定一系列内容价值评估标准。这些标准包括:
1. 分析数据
2. 用户的首要任务
3. 业务目标
首先,要看页面的点击量。如果达不到一定点击量,就应该做出标记,让人重新审查。达不到量并不代表内容就是没用了,只不过是有这个可能性。
下一步,将内容与用户可能需要执行的一系列关键任务进行比较。具体有哪些任务你要首先想清楚。这一点应当是判断内容是否属于杂项内容的首要标准。如果内容和任务不匹配,就说明可能存在问题。
当然,某项任务可能不是对所有用户来说都算关键任务,但对整个公司来说却十分重要。例如,购物网站上只有一小部分用户会执行最后的购买任务,但你能说购买这个任务对公司不重要吗?
所以说,我们一定要问:这项内容是否支持了公司的几个首要业务目标。如果只是支持细微的小业务目标则无所谓。
如果内容没有符合上面说的几个标准,那么就可以判定为杂项内容。不过还不能急着删,对于某些内容,因为法规原因,或者其对于一小撮用户具有非常重要的意义,是不能随意删除的。
对于这类内容,我们在保留的同时,要注意不要让其影响关键内容的浏览。你可以让这些内容只能通过搜索找到,或者将其从主站上删除,因为通过社交媒体、电子邮件或其他通信渠道向用户送达特定页面远比让他们在你的网站上找来找去要容易得多。
困难但重要的挑战对于大型网站来说,处理没用的内容往往让人觉得手足无措,甚至觉得完全做不到。但实际上不是这样。很多时候你只需要有正确的流程就好办了。
我希望大家把从头开始始终当作一个备选方案,不要直接否定。虽然对于很多公司来说从头做一个网站是不可能的,但最后的结果往往不是这样。如果你能做出一个原型让大家看看比之前的网站牛逼很多,他们很可能会同意你的方案。别不好意思!狠狠心免得这些没用的内容吧!
作者: Paul Boag
译者:d-grocer
来源:UI中国
原文地址:http://www.ui.cn/detail/56036.html
分享到:
QQ好友和群
QQ空间
腾讯微博
腾讯朋友
收藏
0
回复
使用道具
举报
返回列表
高级模式
B
Color
Image
Link
Quote
Code
Smilies
您需要登录后才可以回帖
登录
|
立即注册
本版积分规则
发表回复
回帖后跳转到最后一页
用户反馈
客户端