Browser soll wie Touchdisplay reagieren
T-Rex
Browser soll wie Touchdisplay reagieren
T-Rex
Moin,
gibt es ein Addon, das den Chrome (oder anderen Browser) so ausrüstet, dass ein Touchdisplayverhalten simuliert wird?
Gruß
Simulant
T-Rex
-
gibt es ein Addon, das den Chrome (oder anderen Browser) so ausrüstet, dass ein Touchdisplayverhalten simuliert wird?
- Chrome Developer Tools öffnen
- In den Preferences (Zahnrad-Symbol muss »Show 'Emulation' view on console drawer« aktiviert sein
- Zum Elements-Tab wechseln (oder einem anderen Tab außer Console)
- Escape drücken, unten gehen die Tabs Console, Search und Emulation auf
- Auf Emulation klicken
- Entweder ein Device wählen, was verschiedene Emulationen aktiviert, oder unter »Sensors« nur »Emulate Touch Screen« anschalten
https://developers.google.com/chrome-developer-tools/docs/mobile-emulation
Mathias
-
Wow. was in den tiefen des Chrome so alles steckt...
Primär wollte ich ein verhalten ohne Mouseover testen. Das müsste auch so das einzige sein, was man durch diesen Emulator nicht ändert :D. Kann man den Mouseover auch noch abschalten?
Gruß
Chrome wert schätzender
T-Rex-
Hallo,
Kann man den Mouseover auch noch abschalten?
Nicht dass ich wüsste. Selbst wenn – die meisten Touch-Browser emulieren Mouse-Events beim Tap (mouseover, mouseenter, mousemove, click usw.).
http://webkrauts.de/artikel/2012/einfuehrung-touch-events
Eine für Mouse-Bedienung gebaute Website wird also unter Umständen auf Touch-Geräten ohne Änderung funktionieren.
Schwierig wird es spätestens, wenn du einen mouseover-/mouseenter- *und* ein click-Handler definiert hast. Im Mobile Safari löst dann der erste Tap den mouseover/mouseenter aus, erst der zweite Tap den click-Handler. Das ist sinnvoll zum Öffnen von Dropdown-Menüs, die gleichzeitig ein Link sind, aber in anderen Fällen unerwünscht. Z.B. wenn beim mouseover/mouseenter nur ein zusätzlicher Tooltip eingeblendet wird, der auf Touch-Geräten vernachlässigbar ist.
Mathias
-
Hallo!
Kann man den Mouseover auch noch abschalten?
Nicht dass ich wüsste. Selbst wenn – die meisten Touch-Browser
Was für Browser ...!? :-P
emulieren Mouse-Events beim Tap (mouseover, mouseenter, mousemove, click usw.).
Richtig!
Eine für Mouse-Bedienung gebaute Website wird also unter Umständen auf Touch-Geräten ohne Änderung funktionieren.
Was bitte verstehst du denn unter einer "für Mouse-Bedienung gebaute Website"?
Grundsätzlich "funktionieren" Links solange sie nicht von einem CSS Hover abhängig sind.Schwierig wird es spätestens, wenn du einen mouseover-/mouseenter- *und* ein click-Handler definiert hast. Im Mobile Safari löst dann der erste Tap den mouseover/mouseenter aus, erst der zweite Tap den click-Handler. Das ist sinnvoll zum Öffnen von Dropdown-Menüs, die gleichzeitig ein Link sind, aber in anderen Fällen unerwünscht. Z.B. wenn beim mouseover/mouseenter nur ein zusätzlicher Tooltip eingeblendet wird, der auf Touch-Geräten vernachlässigbar ist.
Und bei dieser ganzen Geschichte sollte man nicht vergessen, dass sich auch an (fast) alle "typischen" Touchscreen Geräte eine Maus anschließen lässt, bzw. es mittlerweile ja auch eine ganze Reihe "hybride Geräte" gibt, die sowohl Trackpad und Keyboard als auch einen Touchscreen haben.
Nach dem aktuellen Stand der Technik ist es m.M.n. das beste, wenn man dem User auf der Seite eine Auswahl-/ Umschaltmöglichkeit zwischen Maus- und Touchbedienung anbietet.
Und per Javascript (jQuery) ist es imho am einfachsten, einen 'click' handler zu verwenden:
$("a").on("click", function(){...});Gruß Gunther
-
Hallo,
Was bitte verstehst du denn unter einer "für Mouse-Bedienung gebaute Website"?
Eine Webseite, die mit JavaScript Event-Handler für typische Mouse-Events registriert, und davon irgendwelche Funktionen abhängig macht (z.B. Zugänglichkeit über ein Dropdown-Menü).
Und per Javascript (jQuery) ist es imho am einfachsten, einen 'click' handler zu verwenden:
$("a").on("click", function(){...});Am einfachsten ja, am besten leider nicht. Ein click-Event feuert auf Mobilgeräten erst nach 300-350ms, weil Zoom-Gesten und Double-Taps möglich sind. Die Möglichkeiten, das zu umgehen, sind allesamt schrecklich.
http://updates.html5rocks.com/2013/12/300ms-tap-delay-gone-away
https://github.com/ftlabs/fastclick
http://blogs.telerik.com/appbuilder/posts/13-11-21/what-exactly-is.....-the-300ms-click-delayMathias
-
Hallo!
Am einfachsten ja, am besten leider nicht. Ein click-Event feuert auf Mobilgeräten erst nach 300-350ms, weil Zoom-Gesten und Double-Taps möglich sind. Die Möglichkeiten, das zu umgehen, sind allesamt schrecklich.
Ich weiß gar nicht, ob das unbedingt so "erstrebenswert" ist, diese Verzögerung zu umgehen?
Wenn ich beispielsweise beim Scrollen quasi "aus Versehen" auf einen Link komme, dann kann ich mit der Verzögerung trotzdem wie beabsichtigt scrollen, anstatt dass "unbeabsichtigt" eine neue Seite geladen wird (was gerade bei mobiler Datennutzung extrem "ärgerlich" sein kann).Und hat die Erfahrung nicht gezeigt, dass es eigentlich nie eine "gute Idee" ist/ war, das Default Verhalten, an welches der User ja auch gewöhnt ist, zu ändern?
Gruß Gunther
-
Ich weiß gar nicht, ob das unbedingt so "erstrebenswert" ist, diese Verzögerung zu umgehen?
Definitiv. Wenn ein Button erst nach 350ms reagiert, dann fühlt sich das UI insgesamt langsam und schwerfällig an. Nutzer »spüren« bereits 50-100ms Verzögerung. Als allgemeine Regel sollte man schon bei 200ms Wartezeit ein visuelles Feedback einbauen, damit Nutzer merken, dass das UI überhaupt reagiert. Bei 350ms tappen manche sogar ein zweites Mal, weil sie denken, die erste Eingabe sei nicht angekommen. Das sind Ergebnisse der Usability-Forschung.
Wenn ich beispielsweise beim Scrollen quasi "aus Versehen" auf einen Link komme
Die üblichen Fastclick-Implementierungen berücksichtigen das. Sie warten einen »Tick« auf ein Scroll-Ereignis nach touchend, bevor sie ein synthetisches click-Event werfen. Außerdem prüfen sie bei touchmove, wie weit sich der Finger bewegt hat, und brechen nach einem Schwellwert die Verarbeitung ab. Sprich: Scrolling löst keinen Fastclick aus.
Und hat die Erfahrung nicht gezeigt, dass es eigentlich nie eine "gute Idee" ist/ war, das Default Verhalten, an welches der User ja auch gewöhnt ist, zu ändern?
Das Default-Verhalten war noch nie notwendig das beste für den gegebenen Kontext. Wenn eine Website keine Gesten implementiert, dann besteht kein zwingender Grund, die komplette UI um mindestens 300ms zu verzögern.
Der User ist zudem nicht daran gewöhnt – sämtliche anderen Controls auf Desktop- und Mobilanwendungen reagieren nach ein paar Millisekunden. Nur auf mobilen Websites muss er so lange warten. Das ist besonders bei Buttons und Links nervig, die keinen kompletten Seitenreload auslösen.
Mathias
-
Ich weiß gar nicht, ob das unbedingt so "erstrebenswert" ist, diese Verzögerung zu umgehen?
Definitiv. Wenn ein Button erst nach 350ms reagiert, dann fühlt sich das UI insgesamt langsam und schwerfällig an. Nutzer »spüren« bereits 50-100ms Verzögerung. Als allgemeine Regel sollte man schon bei 200ms Wartezeit ein visuelles Feedback einbauen, damit Nutzer merken, dass das UI überhaupt reagiert. Bei 350ms tappen manche sogar ein zweites Mal, weil sie denken, die erste Eingabe sei nicht angekommen. Das sind Ergebnisse der Usability-Forschung.
OK, scheinabr ist diese Verzögerung bei allen meinen Geräten geringer, denn ich hatte bisher noch nicht wirklich den Eindruck (oder es liegt einfach daran, dass ich langsam alt werde).
Aber OK, grundsätzlich ist so eine Verzögerung natürlich "nicht schön".Aus reinem Interesse: Hast du ggf. mal den einen oder anderen Link für mich zu "brauchbaren" Seiten mit Ergebnissen/ Studien zur Usability-Forschung?
Wenn ich beispielsweise beim Scrollen quasi "aus Versehen" auf einen Link komme
Die üblichen Fastclick-Implementierungen berücksichtigen das. Sie warten einen »Tick« auf ein Scroll-Ereignis nach touchend, bevor sie ein synthetisches click-Event werfen. Außerdem prüfen sie bei touchmove, wie weit sich der Finger bewegt hat, und brechen nach einem Schwellwert die Verarbeitung ab. Sprich: Scrolling löst keinen Fastclick aus.
Wie sieht also deine Empfehlung bezüglich "Fastclick-Implementierung" aus?
Gibt's etwas Brauchbares "fertig" aus dem Regal (darf auch jQuery sein)?Gruß Gunther
-
Hallo,
scheinabr ist diese Verzögerung bei allen meinen Geräten geringer, denn ich hatte bisher noch nicht wirklich den Eindruck (oder es liegt einfach daran, dass ich langsam alt werde).
Sie tritt, wie Mattis Link auch zeigt, auch nicht auf jeder Seite auf. Viele Seiten schalten das Zooming ab, damit Links sofort und ohne Verzögerung aktiviert werden. Letztlich ist das aber keine schöne Lösung, da man ein eigentlich sinnvolles Browserfeature deaktiviert.
Hast du ggf. mal den einen oder anderen Link für mich zu "brauchbaren" Seiten mit Ergebnissen/ Studien zur Usability-Forschung?
http://www.nngroup.com/articles/response-times-3-important-limits/
»0.1 second: Limit for users feeling that they are directly manipulating objects in the UI.«
»A delay of 0.2–1.0 seconds does mean that users notice the delay and thus feel the computer is "working" on the command, as opposed to having the command be a direct effect of the users' actions.«
»If [a command] can't be done in 0.1 seconds, it certainly has to be done in 1 second, or users will feel that the UI is sluggish and will lose the sense of "flow" in performing their task.«http://web.mit.edu/press/2014/in-the-blink-of-an-eye-0116.html
Menschen nehmen Änderungen mit einer maximalen »Auflösung« von 13ms wahr (wenn ich das Testsetup mal auf Webseiten übertragen kann). Demgegenüber sind 300ms eine Ewigkeit.http://googleresearch.blogspot.fr/2009/06/speed-matters.html
verwandt: http://www.nytimes.com/2012/03/01/technology/impatient-web-users-flee-slow-loading-sites.html?pagewanted=all&_r=0
Wenn Google 400ms langsamer wäre, dann würden die Suchoperationen um bis zu 0,6% fallen. Übertragen auf andere Websites werden weniger Interaktionen gemacht (Page Impressions z.B.).http://highscalability.com/latency-everywhere-and-it-costs-you-sales-how-crush-it
»Amazon found every 100ms of latency cost them 1% in sales.«http://javabook.compuware.com/content/intro/how-humans-perceive-performance.aspx
»We expect an immediate response, within a half to one second, indicating our information is received. Even in the case of a simple interaction, we expect an actual response to our request. This is especially true for information we assume is already available, as when paging or scrolling content.«
Es gibt auch eine Buchempfehlung.http://www.allenpike.com/2011/providing-joy-at-60-fps/
Hier geht es mehr um Animationen und Scrolling in nativen Apps, welche mit 60fps laufen sollten. Das heißt: Ein Frame dauert 16,666… Millisekunden. Nicht jeder davon ist wahrnehmbar, aber 60fps sollte erreicht werden, damit direktes Feedback wahrnehmbar ist. Außerdem: »Every tap should have consequences when you lift your finger. First, though, comes an indication of a successful tap when you touch down.«Wie sieht also deine Empfehlung bezüglich "Fastclick-Implementierung" aus?
Es gibt viele kleinere Implementierungen mit riesengroßen Problem und eine große Implementierung mit großen Problem – die besagte https://github.com/ftlabs/fastclick.
Das ist keine exakte Wissenschaft, sondern eine sehr fiese, komplexe, naturgemäß unzuverlässige Heuristik mit einem Haufen an ekligen, aber unvermeidlichen Browserweichen und hartkodierten Erfahrungswerten.
Mathias
-
-
-
-
-
-
-
-