Reading/Web/Desktop Improvements/Frequently asked questions/te

పఠనీయత
వెడల్పు పరిమితించడానికి కారణం, మా వికీల్లో ఉన్న గొప్ప కంటెంటు పఠనీయతను మెరుగు పరచడమే. మా ప్రాజెక్టులన్నిటిలో చదవడం, దిద్దడం చెయ్యడం వంటి పనులకు, పాఠ్యాన్ని సమర్థవంతంగా చదవగలగడమనేది కీలకమైన విషయం. పఠనీయతను ప్రభావితం చేసే కారకాలు - ఫాంటు పరిమాణం, కాంట్రాస్టు, ఫాంటు, లైను పొడవు వంటివి - అనేకం ఉన్నప్పటికీ, ముందు లైను పొడవుపై దృష్టి పెట్టాలని మేం నిర్ణయించుకున్నాం. ముద్రిత పాఠ్యాలపై చేసిన తొలి లైను పొడవు పరిశోధన ప్రకారం, లైను పొడవు 45 - 90 క్యారెక్టర్ల మధ్య ఉండాలి (cpl). Recent research on reading of website text focuses primarily within the range of 35 – 100 cpl, with most recommendations falling towards the smaller end of that range. However currently without any width limitation on article content readers might find themselves with line lengths far above the recommended range. A 2005 study summarizes the latest research well: "short line lengths are easier to read", and furthermore, regarding learning and information retention, "subjects reading the narrow paragraphs had better retention than those reading the wide paragraphs".

Lastly, while it’s always important for us to do our own research and form our own conclusions, we think it’s worth noting the overwhelming amount of major websites that have similar limitations on content width. ఉదాహరణకు: నేచర్ వంటి విద్యా విషయక పత్రికలు, ది న్యూ యార్క్ టైమ్స్ వంటి వార్తా వెబ్‌సైట్లు, ఐరాస వంటి ప్రభుత్వ అంతర ప్రభుత్వ వెబ్‌సైట్లు, LaTeX వంటి విద్యా విషయక డాక్యుమెంట్లు, గూగుల్ డాక్స్, ఎథర్‌ప్యాడ్ వంటి వర్డ్ ప్రాసెసర్లు. ఆ ఉదాహరణలతో, విస్తారమైన పరిశోధనతో కలిసి, ఈ నిర్ణయంపై మాకు ఆత్మవిశ్వాసం కలుగుతోంది.

ఒక్కమాటలో చెప్పాలంటే, కంటెంటు వెడల్పును పరిమితించడం వలన పఠనీయత పెరుగుతుంది, కళ్ళపై భారం తగ్గుతుంది, సమాచారాన్ని మరింత మెరుగ్గా ఆకళింపు చేసుకోవచ్చు.

మరి, ఆ ఖాళీస్థలం సంగతేంటి?
We have heard from around 30 editors (particularly people with large screens) who are frustrated by all of the white space created on the sides of the page, though some of them agree that the width limitation is better for reading. There seem to be two main causes of this frustration: Our goal is to create the best reading experience we can, not to fill every pixel of the screen with content. And in this case less is actually more — people are able to read more easily with shorter line lengths, and focus more easily without the distraction of sidebars or other elements. If the best layout is one that includes white space that is okay — there is nothing inherently wrong with white space.
 * 1) The white space feels like wasted space
 * 2) The white space is bright and distracting

Additionally, as the project proceeds, we are hoping to begin utilizing some of this space for other functionality. We have started experimenting with making the sidebar sticky to the left side of the page (link to prototype). Further along in the project we plan to experiment with putting a table of contents and/or page tools next to the content. Also, as, limiting the content width gives us new options for content layout, such as a right-hand column dedicated to infoboxes and images.

పాఠకులే తమ బ్రౌజరు విండోలను చిన్నవిగా చేసుకోవచ్చు గదా?
చాలామంది మాకు అలానే చెప్పారు: కంటెంటు వెడల్పును తగ్గించుకోవాలని జనం అనుకుంటే, వాళ్ళు తమ బ్రైజరు విండోను చిన్నదిగ చేసుకోవచ్చు. లేదా, పేజీకి అడుగున ఉండే "మొబైల్ వీక్షణ" లింకును నొక్కికుంటారు. పైన చెప్పినట్లు: సైటుకు వచ్చేవాళ్ళలో సింహభాగం వ్యాసాలను చదివేందుకు వస్తారని మాకు తెలుసు కాబట్టి, ముందు వారి కోసం సైటు లేఔటును ప్రామాణీకరించాలి. తొలి చూపు లోనే జనాన్ని అలరింపజేసే అవకాశం మాకు ఒకేసారి వస్తుంది. వాళ్ళు వచ్చీ రాగానే, వాళ్ళు సర్దుబాట్లు చేసుకోవాల్సిన అవసరమేమీ లేకుండానే వారికి ఒక గొప్ప అనుభూతిని కలిగించడం మా లక్ష్యం కావాలి.

