一个人拥有自己独特的风格，是一般人所没有的，就会让人注意到那个人的特别，若那个人的风格是正面的，甚至就会引起别人的羡慕与注意，或是赞赏。就如同一个网站，拥有别的网站所没有的风格，就会让浏览者愿意多停留些时间，细细品尝该站的内容，甚至该站会得到多人的鼓励与注目，粗略的说，网站风格可以从以下几个方向来探讨，而每一项都是有关联性的：

1. 色系：网页的底色、文字字型、图片的色系、颜色等等。

2. 排版：表格、框架的应用、文字缩排、段落等等。

3. 窗口：窗口效果，例如：全屏幕窗口、特效窗口等。

4. 程序：网页互动程序，例如：ASP . PHP . XML . CGI等等。

5. 特效：让网页看起来生动活泼的各种应用，如：Flash . Java script . Java applets . DHTML等等。

6. 架构：目录规划、层次浅显易懂、选单应用等等。

7. 内容：网站主题、整体实用性、文件关联性、内容切合度、是否有不必要的档案等等。

8. 走向：对于网站的未来规划、网站整体内容走向等。

以上这些项目都与网页风格有密切的关系，网页的风格不是某一项相同，网站就是有整体感，而是要各项目的配合应用，才能达到完美的网站风格设计。接下来的段落，将会为每个项目做简单的介绍。

一、色系

网站的色系是浏览者整体的视觉观感，若一个网站色系能有一致性，不仅会使网站看起来美观，更能让浏览者对内容不易混淆，增加了浏览的简洁与方便。而网站的色系更能衬托出网站的主题，若色系能与主题合理搭配，将会增加浏览者的易读性。

网站的色系包含了网页的底色、文字字型、图片的色系、颜色等等，这不单只是将颜色搭配得当就算完美，还要配合每个内容，及网站主题。对于网站的色系，应该要在网站开始制作前，做好规划及设计，才不会到着手制作网站时，难以搭配，甚至造成混乱的设计。

网页的底色是整个网站风格的重要指针。举例来说，以黑色作为背景颜色的网页，因黑色本对人的视觉上会造成黯淡的感觉，若是拿来用作活泼的儿童网站，就是不适合了。因为小孩子是天真无邪的、活泼的、有朝气的，与黑色的沉稳、黯淡，很难联想在一起。

再举个例子，若是写一个有关于环保的网站，若用暗红色作为网页底色，决计不会有人联想到网页的内容是与环保有关。当然，每个人的审美观不同，可能也会对颜色的代表性看法不同，但既然网站不是只写给自己看的，就应该要注意到大部分人可能会有的观点，然后以众人居多的观点出发，来设计网页。

文字字型上的设计，最好的网站是以所有浏览者都能看到的字型为主。常会看到有需多网站要求浏览者须自行下载某种字型，才能达到最佳浏览效果，这是种非常奇怪的行为。毕竟浏览者只是来找资料或是来看网站的内容，不可能会因为这种「为达最佳浏览效果」，而自行下载所需要的字型。

当所要求的字型若不下载，并不会影响到网站内容上的浏览与不便，那么对浏览者的要求就微乎其微的不可能发生任何作用。这么一来，对于网页设计者来说，无非是非常可惜的，因为当初的设计风格却未能让浏览者一窥全貌，岂不是白费心思的吗？

何谓图片的色系？以色彩学简单的区分，可分为冷色系与暖色系，再详细一点的区分，又可分出各种颜色的色系，而色系的区分，就在于主观浏览意识上的差异了。如何将图片的色系与网站整体色系相对应，就是比较困难的地方了。对于网页初学者来说，要绘制一张图并非易事，要绘制一张符合自己网页风格的图，更是困难重重。大部分的网页制作者，并不大可能驾轻就熟的使用影像处理软件或绘图软件，于是乎，网页素材的网站就开始盛行了。当然，不会使用绘图软件并不代表网页就不能设计的很出色，若是能将网络上的素材资源妥善利用，网站也是可以走出自己的风格的。而该怎么选择适合自己网站的图片，就是门很大的学问了。

选择图片该以何作为标准呢？举例来说，若网站内容为科学探讨，当然不能以卡通图片来作为插图，试想，当您正在浏览一个有关天文学的网站，却满是皮卡丘的可爱图片，不是很不协调吗？再举个例子，如果一个教学网站，里头却尽是明星图片，看上去根本就不像是教学网站，而是大杂汇的明星相片网。很多人喜欢将自己欣赏的明星照放上自己的网页中，如果仅是个人网站倒也还好，因为个人网站本就无主题居多，也就没有所谓的符不符合主题的顾虑，但若是有主题的网站，岂不糟糕？

