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.
Sunday, September 30, 2007
Wednesday, September 26, 2007
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?
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?
Tuesday, September 25, 2007
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.
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.
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.
Let me know what you think of the site.
Thursday, September 20, 2007
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:
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.
[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?
Saturday, September 15, 2007
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.
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.
Thursday, September 13, 2007
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.
Let me know what you think...though I guess we will find out tomorrow.
Monday, September 10, 2007
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.
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.
Friday, September 7, 2007
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.
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.
Wednesday, September 5, 2007
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.
Subscribe to:
Posts (Atom)