Sessionmitschrieb vom BarCamp Karlsruhe 2011. Session von Saskia Jancik.

Das was der Benutzer von der Software sieht, ist nur das Interface, vom Interface werden Rückschlüsse auf die Software gezogen, deshalb sollte man viel Liebe und Aufwand in das Benutzerinterface stecken. Ein Interface ohne Funktionalität ist aber natürlich auch nichts. Das Interface muss Professionalität vermitteln, das gibt dem Benutzer Sicherheit, die Software muss das alles selbst vermitteln. Wichtig ist auch der Spaßfaktor, nicht überall Scherze verstecken, sondern die Benutzung sollte Spaß machen.

Die Basis bildet die Funktionalität, z.B. Buttons. Die nächste Stufe des Designs ist, Konsistenz zu geben, klare Strukturen zu definieren. Die nächste Stufe ist die Usability, dem Benutzer Werkzeuge in die Hand geben, um die Software zu benutzen. Die obersten Stufe sind dann Professionalität, quasi als Erweiterung der Usability und Kreativität, aber hier sollte man eher auf gängiges zurückgreifen. Bei der obersten Stufe muss man auch am Ball bleiben und sehen, was gerade der aktuelle Trend ist. Sehgewohnheiten verändern sich auch sehr schnell.

90% des Designs besteht aus rationalen Regeln, bis zur Usability bekommt es jeder hin, für den Rest benötigt man etwas Gespür.

Konsistenz: Gleiches sieht immer gleich aus und steht immer an den selben Stellen, z.B. “Okay” und “Abbrechen” rechts unten. Auch Abstände sollten konsistent sein, da das Auge sich schnell an bestimmte Positionierungen gewöhnt. “Okay” und “Abbrechen” z.B. sollten auch nicht “irgendwo” rechts unten sein. “Don't make me think!” von Steve Krug ist das entsprechende Buch dazu, es geht darum, dass man Leute nicht irritieren soll. Auch wenn man nicht bewusst merkt, dass ein Button woanders ist, führt es doch zu einem kurzen Innehalten/Zögern. Im Web hat es auch oft den Effekt, dass Leute aussteigen.

Beispiel: 4 Punkte als Buttons als Links untereinander. Problem: Benutzer liest immer alles. Besser: Zusätzliche Überschriften einfügen und Abstände einfügen. Abstände sind generell wichtig. Außerdem den wichtigsten Punkt an die erste Stelle stellen und besonders hervorheben.

Blickführung ist ebenfalls wichtig, nicht alles gleich anzeigen, sondern Überschriften hervorheben, unwichtiges kleiner und heller machen, aber natürlich nicht übertreiben, da es gerade auch in Onlineshops Unsicherheiten erzeugen wenn der Text dann schlecht lesbar ist. Farben sollte man bewusst wählen, und von Komplementärfarben die Finger weg lassen. Auch nicht 5 Buttons auf der Seite rot machen. Buttons mit Umrandung erzeugen Unruhe, besser helle Hintergrundfarben verwenden. Linien sind mächtig, aber man muss vorsichtig sein.

“Simplicity” - es gibt auch ein gleichnamiges Buch von John Maeda dazu zum Thema Interfacedesign.

• Reduzieren: Punkte, wenn man sie nicht braucht, wegschmeißen, und die anderen verbinden, verstecken, …
• Organisieren: Gruppen nach Themen bilden, ähnliche Funktionen ineinander integrieren
• Zeit sparen: Zeit des Benutzer einsparen, das, was die meisten Leute benutzen am besten auffindbar machen und die 2%, die Spezialfunktionen nutzen wollen, werden auch die 1 Minute länger suchen
• Beim Lernen Frust vermeiden: Wenn man eine neue Software verwendet, muss man sich erst einmal einarbeiten. Man sollte aber den Benutzer nicht frustrieren, sondern dem Benutzer schnell Erfolgserlebnisse ermöglichen, Tutorials anbieten, die ersten, üblichen Schritte kennzeichnen, außerdem in der Software Erklärungen/Hilfestellungen anbieten. Wenn persönliche Daten abgefragt werden, sollte man erklären, wieso z.B. die Schuhgröße abgefragt wird.

Frage: Wie halte ich Interfacedesign-Entscheidungen fest für ein Team? Dicke Styleguides machen wenig Sinn, aber 1 DIN A4-Seite macht Sinn. Bei sich wiederholenden Mustern kann man auch Musterscreens zur Verfügung stellen. Man muss den Entwicklern erklären, warum Interfacedesign wichtig ist, und es sollte einen Verantwortlichen geben, der bei notwendigen Abweichungen Entscheidungen trifft. Wichtig ist, die Leute zu schulen und das entsprechende Verständnis zu vermitteln.

