Logo: Pisto – Magazin über Web und die Welt

Magazin über Web und die Welt

Lob der Einfachheit

Maximales Maximum von Guido Boyke

Titelbild: Maximales Maximum

Software wird meistens für die Lösung einer bestimmten Aufgabe geschrieben. Mit jedem Entwicklungsschritt löst sie diese Aufgabe besser. Die Wünsche des Users werden immer besser verstanden. Der User wird von Mal zu Mal zufriedener, weil alles besser von der Hand geht. – Ein Märchen, das leider nie wahr werden wird.

Ich greife einfach mal einen Bereich heraus, mit dem ich viel zu tun habe: Content-Management-Systeme. Diese sind seit Ihren Anfängen immer komplexer geworden und erfüllen immer mehr Anforderungen. Leider kann ich nicht sehen, dass die Anwender im selben Maße zufriedener geworden wären, wie die Software komplexer wurde.
Und selbstverständlich sind sie selbst schuld daran, denn an der Software wird es ja wohl kaum liegen – oder?

Ein konkretes Beispiel soll das Rechtemanagement in Typo3 liefern: Ganz zu Beginn war Typo3 ein CMS, um einfach aufgebaute Webseiten ins Netz zu stellen. So konnte ein Redakteur auch ohne technische Vorkenntnisse und mit einer kurzen Einarbeitung Texte im Internet veröffentlichen. Ja, so war das mal, auch wenn es heute kaum noch jemand glauben mag.

Recht haben und Recht bekommen

Die Webseiten wurden komplexer. Auch die CMS wurden komplexer. Es gab nicht mehr nur einen Redakteur, sondern viele Leute, die an ein und derselben Website arbeiteten. Ein Rechtemanagement musste her.

Sowas fängt immer harmlos an. Sicherlich ist es sinnvoll, mehreren Usern den Zugriff auf ein System zu erlauben. Mit unterschiedlichen Accounts, mit unterschiedlichen Rechten. Aber wie unterschiedlich müssen diese Rechte wirklich sein? Dies ist der eigentliche Knackpunkt.

Mit dem Rechtemanagement in vielen CMS (z.B. Typo3)  können wir wirklich bis auf den letzten i-Punkt alles genau kontrollieren. Die Frage, die ich mir nur oft stelle, ist: Brauchen wir das? Oder wollen wir das, nur weil es geht?

Kontrolle über andere zu haben, scheint manche Menschen zu faszinieren. Und die Vorstellung, alles bis ins kleinste Detail unter Kontrolle zu haben, kommt gerade bei größeren Firmen sehr gut an. Hier wird gern ein wenig übertrieben und dem Affen Zucker gegeben. Am liebsten möchte man die ganze Firmenhierarchie mit dem System darstellen. Zwar wird es dadurch unbedienbar, aber sicher ist sicher. Und schließlich arbeiten diejenigen, die diese Featuritis beschließen, ja nicht mit dem System, so what?

Die bittersüße Wahrheit ist ja: Am Ende arbeiten auch bei großen Seiten nur eine Handvoll Leute mit dem System, die zudem alle sehr ähnliche Rechte besitzen. Von Hierarchie kann da oftmals gar keine Rede sein. Wozu also der Aufwand, die ganze betriebwirtschaftliche Organisationsstruktur mit all ihren Rechten und Restriktionen auf die Software zu übertragen? Aus Notwendigkeit? Nein, weil man's eben kann!

Auch der ewige Wunsch, den Workflow abzubilden, steht oft einer praktikablen Lösung im Wege. Muss ich denn alle Rechte und Abhängigkeiten, die eine Arbeit mit sich bringt, im System abbilden und damit die Menschen, die mit dem System arbeiten, entmündigen? Wissen die Menschen nicht auch so, was sie zu tun und zu lassen haben?
Wie war dies denn vor der Erfindung des Computers? Vermutlich herrschte in den Betrieben Anarchie.

Aus dem wahren Leben

Ein Autor (Achim) schreibt Artikel. Diese können aber nur von einem Redakteur (Ralf) freigegeben werden. In dem System gibt es eine Vielzahl von Autoren und Redakteuren. Autoren sind immer bestimmten Redakteuren zugeordnet. Die Artikel von Achim gehen also in diesem Fall immer an Ralf. Diese Beziehung der beiden User kann man natürlich im System fest verankern, so dass Achims Artikel nur zu Ralf kommen.

