Tenor @ the Berlin Open Software Usability Meeting

zdrowa żywność nieruchomości projektowanie stron www agencja reklamowa soczewki kontaktowe nauka angielskiego agroturystyka nieruchomości warszawa klimatyzacja tworzenie stron tworzenie stron www reklama ogłoszenia nieruchomości psychoterapia psycholog żywność ekologiczna psychoterapia warszawa szkła kontaktowe reklama w internecie sm mp ma mpa dentysta stomatolog apteka apteka internetowa nauka języka angielskiego angielski implanty jk psk kocd

Ok, here is the summary of the meeting - in German, as I'm too lazy to translate it

It was really productive and fun - thanks to all who were there!

-----------------

WORUM GING'S?

Das Konzept eines hierarchischen Filesystems wird angesichts der
zunehmenden Datenflut mehr und mehr inadaequat. Abhilfe sollen Projekte
wie Google Desktop Search, Apple's Spotlight, Gnome's Beagle oder KDE's
Tenor schafffen, naemlich Content- und Kontext-basiertes Speichern,
Abrufen und Bearbeiten von Information, einschraenkende Suche und Browsen.

Am besten wird dies durch ein Beispiel veranschaulicht: Stell dir vor,
du brauchst dringend ein PDF ueber data retention, das dir vor einigen
Wochen von einem Freund zugeschickt wurde. Die EMail selbst hast du
geloescht, nachdem du das Dokument abgespeichert hast. Nur wo hast du es
abgelegt?? Auf einem Fileserver, lokal, unter einem bestimmten
Themen-Ordner oder in temp? Statt alle Ordner einzeln zu durchsuchen
(der Titel des Dokumentes ist dir bloederweise entfallen), suchst du
anhand der dir verfuegbaren Kontextinformationen: Dem Namen des
Freundes, per Email angekommen, PDF. Und voila, da ist es

