Advertenties op trage verbinding = mis-click

[BramVroy]

Op een trage mobiele internetverbinding worden advertentie wat later geladen dan de rest van de page, wat op zich heel goed is: onmiddellijk de content laten zien! Maar daar komt een ander probleempje bij kijken, zeker op de front page:

Ik surf naar Tweakers.net, ik zie alle content (ads nog niet ingeladen; screenshot al van even terug). Dat ziet er dan zo uit.

Een mens leest heel snel, zeker titels. Ik zie de content, en denk "oh, dat over die ZenPad wil ik wel lezen!", en juist als ik ga tikken op m'n scherm wordt de advertentie ineens weergegeven.

Resultaat: ik tik ongewenst op de advertentie. Leuk voor jullie, dat zijn weer extra inkomsten maar qua usability niet zo super.

Een oplossing is misschien de ruimte al vullen met een placeholder of opvullen met pure CSS?

[ Voor 8% gewijzigd door BramVroy op 05-12-2015 19:52 ]

[crisp]

Je bent niet de eerste die dit vraagt. Het probleem is dat we vantevoren niet weten of er een banner wordt geladen, en ook niet hoe groot die is. Je zit dus hoe dan ook met een verspringing van de content. We zijn momenteel wel aan het kijken of we het inladen van banners kunnen versnellen (zonder dat dat ten koste gaat van het laden van de content), maar helemaal oplossen kunnen we het niet...

[.oisyn]

Een alternatief zou zijn om even geen clicks te accepteren nadat de banner is geladen, zodat je niet per ongeluk misklikt. Het is bij mij ook een grote ergenis, maar je ziet het helaas overal.

[crisp]

.oisyn schreef op zaterdag 05 december 2015 @ 22:05:
Een alternatief zou zijn om even geen clicks te accepteren nadat de banner is geladen, zodat je niet per ongeluk misklikt. Het is bij mij ook een grote ergenis, maar je ziet het helaas overal.

En dan heb je een trage bannerhoster en is de hele site unresponsive voor tientallen seconden. Of je blocked banners waardoor onze code nooit de 'banners complete' melding krijgt en je helemaal nooit meer ergens op kan klikken...

Nee, dat soort truukjes lijken mij geen goed idee

[MarElo]

not done

[ Voor 93% gewijzigd door MarElo op 07-12-2015 18:45 ]

[.oisyn]

crisp schreef op zaterdag 05 december 2015 @ 22:30:
[...]

En dan heb je een trage bannerhoster en is de hele site unresponsive voor tientallen seconden. Of je blocked banners waardoor onze code nooit de 'banners complete' melding krijgt en je helemaal nooit meer ergens op kan klikken...

Nee, dat soort truukjes lijken mij geen goed idee

Ik zei nadat de banners zijn geladen. Dus dat je een halve seconde ofzo vanaf het inpoppen van de banner niets kunt doen.

[NMe]

.oisyn schreef op zondag 06 december 2015 @ 00:26:
[...]

Ik zei nadat de banners zijn geladen. Dus dat je een halve seconde ofzo vanaf het inpoppen van de banner niets kunt doen.

Even 1 seconde lang pointer-events: none op de container van de banner gooien zou inderdaad vast al een boel helpen. Dan zit je alleen nog met Flash-banners maar daar kun je niet veel aan doen denk ik.

[Dorus]

Eigenlijk zou je alle bewegende content .2-.4 seconden willen blokkeren. Alleen als het beweegt door inladende content dan. Verbaast me dat browsers daar nog steeds geen standaart optie voor hebben.

[crisp]

.oisyn schreef op zondag 06 december 2015 @ 00:26:
[...]


Ik zei nadat de banners zijn geladen. Dus dat je een halve seconde ofzo vanaf het inpoppen van de banner niets kunt doen.

Ah so. Ik zal eens kijken of dat kan. In onze huidige set-up lijkt me dat geen probleem, maar we zijn bezig met onderzoek naar de asynchrone versie van bannertags, en daar zijn we dan volledig afhankelijk van een callback vanuit de API...

