כשמזכירים את המושג "מחיר הטעות", לעיתים קרובות מדברים על כסף, לעיתים אפילו על חיי אדם, ולעיתים על פעולות בלתי-הפיכות שונות במחשב או בעולם הפיזי. אבל במקרה הנפוץ ביותר, וזה שהכי קל לשכוח ממנו, מחיר הטעות יהיה פשוט תסכול בעקבות פעולה שביצענו. כמו זאת שגרמה לשני המסכים שלי היום להראות ככה:
ואיך זה קרה?
זה קרה בגלל אותו מסך שכבר דיברתי עליו:
בפוסט ההוא הרי למדתי שבפינה השמאלית התחתונה נמצאת תיבת קומבו ואפשר לרשום בה ערכים משלך. לכן, באופן טבעי, לא קראתי או לפחות לא הפנמתי את התווית על התיבה, וכשרציתי לפצל קובץ גדול לשני חלקים, רשמתי בו את הספרה 2. כשראיתי שהמספרים רצים מהר מדי ורחוק מדי, לחצתי על "ביטול", אבל היה מאוחר מדי, והתוכנה כבר הספיקה לייצר לי 700 קבצי RAR בגודל 2 בייט כל אחד. בהקשר הזה עולים כמה דברים:
1. אילו המילה bytes הייתה מופיעה מימין לקומבו, אולי הייתי מבין את זה יותר טוב. רק אולי.
2. כשחושבים על זה, אני מסכים שהרבה יותר הגיוני לפצל קובץ לפי הגודל שלו ולא לפי מספר החלקים. כי אנחנו מפצלים בגלל אילוצים חיצוניים, ואלו הם לרוב אילוצי נפח – בשליחה במייל, בהעלאה לרשת או בצריבה. לכן לא הייתי מוסיף כאן עוד רמת מורכבות שתאפשר לפצל לפי מספר חלקים.
3. רק אם ממש מקדישים לזה מחשבה ומנתחים בקפידה את האופציות בקומבו, אפשר לנחש שניתן לרשום בו לא רק בייטים אלא גם קילובייט ומגהבייט. וגם אז אי אפשר באמת להיות בטוחים בזה, וצריך להחזיק אצבעות ולהתפלל שהקומבו יבין אותך – ואת הצורה שבה בחרת לרשום את יחידות המידה (ברבים או ביחיד? בצורה מלאה או בצורה מקוצרת?). התווית עצמה מאוד מטעה, ואין שום דרך להבין ממנה שלא צריך לספור אפסים ולחשב בראש כמה יוצא 100 מגה בבייטים. יש לחשוף את סוגי יחידות המידה האפשריות. בעיקרון היה אפשר לרשום אותם בדרופדאון נפרד, אבל זה יוסיף רכיבים למסך וגם יהרוס את הקומבו החכם. ולכן, הייתי פותר את זה בצורה כזו:
בדיוק כפי שבאתרים רושמים את סוגי קבצי התמונה שניתן להעלות.
4. תאימות לאחור (backwards compatibility), זה נחמד, אבל בחייכם, דיסקט של 1.44 מגה ("3.5)? מתי פעם אחרונה החזקתם כזה ביד? יש כבר דור שלם של משתמשים, שמסתובבים בפורומים של מתכנתים (לא פורומים של טלטאביז) ושואלים את השאלה "מדוע הכונן הראשון במחשבי ווינדוז מסומן באות C – מה קרה ל-A ול-B?", ואתם שמים לי כאופציה דיסקט של 1.44? ואתם יודעים מה, אני בטוח שאם ישובו החייזרים ונצטרך להעלות לספינת האם שלהם וירוס על-גבי דיסקט כזה, כפי שעשה וויל סמית בסרט התיעודי "יום העצמאות", נוכל להקליד את המספר ביד – הרי בשביל זה יש לנו את הקומבו החכם.
בעקרון, אין הגיון בלהגיד לתוכנת כיווץ לפצל את הקובץ שלך לשני חלקים, כי היא לא תדע מתי לעשות את זה. באמצע? אחרי המגה-בייט הראשון? יותר מכך, היא לא יודעת מראש מה יהיה גודל הקובץ המכווץ.
הבעיה שאת כל זה צריך לשדר למשתמש מראש, והם עשו עבודה חלקית. את המילה bytes אתה פספסת, אבל זה לא רק אשמתך.
התווית "split to volumes, bytes" אמורה לשדר שזה לפי גודל. למרות זאת אני מסכים שההצעה שלך משפרת את המיקום שלה. בנוסף המילה volume כבר לא כ"כ מקובלת בהתייחסות לגודל קבצים, כי אנחנו כבר לא חושבים על מדיה כמגבילה אותנו (הסטדנרט המקובל של DVD הוא 4 גיגה). לכן עדיף לכלול את המילה size במקום.
לגבי ה-size – מסכים לחלוטין.
לגבי הפיצול – מן הסתם שהכוונה לשני חלקים שווים :). זה שהיא לא יודעת מראש את גודל הקובץ המכווץ זה נקודה טובה, שלא חשבתי עליה. מצד שני, אפשר להעריך את זה מראש ברמת דיוק סבירה מאוד (אפילו בני אדם יכולים לעשות את זה טוב לפי פורמט הקובץ – וזה בלי להסתכל פנימה ולנתח מה יש שם באמת). אף אחד לא הולך להתקטנן על הבייט.
הסיבה לזה שאפשר עדיין להשתמש בגודל דיסקט הוא, להערכתי, אתרי "שיתוף" עתיקים שעדיין ממשיכים להעביר קבצי ענק (משום מה) מפוצלים לגודל של דיסקט. אם תבדוק טוב את המקורות של התוכנה שאתה משתמש בה לכיווץ, אני מעריך תגלה שהם לא ב-100%, איך להגיד, kosher
🙂
ובכל זאת, זה ממשק מעצבן.
ברק, זה winrar 3.9 כשר למהדרין 🙂 (אבל לא גלאט – בכל זאת, גרסת ניסיון).
ובלי שום קשר לממשק משתמש – אין איזה הגיון בסיסי מינימאלי שיגיד שלא הגיוני לפצל קובץ לקבצים של 2 בייטים ?
גם אם לא למנוע את זה באופן אוטומאטי – כי אולי מישהו הולך להדפיס את זה על פתקים או משהו מטופש אחר, לפחות ראוי להציג שאלה למשתמש ולהבהיר לו שהוא הולך ליצור כמות לא סבירה בעליל של קבצים…
אייל, דווקא יש לזה קשר ישיר ביותר לממשק המשתמש – ההערה שלך עוסקת בדיוק בו. אתה צודק שדיאלוג כזה היה משפר כאן את המצב, השאלה היחידה היא כיצד לקבוע את הרף שמקפיץ אותו. הייתי מגדיר אותו לא כפונקציה של גודל, אלא של כמות משוערת של הקבצים המכווצים. מאה נראה לי כמו מספר טוב. אולי אפילו שבעים.