Flexbuilder 3 Beta 3 upgrade issues

Yesterday I downloaded and installed the new beta of Flexbuilder 3 and I ran into a couple of problems. Now before anyone starts to think that this is a Flexbuilder 3 Beta 3 complaint, it isn’t. The problems I had were easily fixed by following the instructions in the release notes. For anyone interested, the problems I had were caused by reusing a workspace from Beta 2 in Beta 3. As the release notes indicate, you need to force Flexbuilder to reinitialize the workspace. The instructions are clearly specified.

I like many users don’t like to “read the manual” so I immediately went in search of an answer on the web. So, I figured I would save someone the trouble by posting specifically about it.

Worst UI Ever? - Links

First of all, let me say that I love Ebay. How else would I be able to sell my extra Hannah Montana tickets? However, occassionally I find myself asking "huh?" Take this list of links for example:

What do you think the difference between Seller's Guide, Seller Central and Seller Tools is? I clicked on each of them looking for information about the Buy it Now option. I couldn't find any information on any of the resulting pages easily. Eventually I found my way back to the Seller's Guide, which is apparently the code name for Seller's Help, and found it by searching. The first time I was on the Seller's Guide page, I completely overlooked the search box since I had just done a search on the previous screen in the main search box which apparently only searches items. When searching for Buy it Now, I received, as you might expect, over 2000 products.

Here's the problem. The links all sound like the same thing based on their names. They could be slightly improved by adding tooltips assuming it is possible to articulate the difference in 3 to 10 words. To add to the problem, even after visiting those pages, I am still not sure what the difference between Seller Central and Seller Tools is.

The bottom line is that when you decide to add one more link to a menu, it is important to make sure it makes sense in the context off all the other links. All by themselves, each would make perfect sense, but when put together the problem becomes apparent.

Required reading for RIA designers and product owners

With the holiday season usually comes less time and more work. Funny how that works. In the little spare time I have left, I stumbled upon what I think is a must read for anyone working on RIAs. I found Magic Ink - Information Software and the Graphical Interface to be full of useful information for both designers and product owners. One of the biggest challenges for UI designers, especially living in the Agile world, is convincing the rest of the team that slowing down and really "designing" the interface is valuable and in fact necessary for success.

The author makes numerous references to the work of Edward Tufte but also extends some of the concepts of Tufte by illustrating how and why the techniques he suggests can work in an interactive medium such as RIAs.

While the RIA technology described is not Flex or Silverlight, I think those two technologies are likely to be the most common platform for RIA development. So while reading Magic Ink, don't get hung up on the fact that the applications mentioned are HTML or desktop widgets. The concepts apply to any and all RIA platforms.

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.

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.

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.

Is Flex just a Fancy-Pants technology?

I had to comment on this entry. I usually don't post comments on other peoples blogs on my own blog, but this is worth getting into here.

The point he makes about building the user interface with the end user as the sole focus is absolutely true. I don't design a UI that is intended to just be sexy or flashy. The trick is, there are times when things that seem like they just add visual flash to an application do add value in terms of supporting user goals. For example, it might seem like it isn't important to animate a menu opening. However, the value is that that transition from closed state to open state serves to show the user how they got from point A to point B. It is the same as if you are riding in a car and close your eyes for a portion of the trip. When you open them,there is a period of "where the hell am I?" even if you recognize where you are after only a few seconds. Seeing how you got somewhere makes it easier to understand how to get back here the next time you need to as well as how to get back home.

If you have ever used a Mac you surely have noticed that minizing a window animates its transition to the dock. Just visual flash? Not really. If you have ever accidentally minimized a window, it would be obvious where it went because you see it go there.