Frage: Muss das System dies wissen? Wenn wir ohne Computer arbeiten würden, dann würde Achim seine Artikel auf den Schreibtisch von Ralf legen, oder? Und es kommt noch besser: Wenn der Ralf mal krank ist, dann weiß der Achim, dass er seine Unterlagen durch die Renate überprüfen lassen muss. Und wenn die krank ist, dann darf er die Artikel selber freigeben. Hört sich kompliziert an, ist aber so. Möchte man diese Szenarien wirklich programmieren?

Warum sollte man dies fest in ein System hineingießen? Vielleicht wenn es sich um einen riesigen Verlag handelt. Gut. Kann sein. Aber die meisten Webredaktionen sind ja nicht sooo groß. Oftmals bestehen sie aus weniger Leuten, als ein Auto Reifen hat.

Ich finde es außerdem nicht wünschenswert, wenn die Computersysteme den Menschen das Denken abnehmen. Ich glaube z.B. nicht, dass Achim einen Artikel freigibt, obwohl er ihn zuerst der Redaktion vorlegen muss. Er bekäme nämlich sonst Ärger. Den hätte er übrigens auch ohne Arbeiten mit dem Computer bekommen. Warum sollten wir dies ändern? Das CMS stellt ja nur ein Arbeitsmittel dar, das dazu dient, Artikel ins Netz zu stellen. Es dient dazu, die erforderlichen Schritte möglichst einfach zu halten. Einfachheit ist das Stichwort.

Bei allem technisch Machbaren sollten wir immer im Auge behalten, ob eine technische Umsetzung des Machbaren auch wirklich den Nutzern einen Mehrwert gibt. Oft ist es doch viel besser, ein System einfacher und damit leichter bedienbar zu halten, als ein kompliziertes Rechtesystem zu verwenden, das nachher niemand mehr benutzen möchte.

Dies gilt natürlich nicht nur für das hier angesprochene Beispiel. Künstlich aufgeblasene Projekte kennt sicher jeder, der in diesem Bereich arbeitet. Deshalb: Einfach mal mehr Einfachheit wagen.

Der Autor

 Guido BoykeGuido Boyke ist als selbstständiger Webentwickler in Hamburg tätig. Er arbeitet haupsächlich in den Bereichen Typo3 und PHP. In letzter Zeit hat er aber auch ein Auge auf Ruby on Rails geworfen.

Titelbild: »tachometer« von Chepko via istockphoto.com

06.10.20086 Kommentare

Stichwörter:

Kommentare

Dieses "Einfach mal die Einfachheit wagen" hat meines Erachtens zwei Aspekte.

  • Der eine ist, dass jede Software nach langen Entwicklungszyklen zu "feature bloat" neigt. Wenn alle Bugs gefixed, die Oberfläche perfekt glatt poliert wurde - was bleibt dem Entwickler zu tun? Richtig, neue Features. Gerade Open-Source-Projekte wie das genannte TYPO3 sind maßgeblich von den Entwicklern getrieben, und Entwickler wollen zuallererst programmieren. Damit wird jedes gut durchgealterte System irgendwann sehr featurereich.
  • Der zweite ist, dass Anwender bei der Erstimplementierung eines grösseren Systems wie eben TYPO3 oder ezPublish nach dem Non-Plus-Ultra streben und natürlich jedes Fitzelchen von der Agentur einstellen lassen, um halt nichts falsch zu machen. Die spätere Praxis dämpft hier noch keinen der mutigen Entschlüsse Richtung "volle Workflowautomatisierung und feingranulierte rollenbasierende Rechtevergabe".

Das heißt, man muss beim Anwender ansetzen: Das System darf ruhig alles möglich können, aber der Anwender oder wahrscheinlich eher eine gut beratenden Agentur muss aber sinnvolle Selbstbeschränkungen aufstellen. Nicht einfach, wenn auf Basis verrechenbarer Stunden gearbeitet wird...

"Kontrolle über andere zu haben, scheint manche Menschen zu faszinieren."

Da ist wahrscheinlich in der Tat das Problem.

