640x480.de

Beiträge aus dem Was-mit-Medien-Alltag

Wie geht agiles Entwerfen?

Es ist in letzter Zeit viel die Rede von agilem Arbeiten, interaktivem Entwerfen, iterativen Prozessen – doch wie muss man sich das vorstellen? Wir zeigen an einem aktuellen Projektbeispiel die Entwicklung einer Zeitstrahl-Grafik von der Vorlage bis zur fertigen Drucksache.

Wir betrachten eine der Grafiken in der Broschüre „Studieren in Thüringen“ im Rahmen der Kampagne „Entdecke Dein Studium“ des Netzwerks Hochschulmarketing. Wie bei dieser einzelnen Grafik erfolgte der gesamte Gestaltungsprozess in diesem Projekt iterativ, also: Entwurf > Diskussion > Anpassung Inhalte Broschüre und Zeitstrahl > Entwurf > Diskussion – Anpassung Inhalte Broschüre und Zeitstrahl > Gestaltung …, – immer unter Verwendung echter Inhalte, immer im Kontext der Gesamtpublikation und immer im Abgleich mit anderen, parallel bearbeiteten Projekten dieser Kampagne (Website, Anzeigen).

So wie das im agilen Entwicklungsprozess im Webdesign anzustreben ist, steht also am Ende jedes Entwicklungsschrittes quasi ein publikationsfähiges Ergebnis.

Vorlage „Von der Schule an die Hochschule“
Vorlage „Von der Schule an die Hochschule“

Ausgangspunkt war der Wunsch, die Tabelle „Von der Schule an die Hochschule“ aus einer früheren Broschüre in eine zeitgemäße grafische Form zu überführen – Arbeitstitel „Zeitstrahl“.

Entwurfsvariante Zeitstrahl-Grafik für Campus Thüringen
Entwurfsvariante Zeitstrahl-Grafik für Campus Thüringen

Ein erster Entwurf stellte auf Basis der „alten“ Tabelleninhalte eine mögliche grafische Umsetzung vor.

Aktualisierte Inhalte für Broschüre 2014 als tabellarische Zuarbeit
Aktualisierte Inhalte für Broschüre 2014 als tabellarische Zuarbeit

Die Richtung kam an. Nun brachte der Auftraggeber die Inhalte auf den (jetzt gerade) aktuellen Stand, den (jetzt gerade) aktuellen Gliederungspunkten der Broschüre zugeordnet, das Ganze als Tabelle aufbereitet.

Es folgten weitere Entwurfsstufen:

Entwurfsvariante Zeitstrahl-Grafik für Campus Thüringen
Entwurfsvariante Zeitstrahl-Grafik für Campus Thüringen
Entwurfsvariante Zeitstrahl-Grafik für Campus Thüringen
Entwurfsvariante Zeitstrahl-Grafik für Campus Thüringen
Entwurfsvariante Zeitstrahl-Grafik für Campus Thüringen
Entwurfsvariante Zeitstrahl-Grafik für Campus Thüringen
Entwurfsvariante Zeitstrahl-Grafik für Campus Thüringen
Entwurfsvariante Zeitstrahl-Grafik für Campus Thüringen

Die Entwürfe wurden einerseits durch die fortschreitende Ausarbeitung und Veränderung der Inhalte (die Gliederung musste im Laufe der Arbeit mehrfach leicht angepasst werden, Kapitel wurden zusammengefasst oder neue ergänzt werden), andererseits durch die Definition und Vereinheitlichung der grafischen Sprache bestimmt. Der Styleguide für dieses Projekt entwickelte sich kontinuierlich während der Arbeit an den Einzelprodukten – im Gegensatz zu einer Vorab-Definition eines Corporate Designs.

Zeitstrahl-Grafik in der fertigen Broschüre
Zeitstrahl-Grafik in der fertigen Broschüre

Am Ende steht ein Ergebnis, das sich relativ stark vom ersten Entwurf unterscheidet. Die einzelnen Zwischenschritte zeigen, dass der Prozess vor allem in der Reduktion der Elemente, im Aufräumen, bestand, so dass die Anzahl von Farben, Linienstilen und Schriftvarianten – aber auch die Anzahl der Informationen in der finalen Version am geringsten ist.

