Door Sander den Heijer

Product Lead

Wysiwygeditor en verbeterde toegankelijkheid - Development-iteratie #306

05-03-2025 • 08:58

120

De afgelopen development-iteraties zijn we verder gegaan met onze vernieuwingsplannen voor de editors. Ook hebben we de site op het punt van digitale toegankelijkheid verbeterd. Hieronder lees je over deze vernieuwingen en wat er nog meer speelde de afgelopen tijd.

Voortgang wysiwyg

We zijn de afgelopen sprints verder gegaan met het uitwerken van de wysiwyg; een manier om reacties met opmaak te schrijven in een visuele editor. Omdat er veel verschillende library's zijn die we zouden kunnen gebruiken, zijn we eerst begonnen met het selecteren van goede kandidaten. Een belangrijk criterium waar de library aan moet voldoen, is het kunnen ondersteunen van onze eigen RML. Daarnaast keken we ook naar de licentie, hoe actief deze library onderhouden wordt, hoe eenvoudig deze te beheren is en of deze aansluit bij onze manier van werken.

Van de 50 kandidaten vielen er een hoop direct af. Bijvoorbeeld omdat zij niet actief onderhouden werden. Voor elk van de overgebleven 12 kandidaten hebben we vervolgens de documentatie en readme bestudeerd en een poging gedaan om in te schatten hoe eenvoudig het zou zijn om RML-ondersteuning in te bouwen. Na deze tweede schifting hielden we uiteindelijk drie kandidaten over: CKEditor5, ProseMirror en Slate.

Om een keuze te kunnen maken tussen deze drie hebben we voor elk een proefimplementatie gemaakt. We kwamen daarna tot de conclusie dat ProseMirror de beste lijkt te zijn voor onze situatie. We merkten echter ook dat ProseMirror tóch best veel boilerplate code nodig heeft. Daarom besloten we om ook weer Tiptap te bekijken.

demo editor .plan
Screenshot van de editor demo

Lezers die de vorige .plans hebben gelezen, zullen deze naam herkennen omdat we die library de vorige keer ook hadden gebruikt. Dat wil niet zeggen dat de afgelopen sprints voor niets zijn geweest. We hebben nu immers goed uitgezocht dát Tiptap de beste library voor onze situatie lijkt te zijn. En we gaan daar nu dus op door.

Verbeterde digitale toegankelijkheid

Bij Tweakers streven we ernaar om onze website toegankelijk te maken voor iedereen, inclusief mensen met bijvoorbeeld een visuele beperking. Met de komst van de European Accessibility Act (EAA) in juni van dit jaar worden digitale diensten verplicht om te voldoen aan strengere eisen op het gebied van digitale toegankelijkheid. Om hierop voorbereid te zijn, hebben we de afgelopen maanden een aantal verbeteringen doorgevoerd.

Denk hierbij aan beter gestructureerde HTML, verbeterde ondersteuning voor screenreaders en een meer intuïtieve navigatie. Concreet zijn dat bijvoorbeeld beschrijvende labels op diverse knoppen, een verbeterd contrast van de moderatiescores, grotere knoppen in de paginering (nog niet op het forum) en skiplinks naar filters in de Pricewatch. Deze aanpassingen zorgen ervoor dat onze content eenvoudiger te begrijpen en te gebruiken is voor mensen die met een screenreader werken.

Storing op 19 februari

Op woensdag 19 februari was de site laat in de avond offline. Dat is vervelend natuurlijk, en in het algemeen kunnen we dergelijke storingen snel oplossen. Ditmaal duurde het toch iets langer omdat we het probleem niet direct zagen. Achteraf kunnen we er natuurlijk wel wat over zeggen. Wat was er aan de hand?

Het probleem speelde in onze engine. Dit is een in Java geschreven applicatie die we gebruiken als een soort zoekmachine. Deze applicatie laadt een hele hoop data in het geheugen zodat we sneller een antwoord krijgen dan wanneer we via onze PHP-code de database zouden bevragen. Tweakers gebruikt de engine veelvuldig. Als de engine faalt, faalt de hele website en daarom draait deze engine zes keer op zes verschillende servers.

Nu was het vervelende dat we niet direct in de dagen voor de storing iets aangepast hadden wat dit zou kunnen verklaren. Wel hadden we onlangs iets aangepast aan de garbage collection van de engine. Ook hebben we wel wat databaseaanpassingen gedaan die invloed zouden kunnen hebben op het (niet) functioneren van de engine. Helaas bleek het terugdraaien van die aanpassingen het probleem niet op te lossen. Omdat de engines na een herstart vrij snel niet meer reageerden, maakte dit het onderzoeken van het probleem erg lastig.

Uiteindelijk bleek het te liggen aan iets heel anders. Er was recent een extra 'grootheid' toegevoegd die nu voor het eerst gebruikt werd in een specificatie van een product. Een grootheid krijgt bij ons een 'grondgetal', zodat wij de waarde van de specificatie kunnen weergeven met een 'mooi' getal, bijvoorbeeld 25GB in plaats van 26843545600B.

