It’s easy to talk about clever ideas, but it takes genius to present them easily and powerfully – and those guys managed to do it both in this node.js basic concepts presentations. It changed my thinking about callbacks – the concept I loathed at the first sight. I’m going to give node.js a go, seems worth it!

When designing a solution usually we need to show some slick and simple pictures showing user interface we plan to implement. This seems to be the only language both developers and customers seem to understand. Or maybe let me rephrase it to be more specific – screenshot has the highest likelihood that its interpretation by all parties will be similar. Preparing such images takes a long time – the most popular approaches I’ve seen so far are:

• use your favorite graphic editor – e.q. Gimp, Paint.net, Photoshop, Illustrator, etc. The result usually looks good, but is a nightmare to maintain, especially when you need big chunk of text or new large field.
• mock the UI in Word – get a ugly wire-frame of the window only to forget to group the boxes and see them flying around the document after any change
• … or Excel – Excel is good for everything, isn’t it?
• create a form in html – happy styling, call me next week when you’re done!

The process was usually time consuming, but not any more! This week I’ve seen three smart prototyping approaches:

• Balsamiq UI modeler – application to create any UI layout using drag&drop. The web-based demo (functional!) version is available
• Microsoft Visual Studio Express – free, fully drag&drop RAD environment. It seems like an overkill to use it only for this reason, but consider the price tag!
• Microsoft Visio – especially 2010 edition – nice, easy and integrated with Microsoft Office Suite

All above applications let you create both static window images and interactive UI prototypes. Next time you talk with your customer show him a “working” demo next day after you got first requirements – he will love you! And hopefully he will understand what you are actually trying to achieve.

Good, great and beyond

Nearly a hundred years ago Konstantin Eduardovich Tsiolkovsky said his famous words “The Earth is the cradle of mankind, but one cannot stay in the cradle for ever”.

It’s easy to get carried away by such statement to think about the final frontier for human race. Imagine all the worlds that lay out there. But the sentence can also be used more metaphorically as a guideline for moving projects up to the next level – from good to great.

Good projects are those which work as planned, while great project evolve further and further. Good project can make you a decent living, but only the great projects can change the world.

In the cradle of Vision

Each project starts with a vision. The vision should be then kept in mind during whole project live, otherwise the project will become stale and fail in the result. Good vision is what drives the team in common direction, let people focus on what is important. The main goal of the project is to fulfil its vision.

Image you want to create an online book store, so you define your vision in a simple statement “Let’s create a book store”. You gather your team and assign tasks (even if your enterprise consist only of you, you will still form many functional teams!) – define logistics chain, define IT solutions, define marketing plan etc. You start working on details and implementation and sooner of later you end up with working solution.

You’re now selling books. You have a steady flow of orders, you have managed to build a good project. It works, it generates you income, it is predictable and utterly boring. Soon you will realize that your competitors start to run in front of you.

Evolving Vision Statement

What happened? You’ve achieved your main goal, but you failed to evolve your vision further. You sit comfortably in your cradle and capitalize on your hard work. You can grow up to the size of your market and compete hard, but unless you redefine your Vision, you are basically stuck.

Here’s where all the fun starts – you can move in many directions (be careful not to bite more that you can chew at once or you’ll choke), just give your teams more breathing space and you’re on the best way to creating a great project.

Can you imagine the world in which some of the greatest companies in evolving their vision would fail to do so and
* Google is maintaining only a web engine
* Microsoft is releasing only new versions of Basic and operating systems
* Facebook is a signle university only portal
* Walmart runs only one grocery shop
* Amazon still sells only books
?

I’m currently preparing to become “a lawful wedded husband”, which involves buying tons of stuff. I was comparing various offers and one pattern emerged: if a thing X is renamed to “Wedding X” it automatically becomes at least two times as expensive. See for yourself: wedding photography costs 295-1500 GBP while corporate event photography 75-180 GBP for comparable time and effort. Wedding cakes are priced at 250-850 GBP vs event/birthday cake which can be bought for 10-80 GBP. So I decided: from today on I’m charging wedding software engineer rates!

You may ask what is a Wedding Software. I’ve analysed the differences between normal and wedding items and I found some common elements, which I intend to apply to software.

• basic wedding offers are mediocre, so they enforce customizations and add-ons. For cakes you get a plain sponge cake with a white icing. You want some taste, maybe chocolate? No problem – just add +30% to the price :) Do you want some decorations? No problem, 25 milk chocolate stars pressed into the icing – +20 GBP! Or maybe you’d like to write something on the cake? No problem, …
• customizations of wedding items are charge more for. The same text written on a birthday cake costs less than half of the price of the same text on wedding cake. Oh why?
• you get a ribbon with everything. It’s a customization, but everyone is willing to provide you with this one for free.
• you are not allowed to buy non-wedding items for wedding. They may fit, they may suit your needs, you may love it, but still your forced to buy something with a “wedding” tag
• wedding items tell you that they are prepared for “your special day”, “most important day of your life” etc.

So, applying the same rules should improve our margins dramatically. What’s more we it should increase customers satisfaction level. So:

