Kategorie-Archiv: Stadgeschichten

Persönlich: Gruppenwechsel

Nach dem ersten „Speeddating“ und der Datenvorstellung hatte ich mich, um in den Metaphern des Kurses zu bleiben, mit der der Gruppe Stadtgeschichten „verlobt“. Das war meinem Interesse an Stadtpolitik, als auch den Gruppenmitgliedern geschuldet,  die ich seit meinem ersten Informatik Semester kenne.

Die Gruppe hatte sich relativ schnell entschieden ein Objekt zu entwerfen, welches von Person zu Person weitergereicht werden und Geschichten sammeln sollte. Ein spannendes Projekt, das aber erstmal die Entwicklung einer Android App bedeuten würde. Eigentlich sehr interessant, aber ich hatte das Softwareprojekt neben vielen anderen Gründen gewählt, da ich mich mit neueren Webtechnologien wie AngularJS auseinandersetzen wollte.

Das allein wäre aber kein Grund gewesen die Gruppe zu verlassen, da ich ihre Dynamik sehr positiv empfand. Das lag wahrscheinlich auch an der freundschaftlichen Zusammensetzung.

Allerdings hatte ich bedenken mit Freunden zusammenzuarbeiten, da ich zwar weiß wie gut man in solchen Konstellationen Brainstormen kann, aber auch die Konflikte kenne, wenn Aufgabenverteilungen nicht funktionieren und sich Kritik an der Arbeit mit freundschaftlicher Sympathie vermischt.

Ausschlaggebend für meinen Wechsel, war jedoch der Hilferuf der Mustergruppe, die auf einmal nur noch zu zweit waren und ohne weitere Unterstützung das Projekt hätten abbrechen müssen.

Das Musterkonzept entsprach ziemlich genau meinen Erwartungen an das Softwareprojekt. Das Ziel war es eine moderne Webapplikation zu entwickeln, die der besseren Darstellung und Weiterverwendung der von der HTW zur Verfügung gestellten Stoffmuster dienen sollte. Also perfekt dafür geeignet endlich mal ein konkretes Projekt mit Django, AngularJS und co. umzusetzen.

Dazu kam noch ein ansprechendes Layout des Designers und die Herausforderung der Zusammenarbeit mit einem unbekannten Team.

Trotz des schon fortgeschrittenen Projektverlaufs und des schon weitgehend feststehenden Konzeptes entschied ich mich daher nach einem sehr kurzen Kennenlernen und in Absprache mit meiner alten Gruppe zu einem Wechsel.

Neben Expertise und Motivation brachte ich auch einen Schwung technischer Ideen mit: Wie oben schon erwähnt sollten Django und AngularJS die Grundlage der Applikation bilden und mit Bootstrap schnell ein Designprototyp erstellt werden.
Das weder der Designer noch der zweite Entwickler bislang Erfahrungen mit Webentwicklung hatten, übersah ich in den ersten Planungen jedoch leider.

Großstadtziegel Website Rework

Die bisher quasi rohe Rails-Resourcenbasierte Webseite für die Anzeige der hochgeladenen Geschichten hab ich einmal komplett überarbeitet. Die bearbeiteten Punkte sind im Überblick:

  • Einbettung der Audiowiedergabe
  • Less-Styling eingerichtet
  • Struktur/Navigation erstellt
  • Bootstrap eingebunden
  • Farben/Fonts/Styles eingestellt
  • Optimierung der mobilen Ansicht

Zur Einbettung der Audiodateien in die Webseite werde ich noch einen gesonderten Blogpost machen, da mich das einiges an Nerven gekostet hat und imo genug Stoff für einen Post bietet. Dabei hat besonders die serverseitige Konvertierung der Aufnahmen erhebliche Probleme bereitet.

