Chesanqi's Web World

我理解的用户体验

chesanqi — Sat, 07 Jan 2012 20:53:21 +0800

对一些产品同学来说，用户体验这大帽子是修改一切的板砖。而他们所理解的用户体验70%又都是关于视觉优化的，还有30%是所谓的使用便捷。产品性能和安全从来不在他们理解的范围内。

所谓使用便捷。一个界面上有多个流向另一界面的入口，这是方便的设计吗？

信息是一切，其他都是载体，根本需求是获取信息。市场竞争唯信息不破，只是获取信息的手段在不断进化。

用户体验要服务于信息传达，有些产品体验没那么好，但信息传达准确到位，这就是好产品，跑不了。

选对象是要长的靓还是有内涵？长的靓是生理需求，虽然也要认同但有内涵的才能长久。做产品不是做一次性活动，而是要长久打造一种品牌。

信息的准确传达是个匹配度的问题。一个习惯追新闻的人，你推送给他一个全面的深入的几千字的纸媒信息，即使用户体验再好，你也留不住他。他需要的是一个最快的最标题党的140字微博信息。

CSS3 选择器

chesanqi — Wed, 14 Dec 2011 23:26:10 +0800

以前对 CSS3 选择器理解的不准确。比如 :first-child 伪类。如果有这么一个代码片段：

<div>
    <h1></h1>
    <h2></h2>
    <h2></h2>
</div>

给出一个组合选择器

1	div h2:first-child{}

能不能匹配到第一个 h2 呢？
答案是不能。因为 h2 不是 div 元素的第一个子元素。这个伪类选择器只适用于 h2 是第一个子元素的情况，如果 h2 不是第一个子元素，它什么都匹配不到。W3C 官网是这么介绍的：

The :first-child pseudo-class represents an element that is the first child of some other element.

并且明确的给出了两个例子：

This selector can represent the p inside the div of the following fragment:
1
2
3
4
<p> The last P before the note.</p>
<div class="note">
   <p> The first P inside the note.</p>
</div>
but cannot represent the second p in the following fragment:
1
2
3
4
5
<p> The last P before the note.</p>
<div class="note">
   <h2> Note </h2>
   <p> The first P inside the note.</p>
</div>

去 W3C 官网查看例子

那么，如果想实现匹配不是第一子元素的一组 h2 中的第一个，应该用那个选择器呢？
要用 :first-of-type 伪类。
W3C 官网给出的介绍：

The :first-of-type pseudo-class represents an element that is the first sibling of its type in the list of children of its parent element.

去 W3C 官网查看例子

因为
:first-child 和 :last-child 是 :nth-child() 的特例。
:first-of-type 和 :last-of-type 是 :nth-of-type() 的特例。
所以这几个伪类的用法是一样的。

在IE中用CSS3选择器

chesanqi — Mon, 07 Nov 2011 21:48:42 +0800

如果能在IE中实现一些高级的CSS技术，比如CSS3选择器、CSS3多背景、CSS3阴影等。或许就能更好的学习新技术，而不会总感觉那么遥远，总感觉新技术用不上。

写了一个JS。页面中只需引入这个JS，一些高级的CSS技术在IE中同样有效。实现起来很简单，比如选择器（现在只写了选择器 = =），通过JS找到一些高级选择器特有符号（如[] + ~ > *= ^=），把这些样式变成某个类的样式，把这个类名添加到相应的元素标签上。利用 jQuery 找到IE中相应的元素标签。

我找了下网上实现相同功能的办法，都需要一些配置，或者必须得在服务器环境下开发才行。我不是资深的工程师，不想那么麻烦，尽量做到跟平时写静态文件一样。也许这样看起来安全上没那么严谨。同时还有一些问题没解决，比如一些伪类没想好怎么处理。

看一下 demo 吧，共同解决。
点这里是 github 项目地址。

“Stay hungry. Stay foolish”最好的汉语翻译

