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

קְרִיאוּת
הסיבה העיקרית שלנו להגבלת רוחב התוכן היא שיפור הקריאה של כל התוכן המדהים במיזמי הוויקימדיה שלנו. קריאת טקסט בצורה יעילה הינה מכרעת עבור הרוב הגדול של כל מקרי השימוש בקריאה ועריכה בפרוייקטים שלנו. אמנם ישנם מספר גורמים המשפיעים על הקריאות - כלומר גודל הגופן, הניגודיות, הגופן ואורך השורה - אך החלטנו להתמקד בתחילה באורך השורה. על פי מחקר שבוצע לגבי אורכי השורות שעדיפים לקוראים בצורה הדיגיטלית, אורכי השורות המומלצות הן ביו 45 ל-90 תווים בשורה (cpl). מחקרים אחרונים בנושא קריאת טקסטים באתר מתמקדים בעיקר בטווח של 35-100 cpl, כאשר מרבית מההמלצות נופלות לקצה הקטן יותר של טווח זה. אולם כרגע ללא כל מגבלת רוחב על תוכן הערכים, הקוראים עשויים למצוא את עצמם באורכי קו הרבה מעבר לטווח המומלץ. מחקר מ-2005 מסכם היטב את המחקר העדכני: "אורכי שורה קצרה קלים יותר לקריאה", ויתרה מכך, לגבי למידה ושמירת מידע בזיכרון, "למתנדבים שקראו את הפסקאות הקצרות יותר, היה להם זיכרון יותר טוב של הפסקאות הקצרות מאשר אלו שקראו את הפסקאות הרחבות". .

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. For example: academic journals like Nature, news websites like The New York Times, government and intergovernmental websites like the UN, academic documents like LaTeX, and word processors like Google Docs and Etherpad. Those examples, combined with the extensive research, gives us confidence in this decision.

In short, limiting the width of the content allows for better readability, less eye strain, and better retention of the information itself.

But what about all of the white space!?
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.

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:

מתי יהיו השינויים האלו זמינים במיזמי הויקימדיה הגדולים?
לפחות לא ב-2020, אלא אם כן הקהילה באותו מיזם ביקשה להצטרף לבדיקות שלנו. נכון לעכשיו, אנו מתמקדים בפיתוח התכונות הראשונות שלנו על סמך נתונים שכבר אספנו, ובבדיקות במיזמי הויקימדיה שמאמצים את השינויים האלו. אנו מקווים לראות את השינויים שנקבעו כברירת מחדל על כל מיזמי ויקימדיה כבר ב-2021.

האם יש לבצע את השיפורים האלו בפרוייקטים אחרים ובסקריפטים שאינם לטיניים?
כן. ערכנו כבר רשימה של מיזמי הויקימדיה שמאמצים את השינויים האלו. רשימה זו מייצגת מספר תסריטים שונים. רצינו גם להבטיח כי ייבחר לפחות פרוייקט אחד שאינו ויקיפדיה.

באילו מיזמי ויקימדיה שינויים אלו זמינים?
נכון לעכשיו, מיזמי הוויקימדיה שבהם יהו השינויים הם:


 * מיזמי אחות:
 * 
 * 


 * מיזמי ויקימדיה לא-לטיניים:
 * he:
 * fa:


 * מיזמי ויקימדיה לטינים:
 * eu:
 * fr:


 * Office Wiki

אנחנו מוכנים להוסיף עוד מיזמי ויקימדיה לרשימה זו!

