himalia.net | community blogs

There are rumors out there saying that Lewis Hamilton lose the F1 Championship, last weekend in Sao Paulo, because he pressed the "wrong" button (the Start button) that "restarted the system".

I prefer to believe that is just a Hamilton's perception, maybe he pressed the button while another error was taking place in the background...

I can't believe such a terrible user interaction design in a F1 car! Why would someone want to restart the system during a F1 race? In any case, it should be a very-very-very-difficult-to-press button, something you should press very hard during 30 seconds with both hands and your head, not a yellow one in the steering wheel.

What is sure, is that all the F1 fanatics are talking about this yellow button all around the globe. So, we should take this lesson: good interaction has no publicity, bad interaction does, and you should avoid it.

Apparently, the team is now denying this information and assigns the episode to an hydraulic fault. Anyway, do you believe are they going to admit such a design error? Who knows?

Labels: F1, Technology, Usability cookie

# posted by leovernazza : 10/24/2007 09:58:00 PM  0 comments links to this post

From a long time ago I wanted to post about this topic because it is one of the features I love about the way we can build the user interfaces with Himalia.

Iterating From Paper

Many studies have shown the importance of early prototypes. Actually, recent articles point to paper prototyping as one of the best tools for the development of user interfaces, in a cost-benefit point of view, because it helps to point the UI in the right direction from the beginning at a very low cost (if you don't use it, you may be very wrong, too late).

But paper prototyping has some problems, most of them related to accuracy and imagination:

1. you can't test interaction in a reliable way
2. what you see is not what your get; but mainly, is not what the user see
3. once you have started with the development, paper-prototyping becomes more and more expensive
4. once you have prototyped, you have to translate it to code (and you know that translations produce errors)

I think it's similar to the problem we used to have with integration of software before Continuous Integration, so, a similar solution could make sense also here. Note that what makes continuous integration possible, is the fact we have a tool who knows the process used to create software. That is, our integration server knows about check-ins, tests, fails, people, etc and use them as first-class citizens in the process. I think that more and more tasks in software development should be made as frequent as you can, and automatically when it's possible.

If we wanted to take this approach in the user interface field, I would like to have a tool who knows about prototypes, and let me:

1. start with a little one
2. load most used layouts and patterns from a repository
3. change the initial prototype through many steps
4. test interactivity from the beginning and in each step
5. iterate in seconds from the changes to the user-feedback
6. build the final version as an evolution of the initial prototype (I don't want to throw more paper to the bin)

Getting feedback

One main aspect that should be considered, is that the prototyping task is not finished once you release your application. In other words, usage analysis and statistics have changed the way web applications are built today (and probably part of the commerce' history), turning marketing into a tangible discipline.  World-class web enterprises are already doing "continuous prototyping", regardless if they use this term or a specific tool in the process. Sites like Netflix, Amazon and Facebook are continually modifying the user interface in order to better adapt it to the user needs or/and add new functionalities. 

I think it is obvious, but I will say it anyway: not only web user interfaces should adapt itself from users. The user is the same, regardless he is watching the application inside a browser or not. However, while in the web we can just add a simple javascript to all the pages and get a good analysis, you can't achieve it easily in the desktop (mainly because it lacks of the "addressability" concept).

Putting All Together 

So, in order to accomplish both things, we need not only a good tool in the developer side but also a good framework in the user side to make the full story available for us, because feedback is -at least- as important as early-prototypes.

Prototyping should not be seen as the task involved in building an artifact, but as the continuous process of adapting the user interface to the users needs.

In this way, everything we can do to reduce the time from the development to the user feedback, is going to give us more time to do more iterations, and as with continuous integration, each iteration will increase the quality of our "final" product. 

Labels: Guilder, Himalia, Prototyping

# posted by leovernazza : 10/15/2007 11:17:00 PM  2 comments links to this post

During the MDUCDE 2007 in Seoul, just before my presentation, Asaf Degani did a great presentation about his work on UI correctness. Basically, he exposed how inconsistencies between the user model (what the user thinks about what the application does) and the user interface model can produce very frightening problems. The example he presented was a inconsistence in the aircraft autopilot... (I have the full paper in my notebook but I couldn't find it online).

"The conceptual approach for generating correct and succinct user-models is based on the fact that not all the system’s internal states need to be individually presented to the user".

That is, the user interface is a projection/view of the application. So, the user model is different from the user interface that is also different from the application/machine. Asaf modeled the user model from the user manual and he found that with the aim of reducing information overhead sometimes what the manual teach is not what the application/machine actually does.

Suppose the plane is planning at 5000ft, if the pilot enters 10000ft in the autopilot interface, then the plane will climb until that height.

Then if the pilot set a new lower height after the airplane has passed a special point, then the airplane turns into an undetermined state, and continues climbing indefinitely. The problem arises because the pilot thinks (because the user manual tells him) this special point is calculated in a way that is not the real way. From the pilot point of view, the machine is behaving in a non-deterministic way: sometimes it works as expected, sometimes it doesn't but he doesn't know why. Why did they write the manual in this way?  Well... because with the information available in the user interface, the pilot couldn't calculate the real special point, so they decided to avoid "the details" [1].

Obviously, Asaf concluded that the UI is incorrect because it doesn't give the user all the information he needs to do the task. Maybe the manual is incorrect too, but what actually matters is that they are inconsistent.

From my point of view, this is a particular case of a wider topic that came again and again during the conference, in all the forms you can imagine (from cars to aircraft autopilots and smart factories). When you use different languages for each world you have to do a lot of extra work in testing to ensure you are keeping it consistent, because basically, what you are doing is to add more translations. The bigger the difference between the languages, the bigger is the probability to produce translation errors between them. In some fields, it may be still too difficult to unify both worlds in one only language, but in others, we are just not taking the right approach to solve the problems.

However it also happens in other models: software design, implementation, etc. If we were able to merge them, we could avoid testing the translations.

Some time ago I had a similar conversation with Andrés about this topic (he had written a post about it). We agreed that when you express things at the right abstraction level, testing is useless, because it becomes a tautology. Would you test that the += operator is working properly in C# or Java?. I wouldn't. 

To put this in the context of Asaf's work, if the aircraft autopilot and the manual are made with the same language, his work would be useless. You wouldn't need to prove the UI correctness because it will always be consistent with the user model [2].

Obviously, taking this approach ought you to test your high-abstraction language... it is a trade-off, but in most of the cases this is a far simpler and better limited task than testing all the user interfaces, and sometimes it can also be "outsourced for free" as we do with the += operator.

I think Eugenio Pace said exactly this in a different way a week ago, talking about SaaS in the Genexus Meeting. He proposed something like the Law of Conservation of Mass for complexity and software. He said: you can't avoid complexity, but you can redistribute responsibilities and that is what SaaS is about.

I think it is also what DSLs are about, translating complexity until some day, when magically a lot of testing and translations disappear and you can focus on what is really important for your business.

[1] Yes, this is how an aircraft autopilot works today, but don't panic, it is a very strange situation and I believe they can take the airplane control again in any case. I can't remember the special point name, and the exact calculation, but it's not the important thing here.

[2] Asaf is currently working on how to automatically generate the UI from a reduced user model and avoid the testing by producing correct user interface by design.

Labels: airplane, Conference, DSL Tools, MDUCDE

# posted by leovernazza : 10/02/2007 06:52:00 PM  0 comments links to this post

Ingredients: An elastic eyes-cover and food aluminum paper.

It worked for 10 hours avoiding the cold air directly in my face ;) 

Labels: airplane, Travel, UX

# posted by leovernazza : 10/02/2007 02:18:00 PM  0 comments links to this post