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