the SidOnAgile blog

The Agile process: A fast running train?

2012-01-31T14:51:00.000Z

Came up with this title during a meeting I had today with some colleagues. It was a meeting which I dialed in remote, so I had a disadvantage from the beginning, but that's not my point.

If you put a lot of people into a room, all of them will probably have something to say about 80% of the issues you're talking about. That's what we're experiencing in our Agile process, and a lot of that is good. Everyone knows what it's all about and everyone can have his say, so no-one is left behind or in the dark.

The problem is, that meetings like these are usually more of a brain storm session. We are doing Agile with SCRUM, so you need to take care of the fact that the actual work should be done in the Sprint itself. In that Sprint you should do people in what they are best.

In my case, I'm looking from a Usability perspective to a project and the team is really brainstorming on a lot. And making decisions while pokering. In Agile, that usually is not a big problem, if you have ideas on improvement, make a new story and if that delivers business value, develop it. But in a lot of cases, certainly in ours, we've experienced that those improvements are not often developed because the project has no budget. So if I want to make Usability improvements I need to fight for that and try to get my point through in the discussion. Well, that's life for a Usability Analyst, I know.

How would we improve that and be more (mature) Agile?

Recognize the right disciplines in your Agile team, like Usability, Testing, Front End Development, Back End Development, Content Design, Business Process Analysis, etc.;
Don't design too much in the poker sessions, make sure that the idea of the required functionality is clear so the team is able to poker it;
Recognize that design (not only visual but also functional, navigational and content design) is part of the development process;
Choose some form to be clear and unambiguous about function, form and interaction. I prefer making a clickable wire frame or prototype, with detail in those areas where needed;
From a budget perspective, be clear that your entire budget shouldn't be gone when the stories are finished. That's more like a form of waterfall where you just use the budget and then development is ready. Maybe there's is Business Value in there, but in Agile you should be both iterative and incremental. Do do this properly, you need releasable versions you can make improvements on;

If you do this, you will deliver more Business Value. If you don't do increments, you are still trying to do everything in one shot; and that's not Agile. For the same reasons I make wire frames to let my stakeholders see what the effect of decisions is and what value it delivers, you should do that with the releasable product as well.

I've been experiencing the implementation of Agile / SCRUM in a large company for quite some time now, and I realized quite awhile ago that the change from Waterfall to Agile is not only learning a new methodology. It's not only changing your mindset, but also recognizing that the current situation is not Utopia, but it should be the road to it. You should always think about these things:

How are we going to do things best in our current environment and situation?
What is the ideal way of doing things?
Who do we want to be and what do we want to achieve?
How do we get there?

There's no mistake: going to be Agile needs change management. In the spirit of SCRUM: use retrospectives to consider how we've done and what we need to do, because doing that is often forgotten in the delusion of the current day.

The importance of time boxing in SCRUM

2011-11-16T12:14:00.001Z

In an Agile environment, in my experience people get enthusiastic. I think that is one of the good things of an Agile way of working. In my work experience I've seen that starting with an Agile way of working, in this case SCRUM, especially developers get happy.

This has several reasons, but the main things is: they can do their work. And the method respects the dynamics of IT development.

But every methodology has some anchor points, which should guide you in the right direction. Important in SCRUM are these meetings:

The daily SCRUM (stand up)
The SCRUM of SCRUMs
The Sprint Planning
The Sprint Demo or Review
The Retrospective

There are several variants of the SCRUM implementation in an organization. Probably the company will not start entirely Agile, but start a transition from Waterfall methodology onto pure Agile. Each company has to handle the touch points with other parts of the organization which still practices Waterfall methodology and how to translate that to the part that is Agile.

It is important to keep evaluating things and see how they can be improved.

I think an important thing is to look at how much time you need for those meetings, and time box them properly. This takes care of the fact that meetings are going to take to much time, and that the meetings will be used for what they're are meant for. Sometimes people tend to use those meetings to talk about a lot of things, maybe also about how to improve the process.

