Für den Kurs „Human Computer Interaction“ sollte ein Usability Problem definiert und eine Lösung erarbeitet werden. Als Themenfeld wählte ich „Smart-Home“, das vernetzte und intelligente Zuhause. Mein Fokus lag auf der Entwicklung einer erschwinglichen Lösung zur Steuerung von Haushalts und Unterhaltungselektronik in kleinen bis mittelgroßen Wohnungen und Häusern.

Die meisten Hersteller mit bedienen mit teuren Gerätefamilien (Wie z.B. Loxone oder Nest) den lukrativen Markt der vernetzten Eigenheime, wobei eine Komplettlösung zur Steuerung diverser Geräte wie Heizung, Klimaanlage und Fenster mehrere tausend Euro kosten kann. Beschreibt der Begriff „Smart Home“ per Definition Routinen und Abhängigkeiten zwischen vernetzten Geräten (z.B. Wenn Fenster 1 in Raum 2 offen, stelle die Heizung 1 und 2 in Raum 2 automatisch ab) so wird er zum Teil auch synonym für die Steuerbarkeit dieser Geräte mit Apps oder Webinterfaces verstanden. Insbesondere in Fällen in denen dem Nutzer die letztere Option ausreicht, sei es durch kleinere Wohnungen oder schwer in Routinen auszudrückenden Nutzungsverhaltens, muss der Anwender im Vergleich zu analogen Lösungen (Beispiel Funksteckdosen) für die Steuerung mit Smartphone & co einen meist unverhältnismäßig höheren Preis bezahlen. Der Versuch, den Aufwand der manuellen Steuerung durch Automatisierung zu minimieren endet häufig in einem deutlich komplexeren Prozess und Frust beim Anwender. Viele der proprietären Systeme sind darüber hinaus meistens geschlossen und fortgeschrittene Anwender haben wenig bis keine Möglichkeit eigene Empfänger für spezielle Bedürfnisse zu entwickeln und in das Ecosystem ihrer Haussteuerung einzugliedern.

Zudem identifizierte ich Bereich „Home-Entertainment“, sprich Fernseher, Anlage, Receiver etc. ein signifikantes Usability Problem: Jedes Gerät benötigt eine eigene Fernbedienung mit jeweils etwa 40-60 Knöpfen, wobei davon in der normalen Anwendung nur ein Bruchteil benötigt wird. Analoge Lösungen wie Universalfernbedienungen haben den Nachteil, dass sie über ein vorgegebenes Layout verfügen, was zum einen wieder unnötige Knöpfe mit sich bringt und zum anderen den Nutzer häufig zwingt für verschiedene Geräte zwischen verschiedene Modi zu wechseln. Als Resultat hat der Benutzer zwar im Idealfall nur noch eine Fernbedienung in der Hand, diese jedoch durch das Wechseln zwischen den Geräten noch mehr nicht verwendete Knöpfe im normalen Usecase als vorher. Des weiteren ist das Layout einer Fernbedienung nun nicht mehr auf das jeweilige Gerät abgestimmt, und die mühselige Programmierung der Fernbedienung durch Eingabe von Produktcodes lässt sich nicht gerade als intuitiv bezeichnen. Digitale Lösungen in Form von Smartphone Apps gibt es mittlerweile zuhauf mit teils grundverschiedenen Ansätzen. Viele setzten auf Infrarot-Hardware, welche stationär am Smartphone befestigt wird. Dies erfolgt entweder über Peripherie am Kopfhörer-Anschluss (Beispiel „iRed“ oder „Zmart“) oder im Falle des iPhones am 24pin Connector (Beispiel „Re“). Der offensichtliche Nachteil dieser Lösung ist, dass der Nutzer die Hardware vor der Bedienung stets finden und am Gerät befestigen muss, da er diese in der Regel nicht stetig am Gerät angeschlossen hat. Ein weiterer Ansatz sind eigenständige Geräte, welche via Bluetooth angesprochen werden und Infrarot-Signale aussenden können (z.B. „Dijit“ oder „Peel“). Die zugehörigen Apps beschränken sich jedoch auf die Steuerung des Fernsehers basierend auf der App als einen Programmguide für das aktuelle Fernsehprogramms. Allgemein basiert das Interface vieler der verfügbaren Apps auf dem Layout physikalischer Fernbedienungen statt auf den gewohnten Interaktionen in anderen Apps.

