Vernieuwing van navigatiestructuur en editorplannen - Development-iteratie #303

De eerste sprint van 2025 is achter de rug. In deze sprint hebben we gewerkt aan het vernieuwen van de hoofdnavigatie op de site. Ook hebben we de plannen voor de realisatie van een modernere editor afgestoft. Hieronder lees je over deze vernieuwingen en wat we nog meer gedaan hebben de afgelopen tijd.

Vernieuwde hoofdnavigatie

Om de gebruikservaring op mobiele apparaten te verbeteren hebben we de werking van de hoofdnavigatie soepeler en eenvoudiger gemaakt. Voorheen toonden we op kleine beeldschermen aan weerszijden van de navigatiebalk hamburgericonen met menu's die in een paneel links of rechts van de site werden weergegeven. Bij het openen verschoof de inhoud van de pagina en ook de positie van het hamburgericoon. Om het menu weer te sluiten moest je je vinger verplaatsen.

In de nieuwe mobiele navigatie hebben we ervoor gekozen om submenu's als overlay te openen. Het hoofdmenu blijft op zijn plek staan, zodat er geen vingerbeweging meer nodig is om het menu te sluiten. In de onderstaande screenshots zie je de oude en nieuwe hoofdnavigatie naast elkaar:

De persoonlijke menu's in de rechterkant van de navigatie, zoals je gebruikersmenu, notificaties en berichten, worden ook als overlay geopend en zijn vanaf heden rechtstreeks bereikbaar. Er zijn minder handelingen nodig om naar je notificaties of berichten te gaan en je ziet meteen of een nieuw item een notificatie of bericht betreft. Verder is er nu meer ruimte in de breedte beschikbaar voor de weergave van items in je vergelijkingslijst, berichten en notificaties.

De wijzigingen zijn aangegrepen om de mark-up en de JavaScript van de hoofdnavigatie grotendeels te herschrijven. Hiermee hebben we veel techdebt in de code van de hoofdnavigatie afgelost. Tevens hebben we aandacht gegeven aan de toegankelijkheid van de navigatie voor slechtzienden. Zij kunnen nu makkelijker in screenreaders navigeren en naar de eigenlijke inhoud van de pagina springen.

Op de desktop is de navigatie onder de motorkap vernieuwd, maar zijn de visuele wijzigingen beperkt tot subtiele verschillen zoals de gebruikte iconen en de hiërarchie in het gebruikersmenu.

Met deze aanpassingen kan het zijn dat custom CSS die aanpassingen deed in de navigatie niet meer naar behoren werkt.

Uitleg over sortering

Om duidelijker te maken hoe de verschillende listings op de site gesorteerd worden, hebben we op de daarvoor relevante plekken een informatie-icoontje toegevoegd. Als je op dat icoontje tapt of klikt, opent een schermpje met daarin de uitleg.

Aanpak wysiwygeditor

Het is alweer een tijd geleden dat we erover hebben geschreven: de wysiwygeditor. In maart 2022 kondigden we aan dat we begonnen waren met een project om het gemakkelijker te maken reacties met opmaak te schrijven. Helaas moesten we om diverse redenen het project vrij snel daarna in de ijskast zetten.

Met een nieuw jaar willen we het project nieuw leven inblazen. Het voordeel van het stilleggen van zo'n project is dat we er een frisse blik op kunnen werpen. Hierdoor kwamen we tot de conclusie dat we het toch anders willen aanpakken dan de vorige keer.

Laten we beginnen bij het begin. Toen we zo'n drie jaar geleden begonnen, was het idee dat we een nieuwe editor zouden maken in isolatie, die we later aan de website zouden koppelen. We begonnen met het maken van een editor in onze storybookomgeving en zouden deze naar productie brengen zodra hij klaar was. Door deze manier van werken zorgden we ervoor dat gebruikers niet opgescheept zaten met een half werkende editor. Bovendien konden we in de testomgeving eenvoudig verschillende producten uitproberen, omdat we geen rekening hoefden te houden met de rest van onze codebase.

Dankzij deze aanpak waren we zo flexibel dat we zelfs geen rekening hoefden te houden met RML en we een ander formaat konden gebruiken. Nadat het werk in isolatie klaar zou zijn, zouden we eenmalig bestaande inhoud omzetten van RML naar het nieuwe formaat. Op deze manier hadden we geen 'last' van compatibiliteit met RML. Deze flexibiliteit hebben we destijds goed benut. Onze eerste implementatie maakten we op basis van Quill, maar deze bleek toch ongeschikt door de manier waarop wij gestructureerde inhoud gebruiken. We konden toen alles eenvoudig weggooien en opnieuw beginnen met Tiptap door de oude code weg te gooien.