A good moment to look at how you do things, would be the retrospective. But keep in mind that that meeting is time boxed too. Although I do think that during the process of making your organisation more Agile, you might need some more time for the retrospective. On a different level, this goes for the SCRUM of SCRUMS as well.

The positive effect of sticking to this, that is a) time boxing and b) stay to the purpose of the meetings -although it sounds a bit bureaucratic- is that you will have a clear view on how much time it takes to do those meetings and how much time there''s left to do the actual development during sprint. I still believe there's enough dynamics outside these time boxes to keep the process lean - and mean.

The Distributed SCRUM Team: agile teams anywhere on the globe

2011-09-05T15:41:00.003+01:00

"We are looking for a location where we can all be, regardless of where we all are."

After 48 weeks of doing SCRUM, with the number of teams growing from 1 to 6 and trying out different implementations, we now face a new, interesting challenge. Our 5th and 6th SCRUM teams have started in... Chine and India.

So, here it is: "One of the biggest mantras for Agile teams is that you have to be co-located. If you are not co-located, you are not going to be highly performant." (Julie LeMoine, the Fidelity Center for Applied Technology) That's the thing. Everybody, at least in our situation, beleives that one of the biggest benefits is that all team members and teams are at walking distance. Most of them even at pebble throwing distance. And they also agree that most of the problems we face are communication problems with people who are further away then the earlier mentioned.

So how are we going to handle two teams in another part of the world, are we going to share the backlog? Do we instate another product owner? Are they actually working on another product? How do we do shared meetings when we are in different time zones, e.g. for our daily stand up?

Of course there are theories and people who have thought about issues like these, but like always, one also needs to regard the issues of the specific company. And what the possibilities we have to change things. So I'll be probably reading the books below, but also start a discussion, maybe just a theoretic one, with some people and see how we get all advantages there are out of it.

I would be very interested in your opinion and experiences on this, and maybe communicate with the collegues in China and India on a more regular basis, to see what happens from your perspective.

These might be interesting to read:

Optimization has no Business Value

2011-07-05T23:04:00.001+01:00

Or: The future – who cares?

By Sid B. Dane, July 1st, 2011

What is best to do: optimize your IT project to be prepared for the future or don’t care, we’ll see what happens then? In a SCRUM environment you have a strong preference for focusing on Business Value, i.e. effectiveness and not efficiency. The way to reason if you should be prepared for the future is first put it in the two extreme opposites:

Only solve the problem at hand; use the simplest possible solution ("Effective Java (2nd Edition)" / Joshua Bloch, 2008);
Always implement the principles of scalability, maintainability, reliability, availability, extensibility, performance, manageability, and security

The thing is: we cannot predict the future. Well, we can expect things, but it is not a prediction. This is like a weather forecast: it’s reasonably accurate for the next day, but after 3 days it’s more like a guess. So does it take more effort to be prepared for the future than just act on it like it comes? In an Agile environment, the rule is: choose respond to change over following a plan ("Manifesto for Agile Software Development" / Kent Beck, Mike Beedle, Arie van Bennekum, and others, 2001).

Also, taking care of things that might happen or might be handy in the future can introduce concessions to speed and performance and other things ("Premature optimization is the root of all evil - not only in the Agile world" / Przemysław Bielicki, 2008). Should you be willing to do those concessions just for the sake of being prepared for the future?

A mental model

Let’s take a look at these two scenarios:

In scenario 1 and 2 the same functionality is developed, which takes 100 units of work. In scenario 1 though, also 20 units of work are spent extra to do optimization. In scenario 2 just the simplest solution is applied and no extra optimization is done.

In this example, we assume that an extra of 10 work units need to be done to change that particular part needed for the new requirement. We can see that if the extra requirement needs 15 units of work, the total sum of work units spent is 135 in scenario 1 and 125 in scenario 2. If another extra requirement comes along, and we add those numbers again, we result in 150 units in scenario 1 and also 150 units in scenario 2.

We can assume this is quite a retentive model, and even then the early optimization pays back only when the 3rd extra requirement is added. So the question is: how likely is it that there will be at least 3 added requirements?

