记得最开始的版本是“设计报纸”的概念，因为觉得博客和报纸这两个东西有很多相似性。
而且报纸的风格是简洁的、经典的，对信息的处理方式是何等“直接”，可以说是印刷
品中最具“用户体验精神”的。

但是印刷品和互联网毕竟还是不同的，比如不可能像报纸一样每版发行前都重新排版，重新
切页面。所以偶尔拿它做个专题或者季报还可以。于是就直接在报纸这种感觉的基础上改成了
下面的版本。

很显然它过于简陋，缺乏雅虎的特征，这也决定了下一个版本最需要的是雅虎的感觉。

第三版用了大面积的紫色，采用了三栏式，把中间栏做为功能区域。无论是色调还是页面
最下方的链接区域，都用的雅虎的“语言”。
然而，这是一种人为的情感宣泄，也许一个博客并不需要有这样的“义务”，因为它仅仅
是一个博客。

从紫色退却出来，就变成了一个灰色调子的页面，整个页面只有连接字是橘色。刚开始尝
试了很多饱和度比较高的颜色，最后决定不在这上面浪费时间，因为灰色和橘色还是比较
经典的搭配色。

最终确定的基调是，需要体现团队的概念，因为它是一个部门博客，可以任意上传内容
只应该是它一个最基本的功能。而它更应该像办公室里的一面创意墙，任何相关人员都能
随意“勾画”几笔。所以就成了线上看到的这个样子，背景和首屏的大图承担了这个可以
任意勾画的任务。其他地方，传统的两栏式加一个团队秀模块，同样这个模块的添加也是
应了凸显团队的概念。

说到这就更能看出来，任何设计最后承现出来的都是对一种理念的表达，设计产品的时候是
这样，哪怕做自己感兴趣的小玩意儿也是一样。

5月22日，一个阳关异常灿烂的日子，一群兴奋的年轻人（也包括几个孩儿他爸），穿着由stalker 和hippo童鞋专门为此次活动设计的T恤去到了平谷别墅村（传说中的“别野”群？）

走之前先来一张合影

车队Logo

  


总指挥：“大家保持队形，匀速前进”

达到目的地

兄弟们开车辛苦了，来张合影

我们也来凑热闹

趁天没黑上山去

找到组织了

黄昏下幽静的山谷

童鞋们，开饭啦～

健康的农家饭

  
  

太阳落山了

“ 这个颜色看起来不够时尚、不够醒目啊 ”
“ 人气人气！页面要表现出热闹的气氛、火红的颜色 ”
“ 我们这个产品与其他产品不一样、不用考虑我们公司的其他产品 ”
“ 功能太少了、用起来效率低 ”
“ 我们的产品要加点生动的图标 ”
“ …… ”

当然一方面、借助这些不同的声音可以让我们的思考不必受限在盒子中、但另一方面、常常“达成共识”又是一个复杂漫长的过程。怎样让“达成共识”能更容易一些？这是我正尝试的方法：

1. 明确问题
不同声音往往是对某件事缺乏共同的理解、明确当中的“某件事”的实质是什么？简化问题的重点。

2. 是否符合设计目标
明确问题后、点到与设计目标有关的问题上、去问: 这个方案真的符合设计目标吗？

3. 利用规则
有一些原则是必须遵守的、有一些是允许设计发展的空间、明确问题是归于前者还是后者、前者是必须遵守的共识、后者是需要达成的共识。

4. 说明设计内容
对不是原则性的部分、详细的向对方说明设计的构思、设计的目的、想要呈现的设计个性以及使用产品的情形，避免一部分太个人喜好的看待设计问题。

5. 重新思考
如果还存在有缺乏共同的理解的部分、反思我处于什么角度以及是怎么考虑的、这是我的判断还是预测？从自己的境地再重新思考。

6. 检阅设计
以上阶段如果还意见相左、那就邀请更多的人对设计进行检阅、总结评估结果和改进建议。

另外、沟通时注意的：

1. 倾听
随时停下来倾听、避免自说自话、也要避免陈述上过于绝对（我的感觉是往往要非常认真的去听对方的意思）

2. 语气
尽量用征询的语气、切忌一副苦大愁深的表情（这也是我要改的地方、之前受石磊影响多了）

3. 语言
不装、用平实乃至粗浅的语言去说专业上的事情（“设计来设计去”的听着头晕）

4. 词汇
蹦中文、不过度包装且直白

页面主色调为橙色，简单的空间布局，并增加了许多的留白，让页面有了更多的阅读空间。由于之前的页面上图标运用过多，而且没有统一性，以至于左侧出现过多的颜色，干扰了用户的阅读，所以新版关系图标进行了统一设计。