chesanqi — Sun, 09 Oct 2011 23:39:31 +0800

有人知乎问：
“Stay hungry. Stay foolish” 最好的汉语翻译是什么？

我在知乎答：
不是翻译，只是说下我的理解。

有些当初看着幼稚可笑的事情，如果坚持下来，做成了一组一系列或者说成套的，这事情就变的不那么可笑，他就变成了一种风格、一种特色。有种从量变到质变的哲学意味在里面。比如说英国17岁少年手绘的《世界简史》，绝对称不上有多少画画技法在里面，单张画面不过是寥寥草草，任谁都能画着玩，但如果你能画几百张，那就是一个好故事。同样，朱德庸的漫画如果只有一张，我会觉得滑稽可爱，一个成年人的不务正业，但他有一套而且可以用单幅画面串联出有深度的故事，并且形成了自己的风格。

偶尔做一件傻事一定是犯了愚蠢，坚持做傻事有可能成为风格。现在已经没有必要讨论左小祖咒唱歌到底在不在调上，靠走音而红的还有还有华裔歌手孔庆祥。如果那些犯傻的事情，被我们凭借兴趣坚持下来……历史上每次伟大变革都是愚蠢的某些人坚持的结果。乔布斯的每个作品也都被认为是不可能完成的作品，是傻瓜天真的想法，但他每次都能做成，关键就在于“追随我心”在于“Stay foolish”吧。

永不满足，永做自己。

用不用jQuery库

chesanqi — Thu, 22 Sep 2011 15:21:06 +0800

我也一直在想这个问题：用不用JQ库？

有人说用了之后会让人变笨，写的再好不了解具体的东西其实还是不会…什么什么的。

这几天有些碎碎的想法：
1、各种库层出不穷的出来是帮助人解决问题的。
2、要深刻学习机器语言，不要用什么汇编语言、高级语言，那会让你搞不清计算机具体是怎么工作。现在还有抱这种想法的人吗？
3、能把jQuery整好的人，基础的JavaSrcipt不可能太差。这不是两种割裂的语言。（相反，精通JavaSrcipt的人，有可能对jQuery一窍不通，但要学起来会相当快，甚至不能说那是“学”，只是了解一下相应的套路即可。）
4、我们的工作是解决问题，不是研究基础语言的。需要用JavaSrcipt的项目，不介意具体用什么办法，用JavaSrcipt可以，用jQuery也可以只要能解决问题。（jQuery是开源的不会带来技术之外的其他问题）
5、由第4点说来，有些项目不用jQuery，是因为jQuery不适合这个项目只好选择其他库而不是改用原生的JavaSrcipt。
6、由第5点说来，用不用jQuery库这个问题，应该换为“只用jQuery？”。多了解其他比如YUI、Prototype、MooTools知晓他们之间的异同、功能侧重对原生JavaSrcipt的理解也更能深入一层。
7、抱着原生JavaSrcipt不放，不如找个相应的库迅速解决问题。这不就是所谓的“站在巨人肩上”吗？
8、有更多的时间关注新东西，应该远远好于纠结于已有解决办法的老问题。

基于jQuery的仿flash的幻灯片演示插件

chesanqi — Mon, 19 Sep 2011 23:05:53 +0800

把工作中的一个仿flash的幻灯片演示，打包成了jQuery插件。大概满足以下需求：
1、点击小图片切换大图片；
2、每隔一段时间自动播放下一张图片；
3、点击左右按钮，显示相应前后图片；
4、如果当前图片是最后一张，则返回到第一张重新开始；
5、小图片有滚动效果；
6、大图片有渐入效果。

这里有演示地址，请点击参观
——————分割线——————
顺便把源代码放到了github，虽然我不知道这个网站是干嘛的，但貌似很火。费了半天劲才整上去，请点击这里。

苹果会加速泯然众人，但我不是说苹果败落

chesanqi — Thu, 25 Aug 2011 10:50:28 +0800

