Willkommen auf myCSharp.de! Anmelden | kostenlos registrieren
 | Suche | FAQ

Hauptmenü
myCSharp.de
» Startseite
» Forum
» Suche
» Regeln
» Wie poste ich richtig?

Mitglieder
» Liste / Suche
» Wer ist online?

Ressourcen
» FAQ
» Artikel
» C#-Snippets
» Jobbörse
» Microsoft Docs

Team
» Kontakt
» Cookies
» Spenden
» Datenschutz
» Impressum

  • »
  • Community
  • |
  • Diskussionsforum
[CF2.0] Design u. Architekturfrage - Multimodale Benutzerschnittstelle
Luth
myCSharp.de - Member



Dabei seit:
Beiträge: 36

Themenstarter:

[CF2.0] Design u. Architekturfrage - Multimodale Benutzerschnittstelle

beantworten | zitieren | melden

Tag zusammen,

ich bin mal wieder auf eure Hilfe angewiesen weil ich mir gerade gar nicht so sicher bin, dass ich nicht drauf und drann bin, einen großen Haufen Mist zusammenschreibe. ^^

Ich habe mir zusammengereimt was ich für mein Projekt alles brauche und mit welcher Software-Architektur man das vielleicht umsetzen könnte. Genau da hakt es aber. Ob diese Umsetzung sinnvoll, realisierbar, halbwegs performant oder blödsinnig ist, kann ich schlecht einschätzen da sich meine Erfahrung mit .Net in Grenzen hält.

Ich würde demzufolge mal beschreiben, was mir bisher vorschwebt und wäre für jegliche Kommentare und Anregungen dankbar.




//Aufgabe:

Ich steh vor der Aufgabe für einen PDA den Prototyp eines multimodalen Benutzerinterfaces für ein etwas umfangreicheres Programm zu basteln. Da das Program unter anderem für blinde und sehbehinderte Nutzer geeignet sein soll, kann ich mit Windows.Forms alleine erstmal relativ wenig anfangen. Man stelle sich zum Beispiel sowas vor:

Eingabe:
- ein Tastaturaufsatz auf dem Touchscreen
- vielleicht kommandobasierte Spracherkennung
- Exotischere Dinge wie USB-Joysticks, Gamepads, Brailletastaturen

Ausgabe:
- Sprachsynthese
- Taktile Ausgabe über Braillezeilen oder eigens entwickelte Spezialgeräte
- angepasste visuelle Ausgabe für sehbehinderte




// weitere Forderungen:

- Prinzipielle erweiterbar bezüglich Dialoginhalten und Sprachanpassungen
- Möglichkeit zur Einbindung zukünftiger Ein- und Ausgabegeräten
- Weitreichende Konfigurierbarkeit über Benutzerprofile




// Damit verbundene Probleme:

- Kopplung der Ein- und Ausgabegeräte
===> Bei Windows.Forms enge Kopplung. Ein ListView "weis" was und wie es darstellen soll, feuert Events wenn etwas selektiert wird und unterstützt Stifteingaben etc....
===> Im Fall eines Tastaturaufsatz und Sprachausgabe muss erst implementiert werden wie Selektionen oder Auswahlen in einer Liste funktionieren und woher die Ausgabe "weis" das etwas selektiert wurde

- Multithreading
(Sprachverarbeitung braucht viel Zeit, im Hintergrund laufen komplexe Algorithmen ...)

- Präsentation der Inhalte muss vielfältig anpassbar sein. Farbschemata, Soundschemata und bestimmte Dialoge sollen nur für bestimmte Nutzergruppen zugänglich sein.



-----------------------------------------
Bisherige Ideen zur Umsetzung:
-----------------------------------------

1. Einführung einer (sehr begrenzten) Dialogbeschreibungssprache:

- Ausgelagerte Dialogbeschreibung in einer XML. Der Ansatz dürfte von XAML oder UIML bekannt vorkommen. Diese sind aber viel zu groß/komplex und meines Wissens nach gibt es keine Umsetzung für PDA's und CompactFramework. Neben Dialogablauf und Dialogelementen stehen auch die Inhalte in der XML-Datei. Damit schlag ich hoffentlich auch die Umsetzung verschiedener Sprachen tot. Will jemand das alles auf usbekisch haben, muss er halt die Xml-Inhalte ins Usbekische übersetzen.