Ziel des Projektes war es, ein realisierbares Produkt zu entwickeln, welches eine Lösung für die oben aufgeführten Probleme darstellt. Das Ergebnis ist ein Gerät, welches Infrarot- und Funksignale aufzeichnen kann, via Bluetooth mit einer zugehörigen iPhone App kommuniziert und durch Befehl der App diese aufgezeichneten Befehle wiedergeben kann.

Probleme & Lösungsansatz

Existierende „Smarthome“-Geräte sind zu teuer für die Verwendung als einfache Empfänger

Da das Gerät in der Lage ist, Funk auf zwei verschiedenen Frequenzen aufzuzeichnen und wiederzugeben, können herkömmliche Funksteckdosen, Heizkörperthermostate und Funkdimmer verwendet werden. Eine spezielle Smartphone-kompatible Funksteckdose wie die Bluetooth-basierte WeMo von Belkin kostet den Verbraucher um die 50€ während eine herkömmliche Funksteckdose bei Amazon für etwa 7€ pro Stück zu kaufen ist.

„Smarthome“-Systeme sind meist proprietär und nicht um selbstgebaute Empfänger erweiterbar

Anwender mit rudimentärer Erfahrung in der Elektrotechnik können mithilfe einer „Library“ für die Arduino Plattform eigene Empfänger entwickeln und über Infrarot oder Funk in das Netzwerk einbinden.

Usecase: Eine Fernsehsendung einzuschalten benötigt 6 Knöpfe - auf 3 verschiedenen Fernbedienungen

Die App lässt den Benutzer Befehle geräteunabhängig anordnen und zu Befehlsketten gruppieren.

Usecase: Von insgesamt 230 Tasten auf 5 Fernbedienungen werden 26 bei normaler Benutzung gebraucht

Beim Einstellen der App fügt der Benutzer zunächst nur jene Befehle hinzu, welche er für die normale Nutzung benötigt. Kommen weitere Befehle hinzu, lassen verschiedene Anordnungsmöglichkeiten den Nutzer die gesuchten Befehle im aktuellen Anwendungsszenario schnell wiederfinden.

Paradigmen

Im Laufe des Projektes wurden bei gravierenden, wiederauftretenden Konflikten folgende Paradigmen festgelegt, um eine konstante Haltung in der Konzeption zu ermöglichen.

1) „If you like your remote, you can keep it.“

Das System soll dem Nutzer in vielen Anwendungsszenarien eine bessere Option bieten, mit seinen Geräten zu kommunizieren. Dennoch ist die bisherige Art, Geräte über die herkömmliche Fernbedienungen zu steuern in bestimmten Szenarien die einfachere Bedienungsweise. Ein Beispiel: Das Smartphone, auf welchem der Benutzer die App verwendet, befindet sich entfernt in der Jackentasche und die Fernbedienung für einen simplen Task wie die Lautstärke des Fernsehers zu verändern ist direkt zur Hand. Hier soll die Nutzung bisheriger Fernbedienungen weiterhin uneingeschränkt zu ermöglicht, und dafür die Routinen-Funktion der App zu begrenzt werden, da durch die Verwendung von anderen Steuereinheiten als der App aktuelle Zustände der Empfängergeräte nicht mehr nachvollziehbar sind.

2) „Open Receivers“

Im Hinblick auf die Vermarktung des Gerätes soll der wirtschaftliche Fokus auf dem universellen Sender bestehend aus App und Gerät liegen. Eigene Empfängergeräte sollen zunächst nicht angeboten werden. Dafür sollen so viele existierende Geräte über allgemein verbreitete Funkstandards (Bluetooth, Infrarot, Funk auf zwei Frequenzen) angesprochen werden können und erfahrenen Nutzern die Möglichkeit gegeben werden, mit offenen Plattformen wie dem Arduino eigene Empfänger zu erstellen und an das System anzubinden.

3) „Modularity & Extensibility“

Im Bezug auf des Interface der App soll dieses möglichst modular aufgebaut sein, um für verschiedene Geräte passende Steuerlayouts anbieten zu können. Dabei soll die visuelle Darstellung und das mentale Modell so einheitlich wie möglich wirken. Darüber hinaus soll die Plattform um neue Steuerlayouts erweiterbar sein, um in Zukunft auf neue Anforderung oder Erkenntnisse bei der Benutzung reagieren zu können.