@ Robert
Das Software viel kann ist ja erstmal gut. Denn als Entwickler kann man dann aus dem Vollen schöpfen. Solange dabei nur das ausgewählt wird, was wirklich sinnvoll ist. Nur was, wenn der Auftraggeber eigentlich gar nichts sinnvolles haben will, sondern seinem "Wunschdenken" freien Lauf lässt.

"Nicht einfach, wenn auf Basis verrechenbarer Stunden gearbeitet wird..."
Nunja, letztendlich mag das Ergebnis bei besserer Bedienbarkeit überzeugender sein und damit auch der Kunde zufriedener. Allerdings, damit der Kunde merkt, dass er zufriedener ist (als er wäre, wenn es anders gelaufen wäre), muss er vorher schon bewußt schlechte Erfahrungen mit Featuritis gemacht haben.

Aus der Entwicklersicht betrachtet, ist Typo3 mitlerweile ein ziemlicher Krampf. Das Einrichten der von dir angesprochenen Rechtelösung ist ein schierer Aufwand, den dir, wenn du’s versuchst zu erklären, kein Schwein abnimmt.

Aus der soziologischen Sicht ist es nicht minder problematisch. Der Clou ist doch, das Typo3 eine lustige kleine Protokollfunktion hat, mit der man jeden Fliegenschiss rückgängig machen kann. Eine ausreichende Schulung der zukünftigen Redakteure, und man könnte glatt ein dutzend Admin-Accounts anlegen. Ich durfte letztens einen Mitarbeiterstamm von rund 30 Leuten auf 10 verschiedene Gruppen aufteilen, weil’s so gewollt war. Ich dachte nur, ich bin im falschen Film. Wozu dieser Kontrollzwang? Wozu gibt’s die Protokollierung? Hat jemand Scheiße gebaut, gibt’s halt eine Standpauke und einen Roll-Back, fertig. Die konsequente Arbeit an der Schulung der Mitarbeiter könnte viel mehr erreichen, als alle Restriktionen, die man mit der Rechtevergabe verteilen könnte.

Aber es ist ja so schön „einfach“, wenn auch auf einer recht subtilen Ebene, den Daumen draufzudrücken …

Es gibt durchaus Szenarien, in denen eine differenzierte Rechtevergabe Sinn macht und auch welche, in denen es mehr als eine Handvoll Leute sind. Dann spielen TYPO3 und wie die "Enterprise Lösungen" noch alle heißen mögen, an dieser Stelle ihre wahre Stärke aus.
Trotzdem müssen wir uns doch da ein bisschen an der eigenen Nase packen oder nicht?
Wir verkaufen die eierlegenden Wollmilchsäue und wir verkaufen unter anderem damit auch sowas wie den "Redaktionsworkflow" -wenn auch vielleicht nur indirekt.
Es stellt sich damit doch auch generell die Frage, ob nicht die wie auch immer geartete Featureflut mit zu diesem unsinnigen Gedanken beiträgt, dass man dieses und jenes auch noch bräuchte, weil es eben gerade "hip" ist und man sowas heute "eben auch hat" (beispielsweise eine "Redaktion").
Ich stelle im Alltag ganz allgemein fest: je mehr ein System kann, desto mehr trägt das dazu bei, ein Projekt zur Neverending Story werden zu lassen.

Natürlich gibt es durchaus Szenarien in denen eine Rechtevergabe eine wichtige Rolle spielt. Dies ist aber wohl bei recht wenig Projekten der Fall. Ich preise zum Beispiel keine eierlegenden Wollmilchsäue an und muss mich auch nicht an meine eigene Nase fassen. Warum sollte man auch Dinge anpreisen von denen man nicht überzeugt ist? Dies wird schließlich auf einen selber zurückfallen, weil man nämlich falsch beraten hat.

Einfach mal mehr Einfachheit wagen.

so gross ist das wagnis gar nicht.... apple versteht es seit jahren, schlicht wirkende produkte zu überzogenen preis unters (dankbare) volk zu bringen.
das problem ist vielmehr, dass nur wenige designer, coder u.a. in der lage sind, "einfachheit" umzusetzen und zu entscheiden, was weggelassen werden darf.

cx

Werbe-Kommentare werden wir übrigens löschen. Im Zweifel nehmen wir zumindest den Link zur beworbenen Homepage raus.

Es gibt zu diesem Artikel einen Kommentar-Feed