Erfahrungen mit Prototypen

Prototypen

Rückengymnastik: Ich benutze seit einiger Zeit ein selbstgeschriebenes Programm, das mir hilft, meine Rückengymnastik durchzuführen. Die Inhalte wurden angeregt durch das Buch von Hans-Dieter Kempf.

Schlafenszeiten: Bei den Kindern kommt es manchmal ganz gut an, wenn der Psion anzeigt, wann sie morgen wohl ausgeschlafen haben werden, wenn sie jetzt ins Bett gehen  - oder wann sie ins Bett gehen müssen, damit sie zu einer gegebenen Zeit ausgeschlafen haben. Deswegen entstand eine Online-Version dieses Programms, die man über diesen Link erreicht. Grundlage dafür ist das Buch von Annette Kast-Zahn und Hartmut Morgenroth.

BMI: Die Berechnung des Body-Mass-Index war für die Kids auch interessant: Sind von den Fussballern aus den Sammelheften einige zu dick?

Eine Zahnputzuhr, die den Rhytmus für das Zähneputzen vorgibt, wurde nur kurzzeitig verwendet  - elektrische Zahnbürsten, die eine Musik spielen, eignen sich dazu besser. Das war auch ganz gut so, denn PDAs und Wasser vertragen sich nicht so gut.

Man kann Referenzwerte für die Nährstoffzufuhr ermitteln lassen, die für einen persönlich gelten. Diese Berechnung lehnt sich an die Empfehlungen der Deutschen Gesellschaft für Ernährung an. Dies würde erst interessant im Zusammenhang mit den noch nicht realisierten Teilen, die die Ernährungsgewohnheiten analysieren und daraus Vorschläge für den Speiseplan und Einkaufszettel erzeugen.

Diese Programme sind in OPL geschrieben und laufen auf einem Psion Serie 5 bzw. Serie 5 mx. Möglicherweise lassen sie sich leicht für den Nokia Communicator anpassen, da es dafür auch einen OPL-Interpreter geben soll. Kommerzielle Version müssten auf Plattformen realisiert werden, die weniger von der Hardware abhängig sind, wie Java oder .net.

Wenn Sie Interesse an diesen Programmen haben, melden Sie sich bitte - am besten per E-Mail - bei mir. Ich würde dann versuchen, Ihnen diese Programme in geeigneter Form zugänglich zu machen.
 

Gelernte Lektionen über die Benutzerschnittstelle

Aus den mit dem praktischen Einsatz der Prototypen gemachten Erfahrungen leite ich einige Anforderungen an die Benutzerschnittstelle ab. Als eine der wichtigsten Erfahrungen betrachte ich, dass man für die Gebrauchstauglichkeit die Software- als auch die Hardwareanteile der Benutzersschnittstelle zusammen betrachten sollte.

Als wichtige Anforderungen sind mir aufgefallen:
- Zuverlässigkeit. Ein Gerät, das im Alltag eingesetzt wird, wird nicht wie ein rohes Ei behandelt werden. Runterfallen, Sand, Drauftreten - alle diese Dinge können vorkommen. .
- Dauerhaftigkeit, Interoperabilität
  Daten sind möglicherweise noch da, aber es gibt keine Programme mehr, mit denen man sie lesen kann
- Aktuelle Kalenderinformationen: Feiertage möglicherweise gestrichen, Schulferien ....

Informationskanäle

Die folgende Tabelle ist in noch in einer "Brainstorming-Phase". 

