Monday, June 07, 2004
In search of the no frills Ryanair Communicator
Writing in the Sunday Times 2 weeks ago (I'm behind, I've been on holiday), Jeremy Clarkson tells of his search for a no frills, "does exactly hat it says on the tin" mobile phone. He moans at length about the problems he experiences with his mobile and the mobiles of others, and complains about the plethora of new features that find there way into new phones without (in his opinion) any real advancement of the underlying functionality: talking to other people without poor audio, network drop-outs etc.
A couple of things struck me about this piece. Firstly, it's an eloquent demand for stable devices that do a small number of things really well, rather than offering us a range of features we will hardly (if ever) use, at the expense of this reliable basic functionality. Predictably enough, Clarkson compares the development of mobile technology to automotive trends, pointing out that only once the basic workings have been to honed to perfection do we start adding extras such as TV screens and satnav. there's an old rule, the "90:10 rule", that tells us that people will use 10% of the available functions 90% of the time. of course this is a fairly loose rule, but real usage of complex devices is probably subject to something like this.
The other thing about the piece is that Clarkson moans about his phones and his network problems as if they were one and the same. So in demanding a phone that doesn't cut out when he "goes behind a tree", he is asking for an improved device. well, that's the implication anyway, which got me thinking about people's perceptions of services and devices as one. as we move towards distributed, ubiquitous computing, there are some important questions to be asking about how people attribute blame when things go wrong. We know that people tend to treat complex devices as if they are entities in their own right, so bad network coverage could be attributed to a bad phone, so might poor web services might be attributed to poor client software and hardware?
Writing in the Sunday Times 2 weeks ago (I'm behind, I've been on holiday), Jeremy Clarkson tells of his search for a no frills, "does exactly hat it says on the tin" mobile phone. He moans at length about the problems he experiences with his mobile and the mobiles of others, and complains about the plethora of new features that find there way into new phones without (in his opinion) any real advancement of the underlying functionality: talking to other people without poor audio, network drop-outs etc.
A couple of things struck me about this piece. Firstly, it's an eloquent demand for stable devices that do a small number of things really well, rather than offering us a range of features we will hardly (if ever) use, at the expense of this reliable basic functionality. Predictably enough, Clarkson compares the development of mobile technology to automotive trends, pointing out that only once the basic workings have been to honed to perfection do we start adding extras such as TV screens and satnav. there's an old rule, the "90:10 rule", that tells us that people will use 10% of the available functions 90% of the time. of course this is a fairly loose rule, but real usage of complex devices is probably subject to something like this.
The other thing about the piece is that Clarkson moans about his phones and his network problems as if they were one and the same. So in demanding a phone that doesn't cut out when he "goes behind a tree", he is asking for an improved device. well, that's the implication anyway, which got me thinking about people's perceptions of services and devices as one. as we move towards distributed, ubiquitous computing, there are some important questions to be asking about how people attribute blame when things go wrong. We know that people tend to treat complex devices as if they are entities in their own right, so bad network coverage could be attributed to a bad phone, so might poor web services might be attributed to poor client software and hardware?
Comments:
Post a Comment
Atom
RSS