[NMe]

Dorus schreef op zondag 06 december 2015 @ 09:31:
Eigenlijk zou je alle bewegende content .2-.4 seconden willen blokkeren. Alleen als het beweegt door inladende content dan. Verbaast me dat browsers daar nog steeds geen standaart optie voor hebben.

Omdat wat je zegt nogal lastig is om te controleren omdat de definitie van "inladende content" redelijk fuzzy is. Als ik een javascript-game maak à la whack-a-mole dan zou het niet heel handig zijn als je een tijd lang niet op de (eerste?) mol kan klikken omdat die op dat moment voor het eerst ingeladen wordt. Er gaat altijd wel een usecase zijn waarin je veel mensen gaat vervelen met zo'n automatische optie. Dat kun je IMO veel beter aan site-beheerders overlaten.

[Dorus]

Ik bedoelde natuurlijk als css optie. Dat zou in heel veel gevallen handig zijn.

'if content moves, no click for .5 sec.'

[NMe]

Dorus schreef op zondag 06 december 2015 @ 12:28:
Ik bedoelde natuurlijk als css optie. Dat zou in heel veel gevallen handig zijn.

'if content moves, no click for .5 sec.'

Daar is het al een optie in, pointer-events. Als je dat voor een bepaalde periode wil in plaats van permanent dan kost dat twee regels javascript. Ik denk niet dat browsermakers interesse hebben om dat korter te maken dan dat.

[Ramon]

Ik heb hier ook regelmatig last van. Gewoon altijd de witruimte reserveren voor de advertentie, is dat geen optie? Voor mij zou het kleine beetje extra scrollen veel minder erg zijn dan het verspringen van de pagina. Op mijn telefoon heb ik soms wel dat ik 3x achter elkaar misklik, omdat het lijkt alsof de pagina al klaar is met laden.

[Dorus]

Daarmee kun je het klikken uitschakelen, maar kun je ook de detectie op beweging doen? Zo kan het best dat als er een advertentie in het midden laad, de bovenkant van de pagina niet hoeft te worden geblokkeerd. Of dat alles een pixel verschuift, dan hoeft alleen maar een randje van een pixel van alle bewegende onderdelen geblokkeerd te worden.

(ik doel dus op een optie om alle bewegende content tijdelijk even uit te schakelen. Niet alleen de add. Zo is het ook irritant als je een artikel aan klikt en er ineens een andere onder je muis zit. Gebeurt mij als abo niet op tweakers, wel op andere sites, of js spellen. Die optie is er voor zover ik weet niet, tenzij je zelf de logica toevoegt die bedenkt welke onderdelen bewegen. )

[ Voor 36% gewijzigd door Dorus op 06-12-2015 12:59 ]

[Hero of Time]

Ramon schreef op zondag 06 december 2015 @ 12:55:
Ik heb hier ook regelmatig last van. Gewoon altijd de witruimte reserveren voor de advertentie, is dat geen optie? Voor mij zou het kleine beetje extra scrollen veel minder erg zijn dan het verspringen van de pagina. Op mijn telefoon heb ik soms wel dat ik 3x achter elkaar misklik, omdat het lijkt alsof de pagina al klaar is met laden.

Banners variëren van hoogte, dus dat is nou niet echt ideaal. De ene keer heb je een banner van nog geen 50 pixels hoog, de andere keer 100. Ik moet er niet aan denken dat ik elke keer 100 pixels aan hoogte ga missen. Enig idee hoeveel artikelen dat zijn bij 'compact'? Er werd al geklaagd over informatiedichtheid en dat is bij de eerste pageview met een enorme banner al minimaal, met wat geluk heb je dan net 3 artikelen. Dat gaat dus niet gebeuren, tenzij je wilt dat Tweakers gebruikers wegjaagt.
Daarbij, een leeg stuk van 100 pixels is echt super lelijk. Als er geen banners geladen wordt vraag je je af wat er hoort te staan en of er iets mis is met je computer en whatnot.

