Sidebar API usability study

We just finished up a usability study investigating the new Sidebar and Tile APIs.
We asked participants to write code to accomplish the following:

  • Create a tile that says 'Hello World'.
  • Create a tile that displays an image covering the whole tile and that additionally
    displays a smaller image on top, only whenever the user mouses over the tile. Then
    add a flyout to the tile which, when activated, displays both images, one underneath
    the other.
  • Create a tile that contains a list box and two buttons. The buttons should be labeled
    'New task1' and 'New task 2' respectively. When the user clicks one of these buttons,
    add a new entry to the list box that is the same as the label of the button that was
    pressed. Then create a properties dialog for the tile. The properties dialog should
    contain two buttons labeled 'Change to Task1' and 'Change to Task2' respectively.
    When clicked, they should change the labels on the buttons on the main tile to 'Tile1'
    and 'Tile2' as respectively.

We got some interesting results from this study, particularly about the Tile API infrastructure.
I'd be interested in hearing your feedback regarding these scenarios. If you have
a copy of the bits that were handed out at PDC, open up Visual Studio, choose New
Project and then create a Longhorn Tile project and then start working on the tasks
listed above. I'd love to know how you get on.

Comments (6)

  1. Frank Hileman says:

    It is good that usability is being tested for Avalon. Looking at the docs online, I have the feeling it is one of the least-usable APIs I have ever seen. The xml looks easy but the API is very complex and over-engineered.

  2. Steven Clarke says:

    Thanks for the feedback Frank. Can you give some specific examples of where you think the API is too complex and how it could be made more usable?

  3. Frank Hileman says:

    Weak-typing, for one. Using an Object instead of a strongly typed class or interface does not simplify a property or function, it just makes it seem simpler in the documentation, but harder to use overall (what Anders calls "simplexity"). Weak-typing is necessary in design-time libraries, where the members on a type cannot be known before hand. But to use them some extensively at run-time, in conjunction with reflection, defeats some of the purpose of a strongly typed language. The xml looks great but the code does not.

    I see weak typing used in some of the most fundamental places in Avalon: DependencyObject.SetValue, GetValue, etc. These look like design-time API’s, not run-time APIs. And they seem like very low-level implementation details that could have been hidden.

    You may have noticed that some of the things that are normally properties of an object are squirelled away in another object (dynamic properties). Not only is this clumsy and unintuitive, it has the usual weak typing problems. As long as this implementation detail is hidden behind strongly typed, real properties, it is not a problem.

    The Decorator pattern is a fine one, but it is another low-level implementation detail. I don’t think users want to learn this design pattern. The Decorators should be hidden behind something more friendly. For example, if a user wants to change the rotation angle on a rectangle, the first thought will be rect1.Rotation = angle. Consider how complex this is when using TransformDecorator. The "decorator" could have just been internally an optional property in the rectangle — no need to expose that detail to the users and force them to jump through hoops, and it would have been just as optimized.

    The Changeable class. This one really has me stumped. I can’t figure out why the concept is there at all. Why simulate mutability on immutable objects? Why not just make them mutable, if that is what is needed? This looks suspiciously like over-engineering to me, or some sort of premature optimization. I doubt any users really want to learn about Changeable.EmbeddedChangeableReader. If internally, MS wants to use something like that, that is fine. How to fix it? Make the objects mutable.

    Little things, like Length to represent a scalar. It is a scalar, why not use a double? This is what users want.

    I think I could write a whole book here. Looking at how many abstractions the user has to juggle in their head just to understand simple buttons and shapes… it is incredible. Just count the number of classes involved, the number of complicated concepts. Well, maybe I will post more later, write something up in more detail. I don’t mean to disrespect the hard work in that API, but this is supposed to last a long, long time. I think the "less expert" users will just cry when they try to use it, outside of the xml. Plus, exposing all this low-level detail will make it harder to change later.

  4. Steven Clarke says:

    Thanks for the comments Frank, I’ll pass them on to the team.

  5. I added a response to the above question about the "Length" type to my blog. You can find the response at

  6. I added a response to the above question about the "Changeable" class to my blog. You can find the response at

Skip to main content