5) „Layering in Funktionality vs Flat Navigation Hirachy“

Durch die modulare Aufbauweise ist es notwendig Befehle welche über einen binären Status hinausgehen in weiteren Navigationsschichten zu verorten. Auch die Einteilung von Einstellungen oder Funktionen zum Hinzufügen von Befehlen hatten eine teils hohe Komplexität und erzeugten beim Aufteilen Widersprüche hinsichtlich der beiden Anforderungen.
Bei der Entwicklung der Navigation wurde versucht, Funktionen für ein simples und leicht verständliches Layout in weiteren Schichten zu „verstecken“ und gleichzeitig diese Schichten möglichst flach zu halten, um Funktionen mit so wenigen Clicks/Taps wie möglich zugänglich zu machen. Während der Konzeption kam es stetig zu Spannungen dieser beiden Anforderungen, wobei versucht wurde möglichst beiden gerecht zu werden und bei Bedarf Kompromisse zu machen.

6) „HIG Konformität vor Funktionszuwachs“

Um eine möglichst intuitive Benutzung zu garantieren, richtet sich das Design der Apps möglichst eng an den Interface Vorgaben der Hersteller. Bei der Implementierung erweiterter Funktionalität, welche über die grundlegende Umsetzung des Konzeptes hinausgingen, wurden diese stets mit der Konformität zu bekannten Interaktionsmustern („Familarity“) aufgewogen und im Zweifelsfall aus der App gestrichen. Ausgeschlossene Funktionen sollen in Zukunft in separaten Apps berücksichtigt werden können.

7) „Home Automation first, Smart Appliance later“

Die Kernfunktionalität der ersten im Rahmen des Kurses konzipierte und gestaltete App soll im wesentlichen die manuelle Steuerung der Geräte ermöglichen, wie es der Nutzer bislang mit physikalischen Fernbedienungen gewohnt ist. Die „smarte“ Kommunikation der Geräte untereinander, sowie das Nutzen von sensorischen und zeitbasierten Auslösern für bestimmte Befehle soll später in nach dem 6. Paradigma in einer weiteren App berücksichtigt werden.

Schritt 1 Research: Marktanalyse, erarbeiten von Problemen und entwickeln von Lösungen

Im ersten Schritt wurden die oben genannten Probleme bestehender Smart-Home und Home-Entertainment Systeme herausgearbeitet und Lösungen entwickelt, welche die Anforderungen an das Konzept stellten. Dazu wurde ein Survey erstellt, welcher die Zielgruppe, Geräte und Anforderungen an die Lösung besser erschliessen soll. http://fluidsurveys.com/surveys/henrikwaffner/smart-housing-home-entertainment-survey/

Copyright

©Henrik Waffner

Schritt 2 Concept: Konzeption der App und Hardware

Im zweiten Schritt wurden zunächst die „Jobs“ der App konkretisiert und anschliessend die technischen Bedingungen der Kommunikation zwischen Smartphone und Gerät definiert. Für letzteres wurde eine Art „Übersetzer“-Gerät für Funkstandards erdacht, welche technisch realisierbar sind und eine möglichst hohe Menge von verbreiteten Haushalts- und Unterhaltungselektronik abdeckt. Aus den „Jobs“ der App wurden Funktionsanforderungen definiert welche diese erfüllen können.

Copyright

©Henrik Waffner

Schritt 3 Form & Components: Formfindung und Auswahl der Hardware-Komponenten

Mit dem Vorsatz der vollständigen Realisierbarkeit des Konzeptes sollte auch das Hardwarekonzept bis zu einem möglichst ausformulierten Punkt entwickelt werden. Für die technischen Komponenten bedeutete dies die Auswahl eines SoC Microkontrollers (Nordic nRF51822) und der notwendigen Sensoren (940nm IR Diode von Watterott, zugehörige Empfänger, sowie 434MHz RF Link Empfänger und Sender, ebenfalls über Watterott beziehbar). Parallel dazu nutzte ich im Rahmen eines weiteren Kurses in diesem Semester, Onesie bei Frau Prof. Martini, die Möglichkeit des 3D Druckens um die Form des Gerätes zu explorieren.

