There is an interesting synopsis of a Forrester paper over at Computerworld which seems to indicate that the sky is falling if you are building AJAX apps. While I agree that performance problems and lack of rich interactivity still put AJAX behind Flex or Flash for applications, I think the authors took it a little too far. I don't intend to go pay for the actual paper from Forrester, but I have to imagine that their conclusion is a little less alarmist.
Having built many AJAX and Flex applications I personally feel that it is harder to deliver as rich a user experience using AJAX as with Flex. My gripe with the article however, is that the synopsis specifically talks about power users as being disappointed. The reality is that only a small percentage of users of most applications are ever power users. Similarly, only a small percentage are novice users for very long. The majority of users are intermediate users. So be careful about choosing a technology based on the wrong population.
Showing posts with label AJAX. Show all posts
Showing posts with label AJAX. Show all posts
Tuesday, March 25, 2008
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?
Monday, July 16, 2007
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.
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.
Saturday, June 23, 2007
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.
Subscribe to:
Posts (Atom)