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

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

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

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


 * 
 * 


 * he:
 * fa:


 * eu:
 * fr:


 * Office Wiki

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

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

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

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

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

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

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

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

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

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


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


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

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

Why is the width of the content limited?  Why is there so much white space?
There are two reasons why we believe a layout with a max-width constraint will be beneficial to readers and editors:

Readability
The Wikipedia page on Line Length provides a good overview, as does the essay Size Matters: Balancing Line Length And Font Size In Responsive Web Design by Professor Laura Franz. The research study Computer text line lengths affect reading and learning by By Peter Orton, Ph.D. IBM Center for Advanced Learning is a more rigorous, academic study. The popular recommendation is that there should be between 40 and 75 characters per line. The findings of multiple studies conclude that "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".

In short, a maximum width allows for better readability, less eyes strain, and better retention of the information itself.

That said, we recognize that much of the content on our projects is meant to be scannable and we wanted to optimize for both scenarios and thus we landed a bit above the recommendation. We settled on an absolute width of 700pixes, which gives us between 59 and 109 characters per line.

Establishing a common reading experience
The second reason we think introducing a max-width could be beneficial to the reading experience is because it would work towards establishing a common experience for readers and editors. This should allow editors when making decisions about page layouts. The width the editor sees is the one the reader will see eventually. 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 fixed-width, for people with narrower screens), however we would be greatly limiting the range of variation.

For more details on our rationale and the process through which we selected the exact width, please go to the limiting content width project page.