Waehrend die Anforderung an die Datenstruktur - also welche
Kontextvariablen sinnvoll und brauchbar sind - recht gut geklaert ist,
fehlt ein systematisches Repertoire an Use Cases, durch die die
Anforderungen an das Frontend spezifiziert werden. Nachdem uns Scott
Wheeler, der ein entsprechendes Framework fuer KDE entwickelt (siehe
http://dot.kde.org/1113428593/), die Moeglichkeiten und technischen
Grundlagen informiert hatte, entstand eine lebhafte Diskussion ueber die
verschiedenen Arten, die der Mensch anwendet, um Information zu finden.
Anschliessend wurde ueber die Moeglichkeiten und Probleme der Sammlung
von Kontextdaten aus der User-Perspektive diskutiert, wobei eine Menge
an Use Cases entstanden, die wir in einer 'Wish list' fuer das
Browser-Frontend gesammelt haben.

AUFFINDEN VON INFORMATION

1. Ausbreitende Suche: Ausgehend von einem bestimmten File (oder
allgemeiner: Objekt) gelangt man ueber verwandte Objekte (z.B. zur
gleichen Zeit, von gleicher Person bekommen, gleiches Thema)
schliesslich zu dem/den Zielobjekt/en.
Beispiel: Ich lese gerade einen Artikel, moechte vom gleichen Autor zum
gleichen Thema mehr lesen.

2. Eingrenzende Suche / Filtern: Ausgehend von einer Menge an Objekten
grenze ich die Such-Eigenschaften immer weiter ein, bis ich bei dem/den
Zielobjekt/en ankomme.
Beispiel: Ich lasse mir alle Artikel zum Thema Usability anzeigen,
grenze dann ein nach Autor und nach einem spezifischen Topic.

3. Stoebern / Browsen: Ungezielte Suche, ausgehend von einem Objekt wird
verwandten Objekten und Informationen je nach Interesse, Relevanz o.a.
gefolgt.
Beispiel: Ich lese einen Artikel zu Data Retention, lese den Namen des
Autors, schaue, was es noch ueber den Autor zu wissen gibt, entdecke,
dass er fuer eine bestimmte Firma arbeitet, informiere mich ueber die
Leistungen der Firma, usw.

In frueheren Lehrbuechern zur Interaktion beim Suchen nach Informationen
wurde uebrigens zwischen zwei Arten von Suche unterschieden: Der Eingabe
eines Suchbegriffes, so dass die Anzahl der moeglichen Ergebnisse
minimiert (-> ich muss mich initial an den Dateinamen erinnern, aber
dann faellt mir die Auswahl leicht), und das Durchsuchen des
Dateibaumes, bis man es findet (-> ich erkenne das file, wenn es vor mir
liegt, habe bis dahin aber einen grossen Suchaufwand).

Unser Ziel ist es, das Wiedererkennen ('Recognition') bei moeglichst
geringem Aufwand (wenig aktives Erinnern/'Recall') zu foerdern, indem
dem Nutzer vorhandene Relationen aufgezeigt werden, bevor er spezifisch
danach fragen muss.

ZUGRIFFSRECHTE UND DATENSICHERHEIT

Allerdings wurde auch darauf hingewiesen, dass die Speicherung sensibler
Kontextdaten wie Herkunft, Inhalt oder Entstehungsgeschichte eines
Objekt die neuartiger Zugriffskontrollen notwendig macht. Diese muessen
zudem einfach und schnell zu bedienen sein - zu gross ist sonst die
Gefahr, dass man aus Mangel an Zeit, sich durch die Zugriffskontrollen
zu waelzen, seine persoenlichen Kontextdaten an andere weitergibt. Wenn
zum Beispiel jedesmal beim Verschicken eines Dokumentes ausgewaehlt
werden muss, ob und welche Elemente der Entstehungsgeschichte des
Dokumentes (welche Autoren, woher kamen die Bilder, welche
Internetseiten wurden gleichzeitig konsultiert,...) mitgeschickt werden,
werden die Nutzer genervt irgendwann 'Alles' oder 'Nichts' als Standard
setzen. Beides ist nicht ideal.

RELEVANZ UND ZUVERLAESSIGKEIT

Ein weiteres Thema war die Zuverlaessigkeit und Relevanz der angezeigten
Relationen -> Was ist relevant? Wie produziert man Relevanzen? Wird
dafuer Tagging benoetigt, oder kann es ueber Algorithmen ermittelt
werden? Werden die Inhalte automatisch bestimmten Kategorien zugeordnet,
oder macht man das manuell?

Moegliche Ideen fuer automatisches Erzeugen waren:

1. Heranziehen existierender Daten (z.B. Google Daten)
2. Inhalte entsprechend Google analysieren
3. Zeit, bis auf Ergebnis geklickt wird (positive Relevanz)
4. Zeit, bis zu den Suchergebnissen zurueckgekehrt wird (negative Relevanz)

PERSOENLICHKEITS-TYPEN

Trotzdem darf und kann auf ein manuelles Taggen, Einordnen, 'Ablegen'
von Objekten nicht verzichtet werden. Hier kommen verschiedene
Persoenlichkeitstypen ins Spiel - solche, die gerne die Kontrolle ueber
ihr Handeln und Tun haben, und solche, die das nicht benoetigen. Ein
Kontroll-Typ moechte nicht nur ahnen oder wissen, unter welcher
Kategorie sein aktuelles Dokument abgelegt wurde, sondern es selbst tun
(um ganz sicher zu gehen, dass er sich spaeter daran erinntert).

Beispiel fuer ersteres: Ich verfasse ein Dokument, in dem haeufig das
Wort 'Tangible UI' vorkommt. Das System verknuepft das Dokument deshalb
mit anderen Tangible UI Dokumenten, und informiert mich im besten Fall
darueber.

Beispiel fuer letzteres: Der Nutzer sucht sich selbst aus einer Liste an
selbst-erstellten Kategorien die fuer ihn relevanten Kategorien aus. Er
kann damit sicher sein, dass es tatsaechlich dort zu finden ist.

Es muss sichergestellt werden, dass beide Mechanismen unterstuetzt werden.

RELATIONEN ABBILDEN

Bisher undefiniert sind die Relationen, die zwischen den Elementen
bestehen koennen. Die Basics sind

- Is related
- Is the same as
- Is part of
- Contains
- ...

USE CASES

Hier schliesslich eine List an Use Cases oder Wuenschen, die die
TeilnehmerInnen geaeussert haben:

Projekt-Verwaltung:

- Ein Kollege uebergibt mir sein gesamtes Projekt, d.h. den gesamten
Dateibaum dieses Projektes. Der vorherige Verantwortliche sagt, es gaebe
eine PPT Praesentation, die er im Maerz gehalten habe, die das gesamte
Projekt gut erklaere. Wie finde ich es?

- Ich nehme in Dokumenten immer wieder Bezug auf andere Dokumente oder
PDFs auf meiner Hard Disk oder dem Fileserver, die der andere aber nur
schwer nachvollziehen kann (z.B. 'Siehe bla.pdf'). Stattdessen haette
ich gerne Links in den Dokumenten, die das entsprechende Dokument an der
richtigen Stelle oeffnen. Wenn ich ein Dokument mit Links verschicke,
werden die anderen automatisch mit dazu gepackt.

- Ich will die endgueltige Version eines Dokumentes finden.

- Ich will eine bestimmte Vorversion eines Dokumentes finden.

- Ich moechte das Dokument von letztem Montag finden.

- Ich will sagen, dass das Dokument jetzt beendet ist.

Wissens-Management:

- Uebergreifende Kategorien muessen ueberall definierbar sein, egal wo
ich gerade bin.

- Ich moechte zu jeder Datei ein Tag setzen koennen (wichtig, todo) und
es anzeigen lassen.

- Ich moechte Kommentare und Stichpunkte zu einer Datei hinzufuegen.

Konkrete Suche:

- Waehrend ich mit Sven gechattet habe, habe ich eine Mail gelesen, in
der etwas wichtiges stand. Nur welche, von wem und in welcher Mailingliste?

- Ich suche ein Dokument, das ich gelesen habe zehn minuten nachdem ich
ein bestimmtes Bild bearbeitet habe.

Recherche:

- Ich habe ein Bild auf der Festplatte und suche nach allen aehnlichen
Bildern (Farbe, Form, Textur, Zeit)

- Ich bekomme eine Fotokollage aus verschiedenen Bildern und moechte
wissen, aus welchen Einzelheiten es zusammengebastelt ist (aus welchen
Dateien). Wo sonst werden diese Dateien verwendet? Diese Infos sollten
in den Layer-Dialog des Grafikprogramms integrieret werden.

- Ich schreibe einen Artikel und suche nach Information und Bildern, mit
denen ich keine Lizenzprobleme bekomme.

- Ich recherchiere mit Google fuer einen Artikel. Wie bekomme ich Seite
wieder? Wenn ich das Stichwort noch weiss, lass ich mir die Seiten
anzeigen, die ich letzte Woche dazu angesehen habe (nicht alle
Suchergebnisse!)

- Ich haette gerne selbstorganisierende Bookmarks, die alles
abspeichern, was ich mir angesehen habe.

- Ich haette gerne eine Google Stichwort History der Suchbegriffe und
eingesehenen Ergebnisse.

- Evtl. war die relevante Seite gar kein Google Ergebnis, sondern vom
Ergebnis aus ueber drei Links erreicht.

->> Die Desktopsuche muss eine Websuche beinhalten!

Ueberwachen der Arbeit von anderen:

- Ich bin Chef und moechte wissen, an welchen Projekten meine
Angestellten heute wie viel gearbeitet haben

Ueberwachen/Organisieren der eigenen Arbeit:

- Ich moechte wissen, an welchen Dokumenten ich am laengsten gearbeitet
habe (welche am schwierigsten waren)

- Ich moechte wissen, an welchen Emails ich am laengsten geschrieben habe

- Ich moechte wissen, mit welchen Dateien ich am meisten/wenigsten Zeit
verbracht habe

- Wie ist mein Aufmerksamkeitslevel? Springe ich oft zu Email oder Chat?
Wann tue ich das?

- Wie viel arbeite ich woran (time tracking)?

Privacy:

niemand, der an meinen rechner kommt, soll die suchabfragen sehen! (karin)

duerfen andere bei mir suchen?? aus erfahrung weiss ich, dass man eher
nachlaessig beim setzen von restriktionen ist. (karin)

COMPARATIVE EVAUATION

Schliesslich haben wir uns noch Mac's Spotlight und Gnome's Beagle
angesehen und ueberprueft, ob wir unsere Use Cases damit abdecken
koennen. Das ist momentan noch nicht der Fall, da Querverlinkung nicht
funktioniert. Das heisst man kann sich nicht fuer ein Ergebnis
verwandte Objekte anzeigen lassen, was aber die Grundvoraussetzung fuer
die meisten von uns genannten Use Cases ist.

Wunderbar. Dann werde ich mal versuchen ebenfalls anwesend zu sein und zum ersten mal ein paar andere aktive KDE-Fans zu treffen.

Noch eine kleine Bitte; wäre es möglich, daß jemand eine digicam mitbringt? Hab selbst leider keine und würde mich freuen anderen KDE'lern ein digitales Bild meines äußeren Erscheinungsbildes zukommen zu lassen. Danke im voraus und bis Mittwoch!

Um welches Jahr handelt es sich? 2010 oder 2016?

Oder eine Zeitreise in die Vergangenheit (1999)?

Olaf