Herindeling forum en ontwikkeling wysiwyg-editor - Development-iteraties 229/230

Er zijn weer twee development-iteraties afgerond. In de afgelopen periode hebben we gewerkt aan het verbeteren van de forumindeling en zijn we gestart met twee nieuwe projecten. We willen het plaatsen van een gebruikersreview makkelijker maken en we zijn begonnen met de ontwikkeling van een wysiwyg-editor.

Herindeling Computers-forum

Op het Tweakers-forum wordt dagelijks over de meest uiteenlopende onderwerpen gediscussieerd. Het is interessant om te zien welke thema's op welk moment populair zijn en hoe deze door de ontwikkelingen op techgebied, gecombineerd met de actualiteiten, een mooie afspiegeling vormen van wat ons bezighoudt. Wij vinden het belangrijk dat het forum meegroeit met de tweakers en daarmee ruimte biedt aan onderwerpen die toenemen in populariteit. Daarom introduceerden we vorig jaar de nieuwe hoofdgroep: Wonen en Mobiliteit met daarin populaire forums over onderwerpen als smarthome, zonnepanelen, warmtepompen en elektrische auto's.

In de afgelopen sprint hebben we in dit kader een tweede verbetering doorgevoerd in het forum. We zagen over de afgelopen jaren steeds minder activiteit in een paar forums onder het segment Computers. Omdat dit toch een belangrijk segment is, hebben we er, met het oog op de overzichtelijkheid en de levendigheid, voor gekozen om een aantal forums samen te voegen met gerelateerde forums.

• Opslagtechnologie is hernoemd naar Opslag en back-up
• Overclocking en Cooling & Tweaking zijn samengevoegd in Overclocking, cooling en tweaking.
• Netwerken en Professional Networking & Servers zijn samengevoegd in Netwerken.
• Non-Windows Operating Systems is hernoemd in Linux en overige clients.
• Serversoftware & Windows Servers is hernoemd naar Serversoftware en clouddiensten. Servertopics uit PNS zijn naar dit forum verplaatst.

Wysiwyg-editor voor plaatsen van reacties

Begin 2020, nog voordat de coronacrisis uitbrak, maakten we een inventarisatie van wensen en verzoeken die we in de laatste jaren zijn tegenkomen via bijvoorbeeld de reacties en het forum. Daaruit selecteerden we vijf hoofdthema’s waarop jullie konden stemmen.

Het verbeteren van de gebruiksvriendelijkheid voor het schrijven en opmaken van posts door middel van een wysiwyg-editor kwam bij die stemming als derde uit de bus. Inmiddels zijn we begonnen met de realisatie hiervan.

In eerste instantie richten we ons op de editor van de frontpagereacties. We hebben als doel om de komende sprints toe te werken naar de introductie van een eerste versie van een wysiwyg-editor voor het reageren op frontpageartikelen. Aangezien de opmaakmogelijkheden voor frontpagereacties beperkt zijn, stelt dat ons in staat om alvast een basisopzet te implementeren zonder dat we meteen support voor elke mogelijke opmaaktag hoeven in te bouwen.

Maar ook de implementatie voor enkel de frontpagereacties is niet bepaald triviaal. Voor (tekst)opmaak en het invoegen van bijvoorbeeld links en plaatjes hanteren we nog steeds de oude (U)BBCode (zo wordt de RML-code genoemd, naar de naam van de oorspronkelijke forumsoftware React). Hiermee houden we controle over de uiteindelijk gegenereerde mark-up (HTML), zodat daar een zekere uniformiteit in zit en er geen kwaadaardige code kan worden geïnjecteerd.

Hiervoor worden de ondersteunde tags met behulp van een parser aan de serverkant omgezet naar HTML. Deze parser is door onszelf ontwikkeld en biedt ook speciale mogelijkheden om bijvoorbeeld zogenaamde mentions te herkennen, zodat we daarvoor notificaties kunnen versturen, en om een register aan te houden van onder andere dergelijke mentions, zodat we in de content ook nicknames kunnen aanpassen als een gebruiker op verzoek zijn nickname laat aanpassen, of bij anonimisatie. Een nieuwe editor moet dus uiteindelijk ook ondersteuning bieden voor al dit soort zaken.

