Ugly UI

We use to say user interfaces we create are ugly. And in many cases we don’t care.

When I’m a user I complain every time when I work with unintuitive application.

Where’s my consistency then?

A little difference is within target group of users. When a target group for an application are typical Internet-eaters, like you or me, you need to give more. It’s not enough to have every single feature user can think of. You need to have it intuitive and nice. Other way people will go away choosing either ease of use or beautiful façade of competitors. By the way I’m still struggling with Office 2007 – it is way nicer than its predecessor but for biased user of a series of older version new interface isn’t very intuitive. That’s definitely not a sure shot when talking about GUI.

Fortunately you can have another group of end-users. System administrators are great example. They need to be able to do as much things as they can with their UI. Flexibility is a number one here. Intuitiveness is important too but usually users are far too experienced to allow your application to defeat them. But nice GUI design? Who cares? As far as it allows you to do what you want you don’t give a damn how it looks like.

On the side note I’m not a complete hypocrite. In our internal timesheets application I don’t care about GUI design as far as I have reports I need and my team doesn’t cry whenever they need to fill in monthly data. And that interface is ugly indeed.

Coming back to GUI we develop, most of them are either for administrators or for maintenance teams. Then we don’t have to focus much on UI graphical design. No one would really pay for it. Ugly can be good enough.

Users Like What They Know

You plan to introduce a new version of your widely spread application and one of key features will be new user interface. Or maybe you enter the market with new product which shall compete with market leaders and now you design GUI for your app.

And you have lots of ideas how to organize user interface better than it was done before. That’s for sure.

Unfortunately it does mean you set up a goal which is hard to achieve. I can even assume all your improvements ideas are great, which is rarely true. But let’s not complicate the situation. They are great.

You launch your new version/product/whatever and complaints start. We want to have spreadsheet working Excel-like. We want to work on Gantt charts in a way we work with MS Project. We want to have search looking like Google. We want to have invoicing window the same as it is in SAP. We want to have it the way it used to be. Keep your great ideas for others, we want our old damn interface back.

Because we like what we know. And we don’t want to learn new ways of doing things we do. We just don’t.

If you want to try to change the world of users habits you have two ways. You either believe your idea is strong enough to prevail or you stick to standards (no matter how low they are) and work hard to teach users new ways of doing things. The most obvious example of former is Google with clean search engine design. The examples of the latter can be Project-ON-Demand or Google Spreadsheet.

The first option has much higher failure rate. For each example of success you can find a bunch of examples of failure. From time to time I check different applications from area of project management and every time I see GUI totally different from what MS Project offers I see incoming failure. People won’t know it so they won’t like it. I don’t say MS Project is cool. It isn’t. I don’t like MS Project. Actually I hate it. But I used to it and most people around did too. Everyone knows how it works. Everyone expects other software doing the same things will work similarly.

Sure, you always can try to educate me with different approach but remember I’ll be reluctant. I’m like a typical user. Users like what they know. And they are lazy too. Remember about that next time when you start redoing all your user interface or reinventing the way people do things.

Usability is Made of Small Things

How usability is made? It is made of small things. Think about scenarios your users will use. Then improve them one after another. Think in categories of:

• ambiguity of operation

• clear messages shown to user

• speed of operation

• number of clicks needed to complete a operation

• possibility to work without a mouse

That’s not a rocket science. What more, thinking about small things, you can improve the application step by step. That’s completely different scenario than with for example performance improvements, where you often need to redesign big chunks of architecture to move out from a dead end. Usability improvements can be done easy in your next development cycle. Almost all you need is enough will.

The reason of all that evangelization lays in a list of usability issues I experienced lately.

• Error messages in Facebook. That’s so easy – hide your SQL messages, they tell nothing to most of your clients, they confuse users, they look unprofessional and they give out information about structure of your database, database engine etc. Give one of those funny error messages instead. Unfortunately, Facebook crew has still this step on the roadmap. Sin: unclear messages.

• Synchronization with Windows Mobile. I wanted to copy some music to my Windows-based Samsung i600 phone from the notebook. Should be easy: Ctrl+C, Ctrl+V, issue resolved, case closed. No so fast. ActiveSync which works as a middleman here can possibly want to make some encoding here, that’s why copying is so darn slow. First time I used it I thought the progress bar shows progress of copying the whole album. Shit happens – it was a progress of copying a single song... As a bonus the application you’re copying files from freezes until the process is completed. Sin: speed of operation.