[crisp]

De 'topbanner' varieert in hoogte van 60 tot 250 pixels...

[Ramon]

Ah dat was ik even vergeten Op mijn tel heb ik het idee dat ik meestal toch kleine banners zie, en daar is wat mij betreft het probleem het grootst.

of natuurlijk de navigatieknoppen boven de banners zetten, heb je het ook opgelost.

[BramVroy]

Hero of Time schreef op zondag 06 december 2015 @ 13:13:
[...]

Daarbij, een leeg stuk van 100 pixels is echt super lelijk. Als er geen banners geladen wordt vraag je je af wat er hoort te staan en of er iets mis is met je computer en whatnot.

Daar ben ik het niet mee eens. Het probleem ter sprake komt eigenlijk enkel bij trage verbindingen voor, dat is een eerste punt. Ten tweede kan je (als je je toch afvraagt wat er mist of gaat) even naar je browser kijken en dan zie je dat de pagina "nog ingeladen wordt" (door een laadicoontje, of in Android door de horizontale progress bar). Dan is het wel duidelijk dat er nog iets zit aan te komen, en hoef je je geen zorgen te maken en surf je gerust verder.

[NMe]

BramVroy schreef op zondag 06 december 2015 @ 15:19:
[...]

Daar ben ik het niet mee eens. Het probleem ter sprake komt eigenlijk enkel bij trage verbindingen voor, dat is een eerste punt. Ten tweede kan je (als je je toch afvraagt wat er mist of gaat) even naar je browser kijken en dan zie je dat de pagina "nog ingeladen wordt" (door een laadicoontje, of in Android door de horizontale progress bar). Dan is het wel duidelijk dat er nog iets zit aan te komen, en hoef je je geen zorgen te maken en surf je gerust verder.

Het komt zeker niet alleen bij trage verbindingen voor en zoals gezegd weet je niet hoeveel ruimte er nodig is, en óf er überhaupt ruimte nodig is. Crisp zegt hierboven dat banners, áls ze al aanwezig zijn, op die positie kunnen variëren van 60 pixel hoog tot 250 pixels hoog. Je moet dan altijd 250 pixels bezet houden. Zelfs op moderne mobiele telefoons is dat een vierde van je scherm! Dat is erg zuur als er vervolgens überhaupt geen banner in geserveerd wordt, of slechts een kleintje van 60 pixels. Dan kun je het er niet mee eens zijn dat dat raar uitziet of verwarrend is, ik durf wel te stellen dat je daar een van de weinigen in bent.

[crisp]

Op mobiel (grade D) varieert het tussen 50 en 100 op de toppositie, dat dan wel

[NMe]

crisp schreef op zondag 06 december 2015 @ 16:39:
Op mobiel (grade D) varieert het tussen 50 en 100 op de toppositie, dat dan wel

Op desktops met een HD-scherm is het ook eenvierde.

[Hero of Time]

BramVroy schreef op zondag 06 december 2015 @ 15:19:
[...]

Daar ben ik het niet mee eens. Het probleem ter sprake komt eigenlijk enkel bij trage verbindingen voor, dat is een eerste punt. Ten tweede kan je (als je je toch afvraagt wat er mist of gaat) even naar je browser kijken en dan zie je dat de pagina "nog ingeladen wordt" (door een laadicoontje, of in Android door de horizontale progress bar). Dan is het wel duidelijk dat er nog iets zit aan te komen, en hoef je je geen zorgen te maken en surf je gerust verder.

En als je geen banner krijgt geserveerd, dan zit je met een leeg vak dat geen moer doet. Daar gaat het om. Trage verbinding of niet, zoals NMe al zei, je zit met een groot deel van je scherm waar niets staat. Compleet verspeelde ruimte.

Even als idee, open eens www.ns.nl op je desktop. In de vorige versie had je direct de reisplanner in zicht aan de rechterkant, evenals informatie over storingen. Nu krijg je een mega fotowall te zien. Maak die eens voor de gein blanco. Wat heb je dan? Precies, bijna je hele scherm met niets, geen informatie of wat dan ook. Doe hetzelfde met de Tweakers frontpage door 250 pixels te reserveren boven en je krijgt met wat geluk 1 hele regel van de artikelen.