Nachdem ich im vergangenen Jahr so gut wie nichts über mich geschrieben habe, möchte ich das hiermit nachholen.

Seit Anfang Oktober 2008 wohne und lebe ich zu großen Teilen in Karlsruhe und studiere dort nun schon ein ganzes Semester lang Informatik. 1. Semester Informatik, das heißt insbesondere in Karlsruhe sehr viel Mathematik. Mit Analysis und Linearer Algebra durfte ich mich in den letzten Monaten intensiv beschäftigen, und das wird sich auch nicht so schnell ändern, denn die großen Mathematikklausuren sind erst im September und bis dahin gibt es auch noch einmal ein ganzes Semester lang Vorlesungen. Jede Woche ein Übungsblatt zur Analysis und zur Linearen Algebra fordern durchaus einige Zeit, die dann natürlich für anderes nicht mehr da ist. Weniger anstrengend, aber dennoch nicht trivial waren dann die “Grundbegriffe der Informatik”, eine Theorieveranstaltung und “Programmieren”, wo wir Java programmieren lernten (in der Vorlesung natürlich auch nur theoretisch). Am 10. März wurden die Grundbegriffe der Informatik mit einer Klausur abgeschlossen, die ich erfolgreich bestand, in Programmieren waren zwei Abschlussaufgaben einzureichen, bei der ersten erreichte ich die Bestbewertung, von der zweiten haben wir noch kein Ergebnis.

Noch vor meinem Studienbeginn habe ich mich als IT-Dienstleister selbständig gemacht. Hauptbestandteil dieser Tätigkeit war bis jetzt das Programmieren mit PHP und JavaScript (sowie damit verbunden die Arbeit mit (X)HTML und CSS). Mittlerweile auch schon ein Projekt abgeschlossen, das ist das Gesetzwiki, ein auf DokuWiki basierendes Wiki für Gesetzesänderungsvorschläge und ein weiteres Projekt ist mittlerweile online, wenn auch noch nicht endgültig fertig, das ist NIC Easy, ein Portal, auf dem man Domains kaufen und verwalten kann.

Viel beschäftigt habe ich mich im letzten 3/4 Jahr mit DokuWiki, dies zeigt zum einen natürlich DokuFS. Zum anderen gibt es seit einer Weile, hier noch unerwähnt, ein OpenStreetmap-Plugin für DokuWiki von mir und ich habe auch schon kleinere Sachen zu DokuWiki selbst und zu bestehenden Plugins beigetragen. Und nicht zuletzt bei der Arbeit am Gesetzwiki habe ich auch sehr viel über DokuWiki gelernt und erlebt, wie flexibel man mit DokuWiki auch Webapplikationen entwickeln kann, die nicht nur so wie ein traditionelles Wiki funktionieren. Die Arbeit an und mit DokuWiki und mit den DokuWiki-Entwicklern zusammen, die ich letzten Sommer im Rahmen der FrOSCon bei den DokuWiki hackdays auch persönlich getroffen habe, macht mir nach wie vor viel Spaß und wird mich vermutlich auch weiterhin begleiten, meine Todo-Liste für Dinge im DokuWiki-Umfeld wächst derzeit eher, als dass sie schrumpft…

Soviel dazu, weitere Blog-Einträge werden in kurzer Zeit folgen (da bereits vorbereitet).

DokuFS is a FUSE filesystem that allows you to mount a wiki:DokuWiki installation over XML-RPC into your local filesystem.

Two days ago already I've put a new release of DokuFS online into my new cgit installation. There is not only that new release available, but also the whole history, you are able to browse the code, …

But now coming to the important point: the release. It is built for the DokuWiki ♥ release 2009-02-14. First of all there is a completely new big feature: media support. You can upload any number of files by just copying them into the right directory of your mounted DokuWiki. In my opinion that is one of the best uses for DokuFS. Download is, of course, supported, too. At the moment there isn't any cache for media files, please let me know if you need/want that.

There are other smaller features, among others you can disable the cache to always have a fresh copy of your files and you can specify the number of seconds between updates. There were a lot of bugs and problems in the update routine, I'm not sure if it really worked at all. Now it should work. At least I tested it and after I had fixed a lot of things it did work. And it should even work when the local clock and the clock on the server are totally out of sync and in different time zones.

Another change is that I'm using a real option parser now, the options use two dashes now and the help message has a different format. This should give you better error messages as the old ones weren't that good.