- Definition einer Handvoll abstrakter "Widgets". Beispielsweise wird für Auswahl aus einer Liste ein "ListChooser" eingeführt. Der enthält alle wählbaren Optionen, die damit verknüpften Aktionen und eine textuelle Selbstbeschreibung als Hilfestellung. Die Präsentation bleibt den angeschlossenen Geräten überlassen. Ich weis vorher halt nicht, ob da nun vorgelesen wird oder das ganze doch grafisch dargestellt wird.
Für sehende Nutzer kann das ganze dann in einem Windows ListView dargestellt werden, für sehbehinderte kann eine Anordnung extragroßer Windows-Buttons genutzt werden und für Blinde eine textuelle Beschreibung der Optionen über Sprachausgabe. Ähnlich für Labels, InputFields für einfache Typen und Buttons.




2. modulares Gerätekonzept:

- Ein- und Ausgabegeräte werden getrennt und in einem eigenen Thread ausgeführt.
Mit Hilfe zweier Basisklassen, von denen jeweils eine von jedem Geräte implementiert werden muss, wird die grundlegende Funktionalität für Ein- und Ausgabegeräte festgelegt. Als Geräte werden in diesem Sinn zum Beispiel auch zwei unterschiedliche Sprachsynthese-Engines verstanden.

- Klassifizierung von Informationsklassen
Über die jeweils implementierten Interfaces wird festgelegt welche Ein- oder Ausgabeoperationen das Gerät unterstützt.

Doofes Beispiel:
Eine Handytastatur kann zur Navigation durch Dialoge und zur Texteingabe genutzt werden, muss also die entsprechenden Interfaces implementieren. Ein ..hmmm...vielleicht .... Joypad zur Texteingabe ist eher unschön, zur Dialognavigation würde es sich aber eignen, daher nur IDialogNavigation implementieren.

Dööferes Beispiel:
Über Sprachsynthese lassen sich die definierten Widgets prinzipiell beschreiben und darstellen. Das Interface IDialogOutput würde also implementiert werden. Ein ...pfff....tja... Armband mit Vibratoren zur taktilen Ausgabe würde damit nichts anfangen können, wäre aber wohl zur Ausgabe von Richtungsanweisungen geeignet. Dieses würde daher nur IDirectionOutput implementieren.

Wie die entsprechenden Informationen präsentiert werden ist der Umsetzung der entsprechenden Geräteklassen überlassen. Welche Arten von Informationen das Gerät erhält wird über die Interfaces geregelt und was für Informationen präsentiert oder eingegeben werden sollen, steht in der XML-Dialogbeschreibung.



3. Kommunikation der Geräte untereinander:

Ein zentrales Verwaltungssystem hält aktuellen Dialog- und Systemzustand, und informiert die angeschlossenen Geräte über Änderungen.

Jedes Ausgabegerät verfügt über eine queue in die vom Verwaltungssystem Nachrichten gepackt werden. Anstatt die queue immerzu abzufragen sollen Events eingesetzt werden um den Gerätethread zu informieren, das etwas Neues in der Queue liegt.

Das Verwaltungssystem selbst unterhält eine Queue in der alle Eingabegeräte Nachrichten hinterlassen können, wenn irgendeine Nutzeraktion vorliegt.

Für die verschiedenen Informationsklassen werden verschiedene Events definiert damit nur die Geräte reagieren, die die entsprechende Informationen abonniert haben.

Synchronisierung ist angedacht über Locking (mittels lock(queue.syncroot)) für alle Schreib- und Lesezugriffe. Reicht das schon aus oder steckt da wesentlich mehr dahinter? Synchronized queues stehen im CompactFramework nicht zur Verfügung soweit ich das überblicke.


------------------------------------------------------------------------------------------


Soweit erstmal wie ich mir das bisher gedacht habe. Falls noch irgendjemand bis hierher gelesen hat, würde ich gerne wissen ob sowas prinzipiell funktioniert und sinnvoll ist. ^^ Ich bin für jede Anregung offen und stelle diesen Ansatz hiermit zur Diskussion. Ideen, Verbesserungen, Schimpfe, Deklarationen meiner Person als komplett verrückt, Hinweise auf ähnliche Arbeiten oder Tools zur Realisierung sind ausdrücklich erwünscht.

Das ganze soll übrigens keine fertige Anwendung werden sondern ein Prototyp der in der Lage ist, die prinzipielle Funktionsfähigkeit des gewählten Konzepts zu demonstrieren.


