But let’s start from the beginning…

Warm-up: The Corkscrew Controller

The first weekend we were in for a crash course on electrical circuitry and we also got into keyboard hacking briefly (i.e. ripping out the USB controller of cheap keyboard and rewiring the inputs). Our first challenge was to create a new kind of interaction device for a game we like. The choice fell (obviously) on SNES Mario Kart and after some strolling through the CDTM we found a corkscrew somewhat resembling a steering wheel. We put a magnet on its rotating axis and two magnetic switches left and right besides the axis. After we soldered the wires to the keyboard controller our steering wheel was ready to go.

Concept: Music Creation

Jazzed from this quick hack, we went brainstorming about what kind of project we wanted work on the next weekend. We circled in on doing something with music creation and since I always enjoyed playing with drum computers (such as DrumTrack8 on the iPhone) we decided to create a tangible interface for a drum sequencer. We wanted to offer eight beats on three tracks and some sliders for BPM and volume control. Next to the actual hardware controller we also needed something to playback the drum samples, so while Diana was responsible for the design of the hardware, I took over the software development.

Software: Cocoa on OS X and some good old 808 samples

The development of the sequencer software itself was pretty straightforward: I went with a NSTimer driven approach and triggered the playback of preloaded NSSounds. The communication with the Arduino controller was somewhat more difficult. Luckily the sample project on the Arduino Cocoa page helped out a lot. As for the drum samples, I’ve stumbled upon some great Roland TR-808 samples. Next to marbles (blue means that the sample will be played on this beat) the UI also features a gray rectangle that indicates the current beat.

Hardware: Arduino, breadboards, aluminum foil and tons of hot glue

We used the workshop of the TU München to work on the hardware. Diana designed the case out of medium density fiberboard material and spray painted it black. For the marbles there are 24 holes, each with two wires. One of the wires goes into a common 5V power supply, while the other wire (24 of them in total) goes into a 4051 multiplexer cascade. To indicate the current beat just like in the software, we decided to let a blue LED shine through the three holes of a beat. The bottom plate therefore features seven separators to ensure that the LED just glows for one beat at a time. The eight LEDs are also controlled through a 4051 multiplexer. Due to time constraints, the whole electronics were laid out on a breadboard. The software running on the Arduino basically just reads out the current state of the 24 marble holes and updates the LEDs according to the OS X desktop software. Since our budget was limited, we couldn’t afford (conducting) steel marbles, so we had to go with wooden onces, which we wrapped with conducting aluminum foil.

Wrap up

So after three full days of work (I’m still amazed about what one can achieve in such short time, when really focused) we had a working beat box. Our study backgrounds (Industrial Design and Computer Science) really fit together perfectly and among other projects, we will present our controller at one of the CDTM Inspire&Dine sessions.

]]> http://fudgy.de/2011/04/marble-sequencer/feed/ 0 http://fudgy.de/2009/08/anonyme-ui-missbraucher-iphonedevcamp/ http://fudgy.de/2009/08/anonyme-ui-missbraucher-iphonedevcamp/#comments Wed, 05 Aug 2009 10:51:26 +0000 The Fudgy Beaver http://fudgy.de/?p=71 This post is about the usability talk I gave at the Munich satellite of iPhoneDevCamp on 2009-08-01. Since the language at the camp was german, so was my talk and so is the rest of this post.

Ich bin immer noch sehr begeistert vom Camp und den vielen interessanten Personen und Vorträgen die ich dort kennenlernen durfte. Insbesondere der Vortag von Cultured Code’s Andreas Linde zu “Mehr Effektivität im Entwicklungs-Prozess” hat mir direkt weitergeholfen den Betaprozess meiner eigenen iPhone App zu verbessern. Ich hoffe die Folien dazu gehen bald online. Die Videos vom ersten Block der Präsentationen (App Records, iOutBank und Holger Frank) sind bereits online, der Rest sollte in den nächsten Tagen folgen.

Nach den Jungs von Cultured Code, trat ich deren (große) Fussstapfen und hielt meinen Vortrag zu Usability und rief die Selbsthilfegruppe der anonymen UI-Missbraucher ins Leben. Die Folien dazu gibt es übrigens (zunächst einmal) hier.

Neben dem vielen Lob für das Thema und den Vortrag an sich (vielen Dank!), gab es auch fast genauso viel Tadel an der Gestaltung der Folien selbst. Zu meiner Verteidigung: Ich musste sie in (wirklich) kurzer Zeit erstellen. Trotzdem empfand ich sie selbst bei weitem nicht so schlimm. Für mich zeigt das vor allem mal wieder sehr schön, wie schwer es wirklich ist, die Qualität seiner eigenen Arbeit zu beurteilen. Das gleiche Problem plagt einem beim Entwickeln von UIs und deren Interaktion. Da der Entwickler (oft) als einziger die ganzen Annahmen und Entscheidungen hinter seinem Werk kennt, ist die UI aus seiner Sicht natürlich intuitiv und nahezu perfekt. Deshalb ist Feedback von “außen” meiner Meinung nach einfach unersetzlich und ein wichtiger Punkt im UI-Designprozess. Dabei heißt das nicht, bei jeder Kritik sofort in Panik zu geraten und schlagartig die ganze UI umzuwerfen. Aber wenn mehrere Personen über die gleichen Fallen stolpern, kann man stark davon ausgehen, dass dies in Zukunft auch weiteren Personen widerfahren wird.