Proof of concept wysiwyg-editor

Uiteindelijk is na een lange zoektocht de keuze gevallen op Quill als nieuwe editor. Quill is een opensource-next-gen rich text editor die al wordt gebruikt door een aantal grote partijen, zoals LinkedIn en Slack. Het heeft een modulaire opzet, waardoor het makkelijk uit te breiden is, heeft uitgebreide documentatie en werkt met een intermediate formaat, zogenaamde delta's, die serverside eenvoudig te parsen en te verwerken is. Hierdoor kunnen we de functionaliteit die we nu hebben ingebouwd in onze huidige parser, ook realiseren voor de output van de Quill-editor.

Verbeteren gebruikersreviews

Om bezoekers én medetweakers zo goed mogelijk te helpen beslissen of een aankoop hun al dan niet zuurverdiende centen waard is, zijn gebruikersreviews een handig hulpmiddel. Daarom willen we het plaatsen van een gebruikersreview gaan verbeteren. Om dat goed te kunnen doen, willen we natuurlijk weten wat voor jullie belangrijk is. Zijn dat juist de langere, uitgebreide reviews of toch de kortere varianten? Of volstaat een systeem met sterretjes, duimpjes of Henks? Om meer inzicht te krijgen in jullie wensen vroegen we onlangs via een onderzoek naar jullie mening. De resultaten uit dit onderzoek zullen we binnenkort met jullie delen.

Reacties (40)

Hmm, ergens had ik toch graag gezien dat die oude, ongemakkelijke UBB-tags zouden vervangen worden door Markdown-ondersteuning. Dan hoef je met de nieuwe (of oude) editor je handen niet meer van je toetsenbord te halen om een bepaald woord in het vet of cursief te zetten (in plaats van met je muis op een knop te moeten klikken).

Desondanks wel alweer een mooie update! KUTGW!

Je hoeft nu ook geen muis te gebruiken, naast dat keyboard shortcuts al werken kun je ook gewoon zelf de UBB tags typen.

Ik kan uit ervaring zeggen dat het schrijven van een parser die zowel Markdown als UBB 'verstaat' niet simpel is, omdat de Markdown standaard bijvoorbeeld ook gewoon HTML accepteert en UBB juist niet. Daarnaast zijn er veel multiline dingen in Markdown en zit je met dat line breaks eerst een dubbele spatie vereisen. Dat zijn nog niet alle edge cases, maar wel die waar je het snelst tegenaan loopt.

Omdat bestaande posts ook moeten blijven werken zou er dan dus een middenweg gezocht moeten worden, met hoe dan ook als bijwerking dat dingen die nu in het forum staan die toevallig ook geldige markdown zijn *zoals dit* ook ineens meegenomen zouden worden en er anders uit zouden gaan zien, tenzij er een datum check op laatste edit ofzo in zou zitten.

Zelf getypte tags zie je regelmatig langs komen, en dat gaat nogal eens mis. De kleinste fout heeft tot gevolg dat ze niet werken. Een previewknop zou al een stuk helpen.

Zou inderdaad geen slechte toevoeging zijn bij de nieuws reacties. Tweakers ondersteunt volgens mij wel voor iedere tag de optie om af te sluiten met alleen een slash ([/]), daarmee hak je de foutgevoeligheid al doormidden.

[Reactie gewijzigd door Oon op 30 maart 2022 10:40]

