Nieuwe url-structuur en verbeteringen in V&A - Development-iteratie #180

We hebben iteratie #180 opgeleverd. In deze sprint hebben we onder andere de url-structuur voor geselecteerde pagina's vernieuwd en een aantal verbeteringen in Vraag & Aanbod gerealiseerd. Het techteam heeft een begin gemaakt met de vernieuwingen die gaan komen aan de front-end.

Nieuwe url-structuur

Sommigen van jullie is het wellicht al opgevallen; sinds vorige week dinsdag hebben sommige pagina's een nieuwe url. Met de nieuwe structuur willen we ervoor zorgen dat de pagina-intentie beter te begrijpen is door zoekmachines, dat de interne concurrentie tussen pagina’s minder wordt of verdwijnt en dat pagina’s elkaar versterken. De wijzigingen gebeuren op categorie-, merk- en productniveau. Hier is een overzicht met de business rules van de oude versus de nieuwe structuur:

Pagina	Oude situatie	Nieuwe situatie
Categorieomgeving	tweakers.net/categorie/$id/$naam/$tabblad/	tweakers.net/$naam/$tabblad/
Merk+categoriepagina	tweakers.net/merk/categorie/$id/$merknaam/$categorie/	tweakers.net/$categorie/$merknaam/
Productomgeving	tweakers.net/product/$id/$productnaam/$tabblad/	tweakers.net/$categorie/$merknaam/$productnaam/$tabblad/

Merk+categoriepagina's

De merk+categoriepagina's bestaan al een aantal jaren op Tweakers. Dit waren 23 statische pagina's waarvan een aantal in de loop der jaren niet meer relevant is geworden. Denk aan smartphones van Blackberry. Sinds vorige week zijn deze pagina's dynamisch, dus is er nu van elke merk+categoriecombinatie een pagina met daarop de producten, met filters zoals jullie die van ons kennen, het nieuws en de reviews over het product.

Verbeteringen Vraag & Aanbod

We zijn ook begonnen met het verbeteren van Vraag & Aanbod. Aangezien we hier tegen nogal wat oude code aankijken, is een van de eerste dingen die we aanpakken, het formulier om een advertentie te plaatsen. De technische basis achter dit formulier wordt volledig vernieuwd, zodat we daarna kunnen bouwen aan een nieuwe foto-upload en het responsive maken, en daarnaast een onderscheid kunnen realiseren tussen particuliere en zakelijke verkoop.

Opheffen dienstenadvertenties

Bijna tien jaar geleden hebben we Vraag & Aanbod uitgebreid met de mogelijkheid om diensten aan te bieden. Uiteindelijk is daar weinig gebruik van gemaakt. Bovendien gebruikten de meeste dienstenadvertenties die nu actief zijn, niet de speciale velden waarmee ze van reguliere advertenties worden onderscheiden. Om het formulier voor nieuwe advertenties zowel voor de gebruiker als technisch eenvoudiger te maken, hebben we daarom besloten te stoppen met dit onderscheid. Je bent nog altijd welkom om een dienst aan te bieden of te vragen, maar zaken als een uurtarief en beschikbaarheid zul je dan in de advertentietekst zelf moeten vermelden.

Filteren op staat

Een nieuwe feature in Vraag & Aanbod is het kunnen filteren op de staat van het product. Het is mogelijk om te filteren op de volgende opties: nieuw, nieuwstaat, goede staat, gebruikssporen, slechte staat of defect. Door middel van de checkbox kun je de listing aanpassen aan jouw wensen wat de staat van het product betreft.

'Meld misbruik'-knop

Om misbruik op Vraag & Aanbod tegen te gaan, hebben we de knop om misbruik te melden visueel verbeterd en onderaan de beschrijving geplaatst, zodat je weet waar misbruik gemeld kan worden als je een gebruiker daarvan verdenkt.

Frontendvernieuwing

Ons huidige techteam houdt zich op dit moment bezig met de vernieuwing van onze frontendstack. De focus ligt daarbij op dit moment op ons JavaScript. Op dit moment worden er op elke pagina losse JavaScript-bestanden toegevoegd. Door de jaren heen is het een grote berg JavaScript geworden, die lastig te onderhouden is. Daarnaast bevat een hoop JavaScript nog ondersteuning voor inmiddels achterhaalde, browserspecifieke features en quirks. Met het oog op de toekomst zijn we bezig om het JavaScript onderhoudbaar te maken. Dit gaan we doen door het om te schrijven naar modules en volgens de moderne syntax van ECMAScript 2019.

