Re: [de-discuss] UX-Anmerkungen war: Prioritäten im Projekt / Fragen an die Aktiven

Hi Irmhild,

leider bleiben nur ein paar Minuten ... sorry schon vorab.

[Nachtrag: Ich habe versagt. Also, rein zeitlich.]

Am Donnerstag, den 13.01.2011, 10:47 +0100 schrieb Irmhild Rogalla:
> hallo christoph,
>
> Am 12.01.2011 20:31, schrieb Christoph Noack:
> > Hallo Irmhild,
> >
> > Danke für Deine Mail - und das Lesen im Wiki :-)
>
> gerne :-) (und danke für die guten Wünsche!)
>
> Ich habe Deine Mail (und auch die vorangegangenen) mehrfach gelesen und 
> irgendwie das Gefühl: einerseits ist es interessant - aber andererseits 
> habe ich irgendwie den Faden verloren (oder ihn nie gehabt).

Oh, na dann mal schauen ...

> Deswegen nochmal von vorne, sozusagen. Du hast im wiki u.a. geschrieben: 
> "LibreOffice aims to be a great tool for people to let them create, edit 
> and share any kind of information - enabling them to turn their ideas 
> into documents. But offering that much capability doesn't require the 
> software be complicated for all the different users ... The LibreOffice 
> Design Team wants to "Make it just work, and look great, too!" by 
> offering User Experience Design and Visual Identity Design."
>
> In Deiner Mail schreibst Du (dazu) u.a.
>
> > ...
> >
> > Aktuell geht es ja eher darum, wie man zu solchen Erkenntnissen kommt -
> > und wie man die Entwickler (bzw. alle im Projekt) sinnvoll unterstützt.
> > Schauen wir mal, vielleicht sind das ganz gute Beispiele als
> > Ausgangspunkt. Wie jeder Vortragende habe ich natürlich noch keine
> > Ahnung was genau da rein soll :-)
> >
> > ...
> >
> > Mmh, das wäre ein schönes Beispiel für den Vortrag: Wie komplex sind
> > Dokumente? Wie spezifiziert man komplex? Wie bildet man die Wahrnehmung
> > des Anwenders nach?
> >
> > ...
>
> Beides, die Frage wie man zu solchen Erkenntnissen kommt und auch die 
> Spezifikation von Komplexität sind - auch für mich - interessante und 
> wichtige Themen. Ist das hier der richtige Ort es zu diskutieren?
> Zur Spezifikation von Komplexität habe ich einiges anzubieten - 
> interessiert Dich das? Und wenn ja: was?

Grundsätzlich ja, ich harre mal der Dinge, die da kommen ...

> Machen wir mal genau mit diesem Beispiel weiter:
>
> > > (nur ein Beispiel: ich habe
> > > irgendwo schon den Wunsch gelesen, Videos und Videobearbeitung(!) in LO
> > > zu ermöglichen - das halte ich persönlich für absurd).
> >
> > Tja, ich kann das ganz gut nachvollziehen. Blöder Vergleich: Fast jedes
> > kleine Handy kann heute Videos schneiden (oder wenigstens deren
> > Anfangs-/Endpunkte) setzen. Gleichzeitig werden Programme wie
> > Impress/Powerpoint als Dokumentation innerhalb von Firmen eingesetzt (z.
> > B. Prüfstandsvideos und Messdaten visualisieren). Ein paar
> > Basisfunktionen würden da schon helfen ... nur kann ich Dir leider nicht
> > sagen, wie "stark" das wirklich gefordert ist.
>
> Hier stecken nämlich ein Vielzahl von unterschiedlichen Argumenten und 
> Perspektiven und damit auch Sichten auf Werkzeuge (hier: LO) drin, die 
> für den einen (Anwender) eine "Selbstverständlichkeit" und für den 
> anderen (Programmierer++) eine komplexe (oder nur komplizierte?) 
> Herausforderung sind.
> Wir sehen auch von der GrundsatzDiskussion "eierlegende Wollmilchsau" 
> vs. "small is beautiful" ab und lassen auch Argumente wie "*ich* brauche 
> das [nicht], also muss das Programm das [nicht] können" oder "Programm 
> XYZ kann das auch, also muss LO das auch" beiseite, was bleibt denn 
> dann, gerade in Bezug auf UX und im Spannungsfeld zwischen 
> "Nutzungserlebnis" und "Usability" auf der einen sowie Aufwänden und 
> Anforderungen auf der anderen Seite?