Well, in my opinion this is as likely as forecasting the weather for the next 7 days. I could even argue about the number of work units chosen for the early optimization in scenario 1. How likely is it if you spend 1/5th of the development time extra to optimize the system, that this will cover all possible or all likely future changes?

“We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil.” ("The C++ Programming Language, 11.3.7: Efficiency" / Donald E. Knuth, 1988)

It would be nice to measure the following for all stories:

How much time is spent on early optimization?
How much time is spent on developing the new requirement?
How much time is spent because early optimization was not done?
How much time is spent because early optimization was not done?

If you measure these parameters on 500 stories on your backlog, it would be interesting to see what scenario works best. Using the law of large numbers, you should consequently use the same scenario to make it work.

Project Managers will complain if negative signals reach them from the project. Spending time because early optimization is not done would be a negative signal. If it exists multiple times in 1 project, it appears to be a bad thing. Depending on how well the Project Manager is heard, views on early optimization will change. The overall gain usually is not visible because the early optimization that is done is often interwoven in the regular development work.

In non-agile environments, there usually is not much time to spend on early optimization. It is focused on meeting the deadline. In an agile environment, the team can decide for themselves. They will be eager to do early optimization because they never had the chance and it always was a developer’s utopia. And it’s the best thing to do… theoretically.

On the other hand, we are working in a SCRUM environment, so the actual questions that should be asked is:

How much Business Value is generated by early optimization?

“More computing sins are committed in the name of efficiency (not necessarily achieving it) than for any other single reason - including blind stupidity.” ("A Case Against the GOTO, Proceedings of the 25th National ACM Conference" / William A. Wulf, 1972)

How to handle this theory?

To avoid discussion on semantics, we should clearly identify premature or early optimization. The word premature indicates by itself that it’s not a good thing. Early sounds a bit better. But it’s not the words here that matter.

I won’t say that one should never optimize or early optimize. Thing is, in what level are we committed to creating Business Value? If no early optimization is done, the time-to-market will be optimal. The first few changes we can do quickly and it will not cost too much. Changes will take a little more time because we will have to make adjustments to the system to make it fit, but the overall time spent is less, at least for those few first changes.

To make things even a bit better, you could create a rule of thumb about optimization. Some specific aspects of … made us learn that it would be good to invest in those on a certain level. But those optimizations should always be minor and one should always be aware of the motivations and if those motivations are valid and not just because you should optimize or something could maybe happen.

“We follow two rules in the matter of optimization: Rule 1. Don't do it. Rule 2 (for experts only). Don't do it yet - that is, not until you have a perfecly clear and un-optimized solution.” ("Two rules in the matter of optimization" / M.A. Jackson, 1975)

If an optimization is of a larger size, it could be considered a new requirement to the story and the Product Owner and/or Business should be asked if there is any Business Value in it. If not, first make the un-optimized solution and after that reevaluate the necessity of the optimization.

=== END ===

special thanks to Korjan van Wieringen, friend and sparring partner

Bibliography

"A Case Against the GOTO, Proceedings of the 25th National ACM Conference" / William A. Wulf. (1972, August).
"Effective Java (2nd Edition)" / Joshua Bloch. (2008, May 28).
"Manifesto for Agile Software Development" / Kent Beck, Mike Beedle, Arie van Bennekum, and others. (2001).
"Premature optimization is the root of all evil - not only in the Agile world" / Przemysław Bielicki. (2008, oktober 9).
"The C++ Programming Language, 11.3.7: Efficiency" / Donald E. Knuth. (1988).
"Two rules in the matter of optimization" / M.A. Jackson. (1975).

Firefox HTML 5 demonstration

2011-03-18T10:26:00.001Z

When in Firefox, Chrome or any other HTML5/CSS3 capable browser, take a look at this nice Planetarium demo at http://mozillademos.org/demos/planetarium/demo.html

Flex 4 / AIR: copyToAsync does not fire the ProgressEvent

2011-03-15T16:04:00.000Z

Problem:

While working on an desktop AIR application, I came across the problem that the copyToAsync method of the flash.filesystem.File class does not fire a ProgressEvent.