This is a minor example. You get much more value from what seems to be visual flash if the task at hand is more complicated as long as that "flash" was added solely to support a user goal. The fact that he mentions AJAX or Flex as "Fancy-pants" really shows that the author doesn't entirely understand the value of Interaction Design. Perhaps his focus is on the HCM space, but that doesn't make you an expert on the best way to meet user goals. Suggesting that all applications should run inside Office or Google is rather silly. That is like saying that your toaster should make ice. Software is built hopefully to support user goals. Bolting on functions to support unrelated goals complicates the interaction for its original purpose and certainly doesn't give you the ability to focus solely on the new function's purpose. You automatically box yourself into a framework that isn't necessary. Also, chances are, users know how to use their web browser more than Office, so why not use a technology that is easiest to use by the target audience.

Not to long ago, it would have been easy to say "why do we need to invest in the fancy pants computer to do our HR tasks, why don't we just use paper since people use it everyday?"

Klok reaches 2000 downloads

Thanks to everyone who has downloaded and tried Klok. I have been getting a lot of positive feedback, feature requests and, of course, a few bug reports. I expect to be posting a new version in the next week with some new features and some fixed bugs.

I am also currently working on an updated look and feel. However, let me pose this question. Do you like the mostly black color scheme? Drop me a comment and let me know.

Success is just a phone call away

Well sort of. Here is an approach that has worked for me on numerous occasions. To set the stage lets imagine that you are building some new application and it is nothing like any other you have seen. So clear your mind of any preconceived notions of how users will interact with it.

So how do you know what your interface should act like? The technique that I have found to work is appropriate whether you have real users to work with or not.

Step 1: Determining Goals
The first step is to try to identify what goals the user will have when using your software. Usually this is partly determined by business folks, since they are the ones who came up with the idea for this thing. This would also come from real users if you have them. This can also be assumed if you happen to be building an application that is supposed to replace an offline, or paper, process. For our simple example, we will have a single goal. The subject is trying to find a person from an employee directory.

So that part is not where the phone comes in. That comes in step 2.

Step 2: The phone
If you have real users to test, you can use this technique with them. If not you can use this technique yourself or with others on your team. This involves a bit of role-playing however, you can make it seem less silly by the way you present it. You start by having one of the "test subjects" imagine that they have a set of goals that they want to accomplish but instead of having the application in front of them, they have a phone. With that phone they can call an expert user of the software and tell her what to do.

The idea here is to allow the user to forget about the software and focus on the human way in which they are accustomed to interacting. What you will find is people treat a human and expect to be treated by that human very differently. You will find that users typically think in non-linear terms meaning that you need to support unexpected task flows. You will also find, assuming you can do this test with multiple subjects, that patterns arise. These patterns can help you build your interface to meet human needs.

For example, lets say we are building a search interface to enable users to find other employees in their organization. You may be tempted to create a search form with first name, last name and employee id fields. The results screen shows a table of results with a back to search link. What you will find with this test is that users don't necessarily think in discreet properties. They might say, over the phone, "Search for John Doe". What that might translate to is you would have a search field where you type in the user's whole name. They might say "Search for John something that starts with D". That same single field will work if you allow it to support entry of "John D"

Continuing on with the approach, the expert user on the other end might say "There are 200 John Does". The subject might then say "I know he works in the Foo Department". So your search results page should allow further refinement. The user would not likely say "Ok start over and search for John Doe in the Foo department" meaning that your interface should not force the user to start over either.

Imagine for example that instead of returning 200 John Does, the voice said "No John Does were found". The subject might say, well I know if is "something Doe". Your interface, might provide a mechanism on the search results page offering to look for all Johns or all Does in the event that the no results were found.

This technique can be very successful as along as you keep the user on track. Don't let them start to say things like "Click on the button..." or "Go back to the previous screen". If they do, then they are thinking about an imaginary version of the application. This happens frequently when you are trying to redesign an application that users are familiar with. This also happens when doing this test on product owners. They typically have a "vision" of what the product should look like. In reality though, they only concern themselves with the problems you are trying to solve and the goals of the end users.

Klok update - bug fixes and enhancements

