Posts Tagged 'User Interface'

Ich könnt‘ plotzen!

Webbasierte Wireframing- und Mock-Up-Toos gibt es mittlerweile im Netz, wie Kühe auf der Weide. Grund genug, da mal schnell den Überblick zu verlieren. Obwohl es nette Menschen gibt, die viel Zeit haben, um verschiedene Tools auszuprobieren und kurze Reviews zu schreiben.

Ich habe vor ein paar Wochen für ein Projekt iPlotz benutzt. Ich hatte zuerst ein bisschen mit der Demo rumgespielt und mich dann für die Desktop-Kauf-Variante entschieden. Wer will schon seine Daten auf irgend einem amerikanischen Webserver liegen haben, wo Wer-Weiss-Wer Zugang hat. Der klare Vorteil bei iPlotz ist, dass man aus seinen Mock-Ups direkt einen klickbaren HTML-Prototypen exportieren kann, ähnlich wie bei Axure RP. So viel zur Theorie. Wie iPlotz mir in der Praxis geholfen/nicht geholfen hat, will ich hier mal schnell beschreiben. Diese Rezession bezieht sich nur auf die Desktop-Version 2.1 von iPlotz. Ich will das Tool nicht schlecht machen, denn das ist es defacto nicht. Vielmehr schildere ich meine Erfahrungen bei der Arbeit mit iPlotz.

Das Fazit zuerst. Ich wollte mit iPlotz einfach und schnell Wireframes und einen lo-fi HTML-Prototypen für einen Usability-Test basteln. Letztendlich funktionierte das auch. Aber hier und da machte mir es iPlotz nicht leicht. Meiner Meinung nach hat iPlotz seine Stärken für das schnelle Scribbeln von Mock-Ups in der frühen Ideenphase. Für mehr finde ich es noch nicht ausgereift genug. Die Frage ist, ob die Web-Version mehr kann, aber die ist mir im Moment noch zu unsicher.

1. Reaktionszeiten

Auf meinem Rechner (der nicht der langsamste ist) reagierte iPlotz nur sehr gemächlich auf sämtliche Aktionen mit der Mouse oder dem Keyboard. Die Geschwindigkeit nahm mit zunehmender Projektgröße ab.

2. Gewöhnungsbedürftige Shapes

Die Shapes sind irgendwie noch nicht sauber ausgearbeitet. Unterschiedliche Schriftarten und -größen, teilweise zu wenig Anpassungsmöglichkeiten. Allerdings muss man dazu sagen: es gibt recht häufig Updates.

3. HTML-Export

Eines der Top-Features von iPlotz ist die Möglichkeit, Projekte als HTML-Version auszugeben. Das liest sich erst mal gut und funktioniert auch irgendwie. Leider hatte ich einige Probleme mit den exportierten Dateien, wenn der Export denn überhaupt funktionierte. Das war nämlich nicht immer der Fall. Teilweise machte der Export einfach gar nichts. Es wurde auch keine Fehlermeldung angezeigt. Nahe an der Verzweiflung konnte ich durch Exportieren einzelner Screens und Entfernen von Elementen auf den Screens die nicht exportiert wurden das Problem eingrenzen. Verstanden habe ich es aber nicht. Scheinbar kam das liebe iPlotz mit einigen seiner eigenen Shapes nicht klar.

Ein weiteres Problem sind Links. Wenn man Screens mit anderen Screens verlinkt – was man sehr oft tut, wenn man einen Prototyp bauen will – geht der Link in der exportierten HTML-Version verloren. Mit absoluten URLs funktionierte es. Allerdings werden beim HTML-Export Links nicht unterstrichen dargestellt. Das macht es für Probanden oder Kunden schwierig diese zu finden und verfälscht u. U. das Ergebnis.

4. Unsinnige Benennung der exportierten Screens

Man kann den einzelnen Screens in iPlotz Titel geben. Das ist schön so. Exportiert man aber die Screens als JPG oder als HTML, stehen da andere Namen. Insbesondere, wenn man seine Wireframes aus den Kopien anderer Screens erstellt. Dann trägt der Dateiname nämlich nicht den Namen, den man im Tool für diesen Screen vergeben hat, sondern den ursprünglichen zuzüglich einer etwas seltsamen Nummerierung.

5. Massenexport

Jeder Wireframe kann nur einzeln ausgegeben werden. Oder habe ich die Funktion zum Exportieren des ganzen Projekts als JPG oder PDF übersehen? Das kann bei größeren Projekten sehr nervig werden. Ein weiteres Problem ist, dass man den Verzeichnispfad, in den man exportieren möchte jedes Mal neu angeben musste. Das kann man zwar umgehen, indem man erst mal alles in das Standardverzeichnis exportiert und dann kopiert. Ich finde aber das geht auch komfortabler.

Usability in der Straßenbahn?

Auf dem Weg zu einem naheliegenden Kundentermin habe ich gestern mal auf die Straßenbahn zurückgegeriffen. Eigentlich habe ich ja eine Monatskarte. Nur dummerweise ist die zusammen mit meinem Geldbeutel zuhause liegen geblieben.

Da stand ich also dann vor dem Fahrkartenautomaten in der Bahn und überlegte, ob ich für drei Stationen bezahle (Geld hatte ich mir geliehen) oder ob ich eine Schwarzfahrt riskiere. Da kam mir die Frage auf: Ist mangelhafte Usability beim Fahrkartenautomaten eigentlich eine ausreichende Begründung zum Schwarzfahren?

Ich will nicht die Automatensoftware der Bonner Verkehrsbetriebe analysieren. In der Regel sind die User Interfaces ja schon recht einfach gehalten. Aber was wäre passiert, wenn ich dem Kontrolleur verkauft hätte: „Ich habe mich bemüht eine Fahrkarte zu kaufen, konnte aber den Kauf nicht abschließen, weil ich das User Interface nicht verstanden habe.“ Ich vermute stark, dass der Kontrolleur meine Argumentation nicht verstanden hätte. Fahrkartenkontrolleure müssen schließlich ja keine Usability-Experten sein. Und ich glaube, dass ich bei meinem Gegenüber mindestens in den Top5 der seltensten Ausreden gelandet wäre. Aber wer weiß das schon.

Letztendlich habe ich mich gegen den Fahrkartenkauf entschieden. Schließlich hab ich ja eine. Bei einer kurzen Google-Befragung habe ich immerhin herausgefunden, dass man gar nicht Schwarzfahren kann, wenn man eine gültige Montaskarte besitzt. Schließlich schädigt man das Verkehrsunternehmen ja nicht.

Wieder was gelernt.