布局：

图标：

与仅仅作为个人电脑（或电视）不同、AQUOS 项目在设计独特的用户界面上走得更远、看看这些他们的研究结果：

得出的结论认为：个人电脑和电视具有不同的内容。

AQUOS 的目的： 作为“利用客厅的 Yahoo! japan”。而不是 “使用 Yahoo! japan 最理想的方式”。

使用：相比 pc、AQUOS 更多是被动渠道的信息流。

用户群：相比 pc 和移动电话、使用电视服务的老年人比例较大。

显示：屏幕显示按视距比例放大、文字大小也适应新的比例。

内容：需要合理的排序和更少量的信息。

阅读： 电视的高亮度使在白色背景上阅读文字很困难。此外、空间和房间的气氛等都对阅读产生影响。

页面：在页面布局、按钮、远程控制上探索更容易使用的方式。

去探索网络在不同领域下的界面设计、又是一个挑战。

场景：

建筑：

人物：

最初的设计想法是尽量表现产品中8类建筑的特性.用卡通的风格去描绘方块的小房子.一期的图标绘制比较简陋,仅仅是表现特征,增加识别性.

在二期的升级建筑绘制中.遇到了一个难题.就是之前没有规划出建筑升级的概念.所以在一期建筑构图上并没有留下富裕的东西.几经讨论,最后是以缩小建筑比例增加楼层和装修的方面来划分建筑升级的概念.

可以看出2期建筑图标明显比之前的要精致许多.并且配上了小的点缀.

抢房团在关系上顺利登录，期间离不开VD、FLASH、WD通力合作、辛勤劳动，在游戏中，大家通过“投骰子”在地图上行进。在途中，你可以购买房产、给好友打工挣钱、使用道具来获得如心所愿的结果；更会有一些意想不到的随机事件发生…在抢房团中还会有很多的创新功能没有充分的体现出来，我们还在继续努力，在今后的日子里给大家更多的惊喜。

URL：http://guanxi.koubei.com/apps/rich/

（PS：哇咧！谁刚又把我的钱均了）

