Omsnation ist eine große Party, die am 24. April 2009 in Augsburg stattfinden wird. Das Besondere dabei ist, das das Konzept zusätzlich zu den Dingen, die eine Party normalerweise großartig machen, noch möglichst viel Web-2.0-artige User-Interaktion integriert. Von der Info-Seite:

OMSNATION ist nicht nur irgendeine Feier. Sie ist die interaktive Party. Du bestimmst, welche Musik gespielt wird, und Du beeinflusst, was an Live-Visualizations geboten wird:

Während der gesamten Veranstaltung ist unser Fotografenteam unterwegs und schießt Bilder von der Party, die nur wenige Sekunden später auf einer der Leinwände erscheinen, zusammen mit unserem zeitversetzten Live-Video, das dafür sorgt, dass Du keinen lustigen Moment verpasst.
(Ach ja: Wir achten natürlich auf Deine Privatsphäre. Wenn du nicht möchtest, dass wir dich fotografieren, sag es einfach dem Fotografen. Und peinliche Fotos schießen wir erst gar nicht.)

interactive VJ-Tablet-Action: Am Eingang kannst du Dich künstlerisch entfalten. Du hast die Möglichkeit, auf einem Grafiktablet digitale Zeichnungen zu entwerfen. Wir strahlen Dein Werk zusammen mit den Zeichnungen unserer anderen Gäste an die Wand.

Besonders viel Spaß hat es gemacht, die reddit-artige Seite für Musikvorschläge zu erschaffen. Unter dem Punkt Your Music können Besucher der Webseite im Voraus Musikwünsche abgeben und denen von anderen Besuchern zustimmen. Die meistgewünschten Lieder werden dann gespielt. Und die Twitter-Integration ist einfach ein wunderschönes Spielzeug :)

Das gesamte Konzept, Design und auch der Code von omsnation.de ist erschaffen von breakthesystem. Und zwar mit viel Spaß, denn wenn neue Wege und Konzepte in Augsburg ausprobiert werden, dann wollen wir da ganz vorne dabei sein.

Der minimalistische Ansatz

Der minimalistische Ansatz war nicht nur der eleganteste, sondern auch der, der am ehesten zum schlanken Aussehen der alten breakthesystem.org-Seite gepasst hat. Letztendlich hat sich aber herausgestellt, dass der Mockup für die Landing Page zwar sehr schön aussah, das Konzept sich aber für Blog und Portfolio nicht gut erweitern ließ.

Der Design-Prototyp wurde mit dem 960.gs Grid System rein in HTML und CSS erstellt und größtenteils mit CSSEdit bearbeitet, was uns die Möglichkeit gab, schnell verschiedene Farbkombinationen und Typografiestile auszuprobieren.

Der Holz/Papier-Ansatz

Dieser Prototyp ist beinahe das genaue Gegenteil des vorherigen. Anstatt schlicht wollten wir opulent. Anstatt weniger Bilder wollten wir Pixel-Overkill. Das ist uns gelungen :) Lange Ladezeiten und manchmal sogar hohe CPU-Last haben diesen Entwurf aber dann zu Fall gebracht. Außerdem war er leidr nicht flexibel genug, um auf beliebige Seiten ohne Vorbereitung angewandt werden zu können.

Pixellastig wie er ist, ist der Prototyp natürlich komplett in Adobe Photoshop entstanden, dort aber ebenfalls mit 960.gs-Overlay.

Das tatsächliche Ergebnis

Unser neues Design liegt irgendwo zwischen den beiden Extremen: Nicht so leer wie der erste Entwurf, und nicht so schwer wie der zweite. Vor allem aber ist es sehr gut auf unseren Unterbau Wordpress angepasst, was uns das tägliche Leben teilweise enorm erleichtert.

Und wie gefallen die Entwürfe unseren Lesern?

Ideen sammeln

Am Anfang ist eine Anwendung nichts weiter als ein Haufen von guten und weniger guten Ideen. Wir setzen uns mit unserem Kunden zusammen und schreiben alles auf, was uns zu dieser Anwendung Cooles, Wichtiges und Interessantes einfällt. Machbarkeit spielt zu diesem Zeitpunkt noch nicht wirklich eine Rolle.

Danach organisieren wir die gesammelten Gedanken, zum Beispiel in einer Mind Map. Wir müssen jetzt festlegen, was genau die zukünftige Anwendung kann, und an welche Zielgruppe sie gerichtet ist; am besten in einem Satz. Das kann sich dann zum Beispiel so anhören: “Flickr ist eine Webseite, mit der Hobbyfotografen ihre Bilder anderen zeigen und neue Fotos entdecken können.”. Diese Aussage sollte so genau wie möglich sein!

Wenn wir eine Definition gefunden haben, die passt, und die auch angenehm kurz ist, gehen wir die gesammelten Ideen noch einmal durch. Passen die Ideen? Was fällt uns noch ein, jetzt wo wir die Definition haben? Am Schluss haben wir eine gute Idee für eine schlanke, gut definierte Anwendung.

Prototyp

Wir wissen jetzt, was wir wollen; als nächsten Schritt überlegen wir uns, das Wie. Und zwar nicht das Wie aus der Sicht eines Programmierers, sonderen aus der Sicht eines Anwenders, denn die sollen das fertige Produkt schließlich einmal benutzen.