Om browsers te ondersteunen die nog veel gebruikt worden, gaan we Babel gebruiken om moderne syntax om te zetten in begrijpbaar JavaScript voor zogenoemde legacybrowsers, zoals Internet Explorer 11. Om dit allemaal te integreren in de huidige Symfony-codebase, gebruiken we Webpack Encore. Dit maakt het geheel onderhoudbaar en eenvoudig.

Andere verbeteringen

• Topicreeks is nu ook beschikbaar voor rss.
• Met het onlangs vernieuwen van de icontoolbar bij zowel frontpagereacties als in het Forum introduceerden we voor het invoegen van url's en externe afbeeldingen een nieuwe modal dialog box. Deze hebben we nu ook toegepast op de andere toolbarfuncties waarvoor een modal wordt gebruikt.

Reacties (50)

[5pë©ïàál_Tèkén]

Gaat de url voor zoekfilters ook op de schop?

https://tweakers.net/pric...faD6Uz7E4E59jt5qB86EuzXNw

[RoestVrijStaal]

Aangezien URLS -de facto- maar maximaal 2000 karakters lang mogen zijn, is dat een slecht idee.

Het aantal zoekfilters is oneindig. Jouw voorbeeld is al ~521 karakters lang. Sommige namen van zoekfilters zullen weer geëncodeerd moeten worden (apostrofs, procenten, e.d.), waardoor er nòg meer tekens gebruikt worden.

Wat T.net wel zou kunnen doen, is zoekopdrachten, die je per se met medetweakers wilt delen, met een versimpelde id kan genereren.

[5pë©ïàál_Tèkén]

Is het idee slecht of lastig te realiseren? De leesbaarheid laat meen ik te wensen over. Dat het lastig is maakt het idee, meen ik, niet slecht.

[RoestVrijStaal]

Lees wat ik gelinkt heb, zou ik zeggen.

Het is niet onmogelijk, maar bij URLs voorbij de 2000 karakters kom je op onbekend terrein, waarbij het met de ene browser, OS, webserver, whatever het wel werkt en de andere niet.

[ACM]

Wat T.net wel zou kunnen doen, is zoekopdrachten, die je per se met medetweakers wilt delen, met een versimpelde id kan genereren.

Dat hebben we een tijd gehad en werd nauwelijks gebruikt; geen idee of het goed genoeg vindbaar was, maar ik verwacht ook weer niet echt dat de functie heel veel gebruikt zou worden als het beter te vinden zou zijn.

[ACM]

Met welk doel zouden we dat moeten doen?

[edit]
We laten die urls niet eens door Google indexeren; dus voor SEO is het zinloos om dat te veranderen.

Het lijkt erop dat je dat vanuit gebruiksvriendelijkheid wilt? Zoals @RoestVrijStaal al aangeeft is dat technisch vrijwel onmogelijk om goed te doen. We hebben juist ons best gedaan om de urls heel kort te houden; en je ziet hoe lang het nu al kan worden...

[Reactie gewijzigd door ACM op 24 juli 2024 04:51]

[5pë©ïàál_Tèkén]

Leesbaarheid vergroten zodat je (een beetje) kan zien wat 'er in' zit, inkorten (zoals @AW_Bos zegt) zodat het makkelijker te delen is. En voor de nerds die er zelf mee willen spelen.
Thx voor de reactie

[Reactie gewijzigd door 5pë©ïàál_Tèkén op 24 juli 2024 04:51]

[ACM]

Dat had ik ondertussen door

Maar uiteindelijk stelt hij die vraag in een context waar we ivm SEO urls hebben aangepast... En daarvoor is het zinloos, want we laten die filter-urls niet indexeren. We hebben geen plannen om deze urls 'ook' te veranderen; de leesbaarheid voor de gebruiker was hier niet een doel op zich, het beter aansluiten bij zoektermen voor gebruikers wel.

En zoals RoestVrijStaal al aangeeft is het technisch ook nog eens heel lastig om de betreffende informatie goed door te geven, zeker als de klacht nu al is dat de urls te lang zijn
De tekstuele representatie zal veel langer zijn dan de onderhuidse id's die gebruikt worden.

