The Best Tool for Creating GUI Mockups

Digressions, objections, delight in mockery, carefree mistrust are signs of health; everything unconditional belongs in pathology.

Friedrich Nietzsche, Beyond Good and Evil

I just found (Thanks Uri) the greatest tool for UI Mocuups - Balsamiq Mockups. If you are a product manager, a UI developer or a techie marketing person, I highly recommend it.

The traditional ways of creating Mockups are quite annoying.

• Visio is expensive and is not really suitable for this task, although It is a wonderful tool in other cases.
• MsPaint requires some artistic sense, and using the fill brush to erase screen bits feels so 80′s .
• Coding is time-consuming and not relevant to many product managers.

The things I like about Balsamiq Mockups :

• It works ! I created Seven mockups screens in 5 hours for a complex feature
• It feels “Just Right” . It does not try to create a real application, but it comes with many components to make life easy
• The UI looks great, but it is intentionally “sketchy” to avoid Graphic Design distractions
• The developers seem nice and “get it”. I even got an evaluation copy as a blogger.
• Fair price – just $79
• It’s really cute. For example this is how the comments look like, within the mockup.

Comment in Balsamiq

Some minor issues:

• The properties pane behavior is quite bizarre, it keeps popping up in the wrong place and fading away. Should be dockable.
• Sometimes the Flash application feels a bit sluggish.
• The regular evaluation is very limited, and does not allow one to save their work.

I’m looking forward for the SaaS version that would allow easier team work and revision control. A grouphub and TRAC plugin would be cool as well.It would also be amazing to generate “applications” from the Mocks.

To summarize

try it out , it is well worth your $79 and would put a smile on your face.

Alas, poor Yorick! I knew him, Horatio: a fellow of infinite jest, of most excellent fancy. He hath borne me on his back a thousand times; and now, how abhorred in my imagination it is! my gorge rises at it. Here hung those lips that I have kissed I know not how oft. Where be your gibes now; your gambols, your songs? your flashes of merriment, that were wont to set the table on a roar? Not one now, to mock your own grinning? Quite chap-fallen? Now get you to my lady’s chamber, and tell her, let her paint an inch thick, to this favour she must come.

William Shakespeare, “Hamlet”, Act 5 scene 1

Where in the world are the great user interface developers? – Part III, The Conclusions

1. Hire a person that loves to create and program user interfaces.

The ones that “will do it”, “can do it” and “might do it” are not the ones that produce “it”.

Explicitly validate their love during the interview, as most people find it harder to lie when they answer a direct question.

• “Do you love to program UI?”
• “Wouldn’t you be bored  of debugging CSS bugs in IE  24 hours a day ?”
• “Do you use tooltips to remember the names of your kids?”

2. Get a great programmer.

No big surprise here except one – maintain all your regular expectations from your best kernel master.

Look for a developer that understands how UI frameworks work, remembers  binary search and grasp how networking  is a part of the web.

A prior knowledge in UI is a plus, but isn’t mandatory. Core capabilities are the key.

Some representative tasks :

• “Analyze MonoRail and compare it to WebForms”.
• “Make sure our website loads quickly over WAN , although the IE team thinks HTTP pipelining is a risky technology.”
• “Make sure we have a single method for error reporting”

3. Outsource wisely.

Hire excellent usability experts and graphic artists. If needed , augment them with Flash gurus and CSS wizards.

For a start-up you probably don’t have full time positions for these people anyway. For a big organization you should try and get them in-house. However, it is hard to convince the great ones to work in a big corporate with more than 3 employees.

4. Choose people who posses extremely high aesthetic qualities.

No, they don’t have to look like Top Models. They don’t even need to be able to draw a straight line.

God knows my drawing skills reached their prime in kindergarten.

Actually, I was almost thrown out of the army’s officers course, because the psychological screening suggested my image of a house is seriously flawed.