Dazu erstellen wir einen Prototypen, eine Repräsentation wie sich die Seite später für den Benutzer anfühlen wird und wie sie aufgebaut ist. Meistens arbeiten wir dabei mit Papier: Ein A4-Blatt für eine Unterseite und Post-Its oder kleine Zettel für Elemente, die sich ändern können, oder die wir probeweise an verschiedene Stellen setzen. Bei besonders interaktiven Webseiten setzen wir auch Prototypen aus HTML und JavaScript ein.

In dieser Phase arbeiten wir besonders eng mit dem Kunden zusammen, denn hier entscheidet sich, wie sich seine Webseite verhalten wird. Der tatsächliche Code dahinter ist schließlich für jemanden, der die Seite benutzt, meistens weniger wichtig.

Architektur und Code

Basierend auf den Entscheidungen, die wir bisher über Features, Aussehen und Verhalten der Webseite getroffen haben, entscheiden wir uns jetzt, auf welche Art wir genau die Webseite programmieren. Manchmal können wir eine fast fertige Open-Source-Lösung, z.B. ein CMS benutzen und müssen es nur noch anpassen. Manchmal ist eine Seite aber auch so neuartig und anders, oder hat so besondere Anforderungen, dass wir uns dafür entscheiden, sie von Grund auf neu zu schreiben. Dann sind jetzt zu klären, welche Programmiersprache, Datenbank und Server wir benutzen, und wie wir den programmatischen Teil der Webseite aufbauen.

Ach, und, programmieren sollten wir das Ganze dann auch noch. Dazu konzentrieren wir uns typischerweise auf den wichtigsten Teil der Seite — welcher Teil das ist, wissen wir aus unserer Arbeit mit Prototypen — und entwickeln diesen. Danach sehen wir nach, ob das bisher Geschriebene den Kundenwünschen entspricht und ob sich durch die Entwicklung neue Erkenntnisse ergeben haben, die sich auf die anderen Teile auswirken. In diesem Fall passen wir die entsprechenden Prototypen und Designs an und beginnen dann die Arbeit am nächst-wichtigeren Teil. Und so weiter.

Usability Testing

Jedes Mal, wenn ein Teil der neuen Webseite fertig gestellt ist, arbeiten wir an den anderen Teilen weiter, aber wir testen gleichzeitig den fertigen Teil auf seine Benutzerfreundlichkeit. Das haben wir zwar schon zum Teil an den Prototypen gemacht, aber das ist kein Grund, einen tatsächlichen Usability-Test wegzulassen.

Wir lassen also (je nach Größe des Projekts) Freunde, Kollegen oder Beta-Tester (und natürlich auch unsere Kunden) die Seite benutzen und beobachten sie dabei, wie sie verschiedene Aufgaben à la “Bestelle ein Ticket über das Ticketsystem” oder “Finde heraus, wann die Veranstaltung statt findet” lösen. Mit diesen Beobachtungen verfeinern wir die Benutzeroberfläche so lange, bis sie für möglichst alle User intuitiv, elegant und schnell zu bedienen ist. Wenn es nicht Spaß macht, sich auf der Seite zu bewegen, sind wir noch nicht fertig. :)

Auslieferung

Irgendwann haben wir den Punkt erreicht, wo wir die Webseite für auslieferungsreif halten. Manchmal ist dann die gesamte Seite fertig, aber oft auch nur die Kernfunktionalität, und wir arbeiten an der Seite weiter, während sie schon an Bekanntheit gewinnt. Das hilft uns noch zusätzlich, den Ablauf der Aktionen auf der Seite weiter zu optimieren, weil wir genau beobachten können, was echte Benutzer — keine Betatester — tatsächlich tun.

Sei es nur ein Teil oder sei es das Ganze, die Seite muss online. Wir kümmern uns um den Server und um die Domain, und darum, dass von Tag Eins ab der Webauftritt glatt läuft. Unsere Kunden bekommen sogar die Handy-Nummern der beteiligten Mitarbeiter, so dass sie sofort einen Kontakt haben, falls etwas schief geht.

Mehr

So entsteht bei uns eine Webseite. Vielleicht auch Ihre? Unterhalten Sie sich doch einfach mit uns über Ihre Idee! Unsere Kontakt-Seite zeigt, wie Sie uns erreichen.

Mit dem Erschaffen ist es übrigens noch lange nicht vorbei. Eine gute Web-Präsenz wird immer weiter entwickelt, analysiert und gepflegt, und darum kümmern wir uns auch. Aber das ist ein Thema für einen späteren Blogpost.

Bilder: Zevotron, someToast, mccready, breakthesystem, re-ality, Don Solo

Huh?

In recent weeks, I’ve stumbled over so many Tools for managing code snippets, it’s not funny any more. Viusual Studio plugins, TextMate plugins, apps for Windows, apps for OSX, apps for the web… what’s the matter? Why is everybody suddenly horny for little snippets of code?

I’ve thought about trying out a code snippet application, but… I wouldn’t really know what to do with one. I have no fucking clue, really! Yes, of course, you’re supposed to enter little snippets of code that you think could be useful in the future, but I somehow have never come accross these.

I don’t really need snippets, do I?

Of course, I have code on my hard drive that I will definitely reuse. For example, I have a folder called CSS with CSS files to reset font and spacing settings and set grid systems. I also have a folder with an almost-finished CMS that will most certainly be included in more than one web-app of mine.

But that doesn’t really merit a whole App. So I don’t use one. And this is okay by me, or at least I think so.

But what if I’m missing out on something really cool?

What if there are indeed cool things to be said about Schnippets, and I just haven’t realized them? That would suck. Are you using a code snippet app? If so, what for? I’m looking forward to your ideas.