Tag Archives: Web

Web 表单设计以及其它

填写表格是很多人都厌烦的事情,即使填写网络上的表格(表单)也是如此,而设计表单则可能是网络工程师/设计师最烦最无法拿捏的事情。绝大多数用户和一个网站交互的第一步就是面对表单(比如登录或是注册),很可能也是最重要的一步交互。遗憾的是,现在很多中小网站对于表单的设计仍然比较糟糕,或者是不够重视,甚至那些大型网站的表单设计也并没好到什么地方去。

Web_Forms_Design.jpg

中小网站的工程师(可能同时也是设计人员)在日常工作中无法回避表单,与其反复翻看别人的设计,东拼西凑成自己的表单,还不如彻底研究一下表单,所谓磨刀不误砍柴工,要提高提高效率,这是个不错的途径。关于表单的中文图书并不多,目前专门讲表单的只有两本。抽时间看完了《Web 表单设计:创建高可用性的网页表单》这本书之后,才发现表单设计在冰山下还有很多东西(抽时间要把另一本也看一下)。尤其优良设计的表单对于数据分析人员来说也是紧密相关的,毕竟面对要清洗的脏数据是很让人苦恼的事情。

有多少技术人每个月能保证看一本技术类的书籍呢?那些身处大型团队的朋友常说没有资源,我知道没资源的原因要么是拉不到资源,要么是资源在浪费中;中小型团队团队资源也紧缺 — 因为人少,也有资源上的浪费 — 因为重复做低效的事情。身在中小型团队,指望外力扭转现状是不太现实的,所以自身学习与提升不能放弃。

上一周在 QCon (北京)会场和朋友聊天的时候我开玩笑说,”QCon 的确有技术含量,但很多高端的东西现在还用不上,应该组织一场只面向中小网站的技术会议,规模稍微大点公司的人不许来。” 这句话其实也是有感而发,很多中小网站面对的问题其实很多都有共性,完全可以共享一些常用技术,共同进步。如果真的组织这样的会议,希望有朋友来分享一下表单设计。哪位愿意?

EOF

一个多月没写东西了,扯个闲篇再说。

此文作者:, 位于 Review 分类 标签: , , on .
转载须以超链接形式标明文章原始出处和作者信息及版权声明.

Web Analytics 方法

Web Analytics 的几种方法中,分析 Web 服务器日志(Logfile Analysis) 与页面标记方法(Page Tagging/JavaScript Tagging, 也有称之为”打点”)相对更常见一些。今天发现一个关于二者的对比表格,感觉还是挺有帮助的,粗翻了一下,留作参考。

Web Analysis Compare.png
(点击可看大图)

Page Tagging 的方式对业务控制(比如特定业务预警)更为灵活一些。其他的方法比如 Web Beacons(Web Bug) 的方法在 Web 1.0 的时候还是挺普遍的,对付当前的各种新型 Web 应用已经无能为力。

在设计 Web 应用的初期架构师就应该考虑 Web 分析的方法接口,就像在程序中预置性能调试接口那样,早点考虑,会少许多麻烦。

关于 Web Analytics,仍然存在许多误解与误用。冷暖自知吧。

EOF

精通 Web Analytics

Web Analytics  An Hour a Day没看这本书之前我以为我懂 Web 分析,看了之后才发现之前其实并不明白。

算起来,用 AWstats 做了几年的小实验,尽管一些基本的东西是有所了解,但如果要详细说明背后的含义,还是并不清晰。这可能不是我一个人的感受吧? 我遇到过一些做 Web 分析的同仁,整天看网站数据报表,也看不出什么东西来。尽管我们常看到 Web 分析工具的更新,但国内互联网的 Web 分析思路似乎并没有”与时俱进”。 不管承认与否,毕竟是现实一种。

普及这本书,我想能有效避免 Web 分析中的一些误区,以 PageView 为核心的 Web 分析时代应该已经过去。结合自己的实际业务,通过数据去了解客户,真正做点能起到”正反馈”的事儿,而不是到了节假日弄一些无聊活动疯狂弹出一些用户烦透的垃圾页面。这对你们公司也是莫大的损失。

负责网站数据分析的主管啊经理啊总监啊都把这本书偷着买回去仔细读两遍,然后整点靠谱的针对 Web 的 KPI 出来,也让下面的员工心里服气你还算个合格的管理者。把这本书当作了解 Web 的另一面镜子(如果是从传统行业过来的话),通过另一个角度(数据)观察 Web。

此书翻译质量一般…但我想不影响阅读。

Web Analytics,An Hour a Day ,不需那么多,只要一点点。

EOF

作者 Avinash Kaushik ,感兴趣的话还可以观看他的相关采访视频。更多信息访问豆瓣上的 精通Web Analytics页面,如果买书直接点击豆瓣上的链接去买吧,也算支持豆瓣了 :)

