Software erlebbar machen, ohne eine Zeile Code zu schreiben

Das Projekt war gescheitert. Eigentlich war alles nach Plan verlaufen. Nach der Spezifikation der Anforderungen war ein umfangreiches Konzept erstellt worden. Auf knapp dreihundert Seiten, wurde bis ins kleinste Detail spezifiziert, wie sich die Software zu verhalten hatte. Sowohl das Projektteam als auch der Kunde waren sich einig, dass genau so das Produkt umgesetzt werden sollte. Die Software war gemäß der Spezifikation implementiert und getestet worden. Also sollte das Projekt erfolgreich sein, oder? Leider nein! Das Ergebnis war nicht das, was sich der Kunde vorgestellt hatte. Die Endkunden beschwerten sich, dass die Software ihnen nicht bei ihren Problemen half und zudem schwer zu bedienen war. Neuentwicklung? Viel zu teuer! Also blieb die Software, wie sie war und alle Beteiligten waren unzufrieden. Wenn man doch nur in die Zukunft schauen könnte, um schon vor der Implementierung zu wissen, ob ein Projekt erfolgreich sein wird …

Eine Kristallkugel haben wir auch nicht, aber diese ist auch nicht notwendig. Mit geeigneten Prozessen und Methoden kann dem geschilderten Problem entgegengewirkt werden.
Dazu sind zwei Voraussetzungen nötig:

  1. Das Konzept sollte so früh wie möglich erlebbar gemacht werden
  2. Schon vor der Implementierung sollte das Konzept getestet und iterativ weiterentwickelt werden

 

Lebendige Objekte statt tote Dokumente

 

Umfangreichere Spezifikationen garantieren keinen Projekterfolg. Sie werden selten von allen Beteiligten gelesen – und wenn doch, werden sie von jedem anders verstanden. Außerdem schleichen sich schnell Inkonsistenzen ein, die aufgrund des Dokumentenumfangs kaum bemerkt werden können. Zusammenfassend gesagt, dienen umfangreiche Dokumente mehr der Absicherung als der Kommunikation. Jedoch ist ein frühzeitiges gemeinsames Bild vom Produkt essentiell für den Projekterfolg.

Hier stellen Prototypen ein besseres Medium dar, um eine Produktidee oder ein Konzept zu kommunizieren. Prototypen helfen, die Software schon erfahrbar machen, bevor die erste Zeile Code geschrieben wurde. Dabei muss es sich weder um programmierte Prototypen handeln, noch müssen die entstandenen Entwürfe pixelgenau ausgestaltet sein. Entscheidend ist, dass  der Prototyp das kommuniziert und erlebbar macht, was gerade im Projektteam oder mit den Endnutzern besprochen wird.

Wissen statt raten

Jede Idee ist, so gut sie auch klingen mag, am Anfang eine Hypothese. Ohne eine Überprüfung ist eine Hypothese kaum etwas wert. Um sicher zu stellen, dass eine Produktidee erfolgreich sein kann, muss diese getestet werden. Mit Prototypen kann eine Idee getestet werden, ohne dass das eigentliche Produkt fertig entwickelt werden muss. Da die Erstellung eines Prototypen nur einen Bruchteil der späteren Entwicklungskosten ausmacht, können kostengünstig mehrere Iterationszyklen mit dem Prototyp vollzogen werden, bevor das eigentliche Produkt entwickelt wird.

 

Fehler so früh wie möglich machen!

 

Auf den ersten Blick scheint es so, dass die  Erstellung von Prototypen unnötige zusätzliche Kosten für Projekt verursacht. Jedoch ist dies nur eine sehr kurzsichtige Betrachtungsweise. Auf den gesamten Projektverlauf gesehen, sparen Prototypen mehr Geld ein, als sie kosten.

Je weiter ein IT-Projekt fortgeschritten ist, desto teurer wird es, Fehler zu beseitigen oder Änderungen am Produkt vorzunehmen.  Fehler per se lassen sich nicht vermeiden, doch teure Fehler können vermieden werden. So kostet die gleiche Änderung im Prototyp einige Minuten, jedoch in der Entwicklung mehrere Stunden bis Tage.