Um in Rails Less in Kombination mit der Asset Pipeline nutzen zu können, verwendet man am besten das less-rails gem welches sich gut mit dem  bereits im Projekt eingebundenen twitter-bootstrap-rails gem ergänzt. Das funktioniert eigentlich out-of-the-box, man sollte allerdings darauf achten, etwaige konkurrierende gems zu entfernen (beim Generieren des Projekts mit dem rails-Generator wurde bereits ein Sass-gem installiert). Die Asset Pipeline sorgt u.A. dafür, dass alle Assets (Stylesheets, Javascripts…) im Produktionsmodus gebündelt und mit einem Fingerprint versehen werden.

Als nächstes habe ich die Navigation der Seite erstellt. Dabei greife ich auf eine einfache Bootstrap-Navbar zurück. Nach dem Erstellen einer Datei für das Navigationspartial, der richtigen Dokumentstruktur (wie die meisten Bootstrap-Elemente ist auch die Standard-Navbar ganz gut verschachtelt und mit Klassen gespickt), dem Header für die Navbar, den entsprechenden Links mit dem Rails ActionView-Helpertag `link_to` (welches auch mit der Asset-Pipeline zusammenarbeitet) und den Routendefinitionen in der config/routes.rb für die Einträge der Navigation steht die Navigationsleiste auch schon.

Beim Besuchen der Webseite fällt sofort die (hervorstechende) Farbwahl auf. Die Farben stammen dabei aus dem Logo der Großstadtgeschichten-Seite der ZLB und sind nicht als endgültig anzusehen. Der Großteil des Stylings der einzelnen Elemente der Webseite (beispielsweise die Musik-Box auf der Startseite) sind von Hand geschrieben worden. Textspezifische Stylings kommen aus einem sehr empfehlenswerten OpenSans-Styling-Generator, welcher für Standardelemente ziemlich hübsche Styles ausspuckt (was nicht zuletzt an der tollen OpenSans liegt).

Zuletzt noch was zur mobilen Ansicht: Da man der Ziegel ein mobiles Gadget ist und vermutlich unterwegs benutzt wird, klang es erstrebenswert, den Benutzern die Möglichkeit zu bieten, den Token (zur Bearbeitung einer soeben getätigten Aufnahme) direkt auf dem Smartphone eingeben zu können. Mithilfe von Bootstrap (Danke Twitter!) ließ sich das recht stressfrei umsetzen, sodass man jetzt nicht nur die die Tokeneingabe, sondern die komplette Webseite gut mit dem Smartphone besurfen kann. Das einzige, was noch nicht funktioniert, sind die eingebetteten HTML5-Audios.

Der Großteil der Inhalte der Webseite besteht derzeit noch aus Blindtext, wird aber demnächst noch durch echte Inhalte ausgetauscht.

Zum Abschluss eine Gegenüberstellung der alten und der neuen Webseite:

Stadtgeschichten: Stories Index
(ih, bäh!)

Screen Shot 2015-06-29 at 17.48.04
(naja, immerhin bunt und strukturiert…im Hintergrund mein neuer Lieblingseditor Atom)

Die aktuelle Version dieser Webseite ist zur Zeit unter http://kaesim.cepheus.uberspace.de:63190/ erreichbar.

Der GroßstadtZiegel lebt!

Die Record, Play und Upload Funktionalität waren ja schon ziemlich früh fertig. Jetzt musste das alles noch in die richtige Form gebracht werden.

Nachdem wir gemeinsam ein Statediagram erarbeitet hatten blieb noch, die Buttons und Activities zu erstellen und damit das Diagramm umzusetzen.

Zum Verständnis: Activities in Android kennt man in vielen anderen Frontenddesignern oder Webframeworks als Views. Das sind einzelne Bildschirme, die sich zwar in einzelnen Aspekten ändern können, nicht aber in ihrer Grundstruktur. Zum Vergleich: In einem einfachen Computerspiel könnte man ein Hauptmenü, den Spielbildschirm selbst und ein Pausemenü jeweils als eigene Views implementieren.

