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

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

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

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

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

علاوه بر این، ما امیدواریم که با پیشرفت پروژه، استفاده از بخشی از این فضا برای سایر قابلیت ها را آغاز کنیم. ما آزمایش چسباندن نوار کناری به سمت چپ صفحه (پیوند به نمونه اولیه) را آغاز کرده‌ایم. ما در ادامه پروژه قصد داریم یک جدول از محتویات و/یا ابزارهای صفحه را در کنار محتوا قرار دهیم. همچنین همانطور که ، محدود کردن عرض محتوا گزینه‌های جدیدی را برای چیدمان محتوا در اختیار ما قرار می‌دهد، مانند یک ستون سمت چپ اختصاص داده شده به جعبه اطلاعات و تصاویر.

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

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

چرا این را به عنوان بخشی از تنظیمات تبدیل نمی‌کنیم؟
یکی از بهترین بخش‌های رابط مدیاویکی نحوه تنظیم آن است. و در حالی که می‌توانیم تنظیماتی برای عرض محتوا انجام دهیم، اما نمی‌دانیم که آیا تشویق یک تجربه مشترک که بین ویراستاران و خوانندگان به اشتراک گذاشته می‌شود مفید خواهد بود یا خیر. این امر به طور بالقوه می‌تواند برای ویرایشگران هنگام تصمیم‌گیری در مورد چیدمان صفحه مفید باشد (توجه داشته باشید که ۱۰۲۴ پیکسل به عنوان حداقل اندازه مورد استفاده در شیوه‌نامه ویکی پدیا انگلیسی ذکر شده است، اگرچه کاملاً یکسان نیست). در حال حاضر یک ویرایشگر ممکن است صفحه‌ای را در عرض ۱۵۰۰ پیکسل ویرایش کند، در حالی که خواننده آن را در عرض 1200 پیکسل می‌خواند. با پیاده‌سازی یک حداکثر عرض صفحه، ما این اختلاف را به طور کامل برطرف نمی‌کنیم (زیرا افرادی که صفحه نمایش آنها باریک‌تر است، میزان حداکثر عرض صفحه آنها نیز کمتر است)، با این حال ما دامنه تنوع را بسیار محدود می‌کنیم.

با این وجود، ما ذاتاً با قابلیت پیکربندی مخالف نیستیم. اگر می‌خواهید از نسخه جدید پوسته وکتور بدون عرض محدود استفاده کنید، می توانید از اسکریپت یا ابزار کاربر محلی برای این کار استفاده کنید. این را می‌توانیم پیشنهاد دهیم.

جطور در مورد عرض 960px تصمیم نهایی را گرفتیم؟
لطفاً این صفحه را مرور کنید تا در مورد نحوه تصمیم‌گیری‌مان بیشتر بدانید:

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

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

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


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


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


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


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

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

چگونه می‌توانم این را در ویکی‌مدیای شخصی‌ام به کار بگیرم؟
اگر می‌خواهید که بهبودهای دسکتاپ را به صورت پیش فرض در ویکی خود مشاهده کنید،
 * 1) در ویکی خود به اجماع برسید،
 * 2) با SGrabarczuk (WMF) تماس بگیرید، ایمیل: sgrabarczuk@wikimedia.org در صورت نیاز به پشتیبانی.

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

خوشحالیم که می‌بینیم که از بهبودهای ما راضی هستید!

آیا مونوبوک یا تایم‌لس متاثر خواهند بود؟
خیر. این تغییرات فقط در وکتور اعمال خواهند شد. [ وکتور] از سال ۲۰۱۰ رابط پیش‌فرض ویکی‌های ویکی‌مدیا بوده است. هیچ پوسته دیگری تحت تاثیر قرار نمی‌گیرد، از جمله [ مونوبوک]، [$ Timeless تایم‌لس] ، [$ minerva مینروا] یا [$ modern مدرن].

آیا نمودارها، نقشه‌ها، جعبه اطلاعات، جعبه‌های ناوبری و سایر الگوها را بهبود می‌بخشید؟
خیر. ما هیچ چیزی را که در محدوده خاکستری روشن «محتویات مقاله» (به جز فهرست مطالب) را تغییر نمی‌دهیم:



چگونه می‌توانم پیشنهادی برای بهبود بدهم؟
بخشی را به [ صفحه بحث پروژه] اضافه کنید یا با SGrabarczuk (WMF) تماس بگیرید، ایمیل: sgrabarczuk@wikimedia.org.

چگونه با ویکی‌ها کار می‌کنید؟

 * 1) قبل از به‌روز رسانی
 * 2) ما تحقیقات بین کاربران را انجام دادیم، ابزارها و اسکریپت‌های کاربر را بررسی کردیم. برای جزئیات بیشتر به  مراجعه کنید.
 * 3) ما با ویکی‌های مختلف تماس گرفته‌ایم که درخواست پیوستن به پذیرندگان اولیه را دارند.
 * 4) ما بحثی در ویکی‌مانیای ۲۰۱۹ داشتیم (نتایج را ببینید).
 * 5) ما دو دور آزمایش اولیه را اجرا کرده‌ایم. ویراستاران می‌توانند از ایده‌های ما درک کنند و آنچه را که از آن رضایت دارند یا برایشان گیج‌کننده است را به اشتراک بگذارند.
 * 6) مدت کوتاهی پس از توسعه هر ویژگی، ما داده‌های استفاده‌شده را از طریق  برای هر ویکی پذیرنده اولیه جمع‌آوری می‌کنیم.
 * 7) ما A/B tests را برای کاربران وارد شده اجرا می‌کنیم. نیمی از آنها می‌توانند رابط کاربری تغییریافته را تجربه کنند و نیمی از آنها هیچ تفاوتی را مشاهده نمی‌کنند. در مرحله بعد، آمار را مقایسه می‌کنیم. در صورت نتایج منفی، تغییر را بهبود می‌بخشیم یا به عقب برمی‌گردانیم.
 * 8) برای خروج از سامانه، «قبل و بعد» را مقایسه می‌کنیم. متأسفانه نمی‌توانیم آزمایش‌های A/B را روی کاربران خارج شده از سامانه انجام دهیم.
 * 9) ما صفحه بحث پروژه را دنبال می‌کنیم. همچنین به طور مرتب در مورد هر ویکی بحث می‌کنیم.
 * 10)  ارتباط نزدیک‌تر برقرار کردن با ویکی‌های مختلف را برایمان آسان‌تر، سریع‌تر و کارآمدتر می‌کنند.

چگونه می‌توانیم غیرفعالش کنم؟
این امکان وجود دارد که بهبودها را در ترجیحات کاربر روشن یا خاموش کنید. همچنین یک دکمه انصراف در نوار کناری سمت چپ (قابل دسترس در هر صفحه) ارائه کرده‌ایم: 

آیا پیوندی را که اجازه انصراف می‌دهد حذف خواهید کرد؟
پیوند انصراف را حذف نخواهیم کرد. پوسته وکتور مانند سایر پوسته‌هایی که در گذشته به صورت پیش‌فرض مانند مونوبوک در دسترس بوده‌اند، از طریق همان پیوند همچنان در دسترس خواهد بود.

چگونه می‌توانم یک مشکل را گزارش کنم؟
صفحه زیر را بررسی کنید تا ببینید آیا اشکال شما مشکلی رایج است:

می توانید یک وظیفه را به Phabricator اضافه کنید و برچسب Desktop Improvements را به آن اضافه کنید یا با SGrabarczuk (WMF) تماس بگیرید، ایمیل: sgrabarczuk@wikimedia.org.

چرا یک پوسته جدید نمی‌سازید؟ چه اتفاقی برای وکتور قدیمی می‌افتد؟
ایجاد پوسته جدید ایده بسیار خوبی است، اما در مورد پوسته‌های ویکی‌مدیا، تغییر پوسته موجود آسانتر از ایجاد پوسته جدید از ابتدا است. دلایل مختلفی هم برای آن وجود دارد:


 * 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.