乔帮主这事说大不大说小不小，时代转换的前言篇章。是众多因素的其中之一，其他的比如说：
1、现在苹果geek感觉在消散。（街机）
2、市场增长压力，营收压力。（不可能永远保持高速增长，即使帮主在位）
3、Android等的追赶。（谁也不比谁差多少）

谈业绩，苹果依然会持续增长，市场份额达到之前诺基亚的地位也有可能，街巷阡陌男女老少贫富贵贱人手苹果。但这真的是我们希望的苹果吗？是我们印象中的苹果吗？

谈运营，帮主并非常规运营的好手，不远的将来即使见到简化版iPhone、可换壳的iPhone、可拆解的iPhone我不会吃惊。

谈体验，不用担心，苹果甚至Android们都会继续给我们带来更优秀的操作感，但这优秀的操作感能达到魔术般的极致吗？我们面对iPhone X会惊呼它重新定义了手机的概念吗？

苹果会加速泯然众人，但我不是说苹果败落。

——————————————————
最初写在#知乎#，可以在哪讨论。

HTML5演示

chesanqi — Wed, 24 Aug 2011 14:34:41 +0800

距上次写HTML5过去了好长时间。囧~，人真是懒！
最近内部学习用，修改了一下HTML5演示文档，粘在博客吧，请点击这里（Chrome效果最佳）。

另外粘几个关于HTML5的URLs：
1、The HTML5 test（可以测试各浏览器对HTML5支持情况）
http://www.html5test.com/
2、HTML5设计原理—Jeremy Keith在 Fronteers 2010 上的主题演讲（可以深入理解HTML5的设计思想）
http://www.cn-cuckoo.com/2010/10/21/the-design-of-html5-2151.html
3、畅游 HTML 5 (Dive Into HTML 5 中文版)（可以找到相关特性的相关说明）
http://www.diveintohtml5.com/
4、HTML5（火狐官方对HTML5的介绍，附有一些教程）
https://developer.mozilla.org/cn/HTML/HTML5

如果饭否添加捐助按钮？

chesanqi — Fri, 12 Aug 2011 14:38:36 +0800

有两个前提条件：
一是，饭否在比较长的一段时间内不可能有盈利能力；
二是，饭否在比较长的一段时间内不具备再融资能力。

如果说不行：主要在流言蜚语方面，此前没有先例。
如果说可行：主要因为用户忠诚度，505天的不离弃。

如果有捐赠，不应该区分捐助者和非捐助者，不应该有差异化功能。
如果有捐赠，建议开放捐助平台，透明捐助金额，公开捐助去向。
关于捐赠去向，除去运营开销，建议以饭否的名义用于慈善、回馈第三方开发者等。

> 写于“王兴”登上饭否热词之后。
——————————————————
最初写在#知乎#，可以在哪讨论。

share：可用性有如此重要？

chesanqi — Sat, 23 Oct 2010 22:43:46 +0800

来源：http://www.gracecode.com/archives/3035/

请原谅我取了个如此有争议的标题，原文的标题是《浏览器不是什么》。我个人觉得作者有点脱离题目，但这并不影响其想要陈述的观点。

可用性一直是我们前端争论的焦点之一。但仔细想想，我们是否值得为那些连见都没见到过的盲人阅读器或者那些自行禁用 JavaScript 的用户投入额外的、大量的开发成本去“满足”他们？

– Split –

原文地址： http://blog.istvan-antal.ro/2010/10/what-is-not-a-browser/

回想在那混沌初开时期，计算机是没有声音的，如果需要这项功能，则需要插入额外的声卡。而后过了段时期，有些计算机默认就加入了声卡，而有些则仍然保持着“哑巴的传统”。

然后再过了许多年，主板厂商们直接将声卡集成进了主板中－－至此，几乎所有的计算机都配置了声卡。那么问题是：这期间，多媒体行业做了些什么改变了这一切？