Klok has been updated to run on the latest version of the AIR runtime. If you are using the previous version of Klok, it is recommended that you upgrade to the latest version of AIR and the latest version of Klok.

This version of Klok includes fixes for bugs that have been reported. Most importantly, when adding a time entry from the Project View > Time Entries tab, the date and time entered will be respected, rather than always defaulting to the current time. Also, entries made from this screen will immediately show up when you switch back to week view. Previously, you had to switch weeks and come back before it would show up.

Also, some noted that navigating forward and back week by week was a bit painful, so I added a calendar below the project tree. When you click on any day, that week will be shown in the week view.

Whats next?
Check back soon for an updated interface, an online demo version, ability to load different data files, server-based central repository demo and more bug fixes.

UPDATE
If you used the installer to the right and got errors, it should now be fixed. I forgot to update the badge installer to specify the Beta 2 version of the runtime.

Klok to be shown at MAX?

I got an email from Adobe saying that Klok may be shown in Kevin Lynch's keynote tomorrow at MAX along with a bunch of other AIR applications. Having been to numerous conferences, and seeing first hand how time is always short, I wouldn't be surprised if all the apps they intend to show don't fit. However, it is nice to be included in the list of possible applications anyway.

Unfortunately, I couldn't make it this year. However, if you are at MAX and see Klok, drop me a comment and let me know how it went.

Do you really need an Interaction Designer?

There is an idea in the Agile world that the most effective software teams are those made up of generalists. From a development perspective I have found this to be, for the most part, true. However, in most of the places where people make the argument for generalists you never hear any mention of the UI. If you are wondering why that is, so am I. In many cases the design of an application is considered to be a technical problem. "Should we use AJAX or Flash?", "How do we hook that front end up to the data?", "How will it perform?", "How easy is the technology to work with?", "Do we (developers) have the skills with this technology?". These types of questions all have a crucial problem. They are all developer focused questions. None of the questions above even remotely consider the end user... those are the people that USE your software, not necessarily the ones that BUY your software.

Things fall apart here because UI is not a technical problem. If you think in technical terms you get a technical solution that works well for technical users. For example, if you ask most developers how to build an app that allows users to manage their timesheet, you are like to get something like this.

A database to store entries for each users.
A screen with a grid on it where users enter hours for each task for each day.

How to build a better Time Tracking application
The problem here is that we got what we asked for. A screen that looks like the developers version of a timesheet. An Interaction Designer may have come up with something different. Why? Because instead of focusing solely on the task of entering time into a database, they would focus on what the user really needs in order to track time. Thinking "outside the db" allows us to investigate how to best meet user goals. In this case, you may find that many people enter all their time at the end of the week. They may keep track on paper the hours spent and translate that into the application on Friday, or occasionally on Monday morning. A more efficient approach would allow the user to bypass the paper step and replace the whole process with something that meets their goals better. We may find that users write down the time they start a task and then when they are done write down the end time. We may also find that an equal number of people write things down at the end of the day. I bet that we would not find many users that log into their online timesheet and enter time spent on each task immediately after completing it. Even worse some users probable don't keep track at all and just make an education guess at the end of the week.

Realizing that the goal is not to "enter" time, but rather to "track" time makes a big difference. Building an application that allows the user to indicate that "I am about to start on task X" and when done say "I am done for now with task X and I am now starting on task Y" removes the added step of tracking time and then entering time into their timesheet. Building in a way for a user to say, "I was out of the office yesterday working in my hotel room, but I worked on X for 2 hours" would also add tremendous value. Using the same application offline allows the user not need to know or care about the technical difference between being "on the network" and "off the network". Have it sync up automatically when the user gets back on the network and you will really have a seemless experience to the user.