Fazit

Der Einsatz von Prototypen spart langfristig Geld und sichert den Projekterfolg. Er bietet folgende Vorteile:

  • Besseres Feedback
    Das Produkt ist in einem sehr frühen Stadium erfahrbar. Da das Abstraktionsniveau zum Verständnis bei einem Prototypen sehr gering ist, kann frühzeitig von allen Projektbeteiligten Feedback eingeholt werden.
  • Validiertes Konzept vor der Entwicklung
    Schon vor der ersten Zeile Code konnten Sie oder Ihre Endkunden einen Eindruck vom Endprodukt erhalten. Bereits in der Konzeptionsphase kann der Prototyp mit  Nutzern getestet werden.
  • Gemeinsames Verständnis des Produktes von Anfang an
    Damit das Projekt erfolgreich wird, ist es von essentieller Bedeutung, dass alle Projektbeteiligten das gleiche Bild vom Produkt im Kopf haben.

 

 

 

Ein StyleExplorer für Justinmind-Prototypen

Im Rahmen des Eurostars Forschungsprojekts „Advanced Prototyping Platform“ kurz APP entwickelt die SIC! Software GmbH ein StyleExplorer-Tool für Justinmind Prototypen.

Während der Konzeptionsphase einer Softwareanwendung werden verschiedene Konzept- und Styleguide-Dokumente für Kunden und zur späteren Implementierung für Entwickler erstellt. Diese basieren häufig auf erstellten Prototypen. Hierbei ist es immer wieder aufwendig benötigte Grafiken sowie Layout- und Styleinformationen wie Abstände, Schriftgrößen und Farben in einer aufbereiteten Form, direkt aus dem Prototypen zu extrahieren. Um diese Informationen dennoch zu erhalten muss oftmals mit exportierten Bildern oder Screenshots und weiteren Tools wie Photoshop oder Illustrator gearbeitet werden. Das ist zum einen umständlich und führt zum anderen zu erhöhten Aufwänden.

Im Prozess einer effizienten und effektiven Bereitstellung entsprechender Grafiken sowie Layout- und Styleinformationen sehen wir ein großes Optimierungspotential. Deshalb haben wir es uns im Rahmen des APP-Projekts als ein Ziel gesetzt ein StyleExplorer-Tool für Justinmind-Prototypen zu entwickeln.

Während der Anforderungsanalyse zum StyleExplorer-Tool haben wir verschiedene Ansätze zur Umsetzung evaluiert. So zum Beispiel ein programmgesteuertes automatisches oder halbautomatisches Ausfüllen von Microsoft Word-Templates zur Erstellung eines Styleguides für Prototypen direkt über den Justinmind-Prototyper. Allerdings hat sich durch Befragungen von UI-Designern und Entwicklern schnell gezeigt, dass ein solch erstellter Styleguide zu unflexibel ist, um die unterschiedlichsten Ansprüche in Kundenprojekten zu erfüllen. Darüber hinaus ist eine Fixierung nur auf Microsoft Word Dokumente für Styleguides oder Konzept-Dokumente unrealistisch, da dafür auch andere Programme wie Adobe InDesign oder Microsoft PowerPoint verwendet werden.

Aus diesen Gründen haben wir uns dagegen entschieden ein Tool zu entwickeln, welches automatisch Dokumente in einem bestimmten Format generiert. Statt dessen wollen wir mit dem StyleExplorer Designern und Entwicklern ein Werkzeug in die Hand geben, mit dem sie einfach an die nötigen Style- und Layout-Informationen und Grafiken eines Justinmind Prototypen gelangen. Darüber hinaus sollen diese Informationen und Grafiken per Drag’n’Drop oder Copy&Paste in unterschiedliche Programme wie Microsoft Word bzw. PowerPoint oder auch Adobe InDesign exportiert werden können, so dass bei der Gestaltung der benötigten Dokumente selbst keine Grenzen gesetzt sind.