Copyright

©Henrik Waffner

Schritt 4 Prototyping: Arduino, Papier und Makerbot

In dieser Phase des Projektes sollten drei Prototypen den Lösungsansatz für das ausgewählte Usabilityproblem so weit wie möglich validieren. Um einen ersten Eindruck von der App zu bekommen wurden nach der Konzeption der Navigationsstruktur erste Umrisse des Interfaces auf Papier gezeichnet und mittels POP-App ein klickbarer Prototyp erstellt. Feedback im Rahmen des Kurses und eigene Impressionen bezüglich dieser ersten Skizze resultierten in vielen der zuvor aufgeführten Paradigmen und legten den Grundstein für eine konkretere Ausführung im folgenden Schritt. Auf Seiten der Hardware wurde dieser Part mittlerweile komplett im Rahmen des Kurses Onesie weitergeführt. Die Möglichkeit, die beiden Aspekte des Projektes simultan in zwei Kursen abdecken zu können wirkte sich erheblich auf die Konkretisierbarkeit der entwickelten Ideen zur Lösung des Problems aus. Mittels Makerbot und CAD Software entwickelte ich die Form über diverse Schritte immer weiter, und versuchte eine spätere industrielle Produktion zumindest theoretisch im Rahmen meiner Möglichkeiten zu erfassen. Das direkte haptische Feedback, welches durch die Makerbot-Modelle ermöglicht wurde, floss stets in die Konzeption des Folgemodells. Mittels Arduino sollte ausserdem ein „Proof-of-Concept“ Prototyp gebaut werden, welcher zum einen über Bluetooth mit einem iPhone kommunizieren und zum anderen IR-Fernbedienungssignale aufzeichen und wiedergeben kann. Um beide Tasks auf einem Arduino Board zu realisieren wählte ich den kürzlich erschienenen RFduino, welcher auf dem zuvor angesprochenen Nordic nRF51822 Chip basiert und somit über Bluetooth mit dem Smartphone kommunizieren kann, während er mit der herkömmlichen Arduino-Programmiersprache programmiert wird. Beide Anforderungen konnte ich mit diesem Prototypen erfüllen, bis auf die Einschränkung, dass zum Ende des Projektes die Funktion des Wiedergebens von zuvor aufgenommenen IR-Signalen nur auf dem herkömmlichen Arduino Uno funktioniert hat.

Copyright

©Henrik Waffner

Schritt 5 Pixelperfect: Erstellen eines grafisch ausgearbeiteten App-Prototypen

Um Verständnisprobleme und mittels Papierprototyp schwer zu evaluierende Konflikte auszuräumen wurde abschliessend ein weiterer aus 14 ausgearbeiteten Screens bestehender klickbarer App Prototyp entwickelt, welcher die Grundfunktionen der App so detailiert wie möglich darstellen und erfahrbar machen soll. Da der finale Hardware-Prototyp aufgrund der feinteiligen Bestandteile nur fehlerhaft mit dem Makerbot zu drucken war, sollte zu Demonstrationszwecken eine Animation erstellt werden. Die Finale Form liegt als physikalisches Objekt fast fehlerfrei vor.

Schritt 6 Animated: 3D-Animationen des Gerätes

Da der finale Hardware-Prototyp aufgrund der feinteiligen Bestandteile nur fehlerhaft mit dem Makerbot zu drucken war, sollte zu Demonstrationszwecken eine Animation erstellt werden. Die Finale Form liegt als physikalisches Objekt fast fehlerfrei vor.

Von Anfang an war die Prämisse des Projektes die volle Realisierbarkeit mit bestehender Technologie und Infrastruktur. Durch die Verteilung der Hardware und Softwarekonzeption auf zwei Kurse war ich auch in der Lage beide Aspekte detailliert zu bearbeiten. Die erlernten Techniken in beiden Bereichen werden mir in Zukunft auf jeden Fall bei der Konzeption neuer Projekte hilfreich sein. Viele der verbleibenden Aufgaben bei der weiteren Umsetzung des Projektes liegen hingegen nicht in meinem angestrebten Tätigkeitsbereich. Die Realisierbarkeit bedeutet in diesem Fall auch die Rücksichtnahme auf bestehende Infrastrukturen, die ich in künftigen Projekten gerne hinterfragen würde.