• wedding software should be usable, but ugly and limited as possible. Create a blackAndWhite.css and doNotScaleForMobile.css and apply it to any page you release. Basic version of apps should run up to 800×600 and play sound in mono only. But plan ahead for at least 2 customizations for each feature, including (mostly) irrelevant ones like ALHMMO “Advanced Left-Hand Mouse Movement Optimization”.
• customizations are sometimes called “extras” for a reason, they should be extra pricey. Just remember to tell the user that the extra stands for extraordinary usable and smart.
• excel kills millions of lines of custom code a year, wedding software should not allowed users to use multi purpose tools like that. All data should be exported in unportable formats and all 3rd party imports virtually impossible. Or at least customers should be educated that doing so it a very nasty behavior and they should never do it. Hint: avoid question “why?”.
• software should no longer be commodity or necessity. Wedding software should be luxurious and exclusive. Buying software should be advertised as a transition from the dark times to enlightenment. People live to buy software. It will take some time for them to understand that, the only way is constant repetition.

It worked for wedding industry, it will work for software also!

ps. I still haven’t found what the software counterpart of a free ribbon may be…

Today I have encountered an issue while I was uploading new version of my extension to chrome webstore:

"An error occurred: Cannot parse message.json file from uploaded package."

I wasn’t expecting that since the extension was working locally without a problem. Also the error message says about message.json which was not a part of my package as the i18n files are called messages.json.

The error was trivial to fix (although not so easy to find) – I have put some comments into messages.json file, which seem not to be supported by extension gallery even though Chrome itself can handle them properly. But the thing that made me smile was that a Google guy created an error message with hard-coded (incorrect) filename. The gods have fallen ;)

Google is making constant changes to their APIs and they seem to roll the alpha/beta versions for us to test. Which should be fine unless you expect your webpage to be stable and working all the time.

One of the issues in current version of Google APIs is problem of missing markers when you try to place two or more Google maps objects on a page. All maps are displayed in their div tags as expected, but only one of them gets the markers actually displayed. No error message is displayed, individual maps work with markers when they are separated, but together they don’t.

The only solution I have found so far is to tell Google that we want to use Stable Google Map API instead of latest. Do to it add v=3.0 version selector to URL of JavaScript librery, i.e. instead of

<script type="text/javascript" src="http://maps.google.com/maps/api/js?sensor=true">
</script>

use

<script type="text/javascript" src="http://maps.google.com/maps/api/js?v=3.0&sensor=true">
</script>

So far I haven’t noticed any drawbacks of this solution. New unstable versions probably add new features and/or improve performance, but I’m willing to wait until the changes are tested and moved to stable API. I bet you do also.

My chrome extension just got two new features:

• Show in Wikipedia
• Show in Wiktionary

They do basically that they say on a tin. The language of both wiki sites is determined by Google’s translate language detection function. It’s not always accurate, but it’s best I can get at the moment.

I encourage you to install Translate and Speak! and play with it. Any feedback will be appreciated.

Yesterday new version of “Translate and Speak!” (previously TranslateMe) Chrome Extension has been released and it’s now ready to download on Chrome Webstore.

New features in version 1.4 include:

• “Speak!” function, which uses amazing Google’s TTS to read text
• Translate (detect language) function, which tries to guess language of the phrase before translating it to your selected language

Today British police made available their new service – a complete street level map of crimes in England and Wales. The webpage made to all possible headlines in daily papers, tv and radio. The effect is that the service is virtually down and won’t be usable until the novelty wears out.

All web pages have a peak from time to time. It can by due to various reasons – PR publication, Facebook craze, advertisement campaign, algorithm change at google or change of cosmic radiation. You can predict some peaks, some will come as a total surprise. In both cases the effect is the same – the system overloads and you’re starting losing users. That’s bad, really bad.

What could site owners do to prevent this? There are couple of options:

• Scale IT infrastructure to handle the traffic during peaks. This sounds good until you start calculating cost. If you scale for a peak 10 times larger than normal traffic, you will spent 10 times more money. And how can you be sure the peak won’t be 11 times normal traffic? Or 101 times? Or 1001? And what would you do if when the peak is over? You can donate unused computing power to Seti@Home, but I doubt your CFO will appreciate this.
• Deploy to a cloud. When your application is running in a cloud and you foreseen incoming peak, because you’ve bought nation wide TV ad campaign for exmaple, you allocate more resources for some time (for example start some new instances on Amazon EC2). And when the peak is unexpected? You allocate more resources when it happens! Or if you set up the cloud to allocate additional resources automatically for you, you just sit and monitor if everything works smoothly. When the traffic calms down, you just switch off unwanted resources and stop paying for them.

“What’s the catch?”, you may ask. There is none. The whole process just requires some planning in advance. Designing application for scalability is slightly tougher, but it’s not a black magic. And it’s not even rocket science. There are many infrastructure scalability patterns detailed on web. You will have to make some technical decisions on load balancing, session sharing, fallback procedures. The testing is also bit more complicated, but only due to fact of additional features. The rest will be exactly the same as normal design and development job.

I have always known that police is a useful force ;)

The Chrome Extension model is amazingly easy to use with just few basic concepts to understand. But there are rather severe limitations. The most important I found so far:

• There is no easy and consistent way to create option page. Developer needs to create option page as any normal HTML page, this is just overkill! See Extension options page, Chrome issue cr25317.
• Attaching action to context menu is limited in many ways:
  • You can’t add two items to context menu. Chrome automatically creates a group called after the extension and puts all your items into this submenu.
  • Callback method from event gets very limited amount of data about the click – e.g. you can’t easily read the contents of a link (A) tag right-clicked by user.
• There is no way you can modify the title of the link in context menu when it’s being displayed (no OnShow or similar event).

Expect edits here.