Tweakers' frontpage-A/B-tests - Wat hebben we geleerd en hoe gaan we verder?

Rond maandag 13 september heeft een grootschalige A/B-test plaatsgevonden op de Tweakers-frontpage, waarbij een deel van de bezoekers versie A van de frontpage te zien kreeg en het andere deel versie B. Deze test draaide ongeveer dertig uur en hierop kwam veel feedback in het bijbehorende topic: op het design, de testmethode en de communicatie. In deze .plan willen we jullie informeren over wat we willen bereiken, wat we geleerd hebben van de test, wat we hebben gedaan met jullie feedback, wat de vervolgstappen zijn en hoe we dit in de toekomst beter willen doen.

Het doel

De huidige frontendset-up van Tweakers is verouderd en moet toekomstvast gemaakt worden. De frontend die we voor ogen hebben, vormt een moderne, op componenten gebaseerde interface, die de ontwikkeling van nieuwe functies versnelt en verschillende thema’s mogelijk maakt. Deze vernieuwing kunnen we op twee manieren aanpakken:

1. meer dan drie jaar achter de schermen werken om Tweakers helemaal aan te passen aan de nieuwe frontendset-up;
2. beginnen met een gedeelte van de website en de wijzigingen geleidelijk uitrollen.

We hebben ervoor gekozen om te beginnen met een gedeelte van de website. Zo kunnen we de website stapsgewijs aanpassen aan een nieuwe lay-out en de opgedane kennis meenemen naar het volgende deel. Als startonderdeel hebben we de frontpage van Tweakers gekozen; daar willen we de ervaring op een aantal gebieden verbeteren. Het belangrijkste is dat we van de frontpage het best mogelijke toegangspunt voor de verschillende onderdelen van Tweakers maken. Deze pagina heeft het grootste bereik en is de ‘etalage’ voor de andere onderdelen van de website. Daarnaast is er, na de uitbreiding van de reviewredactie vorig jaar september en met de komst van Tweakers Plus, meer uitgebreide content. Deze content willen we beter zichtbaar maken voor de eindgebruiker. De huidige frontpage biedt weinig mogelijkheden om deze artikelen uit te lichten.

De route tot de A/B-test

In december 2020 zijn we begonnen met kleine designverbeteringen om te kijken of we meer uitgelichte artikelen bovenaan de frontpage konden krijgen en later ook of we dit konden combineren met nieuwsberichten bovenin.

We constateerden dat, terwijl we het ene probleem aan het oplossen waren, tegelijk nieuwe problemen creëerden. Terwijl het verkeer naar de ankeilerartikelen toenam ('ankeiler' is de term voor een artikelaankondiging met een afbeelding, zoals voor een review of een achtergrondartikel), zagen we een daling in het algehele gebruik van de voorpagina, vooral als het ging om verkeer naar nieuws. Dit was aanleiding om te beginnen met een meer omvattende verandering, een facelift van de frontpage. Met deze uitdagingen zijn we in januari begonnen de wensen te verwerken in een nieuw ontwerp. Dit ontwerp hebben we met een usabilitytest voorgelegd aan een panel frontpagegebruikers, waarna we de verkregen inzichten en feedback hebben verwerkt in vier verschillende ontwerpen.

Wat is een usabilitytest?

Tijdens een usabilitytest wordt een prototype voorgelegd aan de doelgroep. De gebruiker krijgt een scenario en loopt daarmee door het prototype heen. Bij het doorlopen moet de gebruiker hardop denken en zijn gedachten delen. Hierdoor wordt duidelijk of bepaalde functionaliteiten wel of niet werken.

Deze vier varianten hebben we eind maart via een voorkeurstest voorgelegd aan onze gebruikers. Bij deze test kon iedereen aangeven welk van de vier ontwerpen hij of zij prefereerde en waarom. Twee varianten wonnen met een flinke meerderheid. Deze zijn verder verbeterd aan de hand van de gegeven reacties in de voorkeurstest en de .plan waarin dit was aangekondigd. Daaropvolgend is het developmentteam aan de slag gegaan met het daadwerkelijk bouwen van de twee winnende ontwerpen. Het was een flinke klus om de frontpage elementair op te zetten in een nieuw gridlay-out.

De A/B-test

Na het ontwikkelen van de beide winnaars en het oplossen van de ‘kinderziektes’ was het tijd om de A/B-test live te zetten en de kwalitatieve en kwantitatieve feedback te verzamelen. Het is, naast het horen van de mening van een groep over het design, belangrijk om het gedrag erbij mee te wegen, gebruikers kunnen zich immers anders gedragen dan ze tijdens het gebruik denken te doen. We hadden ons voorgenomen om deze test minimaal drie weken te laten draaien, zodat iedereen eraan kon wennen en we geen seizoensgebonden invloed zouden ervaren. Vanwege te grote verschillen in wat we wilden bereiken, wat we verwachtten en wat we zagen in de test, hebben we besloten om de test te stoppen, de feedback te verzamelen en te verwerken, en een nieuw testplan te maken.

Tijdens de test is veel kwalitatieve en kwantitatieve feedback binnengekomen. Van deze feedback hebben we dankbaar gebruikgemaakt en we hebben hem gebundeld rond de volgende onderwerpen: ontwerp, testmethodiek en communicatie. Deze onderwerpen bespreken we hieronder.

Ontwerp

Feedback op het ontwerp gaat in bijna alle gevallen van links naar rechts. Het is natuurlijk grotendeels een kwestie van smaak en smaken verschillen. Daarbij komt dat de frontpage dagelijks veel gebruikers heeft. Omdat het onbegonnen werk is om een ontwerp te maken dat aan de wensen van al die gebruikers voldoet, zoeken we naar een goede balans voor deze pagina. Tijdens de test zagen we op bepaalde onderdelen veel feedback binnenkomen, waaronder:

• De informatiedichtheid is lager dan bij de huidige frontpage.
• De letters van de nieuwsitems zijn te groot.
• Het openklappen van de tracker heeft tot gevolg dat de frontpage slechts deels zichtbaar is; de rest verdwijnt achter een scroll.

We hebben deze aandachtspunten verwerkt in een nieuwe versie van de frontpage. Hieronder is een kleine sneakpreview te zien van het nieuwe ontwerp op basis van de feedback die tijdens de test is opgedaan.

Origineel (links) en beta variant (rechts)

In de sneakpreview is te zien dat de nieuwslijst hoger op de pagina staat. Waar we op de huidige frontpage maar drie nieuwsartikelen krijgen, zijn dat er in het nieuwe ontwerp vijf. Ook is het aantal uitgelichte posities opgehoogd van één naar vier. De informatiedichtheid is dus toegenomen.

Testmethodiek

Na afloop van de A/B-test hebben we in het productteam, bestaande uit product owners en user experience designers, gesproken over de testmethoden en jullie feedback op de test verwerkt. De feedback kan in onderstaande vier hoofdpunten worden samengevat.

Er zaten veel bugs in de varianten. In aanloop naar de livegang van de A/B-test hebben we met een intern groepje de varianten getest op bugs. Die groep was, helaas, niet groot genoeg om verschillende edge cases te ontdekken. Hierop hebben we besloten om vanaf heden, voorafgaand aan grote lay-outwijzigingen alfatests te gaan houden. Bij deze testsoort volgen we het principe ‘eat your own dogfood’. Dit houdt in dat we het design zelf bedrijfsbreed (Tweakers HQ en crew) testen voordat we het aan de gebruikers voorschotelen. Door het bedrijfsbreed te gaan testen hebben we een grote variatie in omstandigheden: collega’s die met een 1080p-scherm werken, onderweg in de trein op mobiel zitten of redactieleden die een 4k-monitor aan het testen zijn.