Kanal	Welche Information kann das Handy damit erhalten, welchen Nutzen erzeugen?
Ein/Ausschalter	Wann ist der Besitzer aktiv/wann entspannt er sich?
Geführte Telefonate	Ansteigen der Zahl der Telefonate kann auf Stress-Situationen hindeuten.
Tastatur	Informationen aus direkter Kommunikation mit dem Besitzer,  z.B. Feedback zu Vorschlägen des Handys. Damit kann das Handy über die Gewohnheiten seines Besitzers dazulernen. Eingabe persönlicher Daten, .... Anwendungsprogramme starten. Ähnlich der Kommunikation mit Notebook oder PC, jedoch mit stark eingeschränkter Bandbreite.
Ausgeführte Programme	Ergebnisse der Programme selbst (z.B. Reaktionstest-Programm), aber auch Rückschlüsse aus der Art der verwendeten Programme (Büroprogramme, Musik beim Joggen, u.ä).
Uhr	Wenn als Wecker eingesetzt kann die Verzögerung bei Ausschalten des Alarms Rückschlüsse auf Schlafverhalten zulassen
Bluetooth	Kommunikation mit anderen Geräten in der Umgebung. Neben dem üblichen Computern und deren Peripherie könnten das auch sein Sensoren (z.B. zu Waage, Kassenzettel der Kantine für Essensgewohnheiten u.ä. - ist noch etwas Zukunftsmusik)
Mikrophon	Spracheingabe - Ergänzung / Ersatz der Tastatur Stimme des Besitzers, Lärmbelastung -> Kann dem Benutzer das Einstellen der Profile abnehmen, z.B. wenn es sehr leise ist, mit Klingel leise stellen, wenn es laut ist, laute Klingeltöne verwenden.
Kamera	Visuelle Information über Besitzer oder dessen Umgebung. Um diese Information zu nutzen, wird geeignete Bildverarbeitungssoftware benötigt. Damit kann man die Kamera als Barcodeleser geeignet für EAN und PZN einsetzen. Diese Möglichkeit wird z.B. in dem P-nut-S-Projekt ausgenutzt. Diese Funktionalität könnte  in nicht allzuferner Zukunft durch RFID-Reader ersetzt werden, die in Handys eingebaut werden. Bildverarbeitungssoftware gibt es aber auch für viele andere Aufgaben, die man mit einem Kamerahandy sinnvoll erledigen könnte.
Ortsinformation durch GPS oder Informationen über Funkzellen, Signalstärke	Ortsinformationen, man könnte z.B. Autofahrten, Bewegung zu Fuss, Arbeitszeiten u.ä. erkennen, möglicherweise auch ob sich der Benutzer innerhalb oder außerhalb eines Gebäudes aufählt.
Infrarot	ähnlich wie Bluetooth
Display/ Touchscreen	Kommunikation mit Besitzer, wenn der das will. Wie Display von PC oder Notebook, jedoch mit stark eingeschränkten Kommunikationsmöglichkeiten. Touchscreen kann in gewissen Umfang Tastatur oder Maus ersetzen.
Lautsprecher	Aktives Initiieren der Kommunikation mit Besitzer oder Hinweise: Zeit, aufzustehen, Schlafen zu gehen, Mittagspause, ... Braucht Uhr, Feiertagskalender, und persönliche Urlaubsplanung.
Datenübertragung	Zugang zu Wissen, das für die aktuelle Situation relevant ist. Z.B. Feiertagskalender, damit Wecken nur an Arbeitstagen erfolgt, Wetterinformationen,....
Drucker	Einkaufszettel oder Kochrezepte sind in Papierform bequemer zu nutzen als etwa über eine Anzeige im Display eines Smartphones. Über drahtlos angebundene Drucker ist das Herstellen von Papierkopien sehr einfach möglich.
RFID-Reader	Auch wenn möglicherweise derartige Produkte noch nicht auf dem Markt sind: Mit dem heutigen Stand der Technik sollte es möglich sein, RFID-Lesegeräte in Handys zu integrieren. Ein vom Handy aus einem Funketikett gelesene RFID kann es mit verschiedenen Informationen über seine Umgebung versorgen. Das dürfte dann interessant werden, wenn  sich  die RFID-Technologie  in größern Umfang auf dem Markt durchgesetzt hat. Im einfachsten Fall könnte man damit EAN und PZN von Produkten auslesen, um sich über diese zusätzliche Informationen zu verschaffen, oder einen  Bestand an Vorräten zu überprüfen. Da man mit manchen Handys mit geeigneter Software auch über die Kamera EANs und PZNs auslesen kann, lassen sich derartige Funktionen auch mit heute verbreiteter Technologie realisieren.

Architektur von Wellness-Software

Einzelne Programme, die Handys zu Wellnessgeräten umfunktionieren sollen, können ganz einfach sein. Ein Programm etwa, das den Rhytmus für gymnastische Übungen vorgibt, kann sich darauf beschränken, gesteuert von einem Zeitgeber einige Sound-Dateien abzuspielen. Es benötigt nur eine sehr einfache Benutzerschnittstelle, um etwa das Programm zu starten, die Übungen zu wiederholen oder zu unterbrechen und vielleicht noch, die Lautstärke zu steuern.

Im allgemeinen dürfte diese Art von Software so komplex werden, dass sich einige Überlegungen zur Architektur lohnen. Für die Architektur von Wellness-Software halte ich folgende Punkte für wichtig:

1. Es ist denkbar, dass Teile dieser Software als unabhängige, kleine Anwendungen realisiert werden, von denen jede für sich ziemlich einfach ist.  Wenn jede dieser Anwendungen unabhängig voneinander entwickelt wird, hat das für den Anwender die Konsequenz, dass er sich mit einer Reihe verschiedener Benutzerschnittstellen herumschlagen muss. Diese funktionieren möglicherweise nach unterschiedlichen Prinzipien, die der Anwender für jedes Programm speziell erlernen muss. Die Programme werden eine Reihe von Informationen über den Anwender benötigen, die dann für jedes Programm erneut erfasst werden müssen. Diese beiden Phänomene dürften die Anzahl der Programme, die ein Anwender aktiv verwendet, auf eine ziemlich kleine Zahl begrenzen. Dieses Problem kann man vermutlich dadurch entschärfen, dass man eine einheitliche Entwicklungsplattform verwendet, z.B. die Java 2 Platform, Micro Edition.
   


