Oh. Eine Smartwatch! Ist das was fürs Joggen?

Zugegebenermaßen: Ich war noch nie ein Freund der Smartwatches. In letzter Zeit stand ich dem Ganzen allerdings etwas offener gegenüber. Und zwar weil ich sie beim Sport – genauer gesagt beim Laufen – verwenden wollte. Da macht das Sinn. Man könnte…

  • den Brustgurt einsparen und die Puls-Messung mit der Uhr durchführen
  • die Laufapp und die Musik mit Standalone-Apps über die Uhr steuern.
  • eventuell sogar das Smartphone ganz Zuhause lassen, wenn die Uhr eingebautes GPS hat.

Also: weniger Geräte. Gleiche Funktionalität. Angenehmeres Laufen. Nachdem ich aber den Markt gesichtet habe und die Funktionen der potentiellen Smartwatches analysiert habe bleibt nur zu sagen:

tRbwa39

Alles in allem fehlt einfach ein Gerät, dass oben Genanntes kann. Uhren mit GPS haben keinen Herzfrequenzsensorik. Uhren mit Sensorik haben kein GPS. Die Reviews bzgl. Akkulaufzeit und Displayqualität lasse ich mal ganz außen vor. Und zudem sind alle Uhren riesig. Also riesig riesig.

Bzgl. der Funktionalität kommt es mir so vor, als würde jede Firma ihre unausgereiften Konzepte auf den Markt werfen und hoffen dass ein paar early adopter sie kaufen bzw. nutzen. Diese werden dann Beta-Tester eingesetzt. Und irgendwann kommt dann mal ein ausgereiftes Produkt. Vielleicht.

Eine fertige, solide und im Funktionsumfang _gute_ Smartwatch würde ich mir kaufen. Aber diese halbgaren Uhren mit Möchtegern-Ansprüchen. Nö. Für die ~250€ kann ich mir auch entspannt kleinere (und dafür mehrere) Wearables kaufen. Und somit warte ich weiter…

(Der einzige Kandidat wäre die Sony SmartWatch 3. Aber: Keine Sensorik für die Herzfrequenz)

(Oder habe ich eine tolle Smartwatch vergessen meine Anforderungen doch erfüllt?)

 

 

#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ß!

#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.