bamaru.com - René Föhring und Jonas Thiel über Design, Business und die Welt 2.0

Aber Mensch braucht Filesystem…

Ich weiß noch, wie ich als Kind stolz war auf die Ordnung auf meiner Festplatte. Da gab es eine seperate Partition für Windows, eine für Programme und Spiele und eine Dritte für Daten (Treiber, etc.). Die Ordnerstruktur war sauber durchdacht und alles hatte seinen Platz nach meinem Willen. Ich hab mich auch immer über Leute mit zugemüllten Festplatten und Desktops amüsiert, die einfach scheinbar keine Kontrolle über die Verteilung ihrer Daten auf ihrem Computer hatten. Wie würden die denn jemals eine bestimmte Datei auf ihrer Platte wiederfinden?

Mittlerweile sehe ich das grundlegend anders. Irgendwer (ich glaube Bertrand Serlet) hat mal gesagt, dass seiner Meinung nach der Enduser das Filesystem niemals sehen müsste bzw. dürfte. Das verwunderte mich, wirkte befremdlich, doch nach einiger Überlegung stimme ich mittlerweile zu.

Die Gründe:

• Den Enduser, der den Computer wohlgemerkt nicht professionell nutzt, interessiert die physikalische Organisation seiner Daten nicht. Wenn man keine Ahnung davon hat, was hinter den Programmen und Dateien und all dem steht, dann steht man im Zweifelsfall natürlich blöd da. Man hat ja keine Autonomie, kann nicht mal eben das System neu aufsetzen oder den kaputten Treiber ersetzen. Aber Hand aufs Herz: Genau diesen Mangel an Autonomie hab ich auch bei meinem Auto oder meiner Waschmaschine. Nur, weil ich mich mit Computern auskenne, heisst das noch lange nicht, dass das jeder muss.
• Die Grenzen zwischen den Geräten verschwimmen. Mobile Computer und Smartphones sind was UI und UX angeht eher mit Spielekonsolen vergleichbar als mit klassischen Arbeitsrechnern. Der Ease-of-Use steht damit im Konsumerbereich klar im Vordergrund.
• Daraus folgt auch: Mir sollte wichtig sein, dass ich mein Word-Dokument sowohl mit Pages als auch mit Word oder OpenOffice bearbeiten kann. Wichtig ist auch die Möglichkeit, ein Backup machen zu können. Aber, ob die Dateien unter /usr/rene/etc/dokumente oder unter C:\Dokumente\Benutzer\rene\Eigene Dateien liegen – nun, dass ist wirklich nicht kriegsentscheidend.

Letztendlich machen wir als Entwickler nichts anderes, wenn wir Bibliotheken und APIs einsetzen um bspw. CSV-Dateien zu schreiben oder HTML-Dateien zu parsen: Wir erfinden das Rad nicht neu und nutzen Werkzeuge, die wiederkehrende Prozesse abstrahieren. Insofern macht es Sinn, dass das Filesystem von einem modernen Konsumer-OS quasi abstrahiert und verborgen wird.

You can’t handle the truth!

A Few Good Men

Das könnte ich auch ernsthaft den Leuten an den Kopf werfen, die die Software zur studentischen Selbstverwaltung unserer Uni geschrieben haben: Egal ob Notenschnitt, Bescheinigung oder Prüfungsanmeldung – das Stück Software ist einfach nicht benutzbar. Und wahrscheinlich würden diese Wirtschaftsinformatiker dann argumentieren: “Tja, das ist halt alles nicht so einfach” oder “Komplizierte Vorgänge münden nunmal in komplexer Software”.

ABER: Menschen wollen per se keine komplizierten Prozeduren durchlaufen! Ich gehe noch weiter und sage, dass sie auch keine tausend Optionen, Einstellungsmöglichkeiten und Settings-Menüs wollen die drei Seiten lang sind. Natürlich will ich meinem Handy sagen können: “Jetzt lautlos.” und “Jetzt klingeln.” – und wahrscheinlich will ich auch für beide Zustände das vibrieren an-/abschalten können. Aber wenn ich an Handys denke, die noch 5 weitere, typisierbare “Profile” anbieten, in denen ich Umgebungsgeräuschdämpfung, Lautstärke des Mikros, Klingeltöne und am besten Displayhelligkeit beim Anruf einstellen kann, dann ist das einfach too much.

Solche Möglichkeiten wollen bestenfalls digitale Heimwerker, Fummler und Nerds, die auch bei jeder Software ab Version 1.0 nach Skins und Themes schreien. Alle anderen wollen, dass die verdammte Software den verdammten Job erledigt. Und das soll jetzt gar nicht mal ein Rant gegen bloated-software werden, obwohl das sicher ein sehr artverwandtes Thema ist.

Es geht vielmehr darum, dass viele Menschen und damit User gar nicht wissen was sie wollen (im Sinne von brauchen). Marco Ament beschreibt ganz anschaulich, warum er nicht auf die Wünsche seiner Kunden eingeht, obwohl diese manche Features sehr vehement fordern.

Software ist verdammt kompliziert zu entwickeln, sie sollte nicht auch noch kompliziert zu nutzen sein. Denn, dass zu viel Realismus jedem Spiel den Spaß nimmt, weiß auch jeder Nerd.

Ein (natürlich sehr technischer) Bericht über die “Lessons learned” bei der Programmierung von Posterous:

There are a bunch of basic functional elements to building out a popular Rails app that I’ve never really seen explained in one place, but we had to learn the hard way while building Posterous. Here’s a rundown of what we’ve learned [...]

Die Erfahrungen der Macher kurz zusammengefasst:

• Amazon S3 zum Speichern von user-generated-content verwenden
• Cache-Control für statische Inhalte einsetzen und mit YSlow testen
• Zur Volltextsuche die eigene DB benutzen, anstatt externer Lösungen
• InnoDB beim Lesen langsamer, aber crash resistenter als MyISAM
• Queries sind die Schwachpunkte der Applikation
• Du bist nur so gut, wie dein langsamster Query
• Setz memcache erst ein, wenn es nötig ist
• Bestimmte, arbeitsintensive Jobs aus der App auslagern
  (Resizen von Bildern, Kodieren von Video, o.ä.)
• Erreichbarkeit ist das A und O -> Monitoring!
• Vorsichtig sein mit veralteten Rails-Plugins
• Fehler selber fixen und daraus lernen, ist schließlich Open-Source
  (anstatt bei Twitter rumzujammern)

Mehr im Originalartikel auf Axon Flux.