Als tweede hoofdpunt is er de wens voor een opt-out bij A/B-tests. In het feedbacktopic zagen we feedback binnenstromen over de verplichte deelname aan A/B-tests. A/B-tests ontlenen hun kracht aan een willekeurige selectie van een zo groot mogelijk aantal deelnemers. Met deze ingrediënten kunnen we ieders ‘ervaring’ meenemen in de analyse en de uiteindelijke keuze voor een winnaar. De bedoeling van een test is ervan te leren en het design aan te passen aan degenen die het gebruiken. Tests met alleen bezoekers die enthousiast worden van tests en daarna de keuze vastleggen, geven een vertekend beeld en resulteren sneller in ‘rooskleurige resultaten’. Zonder de brede A/B-test onder alle bezoekers hadden we de huidige feedback niet gehad. Daarom blijven we bij ons uitgangspunt om A/B-tests niet optioneel te maken. Wel waren we het erover eens dat voor een frontpagewijziging intern testen direct gevolgd door een A/B-test niet genoeg is. Deze ontwerpverbeteringen willen we eerst aan jullie voorleggen via een publieke opt-in-bètatest.

Het derde hoofdpunt betreft de bètatest. Die begint zodra de alfatest is afgerond. We zullen deze test zoveel mogelijk onder de aandacht brengen om een zo groot mogelijke samplesize te krijgen. Als zoveel mogelijk gebruikers hun mening kunnen geven over de frontpage, wordt voor ons het beeld duidelijker. Toegang tot de bèta kun je krijgen door het aan te zetten in je profielinstellingen. Tijdens de bètatest zullen we het ontwerp bijschaven en als de variant grote gebreken heeft, waar we niet van uitgaan vanwege de alfatest, kan hij weer uitgezet worden. Doordat de deelname aan de bètatest in je profiel is opgeslagen, kun je op elk apparaat meehelpen. Zolang je bent ingelogd, kun je met elk device testen.

Het vierde hoofdpunt betreft de te radicale verandering tussen varianten. Tijdens de bètatest zal duidelijk worden hoe goed het ontwerp aansluit bij de wensen van de gebruikers. Tegen die tijd besluiten we of we het design nog met A/B-tests gaan valideren bij de community en wat de aanpak zal zijn. We nemen ons voor om de tests in kleine stukjes op te hakken om de impact van elke wijziging te kunnen meten. Dit zal een uitdaging zijn, omdat alleen het verbreden van de gridlay-out niet los te testen is. Maar die uitdaging gaan we aan.

Communicatie

Wat de communicatie betreft was er één punt van feedback en dat is, in onze ogen, meer een algemeen punt dan voor de frontpage alleen, namelijk: jullie willen op de hoogte gehouden worden van komende grote wijzigingen.

Wij bedanken iedereen voor de gegeven feedback en vertrouwen erop met de nieuwe opzet en communicatie op de goede weg te zijn. Voor de vervolgstappen, de bètatest en A/B-tests, is het belangrijk om op een constructieve manier met elkaar in gesprek te blijven. Dat doen we door actief te reageren en modereren in het forumtopic en in de reacties op de .plans die verschijnen bij het starten van de bètatest. Door de mogelijkheid van de opt-in-bètatests kunnen we jullie eerder en actiever betrekken bij het designproces. Op deze manier kunnen we ook de communicatie onderling versterken. Waar relevant gaan we dit in het vervolg doen.

Er is nog geen releasedatum bekend waarop de bètatest van start gaat. Als je een seintje wilt ontvangen als de test live gaat, kun je je aanmelden via de poll hieronder of stel je dit in via je profielinstellingen.

Wil je een seintje krijgen als de bètatest begint?

Poll

Ja graag!
Nee, dank je.

De opties zijn uitgeschakeld omdat de deelname gesloten is

Wil je een seintje krijgen als de bètatest begint?

Poll

Ja graag!
Nee, dank je.

De opties zijn uitgeschakeld omdat de deelname gesloten is

Aantal stemmen: 2.004. Deelname gesloten op 31-01-2022 18:00. Stemmen is niet meer mogelijk.

Reacties (138)

[Freeaqingme]

Hoe wordt er in de A/B-tests omgegaan met mensen die custom CSS gebruiken?

We nemen ons voor om de tests in kleine stukjes op te hakken om de impact van elke wijziging te kunnen meten

Maar nu heb je 1 grote verandering gepland, en ga je dat testen in kleine stukjes. Waarom niet ook de veranderingen in kleine stukjes bedenken, testen, en doorvoeren?

[watcher46]

Wat betreft custom CSS kunnen wij hier geen rekening mee houden. Simpelweg omdat we geen controle hebben over de customCSS. Iedereen heeft weer andere selectors er in staan, hier kan je dus onmogelijk rekening mee houden.
Daarom heb je straks voor de bètatest een opt-in mogelijkheid, zodat je kan checken of het werkt met je eigen custom CSS.

Om onze frontend moderner te maken zullen we ook het frame (navigatie, content en footer) mobile-first moeten gaan maken. Dit is niet te combineren met de desktop-first methodiek die nu geldt voor alle pagina's.
Er zal dus een moment komen waarop we dat moeten switchen, en dat is inderdaad geen "klein stukje".

[jmxd]

Neem aan dat dark mode er ook aan zit te komen? Beetje genant voor een site als Tweakers om dit nog steeds niet te bieden

[watcher46]

Zeker, klein tipje van de sluier; we zijn bezig om een design-system op te stellen, waarbij we theme-based de css gaan schrijven dmv custom css properties. Maar ook een component library waarbij we gebruik maken van die css properties.
Dit zal het straks mogelijk moeten maken om eenvoudig extra thema's te kunnen maken.. met onder andere de zo-veel-gevraagde darkmode. Mijn handen jeuken
Dit zal overigens (in mijn ogen) ook de custom CSS wat minder belangrijk maken, in ieder geval op dit vlak.

[ZakKa.dev]

Welke stack gebruiken jullie voor de component lib?

[watcher46]

We zitten nog in de research fase, op dit moment hebben we StorybookJS voor ogen.
Welk framework, of überhaupt een framework gebruiken, staat nog ter discussie.

[dec0de]

Kunnen jullie er alsjeblieft voor zorgen dat de website zonder JavaScript bruikbaar blijft? Al die JavaScript heavy sites werken voor geen poep op een 4+ jaar oude telefoon.

[NHLGMD]

In IE6 tijd kon je dat soort dingen vragen , maar tegenwoordig is dat niet meer realistisch aangezien elke populair front-end framework volledig is gebaseerd op JavaScript. Mijn Nexus 6p draait nog redelijk de zware sites. Was je telefoon wellicht een budget telefoon?

[dec0de]

Met werken bedoel ik zegmaar dat je niet eerst 10 minuten moet wachten tot alle JS is ingeladen om gewoon de tekst uit het artikel te lezen.

Ik bedoel niet dat de hele site zonder JS 100% werkt, maar wel dat hij te *gebruiken* is zonder, bijv: filters in de pricewatch hoeven niet zonder JS te werken, maar de frontpage en de zoekfunctie wel

[Reactie gewijzigd door dec0de op 24 juli 2024 11:42]

[WernerL]

ReactJS ondersteund serverside rendering wat betekend dat je nog steeds statische content kunt serveren als je dat zou willen. Verder is het ook gewoon een kwestie van goed geoptimaliseerde code schrijven, en dat is iets wat helaas niet altijd gebeurd met trage bagger apps als gevolg.

Storybook kan ik overigens absoluut aanbevelen als je richting een component library gaat werken.

[Reactie gewijzigd door WernerL op 24 juli 2024 11:42]

[NHLGMD]

Serverside rendering wil toch niet zeggen dat je geen JavaScript calls hebt?

[MsG]