开始，应用程序发出如果想使用的声音，那么只能通过内置的PC 扬声器发声。而后过了段时期，出现了能够同时使用扬声器和声卡的应用程序。

话说回来，现在是否还有人关心自己的机子上有无声卡吗？我想恐怕已经没有。甚至我觉得人们已经遗忘了机箱中的扬声器了。

例如，我从来没有见过某款游戏因为机子上没有声卡而自动关闭其声音－－当然，如果我耳朵听不到那是另外回事情（老外的这个说法比较冷）。

说了那么多，上述故事和浏览器以及 JavaScript 的故事非常的相似。不同的是现在的开发人员，在开发应用的时候，仍然在考虑如果没有脚本支持的这一情况。

其实和当年的声卡普及情况差不多，JavaScript 发明于 1995 年（已经是 15 年前了）。当时其在浏览器中的份额不到 1%，而且当时的用户（甚至开发者）都认为这玩意是可有可无的。

我的观点是，每个 Web 应用程序应该能够尽可能的运行在不同环境中，但它并不说明无条件的迁就于某一情况，在任何情况下都表现一致。

例如，在浏览器没有 JavaScript 支持的情况下，新闻类站点仍然可以显示其主要内容（新闻），同时不保证那些依赖 JavaScript 的相册脚本，仍然还能正常工作。

我们现在称之为“浏览器”的应用程序必须为：它能理解 HTML、能使用 CSS 渲染页面、同时能驱动 JavaScript 脚本。某个应用程序只能够完成上述一项或者其中两项功能，那么这压根就无法称之为“浏览器”。

例如，搜索引擎理解 HTML（以及部分 CSS 防止作弊），我们只需要提供内容让其收录－－同时它不需要过多的了解 GUI 相关的设计。

从内容方面考虑，其实我只关心两件事物：搜索引擎和浏览器。首先，我第一步需要做的就是创建具有语义的 HTML（这对于 HTML 来说并不容易），然后再使用 CSS 排版并且使其支持现代浏览器，然后再使用 JavaScript 增加针对 IE 的 CSS 规则（很明显原作者非常讨厌 IE）。

我的上述工作流程有时候会收到指责，因为这样必须让老旧的浏览器具备 JavaScript 支持才能引入针对其自身的 CSS 规则。同时情况可能变得模棱两可，我真的不认为我们称之为“浏览器”的玩意竟然不支持 JavaScript，哪怕是那些可以称之为古董的玩意（暗指 IE 吗？）。

总而言之，我们的思路应该为未来而开发，而非迁就过去（We should develop for the future not for the past.）。

我们应该为大多数（用户）而非少数服务。如果我们的用户中有 0.1% 禁用了 JavaScript，那么在我看来，我们可能不值得去耗费大量的开发时间去争取那些 0.1% 的用户。

同时另一个事实是，如果我们让用户觉得在没有使用 JavaScript 的情况下也能使用我们的应用，那么他们会毫不犹豫的禁用它（类似 noscript 插件）。那么这样，我们推进 Web 的前进几乎是不可能的，我们和用户都会认为 JavaScript 是额外的附属品。

最后，其实我想说明的是：在着手实际开发之前，我们首先规划那些有限的资源（例如时间、人力等）－－它们的计划投入和实际产出是否能符合我们的预期。

– EOF –

看了多少谈可用性有多么多么重要的书，但实际项目中真的没有以此来实行。国内总能找到搪塞的理由，却不能真正地说出个严谨的观点。多一种观点总是好的。

个人觉得可用性有那么重要，但不必为所有人群都提供十全十美的解决方案。网站支持落后的浏览器能让访问者走到最后，但路上的风景不必如现代浏览器那般精彩。

有人测试国内的电子商务网站禁掉JS后没有一个能买到东西，而亚马逊却可以。需求总认为一个能把所有浏览器兼容，能把设计师出的页面在所有浏览器中都写的一模一样的技术最牛；其实能表现出差异性的才是真的牛。