Helaas zit er ook een keerzijde aan deze manier van werken, die versterkt werd doordat het project na een paar iteraties stil kwam te liggen: het project is eenvoudig te vergeten. Juist omdat er niets naar productie gaat, is er geen impuls om het verder te ontwikkelen.

Daarom pakken we het deze keer anders aan. We gaan het gefaseerd uitvoeren, waarmee we sneller code naar productie brengen. We willen beginnen met het ontwikkelen van een editor die met RML werkt, waarbij je op elk willekeurig moment kunt wisselen tussen wysiwyg en RML. De eerste versies van deze nieuwe editor kunnen we dan met een kleine groep medewerkers testen door gebruik te maken van een featureflag.

Naarmate de editor completer wordt, breiden we de groep uit die de editor kan testen, om op een gegeven moment een versie als bètafeature aan te bieden aan de grootste groep testers. We blijven ondertussen de editor uitbreiden, maar kunnen al bugmeldingen en andere feedback verwerken. Wat we wel hetzelfde doen als de vorige keer, is dat we eerst de editor voor frontpagereacties maken. De opmaakmogelijkheden voor frontpagereacties zijn beperkt, waardoor we hiervoor als eerste een volledig werkende editor kunnen maken.

Als de gefaseerde aanpak voor frontpagereacties goed verloopt, kunnen we de editor ook gefaseerd op andere plaatsen vervangen. Als de editor overal vervangen is en compatibiliteit met RML niet meer strikt noodzakelijk is, kunnen we besluiten of we RML willen vervangen door een ander opmaakformaat.

Reacties (73)

[RubjeMazter]

Het ziet er an sich prima uit maar het is wel vervelend dat de notificatie knop niet meer in de hoek zit maar 1 plek is opgeschoven. Nu gaat mijn automatisme met 'beweeg naar de hoek' niet meer op... Kunnen jullie hier een toggle voor maken dat je 't kan omdraaien of moet hier custom css aan te pas komen?

[Cavalera125]

Of de settings knop (tandwiel met taalinstelling) verplaatsen naar de user profile settings. Kan me niet voorstellen dat die knop veel gebruikt wordt.

[Skit3000]

Dat was ook mijn gedachte, totdat ik bedacht dat bezoekers zonder account nog wel de landinstellingen voor webshops en het thema moeten kunnen wijzigen (en zij hebben geen profielmenu). Overigens weet ik niet of de instelling voor welke webshops je wilt zien wel een site-wijde instelling moet zijn of alleen op de Prijzen pagina in de Pricewatch (of op het vergelijkingslijst-menu)?

Ik vraag me ook af of notificaties en berichten wel aparte menu's moeten zijn. In het berichtenmenu zie je namelijk alleen maar notificaties (!) als er nieuwe berichten zijn, maar zodra je ze leest verdwijnen ze. Deze twee menu's samenvoegen zou dus misschien zo slecht nog niet zijn (je kunt dan ook gelezen berichten blijven tonen) en scheelt weer een knop.

Overigens vind ik de menu's zo wel een heel stuk beter!

[HollowGamer]

Mijn OCD zegt ook dat de padding (vooral x) in de Settings anders is dan de andere. 😅

[tszcheetah]

Het is inderdaad niet heel handig nu, dat ben ik met je eens. Ik heb het advies van @crisp maar opgevolgd en custom CSS gemaakt: Verberg Weergave-opties in menu

Hiermee wordt de settings-knop verborgen en staan de notificaties weer helemaal rechts. De weergave-opties (land en thema) zijn altijd nog bereikbaar via de layout-instellingen onder je profiel, mocht je het nodig hebben.

[Soppyscroll]

Zo die heb ik er direct op gezet, begon mij al te irriteren.

[Executor16]

Dank!

[rens-br]

Verrek. Merkte precies hetzelfde ja. Weet helemaal naar rechts verhuizen zou wel prettiger zijn ja.

[crisp]

De volgorde van de icons is helemaal niet gewijzigd, zie dit plaatje: https://tweakers.net/foto...8K9oK7gjYKUnFeP342FkQ.png (boven: oud, onder: nieuw)

Edit: ik werd er net op gewezen dat het voorheen op mobiel wel anders was. Dat hebben we dus inderdaad nu consistent gemaakt met de deskop view.

Je zou inderdaad met custom css het instellingen-icon kunnen verbergen of verplaatsen.

[Reactie gewijzigd door crisp op 23 januari 2025 10:20]