Doordat deze nieuwe grootheid het grondgetal '1' had gekregen, trad er een situatie op die we nog nooit eerder hadden gehad. Hierdoor kwamen we in een eeuwige loop te zitten waarbij de code de waarde van de specificatie probeerde te delen door het grondgetal tot de waarde kleiner was dan het grondgetal. Maar als je deelt door 1, dan kun je best lang wachten voordat dat gebeurt. De code zelf bestond al sinds 2012, maar omdat er niet heel vaak extra grootheden bijkomen, heeft het nog nooit eerder voor problemen gezorgd.

We hebben het grondgetal van de grootheid aangepast in de database, waardoor de engine in elk geval weer kon starten. Vervolgens zijn er aanpassingen gedaan aan de engine waardoor dit probleem niet meer kan voorkomen. Ook is er extra validatie toegevoegd zodat de waarde 1 (die hier eigenlijk helemaal niet logisch was) niet meer geaccepteerd wordt.

En verder

Reacties (120)

120
119
104
11
0
3
Wijzig sortering
Die +1, +2 knoppen zijn echt verschrikkelijk.

Om de oude kleuren terug te zetten met Tampermonkey:
// ==UserScript==
// @name Tweakers.net Mod Colors
// @namespace http://tampermonkey.net/
// @version 2025-03-05
// @description Changes the mod button colors on tweakers.net
// @match *://*.tweakers.net/*
// @icon https://tweakers.net/favicon.ico
// @grant none
// ==/UserScript==

(function() {
'use strict';

window.addEventListener('load', function() {
const styleElement = document.createElement('style');
styleElement.textContent = `
:root {
--mod-negative-default: #B10E3A !important;
--mod-negative-text: #FFFFFF;
--mod-zero-default: #F1C72B !important;
--mod-zero-text: #FFFFFF;
--mod-one-default: #CFDF03 !important;
--mod-one-text: #FFFFFF;
--mod-two-default: #8BD900 !important;
--mod-two-text: #FFFFFF;
--mod-three-default: #6EAD01 !important;
--mod-three-text: #FFFFFF;
}
`;

document.head.appendChild(styleElement);
});
})();

[Reactie gewijzigd door NSURLSession op 5 maart 2025 09:53]

Is een custom CSS dan niet handiger?

[Reactie gewijzigd door b12e op 5 maart 2025 10:31]

Bedankt, ik heb die zojuist geactiveerd. Geen idee of het aan mijn scherm ligt, maar ik zie op een Samsung A52 en met dark mode ook nauwelijks verschil tussen de +1 en +2 knoppen.
Ligt echt niet aan je scherm darkmode. Hier het Henk thema, wat dan licht is ook daar zijn de kleuren + 1 tm +3 minimaal anders ik word er zelfs een beetje dol / scheel van de nieuwe kleuren.

@b12e Dank voor je moeite. Direct geactiveerd :Y) .

Hierbij de verschillen in 1 plaatje te zien.
Ik zie het verschil wel, maar ik kan me voorstellen dat er een hele hoop Tweakers zijn die op deze manier ontdekken dat ze licht kleurenblind zijn. Het verschil is wel heel klein.
@b12e en @NSURLSession bedankt voor jullie bijdrage!
Ik heb het even een kans gegeven vanochtend maar kan er echt niet aan wennen, voor mij in ieder geval super onoverzichtelijk geworden.
Ik heb die CSS onder Instellingen toegevoegd maar ik zie geen verschil...
Super bedankt! Ik zou niet weten wat ik zou doen zonder custom CSS en de heldentweakers die deze samenstellen. _/-\o_
Waarom zit dit eigenlijk in een JS? Dat zie je niet vaak meer, meeste gaat toch echt via CSS.
Deze javascript injecteert css die vervolgens de kleuren overschrijft. De daadwerkelijke kleuren zitten inderdaad in de css. Tampermonkey doet niets anders dan deze javascript uitvoeren wanneer Tweakers geopend wordt.
Waarom niet een tool als stylebot gebruiken om de CSS te overschrijven? JS gebruiken om CSS te injecteren is een beetje alsof je een kettingzaag gebruikt om een boterham te smeren.
Stylebot doet hetzelfde. Je ziet het alleen niet omdat er een GUI omheen zit. Kijk in de source maar eens onder etc/injectcss.
Of de custom css feature van tweakers zelf?
Ik heb nu dit, ontbrak nog witte tekst en shadow achter de tekst

```
root {
--mod-unselected-default: var(--grey-35);
--mod-unselected-hover: var(--grey-55);
--mod-text-color: var(--grey-100);
--mod-three-default: hsl(90deg 70% 40%);
--mod-two-default: hsl(90deg 70% 50%);
--mod-one-default: hsl(65deg 75% 50%);
--mod-zero-default: hsl(45deg 90% 60%);
--mod-negative-default: hsl(345deg 80% 40%);
--mod-three-hover: hsl(90deg 70% 50%);
--mod-two-hover: hsl(90deg 70% 60%);
--mod-one-hover: hsl(65deg 75% 60%);
--mod-zero-hover: hsl(45deg 90% 70%);
--mod-negative-hover: hsl(345deg 80% 50%);
}

.moderation-button {
--text-color: white !important;
}

.moderation-button .display-score {
text-shadow: 0 .125rem .5rem var(--text-shadow-color);
}
```