Ich würde sagen, der Faden ist noch voll da.

> Nutzungserlebnis: Klar, in dem von Dir geschilderten Fall Dokumentation 
> und Visualisierung durch/mit Prüfstandvideos: es wäre einfach nur 
> praktisch und vermutlich auch mit wenigen Funktionen (in LO) getan.

Genau, und es war auch tatsächlich ein Beispiel. Es gibt eine Menge
Möglichkeiten, um Anwender und deren tägliche Aufgaben zu
untersuchen ... direkt (z. B. fragen) oder indirekt (z. B. beobachten).

Und hier zeigt sich auch, dass "die Anwender" eigentlich eine kleine
Gruppe von "Video-Dokumentaren" ist. Du stellst korrekterweise Fragen
wie: Lohnt sich das? Wird das nicht zu kompliziert? Wird die Software
damit nicht unhandlich für andere Leute? Lässt sich das Programmieren?
Lohnt sich der Aufwand?

Genau (!) das ist die (Teil-)Aufgabe von User Experience - wir bewerten
potenzielle Funktionalität, und priorisieren sie gegenüber anderen
(gewünschten) Fähigkeiten der Software. Damit helfen wir z. B.
Entwicklern, die selbst wiederum priorisieren (z. B. Machbarkeit, ...).

> Usability: Schon schwieriger. Ich erinnere mich an mehrere endlose, 
> immer wieder aufflammende Diskussion auf der OOo-User-Liste die um das 
> Einfügen und vor allem Beschneiden/Bearbeiten von Grafiken (in 
> Writer-Dokumente) gingen. Da gingen nämlich einige Dinge durcheinander: 
> Fragen der Bedienbarkeit (sowohl im Sinne dessen, was das Programm da 
> anbietet, also auch im Sinne der Kenntnisse und Fähigkeiten der Nutzer) 
> - Grenzen des Bildbearbeitungstools und auch seiner Einbindung - 
> mindestens ein Fehler in den mit einem anderen Programm erzeugten 
> Grafiken (jpg).
> Hier stößt man (scheinbar?) schnell an Grenzen dessen was sinnvoll, 
> machbar, möglich ist. Zumal, wenn "intuitive" Bedienbarkeit sein soll. 
> Der Nutzer sagt: "ich will doch nur ... und auf meinem Handy ist das 
> doch auch kein Problem".

Korrekt geschrieben - "intuitiv" in Anführungszeichen. Diese gibt es
faktisch nicht, denn sie ist Basis der Physiologie (wie ist der Mensch
aufgebaut, Grundreflexe etc.) und der Erfahrung (was kennt er bereits,
wie verhält sich seine Umgebung/Kultur, ...).

Hier bin ich jetzt mal ungenau: "Usability Design" und die zugehörigen
Methode und Werkzeuge versuchen also, eine Funktionalität so zu
gestalten, dass sie zum Anwender passt. Also eigentlich, zu einer
möglichst großen Gruppe von Anwendern und zu den gegebenen technischen
Randbedingungen (Hardware, Software, Plattform, ...). 

Und wenn das nicht geht? Zum Beispiel, Funktionen, die einen großen Teil
der Anwender negativ beeinflussen, dürften (ideal gesagt) gar nicht in
die Software rein. Aus diesem Grund gibt es Möglichkeiten wie die
Erweiterbarkeit mit Extensions ... löst die Probleme einiger Leute, und
trotzdem bleibt die Software für den größten Teil der Anwender gut
benutzbar. Aber auch hier: Nur ein Beispiel.

> Anforderungen: Hier meine ich vor allem System/HW-Anforderungen, die ja 
> gerade bei Grafik- und Videobearbeitung gerne mal exponentiell steigen 
> und damit Erlebnisse "wie früher" ermöglichen ;-)
> Hier scheint mittlerweile fast alles (darauf bezog sich mein "absurd") 
> für Selbstverständlich gehalten zu werden. Einerseits kein Wunder, aber 
> trotzdem: eine OfficeSuite mit Videobearbeitung?