[Richh]

50 tot 100 pixels? Dan reserveer je 100 pixels, en in case van 50px hou je boven en onder een padding van 25px aan. Tot die tijd staat er de tekst 'banner loading'

Floating banners over de content maak ik waarschijnlijk ook niemand blij mee

_{Wat ben ik toch blij met mijn Tweakers-abo. Voor een site die ik zo veel bezoek totally worth it}

[Migrator]

En dan zit je, als er geen banner geladen wordt (want zoals crisp al zo vaak heeft aangegeven: dat is van tevoren niet bekend) weer met een vlak van 100px. De oplossing van ruimte reserveren is geen oplossing.

[Verwijderd]

-

[ Voor 100% gewijzigd door Verwijderd op 05-06-2016 09:45 ]

[Hero of Time]

Verwijderd schreef op zondag 06 december 2015 @ 21:06:
Ik block gewoon de ads....niet via een adblocker...want daar heeft Tweakers bezwaren tegen. Mijn router blocked servers van nagenoeg alle ad networks uit het oogpunt van veiligheid.

Dat geef hetzelfde probleem als het gebruik van een adblocker.

Richh schreef op zondag 06 december 2015 @ 19:45:
50 tot 100 pixels? Dan reserveer je 100 pixels, en in case van 50px hou je boven en onder een padding van 25px aan. Tot die tijd staat er de tekst 'banner loading'

Floating banners over de content maak ik waarschijnlijk ook niemand blij mee

_{Wat ben ik toch blij met mijn Tweakers-abo. Voor een site die ik zo veel bezoek totally worth it}

Volgens mij heb je het topic niet volledig gelezen, of wel?

[Verwijderd]

-

[ Voor 100% gewijzigd door Verwijderd op 05-06-2016 09:44 ]

[Migrator]

Verwijderd schreef op zondag 06 december 2015 @ 21:21:
[...]


Ja, ik weet dat dat voor Tweakers hetzelfde probleem geeft. Voor mij is het een verademing. Tevens moeten bedrijven, en dus ook Tweakers eens wat creatiever worden in het verdienen van Euros. Ik werk niet aan het huidige systeem mee. Advertenties zijn goedkoop, intrusive op de privacy en wekken ergernissen op. Soms zijn ze zelfs ook gewoon gevaarlijk.

Ik heb inderdaad niet het hele topic gelezen. Excuses

offtopic:
Maar zou je niet beter in een topic als [Discussie] Reclame algemeen over dit soort dingen praten in plaats van een bugreport te kapen?
Bovendien weet Tweakers echt wel dat ads vervelend zijn etc. Het is vooral dat er geen alternatief is.

[Zeeuw]

Misschien is het een idee om de banners te laden onder de nog niet gelezen content?

Bij je allereerste bezoek staan dan de banners bovenaan. Als je na een uur weer op Tweakers komt is de banner een paar plaatsen gezakt met daarboven de nieuwe content.

Voorbeeld
Eerste inlog 0800u:
-- Banner --
Artikel A
Artikel B
Artikel C

Tweede inlog 1300u:
Artikel D
Artikel E
Artikel F
-- Banner --
Artikel A
Artikel B
Artikel C

Derde inlog 1400u:
Artikel G
-- Banner --
Artikel D
Artikel E
Artikel F
Artikel A
Artikel B
Artikel C

Uiteraard met een maximum aantal artikelen zodat de banner toch vrijwel zeker in eerste oogopslag te zien is.
Na bijvoorbeeld 24u niet op Tweakers geweest te zijn begint de banner weer bovenaan.

Je hebt toch vaak bij snelle kliks dat het nieuwe content is dus als de banner dan iets vertraagd inlaadt, dan verspringt alleen de content die je waarschijnlijk toch al gelezen hebt.

