It started as a task to understand how Android works and see what user experience (UX) opportunities it offered. Soon realised I’d have to learn Java which was going to turn my short exercise into a longer trial – ho hum.
We’ll, it turns out that the designers of Eclipse really do understand UX. My background in Prolog, Basic, C and Pascal meant I had the fundamentals for Java, but context help provided in the Eclipse IDE made me very productive, very quickly. Mmm… I could learn from Eclipse.
Rather than producing my n’tieth “hello world”, I wanted to develop something that needed mobility and would benefit from a tablet form factor. Through circumstance and coincidence, I opted for volleyball stats. At the time, the established software for collecting stats needed three pairs of analysts; one pair for each team and a backup pair. Surely, my Android app and me could do better than that.
Volleyball, in its indoor incarnation, is played by two opposing teams of 6 players who try to ground the ball in the opponent’s 9m square court. In the way is a net raised to 2.24m for women and 2.43m for men. Each team can touch the ball three times before it has to cross the net so teams typically use specialists players to prepare (touches 1 & 2) for the best possible attack (touch 3). The average rally takes 5 seconds which typically involves a serve from one team followed by three touches by their opponents. This means our analysts have just over a second to record details of each “touch”.
The established software also needed users to learn a set of codes so learning curve was extensive. I would produce a solution that was easy to learn and easy to use. I talked to some of my club’s coaches about stats and to one of the national programme analysts. As well as playing, I watched games and visioned actually recording stats myself. The concept was hatched.
I’d use the tablet’s touch interface to echo each player’s touch of the ball, indicating whether their contact was positive, negative or neutral. No complex codes. To make it easier for analysts, I’d also provide a visual layout of the court so that their actions could mirror the ball’s flight during a point. Finally, given that we’d be building up such a detailed picture of the game, we could feed this back to the analysts – they’d have their own live scoreboard.
Fast forward through the coding, unit testing and system testing to a test, on my laptop, at an actual game. I knew that volleyball was quick but I was a little taken aback. Moving the mouse and clicking in the right place were a struggle but hopefully the directness of a touch interface would be easier. The bigger challenge was watching the game and re-orienting to the app, multiple times in a few seconds. I had to accept that it probably needed a spotter (to watch the game) and a recorder (to capture what the spotter told them). Disappointing; but 2 down from 6 wasn’t bad.
The next milestone was testing with an actual tablet. Much easier to work with than a laptop and mouse but still a challenge. I did ponder restricting the app to only produce stats for one team but rejected this change as it didn’t take account of skill improvement over time and would deny those with faster brains and fingers. I did, however, allow for analysts to collect for both teams or just one – their choice.
So, maybe two analysts, maybe four but easier to learn and a richer more informative environment. Added some utilities (eg sharing) and did a little hardening so good for beta.
Why is it an example of good UX?
Rich, informative environment (eg scoreboard) helps memorability.- Information is grouped logically and some is presented visually (eg substitutions). This helps learning.
- Visuals and positioning (eg court layout) are used extensively for communication and control so the app is easy to use.