Tuesday, October 02, 2007
Abstraction -vs- Testing
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
How To Solve A Conditioned-Air Bug?
Ingredients: An elastic eyes-cover and food aluminum paper.
It worked for 10 hours avoiding the cold air directly in my face ;)
Sunday, September 09, 2007
Usability Cookie - Airplane entertainment system
I get very frustrated using the LAN entertainment system because of a stupid failure in the design of its Navigation Model. I want to share it with you, because little things like this are the ones that make the difference between great and bad experiences. In this case, the difference between entertainment and a post with bad-publicity for the company ;)
Interaction with the entertainment system.
I was just looking for some music to help me overtake the 11-hours flight from Los Angeles to Santiago, so I turned on the individual entertainment system I had in front of me. It presented a friendly menu where I selected Audio and then Library. Then it showed an index of categories, and the albums by category at the right pane. As the display wasn't too big (around 10'') the right pane just presented 6 albums, and you had to use the page controls to explore each category in depth. I selected a Massive Attack album that was in the 13th (of 24) page, so, I had to pass 12 pages...
Suggestion #1: The average category had 10 pages and the only way of exploring them was just with a next/previous page control. A scrollbar was best suited for that case (a user that knows where is going can move faster); other solution could be to add a page index (like the one in the Google result page).
But I couldn't listen to the music because after my choice I received a "This selection is currently unavailable. Try again later" error message.
Rule #1: Be proactive; don't wait for the selection to show the "unavailable" message. If you can, remove (or disable) the unavailable elements before the user have to try them.
After such an imprecise error message I couldn't realize what the problem was, but anyway I was ready to try with another album. But for my surprise, after the message I had to start from scratch again because I was redirected to the Home screen!!! Why? Is this a kind of penalty for trying to listen to Massive Attack? Well... ok, I made the whole process again and selected the Jack Johnson's album In Between Dreams... but I had the same problem again. So, I desisted and continued with the book.
Rule #2: Never redirect your user to the home page unless there is no other choice. Try to conserve the context always.
It this case, the obvious decision is redirecting the user back to the album selection screen remembering the category and the page (that is, doing a good BACK). I didn't count the clicks I needed to get frustrated but they were surely around 30. In this case, 15 clicks in average each time you want to pick a song added to a intriguingly high response time... seems a little expensive for an application with a so bounded functionality.
Navigation Modes. Above is the suggested, below the current.
From my point of view, the problem that derived the current design of the system is obvious: it is a clear case of a stupidly-use-case-driven-application. I can see the analyst writing the Play Album Use Case: "...if I can't play the album, show error. Then, end".
Rule #3: Think always in the step after the end of a use case, both in success and failure scenarios.
Actually, this rule is the opportunistic link pattern put in other words. For instance, after you complete the buy process in Amazon, they provide you similar items to continue buying. The opposite is to present a "Thank you for buying in Amazon message" where the only choice for the user is to close the browser, that is what the entertainment system does.
There are many examples out there of stupidly-use-case-driven-applications, one that always surprised me during my university days was the Beadleship's site where you had to log into the system twice if you wanted to inscribe for two courses... the use case should be something like: the user select Inscriptions from the menu, then enters his user and password, then select the course, end.
Labels: airplane, Travel, Usability, Usability cookie