There are some other changes I almost forgot as I've done them last August already. It concerns the fact that DokuFS is now not only storing the names of the pages but also a lot of meta data it gets from the wiki when asking for all pages (this feature has been implemented in DokuWiki in August, too). This means that DokuFS no longer has to load a page from the wiki in order to know it's size and there are much better permission checks, too. As well for existing as for non-existing files there is a real permission check before you can open that file for write which prevents you from writing a page you can't save afterwards.

As before you can download from dokufs.rb and the usage information can be found under DokuFS. And now you can also use the git repository of DokuFS.

Nevertheless I am also experiencing the limits of FuseFS, the Ruby interface for fuse I am using, that is a rather high-level one. At the beginning that was right, but now as I'm having more and more a full-featured filesystem with permissions etc. I am thinking about moving to another system. Although I really do like Ruby I am also thinking about moving to Python. This has multiple reasons. First of all there is chimeric working on DokuVimKi and a general Python lib for the XML-RPC interface of DokuWiki and there is Notefinder, another piece of software that uses the XML-RPC API of DokuWiki and Python, too. I don't see any sense in doing the same thing twice, that's why I would love to use and extend this python lib. Furthermore I have the impression, that the fuse interface for Python is better and better maintained (the last release is from 2007 in contrast to 2005). This is an impression from someone who has used none of the two full implementations (I use rfuse as comparison here, as it exposes more of the complete fuse api than FuseFS and as such it is similiar to python-fuse).

Before I can begin this conversion project I first of all have to learn Python, so don't expect anything soon. Perhaps it will still be in spring, but more probably it will be in the summer when you can see something from that new project. But one thing is sure: It will be maintained in the git repository I've already linked so you can probably follow the development from the beginning. And if you want to join it, just comment or mail me so we can coordinate.

I've just finished a new version of DokuFS, my FUSE for DokuWiki.

New features are:

• A cache (with memory limit)
• File size is now set properly (some graphical editors rely on that)
• Saving a file without content but a revision comment does no longer directly delete the file, but removes it from the directory listing (deleting the file was irritating some editors)
• Saving empty files doesn't change their content, this change was necessary because on an edit an empty file is saved first before the new content is saved.

All in all I have to say that writing a filesystem isn't that easy as I thought when your back-end isn't a traditional storage. The next features that will be implemented are permission-checking on client side and a check if the write was successful.

The filesystem can be found under dokufs.rb, usage information is under DokuFS.

Ich schrieb bereits öfters über meinen Plan, ein WikiBlog zu programmieren. Vielleicht auch zu oft, denn Tatsache ist, dass ich von einer Idee in die nächste kam und am Ende alles derartig kompliziert wurde, dass ich bis jetzt nur einen kleinen Teil unfertig umgesetzt habe. Und dies wird eventuell auch so bleiben.

Eher zufällig lernte ich in letzter Zeit DokuWiki kennen. Ich muss zugeben, als ich die ersten Websites mit DokuWiki sah, war ich nicht sehr begeistert, sie schienen mir immer gleich auszusehen und im allgemeinen nicht viel zu können. Diese Ansicht hat sich aber radikal geändert, als ich mich mehr mit DokuWiki beschäftigt habe. Nicht nur, dass man DokuWiki so gestalten kann, dass man auf den ersten Blick gar kein DokuWiki mehr erkennt, man kann es vielmehr auch so erweitern, dass es nicht nur ein Wiki sondern auch ein Blog mit allen Funktionen, die man sich nur denken kann, wird. Möglich wird dies durch ein Pluginsystem, das das Hinzufügen neuer Funktionalitäten ermöglicht.

Diese Website basiert jetzt auf DokuWiki und ist ein WikiBlog bzw. Bliki. D.h. es gibt hier Bereiche, die eher an ein Blog erinnern, während andere eher einem Wiki gleichen. Dazu gibt es Kommentare, Trackbacks und Tags. Es funktioniert noch nicht ganz alles so, wie es soll, die Tag-Übersicht geht in dem Sinne nicht, dass die Links nicht funktionieren. Ein eigenes Design fehlt ebenfalls noch und inhaltlich möchte ich auch noch einige Dinge ändern. Ich habe die mir wesentlich erscheinenden Inhalte aus meinem alten Blog kopiert, einige Inhalte, die ich in größerem Umfang ändern möchte, fehlen aber noch. Auch “richtige” RSS-Feeds muss ich noch einrichten, es wird in Zukunft aber auf jeden Fall Feeds mit den neusten Einträgen und den neuesten Kommentaren geben.