[Ramon]

Hero of Time schreef op zondag 06 december 2015 @ 16:48:
[...]

En als je geen banner krijgt geserveerd, dan zit je met een leeg vak dat geen moer doet. Daar gaat het om. Trage verbinding of niet, zoals NMe al zei, je zit met een groot deel van je scherm waar niets staat. Compleet verspeelde ruimte.

Volgens mij gaat het niet om lege ruimte maar om misclicken door het verspringen van de menu-items.

Dat los je dus wel op door lege ruimte te laten staan.

Maar nog maals, als je gewoon het menu boven de advertenties zet heb je het opgelost. Makkelijker kan haast niet.

Verwijderd schreef op zondag 06 december 2015 @ 21:06:
Ik block gewoon de ads....niet via een adblocker...want daar heeft Tweakers bezwaren tegen. Mijn router blocked servers van nagenoeg alle ad networks uit het oogpunt van veiligheid.

Maar dat is geen oplossing voor dit probleem tenzij je alleen thuis op je telefoon surft.

[ Voor 23% gewijzigd door Ramon op 06-12-2015 22:53 ]

[klaaz]

Ik vind dat gestuiter door adds ook bloedirritant. Op zich valt het bij Tweakers wel mee omdat de website erg snel is. Op andere sites en fora gaat het een stukje trager en dus wel vaak mis. Met een 500mbit verbinding!

Op mijn iPad Air 2 is het irritatieniveau het hoogst in die gevallen. PC is nog wel te doen.

[Verwijderd]

-

[ Voor 99% gewijzigd door Verwijderd op 05-06-2016 09:44 ]

[Hero of Time]

Zeeuw schreef op zondag 06 december 2015 @ 22:45:
Misschien is het een idee om de banners te laden onder de nog niet gelezen content?

Bij je allereerste bezoek staan dan de banners bovenaan. Als je na een uur weer op Tweakers komt is de banner een paar plaatsen gezakt met daarboven de nieuwe content.

[knip]

Uiteraard met een maximum aantal artikelen zodat de banner toch vrijwel zeker in eerste oogopslag te zien is.
Na bijvoorbeeld 24u niet op Tweakers geweest te zijn begint de banner weer bovenaan.

Je hebt toch vaak bij snelle kliks dat het nieuwe content is dus als de banner dan iets vertraagd inlaadt, dan verspringt alleen de content die je waarschijnlijk toch al gelezen hebt.

Dat lost het initiële probleem niet op, net als het probleem op het forum. Als je in jouw voorbeeld artikel B nog eens wilt lezen, heb je dus alsnog de kans dat je misklikt.

Ramon schreef op zondag 06 december 2015 @ 22:52:
[...]
Volgens mij gaat het niet om lege ruimte maar om misclicken door het verspringen van de menu-items.

Dat los je dus wel op door lege ruimte te laten staan.

Klopt, maar zoals hier in dit topic voor die 'oplossing' meerdere keren is uitgelegd, je gaat enorme lege vlakken maken waardoor je informatie een hele pagina omlaag duwt zonder specifieke reden.

Maar nog maals, als je gewoon het menu boven de advertenties zet heb je het opgelost. Makkelijker kan haast niet.

Welk menu? De rode menubalk bovenaan is altijd zichtbaar en verplaatst niet als er alsnog een banner wordt weergegeven.

[Zeeuw]

Hero of Time schreef op zondag 06 december 2015 @ 23:52:
[...]

Dat lost het initiële probleem niet op, net als het probleem op het forum. Als je in jouw voorbeeld artikel B nog eens wilt lezen, heb je dus alsnog de kans dat je misklikt.

Niet helemaal mee eens, je focust eerst op de nieuwe artikelen. Dit kost toch enkele ms, misschien net genoeg om de banner te laden. Je kunt dan, afhankelijk van het aantal nieuwe artikelen bijvoorbeeld nog 2 artikelen van de vorige sessie boven de banner plaatsen. Dit kost je hersenen ook weer een aantal ms om te zoeken.