So how do we justify the need for an Interaction Designer?
Usually people who make decisions want to see how their decision affects the bottom line. The value of a well-though user experience can be quantified. Imagine you plan to sell you timetracking software to large organizations of say, 50,000 employees. Every week each employee needs to track their time. If you can reduce the time it takes to track time by 15 minutes. 15 minutes x 50000 employees x 52 weeks = 39,000,000 minutes (650,000 hours) per year savings. How much does that cost the organization a year? Even if you only made it 2 minutes faster, you would have a big savings. This isn't even considering what I call the "Extended Cost of Confusion". Extended Cost of Confusion can be more difficult to track however we probably see it every day. You try to use some application and can't figure some function out so you ask the colleague sitting next to you. Best case, she spends 5 minutes showing you how to do it. Worst case she spends even more time trying to figure it out, can't either and now you are both stuck and have spent valuable time. Add on top of that, the cost of calling the help desk or customer support and it can really add up quickly.

But what about the generalist? Can't they learn how to create better experiences?Maybe, but do they want to? And will they ever be as proficient as the person who won't, in the back of there mind, be concerned about how difficult it will be to implement.

For an analogy, think about going to your primary care doctor who is analogous to a generalist. Say, for example, you have suddenly gone blind in one eye. Who do you want to take care of you? The generalist? or an Opthamologist?

Here's another example. Imagine you want to re-design the interior of your house and make something very peaceful and serene. You a contractor to come in and replace some windows, install bamboo floors and paint your walls. Do you want this same person picking out the fabric for your sofa?

But an Interaction Designer will cost money and take timeYes. He/She will. However, what is the cost in dollars and time of building your product and finding out that it doesn't meet the needs of the people using it? What does it cost to rebuild an application? Will you get it right the second time?

Obviously not every product has the same need for Interaction Design. However, almost all products have SOME need for it. If your product is going to be used by humans, make sure it is designed for them to use from the beginning.

So, do you really need an Interaction Designer? What do you think?

Recommended reading: Can programmers do Interaction Design?

Flash Player - over 93% penetration

I am usually not one to just repost the same information that others are posting on their blogs. However, I will make an exception in this case, because this information is THAT important. 93.3% of users in mature markets can currently view your Flex 2 or Flex 3 applications. That is huge. A year ago, I repeat just one year ago, this number was at something like 50%.

I am also no usually one to bash Microsoft and/or Silverlight, but I will be surprised if they get to 90% in the next 5 years.

UI Design using an "Agile" approach

This is an interesting article discussing how an Agile process can be applied to UI design. One thing to note about what is described is that the whole Agile process, 3 week iterations, daily meetings, etc., is done for the interaction design phase prior to hading something over to development. This is an approach that I have found works well. The thing everyone must remember is that, like in development, you must be willing to "course-correct" as necessary as requirements become more clear or outright change.

This is posted on Alan Cooper's firm's site. No surprise that they know what they are doing. For anyone interested in Alan Cooper's approach, I highly recommend reading About Face 3 - The Essentials of Interaction Design.

Klok gets its own website

For those of you interested in Klok, you can find more information about its use by visiting the official Klok website at http://klok.mcgraphix.com/. The site has some updated screenshots and some instructions regarding its use. Coming soon will be an online trial version of Klok and a way to submit bugs and feature requests. For now though, you can email me directly or post comments on this blog.

Let me know what you think of the site.

Flex Bug? Confirmed

A little while ago I posted about a weird Flex bug. I believe I have solved the problem and confirmed it is in fact a bug. A little more information about the problem is probably necessary. The way my app is set up, I have a Module that I used to load in all the translations for a handful of languages. Each of those languages' set of translations is in its own properties file. I create all the variables like so:

[ResourceBundle("application")]
private var rb:ResourceBundle;


[ResourceBundle("application_de")]
private var rb_de:ResourceBundle;


[ResourceBundle("application_es")]
private var rb_es:ResourceBundle;


[ResourceBundle("application_fr_CA")]
private var rb_fr_CA:ResourceBundle;


[ResourceBundle("application_fr")]
private var rb_fr:ResourceBundle;