[rens-br]

Zouden we wellicht het verzoek in mogen dienen om het consistent te maken met de oude mobiele weergave?

[crisp]

Dat mag, maar dan krijg je waarschijnlijk wel alle desktopgebruikers op je nek

[rens-br]

Geen probleem. Ik heb een hele dikke nek.

[Reactie gewijzigd door rens-br op 23 januari 2025 12:07]

[Slavy]

Na het posten van dit bericht is mijn hele navigatiebalk in de war (desktop) en als ik de notificaties open zie ik de tekst driedubbel staan met allerlei emoticons er doorheen.

Edit: Darkreader plugin was de oorzaak.

[Reactie gewijzigd door Slavy op 23 januari 2025 10:20]

[RobbyTown]

CTRL + F5 doet misschien wonderen?

[Slavy]

Helaas niet, zelfs de browser compleet herstarten doet het hem ook niet.

[Asitis]

Wellicht oude custom CSS of een darkreader-extensie? Daar zie ik dat ook nog wel eens mee gebeuren.

[WillySis]

Dank voor de tip. Die gooit bij mij ook het rechter deel van de navigatiebalk door de war.
Nog wel wat werk aan de winkel, want Darkreader hoort gewoon te werken.

[crisp]

Darkreader doet zelf allerlei styling injecteren; problemen daarmee zal je dus ook bij hun moeten melden aangezien wij daar niets mee (kunnen) doen: https://github.com/darkreader/darkreader/issues

[crisp]

Custom CSS wellicht? Of anders Darkreader plugin (zie forumtopic: Dubbele weergave menu rechtsboven)?

[njitter]

inderdaad Darkreader. Neem aan dat de DEVjes hiermee aan de slag gaan. Want ik heb het liefst alles in Dark Mode.

[crisp]

Wij hebben zelf gewoon een darkmode tegenwoordig: .plan: Join the dark site - Native dark mode voor Tweakers

[njitter]

Dank! Ook weer opgelost

[HollowGamer]

Ik snap de move naar RML niet zo? Had er ook nog nooit van gehoord. Zo te zien is het een React markup taal?

Waarom niet gewoon Markdown? Je kunt daar ook alle tags toevoegen die je wilt, en custom kun je parsen. Het lijkt fijner voor de eindgebruiker, maar ook voor jullie die het in de database moet omslaan.

Een eigen editor is lastig, je moet veel onder water doen, en jullie hebben ook nog mensen die van verschillende browsers komen (gok meer dan de gemiddelde NU.nl bezoeker).

Verder kloppen de notificaties niet (helaas). Ik heb ze net op 'alles gelezen ' gezet, maar het icoontje zegt 11 bijgekomen.. ik snap dit, want ik denk dat jullie code base inmiddels 15 jaar oud is, en al veel stuff heeft meegemaakt, dus er zal vast iets misgaan in de pipeline.

Dat bedoel ik trouwens als een compliment. De meeste beginnen tegenwoordig om de 5 jaar opnieuw (geen grap).

[Reactie gewijzigd door HollowGamer op 23 januari 2025 11:26]

[DaFeliX]

RML is wat we nu gebruiken, dus we gaan niet naar RML, maar misschien dat we straks van RML naar iets anders gaan. Om het uitrollen van de nieuwe editor makkelijker te maken gaan we de editor ondersteuning geven voor RML. Zo hoeft er aan de backend niets te veranderen, kan je oude berichten geschreven in RML aanpassen in de nieuwe editor én kun je altijd heen-en-weer schakelen tussen de "rauwe opmaakcodes" en "WYSIWYG".

Voor wat betreft Markdown, dit formaat is voor ons ongeschikt omdat bijvoorbeeld nesting binnen een tabel niet mogelijk is. We zullen dus niet naar Markdownformaat gaan. Wel willen we Markdownnotatie in de editor zelf ondersteunen, dus je typt twee sterretjes, woord, twee sterretjes en dan word 't woord dikgedrukt.

[AW_Bos]

Even handig om te vermelden voor @HollowGamer : De React mark-up heeft niks met de populaire React-library te maken wat webdevelopers nu gebruiken. Het is afkomstig uit de forumsoftware van wat hier vroeger toevallig ook React heette, en ergens in 2002 werd geïntroduceerd (na het brakke Topix). RML kan je vergelijken met UBB-codes, maar dan met wat extra mogelijkheden.

[Reactie gewijzigd door AW_Bos op 23 januari 2025 11:39]

[HollowGamer]