App_States

In unserem Fall haben wir 4 States und dementsprechend 4 Activities:

  • Hello, mit einem Button, der den Erklärungstext abspielt und anschließend zur Record Activity wechselt
  •  Record, mit zwei Buttons,
    – Hilfe geht zur Hello Activity zurück
    – Record startet die Aufnahme und wechselt danach zur Processing Activity
  •  Processing, mit drei Buttons,
    – Back, geht zur Record Activity zurück
    – Play/Stop spielt die aufgenommene Audiodatei ab
    – Send schickt die Datei an den Server und wechselt zur Token(TODO richtigen Namen finden)* Activity
  • Token zeigt  dem Nutzer ein Token an, über das er auf der Website seine Geschichte weiter bearbeiten kann

Die Activities selbst zu erstellen ist aufbauend auf der Testactivity relativ simpel. Einige Anpassungen sind nötig, da Julian inzwischen eine neue Button-Klasse geschrieben hat, die besser auf unsere Bedürfnisse zugeschnitten ist und die alten Buttons zu den neuen konvertiert werden müssen.

Einer der (wiedermal) umständlichsten Aspekte dabei sind die Animationen. Zur Vertiefung wird es noch einen separaten Blogpost geben, aber insbesondere sind die Schwierigkeiten, das Ende einer Animation abzuwarten, bevor zur nächsten Activity gewechselt wird, den flüssigen Übergang von einer Animation in die nächste zu gewährleisten und zu verhindern, dass der Speicher vollläuft, weil scheinbar die Garbage Collection für diese Art von Animation eher sparsam ist…

the AnimationDrawable and it’s (ha!) Drawbacks

Wir hatten uns entschieden, die Buttons mit Animationen als Hintergründe zu bestücken.

In Android gibt es zwei Möglichkeiten für Animationen:

Animation von Parametern und Frame-by-Frame Animation.

erstere ist insbesondere interessant für Übergangsanimationen und Verformung von Buttons, Fenstern, etc.

Wir wollten allerdings animierte Icons. Also brauchen wir Frame-by-Frame Animation.

Die ist in Android zwar möglich, aber die relevante Klasse, AnimationDrawable, ist sehr eingeschränkt.
Insbesondere sind wir auf zwei Probleme gestoßen: Der Speicher läuft extrem schnell voll und es gibt keinen OnAnimationFinished Callback.

Das Speicherproblem entsteht, da Android für jede Animation sämtliche Frames in den Speicher lädt und sie dann erstmal nicht wieder löscht, was zur Folge hat,
dass der der App zugewiesene Speicher schon nach 2 oder 3 Animationen voll ist und die App mit einem OutOfMemoryError abstürzt.
Es gibt mehrere Methoden, die Frames nach Benutzung zur GarbageCollection freizugeben, allerdings sind sie generell sehr umständlich und im Zweifelsfall fehleranfällig.
Die Lösung, die ich letztendlich gefunden habe ist sehr einfach und insbesondere für unsere Zwecke vollkommen ausreichend.

im Manifest der App lässt sich unter „application“ der Wert

android:largeHeap=“true“

setzen, der den verfügbaren Speicher der App erhöht. Seitdem gab es keine Probleme mehr mit OutOfMemoryErrors.

Der Callback war komplizierter. Da wir einige Exit Animationen haben, die vor einem Activitywechsel abgespielt werden, brauchten wir die Möglichkeit, auf das Ende einer Animation reagieren zu können, nämlich, indem wir den Activitywechsel einleiten.

Da AnimationDrawable diese Funktionalität nicht bietet, musste eine andere Möglichkeit gefunden werden.
Ich habe Julians BasicButton Klasse, die wir als Grundlage unserer Buttons verwenden erweitert, so dass die jeweiligen Funktionen triggerEntryAnimation, triggerExitAnimation und triggerIdleAnimation die Länge der Animation, also die Summe der Längen der einzelnen Frames, zurückgibt.