Zoals elke banner niet even snel laadt, zal ook niet elke gebruiker binnen 5ms het juiste artikel aan kunnen klikken.

[Hero of Time]

Zeeuw schreef op maandag 07 december 2015 @ 00:03:
[...]


Niet helemaal mee eens, je focust eerst op de nieuwe artikelen. Dit kost toch enkele ms, misschien net genoeg om de banner te laden. Je kunt dan, afhankelijk van het aantal nieuwe artikelen bijvoorbeeld nog 2 artikelen van de vorige sessie boven de banner plaatsen. Dit kost je hersenen ook weer een aantal ms om te zoeken.

Zoals elke banner niet even snel laadt, zal ook niet elke gebruiker binnen 5ms het juiste artikel aan kunnen klikken.

Zoals ik al zei, je verschuift het probleem alleen maar, het wordt niet opgelost.

[NMe]

Misschien moeten we eerst even wachten wat crisp en co. kunnen doen met de suggestie van .oisyn? Dat het irritant is weten we allemaal, daar hoef je geen bericht aan te wijden.

Zeeuw schreef op maandag 07 december 2015 @ 00:03:
[...]

Niet helemaal mee eens, je focust eerst op de nieuwe artikelen. Dit kost toch enkele ms, misschien net genoeg om de banner te laden. Je kunt dan, afhankelijk van het aantal nieuwe artikelen bijvoorbeeld nog 2 artikelen van de vorige sessie boven de banner plaatsen. Dit kost je hersenen ook weer een aantal ms om te zoeken.

Banners tussen de content door wordt door de meeste mensen als vervelend ervaren en dat zou ik dus zo veel mogelijk beperken. Bovendien betalen adverteerders voor een bepaalde positie, en het zou zomaar kunnen dat ze minder willen betalen als die positie continu verschuift. Dan zijn er weer meer ads nodig om hetzelfde bedrag binnen te halen.

Zoals elke banner niet even snel laadt, zal ook niet elke gebruiker binnen 5ms het juiste artikel aan kunnen klikken.

Het probleem is ook niet dat elke gebruiker het altijd doet, maar dat sommige gebruikers soms misklikken. Dat los je niet op door de banner steeds op een andere plek te zetten, je maakt alleen de layout rommeliger en de positie waar je al dan niet het risico loopt fout te klikken minder voorspelbaar.

[Ramon]

Ik heb sinds een week ofzo dat ik soms niet op het menu kan klikken bovenaan de pagina op mijn Lumia 640. Is dat vanwege een fix die hiervoor gedaan is?

[NMe]

Lijkt me sterk. Ik heb hetzelfde al een tijdje af en toe op mijn Lumia 930, ook op andere sites. Lijkt een bug in de mobiele browser.

[Dorus]

Ik vraag mij toch af of het niet mogelijk is de banners in twee stappen op te vragen. Eerst een request waar de afmetingen en locatie opgevraagd worden, die binnen 0.2 seconden beantwoord moet worden, en dan de echte banner laden.

Natuurlijk vereist dat enige medewerking vanuit de adverteerders. Zal wel enkele maanden of kwartalen kunnen duren voordat ze zoiets überhaupt voor je willen maken, maar het zou wel de problemen oplossen.

[crisp]

Dorus schreef op zondag 20 december 2015 @ 11:49:
Ik vraag mij toch af of het niet mogelijk is de banners in twee stappen op te vragen. Eerst een request waar de afmetingen en locatie opgevraagd worden, die binnen 0.2 seconden beantwoord moet worden, en dan de echte banner laden.

Natuurlijk vereist dat enige medewerking vanuit de adverteerders. Zal wel enkele maanden of kwartalen kunnen duren voordat ze zoiets überhaupt voor je willen maken, maar het zou wel de problemen oplossen.

Wat je schetst gebeurd al grotendeels. De enige winst die daar nog te halen is om de eerste request asynchroon vanuit de <head>-sectie te laden in plaats van aan het eind van de <body>.