Grafieken soms onleesbaar

[Firestorm]

Ik heb het 'probleem' dat soms de grafieken niet leesbaar zijn.
Bijvoorbeeld in dit artikel:

review: Welke gpu leunt het minst op je cpu? Een nieuwe videokaart in je oude pc

Op de eerste pagina is hij prima te zien en de tekst duidelijk.


Op pagina 3 en verder worden de as-titels 'vaag' en de grafiektitel ineens zwart waardoor deze niet te lezen is.


Waarom niet overal dezelfde grafieken gebruiken?

iets recenter voorbeeld:
nieuws: 84 procent van inkomsten muziekindustrie VS komt uit streaming


Aanvulling: In de pricewatch is het wéér anders:

[ Voor 8% gewijzigd door Firestorm op 10-03-2023 10:16 ]

[ACM]

Tweakers heeft geen darkmode... dus je hebt zelf een custom css optie aangezet of iets via je browser gedaan. Hier kan je daarom ook alleen zelf wat aan doen

[ Voor 18% gewijzigd door ACM op 10-03-2023 10:17 ]

[Firestorm]

ACM schreef op vrijdag 10 maart 2023 @ 10:17:
Tweakers heeft geen darkmode... dus je hebt zelf een custom css optie aangezet of iets via je browser gedaan. Hier kan je daarom ook alleen zelf wat aan doen

Dat vraag ik toch niet?
Mijn opmerking gaat over het gebruik van verschillende grafiekstijlen, waardoor het gebruik van custom css onmogelijk wordt. Ook geeft ik in het eerte voorbeeld aan dat het wel kán werken, maar dat niet overal doet...
Bovendien doe ik dat niet zelf, maar gebruik ik de tweakers perfect dark css. Wat mij beftreft mogen jullie dat beter ondersteunen.

[ Voor 7% gewijzigd door Firestorm op 10-03-2023 10:27 ]

[ACM]

Firestorm schreef op vrijdag 10 maart 2023 @ 10:24:
Dat vraag ik toch niet?
Mijn opmerking gaat over het gebruik van verschillende grafiekstijlen, waardoor het gebruik van custom css onmogelijk wordt.

In mijn beleving vroeg je niet echt iets en liet je ons een beetje raden wat je bedoelde.
En mijn gok van je verzoek was dat je verwachtte dat wij die soms onleesbare grafieken zouden moeten fixen.

Bovendien doe ik dat niet zelf, maar gebruik ik de tweakers perfect dark css. Wat mij beftreft mogen jullie dat beter ondersteunen.

Dat is dan ook work in progress.

Helaas maak je hier gelijk duidelijk waarom dat niet zo simpels is. Die "datawrapper"-grafiek is bijvoorbeeld een iframe (met blijkbaar geen achtergrondkleur ingesteld). Daar kunnen we sowieso niet zomaar met css dingen in anders stijlen.

En de eigen grafieken zijn nu allemaal echarts. Die rendert z'n data in een "canvas" en vormt effectief dus een afbeelding waarvan de inhoud niet met css is te sturen.

Als onderdeel van het darkmode-project zullen we voor echarts een light- en darkmode theme maken. En dan zullen we ook die inconsistenties in de verschillende grafieken op (moeten) lossen.

[crisp]

Je (of de maker van de perfect dark css @Azbest) zou nog dit kunnen toevoegen:

Cascading Stylesheet:

iframe.dataWrapper {
  filter: invert(1);
}

dan ziet het er zo uit:


nog steeds niet ideaal, maar in sommige gevallen iets leesbaarder

[ Voor 8% gewijzigd door crisp op 10-03-2023 10:44 ]

[crisp]

Ter aanvulling op @ACM over de verschillende gebruikte grafieken. We hebben grofweg deze 3 soorten:

- datawrapper (iframes): 3rd-party tool die door de redactie wordt gebruikt voor on-the-fly grafieken met willekeurige data. Hier hebben we zelf namelijk niet echt interne tooling voor
- HTML staafgrafieken (het eerste voorbeeld in je post) - deze wordt door Perfect Dark inderdaad ook mooi gestyled. Dit is echter een grafieksoort voor 1 specifieke usecase.
- echart grafieken (canvas-based): dat zijn o.a. de grafieken met benchmarks in reviews, maar ook de prijsgrafieken en de karmagrafieken in je profiel

[ Voor 5% gewijzigd door crisp op 10-03-2023 10:50 ]

[Azbest]

Hm tja, de grafieken zijn altijd al een ding geweest. Veel meer opties als een invert zijn er inderdaad niet voor de iframe. Ik heb me niet met de grafieken van de reviews bezig gehouden omdat ik daar niet zo vaak kom.

Kleuren zijn overigens wel foei lelijk in negatief.

@ACM Als ik me niet vergis hebben echarts tegenwoordig meerdere thema's ingebouwd. Ik zou met tampermonkey het javascript wel kunnen laten schakelen naar een ander thema.

[Santford]

Wat ik jammer vind aan de grafieken is dat er Microsoft YaHei als font gebruikt wordt voor de labels, waar op de rest van de site een andere font-family wordt gebruikt.
Ook wijken de grafieken af omdat duizendtallen door een komma gescheiden worden en niet door een punt.

[crisp]

Santford schreef op maandag 13 maart 2023 @ 12:11:
Wat ik jammer vind aan de grafieken is dat er Microsoft YaHei als font gebruikt wordt voor de labels, waar op de rest van de site een andere font-family wordt gebruikt.
Ook wijken de grafieken af omdat duizendtallen door een komma gescheiden worden en niet door een punt.

Je bedoelt denk ik Segoe UI? Dat is onder windows het default sans-serif font.