Als zusätzliches Produkt wurde der Zeitstrahl in einer SVG-Variante (hier viel zu klein eingebunden – besser im Original auf campus-thueringen.de/studienwahl/) für die Website adaptiert. Auch hier gab es mehrere Überarbeitungsschleifen bis zum Ergebnis.

Fazit: Ein agiler Entwurfsprozess ist dann sinnvoll, wenn die Aufgabenstellung offen, aber das Ziel klar ist.
Es gab hier keine konkreten Designvorgaben und keine „festen“ Inhalte. Aber es gab das Ziel, die To-Do’s der Studienvorbereitung grafisch abzubilden. 

Diese Art des Arbeitens funktioniert nicht immer und nicht mit jedem. Der Auftraggeber muss genügend Fantasie aufbringen, um auch in unausgereiften Skizzen das Potenzial zu erkennen und darf das Vetrauen in seinen Designer nicht verlieren. Der Gestalter muss konstruktive Kritik als Chance sehen, das Projekt noch besser zu machen – auch, wenn seine Lieblingsidee gerade rausgekickt wurde… nicht immer leicht. Aber am Ende sind alle froh :)

22.08.2014 | 2 Kommentare

Websites als Gemeinschaften

Eine Website zu betreiben, heißt eine soziale Gemeinschaft zu bilden und zu pflegen.

Egal ob Verein, Berufsverband, Schraubenhersteller, Verlag, Schule oder privater Blog - die Zeiten sind lange vorbei, in denen sich ein Sender an eine Zielgruppe gewendet hat. Im Web 2.0 wollen alle etwas voneinander.

Der Verein (also die Mitglieder, die aktiv sind) gibt Informationen an die Mitglieder und wünscht sich dafür Beteiligung. Ein Hersteller veröffentlicht Produktinformationen auf der Suche nach Käufern oder Rückmeldung in Form von Bewertungen, Likes oder Empfehlungen. Ein Verlag ist Mittler zwischen Autoren und Lesern.

Das hört sich im ersten Moment vielleicht etwas banal an. Tatsächlich – in meiner Webentwickler-Realität – werden Websites als technische Konstrukte wahrgenommen – als eine Ansammlung von Funktionalität – und nicht als soziale Gebilde. Das ist ein Problem. Als Dienstleister merken wir das bei Ausschreibungen und in der langfristigen Betreuung.

Ausschreibungen lesen sich wie der Weihnachtswunschzettel meiner Kinder. Sie sind Ansammlungen von konkreten Produktwünschen, gerne mit Stückzahl und Bestellnummer:

  • „Wir brauchen eine Typo3-Website …“,
  • „Ich will eine Lightbox …“,
  • „Da muss ein Karussell rein …“,
  • „Wir wollen einen Blog …“.

Selten bis nie liest man inhaltliche Wünsche nach dem Motto:

  • Wir möchten regelmäßig über neue Produkte informieren und dazu die Meinung unserer Kunden hören.
  • Wir möchten Lehrern, Schülern und Eltern eine geschlossene Plattform zum Austausch von Erfahrungen geben.
  • Unsere Mitgliedern möchten Ihre Erlebnisse bei Vereinsaktivitäten austauschen.
  • Wir möchten, dass unsere zufriedenen Kunden unsere Produkte weiterempfehlen.

Aus solchen Wünschen lassen sich konkrete Aufgabenstellungen ableiten. Wer ist „Wir“? Um welche Informationen geht es? Wie oft und wie viele? Wer erstellt die Inhalte? Wer liest die Antworten? Und so weiter. Daraus ergeben sich dann Anforderungen, welche Technik zum Einsatz kommen kann, ob die eigene Website der richtige Platz ist oder vielleicht ein offenes Forum oder ein soziales Netz?