Kijk daarin ook naar de lange termijn, zou ik adviseren. Het niet gebruiken van een framework kan al gauw namelijk een van de redenen van hoge technical debt zijn of worden. Gecombineerd met een beetje Not Invented Here-syndroom kan je al gauw krijgen dat je achter de feiten aanblijft lopen.

[watcher46]

Dat doen we zeker, een reden om geen framework te gebruiken is dat de frontpage altijd veel traffic heeft. Als je dan een FE-framework hieraan toevoegt krijgt ansich niet echt een performance hit, maar met zo veel traffic kan dat toch wel het verschil maken.
We overwegen ook de optie om Web Components gebruiken. (Niet polymer van google, maar de techniek) Hiermee kunnen we alsnog componenten bouwen en de boel toch performant houden.
Maar bijvoorbeeld de pricewatch zou je toch graag meer dynamiek willen hebben en het wiel niet opnieuw willen uitvinden. Daar zou een FE-framework zeker meerwaarde bieden, waarbij dynamiek (lees: filters voor product- en prijslijsten) veel belangrijker is.

Kortom, we hebben dat zeker in het snotje

[ZakKa.dev]

Dat zijn altijd leuke discussies hehe. Succes ermee.

[bwerg]

Dit zal overigens (in mijn ogen) ook de custom CSS wat minder belangrijk maken, in ieder geval op dit vlak.

Dat geldt voor mij zeker. Dat is de enige reden dat ik nu custom CSS gebruik (en gewoon van iemand anders heb gejat omdat ik zelf geen front-ender ben), met het grote nadeel dat de CSS niet onderhouden wordt. Daardoor heb ik nu al wat slecht leesbare velden die recent zijn toegevoegd, en ik heb geen zin om om de haverklap weer nieuwe CSS te zoeken of zelf iets te fixen terwijl ik eigenlijk de ballen verstand heb van CSS.

Een dark-mode-knopje lost dat hele probleem in ieder geval op.

[PearZeaL]

Ik heb exact hetzelfde probleem. Ik heb ooit een CSS van internet geplukt voor een dark theme op Tweakers maar je merkt dat niet alle tekst altijd goed leesbaar is vooral sommige menus en de pricewatch.

Ach zoals moeders altijd zei: Kleinigheden hou je toch altied.

[OriginalSjoerd]

Ik gebruik de 'dark reader' extensie voor Chrome en Firefox als ik in een niet goed verlichte ruimte zit. Die werkt meestal best aardig en ook op de meeste sites.

[jmxd]

Goed om te horen. Tot die tijd nog maar even gebruik maken van de custom CSS inderdaad.

[Creesch]

Wat betreft custom CSS kunnen wij hier geen rekening mee houden.

Dat is natuurlijk niet helemaal waar. Het is niet mogelijk om rekening te houden met bestaande CSS maar het is wel degelijk mogelijk om toekomstige CSS te faciliteren. Wat mij bij één van de A/B testen bijvoorbeeld opviel was hoe generiek sommige classes en andere selectoren waren waardoor het bijna niet mogelijk was om aanpassingen te doen per (uit mijn hoofd) column.

[watcher46]

Ik snap je insteek en is zeker geen slecht idee. Ik denk alleen wel dat het andere problemen met zich mee brengt. Namelijk, onderhoudbaarheid van onze code. Bijvoorbeeld stel dat wij overal classes of id's op elementen gaan zetten met als doel om custom CSS te faciliteren. Dan betekend dat als je ooit, hetzij per ongeluk, die class op een andere plek gebruikt je direct een custom CSS snippet van iemand visueel kapot maakt. En aangezien er erg veel CSS snippets zijn, is dat daadwerkelijk een hel om te onderhouden.

Een van de redenen om een nieuwe frontend setup te maken was ook om de onderhoudbaarheid te verhogen. Wat de snelheid en consistentie verhoogd van wat wij als devvers opleveren.

Tuurlijk we bieden de custom CSS mogelijkheid aan, en is een zeer krachtige mogelijkheid om de website aan te passen naar je eigen wensen. Maar we hebben al lang geleden besloten om bij het ontwikkelen van de website geen support te leveren voor zelf bedachte CSS snippets.

We zijn bezig nu om alles theme-based te bouwen, wat inhoud dat we custom CSS properties gebruiken. (zie hier mijn uitleg)
Waarbij we bijvoorbeeld de properties instelbaar kunnen maken, zodat je het thema alleen voor jou specifiek aan kan passen. Nu is dit nog maar een idee wat wij als devvers hebben, dus pin me er niet op vast, maar behoort zeker tot de mogelijkheden.

[Creesch]

Fair enough, met de kanttekening dat ik ergens de verwachting had dat jullie in een pipeline ook wel functionele geautomatiseerde tests hebben draaien. Dat soort testen hebben vaak ook baat bij specifieke selectoren voor het testen van functionaliteit.

[jip_86]

Je zou uit oogpunt van backwards compatibiliteit wel zo veel mogelijk kunnen proberen dezelfde namen te behouden. Als er nieuwe features bijkomen is het niet anders, maar de vorige test waren zelfs de ankeilers of nieuwsitems veranderd. Dan kun je wel indenken dat er wrevel ontstaat als in de aankondiging staat dat er wel rekening mee gehouden is.

[GekkePrutser]

Ja dat snap ik goed..

Ik vind het nieuwe design nog steeds veel te visueel (zelfs nog meer plaatjes). Mijn frontpage nu met Custom CSS is helemaal tekst-based 1 kolom nieuws links, en de kleine kolom rechts heeft de nu op het forum. Verder helemaal geen ankeilers. Daardoor zie ik op de pagina 24 nieuwsheadlines zonder te scrollen in plaats van maar 5 Maar ik snap dat dit niet voor iedereen is. Het is niet erg om dat eenmalig te CSS'en bij een grote redesign, en over het algemeen maken de sprints weinig kapot.

Wat ik wel jammer vind is dat jullie mobile-first gaan. Ik snap de reden daarachter niet zo. Tweakers is bij uitstek een desktopsite, ook vanwege de doelgroep die behoorlijk PC georienteerd is.

Mobile-first betekent meestal hamburger menu's (dus meer kliks), minder opties en functionaliteit. Over het algemeen een achteruitgang IMO. Zoals jullie het nu deden met responsive ging het prima (het hamburger menu verschijnt alleen op de mobiel).

Wel nog een tipje: Hou je niet vast aan die 'tracker' als optie voor mensen die van high-density houden zoals ik. Hij is onbruikbaar omdat de titels afgekapt worden. Daarom gebruik ik hem nooit. Custom CSS is de enige optie.

[Reactie gewijzigd door GekkePrutser op 24 juli 2024 11:42]

[unreal0]

Ben het met je eens. En wat een prachtige custom css!

[The Legend]

Wat voor mij, en volgens mij meer oudgedienden, belangrijk is: kan ik na de FP update gewoon nog m’n huidige CSS text based FP blijven gebruiken? Je kunt mij in A/B tests stoppen wat je wilt, maar geen van de voorgeschotelde opties zal ik kiezen. Van drie naar vijf zichtbare nieuwsitems… das voor mij echt van de regen in de drup. De richting die T.net qua design op wil, is gewoon niet aan mij besteed. Dat is kennelijk een fundamenteel verschil, en dat vind ik helemaal niet erg, zolang maar gefaciliteerd blijft dat ik niet verplicht tegen ankeilers en andere designfratsen hoef aan te kijken

[Valandin]

Beetje random vraag, maar ben jij nou de Paul van mastermovies?

[HKLM_]