I stick all this into a static class so I can do something like Translations.get("myKey");

In my last post I discovered that the rb_fr variable was null. And if I switch the order of the rb_fr and the rb_fr_CA definitions in my code, then the rb_fr_CA variable would be null. I initially thought it had something to do with the naming. Possible related to the underscore character. After pulling my hair out I discovered that it isn't that. In fact which ever one is defined last is null. So if I add another one to the end it will be null and all previous ones work. The strangest part of all this is that if I do the same thing direction in my Application instead of in a Module, the problem doesn't seem to exist.

In the end all this probably is a moot point since Flex 3 will give us the ability to do runtime locale changes, which is really what I was trying to accomplish. I really didn't want to have to compile my application 5 times; once for each locale.

Flex Bug?

I came across some strange behavior in Flex 2 today. I think this is a bug, but if someone has any insight feel free to comment. The issue is, I am trying to inject two resource bundles into my application. One for the fr locale and another for the fr_CA locale. So I have two files called application_fr.properties and application_fr_CA.properties. When I use the following code I see that whichever one is second in the source code ends up being null. I have many other resource bundles for other locales that work, so I know I can have more than one. It seems though that something to do with the name of the .properties file is causing a problem.


[ResourceBundle("application_fr_CA")] private var rb_fr_CA:ResourceBundle;

[ResourceBundle("application_fr")] private var rb_fr:ResourceBundle;


In this case:
rb_fr == null; returns true
rb_fr_CA == null; returns false

If I change my code to:


[ResourceBundle("application_fr")] private var rb_fr:ResourceBundle;

[ResourceBundle("application_fr_CA")] private var rb_fr_CA:ResourceBundle;


In this case:
rb_fr == null; returns false
rb_fr_CA == null; returns true.

Anyone know what the deal is here?

Klok: 600 downloads and climbing - future plans.

Despite not winning the AIR Developer Derby (at least, I assume I didn't since I didn't hear otherwise), Klok has been downloaded over 600 times since August. I don't know if that is a lot by the standards of other AIR apps, but to me it is a big deal. So I figured I would take this opportunity to thank everyone for checking it out and talk about what is coming up in future versions of Klok.

Next week Klok will get its own home page where you can download updates, get documentation, report bugs and request features. Stay tuned for the URL. I will probably still post information about it here so keep this blog bookmarked.

I have mentioned earlier that more reports are coming. To be more specific, the ability to report on any week or month will be in the next update. Also coming soon, but probably not in the next update will be "drillable" reports. Right now, they show high level roll-ups of time spent on a top level project. Drillable reports will allow you to see the breakdown of each project.

So far everything I have talked about will be in the free download of Klok. However, there has been some interest in a small business version which would allow a firm to set up projects for all employees to track time against. This would give someone the ability to see time spent on projects across a whole team.

More information will be available soon as to how it will work but my thoughts as of now are this. An administrator would create projects and possible tasks. All users of klok would be able to connect to the server and keep there local version in sync. When users add time, the data will still be tracked locally so that people can work offline. At the end of the week, for example, users would connect and submit their time to the server. Then that information could be viewed by higher-ups for use in paying employees or billing customers.

The deployment details are still in the works. This may be a hosted service available for a monthly fee or be available for sale to be deployed on someone's own network. Most likely this will be a J2EE app but that may change.

To me this is the type of app that AIR was meant for. Occasionally connected with all the power of the desktop with the rapid development of a web-app.

Let me know if this is something you would be interested in using or testing when it is ready.

Is Klok an AIR Derby contender?

I am curious whether the folks who have installed Klok (429 of you) think that it could win me a new Mac. I have seen a lot of folks talking about the applications they have entered but I haven't seen many that seem like they would have gone in the Business Application category (which is where I entered Klok)

Let me know what you think...though I guess we will find out tomorrow.

Worst UI Ever? - Error Messages