I would love to use the Async method, because this does not hold up the rest of the application, but I wanted to display some progress indication in e.g. a ProgressBar.

Solution:

Open 2 streams, one to read from and one to write to. Read and write chunks of bytes and calculate the progress according to the bytesAvailable attribute of the read stream.

Sample code:

// This is an object which has a public attribute which contains the source of the file to copy and
// a public function with a File parameter to copy it to

public var fileObject:File;

public function copyTo(destination:File):void {
   inStream = new FileStream();
     outStream = new FileStream();

     inStream.addEventListener(ProgressEvent.PROGRESS, onProgress );
     inStream.addEventListener(Event.COMPLETE, onReady );

     inStream.openAsync(fileObject, FileMode.READ);
     outStream.openAsync(destination, FileMode.WRITE);
}

private function onProgress(e:ProgressEvent):void {
     // calculate the percentage
   pct = Math.round(e.bytesLoaded/e.bytesTotal*100);

   // if you want to update the progress bar:
     bar.setProgress(pct, 100);

// if the ProgressEvent is fired, we have data available in the inStream, so we can start writing data

     var bytes:ByteArray = new ByteArray();
     inStream.readBytes(bytes, 0, inStream.bytesAvailable);
     outStream.writeBytes(bytes, 0, bytes.length);
}

private function onReady(e:Event):void {
   // the whole stream is read, so close the files
     inStream.close();
     outStream.close();

   // dispatch a COMPLETE event to let listeners to this object know the copy is done
     fileObject.dispatchEvent(new Event(Event.COMPLETE));
}

And somewhere in the application, associated with the copying process, there's a progress bar like this:

<mx:progressbar id="bar" mode="manual" width="100%"/>

I'm sorry this code's not entirely complete, but I had to use fragments of my existing code to illustrate this principle. Feel free to experiment with it.

Twitvertising?

2010-10-08T08:33:00.001+01:00

This week, I realised that Twitter is in danger of SPAM. Or will it be an enrichment? How Twitter can be used for targeted advertisement.

This week, my car needed a checkup. Since I do things digital as much as possible, I made the appointment with the garage by internet. That went quite well. Because I needed to transport quite a lot of stuff, I asked for a bigger car. I have a Volvo V50 myself, and they gave me a Volvo XC70 AWD T5. That's quite a car! I was very happy, 'cause the stuff I needed to transport was so much, that it hadn't fit in my own car. It just fitted in the XC70. I was happy with the car, because it still was very fast and had no problem with the weight.

After I returned the car, I tweeted this message:

"Today I was happy: car was serviced and the temp car was a brand new Volvo XC70 - happy me!"

...Image my surprise - yes, I really was surprised! - When I got this reply:

That means Dealer24x7 is running an engine to search tweets about car brands, and then replying to it! How brilliant is that!

Of course it can mean, that if more -and also sleezy- companies and advertisers start to do this, Twitter might get flooded with advertisements. I wonder what happens. What I know for sure: Twitter will live on for some time...

The Secret Powers Of Time

2010-07-09T16:26:00.001+01:00

E-mail is dead...

2010-06-17T10:14:00.002+01:00

Site specific browsers

2010-01-04T11:06:00.003Z

As defined in Wikipedia: "A site-specific browser (SSB) is a software application that is dedicated to accessing pages from a single source (site) on a computer network such as the Internet or a private intranet. SSBs typically simplify the more complex functions of a web browser by excluding the menus, toolbars and browser chrome associated with functions that are external to the workings of a single site."

So, basically, this is a browser, disguised as an application? We already knew that browsers now act as new layer between the Operating System of a computer and an application, and is not just for browsing through pages of content. A simple step like this might be a step forward to better integration between your desktop PC and the internet, and thus the differences between applications and web (applications) will fade even more.

In his recent article "Exciting web browser trends in 2010" Devindra Hardawar describes that currently only Google Chrome supports this (just use the "create shortcut" option on the upper right). And in fact, it is quite handy! Devindra says in 2010 more browser will support this, and I agree on that. It isn't a too big thing to implement, I guess.

