Ermitteln des Aufmerksamkeitsfokus beim Browsen von API-Dokumentation

09 Aug 2023 - 17:03 | Version 8 | UnknownUser

Studien-/ Bachelorarbeit
Projekt: Aufzeichnen des Mikroprozesses der Softwareentwicklung
Arbeitsaufteilung: 10% Theorie, 70% Implementation, 20% Evaluation
Verwandte Arbeiten:
- Ermitteln des Aufmerksamkeitsfokus beim Durchsuchen von Code

Beschreibung

In dem oben genannten Projekt werden die einzelnen Tätigkeiten eines Programmierers zwecks detaillierter Analyse aufgezeichnet. Eine häufige Aktion und Arbeit eines Programmierers ist das Suchen in der Dokumentation einer Bibliothek, um z.B. eine passende Methode aus einer API auszuwählen.

Es ist von großem Interesse, feststellen zu können, nach was und auf welche Weise ein Programmierer zu einem Zeitpunkt sucht. Schon eine einfache Aussage über den Aufmerksamkeitsfokus auf z.B. eine Methode einer Klasse kann genügen um festzustellen,

ob der Programmierer sich in dem Suchbereich auskennt oder nicht
welche API-Teile zusammen zu gehören scheinen
welche Pfade durch eine API von Neulingen genommen werden, um einen Überblick zu bekommen und die Verständlichkeit einer API zu beurteilen

Solche einzelnen Durchsuchaktionen - üblicherweise "Browsen" genannt - müssen automatisch aufgezeichnet werden können, um eine systematische Beobachtung einer größeren Gruppe von Programmierern durchführen zu können.

Das Ergebnis einer solchen Aufzeichnung wäre eine XML-basierte Liste von "Browse"-Ereignissen. Diese könnten grafisch in Form von zweidimensionalen Plots aufbereitet werden, um z.B. zu illustrieren

welche Dokumentationsstellen zeitlich aufeinanderfolgend besucht wurden
wie sich über die Zeit der Fokus verschoben hat
wieviel Zeit pro Stelle verwendet wurde

Aufgabe

Ziel dieser Arbeit ist es, diese automatische Aufzeichnung zu realisieren und in der Praxis einzusetzen:

Es gilt eine allgemeine Bibliothek für das Verfolgen von Browsing-Aktionen in HTML-Code zu entwickeln. Diese wird wahrscheinlich auf asynchronem Javascript und XML (AJAX) basieren. Hier eine Liste der Anforderungen:
1. Die Bibliothek ist in der Lage bei folgenden Ereignissen Beginn und Ende oder Auftrittszeitpunkt zu loggen:
  1. HTML-Seite im Browser geladen
  2. Anchor-Tag im Sichtfenster des Browsers sichtbar
  3. Link angeklickt.
  4. (Optional) Mausbewegung
  5. (Optional) Markierung und Kopieren
2. Die Daten werden zentral auf einem Server in Form von XML oder in einer Datenbank gespeichert.
3. Es existiert ein Session-Konzept, d.h. ein Benutzer kann eindeutig zugeordnet werden (IP ist nicht genug).
4. Es besteht eine hinreichend intelligente Heuristik zum Erkennen von Inaktivität.
5. Es besteht eine hinreichend intelligente Heuristik zum Erkennen von Erreichen einer Seite via externer Navigation (Google, Bookmarks, etc = Referrer).
6. Es besteht eine hinreichend intelligente Heuristik zum Erkennen von Volltextsuche auf der einer Seite mittels Browserfeatures (STRG+F, etc).
Diese Bibliothek soll dann für API-Dokumentation, welche mit JavaDoc generiert wurde, eingesetzt werden.
Bei einem laufenden Projekt oder während eines Experimentes wird das entstandene Werkzeug eingesetzt und evaluiert.
Zusätzlich kann eine geeignete Auswertung der Durchsuchereignisse erfolgen, d.h. das Zusammenfassen der Daten in Form von Fokuscluster, typischer Suchpfade und Qualitäten des Durchsuchens. Alternativ kann auch an einer guten grafischen Darstellung der Aufzeichnungen gearbeitet werden, die solch explorative Datenarbeit gut unterstützt.

Wie üblich schließt die Arbeit mit einer schriftlichen Ausarbeitung und einem Vortrag ab.

Diskussion der Ziele, die mit dem Tool erreicht werden können

Zuerst wollen wir die folgenden zwei Gebiete unterscheiden, auf dem das Werkzeug nützlich sein könnte:

Einsatz in der Praxis
Einsatz im Labor

Beide Domänen haben ganz andere Anforderungen und Bedürfnisse.