Still, I can be quite obsessive to get others to make it look good. In my younger days I opened  a few bugs over a one pixel misalignment in a firewall dialog box. I did apologize to the programmer before doing so…

5. Pay them accordingly.

If you think UI is as important as the rest of your system, put your money behind it.

BTW, it is probably the most important part of your system.

Where in the world are the great user interface developers? – Part I

After a six months long search, we have finally filled our UI Guru position. While recruiting is not easy these days, it is next to impossible to find an excellent UI developer on any given date.

There is vicious cycle preventing good people from programming UI and pushing good UI programmers to other domains. I will try to describe this flawed process and maybe even start a movement to fix it…

Here is how it works:

1. Development managers unusually come from the server, networking, kernel and database walks of life.

2. Software mangers tend to be arrogant .They presume UI programming is easy, boring and can be done by anyone.

3. UI developers earn less money than kernel\networking developers.

4. The best programmers do not want to become UI experts, as there is less money and prestige in it.

5. As most UI developers are not excellent programmers, they write the code in non modular, non reusable fashion. Thus it really becomes boring and manual to fix. Even if an excellent programmer happens to start in UI, he soon wants to move on to the server side, or at least become a team leader.

6. As a result of the above, the development manager belief is encouraged, since most of their UI coders are not very impressing. They pay them less and distance them form the real interesting product decisions.

Examining the myths leading to this outcome, I believe they are flawed and irrational.

“UI is not an important part of the application”- thankfully, people have largely grown out of this perception. The success of Outlook, iPod, Nokia, Google and others has demonstrated that exceptional user experience carries a huge premium.

Even in more traditional enterprise based security software the rule applies.  If the feature does not have a visible, clear, user interface it might as well be removed. When I worked in Check Point, we sometimes tried to roll out features with no UI, because UI always seemed to be the bottleneck. We rarely succeeded.

In one famous case, we added a dialog to features that existed in the product for two years. The interface was simple and we assumed the task would be quick and easy. We were very wrong. Not only the UI was complicated, it turned out the features themselves are not working and need to be designed from scratch.

The features were turned off by default when they were first released, so they never ran in the field. Off course, no bugs came from support and everyone assumed they work well. QA stopped testing them, as they were pushed to the magical “Test Cycle 3″ which never actually takes place. Our sales and marketing people did not really promote the features and customers did not even know they existed.

“UI Programming is Easy” – Yeah, right. If it is so easy, how come it is always the bottleneck?  I managed software projects in multiple programming language and various organizational structures. X\Motif, MFC, C++, Java, Swing, AJAX etc. I experimented with UI programmers as a separate group, as integral part of the main application team and as outsourced team. The projects domains were in enterprise, consumer and Telco .The developers were Israeli, American and Belarusian.

The one common aspect was the UI effort was almost always the bottleneck in the development process.

Server developers tend to think UI is easy, because one can create a trivial application very quickly. Sadly, most applications are far from trivial. Generating high quality user interface, which is maintainable, modular & pretty is extremely difficult. Unlike backend programming, every mistake is highly visible and everyone has an opinion on the subject.

“UI Programming is boring, tedious and manual”

Strangely, many people think programming kernel drivers with VI in “C”, armed with printf debugging, is more tedious than writing a modern application in C# & Python, using Visual Studio.Net.  Personally, I find the internals of kbuf, mbuf, ioctl & NDIS tiresome and frustrating. If one wants to hand craft assembly code, he might as well become a hardware engineer.

It’s true the debugging Cascading Style Sheets can be frustrating, but so is analyzing core files on Linux machine and the memory is one big mess. Sometimes it seems that the typical male programmer finds it more prestigious to hunt down the prey with bare hands

The truth is that UI programming and design can be extremely challenging. When done right there are sophisticated modeling, design and coding involved. There is always some manual, event customized code that needs to be written, and this tends to be less generic than server code by nature. However, the usage of more modern programming frameworks compensates for that and makes it much more fun.

Stay tuned for the second part of the post – Binary search and the UI Guru.