Entwicklung: Layout, Wireframe oder Click-Dummy?
Fundstück im Assembla Blog: Gibt es eine zwingende Reihenfolge von Schritten bei der Entwicklung einer Web-Software? Da auch Business Intelligence Anwendungen immer über Browser aufgerufen werden, ist das interessant. Frage also: Welche Arbeitstechniken helfen dabei das Projekt schneller und besser fertig zu stellen?
Bei der Entwicklung von Software können verschiedene Entwicklungstechniken helfen, das Endprodukte des Projekts Schritt für Schritt immer genauer zu definieren. Doch welches Vorgehen ist das Beste? Muss man eine genaue Reihenfolge einhalten? Gibt es eine "beste" und eine "schlechteste" Technik bei der Entwicklung?
Da auch Business Intelligence Anwendungen immer öfter über ein Frontend im Web zugänglich gemacht werden, sind diese Fragen auch für unseren Bereich relevant. Zumal die frühzeitige Visualisierung des späteren Endprodukts dabei hilft, Fehlentwicklungen oder auch Überfrachtung mit Funktionen zu verhindern.
Beispiele:
Skizze: Einfachste Form der Visualisierung, kann zur Not auch auf einem Stück Papier aufgemalt werden. Gut für frühe Stadien oder Hauptziele, bald danach aber zu ungenau.
Storybord: Eine Übersicht, in der alle einzelnen Screens einer Software dargestellt sind. Linien symbolisieren die Verbindungen, z.B. für den Bereich "Einstellungen" oder unterschiedliche Ansichten.
Wireframe: Ein "Drahtgittermodell" (das wäre die wortwörtliche Übersetzung) der Software-Screens. Farben und Design bleiben außen vor, hier geht es nur um eine einigermaßen komplette Sicht aller einzelnen Screens und der dort gebotenen Funktionalitäten. Die Funktionalitäten tatsächlich alle abzubilden macht richtig Arbeit. Die meisten Wireframes bleiben auf den ersten beiden Ebenen hängen. Da das relativ normal ist, sollte man unter Umständen mehrfache Runden mit Wireframes drehen, um so Schritt für Schritt ein immer klareres Bild der Gesamtanwendung zu bekommen.
Graphisches Modell: Optisch deutlich ansprechender, mit Logos, Farben und einer Anmutung späterere Menüs. Meist mit Photoshop oder ähnlichem Programm erstellt. Problem ist hier, dass es wenige Grafiker gibt, die sich Software so gut vorstellen können, dass diese Entwicklung reibungslos verläuft. Meist braucht es mindestens eine Skizze oder auch Wireframes, um mit dieser Technik zu einem guten Ergebnis zu kommen. Anmerkung: "Wenige Grafiker" ist ein Erfahrungswert, es gibt aber natürlich auch viele erfahrene Doppelbegabungen, die so etwas in kürzester Zeit erledigen. Solche Leute muss man allerdings suchen.
HTML-Dummy/Click-Dummy: Im englischen auch "mock-up" genannt - ein Mix aus Visualisierung und Funktionen. Hier können erste Layouts mit Wireframes zusammengeführt werden. Die Anzeige erfolgt im Browser, die einzelnen Screens erlauben Clicks auf Menüpunkte. Dieses Verfahren dient dazu, die Usability bereits in frühen Stadien zu prüfen. Meist gibt es keine Verbindung zum Datenbestand, die Anzeigen werden einfach als statische Bilder eingefügt. Kann für Entwickler und auch Kunden sehr hilfreich sein. Gehört aber in spätere Entwicklungsphasen, es sei denn man variiert ein bereits erfolgreich laufendes Projekt oder Anwendungsszenario.
Prototype:Erste Version einer Software, bei der Code und Screens bereits teilweise wie beim Endprodukt funktionieren. Manche Module können noch ausgeklammert werden.
Die Frage von oben ist jedoch immer noch offen: Gibt es so etwas wie eine optimale Reihenfolge für den Einsatz solcher Arbeits- und Entwicklungstechniken?
Beim Assembla Blog steht die Antwort:
The answer is: there is no right sequence for designing a Web app. You can do design and programming , programming and design, in almost any order, and productivity seems to be about the same. Along the way, you have to figure things out about your application.
Mal funktioniert mal das eine, mal das andere Verfahren gut. Ob man also erst mit Pflichtenheft und Scribble anfängt und später mit Wireframes anfängt - oder aber die Visualisierung in "schönem" Design auf Basis des Pflichtenhefts vorantreibt - das hängt so stark vom konkreten Projekt und den Erwartungen ab, dass es eine feste Abfolge nicht gibt.
Wesentlich ist: Die Visibilität des Fortschritts muss erhalten bleiben. Wenn also ein Team oder eine Organisation mit den eher abstrakten Wireframes ein Problem hat, dann mag hier ein anderes Verfahren rascher zum Projektende führen.
Und alle Entwicklungs- und Visualisierungsverfahren sind besser als gar keine.
Link zur Quelle: Assembla Blog | What's the right sequence of events for designing a Web app?