Ich würde es in etwas wie die rechte Variante machen, aber mit etwas "grauer 3D-Haptik" der Textbuttons und daneben "farbigen Symbolen" stat purem Farbindikator, weil:
- Wenn es Touch Bedienung ist, MUSS sich etwas auf aktiven Flächen tun, wenn ich den Finger dort hin halte ("Haptik", z.B. für die Zeit der Berührung dunklere Tastenfarbe)
- wir gegen bei Touch sogar soweit, das wir eine Aktion erst "KeyUp" auslösen, also "wenn die Taste losgelassen" wird.. hat den Vorteil das man wenn man die falsche Taste mit dicken Fingern erwischt hat und das ja "sieht", den Finger noch auf die richtige Taste "verschieben" kann, ohne etwas auszulösen
- pure Farbinikatoren wo rot,grün,gelb vorkommen haben wir abgeschafft, weil es erstaunlich viele Menschen mit Rot/Grün Blindheit (oder Sehschwäche) gibt
. daher wie beim Ampelmännchen: jede Farbe hat auch ein eindeutiges "einfaches" Symbol was zumindest direkt auf die Farbe schließen lässt. (wir bemühen uns aber, doch auch etwas den Buttontext symbolisch zu repräsentieren, weil so auch Leute damit klar kommen können, welche die/eine Sprache nicht 100% verstehen und davon gibt es heut zu Tage immer mehr, aber die merken sich "Bildchen")
Wichtig bei realer/"langsamer" Anzeige von Stati per Indikator und sofortiger/"schneller":
- wenn man die Haptikanzeige des/der Buttons blockiert, solange etwas übertragen/abgewartet wird, wirkt das bei Benutzung der
GUI sehr inkonsitent und wenig vertrauenserweckend, weil man nie "ein richtiges Gefühl" für den Touch bekommt, also wann&wie erkennt der Touch meinen Finger sicher/schnell/Punkt
- wenn die Haptikvisualisierung immer geht und Funktionen im Hintergrund "nicht blockierend" laufen, dann muss es eine "einheitliche" Visualisierung für "In Bearbeitung, Symbolanzeige noch nicht aktuell, bzw. nicht mehr aktuell" geben
Nehmen wir einen Lichtschalter auf einem per Funk kommunizierendem Tablet, welcher immer anzeigt ob das zugehörige Licht gerade an oder aus ist und man es mit einer Tipfunktion "umschalten" kann... da kann die Funkverbindung auch mal gerade dann schief gehen, wenn geschaltet werden soll... wenn man mit der Status/Symbolanzeige immer wartet bis der neue Sollzustand erreicht ist, dann könnte es sein das dies dem Benutzer zu lange dauert und er nochmal oder gar ungeduldig ganz schnell mehrmals drückt das Licht in diesem Fall dann flackern könnte wenn alle Befehle stur gepuffert werden.
Wir arbeiten daher mit "Sollwertanzeige", stellen also das InfoSymbol sofort um und übertragen erst dann im Hintergrund den Schaltbefehl. Das wirkt in der Touch
GUI flüssiger. Wir stellen da um das Symbol noch einen "Rand" oder "Punkt" dar, welcher wieder verschwindet nach TimeOut-Zeit X oder wenn der (neue oder alte) Istzustand real bestätigt verfügbar ist... richtig "gültig" sind nur "pure Symbole"... das ist aber eine Feinheit welche nur Servicekräfte beachten. Anwender freuen sich über die super schnelle Reaktion des Systems und beschweren sich eh wenn etwas nicht schaltet, ganz unabhängig was in dem Moment zu sehen ist
Und so wird aus ein paar simplen Buttons welche nur fix irgendwas reales per Touch steuern sollen ganz schnell eine Wissenschaft, wenn man es draußen selbsterklärend und sicher durch OttoNormalNutzer verwendbar sein soll.
Zum Test wenn schnell mal was gehen soll, setze ich auch einen Standardbutton und schreibe Quick&Dirty auch mal direkt ins OnClickEvent vom Form die Testfunktion ohne Rücksicht auf blockierte
GUI und konsistente Statusindikatoren... Ausliefern würde ich sowas nie, aber muss oft erklären warum denn wo doch nun "die neue Funktion geht" ich nun noch Zeit fürs
GUI oder auch MMI(also Mensch-Maschine-Interface) haben muss!