Jump to content

Reading/Web/Desktop Improvements/Features/Limiting content width/nl

From mediawiki.org
This page is a translated version of the page Reading/Web/Desktop Improvements/Features/Limiting content width and the translation is 100% complete.

Een van de belangrijkste doelen van het project is om Wikipedia, en andere Wikimedia-wiki's, gastvrijer te maken voor nieuwkomers. Een manier waarop we dit willen doen, is door de ervaring van het lezen van artikelen comfortabeler te maken.

Wat betekent het om een comfortabele (of een ongemakkelijke) leeservaring te hebben? Volgens onderzoek zijn er verschillende bijdragende factoren, een belangrijke is de regellengte. De studie Computer text line lengths affect reading and learning door Peter Orton, een Ph.D. aan het IBM Center for Advanced Learning, concludeert dat hoe langer de regellengte is, hoe moeilijker het wordt voor iemand om tekstuele informatie te lezen en uiteindelijk te leren en te behouden. Verschillende andere gerelateerde studies zijn te vinden op het Wikipedia-artikel Regellengte, die allemaal tussen de 40 en 75 tekens per regel aanbevelen.

Hoewel het niet bijzonder eenvoudig is om de aanbevolen regellengtes op Wikimedia-wiki's te bereiken, zullen we de breedte van de inhoud beperken met een maximale breedte om de meerderheid van de tekst op de wiki's dichter bij de aanbeveling te krijgen.

Meer details over het onderzoek en de overweging voor deze functie.

Functie beschrijving en vereisten

De belangrijkste functionaliteit van deze functie is het beperken van de breedte van de artikelinhoud. Om ervoor te zorgen dat de andere elementen op de pagina (namelijk de zijbalk en koptekst) niet te ver van de inhoud afdrijven, hebben we twee extra containers toegevoegd. De tweede container zorgt ervoor dat de zijbalk dicht bij de inhoud blijft. Om te voorkomen dat de koptekst te ver van zowel de inhoud als de zijbalk afdrijft, is er een derde container die de maximale breedte van de koptekst beperkt.

Technisch gezien: de content op de meeste pagina's wordt geplaatst in een content container met een max-breedte van 960px. Er zijn twee extra containers die helpen bij het beheren van de breedte van andere delen van de interface, zoals de header en de zijbalk: workspace container (max-breedte 1440px) en page container (1650px). Hieronder vindt u diagrammen die illustreren hoe deze containers werken. Er zijn bepaalde pagina's waarvan de inhoud niet wordt beperkt door de inhoudscontainer, waaronder geschiedenis, recente wijzigingen en andere vergelijkbare pagina's van het logboektype.

Ontwerpvereisten en richtlijnen

Hier is een GIF die het verschil illustreert tussen de huidige lay-out en de bijgewerkte lay-out met de verschillende breedtebeperkingen die hierboven zijn beschreven:

Een GIF waarin de huidige lay-out wordt vergeleken met de bijgewerkte lay-out die de inhoudsbreedte beperkt

Beperkingen

De belangrijkste complicatie hier is dat bepaalde logboekpagina's, zoals Geschiedenis en Recente wijzigingen, moeilijker te lezen worden naarmate het scherm smaller wordt als gevolg van regelomloop. Daarom hebben we besloten om deze pagina's op een speciale manier te behandelen, waarbij we ze alleen beperken tot de werkruimtecontainer (1440px) in plaats van de inhoudscontainer (960px). Hier is een GIF van een prototype die het schakelen tussen een artikelpagina en de bijbehorende geschiedenispagina laat zien:

Een GIF die de breedte van een artikelpagina weergeeft versus een geschiedenispagina in de vectorlay-out

Gebruikerstesten met editors

We hebben een feedbackronde uitgevoerd met een prototype van de beperkte inhoudsbreedte met editors over meerdere wiki's. Redacteuren werden uitgenodigd om het prototype te verkennen en hun feedback te geven met behulp van een centrale meldingsbanner. Er waren gemengde gevoelens over de functie: veel redacteuren waardeerden de kortere regellengtes en waren het erover eens dat de functie een comfortabelere leeservaring creëerde. Sommige redacteuren hadden een hekel aan de witruimte rond de inhoud en vonden dat het verspilde ruimte was. Al die feedback balanceren we met het uitgebreide bestaande onderzoek naar regellengtes en leescomfort.

