The Two.

和白老师还有关键照着手册做的。准备拆掉了。立此存照。

搜狗刚刚推出云输入法的时候，我说，搜狗真是走了很好的一步，我自己家的ubuntu上就在用，确实不错。不过云输入法至少应该还做两件事：

1. 帮桌面输入法提高准确度
2. 帮助Web应用提升输入体验

后来搜狗云输入法开始帮桌面输入法了。不过，搜狗在帮Web应用方面好像没有什么进展。或许因为他们的Web应用不够丰富？

不过如果百度做云输入法的话，那么估计一定会帮助百度的Web应用提升输入体验了。

[Update 2010/5/27: 其实写这篇文章的时候，QQ已经发布了云输入法的第一个测试版。产品开发的速度真是了不起。我另外一个猜测是，QQ或许能做出国内第一个跑在浏览器里的桌面系统。]

比如，怎么不再让输入法候选窗口挡住百度搜索栏的搜索建议？再比如，怎么让魔兽贴吧的同学们觉得自己在用魔兽专用输入法？

在桌面输入法中，QQ的劲头很足，大有超越搜狗的趋势。为什么腾讯要做输入法？我想来想去，原因可能是这样的：

1. 腾讯似乎要霸占所有的桌面应用。
2. 为了达到上述目标，用户就应该很容易从一个QQ应用到达QQ的其他各项应用
3. QQ聊天软件是个大怪，很多人在用
4. 输入法是一种你就算没在用QQ聊天软件但你同时也可能用到的QQ应用
5. 所以抢输入法就很有道理了。你可以看到QQ输入法的状态栏里有个工具箱，你可以从那里去到截屏、辞典、剪切板管理器……

所以，这么看来，QQ推输入法的决心就可以很大。搜狗危险咯。

猜想如下：

1. 百度云输入法一定会有跟自家Web应用整合的功能，从而真正让云输入法流行起来。
2. QQ桌面输入法会在未来两年内超过搜狗输入法。

所以，QQ和百度才会是未来最重要的输入法比赛选手，作为微软拼音的竞争对手。

等着瞧吧。

Devil is on the Space Bar, too.

[Placeholder]

Last week I was on trip in Redmond. We stayed in Fairfield Inn, a really nice hotel.

Everything was great, except I had some problem with the bath faucet. (Later, I found out one of my colleagues had same problem.)

The faucet looked like this:

(I should have taken a picture…)

It was very clear that the red dot stood for “Warm Water” and the blue one for “Cold Water”.

So, how do I get warm water?

I tried below operation but I failed. It didn’t move.

(This is so-called “User’s Model” *)

And I tried in the direction out of this page. I failed again.

I was very confused. Then I accidentially found it works like this:

(And this is so-called “Design Model” **)

It’s a very good sample that the design is to make it look better but less workable. And the user’s model cannot map to design model very well.

I would think to myself – DON’T HAVE THIS FAUCET IN YOUR SOFTWARE!

*,** – Please refer to the book “The Design Of Everyday Things”, which I was just re-reading on my flight.

I believe it’s a very common scene that 2 (or unfortunately more) program managers argue in a feature design meeting.

It’s more likely to happen in an early stage of feature design when everyone is not clear about how to implement the functionality. The discussion should be focus on setting the goals, target users, and the scenarios.

According to my experience, the arguements are often initiated by introducing unkown factors of the how: “If we can have Scotty SDK to beam my cup to the tea room… If Scotty SDK is not public to 3rd party, we’ll have to…” But what’s more important is how user’s needs get met in the scenario: “I want to get a cup of tea without going to the tea room in person as I’m on a conf call.” The scenario may go well by asking a Star Trek fan developer to do you a favor.

So the motto can be “No developers in this room” when having a feature discussion on early stage. Focus on how to meet user needs but not how to implement everything.

Of course I mean don’t think like coding the feature on the meeting, but we surely should involve the developers!

Spec is the tool for program managers to communicate with others – developers, test engineers, peer PMs, the remote team located on Mars, etc.

A spec is often started from a “Page-one” stage. On this stage, you’re answering some questions to yourself:

• What’s this feature?
• Why we bother to implement it?
• How to measure that we succefully done it?
• How the users will be using it?

I’m not experienced enough to make it a big topic but I want to share a tip which sometimes makes my spec look better:

When I look at my page-one spec over and over again, I would imagine that the spec is telling a story to a stranger. If the stranger gets the points, the spec is good. If not, the spec fails.

If it doesn’t feel real enough, I would try to explain to some guys not from a same team in the way I spec’ed. If they can understand, the spec works.

So this is my first Spec 101: Page one for strangers.

A very valuable learning from today’s Engineering conference is that when co-designing with your customers, don’t simply ask the stupid question of “what do you want us to design our software?” But observe their footprints of how they’re doing with their current pieces.

The words from the customers may inspire you for further innovation but the footprints are telling the truth where you can address the real issues.

I’d like to start the very first blog post with the mysterious button which bugged me for a while.

I saw this “DHB” button in the elevator of the hotel beside my office.

I was curious and asked my friends around but nobody knows what it means. (We’re in BEIJING and we speak Chinese…)

So I took a picture with my iPhone, and forgot about it later.

1 month ago, I went to the hotel for my wedding again, and the button showed up again. This time I asked the girl behind the reception desk and she told me this button is for emergency.

“OK, so nobody hits it?” I said.

“No.”

I believe nobody hits it but I don’t think it’s for alert.

So I googled it and found out yes it stands for “Door Hold Button”..

Then my points are:

1. In China, people hit the “Open” button to hold the door

2. Chinese people really don’t know what “DHB” means

3. The DHB button is really placed very well among other buttons that it looks neat

4. Nobody hits it

So the lesson learnt is – Don’t put any DHB button in your software.