• Playing music on Windows Mobile. OK, I’ve uploaded mp3s to the phone. I’ve started Media Player and found none of new music there. Ops, forgot to use the update library option (as it couldn’t be done automatically during synchronization). I’ve updated library and all music was gone. Ah, forgot to switch back default source for library from my device to storage card (as if it couldn’t remember how it was set before updating the library). And than finally I could start to listen to my music. Thank you Mighty Microsoft for your generosity. Sins: ambiguous operations and number of clicks.

• Setting up an internet connection via mobile phone. You want to connect to the Internet from your laptop through GPRS/EDGE/UMTS/HSDPA/whatever connection of your mobile phone. You configure the connection and finally you have to type “number” which will be called every time you connect. I mean some cryptic chars like “*99#” which I virtually never remember. Sure, you do it once, until you’ll be forced to repave your machine, but even then it should be darn easy as mobile operators charge you for using the service (and flat rates still aren’t as obvious as you’d think). Sin: ambiguous operation.

• Logging into ticket reservation application. I travel a lot between Krakow and Warsaw. Almost always by train. I’m not sure how it looks like in your country but here in Poland we still need a ticket, as Poland isn’t so wealthy to sponsor free train rides (at least not for me). Anyway, I use Polish Railways on-line application to buy tickets at least once a week. I could write about its (lack of) usability for hours but for now just one simple thing. Every time I log into the application I have to confirm I agree with the terms of use. No information if something has been changed or not, just “confirm, don’t ask” approach. As you can guess the terms of use is quite a long document (16 pages actually). As I can guess no one is reading it every time (and most of users don't read even once). If you see any reason to leave that feature there, tell me please. I see none. Sins: number of clicks, lack of thinking.

• Navigation in Google Docs. A couple of days ago I was working with Google Docs, editing very simple document. As you write text you probably use the keyboard unless you can steer the computer using mind powers only. When you want to mark the whole paragraph you don’t want to switch to the mouse and than back to the keyboard. In Google Docs you have to, because Ctrl+Shift+Arrow combination doesn’t work. And that’s not a sophisticated advanced operation – just everyday bread of word processor user. Sin: no-mouse navigation.

Every of those issues could be resolved in a very simple way. Neither of them requires much development or testing. On the other hand fixing any of them would improve user experience. You just need to think for a moment and have a bit of will to change them. Nothing more. Usability is made of small things.

New Features in Wrike

Some time ago I received a message from Daria from Wrike. They’ve fixed one on major issues I’ve pointed in my Wrike review. When you use email integration long threads won’t multiply tasks any more. It is called intelligent reply function. When another email is created in the thread (using reply all function which keeps wrike@wrike.com address on the recipient list) a description of the task will be updated instead of duplicating the task.

Unfortunately another issue appeared. After a couple of answers with standard company footers and multi-line signatures description is cluttered and you don’t clearly see where the useful information is. There should be either text formatting kept form original email or some kind of intelligent and configurable mechanism which allows cutting off needless trash from emails automatically. Or better, both of them.

It's quite typical example of situation when you can’t say that adding a feature invited a bug, but users using the new feature have to face some new problems. When you design new functions, you should always think how users will interact with the application. Think about the whole process user executes, not only about the part which is directly influenced by the new feature.

The Power of Shortcut

Shortcuts are typical user’s best friend. Imagine you use word processor and there is no Ctrl+C and Ctrl+V. Imagine there’s no Alt+Tab combination. What a painful situation it would be. For example copying highlighted paragraph between documents. Instead of: Ctrl+C, Alt-Tab, Ctrl+V you would do: [mouse move to] edit menu, [click], [mouse move to] copy, [click], [mouse move to] taskbar, [click], [mouse move to] edit menu, [click], [yawn], [mouse move to] paste, [click], [time for a nap] and voila.

OK, I guess I don’t have to convince anyone keyboard is faster than mouse and using shortcuts is essential when you want to be quick with keyboard. But when you think about shortcuts in your application you should look deeper. A new invoice icon in sales module of ERP system. A wizard simplifying creation of a new project in IDE. All those mash-ups which are sets of shortcuts of different type. Yes, these are shortcuts too.

The deeper you think the smarter options you can find. One of our local taxi corporations in Krakow (Barbakan for those who live around) greet calling clients with IVR application with TTS-ed prompt. I hear (translated to English):

Hello, this is Barbakan Taxi. If you want to order a cab to 16 Kuznicy Street, waiting time 8 minutes, press one. If you want to order a cab to Central Railway Station, waiting time 4 minutes, press two. If you want to order a cab to 44 Jasnogorska Street, waiting time 12 minutes, press three...

Best possible shots for me indeed. Kuznicy Street is my home. I travel often by train so Railway Station would be another obvious choice for me, and Jasnogorska Street is my workplace. My wife asked me if I have created those list. No, not me. These are my most popular orders sorted by frequency. Shortcuts for the most frequently chosen options. What a nice present.

Of course, I have no illusions about reason why the system was implemented. Neither for my pleasure nor for my convenience, but to save dispatchers time. Anyway I don’t really care. As far as I can use those shortcuts to make the operation quicker and more convenient I like it.

There’s one important factor why I think this shortcut is valuable. It improves path I use very often. Above locations cover more than 90% of all my orders. If I had on the list several random locations or top 10 combined from preferences of a group of users it would be useless.

It is very likely that you have to think about your users individually when thinking about their shortcuts. That’s not so easy as paths beaten on the lawn by majority of walkers.

By the way, when talking about user experience, Barbakan's website is, well, tragic. You don't really have to understand Polish (yes, no English version) to see how dramatic it is. Definitely the worst website I've seen for months. Anyway, I wouldn't check it if I wasn't writing about new great feature those guys implemented in situations which are actually used by their clients (unlike checking the website).

Blogger Localization Rules

OK, I ranted over Google Blogger. OK, twice. I’m sorry. I won’t do it any more. Sorry. But please, don’t make all that localization case worse every single time you can. OK, you guys can think that switching label from “software design” to


is a great idea, but I think it is not. You know I don’t actually know what the heck does means.

What more, you don’t really understand it in your engine. I have typed s-o-f-t-w-a-r-e design, but you’ve shown it as design on the blog.


Maybe you aren't aware but there's a difference. Make up your mind, please. If you change it, at least interpret correctly what you've changed. Oh, I have better idea. Don’t screw it. Leave it alone. It would be better that way.

Blogger Localization Counter Strikes

To add another two cents to my recent rant on Blogger localization issues: other day Blogger localized (Polish) website greeted me with a message.


The message used to be written in Polish. I don’t know why it is now in English. An error? Anyway, if you care to localize the whole website why don’t you care to translate the message which is shown on landing page (for users who are automatically logged in)? I know guys from Google cared to translate the message to Polish but somehow it went back to its original English version and from user perspective there’s no difference between both situations.

I think I’ll just switch the language to English.

By the way I think I’m happy I haven’t gone to Finland with Blogger language not set. Language setting would look like that:


Good luck in finding it. I don’t even try to think what would it be with Japanese or Chinese.

Blogger Localization Issues

Some time ago Blogger was localized to Polish. Although English version was fine for me, nice thing to see the Polish market becomes important for Google. Unfortunately two things could be, let’s say, done better.

First, and much more important, is a decision when to switch the language. Actually as far as I can tell it is made basing on the IP address you connecting from. As every IP address (or rather a range of addresses) is geographically ascribed to specific country it (usually) can be resolved which language is spoken in the place you’re in. Unfortunately it doesn’t mean you speak that language.

When Blogger greeted me in Polish one day it was OK. I wasn’t really enthusiastic as Polish messages are longer (in number of letters) than English ones and I end up with content not fitting into the window.


I’m a lazy user so the effort to switch the language is way too much and I guess using the mouse scroll will allow me to burn a calorie or two so I left the Polish interface alone. Unfortunately I was on business trip in Austria and, what a surprise, Blogger greeted me in German. Then, it became an issue as my German is limited to “Bier”, “danke” and “noch einmal” or so. It’s like with the old trick with switching the language in someone’s Nokia to Finnish. Almost no one (except of Finns) could switch it back easily. Yes, I was puzzled. Switching the language just because my laptop has changed the gateway IP isn’t the great idea. I still have Polish locales in web browser and Google still knows I always change the Google search profile into the English one. There are at least a couple of better ways to resolve languages I understand.

Second thing is a small one. Not so long ago I saw a message:


As you can see I’m still too lazy to switch the interface language. Anyway, the message tells, as you can probably expect, “Downtime planned at 4PM PDT.” The message is in Polish but here in Poland we use different time formatting (would be 16:00 or 16) and what the heck is PDT? Yes, I know that’s Pacific Daylight Time and I’m able to check the difference between PDT and CET (Central European Time, which most of Poles actually know what the heck it is) is 8 hours. But when you bother to translate the whole site why not to remember about showing downtime messages using time zone which is familiar to me? Hey, you know which country I’m in, what vastly limits a range of interesting time zones.

Localization is never an easy thing. And it won’t be soon. It’s worth to think about scenarios users will follow first and then plan how the work should be done.

Software Product Success Stories

There’s a meme about successful projects initiated by Scott Sehlhorst. Generally the goal is to describe a project which, with your help, ended up as a successful one, especially considering what actually had made the project successful. I was recently pointed by Craig Brown to participate so here it is.

My choice is a worksheet application we use in our company. It’s a simple piece of software where all our technical staff fills which project they were working on during every month. Historically the application forced the user to enter data fine-grained data splitting the work effort done everyday to hours spent on different projects. The intention of the stakeholder was clear – get as much detail as possible to exactly count the project’s cost and profit. Of course to be exact users should fill data daily or every couple of days. They would spend a minute or two everyday on the task. The list of projects was of projects was automatically downloaded from CRM database, to make whole thing more convenient.

That was the theory. The practice was that every month, when reminder was sent by managers (with painful penalties for not filling the data included, which was quite a poor idea by the way), people were facing two options. They either spent whole day or so verifying what they were doing three or four weeks ago (which wasn’t very exact anyway) or they just entered whatever looked more or less reasonable hoping no one would find a fault with them.

That’s not all. Having a list of projects automatically downloaded from CRM database ended up with project list where you could find all the records of potential project we’ve never won (or even have been close to win) and virtually no one in technical department had even a sketch of idea what the heck was that. The list was long enough to create some issues when deciding which project people were actually working on. Several old names, a bunch of projects multiplied in several instances etc.

The situation was that users actually hated the application and it wasn’t bringing expected results anyway.

I did three things.

• I came with my opinion stated just above to decision makers (fortunately I was one of them) and convinced them the solution didn’t work at that moment so we could change it a bit with no pain whatsoever.

• I asked Gosia who was developing the application to make one change – switch from hours-per-day to days-per-month metric. User interface practically didn’t change and we didn’t care about integrity of database as we set up a new one. All changes took Gosia less than a day (or I just believe she is so fast) and I got a simple administering interface to fill official holidays as non-working days as a bonus. Then we officially switched “worksheet filling schedule” from daily to monthly regime, which actually was formalizing the reality but made the task less painful, as expected data was coarse-grained rather than fine-grained.

• The last thing was switching off automatic synchronization with CRM database and cutting off 95% of existing projects from worksheet database manually. That limited the list of projects to active ones only, hopefully improving user experience a bit more. Yes, now I have to add every new project manually into the database, but still that happens once per quarter and wasn’t so heartless to ask Gosia to add that feature as she had quite urgent work to do.

Where’s the success? Users hate the application less, which in this case is a success. We still have to send reminders to get the data filled, but that’s much less of a waste of time as people are forced to enter about 2-3 records on average choosing from 20 possible options instead of 50 out of hundreds of options and, magic happens, information isn’t less precise.

By the way making applications stink less should be in mission statements of many of software companies I know.

To invite a couple of people more to participate: Bruce Henry and Glen Alleman.

How to Make Users Happy

Most software vendors struggle to make their software better. We add functionalities, we improve performance, we fix bugs. We follow strategic vision which tells us where our application sucks... I mean is very good but should be pushed closer to perfection. Unfortunately it is the vision which sucks so often because we focus on wrong areas.

Yes, new features make sales easier but they rarely make users happy. Generalizing a bit, most users don’t use the most new features delivered in a new version. Users follow their old, well-known paths. If you want to make users happy you should track those paths to see where they can be improved.

I see many examples how it is screwed up these days. When I shoot at Google Docs or OpenProj it is because my frustration grows when I try to follow the most basic, yet the most frequently used, tasks delivered by the software. And while I like both I still come back to their old-school Redmond-based alternatives.

Similar situation I found today with MindMeister. It is web-based mind-mapper. Probably the nicest-looking web-based business software I’ve seen so far. It looks nice, is free (for basic features) and delivers functionality you need from that kind of software. Nothing more I could have expected. Except of doing the basic things right. The frustration can appear quite fast when you can’t delete a node in a mind-map or change connections between nodes, no matter how hard you try. These are the most often used features. They should work. OK, they work. Most of the time. Actually they work 99% of the time. But that’s not enough.

Although I use mind-mappers rather rarely I like MindMeister much. It’s a piece of well done work. Unfortunately small issues affect a bit that nice picture. They are small but happen in the area where they should not. The one which is the most frequently used.

That’s just another example that when you want to make your users happy (or happier) you should adjust your vision to include the work on the things which your users use the most often. With complex application the quality and usability can differ depending on areas/functions/modules we consider. Focus on those which make your users frustrated with everyday use and fix them. That won’t bring you direct sales (as new features would) but content user will spread the word.

And the good user is the happy one.

Technology for Web Applications

If I was about to start a new software project it would definitely be a web application. A couple of years ago I was building a team creating ERP solution from a scratch. If I had to choose one thing I’d change if I had a chance to start whole thing once again I’d go on-line instead of creating a classical desktop client. And yes, I remember that two years ago web technologies wasn’t so mature they’re now, even though I wouldn’t actually call them “mature” yet. On the other hand now, after two years of following that path it would be a great advantage over competition. Especially when we talk about SME segment of market and multilingual application and that was exactly our target market back then.

When I think about that and I recall all those users I had to deal with when I was support team manager in CDN XL team I believe we’d have to address all major web applications issues. OK, maybe graphical design wouldn’t be so crucial, but speed, contexts, and keyboard-driven steering were on the list. The technology should have been chosen carefully.

A little side note: time when I was an active developer is rather ancient, so I my look at technology is based on what I see developed by others. I don’t say something is definitely impossible with any particular technology, but I believe that there have to be some reasons why (almost) no one makes very good/great applications using the technology. Another little side note: when I look at application quality I consider several factors independently, so I can imagine e.g. great usability combined with poor functionality. Of course overall outcome won’t be very impressive that way.

Coming back to hypothetical technology choice on the end of 2004 I would probably opt for Flash. It loads long, but that’s a single time investment. After that it can work instantly. In terms of speed, when something is efficient in games it will be enough in business applications too. With fully controlled working area, made entirely from your own “controls” contexts shouldn’t be a great problem. I don’t say it would be easy, but I guess there’s no serious technical barrier to achieve that. You could also ignore standard keyboard shortcuts from browser – you wouldn’t have much use of them anyway. A great graphical design wouldn’t be a problem either.

I don’t say that from the technical perspective it would be easy. You don’t see many business applications made with Flash around. The alternative is placed in different AJAX technologies. However, when I look at AJAX applications, they never let me forget I’m using the web. It does mean that despite having all advantages on-line apps provide out of the box (collaboration!) they lost competition in usability category.

I haven’t seen any Flash Application Framework, but I guess we’ll soon see one. The other way is to find universal solution of usability issues in AJAX, which is far easier to use than Flash (basing on number of existing applications). If I had to bet I’d probably go for the former solution, although it can look as a weird idea.

Web Applications Flaws

I believe that the future of software is the web. If you read me regularly, you probably aren’t surprised here. However it’s still hard to imagine the world without desktop applications yet. Why? Although network access isn’t on the availability level of power access (everywhere and always) it’s already acceptable for software except mission-critical applications. The main issue is different. The main issue is usability.

Web applications are still much less usable then their desktop brothers. I’m not talking about functionality, which can easily be enhanced, but about the way the user interacts with the software. There’s list of flaws web applications experience.

• Speed. The Mythical Google Speed, which is by the way still unreachable in rich web applications, doesn’t stun when compared to typical desktop software. On desktop all simple things, like menus to take the first example, work instantly. And I haven’t heard about anyone being impressed by that.

• Contexts. Take the web app. Use the right-click, The God of Context Menus. It will open the context of either browser or Flash Player. Definitely not the context of application.

• Keyboard. Web sites are designed to work with a mouse or a stylus, not a keyboard. On the other hand people are designed to work faster with the keyboard. Web applications very often lack things like shortcuts, which allow better interaction when you’re an experienced user. By the way, there’s another trap here – should Ctrl+F open the application’s search engine or rather the one from browser? When to override browser’s shortcuts and when to leave them in charge?

• Graphical design. I think that’s another great invention of web world. People prefer nice applications over ugly ones. Yes, new, cool, Web 2.0 applications are much nicer than we saw several years ago. However, they all fade when compared to new, cool, Desktop 2.0 programs. Last week I could play with several pieces of software developed with use of WPF and now I’m twisted – Google Reader isn’t so cute any more.

A couple of things can be corrected with current technologies. Microsoft Outlook Web Access has great context menus for example. And, if I’m correct, it’s since 2003. It doesn’t automatically make it a great web application however. Still, people choose the web version only when they have no other choice or in areas where desktop Outlook really sucks (with poor network connection it takes ages for Outlook to stat synchronization with Exchange server).

Yes, we choose (and will choose) more and more of web applications, but in terms of functionality and usability they’re usually worse. Somehow we can lower our expectation, only because the software is installed somewhere else, not on our PC. That’s the subject to play with for psychologists I guess.

Future of Software

I came across summary of Hasso Plattner’s presentation about innovation. His main point is that SaaS is the future of software (no surprise here) and he references often to Google. Google SaaS success. Google speed. Google minimalistic form. Google this. Google that.

While I agree with many of Hasso Plattner’s arguments, I think he flatten the case of Google. Sure, Google speed came into software development dictionary, but it’s a feature of the search engine, not every Google application. Sure, pure design works perfectly, but another time – for search engine. GMail, Google Reader or Google Analytics have rich, webish 2.0 design.

Google is a flagship example of SaaS success, but depending on product there are different priorities in design or innovation. Pure form and speed of Google search isn’t copied in many of other applications. And you can’t treat search engine or AdSense (which is similar case) as typical SaaS applications. Much better examples here will be Reader or Google Docs which are designed to be richer, nicer and (of course) slower.

Although I'm a big fan of on-line software, I think there's still a significant big gap in usability between desktop applications and their web brothers and sisters. I'm yet to see web application which will be fast, functional and full of features. That's the SaaS future, because it will allow smooth migration of users from desktops to web terminals. In other words, I'm pretty sure that we won’t be ruled by minimal design as the price paid for on-line speed. Web 1.0 to Web 2.0 path shows that people want nice and functional UI.

Our Customer Is Wrong

“I don’t understand our customer. They want us to make the interface like that. But that’s far from optimal design.”

“I guess they have some reasons to do it like that.”

“It’s completely unintuitive that way. Look you have to choose from several hundreds of options from drop-down until you can go further. They said they want it exactly the same like in the legacy system.”

“Um... As far as I know their end-users aren’t very fluent with using a computer. Maybe they followed exactly the same scenario for years by now and it would be hard to retrain them, even if the new one is better. I guess, that can be why the customer doesn’t want any changes here.”

“You know, that can be a reason. I haven’t considered it that way.”

Look broader. Accept you can be mistaken. Trust in knowledge of your customer. Customer is (almost) always right.

Another Good Error Message

Yesterday I wrote about good and bad error messages. I have one more example – error message from Technorati.


Another good message. Technorati takes different approach than Pandora with coolness factor as the most important one instead of professionalism factor, but it works that way too. The message is easily readable and understandable, it looks nice and although it doesn’t say what went wrong it’s funny. It makes user smile. It makes user feel better, exactly like Pandora’s error message.

As you can see it isn’t a rocket science to design good error messages and there are several possible options which allow you to hit the target. The time spent on improving these messages is the time spent well.

How to Design Error Messages

I haven’t written about one of my favorite services for several moths already, but as usual Pandora gave me a reason to post a comment. When I was trying to “thumb up” a song an error occurred. It wasn’t a typical error message however:


First, it’s written clearly and in human language. It’s as clear as a day which action failed. Second, I’m really touched when the application apologizes: “I’m sorry. It’s my fault.” So nice. Well written error message can really make the difference and even make the user feel better.

There are a couple of things more. The message window looks nice. Font is big and easily readable. There is no OK button, because it’s far from OK when I can’t use one of basic features. The retry option (the positive one) is more exposed than the cancel option (the negative one).

On the other hand you can find error messages like that:


It’s ugly and clumsy. It forces you to agree that it’s OK that the error has appeared. And for most of users it’s completely incomprehensible. On the contrary to Pandora's message that's the great example how error messages shouldn’t be made. Alas, not so rare example.

Two Rules of Optimization

Looking for something in the abyss of my GTalk history I found short fragment of conversation with my friend:

- But that’s the much less frequent scenario.
- Yep, but perfectly optimized.

That reminded me all of different optimization tasks which I was doing, supporting or heard about. Few success stories. Several with limited effects. A couple of spectacular failures. And when I analyze them I think there are two rules which differentiate those which had a chance from those which were doomed from the very beginning.

1. Check first. Check before you start changing any code do some test. Even when you’re almost sure where the problem is. Make some load tests. Add counters if needed. Hack through logs. And after several weeks come with confirmation of your initial idea. Or something completely different. You never know unless you check. Another benefit is that after all that hard work you’ll feel very well for a while: “Ha! Got you! You can’t run, you can’t hide. Now, you’re mine. It’s payback time. I’m going to optimize you!”

2. Start from the most frequent operations, not the longest ones. It really doesn’t matter that it lasts a quarter to prepare this incredibly complex report because it’s done once per year, and you can stand an accountant yelling with frustration as often. Better take care about this little function which is called twenty times per every darn second. If you can earn 10 milliseconds on its execution you’ll earn 1752 hours per year. 2 and half months of your users’ time. I guess it’s a bit better than 15 minutes on execution of the report. And yelling accountants are strongly overrated anyway.

I’d try those two another time when you hear “Hey, I’ve read that when we use application server in our architecture we’ll scale up much easier. Let’s do it!” And believe me, you can hear something like that faster than you think.

Gliffy Review

Some time ago I was moaning that I lack a web alternative for Visio. I was directed to Gliffy. I have to admit the way Gliffy authors have chosen is the one, which I believe is right. They’ve started small and they’re growing their product (little) step by (little) step.

Beta

First of all Gliffy is still in beta. I think that became some kind of standard in web applications. Well, we still have GMail in beta. How long has it been by now? It’s third year already. Coming back to the subject, I haven’t found major issues within basic functions of Gliffy. There are some in collaboration function, but I’ll share them later on. For a beta version I’d say it is fine.

Basic Functionality

Basic functionality is um… basic. There are limited set of predefined charts: flow chart, UML diagram, network diagram, user interface design and floor plan. If you try to make a bit more advanced diagram you’ll lack a lot of shapes. There are two functions to help you here: you can search the internet to find needed picture or you can upload it from your hard drive. I recommend the latter because results returned from the web search are rather irrelevant. With the help of your own pictures you can create quite appealing charts, although it requires more effort than using standard shapes.

Advanced Functionality

Like I’ve mentioned on the beginning Gliffy started small so you won’t find many advanced features. There are two however which are worth mentioning.

• History. Version history is stored on Gliffy servers and you have an easy access to them.

• Collaboration. The application is web-based so collaboration is a natural idea and fairly easy to develop. Charts are stored on Gliffy’s servers, users log in with their e-mails, chart owner sets permissions for other users, etc. Not a rocket science, right? Well, not a rocket science unless you want to deal with on-line changes displayed instantly and conflicts with saving a file on the server from multiple points. For now Gliffy covers only the easier part of the job and needs some improvements even there. After simultaneous file save from two consoles I’ve lost one of historical versions. I’ve faced some problems with accessing the shared file from account which was invited to participate (haven’t got the file on the list of my files). With this kind of issues with basic collaboration functionality I think we’ll wait some time for advanced features like seeing others’ changes instantly.

Look and Feel

One thing is how Gliffy itself looks and while it isn’t polished it’s OK. Workspace is designed to look like Visio so you don’t need to read help to know how to start. However I’d change graphic design of Gliffy. I don’t know why but it makes me feel like it wasn’t a professional tool.
Another thing is look and feel of charts produced by the application. I think the best comment would be two diagrams one from Gliffy and another from Visio.




Yes, you’re right. The ugly one is from Gliffy.

Usability

And for the end my favorite: usability. The user interface is too sensitive for mouse moves. You’ll often end up moving a shape instead of selecting it. Multiple undo works fine but where’s the heck redo? Setting connectors works almost the same as in Visio. And believe me, it isn’t a compliment. It’s not better or worse – it’s just crappy in a bit different way. Is that so hard to make it work intuitively? Group function doesn’t group all the selected controls – it has some problems with text labels. I think this is the area where on one hand Gliffy can rock because Visio doesn’t set the record very high, but on the other it would be a challenge for them, because a good web user interface is always harder to craft than it is in a classic client application. However the path Gliffy has chosen – writing the whole thing in flash – allows making it. I keep my finger crossed then.

To summarize, I think that for now Gliffy is on the good path but still far from their destination. They definitely chose the better option than Projity with Project-ON-Demand and don’t try to do everything Visio does. For now, the main issue is that I wouldn’t show standard Gliffy diagram to my customer. It just look like it was crafted by country artist, not like it was generated by professional chart tool. With your own uploaded graphics you can make it better, but then you’d have all shapes in one group and it would be much harder to work with Gliffy. On the plus side, the application has two main strengths: price (it’s free) and collaboration (alas some improvements are essential here). I’d consider Gliffy as a tool if I needed to create diagrams for internal use only. Unfortunately mixed mode with some Gliffy charts and some Visio diagrams isn’t an option here because there’s no import/export feature. I can guess why (it would by very difficult) but, from the user’s perspective, who cares?

Architecture Freeze

Some time ago I had an occasion to talk with my former colleagues from my previous company. They were talking how the team had changed, how the design and development processes had been altered. It was very insightful discussion for me. I learned that development team, which formerly worked under one manager, was split into two teams: one responsible just for architecture and tools and another working on functionality.

The architecture team have creative and clever guy as a boss, however he lacks experience in working on the software with business background, with real customers, real deadlines, real budgets etc. On the other side the functionality team have very experienced designer as a leader. Unfortunately he has no development background so he’s no partner in discussion for the architecture guy.

While I don’t say this kind of organization is generally bad, in this case, with these people, the split wasn’t the best idea. Architecture team ended up making constant, of course cool, improvements within base of code everyone else was using. In this case improvements sometimes meant complete redesign of major parts of architecture. Changes were implemented whenever architecture team was ready with them – in the middle of a new version development cycle for example. Yes, you’re right. That exactly means that functional guys had to rewrite big pieces of their code. A couple of times actually. Yes, you’re right. They weren’t happy with that. And yes, you’re right once again. It ended up with silent conflict between architecture and functionality groups.

I’m no longer the part of the team and I know the story in the way it was told me, although I was talking with people from both teams, so I guess I’m not very biased. However the idea of rewriting (oh, actually improving) architecture during every single version sounds for me hm... let’s say unreasonable. Approval for implementation this kind of things sounds even more... unreasonable.

OK, there is time for working on architecture. You should exploit it learning, brainstorming, prototyping, testing, verifying etc. You can start form a scratch again and again when you reach a dead-end, as far as you still have a time for that. That’s perfectly OK. It’s showtime for architecture guys. But then the architecture should be frozen. I know it isn’t perfect. That’s as clear as a day. But I know it won’t ever be perfect. That’s even clearer. Architecture freeze is essential when you start building functionality. It’s essential when you develop your application iteratively. While building a house you just don’t change you foundation when the walls are ready and you’re working on the roof of the building, right? So is with the software.

I don’t say you can’t touch the architecture. Some slight changes can be done, but you have to remember that walls are already there and one false move can ruin whole construction. Unless you have a lot of time and money to rebuild the whole thing (I envy you then), be careful

Design Decisions: Tips

When we were looking at statistics trying to figure out the way Overto’s users are interacting with the service we ended with conclusion that people doesn’t use advanced features. Especially subscriptions, which allow getting information into the mailbox, remained fairly unused.

OK, maybe our users don’t know about subscriptions then? FAQ and About us page aren’t definitely must-read articles for a vast majority of web users. The only other way they could learn about the feature was to accidentally click on the button. We needed to help our users with finding out how cool features we have. We already had the FAQ no one read, but needed something more.


That’s how tips were born. We decided to add on our standard page design a line where short sentences can be displayed. Its first function was to share some knowledge about service, telling about features we think are cool, inviting users to register etc. Soon after first prototype of “tips” functionality was deployed we found out that we can also publish there maintenance messages, ask about filling some survey and so on. With really simple style modifications (colors, font size, links) we can easily make special messages to be better exposed.


Quite often the best ideas are those, which are easiest to implement.

However, after some time with tips working on site, I came to the point where I think they’re invisible for users. That’s another thing to solve and another story to write.