Dan zouden we alweer onderscheid moeten maken tussen de urls voor 'een paar filters' en voor 'veel filters'; wat het gedrag voor ons dan natuurlijk weer complexer maakt en het nut ervan beperkt. Nog los van het feit dat specificaties terugzoeken aan de hand van hun naam ook weer enige uitdagingen kan hebben, zeker zodra de naam wordt aangepast... De ids die nu uiteindelijk in die 'hash' zitten zijn wat dat betreft 'veiliger' (en meestal korter)

Voor de echte nerd is er zelf mee spelen trouwens prima mogelijk

Volgens mij heb ik zelfs wel eens ergens uitgelegd wat er in zit, maar hier nog een keer: het is een json-encoded dataset, dat wordt met gzdeflate wat verkleint en dat wordt daarna weer met base64 (de url-veilige versie) omgezet.
't Is vast mogelijk om het nog kleiner te krijgen, o.a. MessagePack bestond nog niet toen we dit maakten en het zou zomaar kunnen dat dat efficienter is dan json+gzip met deze relatief kleine datasets. Maar helaas moet je ook dat base64-encoden; en omdat er ook tekst in kan voorkomen (o.a. het Trefwoord), kunnen we dat ook niet zomaar omzeilen

[5pë©ïàál_Tèkén]

De wachtwoord generator feature blijft dus, helder. Thx voor de toelichting!

[ACM]

Wachtwoordgenerator?

Wel oppassen dat de tekst niet uniek is; zeker de eerste paar karakters zullen vaak hetzelfde zijn...

[5pë©ïàál_Tèkén]

Ik kan je reacties niet +3 geven, misschien kan je dat zelf? Qua wachtwoord generator gebruik - hoofd- en kleine letters, cijfers en af een toe een - en _. Alles zit erin een willekeurig deel van het filter dan misschien...

[Stoelpoot]

Waarschijnlijk zou je met YAML-encoding ook al een heel eind kunnen komen qua verkleinen, die is van nature iirc al kleiner dan JSON. Dat is alleen ook weer zo'n gedoe aan de backend.

[ACM]

Vziw is Yaml ruwweg even groot als JSON. Er wordt tenslotte indenting gebruikt op plekken waar je in json dan een zichtbaar karakter hebt. En de 'inline' arrays zijn weer min of meer json-style.

[Reactie gewijzigd door ACM op 24 juli 2024 04:51]

[Bender]

Gezien Tweakers de factor SEO belangrijk lijkt te gaan vinden mag je verwachten dat dat ook gaat gebeuren, echter heeft dat pas zin als ze ook een content marketing manager daar op gaan zetten. Alleen mooie urls brengt je niet zoveel.

[Stoelpoot]

SEO-urls hebben volgens mij weinig waarde op een zeer specifiek filter zoals op Tweakers. Die hoeven toch niet geindexeerd te worden.

[Bender]

O ja wel hoor, "Apple Smartphone" is een mooie filter waar op gezocht wordt.
Of denk aan "Smarttv Android" dat soort zaken.

Natuurlijk niet iets als "led display tussen 18 en 22 inch met een dpi van 10000".

[vosManz]

En voor die eerste heb je dus al de categoriepagina's met bijbehorende SEO link: https://tweakers.net/smartphones/apple/

[Bender]

Dat is inderdaad de eerste opzet, maar kan me voorstellen dat ze ook meer long tail willen op termijn (maar met een max van 3 of 4 diep kan ik me voorstellen).

[AW_Bos]

True, toch best iets waar ik mij aan erger. Als ik een URL van een filter aan iemand wil doorsturen wordt dat meteen een hele lap aan tekst wat extra gescroll en onoverzichtelijkheid oplevert.

[dec0de]

Bit.ly? Klopt, dan is het werk van jouw kant, maar toch

[AW_Bos]

Lekker bezig in deze thuiswerk-periode. Hoe doen jullie devvers dat eigenlijk?
VPN verbinding vanaf eigen PC of een remote desktop? En een computer/laptop van de zaak, of gewoon de privé-computer met alle developmentsoftware aan boord?

Ik ben benieuwd hoe de flow nu verschilt vergeleken met dat er op de zaak gewerkt wordt? Aan de iteraties kan ik me niet indenken dat het developen thuis lastiger is....

[Kees]

Hangt van de developer af. Sommige pakken hun werklaptop en werken daarmee, andere instaleren de omgeving die je nodig hebt gewoon op hun lokale desktop machine en anderen (hebben in het verleden) een remote desktop naar een laptop op kantoor gebruikt.

Daarnaast een vpn naar kantoor om daar wat services aan te kunnen spreken en om ip-restricted services te kunnen gebruiken.

