networked society
learning + networked society + dossiers + extra
home + what's new + index + comments + rss feed

The software challenge

Although cars are complex machines, the basic use we make of them is standardised. It is only in the accessories and the related uses that there is wider variety. Most accessories are strictly limited to one type of car. Which is why it should not be confused with a modular approach in which the car is the basic unit but there is a wider selection of 'plugin' accessories that fit large families of cars. Information and communication technologies (ICT) are not like cars. First of all, people's needs in terms of communication, ways of working and ultimately ways of thinking are intimately linked to the person they are. Their richness and their diversity reflects the diversity of human beings. As a result, any tools designed to assist or extend these processes need to reflect the diversity of uses they are to be put to. And, in addition, they must not get in the way of the process they are designed to assist. This is what is clumsily called being 'user friendly'. Manufacturers have responded with two major families of solutions: monolithic dinosaurs and modular lightweights.

Monolithic dinosaurs

On the one hand, there are the monolithic solutions in which as many functionalities as possible are offered in one piece of software. The user is given the possibility to pick and chose. This is the "MS Word" logic. Unfortunately the strategy is counterproductive for various reasons. The complexity of the resulting software is a natural barrier to use. No amount of cosmetic reshuffling can hide the fact that the software is bloated with solutions many of which we don't need and which get in the way. A further set-back is the undue length of the learning curve to use such complexity. In addition, such a solution in which all the functionalities are bound together requires much longer development times and requires longer to respond to changing user needs. Finally, until recently, such solutions were isolated islands that had difficulty communicating with other similar software. As a part way solution to these problems, some manufacturers have produced hybrid systems in which a complex software package is opened to plugins. This is the Adobe model. Unfortunately all the problems of the monolithic, functionality-crammed package remain, and if anything, are made worse because they are bound to additional functionalities that the user can add.

Modular lightweights

On the other hand, there are the modular solutions in which functionality is offered in a multitude of small packages (called apps) that can be 'picked and mixed'. For a modular solution to work, there needs to be a platform that connects all apps together and offers a limited number of common functionalities, rather like a scaled down operating system. The modular approach provides a highly flexible system in which users have only those functions they need and they can swop and change apps depending on the circumstances. Each app, being simpler, is much easier to learn to use. Development times are much shorter, making the software potentially much more responsive to changes in users' needs and the general environment. One of the disadvantages of such a modular system is that it requires the user to find the needed apps amongst the growing mass of solutions available. This is why the app store as a model has become all the rage: it provides a way of organising and mastering the available offer of solutions. Another temporary disadvantage of the modular solution is the fact that users have to learn to combine apps to suit their needs of the moment.

Personalisation

The concept of personalisation was all the rage a while ago. Web sites would let people change the colour of the page they were on or shift elements around on that page, supposedly to create a personal space. Nowadays, those beginnings seem puerile and extremely superficial. Subsequently, the evolution turned to displaying content according to the individual's preferences. This semi-automated customisation of content was driven by a vision of the Web as a platform for the exchange of content. In many circles this vision still dominates. This is the space Google moves in which explains why they were caught off balance by a move away from content to functionality in a change they hadn't anticipated. We are currently moving beyond a vision centred on customisable content delivery to the possibility of the Web as a massively customisable space for functionalities. This is the model Apple has popularised, showing a remarkable ability to anticipate and drive massive changes in users' ways of working. Why is it so important that an app or a constellation of apps together correspond to users' needs? As tools for communication, working and thinking, we expect them to assist us but not to get in the way. When they do get in the way, because their functions don't correspond to what we need or, even worse, they don't do what they are supposed to do, they can be irritating if not infuriating and can sap a lot of our energy.

The challenge of responding to user needs

This latest move towards the web as a space for highly customisable functionalities brings glaringly to light a major shortcoming of software production: the weakness of the feedback loop from users to developers. Market logic breaks down here. According to such logic, buyers' choices will weed out the weaker elements leaving only a limited number of solutions considered to be the best because they sell most. Although this kind of 'quality control with a sledge hammer' has its uses, it is ill adapted to this emerging market. The appropriateness of an app for an individual user is not dictated by the number of people who have bought it, but the extent to which it corresponds to the needs and the ways of working of that individual. If the market were to favour such an approach then getting user feedback would be of the highest priority. Recognising the need to find new relationships between software designers and users, research has experimented with collaborative design in which have users or delegates of users work hand in hand with software designers. Unfortunately these complex processes are neither efficient nor scalable.

Do-it-yourself?

A possible answer to the gap between designer functions and user needs may be emerging at the moment. A number of years ago, with the advent of PCs and desktop publishing, individuals began being their own publisher. The move was further accelerated by easy-to-use tools to make web sites and blogs. What if Apps were to go the same way? What if individuals were to start making their own custom Apps? Recent articles point to the creation of platforms designed to let non-programmers build their own solutions. This can only ever be a partial solution as many people are not willing or able to make their own apps but prefer to pull down solutions off the shelf. So the question of suitable forms of feedback from users to software designers/makers remains to be answered.

Alan McCluskey, Saint-Blaise.

Share or comment
| More

learning + networked society + dossiers + extra
home + what's new + index + comments + rss feed


ISSN: 1664-834X Copyright © , Alan McCluskey, info@connected.org
Artwork & Novels: Secret Paths & PhotoBlog - LinkedIn: Portfolio - DIIGO: Links
Created: Juanuary 29th, 2011 - Last up-dated: January 29th, 2011