Here is another one for the Worst UI Ever series. This is from an application for a a very big software company's time tracking application. These kinds of things are part of the reason I developed Klok. You get this message when you select a project for your timesheet, but don't enter all any timefor that line item. To me, this doesn't even seem like an error. The system can easily ignore line items that have no hours.

At first glance, the message has to be one of the most confusing I have ever read. Click to enlarge it.

"You have entered time information without associating any time with that information. Enter time for this information, or remove it"...ummm....huh?

If you read it a couple of times, it makes sense. But you have to make an assumption about what "information" means. The user shouldn't have to assume or guess anything. If that this is an error that the system can't handle, would it have been impossible to say "You have not entered any time for Project X. Enter your hours or remove Project X from your timesheet". They even could have made "remove Project X" a link making it simpler for the user.

I find these types of issues all over the place. Usually they are due to laziness of the designers/developers or lack of commitment to the end user by companies in general. To a product owner this might not seem like a big deal. However, imagine a user getting this error the first time they use your software. What kind of first impression is that?

The number one thing to remember is that software is supposed to help people do what they need to do. It isn't meant to help computers do what they need to do.

Open Letter to Mark James: Thank You!

I would bet that every person reading this has been exposed to the work of Mark James. If you have used any web based application you are likely to have seen his Silk icon set. Not only are these very well designed icons, but they are actually free to use. I have used them myself in Klok and many other applications I have worked on.

As I download and try out many of the apps entered in the AIR Developer Derby I can't help but notice them used all over the place. On behalf of all the developers, and designers, who don't have the time or skill to create our own icons... Thanks.

Klok update for AIR Developer Derby

I just posted an update to Klok with the final updates for the AIR Developer Derby This update includes a bunch of new features. Some of which are:

• Ability to zoom in on the calendar view
• Browsable trash with the ability to restore items from the trash. However, the trash is not persisted when you close the app. Does anyone think it should?
• Recent projects dropdown in collapsed mode for easy switching between tasks.
• Project templates - Choose from predefined templates for different project types
• Ability to store contact information per project
• Snap to 15 minute intervals when dragging items on the calendar by holding down the shift key. Previously, this was not optional. Now it snaps to the minute unless the shift key is held down while dragging.

It also includes some minor bug fixes.

Download it now using the badge to the right or by download the .AIR file directly

Coming soon... some more documentation and some additional features.

Worst UI Ever? - Validation errors

Here's a little comic relief for you. First of all let me say, I didn't make this up. This is a screenshot from the website of a big, well-established company's website. I won't reveal the name of the site in order to protect the innocent.

This started out as a typical registration form. The label (Name, Address, etc) was inside the input box which conserved space . When you focus on the field, the label disappears so you can enter your value. However it didn't specify which fields were required. So, since I don't like registering, I just tabbed through all the fields without filling out anything. This is what it showed.

Nice. Now I know that all the fields are required... Now what goes in each field again? The worst part, refreshing the screen doesn't bring the labels back. Nor does submitting it. Now in the site's creators defense, after a little refreshing and clicking in and out of the fields, I was able to get it to show the labels again. But would most users?

Do your users a favor and don't do this.

Klok, formerly known as TimeTracker

My timetracker application is now known as Klok. With the new name comes some new features, bug fixes and an updated UI.

The new features include a collapsed view allowing you to tuck it away in the corner where you can see what task you are currently working on and how long you have been working on it.

For bug fixes there were a few minor ones. The most significant caused a problem when you dragged the end time and dropped it before the start time it would cause some weird issues. Now, if you do this it knows enough to swap the times so that the earlier time becomes the start time.

Download it and give it a try. Please feel free to comment on the name, icon, ui, etc.

AIR Crashing problem solved