The most importent thing is if the users will start using it. I did. I use Google's Wave for some weeks now, start Chrome every day to check my mail and found out it is very convenient.

This, in combination with products like Adobe's AIR will bring the internet closer to your desktop and perhaps will bring even Microsoft Windows, Apple OS and Linux closer together.

References: http://royal.pingdom.com/2009/12/21/exciting-web-browser-trends-in-2010/

Don't take your random() for granted...

2009-11-19T21:40:00.007Z

In my current project, we use a functionality which chooses a random colour for a machine. To do this, we need to select a colour from a set of 8 colours. In our Flex application we use a function called randomInt, which generates a random integer between a and b:

public static function randomInt(a:int, b:int):int {
return Math.round(Math.random()*(b-a))+a;
}

Usually we look for functions like these on the internet, but I’d like to emphasize that you also should unit-test functions which are made by others.

So I’ve generated 5000 integers between 0 and 20 in a test application, and put that in a graph:

Note that the numbers on the boundaries, 0 and 20, are significantly chosen less times than the others (1-19). This would mean, that if this function is used for picking a random machine colour, the colours 0 and 7 have only a 7% chance to be selected, while others have a 14% chance!

I’ve talked about this to someone who knows a lot of these mathematical things. The problem is the rounding. Since Math.round() returns a pseudo-random number n, where 0 <= n <>

We need to include the boundaries to produce a evenly distributed random integer. This is the new function:

private function randomInt(a:int, c:int):int {
var b:int = c + 1;
return Math.floor(Math.random()*(b-a))+a;
}

Doing the same test, produces this graph:

As you can see, each integer is chosen about the same number of times. Now we know for sure that colours 0 and 7 won’t stay in storage, but are also sold!

Nomads in IT...

2009-06-03T10:21:00.001+01:00

Yesterday I was present at a job interview at IT.

I represented the technical guys, though I'm more a User Experience Consultant with technical background, but my job is mostly technical right now.

The guy who had the interview was somewhat the same, only a bit more with a designer's background.

It was suprising how difficult it is to find the right position for a User Experience Consultants, especially in the technical department!

They belong nowhere...

Customer Experience Is Usually Very Poor

2009-04-21T14:41:00.011+01:00

