#12months12papers #3 – Beliefs and Biases in Web Search

Beliefs and Biases in Web Searches?

White, Ryan W.

Suchmaschine auf, Frage eingegeben, Das erste Ergebnis angeklickt. Fertig.

Alle Beteiligten sind zufrieden. Das Ergebnis ist wie gewünscht. Aber ist es auch das richtige? Oder ist das Ergebnis der Suchmaschine etwa durch Vorurteile verfälscht? Mit dieser (und anderen Fragen) beschäftigt sich der Autor im dritten Paper von #12months12papers.

Im Detail geht es um Folgendes:

  1. Sind Suchende „Opfer“ von Suchmaschinen mit Vorurteilen?
  2. Werden sie selbst von Ihren eigenen Vorurteilen in Ihrem Urteil getrübt?
  3. Bevorzugen wir positive Antworten von Suchmaschinen?
  4. Behandeln Suchmaschinen negative Antworten anders als positive?

>>> tl;dr; Ja.

Die durchgeführte Nutzerstudie begann mit einem ausgefüllten E-Mail Fragebogen von 198 Microsoft MitarbeiterInnen über deren Suchverhalten. Mit diesen Daten wurde die Frage geklärt, wie sich die Meinung zu einer Frage bzw. zu einem Thema im Rahmen einer Websuche verändert. Das heißt, was haben die Leute vorher geglaubt, und was nachher. Das Ganze bezog sich übrigens explizit auf Ja/Nein-Fragen.

Hier zeigt sich schon, dass die Menschen dazu neigen, die Suche nur zur Bestätigung einer gefestigten Meinung zu nutzen. Es ist auffällig, dass die meisten grundsätzlich häufiger vermuten, dass ja die richtige Antwort auf ihre Frage ist. Egal was sie glaubten, die Mehrzahl der Beteiligten wurde dann durch die Suche in ihrer initialer Meinung bestärkt oder blieb unschlüssig. Sehr wenige änderten Ihre Meinung und wenn, dann ist es zweimal wahrscheinlicher, dass sie sie hin zu ja ändern. Und alle Folgesuchen basierten dann darauf, weitere Bestätigung für die verstärkte Meinung zu finden (was ja wiederum häufiger ja ist). Platt gesagt: Wir suchen also gar nicht die Antwort, sonder nur Bestätigung. Und zwar wollen wir die Antwort ja bestätigt sehen.

Aber was, wenn das Suchergebnis falsch ist? Also die richtige Antwort gar nicht ja ist?

Um das (und anderes zu testen) hat sich der Autor auf Suchdaten bzw. -logs von Bing gestützt. Und zwar explizit auf Ja/Nein-Fragen mit medizinischem Hintergrund.

Nachdem die Ja/Nein-Fragen extrahiert, analysiert und von Medizinern beantwortet wurden (Goldstandard), fand der Autor es schon auffällig, dass das erste Ergebnis in der Liste häufiger positiv als negativ ist und generell Ja-Antworten häufiger angezeigt werden. (Was ja auch super praktisch ist, da der Suchende häufiger Ja-Antworten erwartet. Ein Schelm wer Böses dabei denkt.)

Und hier kommt es: Bei den analysierten Ja-/Nein-Fragen kam drei bis vier mal häufiger eine Ja-Antwort als es der Goldstandard (Fragen wurden ja von MedizinerInnen beantwortet) erwarten lassen würden! Ergebnis: falsche Antwort.

Und wenn sich die Suchenden einfach auf das Ergebnis ganz oben in der angezeigten Liste verlassen, erhalten sie nur zu 45% die richtige Antwort. Auch hier ist wieder eine Tendenz hin zu ja zu erkennen: Wenn die Antwort der MedizinerInnen ja war, steigt der Anteil der richtigen Antworten auf 66%. Bei nein fällt er dramatisch auf ungefähr 25%. Ein gar nicht mal so guter Schnitt.

UND DAS FINDE ICH GANZ SCHÖN KRASS.