[edit] Nu nog Markdown support :x

[Reactie gewijzigd door aaahaaap op 5 maart 2025 13:14]

Ik heb een variant op deze gejat voor de custom css snippet.

Bedank!
Nice! Hoe makkelijker het is voor iedereen hoe beter :)
Dit werkt ook zo te zien als custom css (kopiëren en score aanpassen voor de andere knoppen);

.moderation-button[score="1"] {
--background-active-color: #CFDF03 !important;
--text-color: #FFFFFF;
}
Helemaal mee eens, de nieuwe kleuren zijn niet mooi en qua kleur feller dan de vorige. Het lijkt net of je de 'keer kleuren om' functie aan hebt staan. De donkeren kleuren hiervoor waren veel rustiger.
Inderdaad, wat een vreemde kleuren... Is het contrast niet juist veel minder? Ik zie nauwelijks verschil tussen +1 en +2, en ik ben niet kleurenblind :+
De 0 score ziet er bijna rood uit, ik krijg daar nu een veel negatiever gevoel bij dan het meer neutrale wat het eerst was.
Verandering kan altijd weerstand oproepen maar dit lijkt toch wel erg vreemd.
Ik dacht inderdaad even dat ik naar mijn oude 'washed out' TN scherm zat te kijken van jaren terug. Wat een bleke kleuren zeg holymoly.
Ik geef je maar een +3 in plaats van een +2, omdat het anders niet goed te zien is qua verschil. Oh wacht, zo werkt het systeem niet hè? ;)
Ik dacht dat ik de enige was. Met mijn kleurenblindheid zie ik bij de nieuwe knoppen echt geen verschil meer tussen +1, +2 of +3.
Als dit dan toch op de schop gaat, waarom dan ook niet over naar Markdown voor post formatting?

Dat is tegenwoordig wel een beetje de standaard hiervoor, en ik vind het veel fijner werken dan RML.

Het beperkt jullie ook minder in de keuze voor een editor.
Omdat markdown* zelf niet volstaat voor ons. Eenvoudige zaken werken prima in markdown, maar complexe zaken zoals tabellen met nesting e.d. werkt gewoon niet in markdown. Wil je wel de volledige complexiteit die we nu bieden, zou je HTML embedding moeten toestaan in markdown, dan kun je beter direct HTML doen...

Maar als het alleen gaat om het 'fijner werken', we gaan wel markdownnotatie ondersteunen. Dus je typt **bold**, waarna de tekst bold wordt. We slaan het echter niet op in markdown.

* "Markdown" als zodanig bestaat niet. Er zijn vele verschillende standaarden, wat het verwarrend maakt als je over "markdown" spreekt alsof het 1 standaard is.
Omdat markdown* zelf niet volstaat voor ons. Eenvoudige zaken werken prima in markdown, maar complexe zaken zoals tabellen met nesting e.d. werkt gewoon niet in markdown. Wil je wel de volledige complexiteit die we nu bieden, zou je HTML embedding moeten toestaan in markdown, dan kun je beter direct HTML doen...
Nouja, er zijn prima tabel-uitbreidingen voor Markdown.

Niet voor nested tabellen voorzover ik weet, maar hoe vaak komt dat nou voor? Daarvoor zou je dan weer prima inline HTML kunnen ondersteunen, wat van nature goed integreert met markdown.
Wil je wel de volledige complexiteit die we nu bieden, zou je HTML embedding moeten toestaan in markdown, dan kun je beter direct HTML doen...
Daar ben ik het pertinent mee oneens. Markdown werkt juist heel fijn voor de common cases, en voor de ongebruikelijke 0.1% kun je dan HTML embedden. Zeggen "ja dan gebruik je toch gelijk HTML voor alles" is het kind met het badwater weggooien. Juist die simpele 99% is waar Markdown haar meerwaarde biedt.
Maar als het alleen gaat om het 'fijner werken', we gaan wel markdownnotatie ondersteunen. Dus je typt **bold**, waarna de tekst bold wordt. We slaan het echter niet op in markdown.
Nouja, dat is al iets. Maar in mijn ervaring zijn wysiwig editors die markdown op die manier "ondersteunen" ook een grote bron van frustratie (wysiwig editors in het algemeen eigenlijk). Sterretje woord sterretje oh nee backspace want ik wil nog een woord toevoegen. Maar ondertussen heeft de editor de sterretjes weggehaald en je tekst bold gemaakt, waardoor je je woord backspaced.
"Markdown" als zodanig bestaat niet. Er zijn vele verschillende standaarden, wat het verwarrend maakt als je over "markdown" spreekt alsof het 1 standaard is.
Nouja, als je zo wil beginnen: Markdown als zodanig bestaat wel. Die is wel erg beperkt, dus de meesten gebruiken (terecht) een variant met uitbreidingen.