以图片内容来说，能切合网站主题最好，若不能，也别差异太多。以颜色来说，若一个网页是蓝色的底色，但整个网页的图档却乱七八糟，各种颜色纷纷出笼，更糟的是，蓝色是属于冷色系的颜色，若以蓝色为底的网页，却尽都是大红色、橘色的图片，那将会使整张网页看起来就像垃圾堆，杂乱无章。所以，可以简单的归纳出，网页与图档的颜色，色系一致或是视觉效果一致，将会使网页看起来更为美观且有自己的风格。

Entities

First of all, let us keep in mind that tasks are actually what IWs really care about. They are much happier if they can complete assigned task without touching emails. Right? Completion of tasks is what they are trying to achieve. Second, when they have to communicate, they care about distilled information they are expecting while writing/reading emails. You will not get any additional credit through presenting your idea by writing a poem. Senders and recipients come last. Without them, communication can’t happen. These two entities get lower priorities because if distilled information can be gained by other means, say search engine or anonymous DL, who cares them?

Again – email for IWs is all about tasks, not messages. This is the most fundamental philosophy differentiating Pmail’s design from others.

Problems – an abused tool in workplace

By nature, current email systems allow one sends anything to any number of persons at anytime anywhere. Gradually it turns out true that something that can be anything can do nothing actually. Theoretically any email should be of your interest; otherwise sender will not send it to you. Realistically it is so easy to be over-used:

• Email overload. You might probably find everyone around you is complaining about too many emails. Doubt? Open you email clients, see how many unread mails you have. NY Times reports, E-MAIL has become the bane of some people’s professional lives. This occurs likely because of complicated job nature, but I’d say often it is actually because of poor email prioritization. Can you easily tell which email is much more important than others? Or emails tell its priority to you?
• Hard to map emails to one’s day-to-day jobs. How many times you have to search your emails to dig certain messages out because you need something?
• Mail thread discussions often go wild. Do you find you are in trouble figuring out what is going on when suddenly looped in a thread?

At a glance

Pmail’s primary design goal is to help team get jobs done efficiently – under right timing, priorities, order and resources. Everyone would have a clear picture about how his work contributes to team success.

Pmail would also aim to minimize communications as much as possible. Leave users alone please. In task-centered email design, all emails will fall into one of below four categories:

Persona/User scenarios

Key scenarios that Pmail addresses include:

• Know big picture for better prioritization – Steven, who is a developer in a software development team, came to his office in a morning. He opens bird view of pmail to check how his tasks (or WBS in more general term) fits into the entire team progress. He notices one of his tasks, task8, is in critical path according to updated plan(never expect plan is really locked after lock-down). This task is automatically prioritized to p0(highest priority) by Pmail. It is about implementing a feature according to design specification by feature PM.
• Maintain dependencies – Steven goes ahead to open task8 and find this task depends on two resources, 1) one LHS virtual machine, which has been completed by task7. VM address and credential are also attached. Nice! 2) PM spec. It is also claimed completed.
• Main email threads around tasks –Steven opened the spec document in team Sharepoint server, and he finds several points are not clear for him. Then Steven starts a mail conversation with relative PM, Joanne, against this task. The mail thread is linked to task8 and its status is open.
• Drive team work flow – Joanne received a catch-the-ball mail from Steven about p0 task8, so it is a shadow p0 task for her as well. Joanne can check task details in the Pmail. She quickly comes up with answers regarding Steven‘s questions and writes back a here-you-go email to Steven. Steven receives the email and get unblocked. Steven closed the email thread by several sentences. This mail thread is traceable in task8 and can’t be replied any more as it is closed. Several hours later, Steven completes task8 and closes it in Pmail. When Steven re-visits the bird view page of Pmail, he finds task8′s color turns green due to status change. Steven then picks up another one unblocked taks, task9.
• Maintain team discussion – Task9 is about designing a new feature F9. Deliverable is reviewable dev design spec. Steven has two options about solving a technical problem, but not sure which way to go. He then sends a collective-effort discussion mail to the whole team. Since this is not a catch-the-ball mail, team mates will treat it with best efforts, but Steven still gets several great feedbacks. When he feels the problem is solved, he summarizes the thread with several sentences and closes the thread.
• Check history – One year later, Steven transfers to another team and his replacement, Eric, would like to better understand why F9 is designed this way. He opened Task9 in Pmail, check the mail thread and better understand original design decision.

Demo/UI Mock-up

Bird view will look like above diagram. In following task view, you can see all mail threads about one task are at your finger tips.

Mail view will also a bit different. Every mail has a TaskID field to help you get the whole context conveniently.

Key features in Pmail

In addition to biggest differences we covered before, you might also get excited when seeing below features.