Wenn Websites scheitern, ist das oft keine Frage der Technik, sondern eine Frage falscher Erwartungen oder Ausgangsbedingungen. Wie oft haben wir schon Foren installiert, weil ein Verband offensichtlich vorhandene Probleme zur Diskussion bringen wollte. Wie oft haben wir diese Foren nach einer Weile wieder abgeschaltet, weil nach zehn Wortmeldungen die Aktivität einschlief. Das ist – in erster Linie – keine Frage von gutem Forum oder schlechtem Forum, von Benutzbarkeit oder nicht (einige der aktivsten Foren, die ich kenne sind grottenhässlich und fast unbedienbar). Es ist eine Frage von Ansprache, davon dass die Initiatoren selbst diskutieren, dass auf Fragen geantwortet wird (zeitnah!), dass aus Diskussionen im Forum echte Aktivitäten in Gremien und daraus echte Entscheidungen werden.

Blogs scheitern nicht, weil sie nicht in Wordpress programmiert sind. Blogs scheitern, weil einen Blog installiert zu haben nicht heißt, dass man fertig ist. Es geht um erkennbare Autorschaft, um nützliche Inhalte, um Stetigkeit.

Online-Shops scheitern nicht, weil die Software doof ist. Sie scheitern, weil das Umfeld nicht stimmt, weil es vielleicht kein Verkaufskonzept gibt? Weil keiner die Produkte pflegt und das Schaufenster täglich liebevoll bestückt? Weil die Tatsache, dass man einen Online-Shop installiert hat, nicht heißt, dass die Käufer plötzlich Schlange stehen.

Wenn die Entwicklung einer Website nicht als technische sondern als soziale Frage betrachtet wird, dann besteht auf lange Sicht auch Aussicht auf Erfolg. Dann kommt auch nicht als erste Reaktion auf die Reaktion des Dienstleisters auf den „Wunschszettel“: „Oh – so teuer?“. Denn dann ist selbstverständlich, dass die technischen Fragen – also die Herstellung der technischen und formalen Infrastruktur – nur einen Bruchteil in der Gesamtaufgabe ausmachen. Und mit Sicherheit werden viele der technischen Wünsche nicht sofort gebraucht. Und müssen auch nicht alle Kosten sofort entstehen.

Ich wünsche mir mehr Auftraggeber die erkennen, dass die größten Arbeitsanteile vor und nach der Websiteproduktion liegen.

24.06.2014 | 1 Kommentar

Webdienstag #8

Unser Webmontag – jeden zweiten Dienstag im Monat – am 11.06.2013. Dieses Mal mit einem lange angekündigten und aufgeschobenen Thema: der Werkstattpräsentation unseres CMS Akira.

Präsentationen sind ein super Katalysator. So haben wir quasi bis zur letzten Minute gearbeitet, um pünktlich zum Webstammtisch die neue Website www.akira-cms.de online zu bekommen.

Startseite der Akira-CMS-Website
Startseite der Akira-CMS-Website

Der Präsentation selbst sahen wir mit sehr gemischten Gefühlen entgegen. Akira entwickeln wir seit 2007. Für uns ist Akira das Werkzeug, mit dem wir effizient Websites prototypen und produzieren. Für unsere Auftraggeber ist Akira das Werkzeug mit dem sie ihre Inhalte verwalten und präsentieren können.

Unser CMS vorzustellen - vor Entwicklerkollegen und dem Hintergrund eines riesigen Marktes mit den Platzhirschen Typo3, Wordpress, Drupal, sowie unzähligen Agentur-Eigenentwicklungen hieß für uns auch, die Weiterentwicklung zu hinterfragen.

Dieser Blogbeitrag im Editor von Akira.
Dieser Blogbeitrag im Editor von Akira.

Um so mehr hat uns das positive Echo gefreut. So sahen wir uns bei grundlegenden Konzeptentscheidungen zur Systemarchitektur, bestimmten Funktionalitäten und sogar beim User Interface freundlich bestätigt.

Neu dabei waren dieses Mal Tobias Hofmann und Matthias Breuer. Der eine oder andere Link wurde angesprochen – ich habe diesmal nicht mitgeschrieben – bitte in die Kommentare damit. Wir werden beim Thema Content Management bleiben und uns zum nächsten Treffen der „Konkurrenz“ widmen.

12.06.2013 | 2 Kommentare

Welcher Editor darf’s denn sein?