Doelen en motivatie

Leesbaarheid

Onderzoek

Het primaire doel is het verbeteren van de leesbaarheid van Wikimedia-wikipagina's. We besloten om te werken aan de breedte van het inhoudsgebied. Er zijn op onderzoek gebaseerde aanbevelingen over dit onderwerp.

De populaire aanbeveling is dat er tussen de 40 en 75 tekens per regel moeten zijn. In de bevindingen van meerdere onderzoeken was de conclusie dat "korte lengtes gemakkelijker te lezen zijn". Met betrekking tot leren en het onthouden van informatie: "Proefpersonen die de smalle alinea's lazen, hadden een betere retentie dan degenen die de brede alinea's lazen".[2]

Web Content Accessibility Guidelines (WCAG)

Populaire sites met beperkte breedte

Er zijn veel populaire sites te vinden die aan deze richtlijnen voldoen.

  • Artikelen in het online wetenschappelijk tijdschrift Nature hebben een maximale breedte, wat resulteert in ~76 tekens per regel.
  • New York Times artikelen hebben ongeveer 64 tekens per regel.
  • Times of India artikelen zijn circa 100 tekens per regel (Hindi).
  • Oxford Academic journal artikelen zijn circa 75 tekens per regel.
  • Artikelen op de website van de World Health Organization zijn circa 96 (Latijns alfabet), circa 46 (Chinees alfabet) of circa 85 (Cyrillisch alfabet).
  • Bij gebruik van de leesmodus in Safari of Firefox wordt de tekst weergegeven met respectievelijk circa 73 en circa 77 tekens per regel (Latijns alfabet).

Vergelijking met Wikimedia-wiki's

Nu heeft een Engelse wiki-pagina van Wikimedia op een browservenster met 1280px circa 170 tekens per regel.[3] Dat is aan het kortere kant van het schermgrootte spectrum.

Op Wikimedia wiki groeit het karaktergetal per regel naarmate de schermbreedte toeneemt. Dus op de op één na populairste schermgrootte, 1920px (21% van de gebruikers), is het aantal tekens per regel circa 262, meer dan drie keer de aanbevolen waarde.[4]

Waarom niet kiezen voor "de eenvoudigste" oplossing

Op basis van de aanbevolen regellengte lijkt ergens rond de 700px redelijk. Waarom beperken we de breedte niet zo dat we de aanbevolen regellengte bereiken, zoals andere online content sites lijken te doen?

Omdat onze pagina's anders zijn, en daarom lezen mensen ze anders.

  • Wikimedia-wiki-pagina's zijn erg lang, bevatten veel informatie en zijn onderling niet uniform. Als gevolg hiervan hebben mensen de behoefte om op binnen de pagina's te zoeken. Dit is anders voor het lezen dan bij een typisch online artikel of een boek. Dit wordt ondersteund door ons onderzoek naar leestijd op Wikipedia.
  • Hoe smaller we de inhoud maken, hoe langer de pagina wordt. Misschien wordt het scannen ook moeilijker, omdat het o.a. meer scrollen inhoudt. Voor meer informatie over verschillende soorten online lezen, zie deze studie uit 2006 uitgevoerd door de Nielsen Norman Group.[5]
  • Bovendien is het niet eenvoudig om een bepaald aantal tekens per regel te bereiken. Dat komt omdat Wikimedia wiki-pagina's veel elementen bevatten die langs tekst in de tekst worden gezet.
Maan artikel op 550px breed, ononderbroken paragraaf met een aantal tekens per regel van circa 83
Een artikel over de maan met een breedte van 750px, lid naast de infobox met een aantal tekens per regel van circa 72

Ons ontwerp moet rekening houden met deze verschillen.

  • De breedte moet worden beperkt met een bepaalde hoeveelheid om het gefocust/geïntegreerd lezen te kunnen aanpassen. Dit betekent kortere regellengtes en minder dichtheid (density).
  • Tegelijkertijd moeten we lezers nog steeds in staat stellen om rond te zoeken en een visueel beeld van de pagina te krijgen zonder te veel te moeten scrollen. Dit is een argument voor langere regellengtes en meer dichtheid.

Hoe doen we dat?

Oplossing