כיצד ניתן להפיץ את זה במיזם הוויקימדיה שלי?
אם אתה מעוניין לראות את שיפורי שולחן העבודה כברירת מחדל בוויקי שלך, בצע את הצעדים הבאים:
 * 1) שאלו את הקהילה שלכם ותגיעו לקונצנזוס.
 * 2) אם יש צורך באיזשהי עזרה/תמיכה, צרו קשר עם SGrabarczuk (WMF) (דוא"ל: sgrabarczuk-ctr@wikimedia.org).

האם העיצובים מונובוק או מחוץ לזמן יושפעו בצורה כזאת או אחרת?
בכלל לא. שינויים אלו יחולו על עיצוב הוקטור בלבד. עיצוב ה[ וקטור] הוא ממשק ברירת המחדל בכל מיזמי הוויקימדיה מאז 2010. אף עיצובים אחרים לא יושפעו, כולל העיצובים [ מונובוק], [  מחוץ לזמן], [  מינרווה נויה] ו[  מודרני].

האם תשפרו תרשימים, מפות או תבניות כלשהם?
בכלל לא. לא נשנה שום דבר שנמצא באזור תוכן הערך (למעט תוכן העניינים):



כיצד ניתן להציע שיפורים?
הוסיפו פסקה ב[ דף השיחה של העמוד הראשי של שיפורי השולחן] או צרו קשר עם SGrabarczuk (WMF) (דוא"ל: sgrabarczuk-ctr@wikimedia.org).

כיצד אוכל לבטל את השינויים האלו?
אפשר להפעיל ולכבות את השיפורים בתוך ההעדפות. סיפקנו גם כפתור ביטול הסכמה בסרגל הצד השמאלי (נגיש בכל עמוד):.

איך ניתן לדווח על באג?
Check the following page to see if your bug is a know issue.

כדי לדווח על באג, יש ליצור משימה בפבריקטור (Phabricator) ולהוסיף את התג של הפרוייקט שיפורי שולחן העבודה או ליצור קשר עם SGrabarczuk (WMF) (דוא"ל: sgrabarczuk-ctr@wikimedia.org).

למה לא להכין עיצוב חדש? מה יקרה לעיצוב דור קודם?
זה יהיה רעיון מצוין בשביל ליצור עיצוב חדש, אבל במקרה של עיצובים במיזמי ויקימדיה, קל יותר לשנות אחד קיים מאשר ליצור חדש מאפס. ישנן מספר סיבות שונות לכך:


 * זה יהיה מורכב מדי בכדי להפוך את התוספות, הגאדג'טים והסקריפטים שקיימים כיום, בשביל שיתאימו לעיצוב אחר, וגם יקרים מכדי לשמור על תאימותם.
 * זה יהיה מאתגר מדי לבנות ולתחזק עיצוב נוסף (מאחר שתחליף מוחלט אינו אופציה).
 * סביר להניח שהקהילות ישתפו פעולה בצורה היעילה ביותר בתהליך בניית עיצוב חדש.

מבחינה טכנית, שיפורי שולחן העבודה דומים לתכונות או פרויקטים קודמים כגון או. The only difference is that this time, there will be more of them. Vector documentation should remain relevant.

אנחנו נשמר את עיצוב הדור הקודם. לא מתוכננת שום הורדה שלו.

מדוע לא להשתמש את שיפורי שולחן העבודה כתכונת בטא בלבד?
תכונות בטא זמינות למשתמשים רשומים בלבד, והשיפורים נועדו לשרת גם את הקוראים שלנו ואת המשתמשים הלא רשומים שלנו. לפיכך, שימוש בתכונות בטא בלבד היה נותן לנו משוב מסוג מסויים של משתמשים, שיכול להיות מאוד שהוא לא ייצג את כל בסיס המשתמשים שלנו. בנוסף, אנו מעוניינים לקבל את המשוב של הקוראים והמשתמשים האנונימיים מההיערכות המוקדמת ביותר.

מהם מדדי ההצלחה של השיפורים האלו?
הגדלת השירות בין הקהלים הקיימים שלנו על ידי:


 * אינטראקציות:
 * הגדלת החיפושים לכל מפגש בכ-5% במהלך הפרוייקט.
 * הגדלת החלפות השפה בכ-5% במהלך הפרוייקט.


 * זיקה:
 * עלייה ברגשות חיוביים והסברת הפנים כלפי האתר (באמצעות סקרים ובדיקות משתמשים).
 * עלייה בסנטימיות של אמון ואמינות (נמדדת באמצעות סקרים ובדיקות משתמשים).

ככל שאנו מגדירים את השינויים שברצוננו לבצע כיותר ספציפיות, אנו נרחיב ונתחבר דווקא ברשימה הזו.