Praxis
1. Einsatz in Systemen zur automatischen Verbesserung des Informationspräsentation.
  - Dies lässt sich am besten durch das Amazon-Feature "Benutzer, welche dieses Buch gekauft haben, haben auch dieses gekauft" erklären.
  - Es geht also um vollautomatischen Einsatz der gesammelten Daten zur Verbesserung der Darstellung des Inhalts der Webseite. Es werden bei diesem Ansatz keine wirklich neuen Inhalte generiert.
2. Einsatz zur Ermittlung von Problemstellen in der Dokumentation
  - Es geht darum, dass das Browse-Verhalten der Benutzer herangezogen werden soll, um den Dokumentierenden des Systems Anhaltspunkte zu liefern, wo besondere Aufmerksamkeit gefordert ist.
  - z.B. könnte das System Mitteilungen ausgeben, welches die häufigst verwendeten Methoden sind. Dies kann dann helfen, Energien auf diese Methoden zu fokussieren.
3. Einsatz zur Erkennung von strukturellen Problemen in der Website
  - Gelingt es aus dem Browse-Verhalten erfolgreich darauf zuschließen, wo in der Struktur der Website (im Falle von JavaDoc würde dies der Struktur der API selbst entsprechen), dann kann man gezielt Verbesserungen an diesem Punkt vornehmen.
  - Als Beispiel sei die Position des JPEG-Loaders in Java genannt, welcher eigentlich besser in Java2D aufgehoben wäre.

Labor
- Sammeln von Charakteristika über den Benutzer
  - Ist der Benutzer Experte oder Anfänger?
  - Durchsucht der Benutzer die Webseite flächendeckend oder zielgerichtet?
  - Welche Teile wurden wirklich betrachtet?
  - Lassen sich Session identifizieren?
  - War die Suche des Benutzers erfolgreich oder unerfolgreich.

Alte Beschreibung:

Das Tool soll in der Lage dem Betreiber von API-Dokumentation Hilfestellung bei der Auswahl von zu dokumentierenden Stellen geben.
- Anforderungen:
  - Möglichst wenig Aufwand für den Betreiber der API-Dokumentation
  - Kein Aufwand für den Benutzer der API-Dokumentation
  - Gute Anfragemöglichkeiten für Dokumentatoren, Visualisierung für speziallisierte Anfragen (wo wurde viel gesurft, wo wurde hin- gesurft und wieder weg-gesurft)
- Dies ist der Fall der mit obiger Lösung vollkommen unproblematisch gelöst werden kann.
Das Tool sollte uns helfen zu verstehen…
- wie der Benutzer denkt
  - Wie oft finden wir As-Needed vs. systematic strategies?
  - Können wir identifizieren, was sie eigentlich suchten?
  - Wieso wurde an bestimmten Stellen eine falsche Entscheidung getroffen?
  - Welches Vokabular ist den Benutzer bekannt?
- wie Benutzer überhaupt API Dokumentation verwenden.
  - Welche Features nutzen sie, welche nicht (z.B. Uses)
  - Wo halten sie sich auf?
  - Wie lange brauchen sie zum Lesen?
  - Kann man davon darauf zurückschließen, welchen Funktionen sie verwenden wollen?
Als zweites Element des Themengebiets bietet sich an, darüber nachzudenken, wie wir der systematische Mikroprozessanalyse helfen können. Dies bedeutet, dass die gleiche Datengewinnung auch noch Client-seitig erreicht werden müsste (z.B. ein lokaler Web-Proxy wie der WebWasher oder mittels direkter Instrumentierung des Web-Browsers über ActiveX/OCX)
- Das Tools soll sich in die Mikroprozessanalyse von Sebastian einklinken können. Siehe Diplomarbeit von Frank Schlesinger zum Thema und das Werkzeug HackyStat.
  - Die Anforderungen sind hier etwas anders:
    - Der Benutzer kann ruhig etwas installieren, aber man will nicht alle Webseiten, welche gemonitored werden sollen, instrumentieren.
    - Das Problem mit diesem Ansatz ist, dass man dann nur ganz schwerlich die semantischen Zusatzinformationen erhalten wird (Klasse/Funktion angebrowst), welche man so gerne haben würde.

Offene Fragen

Wie groß ist der Anteil derjenigen Entwickler, welche API-Dokumentationen lokal installieren und nicht die Server-Versionen verwenden?
Kann man Heuristiken entwickeln, welche einem sagen, was der Benutzer momentan browst? Ist er noch damit beschäftigt zu verstehen wie eine Klasse funktioniert oder ist er bereits mit etwas ganz anderem beschäftigt? * Welche Kalibrierungen müssen für den jeweiligen Benutzer vorgenommen werden?