Den gerade weil sich die Studie mit medizinischen Fragen beschäftigt und daraus ja doch erhebliche Folgen und eventuell negative Aktionen folgen können, sind die Ergebnisse erschreckend. Suchmaschinen mit solchen Vorurteilen und Suchende die Antworten und Meinungen und nicht hinterfragen? Keine gute Kombination.

—-

Die Ergebnisse sind natürlich einerseits für die Suchmaschinen wichtig, die tatsächlich die richtigen Ergebnisse liefern wollen und nicht nur einen hohe Klickrate möchten, andererseits aber auch für uns Suchende da wir darauf achten können, wie wir Suchfragen stellen und die vorgeschlagenen Ergebnisse bewerten.
Übrigens: Ja/Nein-Fragen die mit can beginnen oder allgemein schon auf Möglichkeiten abzielten, waren durchweg weniger genau zu klassifizieren. Und Fragen, bei dem die erwartete Antwort nein ist, könnten die oben genannten Probleme etwas kompensieren. Oder einfach mal etwas nachdenken. Geht auch.

Allgemein war der Artikel super. Der rote Faden war klar erkennbar, die Daten durchweg schlüssig, kleinere Mängel wurden direkt diskutiert oder zumindest angesprochen. Mehr davon.

Bis Ende April, Viel Spaß!

Advertisements

#12months12papers #2

Architecture Challenges for Internal Software Ecosystems: A Large-Scale Industry Case Study

Klaus-Benedikt Schultis, Christoph Elsner, Daniel Lohmann

Jetzt könnten wir alle denken, bei Informatik und Software ginge es nur um Sourcecode, Programmiersprachen und wie ich jetzt die Threadkommunikation realisiere. Falsch gedacht. Ein großes Problem bei Softwareprojektion ist das Management. Aufgaben richtig zu verteilen und die Anwendung effizient zu erstellen – also wiederverwendbar, modular und trotzdem gut programmiert – ist ein nicht zu verachtender Teil des Softwareentwicklungsprozesses. Das dachten auch die Autoren vom zweiten Artikel meiner Reihe #12months12papers. Sie widmen sich diesen Problemen. Und zwar im Speziellen bei Software-Ökosystemen.

Ein Software-Ökosystem (engl. software ecosystem) beschreibt das Zusammenspiel zwischen Organisationen und Unternehmen auf einem geteilten Markt für Softwareentwicklung und Webservices.
(wikipedia.de, Software-Ökosystem)

In anderen Worten, ein Unternehmen entwickelt eine Software und bietet anderen Organisationen Funktionalität oder Quellcode an. Ein gutes Beispiel ist Apple mit iOS das sie als Plattform entwickeln, aber unabhängigen Entwicklern als Basis für Apps zur Verfügung stellen. Wenn jetzt ein solches Software-Ökosystem geplant, erstellt und programmiert werden, ist einiges zu beachten bzw. es ist gut, einiges im Voraus zu wissen. Die Autoren haben sich in dem Text speziell auf Kollaborationsmodelle und Architekturherausforderungen bezogen. Und zwar haben sie erstere identifiziert und letztere im Bezug auf die Modelle analysiert. Hierzu haben sie viele Stunden Interviews mit verantwortlichen Menschen aus zwei großen Projektion bei Siemens geführt.

Kollaborationsmodelle

Die identifizierten bzw. genannten Akteure bei den Kollaborationsmodellen sind sehr abstrakt gehalten und sind wie folgt definiert:

  • ISECO:
    Internal Software Ecosystem. Dezentrale Topologie von mehreren verschiedenen Akteuren mit unterschiedlichen Zielen, Einflüssen und Organisationsstrukturen.
  • Keystone:
    Anbieter bzw. Entwickler der Plattform (vgl. Apple mit iOS).
  • Core Clients:
    Ursprünglich geplante Nutzer der Plattform.
  • Consumer Client:
    Nutzer, deren Anwendungsfall eigentlich nicht vorgesehen war, die aber die Plattform im Ganzen nutzen. Sie sind locker mit dem Keystone verbunden.
  • Extended Core Client:
    Nutzen nur einen Teil der Plattform, diesen aber sehr stark und sind eng mit dem Keystone verbunden.