పట్టికలు, ఇతర మూసలూ పరిమితమైన ఈ వెడల్పులో ఇమడవు, మరి అది బాలేదు కదా?
పట్టికలు, మూసలు ఈ పరిమితమైన వెడల్పును దాటి పోతున్నాయని మాకు అనేక ఫిర్యాదులు వచ్చాయి. ఈ మార్పు చెయ్యక ముందు కూడా, మా వాడుకరుల్లో పెద్దపెద్ద తెరలు లేని వారు, ల్యాప్‌టాపులపై చూస్తున్నవారూ చాలామంది ఈసరికే పట్టికలు, మూసలతో సమస్యలు ఎదుర్కొంటున్నారు. మా కంటెంటంతా మా సందర్శకులందరికీ ఒకే విధంగా కనబడేలా చేసేందుకు మేం కృషి చెయ్యాలి.

దాన్నొక సెట్టింగు లాగా ఎందుకు పెట్టం?
ఇంటర్‌ఫేసును కావలసిన విధంగా మలచుకోవడం, మీడియావికీ ఇంటర్‌ఫేసు అత్యుత్తమ అంశాల్లో ఒకటి. And while we could make a setting for content width we wonder if it might be beneficial to encourage a common experience that is shared between editors and readers. This could potentially be helpful to editors when making decisions about page layouts (note: 1024px is mentioned as a minimum size to consider in the English Wikipedia Manual of Style, though that’s not quite the same thing). ప్రస్తుతం ఓ పేజీని ఎడిటరు 1500px వెడల్పు వద్ద దిద్దుబాటు చేస్తూండవచ్చు. అదే పేజీని ఓ పాఠకుడు 1200px వద్ద చదువుతూ ఉండవచ్చు. By implementing a max-width we don’t remove this discrepancy completely (because there would still be variation below the max-width, for people with narrower screens), however we would be greatly limiting the range of variation.

That said, we are not inherently against configurability. If you would like to continue using the new version of the Vector skin without the limited width, you can use a local user script or gadget to do so. We can recommend this one.

వెడల్పు 960px ఉండాలని మేమెలా నిర్ణయించాం?
మేం ఈ నిర్ణయం ఎలా తీసుకున్నామో మరింతగా తెలుసుకునేందుకు ఈ పేజీని చూడండి:

అతిపెద్ద వికీల్లో ఈ మార్పులు ఎప్పుడు అందుబాటు లోకి వస్తాయి?
సముదాయం లోని వాడుకరులు మా టెస్టింగులో చేరితే తప్ప, 2021 మొదటి సగంలో నైతే జరగదు. ఈసరికే సేకరించిన డేటా ఆధారంగా కొత్త ఆంశాల అభివృద్ధి లోను, తొలి వికీల్లో పరీక్షించడం లోనూ ప్రస్తుతం మేం నిమగ్నమై ఉన్నాం. ఈ సంవత్సరం మలి భాగంలో అన్ని వికీల్లోను ఈ మార్పులను డిఫాల్టుగా అమర్చగలమని ఆశిస్తున్నాం. Each community is welcome to join the early adopters.

ఈ మెరుగుదలలను సోదర ప్రాజెక్టుల్లోను, లాటినేతర లిపుల వికీల్లోనూ అమలు చేస్తారా?
చేస్తాం. మేం ఈసరికే కొన్ని వేగు చుక్క వికీల జాబితాను తయారుచేసుకున్నాం. వీటిలో వివిధ సైజులకు, వివిధ లిపులకు చెందినవి ఉన్నాయి. కనీసం ఒక్కటైనా వికీపీడియా యేతర ప్రాజెక్టును ఎంచుకోవాలని మేం అనుకున్నాం.

ఈ మార్పులు ఏయే వికీల్లో డిఫాల్టుగా ఆన్ అయి ఉంటాయి?
ప్రస్తుతానికి ఇవి: మరిన్ని వికీలను ఈ జాబితా లోకి చేర్చేందుకు మేం సుముఖం గానే ఉన్నాం!


 * అదనంగా:
 * ఆఫీసు వికీ
 * 
 * MediaWiki wiki
 * Wikimedia Foundation Governance wiki
 * Collab wiki
 * Strategy wiki

