Tuesday, November 20, 2007

Flex Builder 3 Pricing Confusion

I don’t think I am the only one confused by the pricing structure of Flex Builder 2/3. So, here is how I understand it. Please, correct me if I am wrong here.

Here are the options for those who don’t already own Flex Builder 2 licenses but want Flex Builder 3 Professional:


  1. Buy Flex Builder 2 now for $249 with the additional $99 maintenance which will allow you to get the free upgrade to Flex Builder 3 Standard. At which time, you would need to upgrade to Flex Builder 3 Professional. The cost for that upgrade doesn’t seem to be listed anywhere
  2. Buy Flex Builder 2 with Charting now for $699 with the additional $299 maintenance which would allow the free upgrade to Flex Builder 3 Professional

If you already own Flex Builder 2, I am totally unclear of what the upgrade path is. Can I just buy maintenance? Or is there some other upgrade for pre-existing licenses?

What about teams of developers that are using Flex Builder 3 Professional but have a separate build machine for production builds? Do you need a separate license for that in order to use the Data Visualization stuff? I haven't seen this mentioned anywhere.

I really think that Adobe has dropped the ball here on this. It is not a great user experience when you have a product that plenty of people want to buy, but your customers aren’t sure how to go about the best way to get it.

Please comment, I am just as confused as everyone else.

Monday, November 12, 2007

Worst UI Ever? - Date Entry

Those of you who have read my other "Worst UI Ever" posts may recognize that this one comes from the same application as my last post on the topic. I don't mean to pick on this one application. Its just that I use it so frequently that I notice these problems.




Here's a screen shot of what happens when you try to submit an expense report with dates entered in the "wrong" format. Why's "wrong" in quotes? The real questions is "wrong to who?" From a system perspective, a developer would likely thing that all dates should be entered in a particular format. Sounds familiar? The reality is though, that the "right" format for date entry is the one that the user things is correct. If I, for example, live in the US then I might be used to something like 11/12/2007. However in another part of the world I might use 12/11/2007. So how should any system handle this since both of those could be interpreted as valid dates, albeit incorrect ones. If the system doesn't know what format the user wants to use then it is ambiguous.

Just Getting Picky
So what is a designer or developer to do? Enter the "Date Picker" control. This little gem has been the solution to this problem for quite a while. So no more problems with date formats because now you don't enter one at all, you simply "pick" one. If you are reading some sarcasm in the tone of this, you are not imagining it.

The date picker control is a handy little calendar that pops up when you try to enter a date into an input. The calendar, usually defaults to the current month. It has to default to something, so why not? The problem is that thought really needs to be put into the use of these things. Imagine for a moment that you are entering your birthdate and the calendar defaults to this month. Unless you were "born yesterday" this will probably cause a lot of extra navigation to enter the date that is really on the tip of your tounge, or fingers. If only you could just type it in.

Does it ever make sense to use a date picker? Of course. For example, in a scheduling application where people might be interested in setting up a meeting for next thursday, it might be nice to allow the user to choose that date rather than enter it. The difference is in how the user thinks of the particular date in mind. If the user thinks "I was born on February 1, 1970" then that is different than a user thinking "Two weeks from this past monday". This difference in mental model, should drive a difference in the UI.

So we have dispensed with the date picker for the application in question. Luckily, the application actually allows date entry as well as date picking. However, in the screenshot, the date entry is what caused my "error". The problem is really that the application doesn't do a good job of accepting the format I intended to enter. It also doesn't even do a good job of telling me what format it expects. If you look in the screenshot, it is displayed as a TIP. Now to me, a tip would be something helpful but not crucial to me using the application. It turns out that the format really was crucial given that my mistake lead to 4 separate error messages indicating that the format was incorrect, without once suggesting the format it expected.

The one thing this application does do well is when it gives you the suggested format, it shows you today's date. I have seen many applications which do something like this "(MM/DD/YYYY)" This format is very familiar to developers but would all your typical users understand this. I have even seen some that say "DD-MON-YYYY". Clearly the MON means moth, but why should users have to decode that. Showing "05-Nov-2007" (It was November 5th when I captured the screen) is much better since the context of the date is at least in the user's frame of mind. Most people at least know what month and year they are currently in.

The Bottom Line

  • If at all possible let the user enter the date in the format they want
  • If you can't, give the user a clear indication of the expected format using the current date as the example
  • Use date pickers for dates that user's don't know by date such as "next tuesday"
  • Don't tell the user they made an error if the software can't figure out what they meant. It is never a good idea to tell the user that what they enterd as "11/05/2007" is an "invalid" date when it obviously is.

Thursday, November 1, 2007

Comic Relief for Designers

This is apparently the week of "I normally don't do this but...". However, I had to pass this along since it is so funny. Every designer out there, whether print or web, will be able to relate to this video. If you aren't a designer then this might not seem funny at all to you... which is why it IS funny to us.

It is rather ironic that the company that put this out there (I think anyway) , Agency Fusion, is a development company not a design company.