Ja dat is hem (check zijn LinkedIn) in een YouTube video (volgens mij stemmen van toen eens gehoord dat die bij XS4ALL zat en nu dus bij tweakers

Mooie tijden waren dat haha

[Reactie gewijzigd door HKLM_ op 24 juli 2024 11:42]

[watcher46]

hahaha jup

[marapuru]

Goede vraag, die ik mijzelf ook stelde. Tevens is er naast de custom CSS natuurlijk ook nog element blocking, zoals via bijvoorbeld uBlockOrigin. Mijn homepage ziet er dan ook finaal anders uit dan jullie testen.

Ik heb geen cijfers over hoe groot het aandeel is van mensen met element based blockers. Maar mijn gevoel zegt dat grofweg 15% - 30% daar wel eens gebruik van zou kunnen maken.

Zie hier mijn versie van de homepage

Hoe neem je dat mee in je testproces?

[Reactie gewijzigd door marapuru op 24 juli 2024 11:42]

[vanaalten]

Ik zou zelf zeggen dat je mensen die custom-CSS gebruiken moet uitsluiten van A/B testen: dat zijn gebruikers die sowieso een sterke eigen mening hebben over hoe de frontpage er uit moet zien.

[boenkeijer]

Dat ben ik met je eens, dat is ook een reden dat de custom-css functionaliteit destijds is verschenen. Bij de opt-in bèta kunnen gebruikers zelf bepalen of ze mee doen en hun custom-css er op aanpassen of uitzetten.

[Creesch]

Zou het wel mogelijk zijn om bij toekomstige A/B testen die wel ergens kenbaar te maken? Wat mij betreft ver onderin in de footer oid maar dan weet ik iig of ik moeite moet steken in CSS aanpassingen op dat moment.

[boenkeijer]

Bij een a/b-test weten we niet of jij een custom-css-snippet aan hebt staan die gebruikt wordt op die pagina. Ik denk dat we per test (a/b, alpha, bèta) moeten afwegen of we hier custom css moeten uitsluiten. Voor de ene zal het wel relevanter zijn dan voor de andere.

[Creesch]

Dat vraag ik toch ook niet? Ik vraag simpelweg of het feit of iemand deelneemt aan een A/B test (ongeacht of ze css aan hebben staan) dit ergens heel subtiel en bijna verstopt alsnog vermeld kan worden. Dan kan als ik zie dat een CSS snippet het niet goed doet iig beslissen of ik er iets mee doe ipv op het forum te vragen wat er gaande is om daar alsnog verteld te krijgen dat het gaat om een A/B test.

[boenkeijer]

Mijn reactie (boenkeijer in 'plan: Tweakers' frontpage-A/B-tests - Wat hebben we geleerd en...) ging wel over custom-css, vandaar dat ikzelf de link legde.

Maar interessant punt wat je aanhaalt, ik zal eens overleggen met collega's of dit iets is wat we willen toevoegen.

[Freeaqingme]

Maar dat zijn ook je power-users. Als je die uitsluit krijg je steeds meer een interface die gericht is op senioren dan op de die-hard tweakers. Dus ik denk dat dat een lastige is.

[vanaalten]

Misschien, maar: je wilt een A tegen B testen - en met het opleggen van de test aan custom-CSS gebruikers krijg je dus ook custom-CSS tegen B testen. En omdat die CSS voor iedereen anders is, gaat het de test-maker volgens mij geen informatie geven.

Zo lang die-hard tweakers / power-users met CSS de mogelijkheid hebben de website te maken zoals ze zelf willen, maak je met de interface-wijzigingen zowel senioren als die-hard tweakers blij.

[Blokker_1999]

Dat kan je afvangen door de custom-CSS, zoals door de T.net site geimplementeerd, tijdelijk uit te schakelen voor deelnemers aan de test. Dat moet je niet doen door die mensen uit te sluiten. Er zijn andere mensen die andere oplossingen voor custom-css gebruiken, maar die kan je dan weer niet detecteren.

[vanaalten]

Hmmm, dan hoop ik wel dat je uitgaat van vrijwillige deelname aan de test. Een opt-in systeem of mogelijkheid tot opt-out. Want custom-CSS is onderdeel van het betaalde abonnement, die kan je als tweakers.net niet zomaar even uitschakelen omdat je wat wil testen. Dat moet dan enkel gebeuren als de klant daar mee accoord gaat, lijkt mij.

[Blokker_1999]

Ondanks dat ik in beperkte mate custom CSS gebruik vind ik niet dat ik daarom zou uitgesloten moeten worden van een test. Vergeet niet dat de meeste gebruikers van custom CSS ook veelgebruikers zijn van de site.

En er is niets mis met een eigen, sterke mening te hebben, zolang je in discussie kunt gaan, het beleefd houdt en met argumenten komt waarom je bepaalde keuzes niet goed vindt is daar ook niets mis mee. Je moet er wel rekening mee houden dat het niet bij het oude kan blijven en dat er verandering aankomt. Dan kan je beter mee helpen sturen dan je kop in het zand steken en voor schut gezet worden.

[J2S]

Mijn frontpage ziet er vergelijkbaar uit, BBG vind ik ook niet interessant. Gewoon uBlock gebruikt. De afbeeldingen van de ankeilerartikelen leiden alleen maar af voor mij en hebben dus een negatieve waarde. Daarnaast kan ik zelf wel bepalen wat ik interessant vind.

[P_Tingen]

Ik gebruik de homepage eigenlijk haast niet eens; ik benader de nieuwsartikelen eigenlijk altijd vanuit mijn RSS lezer en kom dan gelijk in het artikel. Hetzelfde geldt voor een aantal forums die ik volg. De enige pagina waar ik wel eens rechtstreeks terecht kom is de pagina naar 'mijn topics' in GoT.

[Globber]

Ik heb geen cijfers over hoe groot het aandeel is van mensen met element based blockers. Maar mijn gevoel zegt dat grofweg 15% - 30% daar wel eens gebruik van zou kunnen maken.

Ik denk dat je dat echt extreem grof overschat. De actieve community van Tweakers is misschien ergens in die richting, maar dat is natuurlijk een fractie van de gebruikers van de site.

[Giant87]

Ik denk nog geen 1%

[ShadLink]

A/B tests zijn gewoon extreem opdringerig, en zonder een opt-out jaag je gewoon letterlijk je gebruikers van je site.

Als je in softwareontwikkeling werkt en ineens een testversie aan je klanten uitlevert waar de klant niet omgevraagd heeft, heb je echt wat uit te leggen. En kan je dat niet is de mogelijkheid groot dat je die klant dan gewoon echt kwijt bent.

Ik zou het beperken tot alfa en beta tests. En desnoods een brede betatest waarbij je gebruikers een popup toont met "we hebben nu deze betatest klaarstaan wil je deze activeren?" en een vragenlijst na de test om in te vullen.

[RobIII]

A/B tests zijn gewoon extreem opdringerig [...]

Als je in softwareontwikkeling werkt en ineens een testversie aan je klanten uitlevert waar de klant niet omgevraagd heeft, heb je echt wat uit te leggen. En kan je dat niet is de mogelijkheid groot dat je die klant dan gewoon echt kwijt bent.

Wat een kul. Ik denk dat je dagelijks aan een handvol, zo niet meer, A/B tests meedoet zonder 't überhaupt te beseffen. Mits goed uitgevoerd hoeft dat ook helemaal niet.

[Reactie gewijzigd door RobIII op 24 juli 2024 11:42]

[vanaalten]

Waar ik zelf wel moeite mee had tijdens deze (en een vorige) A/B test is dat ik een betalende klant ben, dus betaal voor de inhoud maar ook voor hoe het gepresenteerd wordt.

Nou geloof ik best wel dat Tweakers.net juridisch niets fouts doet, dat mijn betalen-voor-abonnement mij geen recht geeft op een bepaalde layout, maar gevoelsmatig steekt dat wel: als de website structureel niet prettig in gebruik is, als ik dat vooraf had geweten, dan zou ik daar geen abonnement voor afgesloten hebben.

Dus ja: je kan een klant echt wel kwijtraken als je een (overduidelijke) testversie voorschotelt.

[phamoen]

Ja het kan (een klant kwijtraken), je hebt een punt.

Maar een A/B test is om te kijken op welke punten welke beter scoort. Dus er is er niet een ontworpen om slecht(er) te zijn dan diegene die er was. Je mag een punt hebben, maar om daar dan een groot punt (zeg niet dat je dat doet, maar zo leest je comment wel een beetje) van te maken tijdens een 30 uur durende test...... ?

Een A/B test lijkt mij een prima manier voor Tweakers om zoiets te testen iig.

(smiley voor de vriendelijke toon waarmee dit gelezen moet worden)

[Reactie gewijzigd door phamoen op 24 juli 2024 11:42]

[vanaalten]

Vriendelijke toon wordt gewaardeerd.

Het is denk ik ook een beetje gerelateerd aan mijn andere punt: mensen die custom-CSS gebruiken wellicht uitsluiten van A/B testen. Ik ben er zo eentje: met custom-CSS probeer ik de frontpage qua informatiedichtheid flink te verhogen. Ik zie graag veel nieuwsregels, voor mij onnodige dingen (een jobs-sectie bijvoorbeeld) haal ik weg.

Dat is behoorlijk anders dan wat de doel-stijl van Tweakers lijkt te zijn: voor elk wat wils, moet er mooi uitzien, niet te overweldigend (dus lekker wat whitespace tussen regels). En afgelopen jaar heb ik geloof ik twee keer in een A/B test gezeten waarbij m'n custom-CSS niet meer werkte en ik dus vooral een website kreeg te zien zoals door Tweakers bedoeld was, niet zoals ik 'm wilde. En als je dan moet gaan zoeken naar obscure cookies om jezelf uit die test te halen, dan is dat best frustrerend.

Dat een nieuw design in principe ongeveer even goed of zelfs beter is dan het gangbare design - dat ben ik wel met je eens. Maar hij is wel flink anders dan 'mijn' custom-CSS versie, dus als dat opgedwongen wordt is dat voor mij wel een duidelijke verslechtering.

Dat er op een gegeven moment een definitieve nieuwe site uitgebracht wordt en dat een custom-CSS dan niet meer werkt - dat snap ik, is weinig tegen te doen en dan moet je even door de zure appel heenbijten om de custom-CSS weer bij te werken. Dat hoort er dan een beetje bij.

Maar stel dat er maandelijks een A/B test is, ik maandelijks gedurende een bepaalde tijd niet meer de door mij gewenste opmaak krijg - dan zou dat wel heel erg irriteren. Dat ik dan betaal voor alle features maakt dan wel dat ik zo iets heb van 'hier betaal ik verdorie niet voor!'.

[phamoen]

Dank voor je uitleg! Jij zou je dus eenmalig willen opt-outen voor al deze tests en enkel willen dealen met de definitieve wijzigingen... snap em

[Daoka]

Maar een A/B test is om te kijken op welke punten welke beter scoort. Dus er is er niet een ontworpen om slecht(er) te zijn dan diegene die er was.

Het is niet ontworpen om slechter te zijn. Helaas vind ik vaak wel dat nieuwe een nieuwe uiterlijk meestal toch slechter is dan de oude. Vaak worden er features ingestopt die ik fijn vind of juist functies eruit gehaald. Om even een simpele voorbeeld te geven de Playstation store via de website. Vroeger kon je het gewoon normaal gebruiken. Sinds dat ze het vernieuwd hebben staan er geen eens meer plaatjes of filmpjes bij de games. Leuk zo een nieuwe nutteloze geworden website. En zo zijn er gewoon veel meer websites / app / programma's die na vernieuwing gewoon minder handig geworden zijn / minder mooi of zelfs schreeuwerig is / functies eruit gehaald die ik juist daar fijn vond. Ja vernieuwing kan leuk en handig zijn alleen heb ik dus vaak helaas dat het voor mij niet goed uitpakt. Dit is dus ook de eerste gevoel die ik had toen ik de artikel las.

[bwerg]

Waar ik zelf wel moeite mee had tijdens deze (en een vorige) A/B test is dat ik een betalende klant ben, dus betaal voor de inhoud maar ook voor hoe het gepresenteerd wordt.

Volgens mij staat er nergens in de voorwaarden dat het tweakers verboden is om de UI te wijzigen, dus een A/B-test is toch niets anders dan elke andere wijziging aan de website? Tweakers kan ook zonder A/B-test besluiten de UI te veranderen, dat heb je ook als betalende gebruiker maar gewoon te accepteren (of je zegt je abbonnement op, als je echt wil) omdat tweakers niet voor iedereen een persoonlijke UI ontwikkelt.

Hooguit is de UI in een A/B-test minder goed uitgewerkt dan een definitieve wijziging, maar dat is in principe een fout. Er horen in een A/B-test net zo min bugs te zitten als in de uiteindelijke UI.

[vanaalten]

Juridisch zal het vast allemaal mogen, dat betwist ik niet.

Maar is het heel gek gedacht dat ik een abonnement afsloot op basis van de inhoud van de site maar ook over de presentatie en gebruiksvriendelijkheid? En dat als ik een paar keer in een A/B test kom die mij irriteert, dat ik dan denk ‘dit is niet waar ik een abonnement voor afsloot’?

[ShadLink]

[...]

Wat een kul. Ik denk dat je dagelijks aan een handvol, zo niet meer, A/B tests meedoet zonder 't überhaupt te beseffen.

Leuke tegenstrijdigheid. Als je het niet beseft dan is het meestal geen probleem. En dat is ook niet het probleem van de community.

Dat kreeg je hierbij:

Mits goed uitgevoerd hoeft dat ook helemaal niet.

De vorige voorpagina A/B test was dus niet goed uitgevoerd.

[Blokker_1999]

De test zelf was vrij goed uitgevoerd. Het grote probleem is dat omdat je heel het ontwerp op de schop neemt, het onmogelijk is om de test onder de radar te doen. Er gebeuren wel meer A/B tests op deze site, maar die zie je meestal amper. Deze was gewoon enorm opvallend.

[dylan111111]

"Mits goed uitgevoerd hoeft dat ook helemaal niet. "
En laat dat juist net het probleem zijn geweest de laatste keer hier*

[pizzacabonara]

Precies een goede A/B test merkt de gebruiker niet anders is het geen test meer.

[ymmv]

Mits goed uitgevoerd, wat betekent dat de wijzigingen niet heel groot zijn. Een A/B-test met een radicaal anders ontwerp, dat zal die klant wel merken en als de betalende klant opeens ander moet gaan werken of zelfs minder functionaliteit omdat features van de oude produktieversie ontbreken, dan breekt de pleuris uit.

Dat heeft Spotify dus een jaar geleden gedaan. Daar kreeg een steeds groter wordende groep betalende klanten ongevraagd een beta-versie van een nieuwe Windows-app in de mik geduw. Aan die nieuwe versie ontbrak nog van alles en de features die er al waren zaten vol met bugs. Mensen waren laaiend en lieten dat volop merken op het Spotify-forum. Er waren gelukkig handigerds die een manier vonden om terug te gaan naar de oude, goede versie en de auto-update te blokkeren, maar die postings werden voortdurend verwijderd door de mods waardoor mensen nog bozer worden. Niet dat het hielp, er werd zelden of nooit inhoudelijk op klachten gereageerd en het duurde maanden voordat doorgegeven bugs werden opgelost.

Voor mij een schoolvoorbeeld hoe je NIET beta's moet testen.

[R4gnax]

A/B tests zijn gewoon extreem opdringerig, en zonder een opt-out jaag je gewoon letterlijk je gebruikers van je site.

Als je in softwareontwikkeling werkt en ineens een testversie aan je klanten uitlevert waar de klant niet omgevraagd heeft, heb je echt wat uit te leggen. En kan je dat niet is de mogelijkheid groot dat je die klant dan gewoon echt kwijt bent.

A/B tests zijn dan ook bedoeld om de effectiviteit van twee verschillende volledig uitgewerkte productie-geschikte versies van een feature die op andere vlakken verschillend is, hoofdzakelijk layout; interactiemodel; etc. te meten, mbv een vooraf opgestelde doel-metric, zoals bijv. percentage 'converterende' gebruikers - dwz. hoeveel gebruikers interacteren met de feature en op bijv. een e-commerce site doorgaan tot een aankoop.

Dit soort tests zijn bij uitstek geschikt voor one-shot visitors die eens op een blauwe maandag langs komen en je daarna maandenlang niet meer ziet. Voor terugkerende gebruikers met bijv. logged-in accounts zijn ze inderdaad stik-irritant. Niet omdat ze incompleet of halfbakken zouden zijn -- Dat horen ze dus niet te zijn! -- maar omdat ze de continuiteit van de user interface aanpassen en daarmee de mate waarmee een terugkerende gebruiker comfortabel van een site gebruik kan blijven maken omdat ze weten hoe ze alles makkelijk terug kunnen vinden; hoe alles werkt; etc.

[Reactie gewijzigd door R4gnax op 24 juli 2024 11:42]

[boenkeijer]

De testaanpak zou per feature afgewogen moeten worden: bij grotere wijzigingen, zoals de frontpage, is het beter om te alpha- en bètatesten, terwijl je aannames in de kleinere optimalisaties weer goed kan a/b-testen.

Waar we bij de frontpage a/b-test hebben geprobeerd om te grote wijzigingen samen te testen, kan ik me voorstellen dat dit als opdringerig is ervaren. Daar proberen we met de nieuwe aanpak verbetering in aan te brengen

[Patriot]

A/B-tests zijn net borstvergrotingen, je denkt misschien dat je er een hekel aan hebt maar dat komt voornamelijk omdat je het eigenlijk alleen ziet als ze verkeerd zijn uitgevoerd

[pizzacabonara]

Echt onzin, wat is er dan opdringerig aan een A/B test?

[Kiswum]

Bij het stukje communicatie mis ik nog wel een stuk waarbij men duidelijker aangeeft dat er een grote/duidelijke fout is gemaakt of excuses wordt gemaakt. Met andere woorden: dat de hand in eigen boezem wordt gestoken. De test is niet voor niets snel uitgeschakeld, want er was echt iets goed mis. Als het wel meeviel, dan zou het niet na zo'n korte periode zijn teruggedraaid. Er kwam namelijk een gigantische stroom aan klachten binnen.
Nu wordt eigenlijk gezegd dat het wel meeviel...

Ik vind het erg vreemd dat de duidelijk zichtbare problemen niet eerst zijn opgelost voordat ze aan het publiek werden getoond. Wat heeft de eigen crew daarover gezegd?

• De informatiedichtheid is lager dan bij de huidige frontpage.
• De letters van de nieuwsitems zijn te groot.

Zo zag het er in werkelijkheid uit:
https://gathering.tweaker...message/68709876#68709876

Het grootste probleem van het huidige design vind ik de plaatsing van de ankeilers.
Het voelt voor mij aan als een reclame boodschap tussen de nieuwsberichten. Daarnaast zijn ze ook nog tussen de dagberichten geplaatst waardoor je de berichten mist die daaronder staan.

Het zou prettiger zijn als deze ankeilers achter het dagoverzicht wordt geplaatst, zodat je in 1 oogopslag het nieuws van de dag hebt, dat zorgt gegarandeerd ook voor extra bezoekers op de oudere berichten.

Momenteel heb ik de ankeilers noodgedwongen uit geschakeld/verminderd voor een overzichtelijke Frontpage.

[Blokker_1999]

Maar je kan een ontwerp niet maken op basis van wat de luidste roepers wensen. Er zit een visie achter wat het nieuwe ontwerp moet bereiken, en dat gaat spijtig genoeg in tegen wat vele power users wensen. Maar die power users zijn een kleine minderheid. Ook ik zou het liefst een site zien zonder ankeilers, maar ik besef maar al te goed dat dat vanuit commerciele overwegingen geen optie is.

En vergeet niet, mensen die tevreden zijn gaan meestal niet lopen schrijven over dat ze tevreden zijn. Het is slechts een kleine minderheid die zijn mening neerschrijft, en vooral mensen die niet tevreden zijn. Men heeft er allesinds wel naar geluisterd en men neemt de feedback mee.

[Kiswum]

Een standaard gebruiken is geen betaald lid, een power user is dat (procentueel gezien) veel eerder. Deze klanten wil je niet verliezen door een design die minder nieuws/artikelen laat zien op de hoofdpagina.

P.s.
Uiteraard zie je lezers niet reageren, die klikken door maar een andere website. Het viel mij wel op dat veel gebruikers aangaven dat ze normaal niet klagen, maar in het topic toch echt wel hun zegje wilde doen.

[Reactie gewijzigd door Kiswum op 24 juli 2024 11:42]

[Blokker_1999]

Wat heb je liever 1 betalend lid of 100 niet betalende bezoekers die een extra klik geven ...

[Reactie gewijzigd door Blokker_1999 op 24 juli 2024 11:42]

[Kiswum]

Ik of Tweakers? 😉
Tweakers gaat denk ik vooral voor de mainstream bezoekers en de vele kliks.

[boenkeijer]

Bij het stukje communicatie mis ik nog wel een stuk waarbij men duidelijker aangeeft dat er een grote/duidelijke fout is gemaakt of excuses wordt gemaakt. Met andere woorden: dat de hand in eigen boezem wordt gestoken. De test is niet voor niets snel uitgeschakeld, want er was echt iets goed mis. Als het wel meeviel, dan zou het niet na zo'n korte periode zijn teruggedraaid. Er kwam namelijk een gigantische stroom aan klachten binnen.
Nu wordt eigenlijk gezegd dat het wel meeviel...

Het aantal reacties valt zeker niet mee, bij een frontpage test weet je dat er veel reacties gaan komen. De reacties gingen wel veelal over dezelfde punten, die zijn ook te lezen in dit artikel.

Als we met de kennis van nu een plan zouden moeten maken dan zou die er anders uitzien dan die van de a/b-test die ik omschrijf in dit artikel. De 'stroom aan klachten' waar jij naar verwijst waren niet de enige reden om de test stop te zetten, daar kwamen ook andere factoren bij kijken.

Ik vind het erg vreemd dat de duidelijk zichtbare problemen niet eerst zijn opgelost voordat ze aan het publiek werden getoond. Wat heeft de eigen crew daarover gezegd?

• De informatiedichtheid is lager dan bij de huidige frontpage.
• De letters van de nieuwsitems zijn te groot.

De sample-size van de interne testers was zo klein dat een reactie over de grote van het lettertype minder opviel, zoiets is in mijn ogen een kwestie van smaak/gewenning. Tijdens de test kwamen er veel reacties op en dat is een signaal dat we daar iets mee moeten. In de beta-variant hebben we dus ook op deze punten verbeterd.

Het grootste probleem van het huidige design vind ik de plaatsing van de ankeilers.
Het voelt voor mij aan als een reclame boodschap tussen de nieuwsberichten. Daarnaast zijn ze ook nog tussen de dagberichten geplaatst waardoor je de berichten mist die daaronder staan.

Het zou prettiger zijn als deze ankeilers achter het dagoverzicht wordt geplaatst, zodat je in 1 oogopslag het nieuws van de dag hebt, dat zorgt gegarandeerd ook voor extra bezoekers op de oudere berichten.

Momenteel heb ik de ankeilers noodgedwongen uit geschakeld/verminderd voor een overzichtelijke Frontpage.

We hebben in de beta-variant het probleem wat jij schrijft opgelost, we hebben geen ankeilers die de nieuwslisting onderbreken. Ik ben benieuwd of dit je bevalt als de betatest start

[Kiswum]

Bedankt voor je uitgebreide en gefundeerde antwoord.

Wat betreft het betatesten. Ik heb mij daarvoor aangemeld en ik wil graag meewerken aan de site vanuit een ander perspectief. Doordat het mogelijk is om op elk moment uit een test te stappen, maakte het voor mij een prettig om hieraan mee te werken in de toekomst.

[LankHoar]

Persoonlijk vind ik de vorige versie van de FP nog steeds beter. De ankeliers komen minder schreeuwend naar voren, en dat vind ik prettig. Momenteel schenk ik eigenlijk geen aandacht aan ze omdat ze onopvallend zijn, juist omdat ze zo opvallen. Kan het niet beter omschrijven eigenlijk.. Iets met door de bomen het bos niet meer zien?

Tijdens de vorige feedback ronde met 4 opties was ook duidelijk dat 3 van de 4 designgs veel te chaotisch waren. En wanneer ik de Beta versie nu bekijken krijg ik weer dat gevoel. In plaats van vooruitgang, zie ik ook dit als achteruitgang. Hoop echt dat er nog wat geschaafd gaat worden. Of geef de keuze aan de gebruiker: laat de gebruiker zelf kiezen om bepaalde elementen wel/niet/minder naar voren te laten komen.

[Kiswum]

Wat een rust geeft die oude weergave, wat een verschil met de hoeveelheid aan informatie die nu naar alle gebruikers worden gestuurd. Wat ben ik blij dat Custom CSS beschikbaar is op Tweakers!

[LankHoar]

Nu ben ik benieuwd wat voor CSS je gebruikt om het rustiger te maken? Zelf heb ik niet zoveel kaas van CSS gegeten dus zelf iets bouwen gaat lastig worden

[Kiswum]

Daarvoor maak ik gebruik van de volgende FP aanpasingen:
Verberg downloads (Crisp)
Verberg Ankeilers tussen de teksten op FP (Kiswum)

Verder nog wat andere aanpassingen, maar het bovenstaande is voor de layout.

[boenkeijer]

We hebben in het ontwerptraject gesproken over het personaliseren van de frontpage, dit is iets waar we wel naar toe zouden willen gaan in de toekomst maar voor nu helaas niet haalbaar. We willen eerst de basis goed neerzetten met een vernieuwde, op componenten gebaseerde, front-end setup.

[spone]

Ligt het aan mij of heeft de tracker het veld moeten ruimen in het betadesign? Zonder de tracker is er imo veel minder verbinding tussen de frontpage en de overige onderdelen zoals het forum en V&A.

[Reactie gewijzigd door spone op 24 juli 2024 11:42]

[Jeroenneman]

Dat was ook mijn eerste reactie, als in: zijn er überhaupt Tweakers die Tweakers bezoeken zonder de tracker uitgeklapt? Ik zie de frontpage echt nooit zonder tracker, en zie hem als fundamenteel onderdeel van Tweakers. Was überhaupt verbaasd dat je de tracker kon inklappen.

[MsG]

Ik gebruik dat ding werkelijk nooit, en zo velen met mij. Iedereen gebruikt een website weer anders.

[boenkeijer]

Dat heb je scherp gezien, dat je 'm niet ziet in de screenshots betekent niet dat ie weggaat. De Tracker is een hele oude functionaliteit met veel techdebt, bij de a/b-test veroorzaakte deze veel problemen en hebben we 'm nu uit de bètatest gehaald. De Tracker willen we t.z.t. goed in de bètatest verwerken.

[barbarbar]

De ankeilerartikelen zou ik in een soort carousel zien van de meest recente 5 tot 7 artikelen. Ik merk regelmatig dat ik denk van "oh, dat wil ik later even lezen" en dan staat het alweer ergens tussen de nieuwssectie verstopt. Ook "zie" ik de ankeilerartikelen regelmatig niet, hier scan/lees ik gewoon overheen omdat dit op sites vaak de advertenties zijn.

Maar ook in de praktijk mis ik vaak de grootste borden, dus wellicht ben ik de uitzondering. In de auto zoekend naar een ingang mis ik gewoon de grootste borden, in de supermarkt zit ik te zoeken naar die aanbieding die blijkbaar met grote borden bij de ingang stond. Inmiddels zo getraind om de grootste aandacht schreeuwers te negeren dat het me niet eens opvalt.

[boenkeijer]

De ankeilerartikelen zou ik in een soort carousel zien van de meest recente 5 tot 7 artikelen. Ik merk regelmatig dat ik denk van "oh, dat wil ik later even lezen" en dan staat het alweer ergens tussen de nieuwssectie verstopt. Ook "zie" ik de ankeilerartikelen regelmatig niet, hier scan/lees ik gewoon overheen omdat dit op sites vaak de advertenties zijn.

Met de nieuwe opzet willen we meer ankeilerposities creëren, zodat ze niet heel snel in de nieuwslisting alleen gedrukt worden. Als we er ook in slagen om de artikelen die op die posities verschijnen te verversen, dan zullen deze hopelijk minder snel in jouw 'blinde vlek' komen.

[barbarbar]

Mee eens, de beta variant ziet er ook goed uit. Wellicht nog overwegen of artikelen die al in de ankeilerposities staan, niet meer in de nieuwssectie te tonen. Volgens mij staan ze nu dubbel op de frontpage.

[jjeggink]

Niet handig, zoals je zelf al aangeeft skippen veel gebruikers de ankeilers als element omdat dit veronderstelt wordt een advertentie te zijn en scrollen enkel door de lijst met artikelen. Bovendien zijn er zat tweakers die custum-CSS de ankeilers uberhaupt niet inladen.

[Blokker_1999]

Niet zozeer advertenties, daarvoor hebben we ons abbonement

Zelf maak ik de ankeilers vandaag klein omdat het content is die vaak lang blijft staan. En als je een artikel 1x gezien hebt moet je er niet telkens op gewezen worden dat het bestaat. Ankeilers zijn leuk voor de toevallige bezoeker van de frontpage, niet voor mensen die er meerdere keren per dag op langskomen.

[boenkeijer]

Klopt, ze staan er nu bewust dubbel. Dat doen we onder anders voor gebruikers die ankeilers verborgen hebben met custom-css of een andere plug-in. Op deze manier kunnen ze toch wel op de hoogte blijven van de nieuwste artikelen.

[Blokker_1999]

Al maar goed dat we custom CSS hebben om ze net in die blinde vlek te duwen

[Ethnic]

Eigenlijk zijn nieuwe updates vaak eng imo, maar de huidige beta ziet er niet verkeerd uit.

Offtopic: Gaan wij ooit donkere modus krijgen? (Nee, heb geen interesse in addons)

[boenkeijer]

Intern hebben we zeker de wens om dark mode te ontwikkelen, helaas is dit technisch nu te veel werk om te ontwikkelen en vooral te onderhouden.

De frontend-vernieuwing die we in willen zetten met de frontpage bèta willen we een moderne, op componenten gebaseerde interface, die de ontwikkeling van nieuwe functies versnelt en verschillende thema’s mogelijk maakt. Als we die thema's hebben dan kunnen we overgaan op het ontwikkelen van een dark mode.

Lang verhaal kort: we willen het graag ontwikkelen, maar hier kan ik helaas geen belofte op doen..

[Blue-eagle]

Wat is er zo moeilijk aan? De community doet het al voor je (ik gebruik het al erg lang) en jullie hebben zelfs nog meer controle, niet minder. Het is super makkelijk om te doen met CSS media queries alleen al en het togglen van een class op de HTML of BODY tag.

Doe dat gewoon stapsgewijs. Eerst een dark-mode van de community, vervolgens ga je de site opnieuw opzetten om van CSS variabelen gebruik te maken in je :root declaratie, en vervolgens pak je die variabelen en verander je ze naar een donkere variant.

Het zou een enkele developer minder dan 5 werkdagen mogen kosten om zoiets te implementeren voor iedereen, in plaats van die bizar felle witte versie van de site die gewoon afstotelijk is.

[watcher46]

Ik snap je punt, en eerlijk gezegd ben ik het ook met je eens. Het zou een developer niet meer dan een week mogen kosten om een darkmode-theme te mogen maken. (los van het samenstellen van een kleurenschema)

Maar misschien kan ik je beter uitleggen waarom het nu op dit moment zo lastig is om een darkmode te ontwikkelen met de huidige CSS.

Als eerste zit er enorm veel geschiedenis in, ooit was er puur CSS geschreven, later kwam SCSS om de hoek kijken. Toen zijn (zo goed als) alle CSS bestanden hernoemd naar .scss en is dat door een parser gegaan. Nieuwe CSS werd daadwerkelijk in SCSS geschreven, maar de oude CSS is nooit goed omgeschreven.
Dus is er nooit echt goed gebruik gemaakt van de variables binnnen SCSS om de huisstijl consistent te maken over alle pagina's. Enerzijds door kennis enerzijds door gebrek aan een styleguide.

Dus, met die legacy hebben we nu te maken. Daarop hebben we besloten dat bij de start van het design-system, we niet meer ons best gaan doen om de legacy te onderhouden en we gewoon opnieuw gaan beginnen. Waarbij we een component-library gaan aanleggen met UI-componenten die dan de huisstijl (middels custom CSS properties) heeft geïmplementeerd.
Je kunt dat zien dat we dus een thema maken bestaande uit custom CSS properties, waaruit dus ook een kleurenschema van darkmode kan gaan rollen, wat dan een klein klusje is.

Kortom, we zijn grotendeels van plan wat jij zegt

[jaenster]

De css die door de community gemaakt is, en gebruikt word door vele zoals ik zou toch een perfect basis kunnen zijn voor een darktheme? Het meeste en harde werk is allemaal al gedaan.

Het lijkt mij sterk als de gebruikers achter deze custom css er bezwaar tegen hebben als deze als basis word gebruikt

[Niekleair]

De css die door de community gemaakt is, en gebruikt word door vele zoals ik zou toch een perfect basis kunnen zijn voor een darktheme? Het meeste en harde werk is allemaal al gedaan.

Het lijkt mij sterk als de gebruikers achter deze custom css er bezwaar tegen hebben als deze als basis word gebruikt

Geef de leden die aantoonbaar aan die CSS meegeschreven hebben gewoon wat extra karmapunten of hoe die dingen ook heten in ruil voor de contributie. En zelfs als ze het zelf overnieuw moeten schrijven; zo moeilijk is dat toch ook niet?

[Reactie gewijzigd door Niekleair op 24 juli 2024 11:42]

[watcher46]

Is ook precies onze gedachte, zodra wij ook maar zicht krijgen op dat we hiermee aan de slag kunnen, zijn wij de eerste die de huidige custom css gaan raadplegen voor mooie darkmode implementaties.

[RobIII]

Feature Tweakers.net Nachtmodus.

[MrWiggle]

Dark modus wordt op dit moment 'native' in verschillende browsers geïntegreerd. Zowel de laatste versie van Chrome, als Firefox hebben bijvoorbeeld zo'n dark mode ingebakken zitten.

[watcher46]

Het klopt dat er ergens in een screenshot van een nieuw design een half maantje stond, scherp! Is ook iets waar we als frontenders rekening mee houden bij het opzetten de nieuwe frontend.

[locke960]

De informatiedichtheid is lager dan bij de huidige frontpage.
De letters van de nieuwsitems zijn te groot.

Volgens mij waren dat in 2012, bij de vorige grote verandering, ook al de 2 grootste bezwaren.
Naast "te wit" en klachten over een op touch gerichte interface voor desktop gebruikers.

Waarom is het toch dat als wij grotere schermen met hogere resolutie kopen, developers weer meer ruimte gaan gebruiken? We kopen die schermen juist omdat er meer oppast en we meer kunnen zien.

[Reactie gewijzigd door locke960 op 24 juli 2024 11:42]

[boenkeijer]

De huidige frontpage heeft op een hoge resolutie scherm veel 'witruimte' aan de zijkanten, als we de ruimte aan de zijkanten benutten kunnen we de informatiedichtheid op het scherm vergroten

[locke960]

Ik vind informatiedichtheid in een venster veel interessanter. Daar speelt die witruimte aan de zijkanten geen rol meer, en kan ik de rest van mijn beeldscherm ergens anders voor gebruiken.

[Psycho_Mantis]

Tegenwoordig open ik nooit meer sites full screen. Dus geen last van.

[lenwar]

Hebben jullie ook overwogen om een minder druk ontwerp voor de frontpage te ontwerpen? Dus minder foto’s en minder ‘vakjes’? Dus gewoon een lijst met nieuwsitems in één kolom.

Ik begrijp dat dat de ultieme nachtmerrie voor iedere grafisch ontwerper is, maar misschien dat veel van de lezers/gebruikers dat ook fijn vinden?

[LA-384]

Dit is idd precies wat ik met custom CSS heb proberen te maken. Geen ankeilers (of hoe die banners ook heten), geen andere content zoals uitgelichte reviews. Puur en alleen regels met artikelen onder elkaar:

https://tweakers.net/i/lJ...QqQMe6vz.jpg?f=user_large

Het vervelendste vind ik wel (en ik weet niet of dat door de custom CSS komt, of "by design" is) dat ik oudere artikelen maar tot een beperkte tijd terug kan zien. Zo zie ik op dit moment maar de artikelen tot gisteren (maandag) 15:33.

Via het kopje "nieuws" kun je wel verder terugkijken, maar dat A. onoverzichtelijk en B. incompleet.

[Reactie gewijzigd door LA-384 op 24 juli 2024 11:42]

[lenwar]

Ik heb hem iets minder plat.
Bij mij ziet hij er zo uit:
https://tweakers.net/i/1j...d2s0TcE9.jpg?f=user_large

[ZombieRofl]

Door de tijd zie ik het UI/UX van Tweakers een beetje worstelen met zichzelf. Als je kijkt naar Nu en Nos, dan kan je niet anders concluderen dat die volwassener ogen. Misschien goed om een externe partij een keer mee te laten kijken?

[boenkeijer]

NU.nl en de NOS hebben de luxe dat ze een duidelijke focus hebben van de dienst die zij aanbieden: nieuws. Tweakers heeft onder andere nieuws, een product- en prijsvergelijker (nieuw en v&a) en het forum, dit is één reden wat het verschil kan betekenen in onderhoud en doorontwikkeling.

Door de jaren hebben we ook wat tech- en ux-debt gecreëerd die we hebben proberen op te lossen, sinds dit jaar hebben we een volledig team die zich richt op het inlossen van deze debt. Zijn er hard mee bezig, maar nog niet op het niveau waar we willen zitten!

[ZombieRofl]

NU.nl en de NOS hebben de luxe dat ze een duidelijke focus hebben van de dienst die zij aanbieden: nieuws. Tweakers heeft onder andere nieuws, een product- en prijsvergelijker (nieuw en v&a) en het forum, dit is één reden wat het verschil kan betekenen in onderhoud en doorontwikkeling.

Helemaal waar en toch geloof ik zoals jij ook dat het echt beter kan. Succes daarmee!