In an earlier post someone had commented that my TimeTracker application was crashing. I posted a comment pointing to a thread talking about similar issues with transparent AIR apps which seemed to either be related to video cards and/or the MS intellipoint mouse driver. I assumed that it was more likely caused by my dual monitor setup rather than the mouse driver because I didn't have an MS mouse. However, after some frustration trying to run the San Dimas app, I decided to do some digging. I found that I did have the Intillipoint drivers installed (somehow) even though I didn't have an MS mouse. After un-installing the driver all the transparent AIR apps started working.

TimeTracker: Take 4

I set the mime type up on my server so this should now be working. For anyone else who runs into this, Mike Chambers posted this a while back.

Thoughts from the onAIR Bus Tour

Wow! I have to say that the creative energy that was in the room was contagious. You couldn't help but get excited about all the things that AIR makes possible. The demos, even the brief Buzzword demo from Ryan, were amazing.

As a UI person, the thing that puts these AIR apps above many other apps is the commitment that their creators have made to the user experience. You definitely get the sense that serious thought was put into how their target users work. Does it mean that they weren't doing Agile? Not necessarily. Given the speed at which many of these apps were built, one might say that it couldn't be done without Agile. I don't have the answer. Perhaps someone who worked on Buzzword, Pownce, Finetune, TwitterCamp (Daniel did you design the UI too?) can post a comment and give us a clue how the UI design fit into your process.

Thanks to all those who gave me feedback on my TimeTracker. I will be incorporating many of the suggestions in coming versions.

TimeTracker: Take 3

Apparently the problem has to do with my web server not serving .AIR files correctly. For now you can download the .AIR file inside a zip file. You will have extract the .AIR before launching it.

TimeTracker alpha - take 2

There seems to have been a problem with the badge installer. Thats what I get for putting it out there in such a sleep deprived state. I have never tried the AIR badge installer before. Since I am not totally confident in it, here is the link directly to the .AIR file.

TimeTracker alpha

Anyone interested it testing out my TimeTracker application can download it from here. If you find bugs or would like to request a feature, add a comment to this post.

UPDATE: Klok (formerly TimeTracker) is now up to version 2. You can install the free version using the installer to the right or by visiting the official Klok website

Going out to get some AIR

I just cleared my schedule enough to attend the onAIR bus tour stop in Boston tomorrow. I will be the one jumping up and down like a kid at Disney World. Feel free to say hi.

TimeTracker testers needed

So I have blogged a couple of times about my TimeTracker (to be named something cool later). It is still being developed however, if anyone is interested in testing the pre-alpha version and point out the bugs that I have missed or suggest features, I would appreciate it. If you are interested, leave me a comment with some way of contacting you. An will post the .AIR file for download.

AgileUI now on MXNA

I just got word that my blog is now being aggregated by MXNA. Hopefully it will be found in the AIR and Flex categories. If you found your way here by way of MXNA, drop me a comment and let me know.

TimeTracker sneak peek with screenshots

In my last post, I mentioned the time tracking application I have been working on. Today is the first in a series of posts with more details.

To set the stage, let me just say that as someone who works for himself you would expect me to me diligent about tracking time spent on each and every task I work on. After all time spent == dollars made. Unfortunately, my right brain gets in the way and complains at all costs about having to stop what I am doing to track the time I spend. So, I set out to create a tool that would allow me to easily track my time with the least amount of effort.

My requirements were basically this:

• Standalone app not needing to be connected to the internet - After all, I can't always connect to the internet when I am working in a booth at Wendy's
• Ability to work on multiple projects, each having a varying number of sub tasks.
• A visual way to specify how my time is spent - Dragging a task onto a calendar for example.
• A way to report on time spent, monthly, weekly or overall
• Ability to export a spreadsheet (Excel) for use by others - The person creating the invoices for example
• A simple way to switch between tasks