In den jeweiligen Buttons wird dann ein Runnable-Objekt erstellt, das den Activitywechsel auslöst und die letzte Activity ein wenig aufräumt.

Runnable startNext = new Runnable() {
@Override
public void run() {
context.startActivity(intent);
((AnimationDrawable)ExplainButton.super.getBackground()).stop();
ExplainButton.super.setBackground(null);
}
};

sowie ein Handler

Handler delayHandler = new Handler();

Direkt nach Start der Exit Animation wird deren Länge an den Handler übergeben und dieser startet wiederum zeitverzögert mit

int waitTime = ExplainButton.super.triggerExitAnimation();
delayHandler.postDelayed(startNext, waitTime);

Nachtrag: Strukturierung der Android App

Leider sind wir nicht rechtzeitig zum Schreiben gekommen, deshalb jetzt etwas verspätet ein Blogbeitrag aus der Wocheniteration vom 3.6. bis zum 10.6. zum Thema Androi App.

Der bisherige Status der Android App war eine einzelne Ansicht (Activity), in der alle technischen Funktionen wie Aufnahme, Abspielen und Hochladen über einfache mit Text beschriftete Buttons enthalten waren (siehe vorheriger Beitrag).

Ich und Kai trafen uns zum Programmieren und wir haben festgestellt, dass zu zweit vor einem Bildschirm sitzen durchaus einige Vorteile hat. Man entdeckt viel leichter Fehler und bleibt mehr bei der Sache bzw. verliert sich nicht so leicht in Details.

Als nächstes Stand es an, Animationen zu integrieren. Das gestaltetete sich als umständlicher als ursprünglich angenommen, letztendlich haben wir sie als Frame-Animations eingebunden, die etwas umständlich bzw. Java-typisch sehr verbose durch zusätzliche in XML geschriebene Sequenzfolgen definiert werden und wie auch die Animationsbilder selbst im res/drawable Ordner des Projekts untergebracht sind.

Diese Drawables lassen sich dann als BackgroundResource für einen View (in dem Falle für einen Button) setzen

Button btn = someButton;
btn.setBackgroundResource(entryState.getEntryAnimation());
AnimationDrawable anim = (AnimationDrawable) this.getBackground();
anim.stop(); // maybe unnecessary
anim.start();

und mit den Methoden start() und stop() lässt sich die Ausführung der Animationen kontrollieren.

Um Codedopplungen zu vermeiden wurde eine Klasse für alle Buttons, die einen togglebaren Status (wie die Buttons für die drei oben genannten Funktionen) besitzen erstellt, sodass für die Verwaltung des Status das Buttonobjekt selbst zuständig ist. Das ließ sich leicht durch die Erweiterung der Klasse Button bewerkstelligen, ihr wurde ein Boolean für den Status hinzugefügt, ein paar Getter/Setter Methoden und die Möglichkeit eine Referenz auf die zu verwendenden Animationen in dem Buttonobjekt selbst zu speichern.

Diese Klasse haben wir dann verwendet um (Platzhalter-) Animationen in den einzelnen Buttons zu platzieren.

Leider hab ichs nicht geschafft ein Video von den  Animationen aufzunehmen, daher nur ein Screenshot:

Großstadtziegel Animation Buttons

Teilweise habe ich auch alleine an der Strukturierung gearbeitet, habe dabei aber gemerkt, dass ich (v.a. bei Java) stark dazu neige Sachen zu überstrukturieren und Java echt nicht besonders gut zum Prototyping geeignet ist. Im Team Programmieren (Pair Programming)  ist eine gute Methode um dafür zu sorgen einen angemessene Menge  Struktur in eine Anwendung reinzubringen ohne es zu übertreiben 😉

Animiertes Menü für den Großstadt-ziegel

