Feedback, apps and development

The number of available Apps has grown exponentially as they have become progressively smaller and more modular and their use has become widespread due to the existence of online stores. The ecosystem that links uses and users to Apps to developers and platforms is extremely complex. Efficiency and satisfaction depend on the possibility to combine Apps to carry out specific tasks in given contexts. Development cycles become ever shorter and developers have to handle the fact that the use of software depends on individual contexts. In such an ecosystem, the need for improved feedback from users to developers and designers is essential. It is not, however, always recognised as such.

There are a considerable number of channels through which feedback can flow to developers and designers but it often the neglected side of the relationship. Many channels of feedback are suited neither to the complexity and immensity of the field nor to gathering and handling the extremely fine-grained, often individualised information that is needed. In what follows, we will look at some of the channels that feedback uses and what their limitations are. But before we look at channels of feedback, we first need to consider the nature of the feedback being provided.

The nature of feedback

Bugs come first: defects, things that clearly don’t work and that are replicable. Given the complexity of platforms and related apps it is not always self-evident that the problem is actually a ‘bug’. Let me give an example. Despite the amiable assistance of someone who knew much better than I did, I spent ages struggling to get registration on ELGG to work as I wanted it to only to discover, after much frustration, that one of the settings was incorrect. The cause of such problems can lie in insufficient documentation, a failure to read the documentation, or the unclearness or unnecessary complexity of the software interface. That people have difficulties is also a form of feedback that needs to be taken into account. Beyond reporting bugs there are questions of usage that fit into the improvements category. The software may function correctly yet ergonomically or in terms of usage the way the software works is cumbersome or inappropriate. Here’s a silly example about adding links in text. The window used to add a URL is identical in ELGG and WordPress. The only difference being that the ‘insert’ and ‘cancel’ buttons are inverted from one platform to the other. As so many people are accustomed to WordPress why did ELGG do things differently? Finally their are major enhancement requests: what additional functions people would like to have from the software.

Note there is a post on WordPress about posting to support forums. It contains some sensible advice on how to post feedback, amongst other things.

Mass production or the the loss of feedback

With industrialisation and subsequent mass production, contact between customers and producers progressively unravelled leaving sales statistics as the surviving indication of demand and customer satisfaction. Companies were forced to commission costly surveys to try to get an idea of what customers wanted. What’s more, users were accustomed to making do with the limited choices available on the market. There were rarely channels open for them to express dissatisfaction and possible wishes, had they wanted to.

Internet and software

When it comes to software, the advent of the Internet has made it possible for users to provide more extensive feedback to developers. Some platforms have built in automatic or semi-automatic systems that send back information to developers when an application crashes. In addition, users can provide feedback, often through a form on a web page where it is clearly stipulated that no dialogue will be entered into by the firm because of the volume of feedback. The tone and content of such alerts is such that the absence of dialogue is seen as self-evident and it goes without saying that the user will naturally agree. In a world increasingly dominated by social media and the active exchange between people, such blunt refusals of dialogue stand like unwanted walls barring the road.

App stores

The rapid growth of specialised places to procure Apps online, like Apple’s App Store, which have built in rating and comments systems offer a potential source of feedback. Elsewhere rating and feedback systems for books, for example, in online shops like Amazon or Abe Books, aim essentially at helping orient other buyers. Feedback is only marginally designed to modify products. Although the intention of an App Store in providing rating and comments is also to help users choose apps, the material offers some feedback to developers and designers that can influence future products. With theĀ  widespread use of social media people are used to providing details of problems or drawing up wish-lists.

Open source projects

Open source projects also have mechanisms to gather feedback from users and developers. ELGG, for example, has a platform where people can register bugs or suggest new functionalities. The complexity of the bug tracking process and the investment needed to plough through the hundreds of existing ‘tickets’ makes the task of providing feedback daunting. Announcing bugs and enhancements to the Moodle platform goes through a democratic process involving people voting for which issue should be dealt with. Someone providing feedback is expected to invest time not only on verifying that the issue is not already covered by one of the thousand other issues already filed but also to promote the idea so it gets votes. Such a system heavily discourages casual feedback and silences the voice of the everyday user who has problems but no the time or the will to become part of the development community. Yet these numerous people are just those whose voices need to be heard.

Participatory design

(to be written)

Social networks

Social networks accustom people to publishing details of difficulties they might encounter with Apps and to insisting on the functionalities they would like to have. They also provide multiple channels for such feedback. Let’s take an example. When Goodreads added a barcode reader to its iPhone App, the developer announced the function, opening a discussion thread on the Goodreads platform. The existence of this thread was prominently announced in the Goodreads monthly newsletter. People reacted to the news by using that thread to provide feedback about bugs, suggestions and requests for help. The developer was on hand to dialogue with readers. Such a situation is largely possible because of the attitude of the developer and the fact that his App is part of a service to an existing community that is accustomed to discussing. Note that this feedback channel although lively and well-used, is probably only temporary.

Temporary conclusion

We are still far from finding a satisfactory form for feedback from users that enables users to engage in the development process in a user-friendly way without binding them to a system beyond their time and means. (…)

Diigo Facebook Blogmarks BlogLines del.icio.us Digg Google Google Reader Newsgator StumbleUpon Technorati Plugin by Dichev.com
This entry was posted in Basic. Bookmark the permalink.