Auch hier springt mal wieder UX ein - und wir versuchen die Wünsche der
Anwender so zu "übersetzen", dass diese auch technisch machbar werden.
Um es mal konkreter zu machen: Mein täglich Brot verdiene ich mir eher
damit, wie man mit eingeschränkten Mitteln ein gewünschtes Ziel
erreichen kann.

In unseren Beispiel, wäre das Beispielsweise das Setzen von
Start/Stopp-Punkte - eine Neuberechnung der Szenen ist da vielleicht gar
nicht erforderlich. Allerdings treten dann neue Probleme auf - weiß der
Anwender, dass noch "Reste" seinen Videos vorhanden sind ("unsichtbare
Daten")? Das kann sehr unangenehm sein ... also ist auch wieder
UX/Entwicklung gefragt.

> Aufwände: Hier meine ich die Entwicklungsaufwände i.w.S. Das betrifft 
> natürlich zum einen die Programmierung. Zum anderen aber auch eben die 
> Frage, die Dich wohl interessiert, nämlich nach Nutzererlebnis, - 
> erfahrungen usw. Und hier wird es tatsächlich ebenso kompliziert wie 
> komplex: denn *den* Nutzer gibt es bekanntlich nicht, es gibt Anfänger 
> und Experten, sowie solche, die sich dafür halten; es gibt Unerfahrene 
> und Erfahrene (aber erfahren mit ganz unterschiedlichen Dingen); es gibt 
> "Schulungen" und "learning by doing"; Shortcut-Liebhaber und 
> Tastaturhasser usw. Entscheidend dabei aber: (fast) jeder Nutzer hält 
> das, was er/sie machen will und wie er/sie es machen will für das 
> Selbstverständlichste von der Welt - das ist einfach menschlich.

Dafür spendiere ich Dir irgendwann mal 'nen Saft - oder ein
Alternativgetränk Deiner Wahl :-)

Siehe oben "intuitiv".

> Nach meiner Kenntnis gibt es im wesentlichen drei Ansätze, dem zu begegnen:
> (1) (Radikale) Beschränkung der Möglichkeiten in Kombination mit (sehr) 
> durchdachter, spezifischer Nutzerführung - im wesentlichen der 
> Apple-Ansatz bei iPod etc., früher auch auf den PCs.

Genau, Beschränkung auf das für den Anwender Wesentliche.

PCs würde ich weniger dazu zählen, das wurde früher eher durch die
fehlende Verbreitung von Cmputern bzw. eingeschränkte technische
Umsetzbarkeit zum Nicht-Problem :-)

> (2) SW/Tool ist/wird erklärt als "für professionellen Gebrauch" - dann 
> ist klar, dass eine Einarbeitung (in welcher Form auch immer) 
> erforderlich ist. Das ermöglicht dann andererseits jeweils spezifische 
> Formen von Usability. Typische Beispiele: CAD, professionelle 
> Videoschnittprogramme, DTP usw. (um mal im hier diskutierten Bereich zu 
> bleiben). Nach meiner Wahrnehmung scheint dieser Ansatz eher auf dem 
> absteigenden Ast - die Programm gleichen sich in der Nutzerführung immer 
> mehr, aber vielleicht täusche ich mich da.

Die grundsätzliche Benutzung der Software wird sich hoffentlich
angleichen - zum Beispiel welche Arbeitshandlungen auf einer bestimmten
Plattform "üblich" sind. Aber Spezialsoftware setzt üblicherweise auch
Domänenwissen (CAD = Konstruktion) voraus.

Grundsätzlich gilt aber für jede Software, dass der Nutzen den
wahrgenommenen Aufwand übersteigen muss, um grundsätzlich akzeptiert zu
werden (und akzeptiert reicht dabei nicht aus). Daher ist auch jede noch
so "gruselige" Software okay, wenn Sie am Ende hilft.

> (3) Alles ist möglich. Das ist nach meiner Wahrnehmung typisch für 
> OfficeProgramme, einschließlich OOo und derzeit auch LO. Sie richten 
> sich an jedermann/frau, für jeden Zwecke und für jede Nutzungsvorliebe. 
> Damit stoßen sie natürlich immer wieder an Grenzen. Und damit bin ich 
> jetzt genau bei Deiner Ausgangsthese angekommen (s.o.)

