שינוי שבירה חזותית במערכות עיצוב

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

מספר 4 מתוך 6 מהסדרה מערכות עיצוב משחררות:
תפוקות | קדנס | גרסאות | שוברים | תלות | תהליך

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

אז, שאלו את עצמכם ...

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

גרסאות סמנטיות (SemVer) מציעות קריטריונים ברורים להעברת שינויים בין גרסאות באמצעות ייעודים גדולים, מינוריים ותיקונים. כל מערכת עיצוב שאני נתקל בה משתמשת ב- SemVer ובמעקב אחר שינוי בממשק תכנות היישומים של החבילה שלהם, או API. זוהי טריטוריה מוכרת למפתחים המקודדים אבזרי JavaScript וסימון HTML. שבר את ה- API שלך, והגרסה הבאה שלך חייבת להגדיל את הגירסה למהדורה הבאה הבאה, כגון 1.4.0 ל- 2.0.0.

ציון ממשק לסגנון חזותי קומפוזיציוני מחמק אותנו. זה מרגיש כל כך קשה להגדיר כללים פשוטים ופשוטים למעקב אחר שינויים בסגנון. יצרני מערכות נאבקים כדי לבטא מה ומדוע "שינוי סגנון זה שובר את ממשק המשתמש של המאמץ" לעומת "שינוי סגנון זה אינו." מעט צוותי מערכת מתעדים קריטריונים כאלה. אני שואל "אילו סוגים ספציפיים של שינויים חזותיים מפעילים גרסה מרכזית עבורך?" תגובתם: ¯ \ _ (ツ) _ / ¯.

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

שובר צבע

רוב צוותי המערכת מרגישים בטוחים בכוונון צבע הרקע של כפתור ראשי. אולי המוטיבציה שלהם היא לשפר את הניגודיות מול תווית טקסט לבן בדרך כלל. "בואו נחשיך מעט את התה," הם אומרים. "נשפר את ניגודיות הצבעים הנגישים של הכפתור מדירוג AA ל- AAA."

התאמת צבע רקע של כפתור ראשי

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

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

דוגמה: טקסט מערכת על רקע מותאם אישית

דמיין שצוות מערכת מכוון את הכחול האינטראקטיבי בכדי לשפר את הניגודיות בצבעים. הכחול האינטראקטיבי של v1.4.0 היה נגיש על רקע לבן אך נכשל על רקע הפחם.

בדיקת ניגודיות צבעונית באמצעות contrast-grid.eightshapes.com

אז, עבור v1.5.0, הצוות התאים את הכחול האינטראקטיבי לטון קל ורווי יותר שעבד גם על לבן וגם על פחם.

התאמת צבע טקסט של תווית כפתור רפאים על רקע בלתי צפוי

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

דוגמה: רקעי מערכת עם טקסט מכוסה מותאם אישית

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

התאמת צבע רקע של כרטיס המאפשר תוכן מותאם אישית הכלול

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

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

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

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

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

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

שובר טיפוגרפיה (עטיפה)

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

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

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

דוגמה: כרטיסיות עטיפה הן נוראיות

תאר לעצמך שהמערכת שלך מתאימה את משקל הלייבלונט מהרגיל למודגש.

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

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

דוגמה: Mayhem ריווח אותיות

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

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

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

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

שובר שטח וגודל

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

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

דוגמה 1: הסרת ריווח אנכי

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

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

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

דוגמא 2: גודל בהתאמה אישית בהתבסס על ריווח משוער

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

סרגל כלים של אייקון מותאם אישית עוטף לאחר שינוי ריפוד. Ewww.

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

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

שינוי מרחבי לא כלול

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

מה עוד יכול לשבור סגנון חזותי?

באופן כללי ניתן לציין שינויים בסגנון הוויזואלי כשינויים בשפע של מאפייני CSS, שטווחיהם מודגמים על ידי קולקציות אסימון עיצוביות ב- Salesforce Lightning, Morningstar, REI ו- Open Table.

אילו תכונות אחרות יכולת לפקח מעבר לתכונות של צבע, טיפוגרפיה, שטח וגודל שתוארו לעיל? אינדקס z המיושם על רכיבים כמו Popovers, Dialogs, Modals, and Tooltips הוא מרכזי בהרכב בממד השלישי, בשכבות של הפריסה. אטימות המיושמת באופן נרחב על שכבות שקופות למחצה (כמו תחת מודל) נראית גם כמועמדת חזקה. אפילו לשינויים עדינים כמו גבול התחתון יש השפעה.

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

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

Takeaway: סקור את האוסף העצום של נכסי CSS האפשריים ושוחח עם הצוות שלך על ההשלכות של נכסי מועמד. סשן עבודה יגלה באופן פורה את הסובלנות של הקבוצה להגנה על מאמצים וייסע לתיעוד כמה רחוק תגיע.

אז מה זה שינוי חזותי?

בשלב זה אתה חושב: האם זה באמת משנה? האם לא עלינו להשתמש במערכת שלנו כדי לשלוט בשפה הוויזואלית שלנו? האם לאומצים באמת יהיה אכפת?

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

בשיחות עם עמיתים למערכת העיצוב, הרגשות הם:

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

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

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

מס '3. גרסאות ← קודם | הבא → # 5. תלות