En ja, ik ben het met je eens dat die fragmentatie niet ideaal is; maar dat staat t.net niet in de weg een markdown variant te kiezen en te implementeren. En basically iedereen gebruikt tegenwoordig toch de github-flavour, dus ach. Alleen tabellen bestaan nog redelijk veel varianten voor.
Goeie punten!
Daarnaast lijken me tabellen en al helemaal nested tabellen niet echt relevant voor reacties op de frontpage. Voor het forum evt wel, maar dat lijkt me oplosbaar (tables) of een acceptabel verlies (nested tables, letterlijk nog nooit van m'n leven gebruikt) voor een veel betere en simpelere UX.
Overstappen naar Markdown is niet zo gemakkelijk. Er is veel legacy code op de site en het forum. Ook wil je backwards compatibility behouden, zodat je niet alle oude posts hoef te updaten zodat ze ook in de Markdown goed weergegeven worden.
Ow, toch geen Markdown? :(

Ja, dat zou betekenen dat wat regexp moet gebruiken voor vertalingen van de legacy-comments. Of ervoor kiezen om beide te ondersteunen. Ik denk niet dat ik helemaal snap om dit niet te doen...
Waarom moet per se Markdown ondersteund worden? Zo slecht werkt RML toch ook weer niet? :) Ik krijg althans een beetje het gevoel alsof dat een verplichting of "moetje" is. En ook Markdown heeft zo zijn beperkingen, trouwens. Zou je met de Markdown de basis in gaan, krijg je zelfs een veel beperktere set dan RML dat heeft.

[Reactie gewijzigd door CH4OS op 5 maart 2025 11:50]

Vroegah, toen Tweakers.net het wiel nog uit moest vinden, was het heel normaal om vierkante haken met html-woorden te gebruiken, want het was met JS al best lastig om een subset van html toe te laten.

We zijn nu ruim 20 jaar verder, en je ziet dat naast dev-sites als Github en Gitlab, ook meer en meer forums, chat-sites en zelfs apps Markdown is gaan gebruiken. Juist omdat het simpel is en gewoon werkt.

Dus het gaat niet om een technische discussie, maar wat evolutionair heeft gewonnen.

PS. WYSIWYG is ook al een discussie van 10+ jaar geleden...
Nou ja, WYSIWYG is iets anders dan Markdown, van de laatste zijn bovendien ook meerdere standaarden. En zaken als tabellen (omdat het forum dat gebruikt) zijn in Markdown ook best een ding (en in de simpele standaard van Markdown standaard niet eens aanwezig. Zie ook DaFeliX in 'Wysiwyg-editor en verbeterde toegankelijkheid - Development-iteratie #306' voor een verdere toelichting waarom Markdown niet echt handig is voor Tweakers.
WYSIWYG-implementaties kunnen zeker met Markdown te maken hebben. Als je backspacet, wat er gebeurt met bold en italic, bijvoorbeeld.

Over de standaard van MD zijn al diverse discussies gevoerd hier. Er is namelijk absoluut een duidelijke standaard, maar voor extended Markdown moet je iets kiezen. Zoals al is gezegd, lijkt Github hier leidend. Dus je klacht is dat er meerdere opties zijn in een standaard, en dat is hetzelfde klagen over gebrek aan standaard ijsjes.

Dus de essentie:
- iedere developer of zelfs IT-mamager kent Markdown, en is een soort standaard geworden.
- Markdown is eenvoudiger dan RML, en zou gemak opleveren
- Het is gedoe om T.net aan te passen

We zijn het met alle drie items eens, alleen de gewichten zijn anders. Ik heb weinig gewicht voor het laatste gezet, omdat ik waarde voor de site belangrijker vind dan gedoe.
Waarom moet per se Markdown ondersteund worden?
Omdat dit
- Dit is een *lijst*
- Met drie items
- Kijk maar
duizend keer fijner is om te schrijven dan dit:
[ul]
[li]Dit is een [b]lijst[/b][/li]
[li]Met drie items[li]
[li]Kijk maar[/li]
[/ul]
Ik gebruik op heel veel plaatsen markdown, maar ook nog een aantal fora (waaronder GoT) met een RML-achtige syntax. Een goed uitgevoerde markdown-support werkt heerlijk vind ik, de RML-achtige syntaxen vind ik maar frustrerend. Terwijl ik met die laatste veel langer ervaring heb!

[Reactie gewijzigd door deadinspace op 5 maart 2025 16:32]

Als dit dan toch op de schop gaat, waarom dan ook niet over naar Markdown voor post formatting?
Alsjeblieft niet uitsluitend Markdown. Ik vind Markdown ontzettend hinderlijk, want het gaat gewoon te makkelijk fout. Het is voor heel erg simpele zaken zoals vetgedrukte of schuingedrukte tekst wel te doen, maar verder juist omslachtig. Het gaat ook ongeveer net zo vaak fout als goed, en de "standaard" is behoorlijk gefragmenteerd. Zonder te testen weet je bijv. vaak niet of een enkele asterisk nou gaat leiden tot schuingedrukte tekst, of dat je daar de underscore voor moet gebruiken.

RML is consequent (het is eerlijk gezegd niet minder een standaard dan Markdown), heeft bijna nooit false-positives en heeft voor de ingewikkeldere zaken een veel logischere syntax.
De nieuwe kleuren voor de moderatiescores (Ik gebruik darkmode in combinatie met het officiele Henk-thema) is ook niet echt een vooruitgang. Ik ben kleurenblind (Deuteranopia) en heb daardoor moeite met de kleur voor +1, +2 en +3, die voor mij gewoon hetzelfde zijn, maar die voor -1 en 0 zijn nu ook niet echt toffe kleuren. De kleuren waren perfect en middels feedback op het forum, waren die kleuren uiteindelijk ook zorgvuldig gekozen. Jammer dat die wijzigingen uiteindelijk teniet gedaan worden en er gewoon wederom geen rekening is gehouden met contrast.

[Reactie gewijzigd door CH4OS op 5 maart 2025 10:20]

Hier ook een Deuteronoop, inderdaad niet handig die nieuwe kleuren. Oude waren prima, vreemde wijziging en wordt ook nergens benoemd waarom dit is veranderd.

Er is al een custom snippet die de kleuren weer terugzet:
Oude moderatiekleuren terug
en wordt ook nergens benoemd waarom dit is veranderd.
Wordt het wel. Vanwege het verbeteren van contrast.
Daarmee wordt wss. het contrast tussen de voorgrond letterkleur en de achtergrondkleuren bedoeld.

De gekozen oplossing ziet er alleen niet uit.
Men had simpelweg de -webkit-text-stroke property kunnen gebruiken om de witte letters middels een half-transparent zwarte kleur van een donkerder afgetekende rand te kunnen voorzien.

(In tegenstelling tot de naam is die vendor geprefixte property retroactief gestandaardiseerd en overal ondersteund.)


Simpel voorbeeldje:
https://jsfiddle.net/42fundps/

[Reactie gewijzigd door R4gnax op 5 maart 2025 23:29]

Klopt, ik heb nu een allergaartje in eigen custom CSS gezet.
@DaFeliX
Zouden jullie wellicht de kleurcodes vd oude kleuren voor de moderatiebuttons kunnen delen?

Met dank aan b12e en NSURLSession gebruik ik nu customcss om deze terug te krijgen. Echter vraag me af of deze kleuren wel helemaal hetzelfde zijn, ze lijken iets feller maar goed dat kan ook aan mij liggen.
De kleurcodes voor de merge waren:

--mod-unselected-default: var(--grey-35);
--mod-unselected-hover: var(--grey-55);
--mod-text-color: var(--grey-100);
--mod-three-default: hsl(90deg 70% 40%);
--mod-two-default: hsl(90deg 70% 50%);
--mod-one-default: hsl(65deg 75% 50%);
--mod-zero-default: hsl(45deg 90% 60%);
--mod-negative-default: hsl(345deg 80% 40%);
--mod-three-hover: hsl(90deg 70% 50%);
--mod-two-hover: hsl(90deg 70% 60%);
--mod-one-hover: hsl(65deg 75% 60%);
--mod-zero-hover: hsl(45deg 90% 70%);
--mod-negative-hover: hsl(345deg 80% 50%);
Waarom zijn die kleuren eigenlijk aangepast? Wat maakt voor jullie de nieuwe kleuren beter dan de vorige?
Hier dezelfde vraag en wie heeft hier voor gezorgd :F
Als je dan toch zo lekker bezig bent, kun je de merge van deze commit terugdraaien? 8-)
Kan mij alleen maar voegen bij de rij van mensen die de oude kleuren terug wil of op zijn minst betere nieuwe kleuren. Wat een fiasco. Grijs voor -1? Rood voor neutraal? En dan drie variaties van groentinten die nagenoeg gelijk zijn? Ik ben niet kleurenblind, maar jeetje zeg.

Ik hoop dat deze selectie niet uit een soort positiviteit meeting kwam of zo. -1 is fout en hoort gewoon rood zodat het makkelijk te herkennen is als zodanig.
Op de waybackmachine kun je de kleuren terughalen.
Wat is eigenlijk de reden dat jullie vast willen houden aan RML voor de weergave van posts? Sure, ik snap dat het wat tijd scheelt in het ontwikkelen van de weergave van posts, maar is het werkelijk zo'n ramp om 2 standaarden te hebben voor hoe mensen hun posts willen typen? En ja, dat maakt het wat lastiger om te wisselen tussen de 2 standaarden, maar daar is ook vast nog wel een oplossing voor. Het ding is vooral dat je door RML wel een enorme eis legt op welke keuze je hebt. Bovendien zou je zonder RML wellicht een eigen oplossing kunnen ontwikkelen, zodat je niet afhankelijk bent van andere projecten. Iets wat je tegenwoordig steeds vaker ziet met webprojecten.
Het gaat inderdaad voornamelijk om het wisselen tussen twee standaarden. Als je iets nieuws bouwt, zal je hoe-dan-ook rekening moeten houden met oude content die in RML geschreven is.

De belangrijkste reden om nú RML te ondersteunen is om het uitrollen eenvoudiger te maken. Je kunt straks content typen in WYSIWYG en in RML, zonder dat dit consequenties heeft voor de backend. We kunnen dus steeds met een grotere groep gebruikers gaan testen, het maakt voor de backend niet uit of de RML handmatig getypt is, of door de WYSIWYG is gegenereerd.

Als we geen RML zouden ondersteunen, zou dit de weg niet perse vrijmaken naar een andere oplossing lijkt me. Het zou het kunnen gebruiken van een andere library eenvoudiger maken, maar helemaal vanaf scratch een eigen editor bouwen is gewoon niet realistisch voor ons.

Overigens, zodra we overal een WYSIWYG editor hebben, zouden we alsnog kunnen afstappen van RML als we dat zouden willen. Dan is er nl 1 interface die iedereen gebruikt, en zouden we kunnen kijken of we RML support laten varen, maar zolang er twee interfaces naast elkaar bestaan is RML gebruiken een logische stap.
. Dan is er nl 1 interface die iedereen gebruikt,
Blijft het wel mogelijk om alleen met het toetsenbord een reactie inclusief quotes e.d. te typen?
Ja, door middel van toetsenbord shortcuts (bijv CTLR+B) en markdownotatie (**vet**); om een quote te beginnen type je dan bijv een ">" aan 't begin en dergelijke.

Ik weet niet of we voor alles beide ondersteunen, maar zeker wel voor de meestgebruikte tags (zegt een toetsenbordgebruiker die geen muis gebruikt).
Vooral die quote (>) is erg irritant als je meerdere regels, met lege regels ertussen wilt quoten. Dan vind ik een [q] ... [/] toch sneller. :)

