בתשובה לאסף רומנו, 11/04/10 21:02
 |
|
 |
||
|
||||
 |
about:config וה־registry של חלונות אינם ממשקי שורת פקודה. אחת התוצאות של נסיונות "לפשט את הממשק" יכולה להיות החבאה של אפשרויות התצורה במקומות פחות נוחים. |
 |
 |
 |
|
|
|
||
|
||||
|
לפעמים עצם קיומן של אפשרויות התצורה מהווה בעיה, וזה לא משנה איזה ממשק אתה נותן להם. לפעמים עדיף לתת פחות אפשרויות ולהתמקד בחשובות. למרבה הצער הגישה הזאת לא ננקטת ברוב המקרים בפרויקטים של קוד פתוח. |
|
|
|
|
|
|
||
|
||||
|
תוכל לתת דוגמה למשפט הראשון? | |
|
|
|
|
|
||
|
||||
|
חצי מהאפשרויות ב"לוח הבקרה" של חלונות? | |
|
|
|
|
|
||
|
||||
|
מה הבעיה? | |
|
|
|
|
|
||
|
||||
|
הבעיה היא שמשתמשים לא מתוחכמים - או הילדים בני ה 12 שלהם - עושים שם סמטוכה נוראית, ואחרי שהמחשב שלהם מגהק בהתאם הם פונים לתמיכה הטכנית, מעמיסים את הקוים, מטרידים את המסייעים במשימות מורכבות וגם מתלוננים על כל צעד ושעל שהמוצר לא טוב, שהשרות גרוע, שהחברה מסריחה וכד'. בכך הם מרחיקים רוכשים פוטנציאליים וגורמים נזק לחברה. | |
|
|
|
|
|
||
|
||||
|
אז למה "לא משנה איזה ממשק אתה נותן להם"? אם הממשק לא יהיה כזה שמשתמש פשוט יודע איך להגיע אליו בכלל, הבעיה נפתרה. כמה משתמשי קצה יודעים על קיומו של about:config בפיירפוקס? | |
|
|
|
|
|
||
|
||||
|
מי שיחפש firefox בגוגל - וזה לא נדיר, יגיע, למשל לפתיל הזה וילמד על קיומו של אותו קונפיג מסתורי. הסיכוי שהוא יטרח לספר על זה לסיוע הטכני (כדי שיוכלו להגיד לו להחזיר את ברירות המחדל לפני המשך הטיפול) לא גדול, בפרט אם מישהו אחר מבני ביתו עשה את הניסויים האלה. טוב, FF הוא לא דוגמא טובה כי ממילא אין למי לפנות בטענות, אז הצב "לוח הבקרה של windows" במקומו. | |
|
|
|
|
|
||
|
||||
|
אי אפשר לרקוד על שתי החתונות - גם להתייחס למשתמש הקצה כאידיוט גמור, וגם להניח שהוא יחפש פיירפוקס בגוגל, יגיע לפתיל הזה, ומקריאתו יגיע למסקנה שצריך לכתוב about:config במקום שבו צריך לכתוב אותו ולהתחיל להשתולל. אני מקבל את הרושם שאתה (לפחות בעברך) תומך טכני מנוסה...? |
|
|
|
|
|
|
||
|
||||
|
וגם ילחץ על "I'll be careful, I promise" לאחר מכן... | |
|
|
|
|
|
||
|
||||
|
ראשת, לא צריך להיות אידיוט גמור כדי לחרבש משהו בקבצי קונפיגורציה. שנית, גם אידיוטים גמורים כבר שמעו על גוגל. מאחר ו"about:blank" מופיע לעתים מזומנות בדפדפן נפוץ למדי, השאלה איפה לתקתק about:config לא כל-כך קשה. מעולם לא הוגדרתי כ"תומך טכני" אבל יש לי נסיון לא מבוטל בתמיכה במשתמשי קצה. |
|
|
|
|
|
|
||
|
||||
|
אוקיי. בכמה אנשים שחירבשו לעצמם את ה-about:config נתקלת? | |
|
|
|
|
|
||
|
||||
|
אף אחד, אבל מעולם לא נתתי תמיכה טכנית למוצר הזה (ומשתמשי FF שאני מכיר הם ממש לא הדיוטות). | |
|
|
|
|
|
||
|
||||
|
אז אני מעז לטעון טענה נועזת: התרחיש הבדיוני שלך על אותו משתמש קצה הדיוט שבכל זאת מתעלל לעצמו ב-about:config, ועוד אחרי שגיגול הביא אותו לאייל (?) לא קשור למציאות (גם אם מורידים את הקטע עם הגיגול לאייל). | |
|
|
|
|
|
||
|
||||
|
אולי. אני מניח שרק מי שנותן תמיכה טכנית למשתמשי FF יוכל להכריע. | |
|
|
|
|
|
||
|
||||
|
נתתי תמיכה טכנית למשתמשי Firefox. זה היה נדיר כשלעצמו, כי בדרך כלל מי שמתקשר לתמיכה לא מודע בכלל לאפשרות לעבוד עם דפדפן חלופי, מבין האנשים שבכל זאת עבדו עם FF אני לא יודע אם מישהו התעסק עם הגדרות מתקדמות מהסוג הזה, לפני שמתחילים לחפש שם פשוט מתקינים מחדש את התוכנה. | |
|
|
|
|
|
||
|
||||
|
"FF הוא לא דוגמא טובה כי ממילא אין למי לפנות בטענות," מה? |
|
|
|
|
|
|
||
|
||||
|
מה מה? מי שמפתח ומתחזק את FF לא חייב לי כלום כי לא שילמתי לו פרוטה. מי שמכר לי windows כן חייב לי משהו. | |
|
|
|
|
|
||
|
||||
|
אז אתה זה שקנה את windows? שמעתי שמועות על קיומך אבל הייתי בטוח שמדובר באגדה אורבנית... | |
|
|
|
|
|
||
|
||||
|
מתי לאחרונה קיבלת תמיכה? למעשה, התרחיש של תגובה 540178 יכול להתרחש באותה מידה עם התמיכה הטכנית של ספק החיבור לאינטרנט. זה גם נשמע יותר סביר. |
|
|
|
|
|
|
||
|
||||
|
את Firefox מייצרת חברה מסחרית (Mozilla Corp). אולי היא לא חייבת לך כלום (יבוא יום ואקרא את ה-EULA), אבל יש למי לבוא בטענות. | |
|
|
|
|
|
||
|
||||
|
וכל מי שרוצה יכול למכור תמיכה ל־Firefox . או למכור את Firefox כחלק מהמוצר שלו. זה היה פחות או יותר המצב בשני המחשבים האחרונים שקניתי. | |
|
|
|
|
|
||
|
||||
|
אם אתה קונה תמיכה, כמובן יש לך למי לבוא בטענות. רוב משתמשי FF שאני מכיר פשוט הורידו אותו מהרשת, כמוני. | |
|
|
|
|
|
||
|
||||
|
לא קניתי תמיכה. קניתי מוצר. FF (בשם אחר) היה חלק ממנו. | |
|
|
|
|
|
||
|
||||
|
הבעיה היא שככל שיש יותר אפשרויות כך קשה יותר למצוא את האפשרות שאתה מחפש. כל אפשרות תצורה שאתה מוסיף גורעת מהיכולת למצוא ולהבין את אפשרויות התצורה האחרות. סתם בתור דוגמה: נניח שיש לך תוכנה המציגה רשימה של פריטים. סביר לצפות שתוכל לשלוט באופן הסידור של הפריטים (אלפבתי, הפוך, לפי תאריך, לפי גודל וכו), אולי סביר גם שתוכל לשלוט בגודל האות או בסידור העמודות אבל פחות סביר שתוכל לשלוט באלגוריתם המיון של הרשימה. אפשרות השליטה הזאת היא אולי שימושית למגזר מסויים של משתמשים והוספתה לא פוגמת ביעילות התוכנה או מוסיפה באופן משמעותי אפשרויות לבאגים אבל הממשק הנוסף הדרוש לשליטה באפשרות גורע מהנראות של פריטי הממשק האחרים שנחוצים כדי לשלוט בתכונות היותר חשובות. |
|
|
|
|
|
|
||
|
||||
|
זה רק במקרה שעיצוב הממשק הוא גרוע. באופן כללי נהוג לשים במקום בולט וברור את האפשרויות החשובות ביותר, ואת היתר להסדיר מאחורי הקלעים בקובץ קונפיגורציה או משהו בסגנון about:config, שבו ממילא לא צריך לחפש אחר כפתור ספציפי ללחוץ עליו (ב-about:config ספציפית משתמשים בפילטר). | |
|
|
|
|
|
||
|
||||
|
מה שגדי אמר. מספיק לשים אפשרות כזאת בלשונית שנייה תחת הכותרת "Advanced", ואולי לזרוק איזה popup בסגנון של "אלו אפשרויות מתקדמות שיכולות לפוצץ את התוכנה שלך ואת היקום, הן מיועדות רק למשתמשים שיודעים מה הם עושים". | |
|
|
|
|
|
||
|
||||
|
האם זה לא קצת אירוני שאתה פותר בעיה של עודף פריטי ממשק באמצעות עוד פריטי ממשק? כשאני נותן תמיכה לאנשים אני תמיד אומר להם לא לפחד מכל האפשרויות שהם לא מבינים, אם אתם לא צריכים את הפונקציונליות, אל תשתמשו (וכשתצטרכו, סביר שהפונקציה תהיה יותר מובנת). בעיני זו עצה פרקטית טובה להתמודדות עם המצב הנתון אבל בפועל, ריבוי פונקציות בלתי מובנות, גם אם הם מוסתרות באמצעות עוד ממשק או אם כתוב עליהם "לא לגעת" עדיין נותנות למשתמשים הרגשה רעה ומקשות על השימוש בתוכנה. איך היית מרגיש אילו היית נכנס למכונית עם כפתורים כמו קוקפיט של 747 והיו אומרים לך: "כן, תשמש רק בהגה ובגז", יכול להיות שתצליח לנהוג במכונית אבל הנהיגה תהיה מלווה כל הזמן בתחושה של חוסר שליטה ופחד פן תלחץ בטעות על איזה כפתור לא נכון או שמשהו יתחיל לצעוק ולא תדע מה לעשות. התווית "מתקדם" נותנת למשתמש תחושה של מי שלא חבר במועדון, שהוא טיפש, שאין לו באמת שליטה בתוכנה. יש גם הרבה משתמשים שלא מצליחים להפנים את הרעיון שהם יכולים להתעלם מתכונות מסויימות של התוכנה וקיומן של תכונות שהם אינם מבינים מטריד אותם. |
|
|
|
|
|
|
||
|
||||
|
צריך לעשות סקר ולבדוק כמה משתמשי קצה בכלל יודעים על קיומו לש about:config (וכמה נעלבים בשל כך). | |
|
|
|
|
|
||
|
||||
|
דוקא עריכה של prefs.js נראית לי יותר מבטיחה (בסגנון dot emacs). אפשר לכתוב שם קוד, וגם יותר נוח להעתקה. | |
|
|
|
|
|
||
|
||||
|
וכמובן - את ההתאמות האישיות עדיף לשמור תחת user.js | |
|
|
|
|
|
||
|
||||
|
אני "נעלב" ממעצבי-ממשק שמתעלמים לחלוטין מהדירשות של משתמשים מתקדמים - איננו מיעוט נכחד כפי שמשתמע ממקצת ההודעות בדיון הזה. ואולם את זה גם אפל מבינה בשנים האחרונות. שאם לא כן, איך אפשר להסביר את הימצאו של "דיסק כלי פיתוח" בערכת הההתקנה של OS X. אגב, עם "כלי הפיתוח" האלו נמנה Property List Editor. כמו about:config, תכליתו העיקרית היא שינוי הגדרות שאין להן ייצוג בממשק הרגיל. על משתמשים שנעלבו מהדיסק הנוסף או מהכלי המתקדם, שאינו כלי פיתוח של ממש, טרם שמעתי. |
|
|
|
|
|
|
||
|
||||
|
אני יודע, גם על גריזמונקי, ואני די מתוסכל מכך שאין לי דרך נוחה לגישה/הבנה/התקנה של "דברים". כהדיוט שלומד לבד להפעיל את המחשב אני מרגיש שיש כאן שתי רמות, למפגרים וליודעי סוד. חסר לי בממשק המחשב שלב הביניים "למפגר המתקדם". |
|
|
|
|
|
|
||
|
||||
|
נסה את מנהל התוספים (Tools->Addons). בגרסאות הארחונות הוא מאפשר גם חיפוש במאגר של מוזילה מבלי שתצטרך לנבור מחוץ לממשק הדפדפן. | |
|
|
|
|
|
||
|
||||
|
גריזמונקי הוא בעל פוטנציאל נזק גדול: מאפשר לך בקלות להריץ קוד של אנשים אחרים. דוגמה פשוטה לנזק שיכול להגרם: תיקון פשוט של טופס ההזדהות באייל, שישלח את את פרטי ההזדהות ל־http://dubikan.com/cgi-bin/ayal-proxy.cgi (אשר יעביר אותם לאחר מכן חזרה לשרת של האייל). ההזדהות תעבוד כצפוי, אולם מישהו יקבל עותקים של כל הסיסמאות. |
|
|
|
|
|
|
||
|
||||
|
''המפגר המתקדם'' בעיקר גורם לעצמו נזק וצריך לשחק בארגז חול. לא כל כך קשה להפסיק להיות מפגרים אם רק רוצים ומוכנים ללמוד. | |
|
|
|
|
|
||
|
||||
|
בהיותו מפגר ''מתקדם'' אינו גורם נזק כי אינו עושה כשאינו מבין. אבל נשאר מתוסכל. בענין הרוצה ומוכן, הייתי מעדיף שהמכונה תתן לי עמוד אפשרויות מפורט אותו אלמד ביום מאשר מאות מאמרי ארכיון ב''כלכליסט מחשבים'' (ותודה מקרב לב לצוות הכותבים). |
|
|
|
|
|
|
||
|
||||
|
אינו עושה כשהוא מבין שאינו מבין, ועושה כשאינו מבין שאינו מבין, ולכן חושב שמבין. | |
|
|
|
|
|
||
|
||||
|
זו כבר בעיה כלל אנושית. | |
|
|
|
|
|
||
|
||||
|
ubiquity נותן פתרון לא רע לשוא"ש. אפשרויות תיכנות, אבל במעיין סקריפט מאוד פשוט כשהבסיס הרבה פעמים כבר כתוב ורק צריך לעבור התאמה לצרכים שלך. |
|
|
|
|
|
|
||
|
||||
|
אתה מתעקש לא להבין את מה שנכתב ולהתדיין עם איש קש. אתה לא באמת צריך אותי פה. | |
|
|
|
|
|
||
|
||||
|
בסגנון הזה אף אחד לא באמת צריך אותך פה. | |
|
|
|
|
|
||
|
||||
|
הסגנון הזה מבזבז הרבה פחות זמן לשאר הקוראים ומכעיס הרבה פחות את שאר המגיבים מאשר דיון מעגלי אינסופי של דמגוגיה ואנשי קש. | |
|
|
|
|
|
||
|
||||
|
אתה יכול לחשוב שאין משתמשים כמו שתיארתי אבל זה הנסיון שלי וזו זווית הראיה שלי על העולם. אתה לא חייב להגיב, ובטח לא בגסות כזאת. | |
|
|
|
|
|
||
|
||||
|
הבעיה שלי היא לא עם תפיסת העולם שלך או הניסיון שלך, אני דווקא מבין את העמדה שלך מצוין. הבעיה שלי נעוצה בקשר שבין תוכן ההודעה שלי לתוכן התגובה שלך - או יותר נכון לחוסר הקשר בינהן. אתה מוזמן לקרוא את התגובות שלי שוב ולשאול את עצמך אם אתה עונה לי או לעצמך. אני חושב שהגזמנו קצת פה עם כל עניין ה"גסות". בסה"כ הודעתי לך שמבחינתי התגובה שלך לוקה בדחליל_(כשל_לוגי) [ויקיפדיה], ופעם השנייה שזה קרה הודעתי לך שאני פורש מהדיון. אם מישהו היה מפנה כלפי את התגובה שלי הייתי מקבל אותה בחיוך, מבין את הרמז, וקורא מחדש את ההודעות האחרונות בפתיל. אותי באופן אישי דווקא מכעיס הרבה יותר מצב שבו הצד השני לא מתדיין איתי אלא עם איש קש שהיא יצר מהתגובה שלי. |
|
|
|
|
|
|
||
|
||||
|
אני מבחינתי התייחסתי ברצינות ובכבוד להודעה שלך. וקיוויתי ליחס דומה. | |
|
|
|
|
|
||
|
||||
|
אני שוב מתקשה למצוא קשר בין התגובה הזו לתגובה שלי שאליה היא מופנית... בוא נעצור כאן. | |
|
|
|
|
|
||
|
||||
|
אני משתמש במכשיר האייפון כמעט מהיום שיצא. מבחינתי, כממשתמש - בין אם זה בטלפון או במחשב, רוב הממשקים לא נעשו להדיוטות אלא לאנשים שמבינים/ בעלי רקע טכנולוגי כלשהוא. זו לדעתי טעות גדולה בהבנת מיהו המשתמש. דוגמא קטנה - בזמנו יצאה תוכנה (לא חוקית) שאיפשרה ליצור באייפון ספריות אפליקציות. הרעיון היה שניתן יהיה לצמצם את כמות האפליקציות בדפים ולרכזן לפי נושאים/ קטגוריות שניתנות להגדרה עצמית. הורדתי בשמחה כי חשבתי שזה יקל על החיים. אבל אחרי שלושה ימים בלבד הבנתי כי מה שלכאורה נראה טריוויאלי כומ בכל מחשב, יצר חיסרון גדול מבחינת חווית המשתמש שלי. הרי שלא זכרתי אלו אפליצקיות יש לי - ולפחות כמה עשרות היו מותקנות. גם לא זכרתי היכן קיטלגתי כל אחת. אתה מוצא את עצמך נובר בספריות לחפש אפליקציה שקודם הייתה פשוט מול עינך. הנקודה שלי היא שיש אנשים רבים, ואני בינהם, שמשתמשים בחשב באופן יומ-יומי - כל היום, אך הם אינם טכניים, ולהם חווית הפשטות חשבוה מאד. מי שניסה פעם להתקין ראוטר אלחוטי לבד בוודאי מבין את הבעיה. |
|
|
|
|
|
|
||
|
||||
|
זה שיש עודף אפליקציות זה מכיוון שלמשכתנת מן השורה קשה מדי לתרום קוד לענף הראשי. | |
|
|
|
|
|
||
|
||||
|
"אפשרות השליטה הזאת... [אולי לא] מוסיפה באופן משמעותי אפשרויות לבאגים" זו נקודה שנרמזה פה ושם בדיון הזה, אבל לא הודגשה מספיק לטעמי: אני לא רואה איך אפשר להוסיף אפשרויות שליטה בלי להוסיף משמעותית, כמעט אקספוננציאלית, אפשרויות לבאגים. או לייקר משמעותית את המוצר בגלל עלויות מאמירות אקספוננציאלית של אבטחת איכות. או כל תערובת מקובלת של השניים. אפשר ליישב את זה עם המודל של אלו שרוצים אפשרויות מתקדמות חצי-נסתרות: להכריז גם שהאפשרויות האלו פחות נבדקו, והיצרן פחות לוקח עליהן אחריות. זה יכול אולי לעבוד במוצרי קוד פתוח, שבהם המשתמשים באפשרויות המתקדמות הם גם בדיוק אלו שיכולים לתקן את הבאגים בהן. במוצרים מסחריים של קוד סגור אני מניח שזה מעשית יהרוג את האפשרויות המתקדמות. אם אני צודק עד כאן, אני בהחלט מבין את ההחלטה פשוט לחסום את מה שבסוף יביא רק כאב לב לכולם. |
|
|
|
|
|
|
||
|
||||
|
עושים את זה כשלתוכנה יש משתמשים. כמו שהזכירו קודם, גם לאפל יש משהו דומה. | |
|
|
|
|
|
||
|
||||
|
כשלקוח משלם רוצה משהו, לקוח משלם יקבל את זה. לכן החלופה ל''הגדרות מתקדמות'' היא לבנות גרסה שונה עבור אותו לקוח משלם. זה מייקר בהרבה את עלות הבדיקה - אתה מגיע למספר אקספוננציאלי של גרסאות שונות. |
|
|
|
|
|
|
||
|
||||
|
בסדר, אבל הפתיל דיבר על מוצר מדף (של אפל), כשאתה צריך להחליט מה לאפשר ומה לא, להשקיע את הכסף, ואז להציע את זה ללקוחות. | |
|
|
|
|
|
||
|
||||
|
"אפשר ליישב את זה עם המודל של אלו שרוצים אפשרויות מתקדמות חצי-נסתרות: להכריז גם שהאפשרויות האלו פחות נבדקו, והיצרן פחות לוקח עליהן אחריות. זה יכול אולי לעבוד במוצרי קוד פתוח, שבהם המשתמשים באפשרויות המתקדמות הם גם בדיוק אלו שיכולים לתקן את הבאגים בהן. במוצרים מסחריים של קוד סגור אני מניח שזה מעשית יהרוג את האפשרויות המתקדמות. אם אני צודק עד כאן, אני בהחלט מבין את ההחלטה פשוט לחסום את מה שבסוף יביא רק כאב לב לכולם." ראשית, רוב "המשתמשים המתקדמים" אינם מפתחים. שנית, הצרכנים הראשונים של האפשרויות המתקדמות הם המפתחים עצמם. וכך, גם אם הן מצויות בתחתית סדר העדיפויות של הבלבתים, הן זוכות לדי תשומת לב מהמפתחים כדי שהן יהיו שמישות ושימושיות - אם כי לא בהכרח מהוקצעות כמו האפשרויות הגלויות. |
|
|
|
|
|
|
||
|
||||
|
דברי כוונו בעיקר לאופציות של העדפות ("קינפוגים") ולא ליכולות מתקדמות של התוכנה. אולי זה המקור לאי ההבנה שנוצרה כאן. במקרה של העדפות אני חושב שברוב המקרים אין תוספת משמעותית לבאגים מלבד אלו הנוגעים לקוד של ממשק ההעדפה עצמו. זו שאלה של כמה החלטות אתה נותן למשתמש להחליט בנוגע למהלך ביצוע הקוד. בנוגע ליכולות מתקדמות. בעצם לא ברור לי במה הם נבדלות מתכונות רגילות. אני יכול לחשוב על שימוש הגיוני בprogressive disclosure במקרים מסויימים כאשר אפשר לבצע בחירה כללית ופשוטה בממשק מסוג מסויים עם אופציה לממשק אחר מורכב יותר לבחירה יותר ספציפית. למשל, בורר צבעים בתוכנה דמויית פוטושופ שמאפשר לבחור צבעים מתוך פלטה מצומצמת בממשקה "החיצוני" וכאפשר לוחצים על כפתור מוצג חלון עם אפשריות RGB או HSB. אבל פה אנחנו מדברים יותר על סוג של קיצור דרך. ------ אני מתנצל מראש בפני כל הרואים בהודעתי מקום משכן לאנשי קש ודמגוגיה זולה. |
|
|
|
|
|
|
||
|
||||
|
אלינ''ב, אבל להבנתי הודעתו התייחסה (גם) לכך. ברגע שיש יותר אפשרויות, יש יותר מקרים לבדוק. | |
|
|
|
|
|
||
|
||||
|
לי נדמה מה שצפריר אמר, אבל אולי יעזור אם תביא דוגמה (לאפשרות נוספת שאתה נותן למשתמש, שאינה מגדילה בהרבה את הסיכון לבאגים). | |
|
|
|
|
|
||
|
||||
|
בעקרון ברור שצפריר צודק. כל אפשרות שאתה מוסיף היא אפשרות לבאגים אבל יש אפשרויות בהן התוספת זניחה, אתה יכול לתת למשתמש לבחור פונט, גודל, צבע וכו. (מאחר ואתה משתמש בפונטים וגדלים וצבעים ממילא תוספת הסיכון נמוכה). אתה יכול לתת למשתמש לשלוט בפרמטרים שונים המזינים את האלגוריתמים של התוכנה. אפל למשל נתנה שליטה בשיטת הAnti Aliasing של טקסט במשך כמה שנים, אני לא בטוח אם זה אכן המצב אבל אפשר לדמיין שאופציה כזאת שולטת בפרמטר מסויים המוזן לתוך האלגוריתם של הרסטרייזר. (אפל הסירו את האפשרות הזאת לאחרונה ואני חושב שזו דוגמה מצויינת לרמת המחוייבות שלהם להקטנת מספר האפשרויות כעקרון של תכנון ממשק). | |
|
|
|
|
|
||
|
||||
|
אתה לא ממילא מתשמש בפונטים וגדלים וצבעים, אתה ממילא משתמש בפונט, גודל וצבע - אחד מכל אחד. יכול להיות שלאפשר המון מכל אחד לא משנה הרבה, אם אין להם אינטראקציה עם מאפיינים אחרים. אבל מחר תרצה להוסיף מאפיינים שכן יש להם אינטראקציה: נניח, שימוש בצבע שני כדי להבחין בין דברים (מצד התוכנה). עכשיו פתאום בחירות צבע מסוימות של המשתמש, או עצם היכולת לבחור, מסבכים אותך. תאמר, כשנגיע אל הגשר הזה נשרוף אותו, כלומר נבטל את האפשרות של המשתמש לבחור צבע. לאניני הצבע לא תהיה הצדקה לכעוס על הרעת התנאים, שהרי ממילא הגדרנו את האפשרות הזאת תחת דיסקליימרים. השאלה היא איך בכלל תדע - היכולת לחשוב על כל האינטראקציות האפשריות של מאפיין חדש עם כל האפשרויות המתקדמות היא מוגבלת. |
|
|
|
|
|
|
||
|
||||
|
אתה עיוור (צבעים) למציאות. | |
|
|
|
|
|
||
|
||||
|
אשמח אם תאיר את עיניי (בצבעים עליזים). | |
|
|
|
|
|
||
|
||||
|
עוורון צבעים גורם לכך שהצבעים (וצירופיהם השונים) אכן חשובים ולא בהכרח מתאימים לכולם. | |
|
|
|
|
|
||
|
||||
|
1. עיוורון צבעים לאדום-ירוק הוא נפוץ מאוד, ואני בעד שיהיה תקן לצבעים באפליקציות שיתחשב בכך, ולא יצריך כוונון מצד המשתמש. בהיעדר תקן, סתם מודעות של מפתחים גם תעזור. (לצערי, תחום אחד שאני עוסק בו התרגל בדיוק לבחירה האומללה בשני הצבעים האלו להבחנה הקריטית - כנראה בעקבות אותה בחירה אומללה מצד מי שעשו את הרמזורים הראשונים.) עיוורון צבעים אחר הוא כל כך נדיר, שאני חושב שעבור הלוקים בו עדיף לתפור "מטא-פתרונות" שעובדים מעל כל האפליקציות ואינם תלויים בהן (כמו מגדילי מסך ללקויי ראייה קיצוניים). 2. תאמר, אם לא בחירת צבעים אז יש עניינים אחרים שבהם אפשרות בחירה למשתמש היא מועילה מאין כמוה. בהחלט סביר, ואני לא שולל מתן אפשרות בחירה, כולל של צבעים - רק לדעת שיש לכך מחיר בלתי-נמנע, בתחום הבאגים ומחיר מניעתם. |
|
|
|
|
|
|
||
|
||||
|
כעיוור צבעים אני יכול להעיד שלי (ולמיטב ידיעתי לחלק נכבד, אם לא רוב, החולקים עמי את הלקות האמורה) אין בעיה להבדיל בין ירוק של כן לאדום של לא, ובכלל אין לי בעיה של זיהוי צבעים. הבעיה היא של קונטרסטים, ומכאן של אבחנה בצבעים. גוון מסוים של אדום, לשם דוגמא, כאשר הוא בא על רקע של גוון מסוים של ירוק, מבחינתי הוא מסתווה בו, בעוד שלרוב האוכלוסיה הוא צועק. לעומת זאת גוון מסוים של ירוק על רקע גוון אחר של ירוק, אשר לכלל האוכלוסיה מהווה הסוואה מושלמת, בשבילי זהו ניגוד צועק. | |
|
|
|
|
|
||
|
||||
|
מה עם כל אלו שקנו כלי סבון ירקרק, ונדהמו כשאמרו להם בבית שזה אדמדם? שמעתי במו אוזני סיפורים כאלה משני עיוורי צבעים שונים (אחד מהם ייסד איזה אתר אינטרנט, לא משנה). | |
|
|
|
|
|
||
|
||||
|
יש כאלה, יש גם כאלה שרואים שחור-לבן, אבל הרשה לי להפנות אותך אל השורה המצוטטת ביותר באתרי ההכרויות (ומכיוון שרחל המשוררת נחה על משכבה בשלום כבר למעלה מ 70 שנה, אין כאן אפילו רמז לפגיעה בזכויות יוצרים). | |
|
|
|
|
|
||
|
||||
|
מילא סבון, תאר לך שזה קורה עם מכונית! תגובה 282773 (למען האמת, ירוק וכחול זה פחות מרשים) |
|
|
|
|
|
|
||
|
||||
|
ירוק וכחול זה לא סתם "פחות מרשים", זה לפעמים סתם עניין של הגדרה, במיוחד כאשר שמות הצבעים כוללים מבחר מצומצם ואינם כוללים שמות כמו "טורקיז", "כחול פלדה" או "ירוק פטרול". נניח שאתה שולח למדפסת (שפועלת GRY, להבדיל מהמסך שפועל RGB) את הצרוף G 255, R 0, Y 0 אין ספק שתקבל הדפסה של ירוק. אם תשלח למדפסת את הצרוף G 255, R 0, Y 255 אין ספק שתקבל כחול. אתה מוזמן להעלות את ערך הצהוב בין 0 ל 255 (לא בהכרח במדרגה של 1, גם של במדרגות של 8 פרדוקס הערמה יעבוד) ולהחליט היכן עובר הגבול בין כחול לירוק. |
|
|
|
|
|
|
||
|
||||
|
במדפסות (בדרך כלל) משתמשים ב CMYK, או CMY בשעת הדחק, אף פעם לא ב RGB (לא מתאימים כבסיס לחיסור צבעים). כחול ב CMYK זה 100,100,0,0 (באחוזים, סולם רציף, לא 8 ביט), ירוק זה 100,0,100,0 סתם לידע כללי... |
|
|
|
| חזרה לעמוד הראשי |  |
| מערכת האייל הקורא אינה אחראית לתוכן תגובות שנכתבו בידי קוראים | |
 RSS מאמרים |
כתבו למערכת |
אודות האתר |
טרם התעדכנת |
ארכיון |
חיפוש |
עזרה |
תנאי שימוש
|
© כל הזכויות שמורות |