Powered by Twitter Tools

Making a cute web site
 

Don’t make the web site just cute. You main goal should be to influence users with the power of arts. Listen to the business people carefully — they want their users to be persuaded doing exactly what? In a web shop, think about what can motivate users to buy things in your shop, not in the neighbour one. In an ad-based revenue model, ensure the users would come back over and over again. Send an emotional message, if you need. Build trust, if you must. Charm them with elegance. Overwhelm them with power and energy. Disarm them. Inspire them. Make them laugh. Make them cry. Embarrass them. Soothe them. Praise them. Make them curious. Make them feel your respect. Manipulate users to help achieving your business goals.
 
 

Not owning design
 

Late change requests tend to be placed in any free area, without re-thinking and re-evaluating the overall impression of the site. Protect your site from scars of change requests. Insist on a new composition to incorporate the new feature in the optimal way. Educate decision makers about negative consequences not doing so. Fight for your baby, own your design.
 
 

Ignoring real data
 

Dummy screens always look so harmonious. Colors fit together, texts fit to their areas, no part is pulling the picture to a side, the focus is flowing perfectly. The only problem is that your users won’t ever see the dummy screen, but the real app filled with the ugly, chaotic, dirty real content. Ensure to get the real random content examples and create your design with them. Test your design with extremes (absence of content, too much content, bad content quality).
 

Not reusing controls
 

The app looks fine in the minimized mode. But let’s look at it in fullscreen. Well… not bad at all, but let’s just spread the controls a couple of pixels apart, for a little better look… Stop. You’re doubling development efforts here, achieving another 2% improvement of design quality. Better pay attention to other areas.
 
 

Reusing controls
 

Coverflow looks cool. We’re using it to select from products. Fine. But we also have another item lists: site navigation; selecting day, month and year of the birth date on the registration form; choosing credit card in checkout… Reuse the coverflow control? Obviously not. While it would undoubtedly save development efforts (unless you change a couple of pixels from usage to usage, see the point above), it would often ruin the overall web site impact.

Powered by Twitter Tools

Powered by Twitter Tools

Powered by Twitter Tools

In this post, I’ve gathered some traditional (and untraditional) spring festival wishes. By clicking on the links, you can easily send the wish to your beloved ones, parents, children, friends, collegues or actually anybody.

万事如意 all best wishes
心想事成 may your wishes come true
幸福安康 happiness and good health
平安快乐 safety and happiness
一帆风顺 single sail, gentle wind
恭喜发财 prosperious new year
笑口常开 life full of happiness and smiles
工作顺利 job to go smoothly
事业有成 success in all projects
无条件爱 unconditional love
自由 freedom
儿童 children
尊重 respect
理解 understanding
友谊 friendship
欣赏 appreciation

Or, you can see them all. This gallery is powered by silverhd.net, a new beta created by my collegues. The wishes are best viewed with Microsoft Silverlight.  I thank 于海婷 for the wishes and translating.

Having hangover? Soy sauce's antioxidant activity is ten times that of wine: http://j.mp/aaMROJ Next time Chinese instead of a bar #

Powered by Twitter Tools

@umputun NYSE isn't going to send their data using twits yet, is it ? http://tcrn.ch/4DnHit by @arrington #

Powered by Twitter Tools

• Create a common vocabulary of artifacts and activities instead of a common process
• Ensure presence and motivation of competent professionals
• Learn how and where to trust them

Just to be sure, I’ll provide a couple of examples what is process and what’s not.

Most companies have common conventions. These are documents decribing for example how to name a private class member, where to put backup files on the production server, where requirement documents and offers can be found if you know the internal codename for the project, etc.

Such common conventions are not processes, if

• most of the employees agree on them and find them useful in the real practice
• their usage is not enforced in any way, besides, may be, a question of a cautious collegue “You’re not using the conventions here? Cool, you have something special in your project?”

In fact, such common conventions build part of the common vocabulary, which is important in absence of processes.

Many companies have developed forms to be filled to transfer the information. The most common examples include a form to reimburse expenses during a business trip, a project review document, and a form you have to fill in the IT ticket system to have them to do just anything for you. These forms ARE typical processes.