Maar dat kan aan mij liggen. Ik ken geen enkele WYSIWYG editor die fijn en intuïtief werkt, zeker met dat soort dingen.
Markdown? Eindelijk!!! Ik kon maar niet wennen aan de oude methodes met `[ li ]`, `[ quote ]`, e.d.
Waardeer het dat Tweakers en haar moederbedrijf oog hebben voor toegankelijkheid. Het klopt inderdaad dat de wet en het verdrag bepaalde minimum eisen stelt. Ik begrijp dat het lastig en kostbaar is.

Goede knopbeschrijvingen en beschrijvingen van afbeeldingen helpen inderdaad. Kleuren is persoonlijk, wat de een geweldig lijkt, is niets voor de ander. De meeste schreenreader bieden thema en kleuroverschrijving aan, waardoor de bronkleur er niet meer toe doet. In bijvoorbeeld Fusion (nee, niet "jullie" fusion maar "onze" fusion van Freedom Scientific, werkt dat prima.

Wat mijn grootste ergernis aan Tweakers was en is, het tig keer op de tab of een andere navigatietoets moeten drukken om bijvoorbeeld een reactie te geven. Er zijn mensen die geen muis kunnen gebruiken. In fusion is het inderdaad mogelijk om een koppen venster te genereren dat alle "ballast" van Tweakers weg laat, maar ook dan moeten de navigatie toetsen tientallen keren worden ingedrukt voor het lezen van een artikel. En dan nog tientallen keren om door de reacties te lopen en een reply te schrijven.
Het klinkt alsof je ons kunt helpen met identificeren van problemen met toetsenbordnavigatie. Dit is iets wat nog niet echt goed op onze radar staat, en ik wil hier wel wat meer mee doen.

Ik ben zelf ook een toetsenbordgebruiker, en herken wel dat er nog veel te verbeteren is. Kun jij aangeven op welke site(s) je wel een fijne toetsenbordbeleving hebt? En neem bijvoorbeeld het typen van een reactie; hoe zie jij de ideale flow voor je?
Voor het lezen van artikelen herken ik je frustratie niet overigens, ik kan zelf prima met pijltes/page-down lezen. Wat is precies jouw probleem mee?
Lezers met een (ernstige) zichtbeperking hebben geen helicopterzicht zoals (goed) ziende mensen. Ze moeten alles sequentieel lezen. Je kan het zelf ook (beperkt) testen door in windows 10/11 "verteller" aan te zetten, je muis los te koppelen en het beeldscherm uit te zetten. Vervolgens luisteren naar hoe de menu's worden gepresenteerd, of een afbeelding een (korte) beschrijving heeft etc. Je kan het ook gratis testen met gratis programma NVDA: https://www.nvaccess.org/download/, dat ook in het Nederlands beschikbaar is.

Probleem met Tweakers is dat de gebruiker soms tientallen keren moet "tabben" voordat het juiste artikel gevonden wordt, dan "in het artikel" leest, dan door de scheidingskopjes tussen het artikel en de reacties moet tabben, vervolgens tientallen keren moet tabben voor de reactie waarop hij wil reageren. En dan nog een paar keer tabben om op "plaats reactie" te drukken.

Natuurlijk wel met een goede adblocker, anders drukt de advertentie Tweakers content weg en geen idee waar de lezer dan is.

Kortom, het is erg tijdrovend om zelfs maar basaal op de hoogte te blijven van het laatste nieuws.
Klopt inderdaad allemaal.
Waar Tweakers eens mee zou moeten beginnen is een analyse van de algehele pagina opzet in landmark roles en aanverwante roles om navigatie te ondersteunen.

Je noemt zelf al het veelvuldige gebruik van de TAB toets dat nodig is om door nieuwsartikelen te bladeren.
Ipv bijv. het gebruik van jump links om snel naar de volgende (of is dat vorige? anti-chronologisch? wordt ook nergens aan screenreaders vermeld...) datums te navigeren. Of het markeren van de news feed als een tree, en pijltoetsen omhoog/omlaag te gebruiken om tussen dagen te springen en links/rechts om in de lijst artikelen per dag te belanden.

Iets dat veel meer zoden a/d dijk zet dan aanpassingen aan het contrast v/d moderatie scores.
Maar ja- het is minder zichtbaar, heh?
In de letterlijke zin. Als je je zicht gewoon kunt gebruiken, en geijkt bent op informatie op die manier tot je nemen, dan ben je genegen je ook op zichtbare zaken te concentreren.

[Reactie gewijzigd door R4gnax op 6 maart 2025 22:55]

Tweakers heeft, een half jaar geleden, wel iets getest met toegankelijkheid. Ze boden een soort "zwevend" menu aan dat "boven" de tweakers webpagina "hing". De lezer kon dan via dat hele basale menu snel door het hoofdmenu van Tweakers naar bijvoorbeeld de artikelen sectie gaan. Helaas bleek de overgang tussen het zwevende menu en de echte Tweakers website niet te werken, kwam de lezer in een soort eindeloze lus waaruit die niet kon "ontsnappen". Een Tweakers stagiair heeft wel eens meegekeken hoe dat werkt en ze werd er inderdaad niet vrolijk van.

Ik kan mij er ook iets bij voorstellen dat het voor Tweakers heel duur is om hun huidige templates aan te passen. Aan de andere kant is er o.a. het verdrag van Marakesh en beleid van de Nederlandse overheid over toegankelijke media. Maar er zit ook een menselijke maat in. Mensen die slecht/niet zien zouden toch ook "gewoon" moeten kunnen "Tweakeren"?

Moderne screenreaders als Fusion hebben AI die bijvoorbeeld een afbeelding analyseert. Of een filter die tracht alle links netjes in een apart venster te plaatsen. Fusion is waarschijnlijk de beste screenreader en je mag heel blij zijn als de ziektekostenverzekeraar het vergoed (zelf een SLA van Fusion met 4 maal per jaar een update). Fusion heeft speciale interface interactie om bijvoorbeeld goed met GMail om te kunnen gaan. Helaas heeft zelfs Fusion het moeilijk op Tweakers en mag ik heel veel toetsen in drukken om te navigeren.
@FrostyPeet heeft het over Fusion van Freedom Scientific. Ik krijg de indruk dat hij een screen reader gebruikt. Dat is nog wel even een stap verder dan alleen navigeren met toetsenbord. Ik zie dat hier al wel een hoop in verbeterd is. De code is er de afgelopen tijd (qua toegankelijkheid) wel op vooruit gegaan!
waarom delen met x compleet weggehaald? kan toch prima naast bluesky
Omdat X niet meer draait om sociaal zijn, maar meer om haatzaaien. Dat gaat niet alleen over Musk of Trump, maar het is verre van een neutraal platform.

Is Bluesky zoveel beter? Geen idee, ik zit er niet op. Maar voor mensen die op X zitten, zou het wel beter zijn als ze minder Musk zouden zien. :)
Er zit een verschil tussen het zelf gebruiken of naar linken.
Dat is zeker waar. Maar wel handig om te weten welk standpunt Tweakers nu inneemt over X.