Hier liegt das Problem, ich meine die Herausforderung von LibreOffice.
Klassischerweise gab es nie eine Beschränkung für OOo/StarOffice, es war
die "Software für alle", aber nicht, weil sie dafür gemacht wurde,
sondern weil sie über die Zeit "so geworden ist".

> Mir persönlich scheint das eigentliche Problem im Anspruch und damit die 
> Lösung in sinnvollen Beschränkungen zu liegen.

Salzstangen zum Saft?

Ich fasse mal zusammen:
      * LibreOffice sollte für einen Großteil der Anwender sein. Dabei
        soll diese den unterschiedlichen Fähigkeiten und Fertigkeiten
        der Anwender gerecht werden.
      * LibreOffice sollte für einen Großteil der anfallenden Aufgaben
        der oben genannten Anwender nutzbar sein. Häufiger anfallende
        Aufgaben sollten dabei im Fokus stehen.
      * Für weitere Anwender und Aufgaben sollte es Möglichkeiten geben,
        die Software an die Fähigkeiten und die Arbeiten möglichst
        anzupassen.

Die - Du nennst sie Beschränkungen - sind zielgerichtet zu treffende
Entscheidungen, welche zum Beispiel einteilen in: "Großteil von
Anwendern" vs. "Weitere Zielanwender", "Großteil von Aufgaben" vs.
"Weitere zu unterstützende Aufgaben".

Genau das macht (bzw. soll) User Experience unterstützten: die
"richtigen" Entscheidungen treffen. Mit all diesen Anforderungen und
Randbedingungen, die Du bereits genannt hast.

(Ich lasse jetzt mal andere böse Sachen weg wie: Unternehmens-Strategie,
Marketing-Anforderungen, Wettbewerber-Vergleichbarkeit, ...)

Und daher fasse ich die Aufgabe (in unserem UX-Sinne) mal fix zusammen -
kein Anspruch auf Vollständigkeit:
User Experience umfasst das Entwickeln und Anwenden von Methoden,
Prozessen und Werkzeugen, um das Produkt LibreOffice und zugehörige
Dienstleistungen zielgerichtet im Sinne der Zielanwender und deren
Aufgaben zu gestalten und den zugehörigen Erfüllungsgrad zu bewerten.

Hier mal Beispiele:
      * Methoden: Umfragen, ethnografische Studien, Experten-Analysen,
        Usability-Tests
      * Werkzeuge: Umfrage-Server, Eye-Tracking, Usage Tracking,
        Nutzerstudien-Design, User Interface Guidelines, ... auch
        "Erfahrung"
      * Dienstleistungen: Web-Auftritt, Support-Möglichkeiten, ...

Und warum ist das so kompliziert? Weil der Großteil unserer
"Anwender" (sprich: Marktanteil) nicht hier ist, sondern "einfach nur"
ihre Arbeiten erledigen will. Wir müssen also - neben der im Projekt
innewohnenden Erfahrung - also irgendwie an diese Informationen heran.

Andernfalls gibt es einen "Wildwuchs", der schlussendlich zu einem
Produkt führt, dessen "wahrgenommener Aufwand" höher ist, als der
"erwartetet/wahrgenommene Nutzen" (bzw. der Konkurrenz). Amen :-)

> Dies nur als - zugegeben wieder recht lang gewordene - Anmerkungen.

Und dies nur - zugegeben wieder recht lang gewordene - Bestätigung! Das
ist vermutlich die beste Einschätzung, die ich bis jetzt in diesem
Projekt gelesen habe. Respekt. Wir haben ja auch schon bei OOo ein paar
wenige Male darüber diskutiert - und vermutlich liegt ein Teil der
Antwort auch in Deiner Mail-Adresse ;-)

Hast Du Lust auf das Design Team? :-)

> Viele Grüße
>       Irmhild

Viele Grüße zurück,
Christoph


-- 
Informationen zur Abmeldung: E-Mail an discuss+help@de.libreoffice.org
Listenarchiv: http://listarchives.libreoffice.org/de/discuss/
Alle E-Mails an diese Liste werden unlöschbar öffentlich archiviert