మా వికీలో దీన్ని స్థాపించడం ఎలా?
If you are interested to see the Desktop Improvements as default on your wiki,
 * 1) ask your community and reach the consensus,
 * 2) contact SGrabarczuk (WMF), email: sgrabarczuk@wikimedia.org if you need support.

How can I enable it on my own (third-party) wiki?
First, make sure you have downloaded. If you accept the risk and would like to see our changes anyway, add following lines in your :

We are glad to learn that you appreciate our improvements!

మోనోబుక్, టైమ్‌లెస్ లలో మార్పులు జరుగుతాయా?
లేదు. ఈ మార్పులు వెక్టర్‌లో మాత్రమే జరుగుతాయి. 2010 నుండి వికీమీడియా వికీలకు [ వెక్టరే] డిఫాల్టు ఇంటర్‌ఫేసుగా ఉంటూ ఉంది. [ మోనోబుక్], [ టైమ్‌లెస్], [ మినర్వా], [ మోడర్న్] తదితర రూపులు దేనిలోనూ మార్పులు జరగవు.

Will you improve charts, maps, a-/f-/o-/tmboxes, infoboxes, navboxes, other templates?
No. We will not change anything that's within the light gray article content area (except for the table of contents):



How can I suggest improvements?
Add a section on the [ talk page of the main page of the project] or contact SGrabarczuk (WMF), email: sgrabarczuk@wikimedia.org.

How do you work with the communities?

 * 1) Prior to the deployments:
 * 2) We performed user research, and reviewed gadgets and user scripts. See the  for more details.
 * 3) We have been reaching out to various wikis asking to join the early adopters.
 * 4) We had a roundtable discussion at Wikimania in 2019 (see the outcomes).
 * 5) We have run two prototype testing rounds. Editors could gain an understanding of our ideas, and share what they appreciate or find confusing.
 * 6) Shortly after the deployment of each feature improvement, we collect usage data via  for each early adopter wiki.
 * 7) We run A/B tests for logged-in users. A half of them can experience the changed interface, and a half does not see any difference. Next, we compare the statistics. In the case of negative results, we improve the change or roll it back.
 * 8) For logged-out, we compare before and after. Unfortunately, we are not able to perform A/B tests on logged-out users.
 * 9) We watch the project talk page. We also engage in discussions on individual wikis regularly.
 * 10) Our  make it easier for us to work with a few communities more closely, react more quickly and effectively.

దాన్ని అచేతనం చెయ్యడం ఎలా?
మీ అభిరుచులలో ఈ మెరుగుదలలను ఆన్, ఆఫ్ చేసుకోవచ్చు. ఎడమ నేవిగేషను పట్టీలో ఆఫ్ చేసుకునే బొత్తాన్ని కూడా ఇచ్చాం (దీన్ని ప్రతిపేజీ లోనూ చూడవచ్చు), ఇలా: [$optout ]. 

Will you remove the link that allows to opt-out?
We will not remove the opt-out link. Legacy Vector will continue to be available through that link, similar to other skins that have been default in the past, such as Monobook.

How can I report a bug?
Check the following page to see if your bug is a know issue.

You can add a task on Phabricator and add Desktop Improvements project tag or contact SGrabarczuk (WMF), email: sgrabarczuk@wikimedia.org.

Why not make a new skin? What will happen to Legacy Vector?
It would be an excellent idea to make a new skin, but in the case of Wikimedia skins, it's easier to change an existing one than to create a new one from scratch. There are various reasons:


 * it would be too complex to make the existing extensions, gadgets, and user scripts compatible with yet another skin, and too costly to maintain their compatibility,
 * it would be too challenging to build and maintain yet another skin (as a total replacement is not an option),
 * it would be less likely for the communities to collaborate effectively in the process of building a new skin.

Technically, Desktop Improvements are similar to previous features or projects such as or. The only difference is that this time, there will be more of them. Vector documentation should remain relevant.

We will keep and maintain the Legacy Vector. There is no intention of its removal.

Why not use beta features only?
Beta features are available for registered users only, and the improvements are intended to serve our readers and unregistered users as well. Therefore, using beta features only would give us feedback from a very specific type of user that is not representative of our entire base of users. And moreover, we wish to receive the readers' and anonymous users' feedback from the earliest deployments.

What are the feature's success metrics?
Increase utility among our existing audiences, proxied by:


 * Interactions
 * Increase searches per session by 5% over the course of the project
 * Increase language switching per project by 5% over the course of the project


 * Affinity
 * Increase in positive and welcoming sentiments towards the site (via surveys and user testing)
 * Increase in sentiments of trust and credibility (measured via surveys and user testing)

As we define the changes we want to make with more specificity, we will expand and iterate on this list.