Ik weet niet in hoeverre we in datawrapper dat soort zaken kunnen customizen. Hetzelfde geldt ook voor de number-formatting. In de door onszelf geproduceerde grafieken hebben we daar uiteraard wel meer controle over.

[Santford]

Misschien dat ik niet goed kijk, het zou ook Segoe kunnen zijn. Dit is wat ik te zien krijg als ik de grafiek in mijn porfiel inspecteer met de developer tools in de browser:

Ik vind het jammer dat het lettertype en number formatting niet consistent is met de rest van de website, mogelijk is er nog wat te customizen aan de gebruikte instellingen van de gebruikte library.

[crisp]

Santford schreef op maandag 13 maart 2023 @ 12:57:
Misschien dat ik niet goek kijk, het zou ook Segoe kunnen zijn. Dit is wat ik te zien krijg als ik de grafiek in mijn porfiel inspecteer met de developer tools in de browser:
[Afbeelding]
Ik vind het jammer dat het lettertype en number formatting niet consistent is met de rest van de website, mogelijk is er nog wat te customizen aan de gebruikte instellingen van de gebruikte library.

Ah ja: https://github.com/apache/echarts/issues/13414

[ACM]

Santford schreef op maandag 13 maart 2023 @ 12:11:
Ook wijken de grafieken af omdat duizendtallen door een komma gescheiden worden en niet door een punt.

Dan staat je browser waarschijnlijk op Amerikaanse/Engelse formatting oid ingesteld?

We gebruiken in ieder geval daar normaliter Number.toLocaleString en de karma-grafiek heeft bij mij dan ook punten in Firefox (en komma in Chrome, geen idee hoe ik die wijs moet maken dat ik het ook in NL-notatie wil?).

[ Voor 17% gewijzigd door ACM op 13-03-2023 13:55 ]

[Dirk]

Ik heb hier komma's in de grafiek en punten in de tekst erboven:
Het lettertype is zo te zien wel gelijk.

[ACM]

Dirk schreef op maandag 13 maart 2023 @ 20:19:
Ik heb hier komma's in de grafiek en punten in de tekst erboven:

Tsja, die bovenste is door onszelf met php geformatteerd zonder rekening te houden met welke locale je browser als voorkeur heeft. De aanname was dat het voor de grafieken - die in javascript werken - handiger was om wel op de browser's voorkeur te vertrouwen. Maar blijkbaar hebben meerdere mensen dat 'verkeerd' ingesteld staan, mijn Firefox (waar ik alleen English in heb als taal) hanteerd de formatting die ik in Windows heb ingesteld.

Lijkt erop dat Chrome dat niet doet. En ook als je Dutch als voorkeurstaal bovenaan zet (maar wel English als browser-taal), negeert ie blijkbaar die voorkeur.

Voor de compleetheid, voer dit maar uit in je Chrome's console (CTRL+SHIFT+I op windows):

JavaScript:

const a = 10000;
a.toLocaleString();

Dus dan zullen we toch elke client moeten forceren op locale nl-NL bij die formatting door dat gedrag van Chrome

[Dirk]

Hier ook Firefox, maar dan op Ubuntu, met de region settings op en_NL. Ik zie dat Firefox het bij mij inderdaad ook standaard fout doet, want de systeeminstelling is wel goed.

[Santford]

ACM schreef op dinsdag 14 maart 2023 @ 07:37:
[...]

Tsja, die bovenste is door onszelf met php geformatteerd zonder rekening te houden met welke locale je browser als voorkeur heeft. De aanname was dat het voor de grafieken - die in javascript werken - handiger was om wel op de browser's voorkeur te vertrouwen. Maar blijkbaar hebben meerdere mensen dat 'verkeerd' ingesteld staan, mijn Firefox (waar ik alleen English in heb als taal) hanteerd de formatting die ik in Windows heb ingesteld.

Lijkt erop dat Chrome dat niet doet. En ook als je Dutch als voorkeurstaal bovenaan zet (maar wel English als browser-taal), negeert ie blijkbaar die voorkeur.

Voor de compleetheid, voer dit maar uit in je Chrome's console (CTRL+SHIFT+I op windows):

JavaScript:

const a = 10000;
a.toLocaleString();

Dus dan zullen we toch elke client moeten forceren op locale nl-NL bij die formatting door dat gedrag van Chrome

Met browser en OS instellingen wijzigen was het nog niet gelukt om het goed te krijgen.

Ik zie dat het inmiddels geforceerd wordt en zowel op pc als mobiel worden de duizendtallen nu met een punt gescheiden in de grafieken

Ik denk dat het forceren hiervan helemaal niet zo verkeerd is. In redactionele artikelen wordt ook een standaard aangehouden, daar is het niet afhankelijk van de browser instellingen. Zo blijft voor de hele site de notatie gelijk.

[ACM]

Santford schreef op woensdag 22 maart 2023 @ 14:00:
Met browser en OS instellingen wijzigen was het nog niet gelukt om het goed te krijgen.

Ik zie dat het inmiddels geforceerd wordt en zowel op pc als mobiel worden de duizendtallen nu met een punt gescheiden in de grafieken

Ik denk dat het forceren hiervan helemaal niet zo verkeerd is. In redactionele artikelen wordt ook een standaard aangehouden, daar is het niet afhankelijk van de browser instellingen. Zo blijft voor de hele site de notatie gelijk.

Klopt, ik wist ook niet hoe ik Chrome zover kon krijgen... wellicht door helemaal de taalinstelling op NL te zetten... En inderdaad, die laatste alinea was uiteindelijk ook een bijkomstigheid.