August 30, 2010
This entry was motivated by @jobrodie’s recent musings on redesigning the way “Stop” buttons on London buses work
To quote the relevant part of Jo’s entry:
London buses do seem to vary in how much noise they make, and probably most of it is for the benefit of visually impaired people. Whenever someone presses the button to get off the action of pressing makes a ‘ding’ sound. But if someone else presses another / same button on the bus, as often happens when lots of people are getting off at the same stop, then each button press ‘dings’ too. Sometimes when people are impatient they repeatedly press the button to indicate their annoyance – fortunately not too often.
My argument is that this ‘ding’ need only happen once, as once the button’s been pressed the driver is going to stop the bus at the next stop and further button-pressing is redundant. There’s a bit sign that lights up at the front of the bus to say it’s stopping, and there’s usually another one halfway along the bus, and I think there’s one on the upper floor too. If the buttons themselves were able to light up once pressed (how difficult would it be?) then everyone could see that the bus was stopping.
The first interesting assumption is that sounds are mostly for the benefit of visually impaired people. Actually, they’re for the benefit of people who are not looking – because they’re watching out for the next stop, reading Shakespeare on their iPad, or debating policy on Twitter. (They could also be playing Sudoku, but let’s assume that all these people who can’t be bothered to use their eyes are being inattentive because they are distracted by something Very Worthwhile and Important.)
The annoying “ding” after the button press provides clear feedback that the button press was indeed successful. This is important, because many users like to get immediate feedback on the success of their actions. Having the button light up once it has been pressed would constitute visual feedback. But visual feedback only works if it can be seen. I have often cursed power-saving LEDs that could only be read from a strange angle, especially in direct sunlight. I have also often grabbed the pole behind or in front of me or beside me to indicate that the driver should kindly consider coming to a screeching halt at the next stop. Because in Edinburgh buses, not every pole has a stop button. Even worse, the button can only be seen properly if you sit right in front of it – I would probably have trouble detecting whether the button was lit from the window seat.
The solution Jo proposed would require a feedback loop from the central console to ensure all buttons light up once one has been pressed, and all lights need to be cleared once the bus has left the stop. A similar feedback loop would be required to stop the little bells from making a sound once one of the buttons has been pressed. Many steps, many potential causes of havoc, whereas the current sound is probably a simple little bell, completely localised, and easy to maintain.
The final nail in the coffin of the visual interface however are the commuters themselves. Jo mentions that there are several visual signs that indicate whether the bus will be stopping. Would the very same people who can’t be bothered to check the (presumably – hopefully) clear visual signage before they press bother to check the illumination on the button, especially if they have to contort their swan-like necks to see it?
So, people don’t care, people reach for the stop button in a reflex action, people don’t check, people are impatient, and one ding leads to another. The only consistent, easy-to-implement solution would be to abolish the “dings” altogether, or to make them softer without compromising their alert function. Somehow.
(The drivers probably learned how to tune out those beeps during their first week on the job. This may be one of the reasons why, on Edinburgh Lothian buses at least, the bell for the disabled space has a special, more insistent sound. Very annoying if it comes into repeated contact with a besuited commuter bottom during rush hour, I can tell you.)
As part of the Scientiae carnival, Karina asks what tools we couldn’t live without. Although I’m an experimentalist, I don’t work with glass or microbes, like most of the science blogosphere I read, but with silicon and people (-> fanciful term for human-computer interaction).
My favourite tool is not an experimental platform – as a respondent to one of our project’s questionnaires noted sagely, “Technology breaks!”. Personally, I am a great fan of good old-fashioned pen-and-paper, which is extremely unlikely to crash and lose data of a whole experimental session. Rather, my favourite is a tool for analysing experimental results and modelling the resulting patterns of behaviour and preferences.
One letter: R
R is a programming language for everything statistical. It’s free, it’s open source, and it’s being maintained by statisticians for statisticians. Its origin means that it is a pain to learn. It takes a while until one has cleared a path through the data structures, including the various conventions for extracting information from objects that store the results of painstaking statistical analyses, and I am still often baffled myself.
But the payoff is magnificent. Clear (modulo coding ability), open, replicable analyses. R is the ultimate in replicable research. If you give people your data set and your source code, they can repeat every single step of your reasoning. There are no paywalls, no limits of affordability, no packages that are indispensable for the analysis, but that your department hasn’t paid for.
R’s free, open source origins are especially important when we’re talking about the analysis of data that is publicly available, data that can be – and should be! – analysed and reanalysed by citizen bloggers and journalists.
An excellent example are the comments on a recent Posterous post by Ben Goldacre on the reanalysis of a publicly available data set Several people are discussing their statistical analysis in terms of the code they used to generate it, which makes the whole discussion far more transparent. While both the Stata and the R code are useful, only the R analyses can be quickly replicated by anyone with a computer and an internet connection (download R, read in data, execute code, done).
R is even better when used in synergy with LaTeX – essentially, the resulting research papers are completely self-documenting. I don’t write any other way, except when forced to collaborate with first authors that insist on Microsoft Word. Even then, I try to document the main results of my analyses using R and LaTeX, although laziness sometimes gets the better of me and I copy percentages straight into Word.
Relying on free, open-source solutions like R and LaTeX is particularly important when you change institutions a lot. I have what could legitimately be called a patchwork career – after three years as a lecturer, I spent three years in industry, where there were no funds for SPSS, so I was glad I took the time to learn basic R at university. Afterwards, I worked for four different universities in two years, a jumble of small, part-time jobs. Using free software as much as possible made me independent of the particular budgetary constraints and preferences at each institution. Now that I have been in the same place exclusively for five years, I make a very conscious effort to stay independent. As we all know, science budgets wax and wane, and periods of relative dearth are common. So it’s even more important to ensure that you have the tools to keep publishing when the funds run dry and you need to beef up your CV for the next round of applciations.
Especially when the tools are as excellent as R.