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

خوانایی
دلیل اصلی ما برای محدود کردن عرض محتوا ، بهبود خوانایی همه مطالب شگفت انگیز موجود در ویکی‌های ما است. خواندن متن به روشی کارآمد برای اکثریت قریب به اتفاق همه‌ی موارد استفاده از مطالعه و ویرایش در سرتاسر پروژه های ما حیاتی است. در حالی که عوامل مختلفی بر خوانایی تأثیر می‌گذارد – یعنی اندازه قلم ، کنتراست ، قلم و طول خط – ما تصمیم گرفتیم در ابتدا روی طول خط تمرکز کنیم. تحقیقات بر روی خواندن متون چاپی، طول خط را بین ۴۵ تا ۹۰ نویسه در هر خط پیشنهاد می‌دهد. تحقیقات اخیر در مورد خواندن متن وب‌گاه عمدتاً در محدوده ۳۵ تا ۱۰۰ نویسه در هر خط متمرکز شده است و بیشتر توصیه‌ها به انتهای کوچکتر آن محدوده مربوط می‌شود. با این حال، در حال حاضر بدون هیچ گونه محدودیت عرض در محتوای مقاله، خوانندگان می‌توانند طول خطوط بسیار بیشتر از محدوده توصیه‌شده داشته باشند. مطالعه ای که در سال ۲۰۰۵ انجام شد، آخرین تحقیقات را به خوبی خلاصه می‌کند: «خواندن طول خطوط کوتاه آسان‌تر است» و علاوه بر این، در مورد یادگیری و حفظ اطلاعات، «افرادی که پاراگراف‌های باریک را می‌خوانند نسبت به کسانی که پاراگراف‌های گسترده را می خوانند، متن را بهتر حفظ می‌کنند».

در نهایت، در حالی که همیشه برای ما مهم است که تحقیقات خود را انجام دهیم و نتیجه‌گیری خود را انجام دهیم، معنقدیم که باید به تعداد زیادی از وب‌گاه‌های اصلی که دارای محدودیت‌های مشابه در عرض محتوا هستند توجه کرد. به عنوان مثال: مجلات دانشگاهی مانند نیچر، وب‌گاه‌های خبری مانند نیویورک تامیز، وب‌گاه‌های دولتی و بین دولتی مانند سازمان ملل، اسناد دانشگاهی مانند لی‌تک و پردازشگر کلمات مانند گوگل داکز و Etherpad. این مثالها همراه با تحقیقات گسترده، به ما در این تصمیم اطمینان می‌دهد.

به طور خلاصه، محدود کردن عرض محتوا باعث خوانایی بهتر، خستگی کمتر چشم و حفظ بهتر خود اطلاعات می‌شود.

اما در مورد کل فضای سفید چطور !؟
ما نظر حدود ۳۰ ویرایشگر (به ویژه افرادی که دارای صفحه‌نمایش بزرگ هستند) که از تمام فضای سفید ایجاد شده در طرف صفحه خسته شده‌اند را شنیده‌ایم، اگرچه برخی از آنها موافقند که محدودیت عرض برای خواندن بهتر است. به نظر می‌رسد دو دلیل اصلی برای این خسته شدن‌ها وجود دارد: هدف ما ایجاد بهترین تجربه خواندن است، نه پر کردن هر پیکسل روی صفحه با محتوا. و در این مورد، افراد می‌توانند راحت‌تر با طول خطوط کوتاه‌تر بخوانند و بدون تمرکز ستون‌های فرعی یا عناصر دیگر به راحتی تمرکز کنند. اگر بهترین طرح‌بندی شامل فضای خالی باشد، مشکلی وجود ندارد. هیچ چیز ذاتاً با فضای خالی مشکلی ندارد.
 * 1) The white space feels like wasted space
 * 2) The white space is bright and distracting

علاوه بر این، ما امیدواریم که با پیشرفت پروژه، استفاده از بخشی از این فضا برای سایر قابلیت ها را آغاز کنیم. ما آزمایش چسباندن نوار کناری به سمت چپ صفحه (پیوند به نمونه اولیه) را آغاز کرده‌ایم. 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.

Why can’t readers just make their browser windows smaller?
Several people have pushed back saying: if people want the content to be more narrow they can make their browser window smaller, or click the “Mobile view” link at the bottom of the page. As mentioned above: since we know that the majority of people come to read articles we should optimise the layout around that use case. We only have one chance to make a first impression and we should aim to give people a great experience as soon as they arrive, without them having to make adjustments.

Tables and other templates don’t fit within the limited width, isn’t that bad?
We have received several reports of tables with long horizontal scroll bars, or templates that expand past the limited width. We’d like to point out that a large percentage of our users, who don’t have large screens and are accessing Wikipedia from their laptops, already had issues with tables and templates even before the change. We should work to make sure that all of our content is as responsive as possible to accommodate all visitors.

Why don’t we just make it a setting?
One of the best parts of the MediaWiki interface is how configurable it is. 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). Currently an editor might be editing a page at a width of 1500px, while a reader reads it at a width of 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.

How did we decide on 960px for the width?
Please review this page to learn more about how we made this decision:

چه زمانی این تغییرات در ویکی‌های بزرگتر در دسترس خواهد بود؟
ما امیدوارم که این تغییرات تا پایان امسال به شکل پیش‌فرض برای همه ویکی‌ها در آید. کاربران برای عضویت در پذیرنده‌های اولیه آزاد هستند.

آیا بهبودها در پروژه‌های خواهر و ویکی‌های غیرلاتین هم پیاده‌سازی می‌شوند؟
بله، ما از قبل فهرستی از ویکی‌های «پذیرنده اولیه» داریم که نمایانگر اندازه‌ها و زبان‌های متفاوت هستند. همچنین قصد داریم مطمئن شویم که حداقل پروژه‌های غیر از ویکی‌پدیا نیز انتخاب شده باشند.

این تغییرات در کدام‌یک از ویکی‌ها به صورت پیش‌فرض فعال است؟
در حال حاضر:


 * پروژه‌های خواهر:
 * 
 * 
 * 


 * ویکی‌های با زبان غیر لاتین
 * bn:
 * he:
 * fa:
 * ko:
 * sr:


 * ویکی‌های با زبان لاتین:
 * eu:
 * fr:
 * pt:
 * sr:
 * tr:
 * vec:


 * به علاوه:
 * ویکی‌آفیس
 * 

ما مایلیم ویکی‌های بیشتری را به فهرست بیافزاییم!

How can this be deployed on my home Wikimedia 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.

چگونه می‌توانم این امکان را در ویکی شخصی خودم فعال کنم؟
در وهله اول، بررسی کنید که را دانلود کرده باشید. آگاه باشید که نسخه پایدار در اواسط ۲۰۲۱ عرضه خواهد شد. 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!

آیا مونوبوک یا تایم‌لس متاثر خواهند بود؟
No. These changes will be applied to Vector only. [ Vector] has been the default interface on Wikimedia wikis since 2010. No other skins will be affected, including [ Monobook], [ Timeless], [ Minerva] or [ Modern].

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.

How can I disable it?
It's possible to turn the improvements on and off within user preferences. We have also provided an opt-out button in the left sidebar (accessible on each page): 

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.

چگونه می‌توانم یک مشکل را گزارش کنم؟
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.