Dat komt omdat de users de / en \ , de [ en [ door elkaar halen of in het geheel niet afsluiten. Door een fout hoort iets niet te werken m.i.

Waar ik meer moeite mee heb is dat op het forum

en

door elkaar wordt ondersteunt en in dm's en reports alleen

.

Dan gewoon verschillende tabjes in de editor: ten eerste in ieder geval de oude UBB-code voor legacy posts en ten tweede WYSIWYG. En dan eventueel nog een tabje erbij voor Markdown. Alle oude posts worden dan in beide omgezet. Niet triviaal nee, maar dat zou volgens mij het beste zijn.

Ik hoop in ieder geval dat oude posts hetzelfde blijven (wat betreft alle functies) en er niet ineens heel lelijk uit gaan zien. Voor de rest vind ik eigenlijk alles wel prima.

Hmmm, hoe bedoel je dat? Want hier kan ik gewoon een woord selecteren en ctrl-b gebruiken om hem vetgedrukt te krijgen, of ctrl-i gebruiken voor italics. Geen muis voor nodig en dat is volgens mij nog steeds met UBB-tags.

Dat klopt, dit inderdaad al jaren beschikbaar. Misschien is het wel een verborgen feature

En vergeet ctrl-k niet voor het ingeven van een link....

O, ik dacht dat dat was met win cmd format c?

Ik heb even gespeeld met de playground en shortcuts als CTRL+B en CTRL+I zorgen gewoon voor bold en italic respectievelijk. Als ze het dus implementeren zoals Quill op hun site heeft staan zal je alles makkelijk met je toetsenbord kunnen blijven doen.

Ik heb zelf ook Quill gebruikt en ik ben er mee gestopt omdat het helaas niet helemaal WYSIWYG is. De ondersteuning van nested lists is er helaas niet en de ontwikkelaars vinden dat een 'enhancement' en geen bug. Ze raden zelf aan om CSS te gebruiken om de onjuiste semantiek te compenseren.

Uiteindelijk ben ik zelf maar voor Markdown gegaan. Bijkomend voordeel was voor ons dat de tekst ook zonder parsen acceptabel is (ook voor non-techies) en we onze teksten ook wel eens naar externe partijen sturen die geen HTML ondersteunen.

Ik ben benieuwd of Tweakers ook heeft overwogen om naar (een dialect van) Markdown over te stappen. En als Quill echt wordt gebruikt: gaan jullie een bijdrage leveren om nested lists ook goed te ondersteunen?

En over de userreviews: ik zou graag hoofdstukken kunnen toevoegen, zoals ook de redactie dit kan. Of beter gezegd: ik heb graag dan anderen dit doen, zodat ik de ellenlange unboxing experience en opsomming van alle specificaties kan overslaan in de reviews.

[Reactie gewijzigd door StephanVierkant op 30 maart 2022 10:49]

We liepen zelf al tegen deze aan: https://github.com/quilljs/quill/issues/1121

We gaan daarom kijken of we dit zelf op een of andere manier beter kunnen oplossen; zaken die ook semantisch in markup moeten kloppen wil je niet plijsterfiksen met CSS

Markdown zou wellicht voor de reakties onder artikelen nog wel een optie zijn geweest, maar voor het forum willen we straks ook gewoon opmaakmogelijkheden en plaatjes e.d. ondersteunen, en dan is wysiwyg toch wel van grote meerwaarde. Verschillende soorten markup ondersteunen (en onderhouden) is ook niet echt wenselijk, dus vandaar dat we niet voor markdown gekozen hebben.

En over de userreviews: ik zou graag hoofdstukken kunnen toevoegen, zoals ook de redactie dit kan. Of beter gezegd: ik heb graag dan anderen dit doen, zodat ik de ellenlange unboxing experience en opsomming van alle specificaties kan overslaan in de reviews.

Hoofdstukken zijn al 10 jaar of langer toe te voegen in reviews.
Als je op zo'n hoofdstuk klikt bij de inleiding, dan ga je direct naar dat stukje van de review toe. Het is daarbij wel goed om te weten dat je de pagina nog wel even moet inladen (op een smartphone).

Je mag het wel uitproberen in mijn review.

Moeten vragen over *NIX servers dus nu in Serversoftware en clouddiensten? Blinkt IMO niet echt uit in duidelijkheid.

Ha, precies mijn eerste gedachte bij het lezen van de indeling. Maar goed, plof je topic ergens neer en een mod lost het wel voor je op

Hoe had je het anders gezien? Aparte forums voor Windows en Unix/Linux server software of aparte forums voor Windows en Unix/Linux maar dan wel client en server software op één hoop?

Ik zou wel graag een afsplitsing zien tussen Windows serversoftware en *nix serversoftware ja, dan hoef ik niet door de Windows topics te scrollen wat, voor mij, interessants tegen te komen. De focus ligt daar nogal op Windows Server, exchange en AD.

Sterker nog, wellicht een algemeen *nix forum erbij, want eigenlijk passen topics als 'Het Grote Ubuntu Topic' en 'Het grote welk OS (bijvoorbeeld linux distro) topic' eigenlijk niet in beide, tenzij ze alleen maar over clients mogen gaan.

Zal ook wel met de populariteit van de fora te maken hebben, maar een splitsing tussen Windows en *nix server onderwerpen zou best kunnen. (ja waar plaats je je WSL vraag dan?). Mijn punt was uiteindelijk meer dat het volgens mij geen doodzonde is om hier een keer een foute keuze in te maken.

Cliënt en server software bij elkaar gooien lijkt mij dan weer helemaal niets. Kan me goed voorstellen dat mensen die willen discussiëren over de ideale docker configuraties weinig behoefte hebben om door de "help mijn driver doet het niet" topics te moeten scrollen.

*Nix en overige clients... maar MacOS krijgt weer een aparte status...

Ik ben benieuwd op wat voor manier de parser de content bij het bewerken van een bericht van RML-code omzet naar de WYSIWYG text? Je zult dan op zijn minst de bestaande RML-parser moeten dupliceren naar JavaScript, lijkt me?

Ik ben benieuwd hoe dit getackled wordt?

We zitten er aan te denken om de huidige reacties die in RML zijn opgemaakt om te zetten naar delta-formaat. Wanneer de uiteindelijke HTML niet teveel afwijkt van de huidige zouden we dat eenvoudig vanuit de geparsede versie kunnen doen, en anders zullen we daar waarschijnlijk een migratie-parser voor moeten schrijven.

We zijn dus eigenlijk niet van plan om de RML-versies te blijven ondersteunen, zeker niet voor de frontpage reacties die je toch maar een beperkte tijd kan wijzigen.

Dus (on the fly) de berichten in RML omparsen naar de JSON-formatted formaat? Dat wordt dan een hoop extra opslag dan.

Nee, niet on the fly maar eenmalig En opslag zal wel meevallen, zeker als de RML-versie uiteindelijk weg kan

Met custom CSS

Uiteindelijk is na een lange zoektocht de keuze gevallen op Quill als nieuwe editor. Quill is een opensource-next-gen rich text editor

Quill is helemaal niet zo next-gen, Quill gebruikt:
* Deprecated execCommand
* WebPack (overhead)

Om problemen voor te zijn met bovenstaande, kwam ik na een lange zoektocht uit op Squire, maar die past waarschijnlijk niet goed bij jullie wensen.

Ik hoop dat jullie in de toekomst niet in de problemen komen en dat Quill de problemen oppakt.

Overigens gebruiken we Webpack al in onze nieuwe frontend setup, dus Quill toevoegen zal niet zo'n issue zijn.

[Reactie gewijzigd door XWB op 30 maart 2022 10:59]

Duidelijk. Jammer dat er voor webpack is gekozen maar begrijp wel waarom.
Het is ook niet zo'n issue vanwege het goede 4G/5G bereik in NL.

Bestaat er een alternatief voor Webpack dat minder overhead genereert? Of is het alternatief handwerk?

Er zijn alternatieven, zoals: Rollup, Gulp, Closure Compiler, etc.

En je kan natuurlijk JS6 modules gebruiken om alleen dat te laden wat je gebruikt.
Best zinloos om Quill in je webpack te proppen als 9 van de 10 keer het niet nodig is.

[Reactie gewijzigd door DJMaze op 30 maart 2022 16:18]

Liever 'gewoon' hoe Github het doet, en vele andere systemen. Markdown dus.

Wysiwyg is altijd kut. Ik hoop dat het uit kan. Sorry als dat als domper over komt, maar het is gewoon een mening die ongetwijfeld een hoop mensen delen. Het is hartstikke mooi voor sommige mensen, maar er zijn hele volksstammen die liever gewoon typen.

Dat UBB ouderwets is, en vooral onhandig om te typen, staat vgs mij buiten kijf. Maar ik vind écht niet dat alléén wysiwyg de oplossing is.

Als alternatief zou die wysiwyg-editor ook een laag bovenop de huidige UBB kunnen zijn. Het het italic-knopje voeg dus een UBB-code in.

Kan best zijn dat dit ook zo gaat werken als ik de beschrijving lees van de aanpak, ik vermoed dat het erop neer komt dat de UBB tags 'on the fly' worden omgezet in de WYSIWYG editor, en dat je die met knoppen kan aansturen.

Je kan dit vergelijken met de 'ouderwetse' wysiwyg editors, waar je in een HTML weergave kan editen (dat zou in dit geval dan de UBB weergave zijn), of in een grafische weergave, dus zoals het er in de post uit komt te zien. Iig oudere wysiwyg editors ondersteunden verschillende modi om mee te werken. In mijn ogen is dat ook de zuiverste manier om dit aan te pakken, zonder dat de bestaande UBB codes (waar mensen toch ook echt aan gewend zijn) hierdoor verloren raken.

Tip voor de redactie. Installeer https://www.nvaccess.org/ of iets dergelijks (gratis, ook in Nederlads instelbaar). Trek je muis uit je pc, zet de luidspreker aan. Probeer dan eens met alleen het toetsenbord een Tweakers artikel te zoeken ("element 4 van 79, element 5 van 79, element 6 van 79") of een reactie in te typen.

Misschien realiseert de redactie dat de Tweakers website veel doorzettingsvermogen nodig vraagt voor de lezer die slechte ogen heeft. Door de onhandige indeling, sequentieel doorlopen van eindeloos lange reeksen voordat je bij de juiste knop/artikel/menuonderdeel bent.

Hou er rekening mee dat over een paar jaar uitgevers "verplicht" hun inhoud toegankelijk moeten aanbieden.

Het zou mooi zijn als ze dit bij hun nieuwe opmaak gaan inbouwen, die momenteel op de frontpage wordt uitgetest, zolang je de betatest daar aan hebt staan.

Ook het moderaten van reviews mag wel wat meer onder de aandacht komen.

Philips Hairclipper Series 9000 HC9450/20 review door Kuusje

5.687 views, 20 moderaties. Nog geen procent van de viewers laten een moderatie achter. Voor de gene die de review schreef is dat niet altijd even leuk, waarmee we weer uit komen bij
Hoe kunnen we gebruikersreviews beter maken voor jullie?

Dat kan natuurlijk ook komen omdat mensen niet ingelogd zijn, geen mod-rechten hebben of helemaal geen account hebben die de reviews lezen.

Of volstaat een systeem met sterretjes, duimpjes of Henks?

Wat is een Henk?

Zelf zou ik trouwens het liefste vooral lange reviews zien. wil je het kort, dan ga je gelijk naar de conclusie van zo'n lange review. Korte reviews of enkel een score/duimpjes geeft Tweakers niet veel meerwaarde meer over andere platformen.

Wie is Henk?

Henk, onze officieuze mascotte die nog altijd voortleeft in de harten van duizenden tweakers.

reviews: De geschiedenis van Tweakers.net: ontstaan en hobbyfase

Wat is 'een Henk geven'?
[Feat] De 'Henk' knop (Tweakers like-knop)

[Reactie gewijzigd door GZFan op 30 maart 2022 14:50]

WYSIWYG is (iig voor mij) een welkome toevoeging op touch. Ik gebruik het forum weinig, behalve sinds de oorlog in Oekraïne. Nu merk ik hoe zeer ik dat mis tov frontpage. Bedankt