Nachfolgend ist ein Scribble abgebildet, wie wir die Umsetzung der Hauptarbeitsfläche des Tools planen, um relevante Grafiken und Informationen zu einem Prototype-Screen einfach zu extrahieren.

Scribble-StyleExplorer

Die Hauptarbeitsfläche wird automatisch angezeigt, sobald ein Justinmind-Prototyp über das Tool geöffnet wird. Die Arbeitsfläche ist in drei Bereiche aufgeteilt: Toolbar oben, Screen-Anzeige links und in Informationsbereich rechts.

Für den ersten Bereich die Toolbar sind folgende Funktionen angedacht.

  • Wechseln des angezeigten Screens
  • Einstellen des Zoom-Levels zur Anzeige des Screens
  • Anpassung des Fixpunktes zur Bestimmung der Position eines Elements innerhalb des Screens
  • Freie Auswahl einer bestimmte Farbe vom Screen über einen Color-Picker

Nachfolgend ist häufig vom Begriff „Element“ die Rede. Dabei handelt es sich um ein Gestaltungselement auf einem Screen eines Prototypen. Das kann zum Beispiel ein Label, ein Button, eine Grafik, eine Bar oder Ähnliches sein.

Im zweiten Bereich wird der ausgewählten Screen angezeigt. Folgende Funktionen sollen unterstützt werden.

  • Annähernd originalgetreue Darstellung des Justinmind Prototype-Screens
  • Selektieren und Deselektieren von Elementen
  • Hervorhebung des selektierten Elements
  • Einzeichnen der Position abhängig vom gesetzten Fixpunkt
  • Unterstützung für Drag’n’Drop und Copy&Paste einzelner Elemente, Gruppen von Elementen und des ganzen Screens mit und ohne eingezeichneter Positionierung.
  • Freie Verschiebung des Fixpunktes zur Bestimmung der Position eines Elements

Der dritte Bereich unterteilt sich in einen Info-Bereich und die Outline. Im Info-Bereich werden die Eigenschaften des aktuell selektierten Elements angezeigt. Folgende Funktionen sollen unterstützt werden.

  • Gruppierung der Eigenschaften nach: Position und Größe, Schrift, Rahmen, Hintergrund sowie Padding
  • Darstellung der Eigenschaften als Einzelwerte
  • Zusammenfassung der Werte einer Gruppe zu einer Kurzfassung
  • Unterstützung für Drag’n’Drop und Copy&Paste von Einzelwerten sowie der Kurzfassungen

Die Outline stellt die Struktur und den Aufbau des Screens aus den unterschiedlichen Element dar. Folgende Funktionen sollen in der Outline unterstützt werden.

  • Abbildung des Screen-Aufbaus in einer Baumstruktur
  • Selektieren und Deselektieren eines Elements

Aktuell befindet sich das Tool in der Umsetzungsphase und wir hoffen bald eine erste Version präsentieren zu können. Als Plattform haben wir uns für JavaFX entschieden. So basiert das Justinmind SDK auf Java wodurch dieses einfach in das Tool integriert werden kann. Weiterhin bietet JavaFX Vorteile beim Erstellen des UIs durch bessere Tools wie den SceneBuilder gegenüber Swing zumal JavaFX der offizielle Nachfolger von Swing werden soll. Darüber hinaus ist seit Java 8 die JavaFX-Laufzeitumgebung  in der Java Runtime Environment direkt enthalten, wodurch auch schon jetzt auf vielen System JavaFX-Anwendungen direkt ausgeführt werden können. Zum Abschluss noch ein Screenshot vom aktuellen Stand. Im Hintergrund ist ein Screen eines Prototypen innerhalb Justinmind zu sehen und dieser Screen wird im StyleExplorer angezeigt.

StyleExplorer-LiveDemo

 