Verder werkte vrijwel iedereen al structureel of incidenteel thuis, enige wat we veranderd hebben is dat alle meetings nu in hangouts gedaan worden ipv mensen op een telefoon in te bellen.

[Erdinger]

Nu nog een native dark mode

[MacPoedel]

Begrijp niet dat je negatief gemodereerd wordt. Ja je kunt custom CSS gebruiken om de website donker te maken, maar ik vind geen enkele van de bestaande snippets goed werken op alle elementen. Ik gebruik op mijn desktop Dark Reader maar op mijn telefoon heb ik geen browser die addons ondersteunt en zou liever ook geen andere browser gebruiken. Dus liever een officiële dark mode waar alle elementen ook effectief getest zijn, dan custom CSS.

[AW_Bos]

Correct me if i'm wrong.... Dat is al vaker geroepen, echter zou volgens de devvers dit een extra laag zijn die ze dan zouden moeten onderhouden, wat extra tijd kost.

[RoestVrijStaal]

Maar nu ze toch met de frontend bezig zijn, kunnen ze dat werk makkelijk meenemen?

[Reactie gewijzigd door RoestVrijStaal op 24 juli 2024 04:51]

[CH4OS]

Probleem is dat je twee stijlen dan moet gaan bijhouden, niet alleen qua (CSS) code, maar ook qua ontwerpen (huisstijlen) et cetera.

Ik zou ook liever een dark mode hebben, begrijp mij niet verkeerd, maar ik snap ook dat niet iedereen zit te wachten op dubbel werk.

[Reactie gewijzigd door CH4OS op 24 juli 2024 04:51]

[RoestVrijStaal]

Zelfs mindere technisch-georiënteerde sites als Nu.nl en Geenstijl.nl waar Tweakers.net qua bezoekersaantal & activiteit absoluut niet voor onder zal doen, hebben dark mode.

T.net is geen site meer die enkel door één of een handjevol personen als hobby wordt bijgehouden.