Im Zweifelsfall jede Woche ein anderer wäre eine bei uns passende Antwort. Der aktuelle Wechsel zu Sublime Text dient mir als Anlass, die in der letzten Zeit genutzten Editoren mal Revue passieren zu lassen und da kommen einige zusammen:

Welcher Editor darf’s denn sein?
Welcher Editor darf’s denn sein?

(in alphabetischer Reihenfolge)

AptanaStudio3

http://www.aptana.com/products/studio3

Das war eine Empfehlung aus einem unserer Stammtische. Wenn man viele Fenster, Menüs, Optionen und Erweiterungsmöglichkeiten mag ist man hier sicher gibt bedient, für uns war das aber nix.

Coda

http://panic.com/coda/

Wurde mal angeschafft, weil wir aus gleichem Hause Transmit als FTP-Programm nutzen und uns davon wohl eine einheitliche Bedienung versprochen haben. Wie auch immer, das Programm ist eher ein Spielzeug und sieht auch so aus.

jEdit

http://www.jedit.org/

Auf Empfehlung von Marko und wegen der Suche nach einem Editor, den wir alle einheitlich nehmen können. War aber wegen der Java-Umgebung und des damit verbundenen anderen User Interfaces nicht unsere erste Wahl. Pluspunkt war das Code folding, gerade in größeren Projekten absolut hilfreich für die Übersicht im Quelltext.

SubEthaEdit

http://www.codingmonkeys.de/subethaedit/

Wegen des Versprechens der gemeinsamen Arbeit an Dokumenten, was wir zwar mal ausprobiert aber in der Realität nie wirklich ausgenutzt haben. Ansonsten ein lange Zeit genutzter, sehr angenehmer Editor.

Sublime Text 2

http://www.sublimetext.com/

Unser Neuzugang unter den Editoren nach einer Empfehlung von Harry Keller während der Typo Berlin. Ist plattformübergreifend zu haben, weswegen auch von Marko einsetzbar und mit vielen hilfreichen Features. Erster konkreter Super-Vorteil war die Installation des Less-Build-Pakets womit man direkt .css-Dateien aus seinen .less-Dateien rendern kann. (vorher mit Crunch unter Adobe Air - http://crunchapp.net/)

TextWrangler

http://www.barebones.com/products/textwrangler/

Aus dem Hause BareBones (remember BBEdit), der wohl am längsten benutzte Texteditor bei uns bisher. Gerne und viel genutzt die Suchen-Funktion über ganze Verzeichnisse.

Welchen Editor nutzt ihr und wie oft wechselt ihr die Werkzeuge? Seid ihr einem bestimmten Editor auf Jahre treu oder seid ihr – wie wir – ständig auf der Suche nach einem noch besseren Tool?

22.05.2013 | 2 Kommentare

Neuer Beruf: „System-Sekretär/in“ oder „Secret Administrator“

Was kleinen Unternehmen und Freiberuflern echt weiterhelfen würde, wäre jemand, der sich liebevoll und sachkundig um IT & Co kümmert, Office-Software bedienen kann (und weiß, dass man damit mehr machen kann, als mit einer Schreibmaschine), in der Lage ist, Telefonate freundlich entgegenzunehmen, Rechtschreibung nicht als notwendiges Übel betrachtet, ein wenig Ahnung von Buchhaltung hat … und überhaupt alles ein bisschen zusammenhält – die Kombination aus Sytemadministrator/in und Sekretär/in eben. Das wär’s.

12.02.2013 | Noch keine Kommentare

MoSCoW-Meeting

Unsere kleines Entwicklerteam traf sich heute zur Priorisierung der Aufgaben zur Finalisierung von Akira2.

Priorisierung der Todo-Liste nach MoSCoW
Priorisierung der Todo-Liste nach MoSCoW • Foto: Martin Kohlhaas

Die Feature-Liste ist geschlossen, jetzt geht es ans Aufarbeiten der letzten Problemstellen, Kontrolle und Doku. Bei der Sortierung der Aufgaben sind wir nach der MoSCoW-Priorisierung vorgegangen.

15.01.2013 | Noch keine Kommentare