Anhand dieser Akteure und den Strukturen in den beiden analysierten Projekten haben die Autoren dann die folgenden Kollaborationsmodelle definiert bzw. extrahiert:

  1. Product Lifecycle Management (PLE) for ISECOs
    Keystone stellt Plattform bereit und ist auf Core Clients fixiert. Andere Akteure spielen keine Rolle bzw. haben keinen Einfluss auf den Entwicklungsprozess und zukünftige Features.
  2. Platform Reuse for ISECOs
    Hier kommen, im Gegensatz zu 1., noch die Consumer Clients hinzu. Diese nutzen die Plattform, haben aber weniger Einfluss im Entwicklungsprozess.
  3. Decoupled Product Lifecycle Management for ISECOs
    Wenn sich herausstellt, dass die Plattform auch für andere Unternehmensbereiche oder Kunden signifikant wichtig und gewinnbringend ist, können Extended Core Clients mit in das Kollaborationsmodell mit einbezogen werden: Sie haben stärkeren Einfluss, da sie die Plattform (oder Teile) stark nutzen.

Anhand dieser drei Modell wurden dann die Einflussfaktoren bzgl. der Organisationsstruktur, des Prozessmanagements, der Architektur und im Management klassifiziert. Im Artikel ist eine schöne Tabelle die das erläutert.

Architekturherausforderungen

Die Architekturherausforderungen die sich während den Interviews ergeben haben sind im Folgenden aufgelistet. Natürlich sind das nicht alle, aber durchaus gute Punkte, die beim Entwickeln eines Softwareökosystems beachtet oder wenigstens kurz durchdacht werden sollten.

A. Platform Opennes Dilemma

Wann öffne ich die Plattform für anderen Entwickler? Zu früh bedeutet das externe Menschen mit krassen Änderungen, Bugs und halbfertigen Features leben müssen, aber eben auch früh Einfluss auf die Entwicklung nehmen können. Zu spät stellt Entwickler und Entwicklerinnen vor vollendete Tatsachen. Diese funktionieren dann aber eben auch.

B. Technical Integration

Was muss alles getan werden, um die Integration von externen Anwendungen, also Anwendungen von der Kunden, so einfach und angenehm wie möglich zu machen? Und wie stark soll die Integration sein? Das heißt, wie abstrakt sollen die Funktionen sein, die von der Plattform angeboten werden? Hier haben die verschiedenen Kunden verschiedene Anforderungen.

C. Independent Platform Developemnt

Wie gehen die Entwickler und Entwicklerinnen der Plattform damit um, dass das Ökosystem sich entwickelt. Bei jedem neuen Release müssen Abhängigkeiten zwischen der Plattform und den Anwendungen der Kunden beachtet werden. Zudem müssen sogenannte breaking changes, also die Wegnahme von Features, angemessen kommuniziert und durchgeführt werden. Alle Entscheidungen müssen so getroffen werden, um eine möglichst gute Evolution des Ökosystems zu ermöglichen.

D. Independent Application Development

Nicht nur die Plattform entwickelt sich am Besten unabhängig. Auch die Clients müssen die Möglichkeit haben, sich unabhängig zu entwickeln. Das schließt die Möglichkeit ein, dass externe Organisationen Funktionen für die Plattform entwickeln. Es ist dann möglich, dass gute Features in die Plattform migriert werden oder die externen Anwendungen bieten sie direkt anderen Anwendungen an.

E. Qualities

Alle Anwendungen des Ökosystems müssen bestimmte Eigenschaften haben. Im Text wird hier zwischen internen und externen unterschieden. Interne Eigenschaften sind z.B. Verständlichkeit oder Lesbarkeit des Quellcodes. Allgemein alle Eigenschaften die die Wartbarkeit betreffen. Die externen Eigenschaften sind z.B. Speicherverbrauch, Zeitverhalten oder Verlässlichkeit. Im perfekten Ökosystem erfüllen alle Softwarebausteine bestimmte Mindestanforderungen.