(I didn't finish this article, and to engage myself in finishing it, I post it as such.... Yes I will finish it soon!)

this article will be translated to English

Uit een onderzoek van Forrester uit 2008, waarin zij aan klanten vroegen naar hun ervaringen met verschillende bedrijven op het gebied van bruikbaarheid, usability en plezier, bleek dat ANWB winkel, Esprit en de Bijenkorf aan de top staan in Nederland.

Forrester stelde uit die gegevens de Customer Experience Index samen. De lijst omvat 57 bedrijven, waarvan er slechts 6 een waardering "excellent" kregen. Daarentegen kregen 30 bedrijven de waardering "slecht" of "zeer slecht"...

Wat valt er op aan deze onderkant van de lijst? De bedrijven uit de lijst waren grofweg ingedeeld in 5 branches: retailers, banken, energiebedrijven, internet service providers en mobiele telefonie bedrijven. Wanneer je gaat kijken wie er aan de onderkant van de lijst staan, valt het wel op dat de energiebedrijven het wel heel slecht doen:

25e plek: Greenchoice
45e plek: Essent
47e plek: Eneco
48e plek: Nuon
52e plek: Energie:direct
55e plek: Oxxio
56e plek: E.ON
57e plek: Nederlandse Energie Maatschappij

Alleen Greenchoice krijgt een waardering "okay". Wanneer je in deze lijst onder nummer 37 staat, is het niet best met je, de waardering is daar ronduit "zeer slecht". Valt het u op dat het 2e energiebedrijf op de lijst Essent op nummer 45 staat? Niet zo best dus.

De energiebranche in Nederland doet het dus het slechtste op het gebied van Customer Experience. Overigens doen de Internet Service Providers het net iets beter, maar worden nog steeds gewaardeerd als "zeer slecht".

Waarom zit het nou in die specifieke branche zo slecht? Ik ben 2 jaar gedetacheerd geweest bij één van de genoemde energiebedrijven, dus op basis daarvan kan een ik kleine analyse doen.

The Experience Economy

Het draait erom in hoeverre het belang van Custromer Experience meespeelt in de bedrijfsprocessen. En dat begint met het erkennen en willen dat het bedrijf zich onderscheidt in Customer Experience. Vanuit de gedachte dat je niet in alles de beste kan zijn, moet je in alles even goed zijn als de concurrent en in één ding uitblinken. En aangezien de economie nu steeds meer draait om Experience (zie: The Experience Economy [Pine & Gillmore, 1999]), laat dat dan dat ene zijn waarin het bedrijf uitblinkt. Uiteindelijk zal het voor energiebedrijven zeker zo zijn dat de tarieven overal net zo scherp zijn, de stroom net zo groen en de energiemeters net zo slim.

Als je de volwassenheid (maturity) van Customer Experience in de organisatie in de volgende niveau's verdeelt:

Interesse

Er wordt in geinvesteerd

Toegewijd

In ontwikkeling

Opgenomen in de organisatie

Kunnen we met zekerheid zeggen dat energiebedrijven niet veel verder komen dan niveau 1. De interesse is er in die zin, dat er veel over gesproken wordt en dat eigenlijk wel iedereen er het belang van inziet (85% van de bedrijven bevestigen dat zij het belang van een goede Customer Experience inzien). Uit mijn ervaring kan ik zeggen dat die interesse er eigenlijk nu zo'n 2.5 jaar is. In de 2 jaar dat ik bij het bedrijf werkzaam ben geweest is er ook echt wat mee gedaan, maar dat kwam voornamelijk omdat ik daar persoonlijk de focus op legde, maar niet omdat dat door de organisatie gevraagd werd. Dat ze nog niet bij niveau 2 waren, was duidelijk doordat er geen ruimte voor was in planningen en allocaties.

Daarnaast wordt vaak Usability, User Experience en Customer Experience over één kam geschoren. Wat zijn dan die verschillen? Mijn definities zijn deze:

Usability

De gebruiker wordt goed ondersteund doordat de best-practices in het design zijn toegepast. De interactie is consistent, navigatie is duidelijk en indien nodig wordt de gebruiker op weg geholpen. De gebruiker raakt niet in verwarring, vindt wat hij zoekt en begrijpt waar het over gaat doordat het intuitief werkt of goed wordt uitgelegd.

User Experience

De gebruiker krijgt ook een bepaald gevoel tijdens en na het contact met de website of applicatie. Dat gevoel dient prettig en passend te zijn. Hij moet aan zijn vrienden kunnen vertellen dat het gebruik van de website makkelijk en leuk was. Omdat de resultaten naar verwachting waren en het "servicegevoel" in lijn met de norm van het bedrijf.

Customer Experience

Hier verandert de gebruiker in een klant. Op dat moment spelen er subtiele andere gevoelens mee dan in de User Experience. De klant moet overtuigd raken, onderhevig zijn aan bepaalde emoties en vertrouwen hebben (zie: How to Design for Persuation, Emotion, and Trust [Human Factors International]). Een gebruiker moet gewoon de dingen kunnen doen die hij moet doen, een klant moet daar ook zo'n positieve ervaring bij hebben dat hij ook terugkeert en beter nog: het bedrijf aanbeveelt bij zijn vrienden en kenissen op verjaardagen (zie: Net Promoter Score).

Waarom zijn dan de energiebedrijven hier zo slecht in?

...

If it walks like a duck and quacks like a duck, I would call it a duck.

2008-10-12T19:05:00.007+01:00

Just a few days ago my Nokia Phone Suite application told me there was a new version available. And the installation surprised me again. It's the year 2008 and the most simple usability rules are still unknown to some software developers.

Let me show you the dialog:

It is really simple. If you suggest I can click YES the should be a YES button. Not a button with a green V. Same for the NO button. Not a red X.

Call it what it is.

I understand: it it obvious, everyone can figure out that the green V is the YES and the red x is the NO. But it takes (a little) time to figure that out. And that, only that, can kill the trust users have in your application. Dr. Eric Schaffer of Human Factors International talks about PET design. Design for Persuation, Emotion and Trust. I believe it's a fair point. Especially the fact that there always is tension between that and Usability. In the Nokia case, the designers probably wanted to make a trendy flashy application (it's a lot of young people who use mobile phone applications, not?).