Conclusie: Tweakers gebruikt zelf X niet meer en is vervangen voor Bluesky (een reden zou kunnen zijn die je al aanhaalde, maar ik ben bij geen van beide lid dus ook geen ervaring) maar compleet afscheid/verboden is X nog niet aangezien linken naar X nog wel mag.

De ene keer is een bepaald linkje toegestaan, geen knip en de andere keer niet toegestaan, zie knip.
Consistentie is ver te zoeken idd
de communitnotes/fact-check features op x is plezierige toevoeging - zouden meer socials moeten doen
Waarom laten staan?
Tegen nazis zijn is niet 'hip', het is de gewoonste zaak van de wereld.
exact. moeten ze verder natuurlijk zelf weten. Op X zit vrijwel heel nederland, op bluesky alleen een beperkt groepje.
Ik ken letterlijk niemand op X (buiten parasociale relaties zoals met de tweakers podcasters misschien, geen idee of de journalisten daar wel nog rondhangen bijvoorbeeld) maar wel mensen op bijvoorbeeld Mastodon. Vroeger wel veel mensen op twitter, ik was daar actief en had een tweede account als mirror van de rss feed voor m'n blog en een derde account voor een botje dat wikipedia-bewerkingen van mijn school opmerkte, en vast nog wel meer dat ik me nu niet herinner, maar dat is nu jaren geleden. X is intussen niet meer relevant voor "vrijwel heel nederland"