Ich danke für die Aufmerksamkeit,
der Lutz
private Nachricht | Beiträge des Benutzers
herbivore
myCSharp.de - Experte

Avatar #avatar-2627.gif


Dabei seit:
Beiträge: 49.486
Herkunft: Berlin

beantworten | zitieren | melden

Hallo Luth,

ja, ich habe tatsächlich bis zum Ende gelesen. Ich hoffe du bis mir nicht böse, wenn ich nicht so viel schreibe wie du. Ich denke, das Konzept ist ganz ok. Sehr engangiert, aber machbar. Du musst bloß mit deinen Threads aufpassen, weil alle Zugriffe aus das GUI aus dem GUI-Thread erfolgen müssen.

herbivore
private Nachricht | Beiträge des Benutzers
svenson
myCSharp.de - Member



Dabei seit:
Beiträge: 8.746
Herkunft: Berlin

beantworten | zitieren | melden

Multi-Modal schreit natürlich nach Patterns wie MVC & Co.! Spannend ist aber, ob überhaupt das View-Konzept auf so unterschiedliche Darstellungsformen wie Schirm, Sprache und Braille einsetzbar sind. "View" heisst ja nicht umsonst "Sicht". Das impliziert eine parallele Darstellungs- und Bedienform. Sprache und Braille sind aber eher linear. Meine "Bedenken" sind aber eher aus dem Bauch heraus, kann das nicht konkret begründen.

Es gibt aber ein paar XML-Beschreibungssprachen, die ungefähr das (oder Teile) adressieren:

MPML , SMIL, DAISY.

Brauchst nur noch einen Processor dafür.

Spracheingabe wird in jedem Fall ein großes Problem auf dem PDA, wenn man mal sieht, was die "guten" Systeme an Performance schlucken (und die haben eine FPU!).
private Nachricht | Beiträge des Benutzers
Luth
myCSharp.de - Member



Dabei seit:
Beiträge: 36

Themenstarter:

beantworten | zitieren | melden

Erstmal danke für die Kommentare, auch wenn es nur zwei gab.
Vielleicht kommt ja später noch jemand angelaufen.

@Herbivore:
Ne da bin ich nicht böse, immerhin gab's ne Antwort und den Hinweis mit dem GUI-Thread. Das hatte ich die Tage schon ein paar Mal gelesen, aber es war trotzdem schon fast wieder im hintersten Gehirnwinkel verschwunden.

@svenson:
Deine Bedenken bezüglich Linearität von Sprache und Parallelität von visuellen Informationen sind durchaus berechtigt. Mit dem Gedanken schlag ich mich auch seit einer Weile herum.

Abgemildert wird das Problem etwas, da für sehbehinderte Menschen, auf Grund des kleinen Monitors auf dem PDA, auch nur sehr wenig Informationen zugleich dargestellt werden können.

Und den Rest werde ich versuchen mit einer automatischen Zusammenfassung von Teildialogen für Sehende und/oder eine Aufspaltung in mehrere Teildialoge für Blinde in den Griff zu bekommen. Ich halt mich da in etwa an die Kognitionsforscher-Typen die da behaupten, man könne im Arbeitsgedächtnis etwa 7 Information"chunks" zugleich behalten. Mit der Grundregel kann man bei der Gestaltung von Dialogen so ungefähr arbeiten, auch wenn die anstehende Strukturierung der Informationen nicht sonderlich einfach ist.^^

Die Beschreibungssprachen habe ich mir mal angeschaut, vorerst aber nur überflogen. DAISY scheint mir wenig geeignet, da zu sehr auf interaktive Hörbücher ausgelegt. (wenn ich das richtige DAISY gefunden habe) Zu SMIL habe ich bisher nur vage Informationen gefunden und MPML scheint mir ein wenig zu komplex für meine Zwecke zu sein. Für solche Sprachen wird ein Interpreter zu umfangreich glaube ich. Ich werde morgen nochmal mit mehr Ruhe nachlesen.

Und zum Schluss:
"Freie" Spracherkennung ist nur eine Zukunftsoption. Soweit ich weis ist das erkennen eines kleinen und auf einen Sprecher trainierten Vokabulars von einigen dutzend Kommandos wesentlich einfacher und wird zum Beispiel von der Sphinx-Engine ganz gut gemacht. Geht mich aber eigentlich auch nix an, muss mein potentieller Nachfolger sich anschauen.



Weitere Kommentare natürlich erwünscht!
private Nachricht | Beiträge des Benutzers