[Devtip] Fastclicks

[Verwijderd]

Mogelijk interessant voor de tweakers developers:

https://github.com/ftlabs/fastclick

Uitleg: browsers in touch devices wachten standaard ongeveer 300ms na het registeren van een touch (click) voordat een link daadwerkelijk geopend wordt. De reden is dat mogelijk de gebruiker een reeks van gestures maakt die samen tot een enkele aktie leiden, bijvoorbeeld double tap to zoom of pinch to zoom. Hier heeft de gebruiker wat tijd voor nodig, waar de browser dus 300ms op wacht.

Bovenstaande library verwijderd in feite deze vertraging. En dit heeft 2 effecten:

- Normale clicks verbeteren enorm in snelheid. 300ms lijkt niet veel maar is een verschil van dag en nacht. Het voelt aan als de snelheid van een native app. Pas zonder die vertraging merk je hoe groot deze was.

- De bovengenoemde gestures werken helaas niet goed meer. Double tap to zoom werkt helemaal niet meer, en pinch to zoom werkt alleen als je beide vingers echt tegelijk gebruikt.

Ik vind persoonlijk zowel snelheid als de mogelijkheid tot zoomen erg belangrijk, dus voor mijn eigen project is het een onmogelijk dilemma. Maar misschien is dit voor de tweakers situatie anders.

Het is heel snel uit te proberen. Link die library in en voeg een call toe in je main javascript. Daarna zie je het effect. Ik keek mijn ogen uit toen ik het voor het eerst in aktie zag, ben benieuwd of jullie het ook willen proberen en zo ja, of het net zo goed werkt

[BtM909]

Punt is dat double tap zoom of pinch to zoom toch wel redelijk belangrijk zijn voor een touch-device. Ik snap dat je de mobiele website snappier maakt, maar die 300ms is er niet voor niets ingezet

[crisp]

Ja, ik ken fastclick (en ook het technische principe erachter). To be honest: het is een ranzige hack met nasty side-effects en met elke nieuwe generatie devices komen weer andere issues naar boven.

Wat mij betreft liever niet dus. Standaard UI-behaviour proberen te overrulen of app-like behaviour proberen te mimmicken is sowieso echt een pain-in-the-*ss. Hoe minder daarvan hoe liever; laat de browser-vendors dat maar oplossen...

[Verwijderd]

Op zich met beiden van jullie eens, toch was ik stevig onder de indruk van de performance boost. Ik heb het pas 2 dagen geleden geprobeerd dus ik ben het nog aan het evalueren. Welke issues/side effects heb je het precies over, afgezien van dat zoomen niet meer werkt?

[crisp]

Verwijderd schreef op woensdag 17 april 2013 @ 07:58:
Op zich met beiden van jullie eens, toch was ik stevig onder de indruk van de performance boost. Ik heb het pas 2 dagen geleden geprobeerd dus ik ben het nog aan het evalueren. Welke issues/side effects heb je het precies over, afgezien van dat zoomen niet meer werkt?

Tekst selecteren wat mogelijk niet meer werkt (die issue hadden we ook met hammer.js), en waarschijnlijk conflicten met andere scripts die ook touch-behaviour toevoegen. En natuurlijk de issues die genoemd zijn op https://github.com/ftlabs/fastclick/issues

Zeker op onze site zal het niet eenvoudig zijn iets dergelijks goed te implementeren. Als we het al doen dan zullen we waarschijnlijk zelf een oplossing moeten maken die goed samenwerkt met de rest van onze scripting.

[Verwijderd]

Dank voor de reactie. De issue list van Fastclicks had ik al gezien, maar aangezien ik maar een test device heb is het lastig de gevolgen te overzien. Het is en blijft een hack, maar de performance boost is zo aangenaam dat ik het moeilijk kan verkroppen om het toch uit te zetten

[BtM909]

Maar begrijp je dat het geen performance boost is, maar een workaround voor iets wat juist bedacht is om browsen werkbaar te maken op je mobiele device?

[Verwijderd]

@BtM909: Yep, dat begrijp ik, performance boost is technisch gezien niet de juiste term, maar zo voelt het wel degelijk aan.

[Misha]

Het is een stukje vlugger geworden

[JoostBaksteen]

Vandaag hebben we de animatie in het menu hersteld en met een vergelijkbare techniek als fastclick het openen van de menus een stuk sneller gemaakt.

De zij-menus (is dat een woord? ) openen en sluiten nu in ieder geval lekker vlot

[filenox]

Ik weet niet of Fastclicks iets met dit probleem te maken hebben maar als ik de knoppen van de reactiefilter gebruik als 'veegpunt'* dan denkt de browser dat ik er op heb geklikt. Hierdoor wordt de hele uitleg van "wanneer moet iets +1 zijn" etc zichtbaar gemaakt.

Ik weet dat het iets kleins is, maar toch ervaar ik het als storend aangezien ik er niet om heb gevraagd.

_{*Het punt waar ik mijn vinger fysiek op het scherm leg om een scrollbeweging te maken}

[filenox]

filenox schreef op zaterdag 01 juni 2013 @ 19:47:
Ik weet niet of Fastclicks iets met dit probleem te maken hebben maar als ik de knoppen van de reactiefilter gebruik als 'veegpunt'* dan denkt de browser dat ik er op heb geklikt. Hierdoor wordt de hele uitleg van "wanneer moet iets +1 zijn" etc zichtbaar gemaakt.

Ik weet dat het iets kleins is, maar toch ervaar ik het als storend aangezien ik er niet om heb gevraagd.

_{*Het punt waar ik mijn vinger fysiek op het scherm leg om een scrollbeweging te maken}

Ik ontdek net dat probleem zich enkel voordoet op de stock browser, in Chrome is er geen probleem.

[crisp]

We hebben geen fastclicks implementatie, dus dat kan niets met het probleem te maken hebben Het probleem is inderdaad dat sommige browser(versie)s wat sneller zijn in het triggeren van mouseover (dat doen ze feitelijk vanwege backwards compatibility) dan andere. Dat is ook een van de redenen waarom je eigenlijk geen mouseover/hover behaviour (meer) zou moeten gebruiken als het ook op touch goed moet werken of in ieder geval niet in de weg moet zitten. Helaas is dat nog niet bij iedereen van ons productteam helemaal doorgedrongen (bij Misha wel iig hoor ).

[filenox]

Haha oke, bedankt voor de verduidelijking

[Misha]

Death to the mouseover!