搞Java开发的人不应该陌生。我没搞过Java开发所以之前没接触过，最近听过一堂Zakas的课后，觉得这东西超好用。关于Ant的解释：
“Ant是一种基于Java的build工具。理论上来说，它有些类似于（Unix）C中的make ，但没有make的缺陷。”(出自http://www.kuqin.com/beginner/ant.html)。

需要一个什么样的前端开发流程?

想想我们是怎么进行前端开发。
写代码 —-> 执行代码 —-> 发布

因为Javascript无法提前编译，所以代码有没有错只能在“执行代码”这个阶段才能发现。前端开发的一个特点是很多潜在的错误或设计缺陷不好预前发现，只有等到发布后不断的使用才能发现，但已给用户造成不好的使用体验。

所以如何保证高质量的代码和规避风险一直是讨论的话题。 雅虎美国的前端工程师Zakas建议建立一个完善的前端开发流程，让我们的前端开发更加井井有条。

一个比较合理前端开发流程：
写代码 —-> 检验语法 —-> 整合代码 —-> 生成文档 —-> 压缩代码 —-> 布署测试环境 —-> 单元测试 —-> 发布

Ant可以轻松的使其中大部分环节自动化，如果再写的复杂点，可以实现全部自动化。

如何创建一个前端开发流程?

用JSLint进行Javascript语法校验。这里要用到JSLint和Rhino。
首先到http://www.jslint.com/lint.html下载fulljslint.js, 再把rhino扩展贴在jslint后面，并修改一下：

if (!JSLINT(input, {rhino: true, passfail: false})) {
print("jslint: 发现问题 " + a[0]);
.......
quit(1);
} else {
......

校验的target：

<property name=”rhino.jar” value=”E:\rhino1_7R1\js.jar” />
<property name=”jslint.js” value=”E:\rhino1_7R1\fulljslint.js” />
<target name=”js.validate”>
<apply executable=”java” parallel=”false” failonerror=”true”>
<fileset dir=”${js.src.dir}” includes=”*.js” />
<arg line=”-jar” />
<arg path=”${rhino.jar}” />
<arg path=”${jslint.js}” />
<srcfile />
</apply>

使用Ant内置的Concat任务合并文件

开发时可以按照功能分成若干个独立的模块开发，在Build时再合并成一个文件。这样更容易维护，而且可以根据不同需求灵活的组合这些模块很方便。
<target name=”js.concat”>
<concat destfile=”${js.build.dir}/${js.build.file}”>
<fileset dir=”${js.src.dir}” includes=”*.js”>
</concat>

使用yuicompressor压缩文件

<property name=”yuicompressor.jar” value=”F:\yuicompressor-2.3.5.jar” />
<target name=”js.compress”>
<apply executable=”java” parallel=”false” failonerror=”true”>
<fileset dir=”${js.build.dir}” includes=”*.js” />
<arg line=”-jar”/>
<arg path=”${yuicompressor.jar}” />
<srcfile/>
<arg line=”-o” />
<mapper type=”glob” from=”*.js” to=”*-min.js” />
<targetfile/>
</apply>

压缩CSS同理，
<target name=”css.compress”>
<apply executable=”java” parallel=”false” failonerror=”true”>
<fileset dir=”${src.dir}” includes=”*.css” />
<arg line=”-jar” />
<arg path=”${yuicompressor.jar}” />
<srcfile/>
<arg line=”-o” />
<mapper type=”glob” from=”*.css” to=”${build.dir}/*-min.css” />
<targetfile/>
</apply>

代码布署

使用copy任务进行本地/局域网内布署
<property name=”local-server.dir” value=”E:\wamp\www” />
<target name=”files.local.deploy”>
<copy todir=”${local-server.dir}”>
<fileset dir=”${js.build.dir}” includes=”*.js” />
</copy>

布署到远程服务器
<target name=”js.deploy”>
<ftp server=”ftp.yourserver.com”
remotedir=”/_demo”
userid=”your_username”
password=”your_password”
depends=”yes”
verbose=”yes”
binary=”no”>
<fileset dir=”${js.build.dir}” includes=”${js.build.file}”/>
</ftp>

或使用SCP，但需要额外安装Ant插件 – jsch (http://www.jcraft.com/jsch/)。
<scp todir=”${remote-server.host}:${remote-server.dir}”>
<fileset dir=”${js.build.dir}” includes=”*.js” />
</scp>

Ant手册中(http://ant.apache.org/manual/index.html)可以看到，Ant有很丰富的内置组件，并且可以很方便引入外部扩展组件。Ant几乎没有不可能完成的任务!

UTF-8的文件有中文一定要指定编码：
<target name=”js.concat”>
<concat destfile=”${js.build.dir}/${js.build.file}” encoding=”UTF-8″>
<fileset dir=”${js.src.dir}” includes=”*.js” />
</concat>

<target name=”js.compress”>
<apply executable=”java” parallel=”false” failonerror=”true”>
<filelist dir=”${js.build.dir}” files=”${js.build.file}” />
<arg line=”-jar” />
<arg path=”${yuicompressor.jar}” />
<arg line=”–charset utf-8″ />
<arg line=”-o ${js.build.dir}/${js.build.file}” />
<srcfile />
</apply>

以前都是道听途说一些关于Google的事，这次有幸亲身体验一回并且有老友作导游讲解，对Google的认识更真实了。

以前看来的都是Google的办公环境如何如何好，管理如何如何人性。其实在Google工作压力还是很大的。Google内部有几千个项目在跑，这些项目都没有上线计划，因为一个产品要在内部做的足够好了才能公开，就是先要“吃自己的狗食”，像GMai就是这样诞生的。

刚加入Google的新工程师，第一件事就是找自己感兴趣（有信心做好的）的，有前景的项目。这一点很关键，在Google每个人有一个履历表（类似个人档案），记载你在Google参与完成的项目，就像一份成绩单。这份成绩单直接关系你的薪资水平。Google的组织架构很偏平，从普通工程师到佩林之间，无非就有五六级。薪资跟职位没关系，所以相比职位的晋升，Google的工程师们更关心，自己的成绩单。

在Google的经理，不是像国内主要是分配任务，而是给你提供帮助，所有都要靠自己去做，找人了解公司正在进行的项目情况，找相关的技术培训，找资源等等。每周都要写技术周报，内容主要是项目的阶段完成情况，下一步实现的目标这些。代码要提交给项目是的资深工程师审查，这个审查很严，所以Google的代码风格都是出奇的一致。每季度考评一次，这个考评不是经理做的，而是工程师之间相互评价，这是匿名的。所以你要努力的表现出自己的专业性，帮助别人，积极交流，赢得好评。

在Google工作久了有了人脉之后，就可以自己组织人马立项目。

这里绝不是入职之后，大家一团和气，相安无事的地方。经常会有入职之后适应不了而惨遭离职的人。为了平衡这种压力，Google才会提供超豪华的免费餐厅，优越的办公环境和诱人的员工福利。

这种机制非常适合互联网公司。每个人每天在想“我能为Google贡献什么”。