MarkInTosh schrieb:
Sorry, aber das ist Unsinn. Die Touch-Abfrage eines Fingers ist wesentlich komplexer, als die pixelgenaue Steuerung und Abfrage einer Mausposition. [...], ist es nicht vergleichbar trivial. [...] so muss man bei Touch-Bedienung einiges berücksichtigen, das bei einer Maus vernachlässigt werden kann oder gar nicht vorkommt.
Da wir schon eine gewisse "Aggressivität" in den Kommentaren haben, werde ich mir da auch erlauben etwas direkter zu sein und sage mal frei heraus: Du magst meinen Beitrag gelesen haben, mit deinen Einwürfen gehst du aber vollkommen inhaltlich entweder an meinen Aussagen vollkommen vorbei - Thema verfehlt - oder beschränkst dich nur darauf es als Falsch hinzustellen, ohne dass du wirklich inhaltliche Argumente dafür nutzt.
An dieser Stelle macht es theoretisch überhaupt keinen Sinn auf deinen Beitrag weiter einzugehen, weil ich nicht nur deine Aussagen in der Luft zerpflücken würde, sondern die anderen hier inhaltlich langweilen würde.
Alleine die Aussage, dass die Touchabfrage eines Fingers wesentlich komplexer ist als die pixelgenaue Steuerung und Abfrage einer Mausposition ist in der Form genau eines Unsinn! Natürlich ist die Abfrage in Software einer Touchgeste anders aufgebaut als die Abfrage anders als die Mausbewegung und ebenso ist der Click anders zu bewerten. Alleine aber die Aussage, dass du das eine als trivial hinstellst und das andere nicht, lässt hier sehr wohl die Frage aufkommen, ob du wirklich jemals einen "Treiber" für ein Touchdisplay geschrieben hast oder eine Maus und so wie du hier schriebst: Du hast beides nicht gemacht!
Sowohl die Maus als auch ein Touchdisplay liefern über eine Schnittstelle gewisse Rohdaten, die man auswerten muss und während man bei einem Touchdisplay relativ einfach die X/Y-Positionen ermitteln kann - also wo jemand Klickt - muss ich bei der Maus sehr wohl beachten, wo ist die Maus gerade und entsprechend die Beschleunigungsvektoren beachten.
Ich will es an der Stelle nicht weiter ausführen, aber Treiber für eine Maus oder ein Touchdisplay, wenn man diese von Grundauf schreibt, sind beide nicht trivial, sondern man muss einiges beachten.
Nur ist Treiberentwicklung für eine Touchsteuerung ebensowenig Thema dieses Beitrages wie es die Treiberentwicklung für die Maussteuerung ist. Eingaben werden in Windows, Linux als auch MacOS, iPadOS und iOS über eine API an die entsprechenden Programme weitergeben und übermittelt.
MarkInTosh schrieb:
Sorry, aber: Beide Aussagen sind aus Sicht der Ergonomie schlicht falsch. Nicht umsonst beschäftigen Apple und Microsoft hunderte Spezialisten im Bereich Human Interfaces - und scheitern doch hin und wieder an ihren eigenen Konzepten.
Welche Aussagen sind denn schlicht falsch? Es ist immer wieder lustig, wie gewisse Leute zwar jemanden eine falsche Aussage unterstellen, dann aber keine wirklichen Argumente bringen, sondern sich auf Pseudoargumente - hier dann die hunderte Spezialisten im Bereich Human Interfaces und dass diese scheitern.
Das ist nicht nur schlechter Stil, sondern einfach nur billig. Dabei gibt es an meiner Aussage durchaus etwas zu kritisieren, weil ich selbst an der Stelle zu einer drastischen Vereinfachung neigte, die durchaus dazu führt, dass eine der beiden Aussagen in der Form wirklich als Falsch bezeichnen kann, die andere Aussage wiederum ist nicht schlicht falsch, sondern DER entscheidende Punkt, wo die Hauptprobleme vernüftiger User-Interfaces liegen und damit kann ich - jetzt noch mal populistisch - meine Aussage wiederholen: Das Problem bei der Interface-Entwicklung ist nicht Maus+Tastatur gegen Touch, das Problem liegt in der Displaygröße und damit verbunden, wie viel Platz man hat. Für die Entwickler eines Programmes ist es vollkommen egal ob die Eingabe über eine Maus erfolgt oder über einen Touch auf dem Display.
Und jetzt werden wir etwas genauer und etwas differenzierter: Natürlich hat Touch und Maus durchaus auch eine Auswirkung auf die Interface-Gestaltung, dass habe ich sogar - wen auch überspitzt und stark vereinfacht - angedeutet. Mit einer Maus kann ich wesentlich feinere Icons nutzen, kann kleidere Taskleisten und Co verwenden und kann damit auch auf kleineren Displays mehr einblenden, als wenn ich wirklich auf Touch setze.
Und natürlich gibt es auch durch die Gestensteuerung bestimmte Aspekte in der UI, die ich anders lösen muss als mit der Maus und der Tastatur, aber da kommen wir halt wieder zu Teilen in der Treiberentwicklung und was der Treiber ermöglicht. Für mich als Entwicklerin ist es am Ende aber vollkommen unerheblich, ob der Nutzer nun per Maus und Tastatur oder per Touchdisplay mein Programm bedient: In Aqua - iOS greife ich auf
UIEvent zurück in JavaScript nutze ich die entsprechenden
Events für Tastatur, Maus und Co um bestimmte Aktionen abzuhandeln.
Das hat natürlich gewisse Fallstricke und man muss sich als Entwickler*in klar darüber sein, dass ich nicht jedes "Touch"-Event auch auf ein Mausevent und Co umwälzen kann, aber es gibt durchaus Synergien zwischen Maus und Touch und damit auch verbunden Aspekte die man gleich behandeln kann. Ich habe bereits Apps für iOS, iPadOS und MacOS entwicklet, ebenso habe ich WebApps entwickelt, die von SmartPhone über Tablett bishin zu großen Monitoren skalieren müssen und damit habe ich mich antürlich auch mit Responsive-Webdesign beschäftigt.
Und natürlich gibt es da dann Sachen die man beachten muss, aber und jetzt kommt der wichtige Punkt - und das habe ich auch bereits angedeutet - die Probleme beim Entwurf eines Interfaces für eine App oder für eine WebApp war seltenst der Unterschied zwischen Maus + Tastatur gegen Touch-Display, sondern die primären Probleme sind immer wegen der Größe des Displays entstanden.
Auf einem kleinen Smartphone-Display muss ich eine UI anders strukturieren, weil ich viel weniger Platz habe um Elemente anzuordnen. Ich muss mich auf die wichtigen Kerninformationen beschränken, während ich andere Informationen hinter "Icons" und "Gesten" verstecken muss, damit es nicht zu klein wird. Auf einem Tablett habe ich dann mehr Möglichkeiten, kann bereits Zusatzinformationen einblenden, gewisse Arbeitsschritte schon anders gestalten und auf einem Desktop-PC mit 27" kann ich ein Interface noch mal ganz anders aufbauen und noch viel mehr Informationen direkt zugänglich machen, statt sie irgendwo zu verstecken!
Und da kommen wir nun zu dem entscheidenden Punkt und ich könnte es jetzt mit Screenshots demonstrieren, wenn ich mein Arbeitslaptop nicht vergessen hätte:
Ich habe hier gerade ein ActivePanel mit 80" Touch und da läuft Windows 10 ohne jegliche Anpassung an "Touch". Ich kann darauf sehr gut arbeiten und kann alleine wegen der schieren größe. Touchanpassungen braucht da die Windows UI als auch die Software UI keine. Problem ist hier nur beim Programmieren die "Breite" und "Höhe", damit ich viel Text sehe, muss ich entsprechend die ganzen Zusatzfenster einklappen.
Auf meinem 4K-Monitor kann ich mit Maus und Tastatur fast weitgehend alles offen lassen, was ich an Informationen habe, es ist genug Platz da! Gehe ich jetzt auf den FullHD-Monitor daneben und würde da arbeiten, müsste ich so einige Zusatzinformationen bereits einklappen wieder, wie am ActivePanel. Am 13" MacBook muss ich noch mehr einklappen und in Alternative-Desktops verlegen, mit der selben Aufteilung im Editor kann ich aber auch auf meinem 13" iPad Pro arbeiten, einziger Unterschied: Die Elemente zum Klicken muss ich etwas größere stellen wegen den Fingern.
Auf dem SmartPhone geht das alles so nicht, da ist nur das Textfenster offen, der rest ist hinter Icons versteckt, die dann sich einblenden. Schade, dass ich jetzt keine Screenshots machen kann, die das verdeutlichen.
Aber ich bleibe damit bei meiner grundlegenden Aussage: Das Hauptproblem für eine vernüftige UI ist nicht unbedingt Maus vs. Touch, sonder eher bei der Displaygröße zu lokalisieren.
