Chris Keene wrote on his Blog a personal definition of RIA's:
"Rich Internet Applications match the responsiveness of traditional desktop apps by minimizing web page refreshes. RIA taps into the collective power of the Internet to supply widgets and services for building web clients, like rss feeds, Google maps and Youtube. The goal of RIA is not merely to emulate a PC GUI in a browser (aka the Silverlight sell-out), but to deliver browser-based clients which far outperform PC GUIs in speed and functionality."
Lot's of people indicate that now is the time to use RIA's in the enterprise. There are more releases of RIA products (Dojo just had its 1.0 release, before it were 0.x releases). There are currently 58 mature RIA products to choose from. Which one to choose is another question, but the time is here to think about that!
Wednesday 7 November 2007
Wednesday 24 October 2007
Yes, you really should do Usability Testing!
You should do Usability Testing. Really. When you create a new website, Usability Testing should be part of your project.
If not, it will cost you more money and less people will use, visit and like you website.
Why?
Simply because you are not the user. It is really impossible for people in the project or even in the company or people in the web development business. You have no idea how the visitors of your website experience the site. An you surely will agree that you want them to like it and use it?
What's the occasion?
At the company I work now, we've done a redesign project of their new website. A Usability test was done (by another company) on the old site. I started to work on the project when it actually was started already. So in fact I was a bit too late. But I tried to make the project work by introducing User Centered Design (UCD) to them. And Usability Testing is part of UCD.
What I've done.
I couldn't do the whole UCD process, but I did some parts to catch up and ensure that the project would be a success. Since you may not know what the UCD process is, I will tell you what I did in this perticular example.
I made personas. Personas are fictional website visitors which fit the main profile of the visitors. This profile was determined by talking to the Business people about who their customers are and on which they target. I made 3 Personas.
The website was graphically designed by a design company who seemingly didn't have too much website design experience. They still designed for print instead of the web. And these are really different!
When we saw the first designs, I knew we had a lot of work to do... I won't get into detail here, but I made quite some remarks on Usability issues. There are a lot of things about the use of colour, contrast of colours, position of elements, what kind of buttons to use, the use of bread crumbs, and so on, you can tell in advance they won't work or confuse the user.
At the end, I've won on a lot of parts, and some parts were left as is. They probably would be exposed in an Usability Test!
Functional testing
Using the Personas, I made some scenarios with the Business people. The scenarios represented the most common and most important scenarios on the website. The developers of the site should consider if the Personas would be able to complete these scenarios. I sent the scenarios to the Business people and asked them to make it part of their test-plan. The company has a low maturity on testing, so it also stimulated them to make testing, in fact, functional testing, more important.
The testing process started a bit uneasily, but after all it was done quite well.
The Usability Test
After the site was developed and functionally tested, the company decided it should go live and then do a Usability test. Well, it would be better to do the Usability test first. But hey, as I told before, I got into the project a bit late, so it was a bit hard to change the planning for this.
And it wasn't too big a problem, since I could do the test right after the site went live.
No or low budget Usability Testing
I've done a cheap Usability Test. This meant that I invited some friends and acquaintances to participate in the Test. They've never done a test like this and they hadn't seen the website yet. I drove to them in my car, so that cut down on expenses.
When I designed the test, I used the Personas to pick the participants and the scenarios to perform the test. I used a demo version of a screen capture software package to record what the participants did.
I told the participants that they were not doing an exam, and that if something didn't work or was difficult, the website was to blame. I asked them to perform the scenarios and cleverly avoid any questions they had. I was an observer and nothing more. This simulated the situation they would be in when they visit the site from home or somewhere else without anyone around from the company itself!
I also had a questionaire about how they liked the site, what they would change etc. And finally, as a bonus, I gave them a sheet with keywords like "nice", "ugly", "easy to use", "family like", "professional", etc. and asked them which keywords fitted the website. The results of this can be used to match them with the ones the Business people would like to represent the company.
All went well and it took me about 24 hours all together to design and take the test with the 5 participants!
Last monday I made the presentation to present the test results to the Business people. And again, it really surprised me! Issues arose about which I haven't thought yet and offcourse also some issues which I predicted when the design company presented their design ;-).
Now what?
Doing a Usability test before you even develop the site, on a paper prototype or prototype, will reveal 85% of the Usability issues inyour design. You should do the test again when you have developed a first version. It will again reveal 85% of the Usability issues. After some iterations, when the site is live, you should continue to do Usability Tests. The science of Usability changes, and the way users behave does.
What will this cost?
Early Usability Testing is much cheaper. The costs of fixing the issues from an Usability Test in an early design stage are at least 5 times lower that when they are fixed after the site has gone into production.
If not, it will cost you more money and less people will use, visit and like you website.
Why?
Simply because you are not the user. It is really impossible for people in the project or even in the company or people in the web development business. You have no idea how the visitors of your website experience the site. An you surely will agree that you want them to like it and use it?
What's the occasion?
At the company I work now, we've done a redesign project of their new website. A Usability test was done (by another company) on the old site. I started to work on the project when it actually was started already. So in fact I was a bit too late. But I tried to make the project work by introducing User Centered Design (UCD) to them. And Usability Testing is part of UCD.
What I've done.
I couldn't do the whole UCD process, but I did some parts to catch up and ensure that the project would be a success. Since you may not know what the UCD process is, I will tell you what I did in this perticular example.
I made personas. Personas are fictional website visitors which fit the main profile of the visitors. This profile was determined by talking to the Business people about who their customers are and on which they target. I made 3 Personas.
The website was graphically designed by a design company who seemingly didn't have too much website design experience. They still designed for print instead of the web. And these are really different!
When we saw the first designs, I knew we had a lot of work to do... I won't get into detail here, but I made quite some remarks on Usability issues. There are a lot of things about the use of colour, contrast of colours, position of elements, what kind of buttons to use, the use of bread crumbs, and so on, you can tell in advance they won't work or confuse the user.
At the end, I've won on a lot of parts, and some parts were left as is. They probably would be exposed in an Usability Test!
Functional testing
Using the Personas, I made some scenarios with the Business people. The scenarios represented the most common and most important scenarios on the website. The developers of the site should consider if the Personas would be able to complete these scenarios. I sent the scenarios to the Business people and asked them to make it part of their test-plan. The company has a low maturity on testing, so it also stimulated them to make testing, in fact, functional testing, more important.
The testing process started a bit uneasily, but after all it was done quite well.
The Usability Test
After the site was developed and functionally tested, the company decided it should go live and then do a Usability test. Well, it would be better to do the Usability test first. But hey, as I told before, I got into the project a bit late, so it was a bit hard to change the planning for this.
And it wasn't too big a problem, since I could do the test right after the site went live.
No or low budget Usability Testing
I've done a cheap Usability Test. This meant that I invited some friends and acquaintances to participate in the Test. They've never done a test like this and they hadn't seen the website yet. I drove to them in my car, so that cut down on expenses.
When I designed the test, I used the Personas to pick the participants and the scenarios to perform the test. I used a demo version of a screen capture software package to record what the participants did.
I told the participants that they were not doing an exam, and that if something didn't work or was difficult, the website was to blame. I asked them to perform the scenarios and cleverly avoid any questions they had. I was an observer and nothing more. This simulated the situation they would be in when they visit the site from home or somewhere else without anyone around from the company itself!
I also had a questionaire about how they liked the site, what they would change etc. And finally, as a bonus, I gave them a sheet with keywords like "nice", "ugly", "easy to use", "family like", "professional", etc. and asked them which keywords fitted the website. The results of this can be used to match them with the ones the Business people would like to represent the company.
All went well and it took me about 24 hours all together to design and take the test with the 5 participants!
Last monday I made the presentation to present the test results to the Business people. And again, it really surprised me! Issues arose about which I haven't thought yet and offcourse also some issues which I predicted when the design company presented their design ;-).
Now what?
Doing a Usability test before you even develop the site, on a paper prototype or prototype, will reveal 85% of the Usability issues inyour design. You should do the test again when you have developed a first version. It will again reveal 85% of the Usability issues. After some iterations, when the site is live, you should continue to do Usability Tests. The science of Usability changes, and the way users behave does.
What will this cost?
Early Usability Testing is much cheaper. The costs of fixing the issues from an Usability Test in an early design stage are at least 5 times lower that when they are fixed after the site has gone into production.
Thursday 12 July 2007
Measuring and ranking Rich Internet Pages
Does the current model of measuring page popularity, based on the number of page hits fit the single page interfaces RIA applications have? Answer: no.Nielsen/Netratings (Global leader in internet media and market research) are currently going to change their way of measuring page popularity.
For more information on this, use the following links:
Marketing Pelgrim: The problem with measuring time spent on a web site
The New York Times: Nielsen Revises Its Gauge of Web Page Rankings
Friday 6 July 2007
Rich Internet Applications in your company: Things to consider
Why should you use Rich Internet Applications in your company?
The answer is quite simple: because it's better. It solves a lot of usability issues and technical shortcomings, especially on your webpages. It is even so much better that applications can be created for a web browser which earlier would be developed as a desktop application because of the limitations of the web.
I am not going to tell you what the advantages of RIA's, you can read all that everywhere, for example on Wikipedia.
Here are the things you should consider when making the step:
How service oriented is your company?
This is a technical thing. Maybe you've heard of SOA (Service Oriented Architecture) or SOE (Service Oriented Enterprise). It basically means that you will take the front-end (the interface) apart from the calculations, rules and processes (business logic). These are going to be seperate applications: services.
This means that any application can use a specific service to get it's data. For example a service to give pricing information on you products. An application can use this service to get product information without doing any database stuff or permission stuff or anything. It doesn't have to look if the product is in stock or anything, the service does that.
The services can be introduced step by step and old applications can be rebuild to use these services and so remove their own business logic. So your legacy can stay or fade away in time.
How can we develop RIA's?
Currently a growing number of developers are learning how to create RIA's. The leading technologies are Adobe Flex (based on Flash) and Microsoft Silverlight. Research of The Butler Group in June 2007 state that also Nexaweb and Sun Microsystems are major players on the 2008-2009 market. You should also consider Backbase, edge IPK, OutSystems and TIBCO.
Your developers will be more front-end or back-end oriented and they should speak eachothers languages to be able to communicate.
The way a RIA project should be run differs from a standard ICT project. It should be user oriented, business oriented and technology oriented. In "classic" ICT projects the user usually is forgotten. To improve the user's experience this is neccessary to make the project to a success.
This takes care of problems you usually experience after the product is launched. Redesigns, remakes and fixes then usually cost 80% more and doing a user centered design takes care of these things in an earlier stage, when changes are much cheaper.
Will my users understand this new stuff?
Yes! Ofcourse currently there are not a lot of RIA's online, but the number is growing. Because of the user centered design, the learning curve for the user is short and the benefits are instantanious. Maybe your users won't notice that they are working with a RIA, but they will be happy about how everything works.
Don't do too much!
Don't make your website one big RIA. You will run into big problems (Google-ability, print issues, etc.). Take the "application like" things, like the order and checkout process, searching and selecting things or processes with a lot of forms or form-elements in it. Make a hybrid website (part HTML and part RIA applications).
Okay, nice. But where should I start?
Start with your most important website or the site a lot of people complain about. Make an inventory of the problems. Let a Usability Analist (like me ;-)) do a Usability test and let him/her make recommendations. Then you can start considering technology things to work on those recommendations.
And do not forget: Define what your goals are! State how much more products you want to sell, by what percentage you want to decrease the number of helpdesk calls, etc. Quantify them!
Do testing in early stages. The sooner you discover problems the better (and the cheaper to change). Also test afterwards and monitor if your goals are met and why or why not.
Don't start with too large projects. I can tell you a hundred things about how to do things, but each company has it's own politics and ways of doing things. You can get accustomed with that in the first smaller projects.
The answer is quite simple: because it's better. It solves a lot of usability issues and technical shortcomings, especially on your webpages. It is even so much better that applications can be created for a web browser which earlier would be developed as a desktop application because of the limitations of the web.
I am not going to tell you what the advantages of RIA's, you can read all that everywhere, for example on Wikipedia.
Here are the things you should consider when making the step:
How service oriented is your company?
This is a technical thing. Maybe you've heard of SOA (Service Oriented Architecture) or SOE (Service Oriented Enterprise). It basically means that you will take the front-end (the interface) apart from the calculations, rules and processes (business logic). These are going to be seperate applications: services.
This means that any application can use a specific service to get it's data. For example a service to give pricing information on you products. An application can use this service to get product information without doing any database stuff or permission stuff or anything. It doesn't have to look if the product is in stock or anything, the service does that.
The services can be introduced step by step and old applications can be rebuild to use these services and so remove their own business logic. So your legacy can stay or fade away in time.
How can we develop RIA's?
Currently a growing number of developers are learning how to create RIA's. The leading technologies are Adobe Flex (based on Flash) and Microsoft Silverlight. Research of The Butler Group in June 2007 state that also Nexaweb and Sun Microsystems are major players on the 2008-2009 market. You should also consider Backbase, edge IPK, OutSystems and TIBCO.
Your developers will be more front-end or back-end oriented and they should speak eachothers languages to be able to communicate.
The way a RIA project should be run differs from a standard ICT project. It should be user oriented, business oriented and technology oriented. In "classic" ICT projects the user usually is forgotten. To improve the user's experience this is neccessary to make the project to a success.
This takes care of problems you usually experience after the product is launched. Redesigns, remakes and fixes then usually cost 80% more and doing a user centered design takes care of these things in an earlier stage, when changes are much cheaper.
Will my users understand this new stuff?
Yes! Ofcourse currently there are not a lot of RIA's online, but the number is growing. Because of the user centered design, the learning curve for the user is short and the benefits are instantanious. Maybe your users won't notice that they are working with a RIA, but they will be happy about how everything works.
Don't do too much!
Don't make your website one big RIA. You will run into big problems (Google-ability, print issues, etc.). Take the "application like" things, like the order and checkout process, searching and selecting things or processes with a lot of forms or form-elements in it. Make a hybrid website (part HTML and part RIA applications).
Okay, nice. But where should I start?
Start with your most important website or the site a lot of people complain about. Make an inventory of the problems. Let a Usability Analist (like me ;-)) do a Usability test and let him/her make recommendations. Then you can start considering technology things to work on those recommendations.
And do not forget: Define what your goals are! State how much more products you want to sell, by what percentage you want to decrease the number of helpdesk calls, etc. Quantify them!
Do testing in early stages. The sooner you discover problems the better (and the cheaper to change). Also test afterwards and monitor if your goals are met and why or why not.
Don't start with too large projects. I can tell you a hundred things about how to do things, but each company has it's own politics and ways of doing things. You can get accustomed with that in the first smaller projects.
Wednesday 20 June 2007
Thursday 14 June 2007
HTML will be there forever
Just had an interesting conversation with a collegue about the future of HTML.
It's function is clearly shifting from a markup language (well, language... i'm not sure) to an XML variant which will be used to position components and plugins.
After all, what more do we need than the basis of the HTML DOM with some includes of your preferred Ajax Framework or an EMBED tag to startup the Flex application? Programmers hardly type HTML anymore, all HTML snippets and components are generated by frameworks! The only reason why some of us do type HTML is because the framework just isn't supporting these few features we would like and we need to do some working around... But that will end when the frameworks are at their 2.0 version.
I think in a few years the meaning of HTML will move to some kind of configuration thing, like we used to have in the settings.ini file of your classic Windows application.
It's function is clearly shifting from a markup language (well, language... i'm not sure) to an XML variant which will be used to position components and plugins.
After all, what more do we need than the basis of the HTML DOM with some includes of your preferred Ajax Framework or an EMBED tag to startup the Flex application? Programmers hardly type HTML anymore, all HTML snippets and components are generated by frameworks! The only reason why some of us do type HTML is because the framework just isn't supporting these few features we would like and we need to do some working around... But that will end when the frameworks are at their 2.0 version.
I think in a few years the meaning of HTML will move to some kind of configuration thing, like we used to have in the settings.ini file of your classic Windows application.
Sunday 10 June 2007
Silverlight or Flash/Flex?
Has the big shakeout started yet? Wel, not yet I suppose, but Microsoft and Adobe are preparing for the battle. And ofcourse, we have "the others"...
One thing I know for sure: Rich Internet Applications are commonly accepted to be the future of the web (Web 3.0)? User Experience is the keyword, and it all started with a brochure online and via dynamic websites we went to the Rich Internet Application.
And in my opinion, Adobe was the first with a useful and solid environment for developing RIAs.
There are some interesting discussions going on: the pros and cons of the issue: "Silverlight will kill Flash" are found here:
One thing I know for sure: Rich Internet Applications are commonly accepted to be the future of the web (Web 3.0)? User Experience is the keyword, and it all started with a brochure online and via dynamic websites we went to the Rich Internet Application.
And in my opinion, Adobe was the first with a useful and solid environment for developing RIAs.
There are some interesting discussions going on: the pros and cons of the issue: "Silverlight will kill Flash" are found here:
Subscribe to:
Posts (Atom)