Wandering Thoughts archives

My view on window titlebars and when they are good and bad

I mentioned in yesterday's entry that I included the window's titlebar in my little screenshot of xrun because I considered it part of the program's interface. When I wrote that it was a quick aside, but in thinking about it I think that this is very close to being my defining view of when window titlebars are worthwhile.

In many environments, window titlebars are not optional; you just don't get to turn them off on Microsoft Windows or Mac OS X (at least not as shipped). However, old-fashioned window managers for X Windows have always let you turn them off, either totally or selectively, and I have been selectively turning them off for years. Depending on what I'm doing, it's very common for most of my visible windows to not have titlebars.

At first it may sound crazy to talk about titlebars as an element of the program's interface, since they are usually supplied by the system. However, titlebars are clearly part of the visual appears of the program as a whole, and all of the appearance of a program is part of its interface. And once they become an element in the program's interface, it's perfectly sensible to ask if they are a useful element or a waste of space, just as you'd ask the same question about other interface elements.

Of course the situation is more complex than this. One of the things that titlebars do is they create a uniform interface; regardless of the program, you know that you find certain information and certain interface elements in specific places and they behave in specific ways. Just as with other standardized GUI bits, this has the cost of not necessarily being ideal for any particular program but the gain of being, well, uniform. So even if titlebars are not a useful interface element, it may be important to include them just because they are a standard one.

Having said that, pretty much every system has conceded that titlebars aren't always useful interface elements and has created categories of applications that can leave them off. Usually we don't call these 'applications'; we call them 'applets' or similar terms, and they live in a special small screen area where the rules are different.

(Well, mostly this is how people have gotten rid of titlebars. Even on systems that try very hard for standard window decoration, there are programs that decide to be special and go their own way. For example, people seem perfectly happy to let music players look nothing like normal programs.)

Thinking about misunderstandings (in systems)

One of the things that I am trying to do now with the web application I'm building is to think about how people may misunderstand and misinterpret it.

When I create a system I know how it's supposed to work and be used to do particular things, and I write the code and create the interface to fit this. Of course, how to use the system is clearly obvious to me. But it's not necessarily clearly obvious to other people, and so I need to turn a sceptical eye on my own work and ask myself what people could get wrong. What perfectly reasonable alternate interpretations could they put on the labels of the interface? If they are starting from scratch, without my knowledge of the system, how would they try to do some particular operation that they want to do? Once I've figured this out, I can go in and fix the system in various ways so that these foreseen potential misunderstandings won't cause problems.

All of this sounds really wishy-washy and theoretical, so I'll give you a practical example drawn from the new account request system.

In the system, the normal situation is that people basically request accounts from some particular sponsor. That sponsor can then ignore them, approve their request, or reject it, and so the sponsor interface offers those choices. Now, when a bunch of new graduate students are accepted there is a somewhat different procedure to get pre-approval from all of their various supervisors to be; the Graduate Office enters a list of new students and their supervisors, the requests are sent to the supervisors for approval, and when they are approved, the new students are prompted to complete their account request by providing a login name.

It sometimes happens that the Graduate Office data on who is supervising a new student is wrong. When this happens, what my design wants the supervisor to do is to change the student's sponsor; if they know who the correct supervisor is, they can directly change the sponsor to it, and if not they can send the student back to the Graduate Office. There is a procedure for this, and help text telling the supervisors to do this.

When I was looking at this recently, it struck me that a completely natural thing for a supervisor to do instead was to reject the account request. After all, they're not sponsoring the student. This was bad, because a rejected request disappears entirely (rejection is assumed to be a permanent condition). My fix was to change the code so that if a sponsor rejected a request that looked like an incoming grad student, the request was instead quietly reassigned back to the Graduate Office.

(It's also now obvious to me that the system needs a somewhat convenient way to undo rejections; sooner or later, someone is going to make a mistake.)

Sidebar: one view of this misunderstanding

The classical view of this sort of misunderstanding is that the users have a different conceptual view of the system than the designer does. In this case the mismatch comes from the sponsor having a local view of their actions, when the system actually has a global view. To the sponsor, 'reject' just means that they reject the request; to the system, 'reject' means that the request is rejected, period, globally.

The challenge here is that sometimes the local action of 'I reject this request' implies the global action and sometimes it doesn't. When people make requests themselves, their listed sponsor rejecting them means that their request goes down in flames. But for new graduate students, really only the Graduate Office gets to declare that a request is invalid for some reason (the student has declined our offer, for example).

(If I wanted to complicate my schema design instead of just doing some code hacks, this suggests that I could give account requests an 'owner' field. 'Reject' would only have global effect if done by the owner; otherwise, it just reassigns the request back to the owner.)