Allmählich nimmt der Ziegel Form an: unser Gadget zur Aufnahme der Großstadtgeschichten sieht aus wie ein gewöhnlicher Backsteinziegel. Ein Quader mit den Maßen 160x 90x 45. Auf der Oberseite drei runde Öffnungen mit 26mm Durchmesser, durch die die Bedienung des Touchdisplays eines Smartphones möglich wird. Das Menü ist minimalistisch. Die Funktionen „Anleitung“, „Aufnahme“ und „Senden“ sind nach Bedarf anwählbar.

IMG_0003

Ein Ziegelstein ist kalt, mineralisch, roh und einfach. Ein Smartphone hingegen warm, technoid, perfekt gearbeitet und hochkomplex. Der Gegenstand soll durch das Menü in seinen Eigenheiten nicht beeinträchtig werden. Es soll wohl aber dazu dienen, den potenziellen Geschichtenerzähler zum Mitmachen zu animieren und zu motivieren. Die Gestaltung darf also nicht zu bunt oder poppig erscheinen, sondern minimalistisch. Bewegte Bilder wecken Neugier- Icons, die als bewegte Lichtpunkte agieren und dann ihre Form annehmen, erzeugen ein Gefühl, etwas magisches, mystisches in den Händen zu halten. Eine Assoziation zu einem Smartphone wird durch maximalen Kontrast unterbunden- die Icons sind weiß auf schwarzem Grund.

In der vergangenen Woche habe ich mich erstmals mit der Herstellung des entgültigen Prototyps beschäftigt, sowie des animierten Menüs, während Julian und Kai sich der Programmierung des Menüs angenommen haben.

Der Korpus des Großstadt-Ziegels wird aus drei Teilen bestehen. Ein innerer Kern ist bereits mit Solid Works gemodelt und wird am kommenden Mittwoch gefräst. Er sieht eine Aufnahme für das Smartphone vor, sowie Ausschnitte für Knöpfe, Ladekabel und ggf. eine Anleitung in Papierform. Umgeben ist dieser Kern von zwei Schalenhälften, die aus einem Komposit von Ziegelbrösel und Epoxidharz gegossen werden. Für beide Teile wird jeweils eine zweiteilige Gussform mit Solid Works gemodelt und gefräst.

Um in der kommenden Woche das animierte Menü testen zu können, habe ich einen weiteren Papierprototypen hergestellt, passend für das Huawai Ascend, mit dem wir arbeiten.

Das Animieren des Menüs hat in der letzten Woche eine besondere Herausforderung dargestellt.

Prinzipiell ist es möglich, einzelne Jpgs mit Photoshop zu einem animierten Gif zusammenzufügen- dies habe ich bereits zur letzten Woche realisiert. Bis vor wenigen Tagen war allerdings noch nicht klar, ob die Grafikdatei bewegt sein muss, oder ob mehrere einzelne Dateien vom Backend nacheinander abgespielt werden. Dies ist inzwischen möglich.

Einzelne Zeichnungen habe ich zunächst mit Adobe Illustrator angelegt, jedoch ist das Variieren der Bilder beim Anlegen vieler einzelner Dateien kaum möglich. Carola hat mir am Montag morgen darum Adobe InDesign empfohlen. Es lassen sich Sketches recht einfach anlegen und über den Seitenmanager vervielfältigen. Die Splines der Sketches werden mit jeder neuen Seite verschoben/ verzerrt/ gestaucht- in der Aneinanderreihung entstehen so animierte Bilder!

IMG_0001 IMG_0002

Android zähmen und auf Rails setzen

Meine letzte Projektwoche begann damit das Handy (ein Huawei Ascend P1) für unser Projekt abzuholen (Danke an Kai und Ebay Kleinanzeigen!)
Zuhause wurde das dann gleich gerooted und nach ein paar anfänglichen Problemen mit Zugriffsrechten mit einem frischen Cyanogenmod 11 bestückt.