So out of the gate I wanted to use Flex. However, when I first conceived of this app, AIR or Apollo for that matter didn't exist. I had thought of creating a Java Swing app but quickly decided that it would be no fun to build and probably take a long time. Plus, I really had no idea how to code all the slick Drag-n-Drop stuff I wanted to do. So I originally decided to build an app that would run in the browser as a Flex app. Before long Apollo was all the buzz and looked promising. I now had my technology of choice so off I went. All I needed was time to work on it... There's that "time" thing getting in my way again.

Finally I found a window of opportunity where I could sit down and start proptotyping. Then I had the "ah-ha" moment where I realized that my prototype, was actually turning into the real app. Now that is Agile!

The app is far from finished, however it is at the point where I can use it to track my time. It isn't quite ready to post for download but some screens are shown below. When down, this will be free to download and use.

Dragging a project or task from the left onto the calendar creates an entry for it. To indicate you are currently working on a task it can be dragged onto the "currently working on" area at the top.

Entries can be resized or moved by dragging. Double clicking brings up the edit panel.


While entries are shown on the calendar, you can also see them in grid format by going into project view and selecting the Time Entries tab. The "Properties" tab (not shown) is where you specify the task name, select a color, add a time estimate for later comparison with actual time, and more.

Reports are located in the Reports section. More are coming such as variable date ranges for selected a two week interval for example



Launching a report gives you a chart showing the breakdown for the time period selected.

That isn't everything, but I need to save some for later. Features coming up include:

• More reports
• Condensed view
• Printable reports
• Export to excel

As a side note, if you look carefully at the summary chart you will see that the time spent on the TimeTracker was only about 14 hours. That 14 hours is the time I spent on this since it worked enough to actually use. I probably spent about 8 hours (I don't know the actual since I didn't track it anyway...doh!) getting the initial app working which didn't have the weekview, drag-n-drop, charts, etc. So all in all, this thing represents less than a weeks work so far. Try doing that with Swing.

I'm still here

I haven't blogged in a while because I have a new baby son born just two weeks ago. However, I was able to code with one hand while holding him in the other. Coming up soon will be some information about my new TimeTracker AIR application. This app was built solely for my own use in keeping track of some projects I am working on. Since I hate having to track my time, I started work on this application.

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.

Tip #1: 'Ignore your users"

I can't take credit for this tip. Robert Hoekman (rhjr.net) inspired me to really think about whether or not we are gaining truly valuable information by spending days, weeks, months studying "real users". Thinking about attempts at studying users I have done before made me realize that, most of the time, the assumptions we made without users were largely correct. And while it is valuable to have your assumptions validated, it isn't always necessary before starting development. Notice that I say "most" of the time. Well, the reality is, get ready... we don't always get it right, even when we do extensive user testing.

Why? Well when you are testing users, regardless of how "real world" you try to make it, the user always knows that they are being tested. Many people are self-conscious having someone (or two people usually) looking over their shoulder. There are many other reasons as well.

Now before all the UCD practicioners stand up and start disagreeing with me, let me make one last point that is important. In order for this approach to work you have to make realistic assumptions in which you are highly confident. So how do you make confident assumptions? That is part of Tip #2. Stay tuned.

If ignoring your users sounds like an approach you are interested in, check out http://rhjr.net/theblog/2007/06/06/why-we-should-ignore-users-the-podcast/

On "Rich Internet Applications (RIAs)"

I should have clarified in my initial post that my main focus is in the design/development of RIAs. So most of what I will be talking about will be focusing on apps based on Flex, AIR, Silverlight or AJAX. This isn’t to say that traditional desktop apps won’t be discussed. They just aren’t my focus.

Also, since I have had the opportunity to build apps in both AJAX and Flex, I will share my thoughts on my experiences.

Hi

As a professional User Interface Designer working on an Agile development, I have had the opportunity to learn a lot about how to create software that is easy and obvious to use without a lot of up front work. In speaking with my peers, I have also found that many designers are trying to fight the mismatch between a User Centered Design approach (big up front design phase) and Agile (barely any up front design). This blog is intended to share what I have learned and hopefully learn some lessons from all of you.

More to come.