Ah, bedankt voor de opheldering! Ik had er nog nooit van gehoord, dacht namelijk dat Tweakers bbcode nog gebruikte.

[DaFeliX]

We gebruiken Tweakers RML, wat een versie van RML is, wat dan weer een variant is van (U)BB code

[Webgnome]

waarom zou je van RML afstappen?

[AirX]

Op een iPhone SE (2016 met iOS 15.8.3) werkt de navigatie niet meer. Notificaties zijn niet te openen en menu helemaal links boven ook niet meer.

[crisp]

Ik ben even aan het kijken wat het probleem is met oudere iOS devices; het lijkt er inderdaad op dat wij nu iets gebruiken dat daar nog niet in ondersteund wordt...

[crisp]

Ik heb wat dingen aangepast zodat het als het goed is vanaf iOS 14 weer zou moeten werken

[AirX]

Het werkt weer. Dank!

[The Zep Man]

Is het een idee om RML na verloop van tijd te vervangen met (verdunde) Markdown? Dat schrijft een stuk simpeler en prettiger.

[DaFeliX]

Het idee is dat we Markdownnotatie ondersteunen in de editor. Dat wil zeggen, je typt twee sterretjes, woord, twee sterretjes en dan word 't woord bold (eventueel terug te draaien door undo/CTRL+z te doen). Dus qua schrijven gaan we "markdown" ondersteunen.

Maar RML vervangen door markdown gaan we niet doen, omdat de nesting niet volstaat voor ons gebruik. Het is dus niet dat RML vervangen gaat worden door Markdown.

[HollowGamer]

Wat precies volstaat niet in nesting? In Markdown kun je toch gewoon dat doen met spaties?

Of welke beperking lopen jullie tegenaan?

[DaFeliX]

Met nesting bedoel ik verschillende soorten tags in elkaar. Voor reacties is dat een probleem bij quotes, maar op het forum heb je nog wel 'ns zeer uitgebreide topicstarts met tabellen en andere opmaak. Het gaat dus niet zozeer om indenting.

Markdown zelf werkt daar omheen door HTML toe te staan, maar dan zouden we net zo goed helemaal naar HTML kunnen gaan. Maar dat willen we niet, omdat we nu eenmaal zitten met gebruikers die we niet kunnen vertrouwen qua input

[The Zep Man]

Bedankt voor de verduidelijking!

Eens over dat HTML een slecht idee is. Over de gekozen koers lijkt goed nagedacht.

[Martinspire]

Je hoeft niet alle HTML tags toe te staan en ook deze xss is wel te pakken met bepaalde Regex. Of doe eens stoer: een AI

Maar goed, je zou er natuurlijk voor kunnen kiezen om de gebruiker zelf te laten bepalen welke variant ie wil gebruiken voor zijn bericht. Extra waarde per post voor welk type en je kiest vervolgens de juiste parser om de reactie op te bouwen. Ik verwacht dat voor veel gebruikers markdown veel natuurlijker zal zijn in 2025, dan RML. Maar ik snap waarom je die niet helemaal wilt vervangen en ik denk ook niet dat iemand daar om vraagt.

Markdown opent ook de deur naar een echte WYSIWYG editor, wat voor de minst ervaren of technisch onderlegde gebruikers ook een voordeel is, dus wie weet open je daarmee de deur naar een grotere doelgroep om uberhaupt te reageren met wat meer dan alleen tekst.

[RobIII]

met bepaalde Regex

Oh de onschuld

[RobertMe]

Op mobiel (Firefox Android) zie ik nu elke page load even 3x een "0" badge op de 3 icons van vergelijk, DM en notificaties voordat deze verborgen worden, vrij storend IMO.

En op het forum lijkt het scrollen naar posts (/aanklikken van eender welke link naar een post, zoals een notificatie of het topic icon om verder te lezen) mis te gaan. Voorheen werd natuurlijk niet de post helemaal bovenaan gezet omdat die dan onder de navigatiebalk (met fixed position) zou verdwijnen. Echter lijkt nu die ruimte voor de navigatiebalk nog "gereserveerd" te zijn. Waardoor dus elke keer de laatste zin van het vorige bericht er nog staat (daar waar voorheen de navigatiebalk er overheen stond).

[crisp]

Thanks! Dit zijn zo te zien wel dingen die we nog kunnen verbeteren, hoewel het issue met de "0"-badges wel specifiek Firefox Android lijkt te zijn...

[RobertMe]

Ik heb ook het idee dat de navigatiebalk niet altijd (/vaker niet dan wel?) verschijnt bij het terug naar boven scrollen, waardoor ik dus helemaal terug maar boven moet scrollen (of dat kleine knopje zoeken) of nog een keer omlaag om weer de balk te krijgen.