[Reactie gewijzigd door Lucb1e op 6 maart 2025 01:35]

Ok. Het aantal gebruikers zegt iets anders dan jouw persoonlijke ervaring, maar dat invalideert jouw persoonlijke ervaring verder niet natuurlijk, dus ik accepteer dat jij een van de weinige uitzonderingen op de regel bent.
Om een keuze te kunnen maken tussen deze drie hebben we voor elk een proefimplementatie gemaakt. We kwamen daarna tot de conclusie dat ProseMirror de beste lijkt te zijn voor onze situatie. We merkten echter ook dat ProseMirror tóch best veel boilerplate code nodig heeft. Daarom besloten we om ook weer Tiptap te bekijken.
Jep, dat klinkt als een heel erg team + management laagjes stellen vragen waardoor meer overwogen moet worden.

Is het misschien een idee om het comment blok niet in RML te doen maar in Markdown? Wat misschien het makkelijkste is om mee te vergelijken is het comment boxje in github issues, dat is markdown. Daar heb je ook een preview bij van hoe je text eruit komt te zien. Zeker voor een doelgroep als tweakers lijkt me een format als dat meer geschikt dan het aloude (wellicht nostalgische redenen) RML format.
Zie mijn reacties elders hier, maar het markdown formaat is gewoon niet afdoende voor Tweakers (voornamelijk nesting). Dit "lost" markdown op door HTML ondersteuning, maar dan kun je net zo goed naar HTML gaan. Dus markdownformaat zou een achteruitgang zijn.