Nach dem Durcharbeiten des Getting_Started-Tutorials fühlte ich mich bereit mir als nächstes Ziel eine einfachen App (siehe github) zu setzen, die Audio aufnehmen und wieder abspielen konnte. Die gute Dokumenation und Android Studio legen einem dabei zum Glück nicht allzu viele Steine in den Weg.

Die grobe Funktionalität der Anwendung: Sie besteht aus einer Activity (also einer Seite), die Buttons enthält, mit denen sich eine Aufzeichnung über das Mikrofon durchführen und abspielen lässt. Die Aufzeichnung wird im Dateisystem abgespeichert, alte Aufzeichnungen werden dabei immer überschreiben. Die Datei wird über eine HTTP-POST Anfrage hochgeladen. Durch das Android-Rechtesystem muss die Anwendung die entsprechenden Permissions für Mikrofonzugriff, Dateisystemzugriff und Netzwerkzugriff enthalten.

Grässliche Android-Oberfläche zum Testen der Funktionalität

Wie am Screenshot deutlich zu sehen, geht da noch was in Sachen Gestaltung 😉

Es gibt zwei Wege Android-Oberflächen zu erstellen: Durch die Definition in XML und auf programmatischem Weg in Java-Code. Mir scheint die XML-Variante wesentlich übersichtlicher und sauberer zu sein. Das mag aber auch durchaus daran liegen, dass ich viel mit HTML+Javascript gemacht habe und diese Trennung gewohnt bin. Wie und ob man diese zwei Arten der Oberflächenerstellung mischt, ist mir noch nicht so ganz klar. Daher habe ich mich fürs Erste dafür entschieden, das Layout in XML zu definieren und im zugehörigen Javacode Eventhandler an die Elemente zu kleben. Das funktioniert unter Android indem man Methoden der Activity definiert und diese Methoden beim initialisieren mit den in XML definierten Buttons verknüpft.

Der tatsächliche Upload der aufgenommenen Dateien zu einem Server gestaltete sich dabei ein wenig trickier, letztendlich war aber auch das mit dem richtigen Werkzeug recht einfach und gut zu erledigen (ein Hoch auf die 3rd-party-library Android Asynchronous Http Client die das Übertragen von Dateien via HTTP sehr einfach macht).

Um den Upload testen zu können, musste ein Server her, der die Dateien entgegennimmt und abspeichert. Da ich schon etwas Erfahrung mit Ruby on Rails habe, habe ich das als Rails Projekt umgesetzt (siehe github). Der Server beinhaltet eine Schnittstelle zur Entgegennahme der Audiodateien und Schnittstellen zur Anzeige der vorhandenen Aufzeichnungen. Im Hintergrund wird eine MySQL-Datenbank zur Persistierung der Aufzeichnungen verwendet.

Was nun noch fehlte war es die hochgeladenen Aufzeichnungen auch wieder abrufen zu können. Dafür hat der Server (fürs Erste) noch eine Download-Schnittstelle bekommen, mit der die Dateien über den Browser heruntergeladen werden können. Später irgendwann sollen die Dateien allerdings auch ohne Download im Browser abrufbar sein.

Die Index-Seite der Aufzeichnungen ist auch noch rein funktionaler Natur, aber immerhin funktioniert sie!

Grauenhafte Index-Übersicht über die auf dem Server hochgeladenen Geschichten

Funktionale Index-Übersicht über die auf dem Server hochgeladenen Geschichten

Die erste unserer Userstories „Ich als Besitzer möchte mithilfe des Ziegels eine Geschichte aufnehmen können um sie auf der Plattform einzubringen.“ ist damit schonmal abgearbeitet.
Auch die Story „Ich als Besucher möchte, dass auf einer Webseite die Geschichten zugänglich gemacht werden, um sie anhören zu können.“ ist in Teilen bereits bearbeitet.

Userstories über Userstories