[crisp]

Ik zag daar nog een dingetje dat ik niet helemaal goed had overgenomen uit de oude code wat kan verklaren dat het wat minder 'responsive' was dan voorheen. Dat heb ik bij deze herstelt; helpt dat?

[RobertMe]

Jup. Het lijkt nu weer zoals vanouds te werken. En als ik het goed zie is het dingetje met de badges en archors ook opgelost?

[crisp]

Inderdaad Top!

[Barleone]

Op mijn iPhone 7 doet de notificatie knop niks meer, ook het tandwieltje doet niks.
De andere knoppen ook niet.
De profiel knop werkt wel.

[Reactie gewijzigd door Barleone op 23 januari 2025 10:54]

[crisp]

Welke iOS versie draait 'ie?

Ik heb zojuist wat aanpassingen gedaan specifiek voor zaken die in iOS 14 en 15 niet werken in Safari. Hopelijk lost dat het op

[Barleone]

ios 15.8.3
@crisp
Het lijkt nu te werken maar niet vlekkeloos.
Het notificatie venster komt in beeld en is meteen foetsie

[Reactie gewijzigd door Barleone op 23 januari 2025 14:47]

[crisp]

Helaas heb ik alleen browserstack tot mijn beschikking, maar daar zie ik geen problemen (meer) in iOS 15.3 en iOS 15.4 op een iPhone XS en een iPhone 11. Helaas zit daar geen iPhone 7 in; wel een iPhone 8, maar die is met iOS 11 die we sowieso niet meer ondersteunen.

Het is voor mij dus een beetje koffiedik kijken waarom het bij jou nog niet goed werkt helaas...

[Loller1]

Is het de bedoeling dat de editor uiteindelijk wel Tiptap-gebaseerd gaat zijn?

[DaFeliX]

Neuh.

Prosemirror staat op ons lijstje van potentiële kandidaten (samen met CKEditor 5 en Slate). Als we besluiten voor Prosemirror te gaan dan zou Tiptap het overwegen waard zijn. Het enige probleem is dat Tiptap voor onze situatie best wel prijzig lijkt te zijn...

[Loller1]

Ik bedoelde eerder de open source packages en niet zozeer de dienst. Aangezien deze blog ook al aanhaalde dat het originele project Tiptap-based was. Voor welke reden zouden jullie mogelijk moeten betalen bij Tiptap wat gratis is bij de rest?

[Toet3r]

Ik merkte veranderingen doordat mij custom css stuk was.

[Beta]

Idem hier. Kan de notificaties niet zien.
Ach daar is het custom css voor, eigen risico ;-)

[CriticalHit_NL]

Hopelijk kan de product-review editor ook een upgrade verwachten wat betreft wysiwyg want op dit moment is het nogal tijdrovend (en eigenlijk gebruikersonvriendelijk) om zoveel tijd te moeten besteden aan het correct invoeren van alle code tags zodat de opmaak een beetje fatsoenlijk is, en je ziet de foutjes snel over het hoofd bij een grote review waardoor je telkens moet submitten en dan weer zoeken of het nu wel klopt etc etc.

Verder zou ik graag zien dat de review editor automatisch te grote afbeeldingen, dus ook van externe bronnen, kan schalen binnen de maximale breedte van de viewport van de review.
Nu is het zo dat alle afbeeldingen die breder zijn dan ~620 pixels gewoon buiten beeld vallen.
Dan kan je zeggen, dan resize je alle afbeeldingen toch gewoon op basis van de aspect ratio en plaats ze dan?
Maar dat is onhandig omdat bij grotere afbeeldingen dan informatie vrijwel onleesbaar wordt, het erop kunnen klikken voor een vergrootte versie is dan ook een must, net iets wat dus niet standaard kan.

Dus wat ik nu doe is alles bij een externe host uploaden, en dan op basis van de 620 pixel breedte de hoogte aanpassen van iedere afbeelding (de groottes wijken ook vaak af en dus betekent dat veel wijzigen) en dat hardcoden in de IMG tags, dat vergt voor 50-100 afbeeldingen toch wel zoveel werk dat je er nog maar weinig plezier aan overhoud een enigsinds uitgebreide review te tikken.

[Femme]

Je hebt helemaal gelijk dat de omgang met afbeeldingen in reviews beter moet. Het zou gewoon moeten werken zoals op het forum met een mogelijkheid om afbeeldingen te uploaden en deze via de editor makkelijk inline in je review te plaatsen.