Instead of communicating information according to situation (i.e. also verbally, or in form of an internal blog post), individuals are forced to fit it into a predefined, sometimes outdated and never fully adequate form. While it sometimes reduces the amount of work for the recipient of the information, it often also reduces the overall effectiveness of the company. Not only because the time of form recipients is often less expensive than the time of form fillers, but also because valuable verbal and non-verbal information gets lost. Such processes should be avoided, unless legally required for financial etc. purposes.

To go this way, you need competent people who understand how and why software processes can work. You need motivated people willing to use their knowledge for their employer. And you should be able to trust them.

Software processes on the other hand promise to work with just any kind of employees. Just have them do the steps defined in the process, and make them accountable for adhering to it. The only absolutely necessary feature employees must have is the discipline. And because employees whose main skill is discipline cost less on the labor market, you can develop software cheaper and thus raise the efficiency of operations. So the theory.

The notion of processes used as substitute of competency and creativeness is so immediately ridiculous and obviously wrong for everybody who was in this business for some time that I’m not going to spend much words arguing. But it is still interesting to investigate, why this idea seems to be so insane.

Let’s examine a basic software developing activity: the coding. It consists from several atomic operations like typing text, editing text, saving file, searching for a substring, executing an application and so on. Everybody including my mum and her dog can learn how to do these operations, after a 3-month course. But, applying the right operations in the right order and knowing what to type cannot be instructed.

You can learn capitals of every country in the world. You can learn 3000 words of a foreign language. You can memorize them. But you cannot memorize how to code. Because it is different in any new situation. And computers will never forgive you for any small mistake: while you can still become an average cook by memorizing tons of recipes, you cannot become an average programmer by memorizing all the words in a programming language.

What you have to do is to improvise each time you code. Your first improvisations will be extremely bad. You repeat and repeat them again, and you slowly improve in it. And when you reach the level of proficiency, you cannot dump your brain so that others would ingest it and immediately obtain your skills. Because it is your subconscious, which will be trained, and your subconscious is highly specific to you, your childhood, your genes, your environment and the history of your life. It is useless for anybody except of you.

This fact has a couple of interesting consequences for knowledge sharing, software developers working in groups, dealing with source code from others, and colleague-to-colleague learning, but I digress.

The need for improvisation is also required in the basic activities of other professionals participating in the creation of software product: you can memorize all Photoshop features but it won’t make you a graphic designer; you can learn by rote books about handling conflicts, but it won’t make you a project manager; and you can know the test script by heart, but it won’t make you a software tester.

Ability to improvise is a required skill to get things done in the software development business. No software process can replace it, when it comes to getting hands dirty and actually develop the software. A certain level of experience and creativity is needed anyway, so no software process would really allow to hire people whose main skill is the discipline.

Now, it can happen that particular software professionals are experienced enough to code, but are not experienced enough to be able to select proper course of actions depending on the particular situation. Wouldn’t a small nifty software process guard them against mistakes simultaneously showing them one of many possible ways of software development?

I believe, the answer is no, unless there is someone adapting their software process to the current situation, on the daily basis. If it isn’t happen, they end up doing mistakes ACCORDING to the process. And, they will not accept these mistakes as their own mistakes. So they don’t learn from them and will not try to improve the process. Because, “hey, I’m doing everything exactly according to YOUR process, so don’t blame me, go change YOUR process yourself.”

The better alternative to that seems to be pairing software professionals with more experienced ones. So they can observe how decisions are taken, ask questions about the reasons; and take their own decisions on topics delegated to them and get a feedback about suitability of those decisions.

Say, if I want to be a team lead, I am assigned to be a part-time associate team lead of a project. My job is mainly observing what the chief team lead does, accomplishing routine tasks for him to polish my skills, and temporarily replacing him when he is on vacations or not available. After several projects, I may feel to be knowledgeable enough to take over the chief team lead responsibilities. Of a small simple project, of course I think, this idea is worth to be tried out.