Freigeben über

Aesthetics, language design and usability

  • Artikel

Here's an
interesting interview with Anders Hejlsberg in which he makes some points about programming
language usability.

Anders says that "good language design
boils down to assembling a team of people who have good
taste." I couldn't agree more. It's absolutely vital to understand
your target customers so that you know what they will like and what they won't like.
Developing that sense of good taste takes time and experience. You can build
that experience up by designing languages or APIs that you yourself would like to
use, if you consider yourself a good representative for your target users. But what
do you do if you are designing a language or API for a group of users who you don't
represent, such as children?
This is where usability data is useful.

One of the biggest benefits of doing any kind of usability study is not the list of
usability issues or bugs that you collect. Instead, it's the increase in customer
empathy and understanding that comes of watching someone work and observing their
work style and behavior. It's illuminating to see how differently someone thinks
or works to the way that you would in that same situation. Gaining such an insight
is incredibly useful when you are designing any kind of product, be it a programming
language, an API or a GUI, especially when you are not representative of your users.
Instead of basing design decisions on what you would do, you can now base design decisions
on what your users would do.

Anders suggests that you don't get as high a yield from usability studies for language
features as you do for IDE features. I think this is a reasonable statement to make
when you compare the results obtained from a 2 hour usability study on a programming
language or API with the results obtained from a 2 hour usability study on a GUI (with
some exceptions - see below). Most APIs and programming languages take more than 2
hours to really get to grips with. Instead of just relying on one single two hour
session per participant, API and programming language studies tend to demand more
longitudinal studies where you can observe developers working with the API or programming
language over a longer period of time, measured at least in days or weeks instead
of hours (the exception is an API or language that supports tasks that you expect
users to be able to complete in much shorter periods of time).

I'd argue that APIs and programming languages are interactive products, just as GUIs
are. They expose affordances which
indicate to the user the actions that the artifact makes possible. The big difference
between GUIs and APIs or programming languages is how those affordances are discovered
and learned, not whether or not they exist. That interaction between the user and
the perceived affordances of the product is an important aspect that needs to be understood
and designed. Usability studies are a very useful tool to help build up an understanding
of how that two way interaction between a programmer and the API or programming language
develops over time. With a programming language or API the interaction typically takes
place over a longer period of time than with a GUI, hence the need for studies that
take place over a longer period of time than GUI based studies.

As always, data obtained from usability studies should not be the only source of data
that you collect about your design. It's always important to get a broad spectrum
of data. But usability data should be part of that spectrum.

Comments

  • Anonymous
    October 15, 2003
    I think you are right that APIs and languages have become interactive products, and that long-term usability studies are useful. It is great that you are doing this!When I see many people use development tools today, especially application level programmers, it often looks like what I used to call "hacking", just poking around, trying this and that, until it works.But there is another type of programming, that involves more design, and more thought about what Anders called "good taste". This would be the developement of larger APIs that cumulatively create a system of abstractions, or the development of a language, very similar. When creating these things, one is trying to guide the user toward certain ways of performing tasks, that lead not only to smaller code, but to less bugs and maintenance work in the long term.I can see how a long term usability study can be used to evaluate such an API or a language. All of your points are excellent. Still, usability studies are no substitute for experience and knowlege on the part of the API/language desginer.One problem I see is the experience and skill of the developers participating as users in the study. I think the usability study would be very good at evaluating the API for application level or inexperienced developers. But now consider evaluating the rarer developers, the ones that need to create another API on top of yours. This is where hidden flaws and missing functionality in the evaluated API start to come out. But it would be a long term study indeed, and those developers, and the tasks they perform, are harder to find.
  • Anonymous
    October 15, 2003
    Even GUI usability studies should be long term. I learnt this many years ago when I was designing GUIs for Investment Bankers. I used to design GUIs that were nicely laid out, but I discovered that after initially liking them, the users then started to dislike them.What actually happened was that when leaning a new application, the users wanted nicely laid out GUIs; but once the app was learned, then screen real estate mattered. They wanted as much information crammed onto the screen as possible.Therefore, ideally you needed 2 screens per 1 old one i.e. a nicely laid out one and one crammed with information. Unfortunately, I never had the time to design 2 screens every time. Instead I went down the cramming as much information as possible on the screen. This is because the nicely laid out screen was only used when learning the application (usually 2-4 weeks) whilst the crammed screen would be used most of the time i.e. after the first 3-4 weeks
  • Anonymous
    October 17, 2003
    These are great points. Usability studies are definitely not a substitute for good design. Hopefully I haven't given that impression.Regarding the skill level of the developers who take part in our studies, we do our best to make sure that the people who come in are as close a match to our target users as possible. We have a pretty large database of developers who have registered to take part in a study. Given the size of the database we are very fortunate to be able to recruit people with a wide variety of skills and experience.I agree with you Alex, designing a product for long term usage is very different to designing a product for one time or short term usage, whether that product is an API or a GUI. It's important to know the most common usage pattern and design with that in mind and to make it easy for users to transition from the learning phase to being competent or expert with it.Thanks for the comments.