Tag: design

Was gutes Design ausmacht

Es ist wirklich schade, dass es derzeit eigentlich so gut wie keinen anderen Hersteller auf diesem Planeten gibt, der so viel Energie in Design steckt wie Apple – und damit meine ich jetzt nicht nur optisches, sondern auch funktionales Design. Dabei kommen Produkte heraus, die erstens einfach funktionieren (Stichwort “idiotensicher”) und zweitens noch sehr sehr elegant aussehen.

Man kann nun über die Firma Apple geteilter Meinung sein – aber je mehr ich in die Apfel Welt eintauche und die Philosophie verinnerlicht habe, umso mehr fällt mir auf, wie viele bescheuerte Produkte es auf dem Markt gibt. Und selbst im Hochpreissegment gibt es in dieser Hinsicht keine großen Unterschiede. Es werden zwar bessere Materialien verwendet, die Bedienung bleibt aber immer wieder auf der Strecke.

Ich denke, dass Apple mit seinem Ansatz den richtigen Weg geht – und die aktuellen Bilanzen geben dem Konzern aber mal sowas von Recht. Allen Unkenrufen zum Trotz.

Aber zurück zum Video: Im ersten Teil spricht Dieter Rams, welcher DER Designer bei Braun war, darüber, was für ihn Design bedeutet. Anschließend kommt einer der besten Designer der Welt, Jony Ive, seines Zeichens Chefdesigner bei Apple, zu Wort. Er berichtet darüber, wie aus einem genormten Stück Metall verschiedenste Teile von Apple Produkten hergestellt werden, welche Schwierigkeiten dabei entstehen und wie viel Zeit man damit verbringen kann, überhaupt erstmal die Werkzeuge für den Bau der Geräte zu designen. Wenn man ihm so zuhört, erkennt man, was wirkliche Leidenschaft für seinen Beruf und vor allem für seine Fähigkeiten bedeutet.

Und nun: Film ab!

via dennis-wisnia.de

Readme driven Design – das etwas andere Pattern

Letzte Woche fiel mir ein sehr interessanter Beitrag (How I Develop Things and Why) zum Thema Entwicklungsstil in die Hände. Der Autor, Kenneth Reitz, vertrat dabei die Meinung, dass man alles sinnvoll designen sollte. Das mag jetzt zwar logisch klingen, ist es aber nicht. Wenn Entwickler von Design sprechen, dann ist meist das Design für den Endkunden gemeint. Die gleichen Regeln sollten aber auch für alle anderen gelten. Sprich, auch ein API oder eine Library sollte intuitiv und nutzerfreundlich sein.

Keneth, selbst ein bekennender Python Fan, geht darauf am Beispiel der http Library für eben diese Sprache ein. Sie tut zwar was sie soll, nervt den Entwickler aber mit unzähligen kryptischen Parametern und viel Schreibaufwand für einfachste Aufgaben. Um diesen Umstand zu verbessern, hat er eine Library geschrieben, die als Schnittstelle zwischen dem Entwickler und der ursprünglichen Library sitzt – spirch, ein Wrapper.

Und somit kommen wir zum Kern dieses Beitrages: Als Designphilosophie für diesen Wrapper wählte er das “Readme driven design”. Häh? So in etwa habe ich auch geschaut, als ich es zum ersten mal las. Das Prinzip ist aber recht sinnvoll: in der normalen Entwicklung fängt man mit einer simplen Idee an, baut das entsprechende API und alles ist toll. Nachdem die Grundfunktionen stehen, erweitert man das ganze, passt das API ein bisschen an, refactored ein bisschen, wieder wird das API angepasst usw. Irgendwann hat man zwar eine Library (bzw. ein Tool), die alles mögliche kann, was aber wiederum mit dem ursprünglichen API-Design nicht mehr realisierbar gewesen wäre. Heraus kommt dann ein Konstrukt aus undurchsichtigen Parametern und umständlichen Vorgehensweisen, um das gewünschte Ergebnis zu erhalten.

Die bessere Alternative ist nun folgende: man schreibt zuallererst die Readme Datei inkl. ausführlicher Syntax und Beispielen – genau so, als ob das Stückchen Software bereits existieren würde und fertig wäre. Und erst dann beginnt man mit der Umsetzung. Der Vorteil ist nun, dass man das API so designt hat, wie man gern damit arbeiten würde – unabhängig von auftretenden Hürden und Problemen. In der Regel sollte ein großer Teil der Entwickler in dieser Hinsicht ein gleiches Verständnis von “leicht” haben. Hinzu kommt: man “überdesignt” nicht – denn der Funktionsumfang ist ja nun genau definiert.

Wie man bereits feststellen kann, eignet sich diese Methode natürlich nicht für große Projekte – dafür macht sie für kleine Scripte oder Libraries umso mehr Sinn.

Was haltet ihr davon? Sinnvoll, oder Quatsch? Oder konntet ihr bereits Erfahrung damit sammeln?