• Sometimes feature-rich is not a good thing. It is so easy to reach this point when email system is designed for multiple purposes after several releases, say home usage included. But in any event, Pmail will provide a button to show/hide features(say, increase/decrease indent) which I don’t use in last month. Get me a simple world.
• Mouse hover will show abstract of email(user could assign, or automatically select) before deciding to read it
• Send me SMS notification when a selected critical thread gets new replies. No special carrier service needed, input my cell phone and go
• For discussion mails, send brainstorming results or decision made, and then close the thread by marking it as un-reply-able
• Enforce sequential replies, for example fill in a excel table
• Automatically memorize folder or url of files you are editing, and go to Pmail, it can be attached to the email by a hot key, say “ctrl+shift+v”
• mailURL(say, steven-task9-show-me-money-88; don’t use GUID, please) which can be shared across the clients. Don’t to forward again
• Automatically send out ping for dead catch-the-ball emails after pre-configured interval times out
• Play video/audio right inside the mail client
• Mail web client also provides web API like Facebook. OWA kills programmability.
• Tag everywhere – one mail thread might relate to more than one task. It is not a good idea to put a mail in one folder exclusively.
• Don’t allow send active documents to team for review, put it on shared place(say, Sharepoint) and send a link

I am interested in your thoughs on it. Let me know. Thank you.

Pros and Con

Why bother to build global development team?

• New talents pool – Software development needs so many persons with similar attributes. In Microsoft Company wide, top 3 hiring criteria are smart, passion for technology and fit to company values such as openness, continual self-improvement and mutual respect, etc. From various studies, supply of talented IT staffers isn’t keeping up with demand. And it won’t change anytime soon. Even when Microsoft is cutting 5000 jobs now, we still have another 2000~3000 job openings there. What to do if enough qualified hires can be not found within US? Go outside.
• Lower cost – let us straightly go to data. Annual pay for Level “59″ is about $74,000 in US, while same level is paid about $20,000(~RMB150K equally) in China. Another slight fact – It costs about $1.5 to go most common places in Shanghai…
• Close to market – Most innovative ideas often comes out of interactions with customers. And customers’ requirements vary from country to country. So best way to serve a local market is to be in the market.
• Specific knowledge – Cross-nation acquisition for specific technologies is another reason to build global development. You can’t(or not able to) move all folks to HQ.

Like many other things, challenges always go with benefits hand in hand. You can’t take only part of it. Fair enough.

1. Distance – People who work on the same software can’t work alone, they have to exchange information and make decisions. Less than 3 minutes conversation is often enough for slight but frequently arising communication needs, for example, “Could you show me the bug in your environment?” Distance makes it impossible to stop by one’s office. Network bandwidth is another issue introduced by distance. Why it matters? Suppose one team has to copy large file sets from another remote team daily, it would be a problem. The file sets can be growing amazingly big – for example, daily SQL Server build is about 300GB.
2. Time zone – Would communication a real headache since modern technologies such as email and telephone have been there for quite a long time? But the things are no one is there when you are working due to time zone. You have to wait another day to get an email response. When you rush to office to check it, the most frustrating but concise reply could be – “What do you mean by <insert anything you assume others should understand>? How can I help you?”
3. Culture/Language – Master level of English is unbalanced in global teams. There are dozens of ways to say “A beats B” in English, but only several of them are understandable for general public; dialect is another obstacle. For example, Chinese folks often have hard time pronouncing letter “L”, as a result, words like “girl” might sound weird sometimes.
4. Junior team – In my organization, most hires right come out of college. We are raw smart, but less experienced. It is hard to deny that some key ingredients for great engineers just take time – design skills, debugging techniques, influencing capabilities. This is not a cutting-corner example.
5. Conflicts between hierarchical management and local branding – By organization hierarchy definition, many business units have existence in China. STB, Live, Online Service, etc. They functions nearly independently of each other and reports to US. But from the perspective of customers/partners/talents, it looks a bit confusing because there are so many Microsoft’s.
6. People development – folks in remote sites are not equally exposed to development resources such as face-to-face training, library, mentors, etc.
7. Governing issue – due to well known concerns, something confidential can’t be moved out of US.

How-to

There are several factors playing critical role in deciding appropriate distributed development model. At least you should consider project type, team seniority, team size, team culture, communication cost and history.

• Build trust first. No matter how adaptable a new team is, it always takes time to fit into a specific team culture. So starting with easy jobs to build team moral and credibility is the safest steps before moving forward. Beyond this, the new team can target increased ownership.
• Decide on team coupling level. From highest to lowest, the level could be: pseudo random assignment, same branch same feature/component, same branch different feature/component, different sub branch but same main branch, different main branch & clearly defined data contract. Avoid circular dependency.
• Come up with communication plan. Minimized communication is not always the best, especially for relatively junior teams. The best way to develop people is to work with senior folks on daily basis as much as possible. So you have to make tradeoffs here based on various inputs.
• Shared lab if possible. If you have to copy large files across the ocean frequently, consider doing your job on a lab down in remote team. If you have to do copying, make sure the files meet most critical quality requirements before doing so, for example, a build verification test.
• People development plan. Regular staff exchanging plan such as Marco Polo and Silk Road program, getting a mentor, record trainings, etc.
• Local brand management. Externally shown as one image; internally run by functionality as usual.