I think Nokia went wrong here in the installation of the application. They don't do what they promise: offer a YES and NO button. Bye bye trust.

Will the end user regain his trust and trust the application itself or will they quit using it at the first failure?

I leave you with this question, but I can make a guess...

Customer Experience and User Experience

2008-05-07T11:41:00.005+01:00

"The customer is always right"

"Know thy user, for he is not thee"

A marketeer looks differently at an online customer than a web designer. A Usability Analyst looks differently at an online user than a web designer. So do marketeers and Usability Analists look the same way at an online user?

In the real world: they don't. But I think they should. We all know that a website is not a pure technical thing, neither a pure marketing and sales thing and neither a pure user thing. These three forces work together and since the beginning of the internet, the technical forces always been stronger than the others and in the last few years the marketing and sales force has become one of the strongest forces: we need return on investment!

Lately, organisations start to realize that Usability of a website is very important. If your website is not usable they will leave. And even worse: if your competitor's website is more usable, they'll use that one because the User Experience is better!

And a good user experience is the basis for a good customer experience. For a good customer experience you need to look at the whole customer life-cycle. Huub Esten, my collegue at Capgemini says: "You need to be the best in one part and at least as good as the others for the other parts of the process". Especially when your company does online business, awareness of Usability and User Centered Design is key.

In his latest "Alertbox", the Usability guru Jakob Nielsen told about a research where they found that if your webpage has about 111 words on it, about 50% will be read. With more words that percentage drops fast. So tell that to the marketing people: your customers will read only half (or less!) of what you need to say to them.

References:

"Wat doet de Customer Experience Methodiek?" (dutch), Telecommerce Magazine, Jaap van Sandijk
"How little do users read?", useit.com Alertbox, Jakob Nielsen

A new era: Rich Internet comes to your desktop!

2008-02-28T09:22:00.005Z

A lot of people will say it has been there for years/awhile, but I think that with the launch of Adobe AIR 1.0 in combination with Flex 3 and products like Mozilla's XULRunner, Rich Internet is coming to your desktop.

In fact, that is a funny thing! Over the last few years desktop applications have moved to the internet, loosing richness but gaining reach. The next move was gaining richness with the introduction of Rich Internet Applications.

But now!

By bringing Rich Internet to the desktop, we complete the circle and combine all those things. It adds the availability of local data to the whole thing. Things like this have been there for a bit for a time already, but now these big players like Adobe and Mozilla truly believe in the future of bringing web applications to your desktop, a new era has truly started. And not forget Google Gears.

Read the article by Technology Review on Adobe's Kevin Lynch about Offline Web Applications. Check the O'Reilly blog about Mozilla, part 1 and part 2.

The future's so bright, I gotta wear shades...

P.S. I'm very curious who will extend the picture above to support these new technologies.

Are users getting more experienced? Should we drop Usability Design Guidelines?

2008-02-05T09:06:00.000Z

Jakob Nielsen, the famous Usability guru, wrote an article about Usability enemies and the counter arguments they have against design guidelines:

"You're testing idiots — most users are smarter and don't mind complexity."
"You were right in the past, but users have now learned how to use advanced websites, so simplicity isn't a requirement anymore."

In a recent research, they concluded that user skills are improving, but slightly. Still a lot of guidelines still apply...

(Quote) For now, one thing is clear: we're confirming more and more of the old usability guidelines. Even though we have new issues to consider, the old issues aren't going away. A few examples:

Email newsletters remain the best way to drive users back to websites. It's incredible how often our study participants say that a newsletter is their main reason for revisiting a site. Most professional users are not very interested in podcasts or newsfeeds (RSS).
Opening new browser windows is highly confusing for most users. Although many users can cope with extra windows that they've opened themselves, few understand why the Back button suddenly stops working in a new window that the computer initiated. Opening new windows was #2 on my list of top-10 Web design mistakes of 1999; that this design approach continues to hurt users exemplifies both the longevity of usability guidelines and the limited improvement in user skills.
Links that don't change color when clicked still create confusion, making users unsure about what they've already seen on a site.
Splash screens and intros are still incredibly annoying: users look for the "skip intro" button — if not found, they often leave. One user wanted to buy custom-tailored shirts and first visited Turnbull & Asser because of their reputation. Clicking the appropriate link led to a page where a video started to play without warning and without a way to skip it and proceed directly to actual info about the service. The user watched a few seconds; got more and more agitated about the lack of options to bypass the intro, and finally closed down the site and went to a competitor. Customer lost.
A fairly large minority of users still don't know that they can get to a site's homepage by clicking its logo, so I still have to recommend having an explicit "home" link on all interior pages (not on the homepage, of course, because no-op links that point to the current page are confusing — yet another guideline we saw confirmed again several times last week). It particularly irks me to have to retain the "explicit home link" guideline, because I had hoped to get rid of this stupid extra link. But many users really do change very slowly, so we'll probably have to keep this guideline in force until 2020 — maybe longer. At least breadcrumbs are a simple way to satisfy this need.
People are still very wary, sometimes more so than in the past, about giving out personal information. In particular, the B2B sites in this new study failed in exactly the same way as most B2B sites in our major B2B research: by hitting users with a registration screen before they were sufficiently committed to the site.
Non-standard scrollbars are often overlooked and make people miss most of the site's offerings. The following screens show two examples from last week's testing.

(End Quote)

Read the whole article "User Skills Improving, But Only Slightly", by Jakob Nielsen.

The Usability of driving a car

2008-01-16T20:33:00.000Z

If you have trouble convincing people that Usability is very important for your website, Rich Internet Application (RIA) or any other application, just put them in a strange car and tell them to drive...

I realised this when my car broke down and I needed a rental. Since my car is a company car, it always is a surprise which rental you get. Usually it is a car which is completely unknown to me, so it will be a long test drive.

When I got the car and wanted to drive away, I needed to look around to see if the controls were like I was used to. Usually things like steering wheels, throttles etc. are just the same, so I can get in and just drive away!

Less important things are less obvious, like changing the interval speed of the windscreen wipers and stuff like that.

And that is why people who can drive, can drive in any car! So, wouldn't it be nice if it was the same for using a website or application? And still, this is not the case...

A website should be obvious to use, like a car is. You shouldn't need to do a lot of thinking (read "Don't make me Think" by Steve Krug). People should be able to do the most common tasks or actions without reading the manual first. Off course, the "battle" between design and Usability comes up here, but I think it should be a major challenge for the designer to design for a website with great Usability. This is better than a great design leaving people confused on how to use it... So the Usability Analyst and the Designer should work together from the beginning.

If you want to introduce Usability in your project or create Usability awareness, please keep going and maybe use this example. I'm sure that anyone who ever drove a type car they've never drove before know exactly what you are talking about.

(Interested? Also read this post)

Get your RIA product into the enterprise NOW!

2007-11-07T09:08:00.000Z

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!

Yes, you really should do Usability Testing!

2007-10-24T17:39:00.000+01:00

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.

Measuring and ranking Rich Internet Pages

2007-07-12T09:25:00.000+01:00

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

Rich Internet Applications in your company: Things to consider

2007-07-06T16:01:00.000+01:00

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.

Usability 2.0

2007-06-20T09:38:00.000+01:00

Watch the video about the Web Guild event on Usability 2.0 by Google...

HTML will be there forever

2007-06-14T11:00:00.001+01:00

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.

Web 2.0 ... The Machine is Us/ing Us

2007-06-10T11:36:00.000+01:00

Silverlight or Flash/Flex?

2007-06-10T09:21:00.000+01:00

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:

Flash in the Pan (Scott-Bradley Pearce)

Lights out for Silverlight (Chris Duckett)