Maar markdownnotatie (dus **dit is bold**) ondersteunen gaan we doen, net als keyboard shortcuts en knopjes in een toolbar.

Overigens kwam de vraag of er betere alternatieven waren vanuit onszelf, niet vanuit management :)
Kan je wat meer zeggen over wat markdown dan niet kan voor tweakers? En welke nesting doel je op?

Als je het over lijsten heb, die kunnen wel degelijk in nette markdown genest worden.
Hele sites kunnen in markdown - zonder html embedding - worden gemaakt.

Ja, het wordt complexer als je meerdere kolommen naast elkaar wil hebben, dan kom je wel in markdown hacks of html.

In zowel de content als comments bij posts en topics op het forum zie ik geen vreemde zaken die niet in normale markdown kunnen.
Nested tabellen is een voorbeeld dat mij zo te binnen schiet, maar er zijn meer zaken die in markdown formaat niet werken. Underline heeft trouwens geen ondersteuning in de meeste markdownstandaarden, dus daar zul je sowieso wat op moeten bedenken.

Voor het gros van de reacties zal dit geen problemen zijn, vandaar jouw "zie ik geen vreemde zaken"; maar waarom zouden we qua functionaliteit achteruitgaan door het als markdown op te slaan, als onze eigen RML al prima werkt.
Wie heeft bedacht om de +1, +2 en +3 qua kleur nagenoeg hetzelfde te maken?
Ik vond de oude kleuren veel duidelijker.
Helemaal eens. Hoe is dit beter voor bijv. slechtzienden?
Alleen maar slechter zie: CH4OS in 'Wysiwyg-editor en verbeterde toegankelijkheid - Development-iteratie #306'

Hoewel ik dat niet heb. Ook ik heb de oude kleuren terug met behulp via custom css aangezet, werd er dol/scheel van.
Nu je het zegt dat verschil is op mijn scherm amper te zien
Ik zal mijn vraag van de vorige dev even herhalen nu jullie blijkbaar alsnog voor Tiptap hebben gekozen:
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?
Dat gezegd hebbende, ik merkte eerder al op dat Twitter niet meer op de website staat en was vervangen door BlueSky. Mooie vooruitgang.

Wat niet zo'n mooie vooruitgang is zijn de nieuwe fletse kleuren van het moderatie systeem. Zeker van +1, +2 en +3 is het verschil nu veel te minimaal. Dit is geloof ik de 2de keer dat jullie experimenteren met nieuwe kleuren hiervoor, en jullie slaan de bal weer ferm mis.

En jullie moeten ook nog eens dringend naar die advertenties kijken. Ze lijken véél storender te zijn geworden in de laatste paar weken. Advertenties springen weer heel de tijd in verschillende seconden nadat de pagina al geladen is en er wordt steeds maar weer op foute artikels geklikt zo. Natuurlijk snap ik dat dat voor jullie alleen maar betekend dat er nog meer advertenties getoond worden aan gebruikers die nu op pagina's zijn waar ze niet willen zijn, maar kop op zeg...

[Reactie gewijzigd door Loller1 op 5 maart 2025 10:40]

Wat niet zo'n mooie vooruitgang is zijn de nieuwe fletse kleuren van het moderatie systeem. Zeker van +1, +2 en +3 is het verschil nu veel te minimaal. Dit is geloof ik de 2de keer dat jullie experimenteren met nieuwe kleuren hiervoor, en jullie slaan de bal weer ferm mis.
Hier is inderdaad in 2023 en 2022 ook reeds over gesproken, zie ik althans met een snelle Google. Het voelde alsof het korter geleden was:
2022: forumtopic: De nieuwe weergave van de reactiescore (Waar ik mij ook al meldde)
2023: forumtopic: Feedbacktopic voor dark & light mode
[...]Voor welke reden zouden jullie mogelijk moeten betalen bij Tiptap wat gratis is bij de rest?
Ik begrijp de vraag niet helemaal zonder de originele context, maar wij zijn voornemend om nu Tiptap te gebruiken zonder Pro extensies, en daarom geen licentie nodig hebben. Dat wil wel zeggen dat we zelf wat meer werk moeten doen, maar dan kunnen we wel met de gratis versie af.

Overigens geldt voor bijna alle libraries dat er een licentie nodig is voor commerciële projecten met meer dan zoveel gebruikers, waar we bij Tweakers al snel aan zitten.

Op dit item kan niet meer gereageerd worden.