Hallo @ll,
vielen Dank für die bisherigen Beiträge - positiver wie kritischer Art -
zu meinem Vorschlag.
Da diese Beiträge sehr vielfältig sind, versuche ich mal, Entscheidendes
zusammenzufassen und noch ein bisschen für meine Idee zu werben ;-)
< letztlich sehr lang geworden, wer mag, kann die Zusammenfassung
überspringen -> vgl. u.: "Fazit" >
Aus meiner Sicht gibt es im wesentlichen drei Punkte, die bisher
diskutiert wurden:
1. Wer sind die End-Nutzer? Wie sind sie erreichbar (sind sie es
überhaupt)? Was können sie (nicht)?
2. Wer vertritt die End-Nutzer? Ist das überhaupt möglich, sinnvoll,
notwendig? Welche Rolle haben oder hätten sie? Wie ginge das mit der
Organisation und Arbeit einer solchen Vertretung?
3. Worum kann es inhaltlich bei der Mitwirkung der End-Nutzer gehen? Wie
könnte das Verhältnis zu anderen Beteiligten, insbesondere den
Entwicklern, gestaltet werden?
zu 1. Wer sind die End-Nutzer? usw.:
Florian R. schrieb, dass "alle Zielgruppen" berücksichtigt werden
sollten, darunter auch
- Schüler (bis Matura | Abitur)
- Studenten
- (Entschuldigung für das Wort) Notorische Computerverweigerer "Wenn es
einfach ist, dann gut!"
- Ältere, die sich nicht mit Computern auskennen ca. 60+
(Entschuldigung, wenn ich euch damit beleidige, wenn ihr in diese Gruppe
fällt)
- ...
Durch diese Liste (die ja beliebig erweiterbar wäre) werden natürlich
Probleme einer potentiellen Nutzervertretung offensichtlich, die
ebenfalls schon angesprochen wurden:
- Sind (diese) End-Nutzer überhaupt erreichbar/ansprechbar? ("Und ganz
nebenbei, wie willst du die Benutzer erreichen die auch jetzt keine der
Möglichkeiten des Kontakts wahrnehmen." Michael M.)
- Würden sie sich einer Mitwirkung nicht verweigern ("Konsumhaltung")
oder ihr mit Unverständnis begegnen?
- Können (solche) Nutzer überhaupt sinnvolle Beiträge leisten?
zu 2.: Wer vertritt die End-Nutzer? usw.
Abgesehen von der prinzipiellen Frage, welche Rolle die Wahrnehmung und
Beachtung von End-Nutzern für ein F/OSS-Projekt überhaupt spielt (vgl.
unten), gab es mehrere Stellungnahmen (Bernhard, André, teilweise auch
Michael M.(?)) die für eine indirekte Vertretung der Endnutzer plädieren
bzw. diese bereits sehen, wenn auch nicht mit hinreichendem Nachdruck.
Der Ort dafür ist dann insbesondere das UX-Team und die geeigneten
Personen kämen aus diesem Team und/oder aus der Gruppe der
User-Betreuer/innen.
Gegen ein eigenes Gremium spricht auch der Aufwand und die Gefahr eines
"bürokratischen Monsters".
Zudem gibt es ein prinzipielles Problem: Verliert jemand, der über die
Fähigkeit verfügt, End-Nutzer/innen zu vertreten und ihre Sicht
gegenüber Entwicklern zu kommunizieren, nicht automatisch die
Eigenschaft "typischer Nutzer/in"? ("Das merkwürdige ist doch, sobald
jemand sich im Rahmen dieser Nutzervertretung beteiligt ist er Teil der
Community und man ist genau da wo man auch jetzt schon ist." Michael M.;
in der Tendenz ähnlich auch Bernhard und André)
zu 3.: Worum kann es inhaltlich bei der Mitwirkung der End-Nutzer gehen?
Wie könnte das Verhältnis zu anderen Beteiligten, insbesondere den
Entwicklern, gestaltet werden? usw.
Ich fang' mal mit der zweiten Frage an, da hier die Positionen sehr weit
auseinander gehen. Die Extrempunkte sind: Bedürfnisse der (End)-Nutzer
sind wenn nicht entscheidend so doch sehr wichtig (explizit von mir
selbst so vertreten ;-)) bis zu: Was im Projekt tatsächlich passiert,
entscheiden die Entwickler (als diejenigen, die die Arbeit machen: "Das
ist gerade der Punkt der mich irritiert. Ich sehe keinerlei
Ausgestaltung die das grundlegende Prinzip, dass am Ende jemand die
Arbeit machen muss aushebeln kann." Michael) oder diejenigen, die die
Entwickler bezahlen (Das Projekt soll sich/kann sich nicht nach den
Vorstellen der Nutzer richten sondern richtet sich "Nach den
Vorstellungen derjenigen die etwas dazu beitragen oder den Vorstellungen
derer die andere dazu bezahlen etwas beizutragen." Michael M.).
Dazwischen gibt es einiges, wobei es im wesentlichen um das
Sichtbarmachen und Kommunizieren der Anwenderbedürfnisse geht.
Stefan W. hält die Frage offen: "Das Ziel des einzelnen Mitwirkenden
kann zwar, muss aber überhaupt nicht sein, dass man ein Produkt
herstellt, das möglichst vielen Endanwendern Nutzen und Freude bringt.
Auf die Frage, wie stark sich das Projekt an den Bedürfnissen der Nutzer
orientiert und ob es das mehr oder weniger tun sollte, ist für mich
daher gar nicht so leicht zu beantworten." und verweist damit wieder auf
den Kontext F/OSS-Projekt.
Zur Frage der Inhalte der Mitwirkung wurden allgemein das genannt, was
im UX-Team eine Rolle spielt/spielen könnte ("Letztendlich geht es
darum, die Wichtigkeit bestimmter Punkte für den Endanwender bei den
Programmierern so präsent zu machen, dass diese auch Interesse an deren
Umsetzung haben." Bernhard), außerdem
- "Probleme und Wünsche der "typischen End-User"" (André)
- Feature-Requests, darunter "Makro-Unterstützung von Excel" und "ein
eigener Mail-Client"
- (seit Jahren offene) Bug-Reports
Soweit erstmal die Zusammenfassung - ich hoffe, ich habe niemanden
übersehen und keinen wichtigen Punkt ausgelassen.
Fazit:
Nun: noch gebe ich nicht auf - allerdings sehe ich, dass die Form(en)
der End-NutzerInnen-Vertretung der weitere Diskussion bedarf.
Wichtig: Selbstverständlich müssen Aufwand und Ertrag in einem wirklich
angemessenen Verhältnis stehen und jeder bürokratische Overhead
vermieden werden, dass können wir uns wirklich nicht leisten. Zudem:
Selbstverständlich bin ich selbst bereit mich in diesem Bereich - über
das Schreiben langer Mails hinaus ;-) - zu engagieren. Mir ist aber
trotz einschlägiger Andeutung immer noch nicht klar, was in dieser
Hinsicht sinnvoll und zielführend ist/sein könnte.
[NB @Bernhard: Ich lesen schon seit längerem die Design-Liste mit. (Und
ich weiß auch, dass UX Christoph ein entscheidendes Anliegen ist.)
Zugegeben: vieles auf der Liste überfliege ich nur, manches lese ich gar
nicht. Auch ist mir nicht wirklich klar, was hier wichtig ist und was
sich an Wichtigem vielleicht auf der Liste nicht widerspiegelt. Mein
Eindruck ist allerdings, dass UX so gut wie keine Rolle spielt,
diskutiert (und bearbeitet?) werden Design-Themen im engeren Sinne.]
Ein weiterer Punkt: Offensichtlich verweist das Thema "Berücksichtigung
von (End)-Nutzer-Bedürfnissen" bei F/OSS-Projekten auf prinzipielle
Fragen oder gar Schwierigkeiten. Ich weiß, dass es (viele?) Entwickler
gibt, die bei F/OSS-Projekten gerade deswegen mitmachen, weil sie in
Bezug auf das "was" und "wie" dessen, was sie entwickeln/programmieren
ihren eigenen Vorstellung folgen können. Ich weiß auch, dass LibO (oder
auch OOo) noch ein paar zusätzliche Besonderheiten/Schwierigkeiten
aufweisen, wie Herkunft aus closed source, schiere Größe des Programms
wie des Projekts, ausgeprägte "Konkurrenz" zu ähnlichen, auch
kommerziellen, Programmen etc.
Als Extremposition könnte man hier formulieren: F/OSS-Programme, die
sich an End-Nutzer richten, sind unmöglich (oder sie erfordern mündige
Anwender, die (zumindest potentiell) bereit und in der Lage sind,
Beiträge zu leisten, die sie für die Aufnahme in die Community
qualifizieren - das sind aber größtenteils nicht die End-Nutzer, die in
dieser Diskussion gemeint sind).
Gerade deswegen und mit Blick auf die neue Konkurrenz (z.B. Dienste wie
google docs oder neue Endgeräte) scheinen mir neue Wege angesagt, die
sich sicher nicht auf "Votings über Feature-Requests" beschränken
können. Ich denke da eher an Formen der Partizipation und Kommunikation,
in der beide 'Seiten', Entwickler wie Nutzer, eine aktive (im Idealfall:
gleichberechtigte) Rolle spielen. Gegenseitiges Verständnis und
"Überzeugung" sind hier die entscheidenden Stichworte.
Allerdings scheint auch mir selbst das gerade, nach allem was
geschrieben und diskutiert wurde, sehr idealistisch ;-) Zumal es eine
Änderung der Prinzipien bedeutet, ist also ein langfristiges Ding ...
Thematisch/inhaltlich denke ich da auch eher an die langfristige
Ausrichtung und grundlegende Entscheidungen, und weniger an die täglich
Arbeit. Deswegen wollte/will ich ja auch eine Vertretung/Repräsentation
in der TDF.
Vielleicht hilft ja eine Metapher: In der Frühzeit des Automobils musste
jeder Autofahrer auch mehr oder minder Automechaniker sein, das war
sogar Bestandteil der Führerscheinprüfung. Dann gab es eine lange Zeit,
in der Autos immer "nutzerfreundlicher" wurden. Mittlerweile kann
praktisch jede/r Autofahren (lernen) und nur noch die wenigsten
verstehen, was dabei vor sich geht (oftmals werden auch in der Werkstatt
nur noch Module gemäß Computerdiagnose ausgetauscht - ob das wirklich
nutzerfreundlich ist, steht auf einem anderen Blatt ;-)).
Aber: In Bezug auf SW befinden wir uns aus meiner Sicht derzeit mehr
oder minder am Ende der Zeit des Autofahrer=Automechaniker-Daseins.
Deswegen scheint mir das "wie" des nutzerfreundlicher Werdens ganz
entscheidend (oder alternativ die Entscheidung, dass sich LO nur an
bestimmte Zielgruppen richtet).
Dies nochmal als Diskussionsbeitrag.
Viele Grüße
Irmhild