Jedenfalls, sollte es ein iPhoneDev Camp 2010 geben, bin ich definitiv wieder dabei! Außerdem möchte mich noch mal bei App Records und Boinx Software für die professionelle Organisation bedanken!

• Wow, ist ja wie Apple Keynote fürs Web!
• Die Anwendung setzt Maßstäbe in Sachen Usability!
• Die Grenzen zwischen Web und Desktop Anwendungen verschwimmen immer mehr!

Nur: Braucht die Welt wirklich noch 5000 weitere Online Office Anwendungen?

Nein! Zumindest nein, wenn die Entwickler das Ziel haben langfristig mit der Anwendung selbst Geld zu verdienen. Und Venture Capital sammeln zählt nicht als Geld verdienen.

Zu den Nutzern von Präsentationssoftware gehören vor allem Unternehmen und deren Akzeptanz wird gering sein, solange nicht absehbar ist ob der Software Anbieter (samt den bei ihm gespeicherten Daten) in einem Jahr überhaupt noch existiert. Ein wunderschönes Beispiel dafür ist iAmaze, die diese Idee schon im Jahr 2000(!) verfolgt haben und inzwischen vom AOL Moloch absorbiert wurden.

Die gern zitierte Erkenntnis, das vom großen Vorbild Microsoft Office 80% der User nur 20% der Features nützen rechtfertigt zudem die beschränkte Funktionalität dieser Anwendungen nur auf den ersten Blick. Wenn nämlich jeder Benutzer andere 20% braucht und verwendet (persönliche Killer-Features für mich: PDF-Export, Presenter-Modus, Masterslides), dann wundert man sich recht schnell warum man nicht gleich Microsoft Office oder OpenOffice verwendet.

Gerade im Unternehmenseinsatz kommen dann noch ganze andere Aspekte hinzu: Die Tatsache, das man nicht mal eben ein Management Briefing mit vielen bunten und vertraulichen Zahlen auf dem Server irgendeines Startups liegen haben will klopft dann auch noch leise an der Tür der IT-Security Abteilung. Dieses Henne-Ei Problem, nämlich das ein Softwareanbieter erst einmal bis zu einem gewissen Punkt wachsen muss um Stabilität (im Sinn von Bestehen am Markt) und Vertrauenswürdigkeit vermitteln können, für dieses Wachstum aber erst mal diese beiden Faktoren sicherstellen muss wird sich nicht durch ein weiteres Web Office me-too Produkt aufbrechen lassen.

Die verdammte Lernkurve

Man übersieht aber bei diesem sehr wirtschaftlichen und kurzfristigen Blick leicht, wie das Web als Gesamtes von solchen Entwicklungen profitiert. Auf die gleiche Art wie der Zweite Weltkrieg und der Kalte Krieg ein technologische Wettrüsten ausgelöst haben, ohne das wir heute (so pervers es klingt) wahrscheinlich keinen Computer auf jedem Schreibtisch hätten, treibt die Blase um Web-basierte Anwendungen und Software-as-a-service Geschichten natürlich die Etablierung des Browsers als ernstzunehmendes Entwicklungsziel weiter voran.

Im Laufe der Zeit wird dadurch ein enormer Erfahrungsschatz in Sachen Web-basierte Clients aufgebaut, schon allein weil viele Fehler der Desktop Client Entwicklung wieder gemacht werden und viele Probleme wieder auftauchen. Als Lösung entstehen immer bessere Web-Frameworks und somit Abstraktionen von den darunter liegenden Technologien (HTML/CSS/JavaScript).

Warum 280 Slides wichtig und interessant ist

Abstraktion ist genau der Begriff für das was 280 Slides interessant macht. Man mag ja durchaus Zweifel am Geschäftsmodell einer Präsentationssoftware haben, aber aus technischer Sicht haben die Entwickler 280 North wirklich Neuland betreten:

Die drei Entwickler von 280 North waren wohl von Apple’s Cocoa Framework zur Desktop Entwicklung sehr begeistert. Denn 280 Slides wurde mit einem neuen Framework names Cappuccino realisiert, das nichts anderes ist als 280 North’s Versuch ist ein Cocoa ähnliches Framework für Web-basierte Clients zu entwickeln.

Wenn man einen Blick in den Quellcode wirft, wird man sich dann als Cocoa Entwickler sofort heimisch fühlen:

- (void)newDocument:(id)aSender
{
    if (!_applicationHasFinishedLaunching)
        return [super newDocument:aSender];

    [[ThemePanel sharedThemePanel]
        beginWithInitialSelectedSlideMaster:SaganThemeSlideMaster
                              modalDelegate:self
                             didEndSelector:@selector(themePanel:didEndWithReturnCode:)
                                contextInfo:YES];
}

