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?"
Wednesday, October 31, 2007
Tuesday, October 23, 2007
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.
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.
Tuesday, October 16, 2007
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.
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.
Thursday, October 4, 2007
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.
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.
Subscribe to:
Posts (Atom)