2. Manche Anwendungen müssen, um sinnvoll zu sein, Daten aus unterschiedlichen Quellen verknüpfen. Das kann bereits bei scheinbar harmlosen Programme der Fall sein. Wenn ein Wecker werktags wecken soll, dann sollte er über die Feiertage informiert  sein, die am Aufenthaltsorts des Anwenders gelten. Da sich diese Feiertage durch politische Entscheidungen ändern können, kann man sie nicht fest in die Software einbauen, sondern man benötigt einen Dienst, von dem das Handy die aktuellen Feiertagsregelungen beziehen kann. Wenn der Anwender den Wecker braucht, um rechtzeitig zur Arbeit zu kommen, dann müsste das Handy auch über Urlaub und Krankeit seines Benutzers informiert sein.
   


3. Die Kommunikation mit einem Handy unterscheidet sich erheblich von der mit einem herkömmlichen PC oder Notebook.
Das Fehlen einer komfortablen Tastuatur bewirkt, dass es für den Anwender schwierig ist, das Handy mit Informationen zu versorgen. Wegen der beschränkten Größe des Displays kann das Handy nur wenig Information an den Anwender weitergeben. Das bedeutet, das sich die Kommunikation zwischen Handy und Anwender auf kleine Datenmengen beschränken muss, die nur die wichtigsten Informationen enthalten. Die Informationsreduktion kann man dadurch erreichen, dass man Hintergrundinformationen verschiedener Art verwendet. Viele Handys verfügen über zusätzliche Informationskanäle, die man einsetzen kann, um die Hintergrundinformationen zu beschaffen und/oder die Bandbreite der Kommunikation zum Benutzer zu erhöhen.


4. Vertrauenswürdige Datenhaltung
Ein Handy kann eine ganze Menge von Informationen sammeln, die dazu beitragen, seinen Nutzwert zu erhöhen. Manche dieser Informationen, z.B. einige medizinische Informationen, entfalten ihren Nutzen erst dann, wenn sie über einen Zeitraum zur Verfügung stehen, der länger ist als die Dauer einer aktuellen Handy-Generation. Sie sollten also einen Gerätewechsel überdauern können. Bei vielen dieser Informationen wird der Anwender Wert auf eine Kontrolle darüber legen, wohin die Informationen weitergeben werden. Aus der Sicht des Anwenders ist wegen der Kommunikationsmöglichkeiten der Handy dieser Aspekt nur schwer zu kontrollieren.

Einige erste Ideen zu den Folgen für die Benutzerschnittstelle (Man Machine Interface, MMI) und die Architektur derartiger Software:

• Daten-Spiegelbild des Benutzer sollte explizit enthalten sein.
• Die darin gespeicherten Daten können von vielerlei Anwendungen genutzt und aktualisiert werden. Das würde es ersparen, dieselben Daten mehrfach in verschiedene Anwendungen einzugeben. Es wirft aber das Problem auf, dass irgendwie sichergestellt werden muss, dass die Vertraulichkeit der persönlichen Daten gewahrt bleibt.
• Ablage der Daten in standardisierten Formaten mit (hoffentlich) langer Lebensdauer, z.B. XML. Wegen der nicht vorhersehbaren Entwicklung sollte das Datenformat nachträglich erweiterbar sein und z.B. in einem XML DTD festgelegt werden.
• Sicherstellen der Kontrolle des Nutzers, welche Daten weitergegeben werden.
• Nutzung verschiedener KommunikationskanäleNäheres dazu ist im Abschnit über "Informationskanäle" zu finden.
  
• Daten-Spiegelbild der aktuellen Umgebung des Benutzers wird benötigt, Beispiele
• Ort (Zuhause, Büro, unterwegs, ...) 
• Wetter
• ...
• Diese Art von Software könnte als "Spielwiese" für eine Reihe von Aktivitäten dienen, an denen Probleme kommender Softwaregenerationen an einfach erscheinenden Anwendungsbeispielen ausprobiert werden können. Mit Fragestellungen, die hier relevant sind, beschäftigt sich meiner Meinung nach die Open Mobile Architecture (OMA) Initiative. Auch in dem Positionspapier der VDE/GI über Organic Computing glaube ich einige Punkte entdeckt zu haben, die für diese Art von Software relevant sind.
  

Links zu Büchern und Webseiten.