Über das Eurostars Forschungsprojekt „Advanced Prototyping Platform“:

Die SIC! Software GmbH ist Projektpartner des Eurostars Projekts „Advanced Prototyping Platform“ (APP). Das Ziel des Projekts ist das Entwerfen, Prototypen und Simulieren komplexer Softwareanwendungen zu vereinfachen sowie den Prozess von der Anforderungsanalyse über die Konzeptionsphase bis zur Implementierungsphase zu optimieren.

Dazu sollen auf Basis der bekannten Prototyping-Umgebung Justinmind und dem zugehörigen Justinmind SDK verschiedene Plug-Ins und Softwaretools entwickelt werden. Als weitere europäische Projektpartner arbeiten wir mit den Prototype Experten Justinmind aus Barcelona, den AI Experten Taiger aus Madrid und den OpenData-Spezialisten OpenDataSoft aus Paris zusammen.

Webseite zum APP-Projekt: http://taiger.com/APP/

advanced_prototyping_platfrom_logo eurostars_logo

UI – Testen und Debuggen mit Xcode 6

Wenn man die Benutzeroberfläche einer iOS App mit dem Storyboard aufbaut, ist man spätestens mit iOS 8 bestens beraten, das Layout möglichst unabhängig von einer bestimmten Geräteauflösung zu halten. Bei neu erstellen Xcode 6 Projekten sind die ViewController im Soryboard sogar quadratisch, damit klar ist, dass es sich um kein bestimmtes Gerät handelt.

Die Preview-Ansicht

Um zu testen, ob sich das Layout auf unterschiedlichen Geräten und in unterschiedlichen Orientierungen korrekt verhält, gibt es eine Preview-Ansicht.
Man schaltet zunächst auf den Assistant editor um. Auf der linken Seite wählt man einen ViewController aus und auf dere rechten Seite wählt man in der oberen Leiste „Preview“ aus.
In der unteren linken Ecke kann man mit „+“ weitere Geräte hinzufügen, die man gleichzeitig nebeneinander sehen möchte. Die Geräte können danach noch gedreht werden, um auch die unterschiedlichen Orientierungen zu testen.

Preview-Ansicht

Die Preview-Ansicht beachtet natürlich auch die gesetzten Layout-Constraints.
Unten rechts kann man die Sprache umstellen und eine „Double-Length Pseudolanguage“ auswählen. Diese Pseudosprache verdoppelt die Länge aller Texte und ist sehr praktisch um zu testen wie sich Zeilenumbrüche oder sehr lange Texte auf das Layout auswirken.

Die App sollte man natürlich trotzdem mindestens ein Mal auf einem Gerät oder zumindest auf dem Simulator testen, um zu sehen wie sich das Interface mit echten Daten verhält. Man darf sich auch nicht komplett auf die Preview-Ansicht verlassen. Je nach Komplexität des ViewControllers und der Layout Constraints kann das Resultat in der App anders aussehen als in der Preview Ansicht.
Aber die Preview-Ansicht ist sehr praktisch um schnell zu prüfen ob das Resultat in groben Zügen den eigenen Vorstellungen enspricht.

Die 3D Debug-Ansicht

Wenn das Layout in der laufenden App nicht so aussieht wie erwartet, ist die 3D Debug-Ansicht ziemlich hilfreich. Um in diese Ansicht zu gelangen, klickt man während einer Debug-Session auf den „Debug View Hierarchy“-Button:

Debug View Hierarchy

Die App wird pausiert und es öffnet sich eine Ansicht, in der man die View-Hierarchie betrachten kann. Hier hat man zum Beispiel die Möglichkeit den Blickwinkel zu ändern und uninteressante Ebenen auszublenden. Wenn man auf eine View klickt, werden im Utilities-Bereich (rechts) einige Werte zu der View angezeigt. So kann man zum Beispiel in Erfahrung bringen, welche Schriftart oder Textfarbe gerade gesetzt ist:

debug2