Dieses mal dreht sich alles um die Formulierung von Anforderungen an unsere Anwendung. Wir haben versucht, die Anforderung in Form von Userstories festzuhalten, haben aber festgestellt, dass es Anforderungen bzw. Arbeitspakete gibt, die sich anders besser formulieren lassen. Aber dazu später mehr.

Zuerst etwas zur Vorgehensweise: zum Besprechen haben wir auf die inzwischen bewährte Kombi aus Skype&Etherpad gesetzt, auf Trello haben wir unsere Stories gesammelt und sind diese dann einzeln durchgegangen. Anschließend haben wir sie durch Labels und Positionierung priorisiert und versucht den zeitlichen Aufwand einzuschätzen.

Priorisierte Liste

Die (bereits priorisierte, absteigend geordnete) Liste unserer Userstories:

  • Ich als Besitzer möchte mithilfe des Ziegels eine Geschichte aufnehmen können um sie auf der Plattform einzubringen. (+++++)
  • Ich als Besitzer möchte verstehen, was es mit dem Ziegel auf sich hat um ihn verwenden zu können. (+++++)
  • Ich als Besitzer möchte den Ziegel einfach bedienen können, um nicht von einer Barriere abgeschreckt zu werden. (++++)
  • Ich als Besucher möchte, dass auf einer Webseite die Geschichten zugänglich gemacht werden, um sie anhören zu können. (++++)
  • Ich als Erzähler möchte die Geschichte auf der Plattform finden um sie evtl. noch nachbearbeiten und mit Metainformationen versehen oder löschen zu können. (+++)
  • Ich als Erzähler möchte vom Ziegel angeredet werden um ein besonders persönliches Benutzerlebnis zu haben. (++)
  • Ich als Besucher möchte die Geschichten auf einer Webseite kategorisiert abrufen können um einen Überblick über die Art der Geschichten zu bekommen. (++)
  • Ich als Besucher möchte die [schon vorhandenen] Geschichten anhören können um sie nicht lesen zu müssen. (++)
  • Ich als Besitzer möchte den Ziegel schütteln müssen. (+)

Gruppierung nach Rollen

Um die Stories besser fassen zu können haben wir sie nach den Rollen Besitzer, Erzähler und Besucher (der Webseite) gruppiert. Die Rollen Besitzer und Erzähler sind nicht klar zu trennen, der Erzähler ist eigentlich eine Unterrolle des Besitzers, nimmt aber einen großen Stellenwert ein und wird daher als eigene Rolle aufgefasst. Dabei haben wir festgestellt, dass Stories mit gleichen Rollen beim Umsetzen nahe beieinanderliegen. Durch diese Gruppierung und die vorherige Priorisierung der Stories lassen sich nun auch Projektschwerpunkte besser erkennen.

Besitzer

  • Ich als Besitzer möchte mithilfe des Ziegels eine Geschichte aufnehmen können um sie auf der Plattform einzubringen. (+++++)
  • Ich als Besitzer möchte verstehen, was es mit dem Ziegel auf sich hat um ihn verwenden zu können. (+++++)
  • Ich als Besitzer möchte den Ziegel einfach bedienen können, um nicht von einer Barriere abgeschreckt zu werden. (++++)
  • Ich als Besitzer möchte den Ziegel schütteln müssen. (+)

Erzähler

  • Ich als Erzähler möchte die Geschichte auf der Plattform finden um sie evtl. noch nachbearbeiten und mit Metainformationen versehen oder löschen zu können. (+++)
  • Ich als Erzähler möchte vom Ziegel angeredet werden um ein besonders persönliches Benutzerlebnis zu haben. (++)

Besucher

  • Ich als Besucher möchte, dass auf einer Webseite die Geschichten zugänglich gemacht werden, um sie anhören zu können. (++++)
  • Ich als Besucher möchte die Geschichten auf einer Webseite kategorisiert abrufen können um einen Überblick über die Art der Geschichten zu bekommen. (++)
  • Ich als Besucher möchte die [schon vorhandenen] Geschichten anhören können um sie nicht lesen zu müssen. (++)