又及:这本书也被我列入豆列 Web 2.0 网站架构不可或缺的图书

网站运维之道 之自动化管理

还是继续这个网站运维的话题吧。前面谈了知识管理与积累,这次谈一下运维过程中的自动化管理。

在进行这篇的扯淡之前,让我想起了《太平广记》里的一个《 板桥三娘子》的故事,姓赵的客商窥探到客栈老板娘三娘子在小箱子中取出小孩玩具大小的木头牛,木头人,喷口水,木头人、牛开始犁地耕作,撒一粒荞麦种子,木头小人种下,不一会儿,荞麦长成开花结实,木头人收割,乃至磨成面粉。然后三娘子把木头牛、人收入箱中,用得来的面粉做了数张面饼。多么好的一个自动化场景呀。

自动化的目的

自动化管理是网站规模化之后必须要面对的问题。为什么要自动化?肯定不是为了炫技,针对一个发展中的网站来说,自动化的主要目的还是为了节省维护成本,提升运维成熟度能力。另外一个经常被忽略的收益是能让运维工作更有趣味性一些,不那么无聊,不无聊的有益副作用是减少人为出错的可能。

自动化针对的范围大致可以分为安装自动化、部署自动化、软件发布自动化、升级自动化、监控自动化等几个方面。优化自动化? 别,这个稍微”高级”并且不靠谱了一点。

自动化要解决的问题是 N 次循环的过程,如果 N 不具备延续性,那么自动化未必有必要。比如某个过程可能只是短时间内需要临时进行几次,是否有必要将其自动化就有待于商榷。如果计划和开发自动化过程的成本高于非自动化成本就没必要了。

开发自动化过程

如果看过古龙的小说,他曾经描述过几个有趣的懒人,懒人造了一些木头人和机关来帮自己干一些不愿意做的事情。自动化多少就是”懒人”要做的事情,因为懒嘛,所以才会想办法节省时间和其他成本。一般来说,这个过程的开发者也是使用者,所以没必要一定要按照所谓的项目过程去走,但是开发者必须能够产出一份文档给同团队的伙伴(如果有的话)。

考虑到多数的网站运维可能都是在 Unix like 环境中的,而 Unix 的哲学思想之一就是”Write programs that do one thing and do it well”,每个过程只做一件事情就很关键,”功能单一的自动化模块”是有必要的,把不同的模块拼装起来再去完成更复杂的需求。

Unix 相比 Windows 来说,天生具备可自动化能力。如 Shell/BASH(自动化日常操作)、CronTab(自动化任务调度) 、Expect (自动化交互场景) 、rsync(数据远程同步)等 啊都是一些需要注意的技术内容。

优化自动化过程

自动化过程一般要有个生命周期,定期升级、优化也是有必要的。面对不同的应用场景应该逐渐改进自动化的可用性。

示例:自动部署 Linux

对于批量的 Linux 安装,RedHat 提供有 Kickstart Installations 自动安装解决方案,不过该方案相对比较繁琐,前不久推出的 Cobbler 是让人眼前一亮的好工具(参见 hutuworm 的介绍文章)。我一直怀疑 Cobbler 是中国人命名的项目,因为 PXE 发音为”pixie”(皮鞋),而 Cobbler 的中文意思是”补鞋匠”。

OS 安装完毕之后的软件安装、更新是个麻烦事。在一个 Linux 的环境中,SA 一定不要为软件相互依赖性浪费太多的时间。什么 YUMAPTYAST 啊,能用就用上。别太迷信自己编译软件所能带来的优化收益,实际上犯错的几率更大。达到某个规模后,本地建立、维护一个软件资料库(repositories)也是有必要的。

Linux 软件安装进化之路:

手工预编译-->RPM-->APT 等工具

已经进化到更好的阶段了,没必要还走着老路在原地折腾。

其他参考:Flickr 运维曾经采用 System Image 来自动化 Linux 相关的的运维工作。或许也可以尝试一下。

在系统配置管理(别混淆到另一个配置管理上去)方面,其实 cfengine 就挺好用的。更多类似工具参考这个比较列表

标准化,减少后续维护成本是节省人力资源的一大法门。

自动化的一些风险

必须要承认的是,自动化有的时候是容易带来一些风险的,比如”冲掉”原有配置文件信息,不恰当的自动化脚本给系统带来额外负载等,在运维过程中需要不断总结经验。(又落入俗套)

这方面值得推荐的一本书是《UNIX和Linux自动化管理》,借鉴一下其中的思路和方法。

对了,补充一下前面的《板桥三娘子》的故事发展,三娘子的面饼如果被客人吃下,则会变成驴…… 同样,自动化有的时候会把人陷进去的,运维人不要变成自动化的奴隶。

这个话题还需要继续下去么? 我再想想 …