Origin

Hulu, an online video streaming company, managed to do something which YouTube failed to do. Copyright is one of YouTube’s headaches, but it is incredible positive thing for Hulu, because it is built intentionally aimed to server property content by two major stream media dogs, NBC Universal and Fox.

{YouTube, watch someone’s DIY video} VS { Hulu, watch TV & Movies online legally} -> Similar but different market niche.

People might be asking, why NBC and Fox executives don’t rely on YouTube to serve their plays? You can imagine following conversation which probably happened behind the scene:

This is the first site who delivers property video to your computer for free. Traditional Media Company gradually realized that they have to embrace the changes if they are not able to prevent them. It is online streaming, in this case. Hulu has more than 120 sources now.

Key is property content sources are nonrenewable rare resources.

Independence

Hulu’s CEO said to capital angels, “I don’t think you’ll be seeing the name Fox or NBC on the site hardly at all, Hulu is about the shows, not the networks. The shows are the brands that users care about.” Another quote, “the key to Hulu’s success is its freedom to operate essentially as a stand-alone company…”

From startup’s perspective, captical can be good thing, or bad thing. It can help you grow much faster, but it can also easily enable you miss your initial goals. Capital often appoints some seemingly smart guy, who is with XYZ MBA degree or n years of experience in ABC company, to take over the company as one of its investment agreements.

That is indeed one of the worst investment risk controls, although it happens again and again. Give money to most passionate guys, and letting them be passionate always is the only way to maximize the probability of getting most out of your investment.

Feature?Solution? Experience!

Question: If you are given a task to build a video streaming site within less than 3 months, what would you do?

We were taught this way:

1) Identify who will be using your site

2) Draw use case diagram

3) List scenarios for each user role

4) To support each scenarios, figure out needed features

5) Design/Code/test your features

6) Go live

7) Yeah! Party! :- )

If you follow this in your next interview, I can almost guarantee a pass. Do we miss anything? Actually we missed most critical one – Experience! Experience is a combination of brand/feeling/easy-to-use/enjoyable process. For example, given below requirement:

“Design something which is used to sit on, commonly for use by one person. It often has the seat raised above floor level, supported by legs.”

People will respond immediately, “Chair!”. You may notice that there are at least hundreds of types of chairs in the world, if not thousands of, if not millions of. Only most imaginative ones who deeply understand that particular set of users’ needs, care about their feelings and eventually apply those into product designs can do the best work. Let us take a look at “art of chair”.

Be COOL, in show time, although you might have the similar hard time figuring out what some of them really are. Just like someone said about iTune – “iTune is not selling features. iTune is selling experience.”

Hulu’s key experiences:

1) Simple

2) Larger screen

3) High-resolution video

4) Clutter-free

5) Quality control

6) Free to users

7) No download

Obsessed with users

Technique #1: Dispatch a delegate on UI thread

Use Dispatcher.Invoke, we can execute the specified delegate on UI thread. The sample code would be:

this is the form object or control object owned by the UI thread. In this event handler, we simply call the Invoke method. The first parameter is priority; the second one should a delegate. In our case we cast a statement lambda to Action delegate type. Other than invoke(), you can also use methods such as BeginInvoke() in certain situations. And the equivalent code for WinForm would be:

We are using an anonymous delegate in above implementation, and you can see the code is pretty similar.

Technique #2: Update the UI while application is not busy

WinForm is still core part of many Windows application UI, especially when people design software years ago. For example, to extend the Outlook 2007 functionalities by writing your own form region in an add-in, you have to follow WinForm principles. To update your own form region in main Outlook UI thread, one of simple ways is to update it when application is idle:

In WPF world, this can be achieved by using DispatcherPriority.ApplicationIdle as dispatch priority parameter in technique #1.

Technique #3: Background Worker

Background worker is the build-in .NET mechanism to multi-thread UI, but the reasons why I list it as #3 are that developers complain that it is not that good to fit all scenarios as opposed to your own thread. If you take a look at exposed events by background worker, you will know why. You can find sample code here if you are still interested in.

Technique #4: Freezable (WPF specific)

In WPF, freezable objects can be frozen, at which point they become read-only and can be used on any thread at any time. These are used across all graphics primitive resources (brushes, pens, etc).

You can also create your own freezable classes.

Technique #5: HostVisual (WPF specific)

If you doesn’t require interactivity(e.g., keyboard inputs), HostVisual could be another option WPF provides. The element tree owned by the worker threads are rendered into their own composition target (called VisualTarget), and the results are composed into the HostVisual owned by the UI thread. The excellent code sample I found is here.