Man sieht nun, dass auf der Rolle des Besitzers ein Projektschwerpunkt liegt bzw. dass die Besitzer-Stories im Durchschnitt besonders hoch priorisiert sind.

Einschätzung des Arbeitsaufwandes

Beim Durchgehen der einzelnen Stories sind wir auf das Problem gestoßen, dass die pauschale Einschätzung des Arbeitsaufwandes von Userstories ohne weiteren Maßstab schwierig ist. Die Geschichten lassen sich sehr weit fassen und der Arbeitsaufwand einer einzelnen Geschichte ist nicht so sehr vom Inhalt der Geschichte als vielmehr der erwünschten Qualität des Ergebnisses abhängig. Daher haben wir beschlossen auf Basis der Geschichten eine Liste von Aufgaben zu entwickeln, sodass die Anforderungen konkreter definiert und auch andere notwendige Arbeiten erfasst werden können, die sich nicht durch eine Userstory ausdrücken lassen (beispielsweise die Einarbeitungszeit in eine neue Technologie).

Wenn das geschafft ist, geht es endlich ans Umsetzen!

Stadtgeschichten aus Pappe und Stein

Unser Projekt war zwar als eines der ersten ziemlich konkret, die letzten Schritte zu einer wirklich definierten Idee haben uns aber umso mehr beschäftigt.

Die ganze Stadtgeschichtenidee bestand von Anfang an aus zwei Komponenten:

-Dem „Objekt“, mit dem die Geschichten aufgenommen werden und -der Platform, auf der sie präsentiert werden.

Da wir uns lange auf das Objekt konzentriert hatten, lag unser Fokus vor der letzten Woche ersteinmal bei der Plattform und wie wir die attraktiv gestalten können. Insbesondere auch, da ja die bereits bestehenden Geschichten von der ZLB mit aufgenommen werden sollen. Nach einigem hin und her haben wir uns für eine eher minimalistische Kartenansicht entschlossen und für unsere letzten beiden Treffen den Fokus wieder auf das Kernstück unseres Projektes gelegt:

Das Objekt soll mehr sein, als ein einfaches Aufnahmegerät. Es soll den Wunsch wecken, eine Geschichte zu finden oder vielleicht sogar selbst zu erzählen. Und es soll Lust machen auf die Geschichten, vielleicht sogar Begehrlichkeit wecken bei denen, die es noch nicht mit sich rumtragen durften.

Ein Smartphone bietet als Kern sämtliche Funktionalität, die wir brauchen. Es hat ein Mikrophon, die Möglichkeit, Daten über das Internet zu versenden und mit dem Touchscreen und den restlichen Sensoren sehr flexible Bedienmöglichkeiten.

Aber niemand erzählt einem alten Smartphone eine interessante Geschichte.

Wir brauchen einen Körper.

Hier ein paar Ideen unseres großartigen Smartphone-Geschichten-Körper-Designers Stefan:

sketches2

Eines unserer beiden Lieblingsdesigns:

Ichtogamat

Für den Paperprototype haben wir uns für das andere Design entschieden:

Berlin besteht aus Ziegeln, selbst wenn man sie nicht immer sieht. Jedes Mal, wenn eine Geschichte erzählt wird, ist ein Ziegel in der Nähe. Wenn die Reden könnten…

Aber warte mal!

Story_Brick

Ein Ziegel, der redet??? Naja, so oder so ähnlich.

Auf Basis dieser Idee ist dann in einer Nacht und Nebel Aktion diese Schönheit entstanden:

Gestatten, der Smart Brick… oder so:

Story_Brick_Proto

Unser Paperprototype, mit mindestens 3% Paper. Das User Interface ist noch ein bisschen verrutscht, aber das wird noch.