Hallo Christoph, Christoph Noack schrieb: > Das stimmt, sobald Anwender ein gewisses Mindestmaß an Zeit investiert > haben, um die Interna (für Interessierte: das Systemmodell) verstanden > haben. Und, es gilt nur für bestimmte Bereiche von OOo.
genauso ist es > Bis dahin kostet es Anwendern teilweise viel Zeit und Aufwand, um sich > in OpenOffice.org einzuarbeiten. stimmt ebenfalls, aber der Aufwand lohnt sich. Das ist ja genau das Prinzip man investiert /einmal/ die Zeit zum lernen und hat für die Zukunft /immer/ eine *effiziente* Funktion. Genau das ist der Vorteil von OOo im Gegensatz zu MSO (an wie du richtig sagst bestimmten Stellen), denn MSO erfordert dort tendenziell weniger Lernaufwand bietet aber dann, trotz Lernen, weniger Effizienz, /dauerhaft weniger/. Du *glaubst* vielleicht (ich weiß es nicht) das OOo alles was es besser kann bewahren könnte, wenn versucht wird erkannte Vorteile von MSO hinzuzufügen - nur so linear ist der Zusammenhang, meiner Beobachtung nach, nicht. > Wenn unser Anwenderkreis also nur aus schon sehr gut eingearbeiteten > Nutzern bestehen würde, dann wäre meine Antwort auf Deine Mail > hinfällig. Ist sie - nehmen wir unsere breite Anwenderbasis mal als > Referenz - nicht :-) wird sie aber tendenziell, denn das Wissen der Anwenderschaft ist nicht statisch, sondern die Anwender lernen hinzu. Ein Mehrlernaufwand von einigen Stunden (für eine bestimmte Funktion) ist nichts wenn die Funktion so effizient ist das ich danach (immer wieder) 1 Minute spare. Ich kenne Firmen die in inhaltlich banale Makrolösungen hunderte Euro investieren um 10 Sekunden pro Ausführung eines bestimmten Arbeitsschritts zu sparen und aufgrund vieler Einzelnutzer rechen sich diese Makrolösungen binnen Wochen. > Aus Deinen bisherigen Aussagen schließe ich mal, dass Du mit > "Fehlerfreiheit" das Ausmerzen von funktionalen Fehlern meinst. > > Wenn das Gesamtprojekt nach genau dieser Maxime handeln würde, dann > würde in diesem komplexen Produkt (und der entsprechenden Menge an > Fehlermöglichkeiten) keine Zeit mehr für Funktionserweiterunge und > Verbesserung der Benutzbarkeit bleiben. Das genau verringert > den Anteil > der dafür spendierten Ressourcen, die Du (siehe Absätze unten) von UX > forderst wieder "mit Druck" einzuwerben. > > Wirkt auf mich sehr widersprüchlich; für Dich auch? Nicht unbedingt, denn ich habe die große Diskussion zur Thematik (ausgehend von der Kritik an Meeks) auf dev-de vor einiger Zeit mit den Entwicklern gelesen. Ganz eindeutig war zu erkennen das das Fixen von Bugs derzeitig in der Hinterhand ist, insofern die Einführung neuer Features eher vorne liegt, und nur so argumentiere ich, (es kann ja sein das sich in 2 Jahren die Verhältnisse anders darstellen). > Verbessert diese unergonomische Bedienung und den damit verbundenen > zusätzlichen Zeiteinsatz die wahrgenommene Qualität des Produkts (im > Vergleich zu anderer Software)? Die Erfahrung sagt "nein", > denn auch das > sind Fehler. Viele Unternehmen sind, wissend um langfristige Vorteile, bereit solche Dinge hinzunehmen, aber Unternehmen sind teils nicht in der Lage Fehler hinzunehmen. Ich kenne Firmenanwender die vor Chart2 das Modul Calc sachlich nicht benutzen konnten, weil es einfach Dinge gab die ihnen bei Chart1 nicht ausreichten und es gab keine geigneten workarounds. Selbe Anwender finden z.B. die bedingte Formatierung heute noch unergonomisch, nur da gibt es für sie Möglichkeiten das Programm doch zu nutzen. *So* liegen die Unterschiede, denn hier steht einmal sachlich begründete Nichtnutzbarkeit gegen Unzufriedenheit mit der Ergonomie, die aber die Nutzung nicht völlig ausschließt. Hier sagen zu wollen das Beides wichtig ist, ist theoretisch unwiderlegbar, aber praxisfern wenn man sich, wegen knapper Ressourcen, für nur eines entscheiden muß. > Jörg, Du hast mir mal auf dem LinuxTag gesagt, dass Dich die > Interna des > Gesamtprojekts bisher wenig interessiert haben (z. B. die Abläufe und > die Zusammenarbeit von/mit Sun). Deine Aussage oben verleitet mich zu > der Annahme, dass sich daran wenig geändert hat ... leider. 'Danke' für Deine Einschätzung meiner Person - wie kommst Du überhaupt dazu? Ich fänds besser über Sachinhalte zu streiten, denn nur das bringt OOo voran. Komm einfach in die tägliche Praxis von Migrationen und höre Dich um wie dort das Verständnis für Funktions-Bugs und Ergonomie-Probleme ist. Letztere sind unangenehm (und kosten indirekt auch Geld) Erste hingegen kosten richtig Geld wenn mit viel Aufwand z.B. mittels Makros workarounds realisiert werden müssen. (man könnte zwar, aus Dienstleistersicht, sagen Geld ist Geld, nur vor dem Hintergrund das ich Projektmitglied bin schmerzt es mich schon wenn Kunden Aufwendungen für workarounds tätigen müssen wo dieses GEld vielleicht besser in SChulungsmaßnahmen angelegt wäre.) Ich bin mir bewußt das sich das in Foren und Mailinglisten teils anders aussieht, nur dort sitzen weitaus weniger Multiplikatoren als bei Firmenanwendern. Auch ist es, meiner Beobachtung nach, ein Unterschied ob wir über öffentliche Aussagen von Firmen reden (denn kaum eine Firma die sich für OSS entscheidet redet das dann öffentlich runter) oder über ihre tatsächlichen Probleme, mit denen sie in Praxis zurechtkommen müssen und von denen man dann erfährt wenn man den Firmen Hilfe zu OOo leistet. Es wäre wohl besser wenn wir hier wechselseitig auf Erfahrungen und Wissen des jeweils Anderen hören, statt 'persönlich' zu werden, nur weil uns manche inhaltlichen Aussagen des Gegenüber nicht besonders gefallen. > Wie genau sieht aus Deiner Sicht das ideale "Kümmern" von UX aus? UX sollte Übersetzer/Mittler zwischen dem Endanwender, dem Projekt und den Entwicklern bei der Verbesserung des Programms sein. Nutzer haben Forderungen ohne technische Möglichkeiten genau zu kennen, Programmier haben technische Angebote ohne Nutzeranforderungen genau zu kennen, das gilt es zu vereinen. Ich würde es richtig/sinnvoll finden wenn UX die issue-schreibenden Nutzer in der Durchsetzung ihrer Wünsche unterstützt. Das ist etwas anderes als QA, denn es ginge darum das UX bewertet, Ergonomie testet, Meinungen sammelt und diese bündelt (so wie es z.B. dezeitig bzgl. der GUI geschiet) derum so Sinnvolles von wenig Sinnvollem zu scheiden. Hier geht es auch um langfristige, teils unangenehme Arbeit an der 'Front' wo sich Nutzer mal richtig Luft machen und man trotzdem versuchen muß sie ernst zu nehmen und ihre Interessen einerseits zu berücksichtigen und dort wo die Nutzerinteressen technisch nicht begründet sein mögen, trotzdem eine Brücke zu schlagen. Zu versuchen den Nutzern entgegen zukommen die nicht von sich aus mit ihren Anliegen zu uns finden wäre hierbei ebenfalls wichtig. Startcenter? Aber ganz sicher gehören solche Entwicklungen dazu, ich schrieb ja bereits das solcherart Schwerpunktsetzungen wichtig sind, nur sollten wir über die 'Kür' nicht die 'Pflicht' vergessen. Die neue Notizfunktion (die ich persönlich nicht mag, die aber der Mehrheit entgegenkommt) ist z.B. ein Stück 'Pflichterfüllung', das Startcenter hingegen ist 'Kür' insofern es Optionen für die WEiterentwicklung in der Zukunft schafft ohne momentan etwas zu verbessern, denn alles was derzeitig mit Startcenter geht giung früher auch ohne und geht auch heute ohne. Ich bin übrigens ausdücklicher Befürworter des Startcenters weil ich dessen WEiterentwicklungspotential sehe. > Mal als Gegenbeispiel: Warum gibt es so viele offene Issues in > OpenOffice.org? weil es nicht genug Kapazitäten gibt und weil Bug-Fixing häufig hinter neuen Features zurücksteht. > Kümmert sich die QA denn gar nicht darum? Das > müssen die > doch!!! Das ist doch die QA! (Meiner persönliche Meinung: Das tun sie > sehr gut; trotzdem bleibt OOo teilweise fehlerbehaftet.) Nö Christoph, ich mache hier keinen verbalen Sympatiewettkampf, dafür habe ich keine Zeit. Die Leute von QA arbeiten hart und anständig, wer würde das bestreiten wollen, den Endanwender interessiert aber das Gesamtergebnis was ihn in Form des Programs erreicht. Gruß Jörg --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