Hilfreich ist hier vor allem, dass man sehen kann wie viele und welche Views übereinander liegen und dass man Views debuggen kann, die von anderen Views verdeckt werden.
Oft sieht man auch, dass einige Views (in diesem Fall die tableView) über den Bildschirmrand hinausgehen. Damit lassen sich einige rätselhafte Phänomene erklären.

Fazit

Die beiden Ansichten können beim Testen und Debuggen viel Zeit sparen. Denn man muss nicht viele Änderungen am Code durchführen, Log-Ausgaben machen, bauen und die App erneut ausführen.

Usability und User Experience – Warum eine Unternehmens-Software auch attraktiv sein muss

In Frankfurt fanden am 13. und 14. Mai 2014 die neunten M-Days statt. Auf der Fachmesse für mobile Business versammelten sich Anwender, Entwickler, Anbieter sowie Experten zum wissenschaftlichen und praxisnahen Austausch zu ihren Fachgebieten.

Marie, UX-Designerin bei SIC! Software hielt einen Vortrag zum Thema User Experience bei Unternehmenssoftware. Häufig gestellte Fragen zu Usability und User Experience beantwortet Marie noch einmal in unserem Blog für alle, die diesen spannenden Vortrag nicht auf den M-Days verfolgen konnten.

Ist User Experience nicht nur ein Synonym für Usability?
Nein, Usability und User Experience beschreiben zwei unterschiedliche Dinge und verfolgen jeweils andere Zielsetzungen. User Experience (kurz UX) bedeutet Nutzungserlebnis und erweitert den bisherigen Usability-Begriff um das Erleben und die Emotionen bei der Benutzung eines Produktes. Usability beschäftigt sich vornehmlich damit, negative Nutzererlebnisse zu vermeiden. User Experience hingegen hat zum Ziel, ein möglichst positives Nutzungserlebnis zu schaffen.

Reicht Usability allein nicht aus?
Usability ist heutzutage als Hygienefaktor bei Software zu sehen. Eine einfache Bedienung und die Möglichkeit schnell an das Ziel zu kommen wird als selbstverständlich angesehen. Die Anwender sind aus ihrem privaten Umfeld gewohnt, dass Software attraktiv gestaltet ist. Wenn die Usability einer Anwendung unzureichend ist, so führt dies automatisch zu Unzufriedenheit. Um Begeisterung für die Anwendung zu erzeugen, reicht gute Usability allein nicht aus.

Warum ist das für Unternehmenssoftware wichtig? Die Mitarbeiter können sich schließlich nicht die Software aussuchen.
Wenn die Software gerne benutzt wird, so steigt die Akzeptanz der Software. Es ist so leichter, diese in der Praxis einzuführen, da es weniger Widerstände aus der Belegschaft gibt. Außerdem ist eine gute User Experience auch den Unternehmenszielen dienlich. Empirische Studien haben gezeigt, dass zufriedene Mitarbeiter besser und produktiver arbeiten.

Können sich das nicht nur große Konzerne leisten?
Gute User Experience muss nicht unbedingt teuer sein. Wichtig ist hier eine Veränderung des Blickwinkels mit dem Software entwickelt wird. Nicht die Technologie steht beim Design im Mittelpunkt, sondern der Anwender der Software.
Momentan arbeiten wir im Projekt Design4Xperience daran UX-Methoden zu entwickeln, die auch für kleine und mittelständische Unternehmen geeignet sind.

Was hat es mit dem Projekt Design4Xperience auf sich?
Das Projekt Design4Xperience ist Teil der Förderinitiative „Einfach intuitiv

– Usability für den Mittelstand“

, die im Rahmen des Förderschwerpunkts „Mittelstand-Digital – IKT-Anwendungen in der Wirtschaft“ vom Bundesministerium für Wirtschaft und Energie (BMWi) gefördert wird.

Ziel des Projekts Design4Xperience ist die Entwicklung von Methoden und Instrumenten, mit denen kleine und mittlere Unternehmen die User Experience ihrer Software verbessern können.