Er zijn twee veel voorkomende ervaringen die we misschien willen overwegen.

  1. Het bovenste gedeelte van een artikel, een paragraaf van de tekst naast een infobox
  2. Het midden van een artikel, een paragraaf zonder onderbrekende elementen

We kunnen deze twee ervaringen op verschillende breedtes beschouwen en de lengte per regel voor elk tellen:

Breedte van de inhoud Paragraaf naast een infobox Niet onderbroken paragraaf
600px ~30 karakters per regel ~94 karakters per regel
700px ~59 ~109
800px ~76 ~125
900px ~89 ~142
1000px ~105 ~154

Bij een breedte van 1000 px is een ononderbroken alinea met tekst circa 154 tekens lang, ongeveer het dubbele van de bovengrens van het aanbevolen maximum aantal. Soms zijn er drijvende elementen die breder zijn dan infoboxen, wat resulteert in smalle tekstkolommen naast die elementen. Ook is er geen maximale breedte geweest. Hoewel sommige bewerkers op smalle schermen kunnen werken (of controleren hoe pagina's er op smalle scherm uitzien), is er waarschijnlijk inhoud op pagina's die er niet goed uitzien op een smalle breedte (nog), omdat het misschien niet een overweging was (bijv. grote tabellen).

Een andere aanpak is het bedenken van een op het raster gebaseerde lay-out. [6] Dit is een aanpak die zowel op de pagina gericht is op visuele harmonie als het nemen van beslissingen over spacing, breedte, enz. gemakkelijker. De skin Vector gebruikt nu geen raster. We kunnen de breedte van de infobox als een rasterkolom beschouwen (omdat het zo veel voorkomende elementen zijn), en dan een veelvoud daarvan gebruiken om de breedte van de inhoud te bepalen.

Artikel uit India met inhoud met 3x de breedte van een infobox
Artikel uit India met inhoud met 4x de breedte van een infobox

Voor een gewone leeservaring zorgen

De invoering van een maximale breedte zou bijdragen tot het verkrijgen van een gewone ervaring. Hopelijk zal het de redacteuren helpen bij het nemen van beslissingen over de lay-outs van pagina's.

NB: 1024px wordt genoemd als een minimumgrootte om te overwegen in de Handleiding van Stijl/Lay-out pagina. Dat is echter niet hetzelfde.

Nu kan een editor een pagina bewerken met een breedte van 1500px, terwijl een lezer het leest met een breedte van 1200px. Door een maximale breedte te implementeren, verwijderen we dit verschil niet volledig. Er zal nog steeds variatie zijn onder de vaste breedte, voor mensen met smallere schermen. We zullen dan echter het bereik van de variatie sterk beperken.

Conclusie

Na een goed overleg zijn we tot twee conclusies gekomen:

  1. Het lijkt erop dat een maximale breedte van 800-1000px een verstandig uitgangspunt is. We zullen de inhoud op de pagina centreren om ervoor te zorgen dat deze er goed uitziet met de zijbalk, zowel geopend als gesloten.
  2. Het lijkt de moeite waard om een studie te doen die zich specifiek richt op de leesbaarheid van Wikipedia-artikelen. Wij hopen dat we de middelen kunnen vinden om dit te doen.
Het weergeven van inhoud met een maximale breedte van 960px (zijbalk is gesloten)
Het weergeven van inhoud met een maximale breedte van 960px (zijbalk is geopend)

Aanvullende opmerkingen

Een notitie over het stuklopen van sjablonen, inhoud, speciale pagina's enz.

Een deel van wat Wikipedia en andere Wikimedia-wiki's een krachtig hulpmiddel maakt voor het delen van kennis is dat er heel weinig beperkingen zijn aan hoe informatie wordt gepresenteerd. Het resultaat hiervan is een grote verscheidenheid aan verschillende elementen op de pagina's: tabellen, afbeeldingsgalerijen, diagrammen, panoramische afbeeldingen, grafieken, formulieren, kaarten, categorievakken en meer. We hebben de uitdagingen van het ontwerpen van de mobiele site aangepakt en we laten de inhoud goed zien. We erkennen dat er soms situaties zijn waarin de pagina's er niet goed uitzien door de gekozen max-with. Ons plan is:

  • Met onze testwiki gemeenschappen werken om problemen te identificeren en oplossingen te bespreken met behulp van sjabloonstijlen of andere bestaande hulpmiddelen.
  • De maximale breedte niet implementeren op speciale pagina's. Speciale pagina's zijn niet bedoeld om te "lezen". Ze functioneren vaak meer als lijsten of dashboards. Totdat we tijd hebben om de details over meer responsieve lay-outs voor deze pagina's te onderzoeken, zullen we ze niet wijzigen. Hier is een eerste prototype van hoe dit zou kunnen werken. U kunt schakelen tussen "View history" en "Read" om het te begrijpen: https://di-collapsible-sidebar-5.firebaseapp.com/Tea

Eerder overleg

Dit onderwerp is al eerder besproken.

Voeg hier links toe naar ander eerder overleg.

Schakelaar over de volledige breedte

the fullscreen toggle icon
De schakelaar fullscreen

Tot oktober 2022 konden ingelogde gebruikers alleen met behulp van gadgets tussen de beperkte en volledige inhoudsbreedte wisselen. Volgens de Engelse Wikipedianen was dit onvoldoende. We hebben besloten om een schakelaar te maken. (Aan de rechterkant ziet u een screenshot van deze schakelaar.) Het moest zichtbaar en beschikbaar zijn voor zowel uitgelogde als ingelogde gebruikers. Als gevolg hiervan hebben we:

  1. Een voorkeursoptie gemaakt voor ingelogde gebruikers. De optie maakt het mogelijk om de breedte in te stellen voor paginaweergaven en wiki's. De voorkeur is beschikbaar in het gedeelte Uiterlijk bij de Voorkeuren ("Inschakelen modus beperkte breedte"). Het kan ook worden ingesteld als een |globale voorkeur.
  2. Een schakelaar gemaakt voor ingelogde en uitgelogde gebruikers. De schakelaar is beschikbaar op elke pagina als de breedte van het scherm groter is dan 1400px. Door het kiezen van de schakelaar wordt het inhoudsgebied groter.
    • Voor ingelogde gebruikers wordt de schakelaar ook door de in punt 1 genoemde voorkeur gestuurd. Als u bijvoorbeeld op de schakelaar op de pagina klikt en de pagina voorkeuren bezoekt, ziet u dat het selectievak Inschakelen modus beperkte breedte niet is aangevinkt.
    • Voor gebruikers die zich niet hebben aangemeld, wordt de breedte in eerste instantie per pagina ingesteld. Dit betekent dat na het vernieuwen van de pagina of het openen van een andere pagina de breedte terugkeert naar de standaardwaarde (beperkt).
    • Nadat onze skin de standaard op de Engelstalige Wikipedia is gemaakt, hoorden we zorgen over de instelling voor uitgelogde gebruikers. Na afstemming met meerdere teams hebben we een verandering doorgevoerd. Sinds februari 2023 zien alle gebruikers de breedte-instelling van hun keuze, ondanks het vernieuwen van pagina's of het openen van nieuwe pagina's.

Waarom werkte de schakelaar aanvankelijk per pagina? Dit kwam omdat voorkeuren in principe niet beschikbaar zijn voor uitgelogde gebruikers. Het ontbreken van voorkeuren voor uitgelogde gebruikers is niet alleen van toepassing op deze skin. (Meer over de technische beperkingen .) We zijn erin geslaagd voor de korte termijn een bypass te vinden. We hebben meer werk te doen om ervoor te zorgen dat deze oplossing kan worden gehandhaafd. Misschien is er in de toekomst een betere oplossing. Dit kan worden toegepast op instellingen zoals lettergrootte of donkere modus.


Referenties

  1. Size Matters: Balancing Line Length And Font Size In Responsive Web Design
  2. Computer text line lengths affect reading and learning by Peter Orton, Ph.D. IBM Center for Advanced Learning
  3. Waarom 1280px? Vanaf midden 2020 is de meest voorkomende schermgrootte volgens StatCounter 1366px breed, voor 22% van de gebruikers. Als u zich een browservenster voorstelt met bijna volledige breedte, krijgt men circa 1280px.
  4. We nemen weer aan dat het browservenster bijna volledig breed is.
  5. K. Pernice, K. Whitenton, J. Nielsen, "How People Read Online: The Eyetracking Evidence (Hoe mensen online lezen: het bewijs van het volgen van de ogen)", 2e editie
  6. Overzicht van het onderwerp: bouwen van betere UI-ontwerpen met lay-out grids