Wie man sieht haben 280 North zudem eine Objective-C nicht unähnliche Sprache names Objective-J entwickelt. Samt Javascript Interpreter.

Die Idee Cocoa fürs Web klingt sehr verlockend, loben doch viele Entwickler (samt mir) die hohe Produktivität die man mit Cocoa erreichen kann. Als Beispiele seien nur Key-Value-Coding/Binding, Undo Manager und Delegates genannt. Wenn es jetzt 280 North schafft ihre Vision weiter zu verwirklichen, sind Mac Entwickler in der einmaligen Position mit der gleichen Sprache (Objective-C), gleichen Grundkonzepten und sehr ähnlichen Frameworks für den Mac (Cocoa), das iPhone (Cocoa Touch) und das Web (Cappuccino) entwickeln zu können. Haben Mac Entwickler schon jetzt den Vorteil mit einer gewissen Vorerfahrung an das Thema iPhone Entwicklung heran gehen zu können, könnte Cappuccino es schaffen diesen Vorsprung auch noch aufs Web auszuweiten.

Für den Entwickler bedeutet das, sich auf eine solide Technologiebasis verlassen zu können mit der sich Ideen schnell in Produkte umsetzen lassen. Der Anwender profitiert von Web-Clients die in Sachen Interaktivität, Funktionalität und Look-and-Feel gestandenen Desktop-Anwendungen kaum mehr nachstehen. Ich bin gespannt wann wir Lieblinge wie Delicious Library als Web-App sehen.

Abschied von der Web-Assembler Entwicklung

Cappuccino ist ein weiterer Nagel in den Sarg von etwas das ich Web-Assembler Entwicklung nenne. Damit meine ich das in Zukunft Web-basierte Anwendungen immer weniger in den Assembler-Sprachen des Webs (wie HTML/CSS/Javascript) geschrieben werden, sondern vermehrt Frameworks zum Einsatz die diese zum Teil unangenehmen Technologie abstrahieren.

Damit hat der Entwickler den Kopf frei für das eigentliche Problem und muss nicht mehr darüber nachdenken ob seine Text Felder jetzt in allen aktuellen Browsern richtig dargestellt werden. Das schöne daran ist, dass der Output fürs Web nur ein Implementierungsdetail ist und unter diesen Frameworks genauso gut Flash, SVG, Silverlight oder was auch immer stecken kann.

Dieser Ansatz wird zum Beispiel von der Eclipse RAP (Rich Ajax Plattform) schon verfolgt. Das Programmiermodell von RAP ähnelt sehr stark dem der Eclipse Rich Client Plattform. Damit können RCP Desktop-Anwendungen mit geringen Änderungen als Ajax Web-App verfügbar gemacht werden – ohne das der Programmierer auch nur eine Zeile Javascript oder HTML tippen muss.

Auch bringen Frameworks wie RAP und Cappuccino Standardisierte GUI-Komponenten mit, was natürlich die Usability verbessert.

Von Serverseitigen, über Gleichberechtigte hin zu Clientseitigen Anwendungen

Cappuccino unterscheidet sich aber von Eclipse RAP dadurch, dass das komplette Framework im Browser läuft.

In der Anfangszeit von Web-basieren Anwendungen lief die komplette Logik auf dem Server, der Browser war schlicht für die Anzeige der fertigen Seiten zuständig. Mit der Entdeckung von Ajax, wurden die Aufgaben zwischen Server und Client etwas mehr aufgeteilt. Der Browser dürfte selbstständig Eingaben (Vor-)validieren, Daten nachladen und Änderungen vom Server pollen.

Aktuell geht die Entwicklung dahin, komplette Anwendungen für den Browser zu entwickeln, die einmal geladen, komplett selbstständig im Browser laufen. 280 Slides zum Beispiel kommuniziert nur mit dem Server wenn es speichern will oder Daten (Bilder,etc) aus dem Web einfügt.

Der Vorteil darin liegt neben der höheren Interaktivität, dass es einfacher wird Web-Apps auch offline zur Verfügung zustellen. Auch kann sich der Softwareanbieter über eine geringere Serverlast freuen, wenn so gut wie alles auf dem Client abläuft.

Natürlich ist dieses Clientlastige Entwicklungsmodell vor allen bei Produktivitätsanwendungen wie Office Pakete oder Bildbearbeitung sinnvoll. Bei datenbanklastigen Anwendungen (z.B. Bücherladen) kommt man um eine häuftigere Kommunikation mit dem Server nicht herum.

Nur wie will 280 North jetzt Geld verdienen?

Bleibt noch die Frage warum 280 North überhaupt Funding erhalten haben. Meine Vermutung: 280 Slides ist für mich vor allem eine sehr gelungene Techdemo, mit dem 280 North einen idealen, medienwirksamen Showcase für ihr Cappuccino-Framework gefunden haben. Das große Geld kann dann über die Beratung und Umsetzung von individuellen Kundenprojekten mit ihrer eigenen Technologie kommen – aber das sind natürlich nur wilde Theorien aus meiner Feder.