The Great Escape

Imagine this. You are in a foreign country where you don't really speak the language and are walking down a street. On this street there are many shops to choose from though you can't really understand the name of the shop or what each one sells. Maybe you are on this street for the first time and are feeling a little adventurous so you decide to go into one that you think might be interesting. You open the door and are surprised to see that it sells "widgets". You are not interested in widgets. In fact, you find them slightly mysterious and are afraid of them in general. What do you do?

Most likely you would turn around and walk out the door. Now imagine that you turn around and the door you just came in is gone. You have no choice but to progress forward through the "widget" jungle hoping that you don't hurt yourself or someone else in the process of trying to find the exit. Finally you find your way out and head up the street.

This isn't a totally unrealistic scenario in the real world. I have been in some stores where you walk in the font door and are force through what seems to be a maze in order to find your cheese... I mean exit. For some reason, it always seemed to be office supply stores that were set up like this. I haven't been in this kind of store in quite some time perhaps because someone realized that users...I mean shoppers, don't like to feel trapped or not in control of what they do next.

Users of software are no different. They like to feel safe while using an application. They also like to feel like they can explore it without "hurting themselves". Giving the user an escape route in the form of a "cancel" button reassures them that it is ok to go through the next door and that they can always turn around and come right back through it if they desire.

Taking away that feeling of safety on one screen can have dramatic effects on the way they use every screen going forward.

One other thing to keep in mind is you need to make the escape act consistently on all screens. Don't make it take you back one step in some cases and take you back to the beginning in other cases. Once you make that mistake the cancel button starts to seem like a roulette wheel in which the user will have no confidence.

The AJAX vs Flex fight continues

Over at Schematic, there is a wonderful summarization how Forrester missed the mark when comparing AJAX and Flex. I won't bother summarizing it here. You should read it for yourself.

As a designer/developer having built large scale Enterprise web applications using both AJAX and Flex, I have to stand up and whole-heartedly agree with Schematic. I guess the folks over at Forrester have never actually built an AJAX application and had to deal with browser compatibility issues, memory leaks and the obvious sub-optimal UI you end up with in the end.

While much of the Forrester report seems to be incorrect, I have to disagree most with the statement that AJAX is faster to develop and easier to learn. I have had the opportunity to build the same application as both an AJAX and a Flex application and I can say without a doubt that the Flex version took about 40% less time to develop, has a much better UI and works seamlessly on multiple browsers and platforms. When we made the decision to build it in Flex we had very little experience with Flex as most of our previous applications were all AJAX. Yet, it was still faster to develop in Flex.

In my opinion, if you are building or rebuilding a new application, as opposed to enhancing an existing one, Flex or Silverlight are the obvious choices. OpenLaszlo is out there too, though I have not seen a compelling reason to choose it over the now OpenSource Flex. Now, before someone comments with "OpenLaszlo can generate DHTML" let me say, that generating DHTML seems to be something like Un-alchemy where you turn Gold into Lead. While Silverlight looks promising, Flex is a few laps ahead in the RIA race.

Dragging and dropping from a tree in Flex

This might be common knowledge to some but it took me a bit to figure this out. Suppose you have a tree of items such as a hierarchical list of folders and you want to enable the user to drag an item out of the tree onto a trashcan.

Here is a snippet of the code:

<mx:Tree x="10" top="10" bottom="75" width="200" id="tree"
 labelField="name" dragEnabled="true"/>

<local:TrashCan id="trash" dragdrop="deleteItem(event)"
 dragenter="doDragEnter(event)"/>

...

<mx:Script>
private function doDragEnter(event:DragEvent):void {
 var dragInitiator:TrashCan=TrashCan(event.currentTarget);
 DragManager.acceptDragDrop(dragInitiator);
}

private function deleteItem(event:DragEvent) : void {
 //do the actual delete here.
}
</mx:Script>

When you run this code everything works except you get an error. The problem was that the default behavior when dragging from a tree expects that you are dropping the item into a tree, either the same tree or a different one. Since my TrashCan was not a subclass of Tree the error was being thrown.

The simple solution is to tell the tree to skip the default behavior. The way you do it is to add dragComplete="event.preventDefault()" to the Tree.

The Psychology of Color

So I found myself in the hospital last night/this morning. And as all the nurses came in and out over the course of the evening I noticed that all had blue scrubs on. No surprise there really, until early this morning when one came in wearing scrubs with a orange patterned shirt. Immediately, I assumed that she was a "head" nurse or in some way more important that the others. Was she? I have no idea.

The point is there are times when we differentiate something with color intentionally, such as marking a value in a report red if it is negative. Most people know that difference in color is easily noticeable. For those book-smart types this would be known as a pre-attentive variable. Others are shape, texture, size and orientation. However, often times you see things in applications, on websites and in printed materials (or in Emergency Rooms) that may seem more important unintentionally.

So be careful when you choose colors for elements of your interface. We want users to think the important things are important; not the ones that happened to wear orange that day.

Never be surprised by the way users actually use your app

This post from rhjr.net is a great example of the way users actually think. So don't be surprised when a user enters an email address where you were expecting a web address.

Pownce invitations

So I got invited to join Pownce and got the opportunity to invite a few people. It is a pretty cool AIR app. I used a couple but have 4 more that I am willing to share. Post a comment and it is yours... It will prove that this whole blogging thing is worthwhile and there is actually someone reading it.