Achtung - das Bamblog wird seit Mitte Oktober 2007 nicht mehr aktualisiert. Bitte besuchen Sie mein neues Weblog unter http://www.schmidtmitdete.de. Danke! - Please note that this blog is no longer active. You can find my new blog at http://www.schmidtmitdete.de. Thanks for visiting!
danah boyd [weblog] beharrt nicht nur auf der Kleinschreibung ihres Namens, sondern sticht immer wieder durch Vorträge und kurze Essays rund um Social Software hervor. Vor einigen Tagen hat sie einen hervorragenden Vortrag veröffentlicht, den sie Anfang März bei der O’Reilly Emerging Technology Conference gehalten hat: "G/localization: When Global Information and Local Interaction Collide". Sie beschreibt darin die Wechselwirkungen und Dynamik von Nutzungspraktiken bei Social Software, also dem Zusammenspiel von kulturell gerahmten Gebrauchsweisen, sozialen Beziehungen und dem Software-Code.
Am Erhellendsten fand ich eigentlich den Teil, wo sie auf die Konsequenzen dieser sozialen Prozesse auf die Software-Entwicklung zu sprechen kommt. Erfolgreiche Entwickler von social software sind in ihren Worten "embedded observers" bzw. "design ethnographers", die in starkem Maße an den Nutzergemeinschaften teilhaben, die ihr jeweiliges Software-System unterstützt [1]. Sie sehen ihre Software nicht als ein Artefakt, das man den Nutzern vorsetzt, damit diese gefälligst Dinge zu tun haben, die den Entwicklern vorgeschwebt haben, sondern vielmehr als Grundlage für das Entstehen und den Wandel von sozialen Netzwerken, deren Teilnehmer ihre eigenen Vorstellungen einbringen.
What they’re doing methodologically is very unique in software development and is not yet part of the standard practices for developing social software, although it should be. Embedded observation allows developers to understand culture. They are doing a form of ethnography, the method used by those seeking to understand culture. They understand culture by living amidst the cultural natives, trying to understand practices from the perspective of the people engaged in them. They are trying to make sense of how the symbols came to be and how the culture is maintained. They are doing so in order to understand culture and to help shape the architecture to support the culture.
Durch das eigene Eintauchen in die Kultur, d.h. die geteilten Vorstellungen, Routinen und Erwartungen einer Nutzergemeinschaft, kann diese besser verstanden werden als durch bloße Nutzerstudien oder Marktforschungsbefragungen.
Embedded observation takes into account the cultural forces that can not be systematically tested or modeled. As a result, the designers are aware of social problems when they materialize and can work immediately to try to influence change. Their efforts at understanding culture and evolving the design alongside it create a meaningful bond between the users and the designers.
Natürlich hat ein solches Vorgehen auch Nachteile: Es ist zeitintensiv und das so gewonnene Wissen ist nur schwer auf andere übertragbar, was vor allem beim Wachstum eines Software-Entwicklungsteams oder beim Weggang von altgedienten Entwicklern Probleme aufwirft. Und schließlich: Es stößt auf Probleme, wenn die Nutzerbasis einer Anwendung wächst. Dann setzen nämliche interne Differenzierungsprozesse ein, weil sich Sub-Gemeinschaften herausbilden, die ihre eigenen Vorstellungen und Praktiken mit bringen. Aus Nutzersicht ist dieser Punkt spätestens dann erreicht, wenn die ersten Mitglieder einer Community seufzen: "xyz ist auch nicht mehr so schön, wie es früher einmal war". danah plädiert nun dafür, diese Prozesse bei der Software-Entwicklung einzuplanen - den wichtigsten Ratschlag finde ich:
Don’t design for perfection - design for reinterpretation. No matter how perfect you see your design, it will be modified, altered or manipulated in use. If you design for perfection, you will be disappointed in what people do. Design conscientiously but plan to react immediately after something goes out. Make sure you’re able to make changes on the live server quickly and in response to what people are doing. You may have thought something that you threw out there was culturally sound, but it might not be - be prepared to change it.
Eine solche Haltung stellt die interpretative Flexibilität der Nutzer von vorneherein in Rechnung: Anwender einer Technologie sind kreativ, sie erfinden neue Verwendungsweisen, indem sie entweder zweckfrei mit der Software ‘herumspielen’, oder weil sie Probleme lösen möchten, die die Entwicklern nicht vorhergesehen haben [2]. Gutes Software-Design bezieht die Nutzer als Experten mit ein - und Experte meint hier nicht den Programmier-Crack, sondern den ‘Experten in eigener Sache’, denn die Anwender wissen ja am besten, wofür sie eine bestimmte Software einsetzen wollen und können. Veränderte Nutzungsweisen können dann wieder in neue Versionen der Software eingehen, es findet also eine gemeinsame (Weiter-)Entwicklung der Software durch Designer und Anwender statt, oder noch allgemeiner: Die Nutzungspraktiken selber haben einen Einfluß auf ihre technische Basis [3].
[1] Sie nennt als Beispiel Craig Newmark von ‘Craigslist‘, Stewart Butterfiel und Caterina Fake von ‘Flickr’ und Tom Anderson von ‘myspace‘.
[2] Mein Lieblingsbeispiel für interpretative Flexibilität ist das Zweckentfremden von Gegenständen zum Öffnen von Bierflaschen - siehe dazu auch hier.
[3] Aus etwas anderer Perspektive habe ich dies auch in diesem Eintrag beschrieben.
Dieser Beitrag ist für Kommentare geschlossen.