F. Compliant Software Development

Hier geht es darum, nicht nur die Eigenschaften aller Anwendungen mehr oder weniger konsistent zu halten, sondern auch Entwicklungsstrategien, Maßnahmen und Prozesse unter allen Involvierten zu diskutieren. Zudem geht es darum, wie Verantwortlichkeiten verteilt werden.

Diese Herausforderungen müssen während der Planung, während der Entwicklung und während des Betriebs eines Software-Ökosystems bedacht werden. Der Text gibt dazu gute Fallbeispiele mit nachvollziehbaren Beispielen und Erklärungen. Und das sehr ausführlich. Die Informationen wurden, wie gesagt, aus Interviews mit mehreren hundert Entwicklern und Entwicklerinnen gezogen. Dem Titel nach habe ich eigentlich etwas ganz anderes erwartet, aber letztlich war der Text doch ganz informativ. Und wer sich mit der Entwicklung von einer Plattform beschäftigt, die Services oder Teile des Codes zur Verfügung stellt, kann sich hier gute Inspiration für den Planungsprozess holen.

#12months12papers #1

Duet: Exploring Joint Interactions on a Smart Phone and a Smart Watch

Xiang „Anthony“ Chen, Tovi Grossman, Daniel Wigdor, George Fitzmaurice; CHI14, Proceedings of the SIGCHI Conference on Human Factors in Computing Systems; Pages 159-168

Das Smartphone ja doch für viele Menschen unverzichtbar. Der Siegeszug der Smartwatch steht (vielleicht) noch an. Was der Smartwatch meiner Meinung nach fehlt, sind wirklich praktische Anwendungen und sinnvolle Anwendungsfälle. Als Spielzeug ist sind die Geräte ja ganz nett. Als wirklich nützliche Ergänzung im Alltag eher so meeeeh. Die Nutzung der Smartwatch nur als Anzeige oder nur als Fernbedienung für das Smartphone ist imho nicht ausreichend, um einen Durchbruch zu garantieren.

Bezogen auf die Interaktion des Menschen mit den smarten Geräten ist seit dem Siegeszuges des iPhones und damit des Touchscreens wenig passiert. Wir wischen und drücken mit einem oder mehreren Fingern über die Displays. Und das seit knapp acht Jahren. Mehr nicht. Sprachsteuerung hat sich noch nicht wirklich durchgesetzt. OK, hier ein Stift, da eventuell mal ein Schütteln. Aber das war es dann auch schon.
Chen et al. versuchen dieses Paradigma mit Duet auf zu brechen: die Smartwatch soll mit einem Smartphone kombiniert werden. Und das nicht nur in der Art und Weise, dass die Uhr Information des Telefons anzeigt, sondern es werden Interaktionsformen vorgestellt, die explizit beide Geräte erfordern. Und diese eignen sich natürlich super für Aufgaben, die beide Geräte erfordern.

Im verlinkten Artikel wird deswegen ein Set von dualen Gesten entwickelt, Anwendungsfälle für diese vorgestellt und dann bzgl. der Genauigkeit und subjektiver Nützlichkeit durch eine Studie evaluiert.

Die Gesten basieren auf zwei grundsätzlichen Modalitäten:
1. Der räumlichen Position und Orientierung der Geräte
2. Toucheingaben an den Geräten.

Mit der Verknüpfung von diesen Modalitäten wird ein Set von Gesten entwickelt um Aufgaben wie „Bildschirm sperren/entsperren“ oder „Benachrichtungen verwalten“ einfacher zu gestalten und bzw. die Interaktion natürlicher zu gestalten.

Um genauer zu werden ein paar einfache Beispiele:

