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?
Subscribe to:
Posts (Atom)