UX-wise valt er veel te leren van hoe bestaande website en applicaties dat doen. "Not invented here" toepassen is oliedom. Daarnaast doet een goede styleguide wonderen.
Technisch is het met JavaScript & CSS peanuts.
Bij quality-check valt de detectie van ongewenste verschillen (regio's die niet donker worden ondanks dat dat wel zou moeten) te automatiseren (screencap + image diff anyone?).

Op lange termijn is het echt minder werk dan je denkt. Juist dat (Dè?!?) meest bekende Nederlandstalige tech-website haar vingers niet aan wil branden, is lachwekkend.

[Reactie gewijzigd door RoestVrijStaal op 24 juli 2024 04:51]

[CH4OS]

Op lange termijn is het echt minder werk dan je denkt.

Dat het qua werk meevalt weet ik, maar ik ga er niet over bij Tweakers. Nogmaals, ik zou zelf ook graag een darkmode zien, maar wij kennen de (huidige) codebase van Tweakers niet. Daarnaast hebben de devs van Tweakers ook andere prioriteiten dan enkel en alleen een feature 'voor de leuk' toe te voegen (het helpt immers niet bij de omzet!).

[crisp]

Nu.nl en GS zijn qua codebase veel kleinere en ook jongere sites die waarschijnlijk veel minder legacy en techdebt met zich mee hoeven te zeulen. Grote delen van onze CSS-setup zijn al vele jaren oud en omvatten verschillende generaties design. Het is niet eenvoudig en juist wel arbeidsintensief om daar een andere thema op te bouwen en dat ook te onderhouden.

Het kan inderdaad wel opgezet worden op een manier dat het qua werk op lange termijn meevalt, maar dan moet de hele setup in de basis ook geschikt gemaakt zijn voor het ondersteunen van verschillende kleurthema's. In onze situatie zou dat betekenen dat we grote delen van onze CSS moeten refactoren of herschrijven. Dat is een eenmalige, maar niet triviale klus waar wij op korte termijn helaas geen ruimte voor hebben...

[Falcon]

Deze CSS snippet werkt aardig goed anders:

custom css snippet: Toekomstbestendige nachtmodus

😎

[Sjeefr]

Dit doet meer pijn, dan fijn aan mijn ogen eerlijk gezegd.

[beOnt]

Ik ben ook vragende partij. Momenteel gebruik ik custom CSS, maar het zou beter zijn mocht dit native kunnen, er zitten ook her en der nog fouten in. Voor mijn part hoeft wit zelfs geen optie te zijn, maar meningen verschillen natuurlijk

[Reactie gewijzigd door beOnt op 24 juli 2024 04:51]

[i-chat]

fouten in de css kun je toch prima zelf oplossen of melden bij de persoon die het heeft geplaatst,

ik ben het er mee eens dat tweakers best een oplossing zou kunnen bieden voor een donker thema maar dan zouden ze dat naar mijn idee ook prima via deze oplossing kunnen bieden maar dan dus als officiële theme.

zelf gebruik ik nu een aantal elementen uit een aantal snips en dat werkt aardig maar niet geweldig, misschien ga ik er nog wel eens voor zitten een echt goede theme te maken, verder lijkt een dag-nacht modus me voor somigen ook nog best wel prettig dan gaat om x uur de boel letterlijk op zwart.

[Sebazzz]

Ik vraag mij af hoe jullie het gebruik van Webpack en eigenlijk het Node.js ecosysteem voor jezelf verantwoorden. Dit gezien de staat van dit ecosysteem: een web van duizenden ondoorzichtige dependencies, een slecht doordachte package manager (npm), rijke historie van indicenten (leftpad, en recent is-promise, vele securitylekken).

Begrijp mij niet verkeerd, ik gebruik het ook en op dit moment zijn wij op m'n werk er ook mee bezig. Ik ben gewoon benieuwd hoe jullie dit voor jezelf verantwoord Ondertussen is de beredenatie die wij gebruiken is min of meer "het is de de-facto standaard, dus we moeten ermee leren leven, dus 'pray & hope'".

[Reactie gewijzigd door Sebazzz op 24 juli 2024 04:51]

[crisp]

Vooralsnog wordt node.js alleen gebruikt in het build-proces en zijn we erg voorzichtig met het includen van 3rd-party componenten.

[Sebazzz]

Klopt, maar je hebt nog steeds dezelfde ellende

[watcher46]

Dat is zeker zo, maar dat heb je ook met Composer. En elke andere vorm van package-manager. Je bent afhankelijk van software van anderen. Zoals @crisp zegt, we zijn voorzichtig met wat we includen. Net als we voorzichtig zijn met packages voor PHP.
Ik ben het met je eens dat er met NPM best wat ellende is voorgevallen. Maar ook dat heeft inmiddels wat stappen gemaakt. Maar het wordt voor onze codebase gewoon tijd om het beter onderhoudbaar te maken en dan kom je al heel gauw op deze tools uit.

[AW_Bos]

Trouwens, zijn er ook plannen om de URL's van de topics in het forum ook SEO te maken, zodat de titels daar ook in staan? Of biedt dat volgens jullie geen meerwaarde?

[boenkeijer]

Voor nu nog niet in ieder geval, zoiets moeten we gaan onderzoeken. De meerwaarde voor de categorie en product url's waren nu erg groot, maar als dit voor het forum ook het geval gaat zijn dan is het zeker een optie

[TheNephilim]

Ik ben wel benieuwd of de aanpassingen in URL's meetbaar betere resultaten opleveren voor SEO. Bij veelgehoorde SEO-specialist-opmerkingen kom je vaak tegen dat een ID in een URL (naast naam) heel slecht is; maar is dat ook echt zo?

[PcDealer]

De misbruik-knop staat er nu tweemaal. Wat is de meerwaarde hiervan @boenkeijer?

[ikloon]

We wilden de mogelijkheid om misbruik te melden wat meer in het oog laten springen. Nu is de link ook zichtbaar wanneer een koper (op mobiel) naar de gegevens van de aanbieder kijkt.

[WCA]

Wow, hier zijn een paar langgevraagde veranderingen behandeld! Lekker bezig!

[Anoniem: 372172]

Verbeteringen Vraag & Aanbod helemaal blij mee

[pven]

Nice. Eindelijk!

[Wisher]

Pricewatch & V&A is toch echt wel een speerpunt van deze site. Bijna bij alles wat ik wil aanschaffen ga ik eerst naar de V&A. HEERLIJK om te kunnen filteren op "vanalles-en-nog-wat".

Het is ook de enige site die ik regelmatig doorstuur aan anderen als ze vragen hebben als: "maar wat moet ik dan kopen?" "Nou: filter, filter, filter -->Eentje uit deze lijst is prima voor je".

[Reactie gewijzigd door Wisher op 24 juli 2024 04:51]