Aufgabe: Alle Notifications sollen auf der Uhr ankommen
Das Smartphone wird mit der Hand gehalten, die sich auf der Seite befindet, auf der auch die Smartwatch getragen wird. Jetzt muss vom oberen rechten Eck des Smartphones zur unteren linken Ecke gewischt werden. Die Geste wird dann vollendet, in dem ohne (lange) Pause vom oberen rechten Bereich der Uhr weiter zum unteren linken Bereich gewischt wird.

Hier kann ein Nachteil der Technik erkannt werden: Die Uhr muss so getragen werden, dass ihr Display auf der Seite der Handinnenfläche ist. Macht ja nicht jeder Mensch so. Haben die Autoren aber erkannt und versprechen weitere Maßnahmen.

Aufgabe: Handy entsperren.
Der Mensch nimmt das Gerät mit der Hand, an der er die Uhr trägt, aus der Tasche. Jetzt dreht er das Handgelenk mitsamt Uhr und Telefon um ca. 45°hin und zurück (Achse: Ellenbogen) und tippt zweimal auf das Gerät. Die synchronisierte Bewegung von Uhr und Telefon authentifiziert den Nutzer bzw. die Nutzerin und der Tipp bestätigt, dass tatsächlich „Entsperren“ gewünscht ist.

Fand‘ ich auch ziemlich gut. Die Autoren auch. Jedenfalls auf dem Papier. In der Studie stellte sich dann heraus, dass die Leute gar nicht mal so zufrieden damit waren. Zu umständlich. Tja.

Aufgabe: Kartenanwendung (Maps etc.) steuern
Auf dem Smartphone kann gewischt werden um den Ausschnitt zu bewegen und zu zoomen. Alle anderen Kontrollfunktionen wie z.B. die Ansicht umschalten, die Suche aktivieren oder die Routenplanung starten kann auf der Uhr geschehen. So bleibt mehr Platz für die Karte auf dem Device und die Steuerung ist immer noch (räumlich) nahe beisammen.

Macht alles ziemlich Sinn. Der Platz auf dem Smartphone-Screen wird gut genutzt und einfache Steuerfunktionen sind auf der Uhr gut aufgehoben. Trotzdem bleiben die Orientierungs- und Navigationsaufagben genau dort wo sie hingehören: auf der Karte. Kam in der Studie gut an. Und bei mir auch.

Zudem kann mit den beiden Geräte das Standardgestenset erweitert werden indem erkannt werden kann, ob mit der Fingerkuppe, der Knöchel oder der Seitenfläche des Fingers ein Touchevent ausgelöst wird. Hierzu wird die Orientierung der Uhr verarbeitet. Das kann einerseits die Steuerung vereinfachen, verlangt aber auch, dass der Mensch sich mehr Gesten merken muss.

Die Idee, Interaktionen zu kombinieren finde ich ziemlich cool. Vor allem Aufgaben die tatsächlich auch beide Geräte – also Smartwatch und Smartphone – einbeziehen bzw. erfordern, können super durch das vorgestellte Gestenset gesteuert werden. Das Beispiel mit den Benachrichtigungen fand ich super gut. Aber denkbar ist diese Form der Interaktion für Anwendung um das momentan vorhandene Gestenset zu erweitern (vgl. Maps) und die Interaktion und Präsentation zu verbessern. Sofort fällt mir da Video- und Fotobearbeitung ein. Duet erweitert den Einsatz der Smartwatch ungemein und kann durchaus dazu beitragen, die intelligenten Uhren zum Kassenschlager zu machen. Und das ohne sie mit Technik und damit Gewicht zu beschweren.

Der Artikel ist ziemlich super geschrieben, und die Ideen die präsentiert werden, erschließen sich einem sofort. Kann ich sehr empfehlen! Kudos an die Autoren.

Was meint ihr? Fallen euch noch tolle Anwendungsfälle ein? Oder ist das alles totaler Blödsinn?

PS.
Die Reihe #12months12papers ist einer meiner Vorsätze für 2015. Das ganze wird eine Serie von zwölf Artikeln. Ich suche mir jeden Monat ein Paper aus, dass den Best-Paper-Award einer Konferenz gewonnen hat und stelle es vor. Mehr nicht. Danke.