עיצוב ממשק משתמש המניב ROI גבוה – חלק 2

23 באוקטובר, 2010

חברת 5IVE // עיצוב ממשק משתמש – בפוסט על ROI ||| בפוסט הקודם סיפרתי על כנס UXI השנתי שהתקיים לפני כשבועיים, ובו התבקשתי להציג case study על אחד הפרויקטים שלנו, ולבחן את ההחזר על השקעה בחווית משתמש באותו פרויקט, או בלעז – ה- ROI של ה- UX בו. כזכור, בחרתי בחברת קונדואיט (conduit.com), לקוח ותיק שלנו. באותו פוסט תארתי את המיזם של קונדואיט, וכעת הגיע הזמן לספר מעט על מאמץ תכנון ממשק המשתמש במיזם.

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

  • "מהן דרגות החופש שמעוניינים להעניק משתמש הקצה": האם הוא יכול להסיר apps? לשנות סדר של הופעת איקונים של apps בטולבר?וכו'.
  • "מה קורה אם המשתמש מוריד מספר toolbars".

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

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

דוגמא 1 לממשק המשתמש של conduit

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

והנה הממשק של ה- apps marketplace:

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

אם אני למשל כעת מעוניין, כ- publisher, להוסיף את ה- facebook app לטולבר שלי, אקליק על איקון facebook (ראו בתמונה למעלה), ואז ה- איקון מטפס למעלה באנימציה נחמדה לכיוון הטולבר, ובסופו של דבר באמת "מתיישב" עליו (נו, לעיתים אחרי השהיה מסויימת…).

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

שלכם,

יורם

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

9 באוקטובר, 2010

חברת 5IVE // עיצוב ממשק משתמש – בפוסט על ROI ||| בכנס UXI השנתי הראשון שהתקיים לפני כמה ימים בשפיים, התבקשתי להציג case study על אחד הפרויקטים שלנו, ולבחן את ההחזר על השקעה בחווית משתמש באותו פרויקט, או בלעז – ה- ROI של ה- UX בו. ובכן, בחרתי בחברת קונדואיט (conduit.com), לקוח ותיק שלנו.

שלושת היזמים של קונדואיט

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

ממשק המשתמש שמגיש את ה- apps

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

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

toolbar של fox news

עד כאן – תאור כללי ביותר של המיזם של קונדואיט. בפוסטים הבאים אמשיך את ה- case study: אתאר את פעילותנו אנו, את הממשק כפי שהוא היום, as made, ולבסוף, כמובן, אתייחס להחזר על השקה בממשק המשתמש.

יורם

ROI של UX

29 בספטמבר, 2010

התבקשנו להציג בכנס UXI הקרוב בנושא ROI של פרוייקטי UX. ככל הנראה נדגים בעזרת conduit (קונדואיט), ואולי גם U3. פרטים נוספים בהמשך…

עיצוב ממשק משתמש – הגישה ההסתברותית

18 בספטמבר, 2010

חברת 5IVE // עיצוב ממשק משתמש – בפוסט על ממשק והסתברות ||| גורו השימושיות אלן קופר הצביע עוד בספרו about face על אלמנט ליבה שמייחד את מקצוע ממשק המשתמש לעומת חלק מהמקצועות הנדסיים אחרים: העובדה שההכרעות בדיסציפלינה המקצועית הזו מבוססות במידה רבה מאד על מפת הסתברויות. בדרך כלל אני לא מחבב את ספריו של קופר, אבל האמירה הזו היא בול לעניין.

אסביר: במקצועות הנדסיים קלאסיים אסור למתכנן להתפשר על חשבונם של תרחישים בעלי הסתברות נמוכה (להבדיל מזניחה, negligible). למשל, מתכנן של גשר לא יכול להתעלם נאמר מכך שעוצמת הרוחות היא גבוהה ממאה קשר רק באחוז אחד מהימים בשנה. אחוז אחד הוא מספיק ודי… ואיש תוכנה שכותב ביטוי case, חייב לחשוב מראש על כל ה- cases, גם אלה שבהסתברות של 1 ל- 1000, כי אלף שימושים קורים מהר מאד, כך שמובטח לו שידווחו לו על crash תוך כמה ימים. למעשה, היות וגם הסתברות קטנה מאד היא חשובה בדיוק כמו הסתברות של 99%, ההסתתברות כמושג שיש להתייחס אליו נעלמת מעולמו של התוכניתן, ובצדק. אין לה משמעות כלשהי עבורו, תוכניתן הוא עיוור להסתברות.

לעומת זאת במקצועות הקשורים יותר לפרקטיות של שימוש וחוויה של שימוש, ההסתברות קובעת גם קובעת. אתחיל דוקא מעיצוב פנים, וספציפית אדגים בעזרת – פתח של חדר. הפרקטיקה של עיצוב פנים היא לקרוע פתחי חדרים בגובה של 199 ס"מ (כך למיטב זכרוני קובע התקן הישראלי). משמעות הדבר היא כי אנשים שגובהם שני מטר ומעלה ייאלצו להתכופף בדלת, וחמור מזה – יסתכנו בחבטה קלה. מדוע "דופקים" את הגבוהים? מדוע מאפשרים חווית משתמש פחותה ואפילו כואבת לפלח מסויים באוכלוסיה? התשובה היא: מתפשרים על חשבונו של פלח משתמשים (משתמשי דלת) שהסתברותו נמוכה! הרי ברור לכולנו כי לו אחוזם באוכלוסיה של אנשי השני מטר ומעלה היתה, נאמר, 30%, הפתחים היו גבוהים יותר. ומה משיגים בפשרה כזו, מה ה"רווח" שמתקבל כתוצאה מההרעה בתנאי השימוש של משתמשי ההסתברות הנמוכה? ובכן, כמה דברים: פתחים גבוהים מצריכים דלתות גבוהות, משמע דלתות יקרות יותר; וכן – דלתות כבדות יותר, כולנו נצטרך להתאמץ יותר בסגירה ופתיחה שלהן. וגם – הדבר מותיר חגורת קיר צרה יותר מעל הדלת, מה שעשוי להקשות על קורות קונסטרוציה חזקות דין. וגם – דלת גבוהה וצרה אינה אסטתית, ואז היינו צריכים להגדיל גם את רוחב הפתח, ואז שוב משקל ומחיר וקירור וכו' וכו'.

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

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

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

באיחולי שנה שתהיה מעולה בהסתברות גבוהה (וסתם טובה בהסתברות נמוכה),

יורם

עיצוב ממשק משתמש wow

9 בספטמבר, 2010

חברת 5IVE // מעצבי ממשק משתמש – בפוסט על wow ||| אחד הלקוחות שלנו ביקש מאיתנו עבודת עיצוב ממשק משתמש לאפליקציית web בתחום הקשור למדיה. ובכן, ניגשנו למשימה במלוא הרצינות, ניתחנו – ביחד עם הלקוח – את תהליכי העבודה של המשתמשים לסוגיהם, תכננו מודל תפעולי לממשק המשתמש, ובעקבות זאת תכננו את הפ screen layouts השונים.

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

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

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

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

יורם

עיצוב ממשק משתמש ל- FLEX

4 בספטמבר, 2010

חברת 5IVE // מעצבי ממשק משתמש – בפוסט על עיצוב ל- FLEX ||| כידוע גורלו של הפלאש אינו ברור אל מול גיחתו המסעירה של ה- HTML5. רבים חושבים על עתידם הצפוי של סרטוני הוידאו (המממושים כיום ב- Flash ) , של האנימציות ושל אתרי הפלאש למיניהם, אבל יש נישה נוספת – נישת ה- FLEX. יש לנו לקוחות שזו סביבת הפיתוח שלהם, כך בחרו לממש את היישומים שלהם. מדובר ביישומים ארגוניים בד"כ, לא בסתם web services לציבר הרחב.

גורלו של הפלקס כרוך בודאי בגורלו של הפלאש כולו: דעיכה בשימוש בפלאש תדעיך אותו בוודאי גם, אלא שאולי הקצב של דעיכתו יהיה נמוך יותר. כאשר אנו עוסקים ב-עיצוב ממשק משתמש ל- FLEX, אנו נוהגים לדלוור את העיצוב בדרך של styling ישיר של הקונטרולים של FLEX. אפשר לעשוות זאת באמצעות ה- Flash Builder 4, או באמצעות כלים אחרים כמו ה- Flex Style Explorer. לעיתים styling (כלומר יצירת CSS ל-פלקס) אינו מספיק – אינו מאפשר להגיע לעיצוב המבוקש, ואז מעצב ה- FLEX שלנו צריך לעבור לטכניקת skinning שהיא מורכבת יותר, ומצריכה יכולת קידוד ה- mxml.

אני מניח שאספר עוד על הטכניקות האלה לעיצוב ממשק משתמש וחווית משתמש באחד הפוסטים הבאים (אלא אם, כאמור, ה- FLEX ידעך חלילה קודם…)

יורם

GUI mockup

27 באוגוסט, 2010

חברת 5IVE // מעצבי ממשק משתמש – בפוסט על GUI Mockups ||| בזמן האחרון יותר ויותר לקוחות מבקשים מאיתנו להכין mockups (או בתלעיז עברי – מוקאפ) לממשק המשתמש המיועד. mockup כזה יכול לשמש הן ככלי ל- POC וכן כמערכת הדגמה עבור משקיעים, מנהלים בכירים וכד'.

אני מודה, פעם לא התחייסתי ל- mockups בחשיבות הראויה והתבטאתי בסגנון, "מה, אתם לא רואים שכתוב כאן שאם לוחצים על הכפתור הזה אז מופיע המסך הממוספר 2.3.1, ואם לוחצים לו על הקומבו נפתחת הרשימה שמובאת בצד כאן מימין?" ובכן, לא, לא רואים. אמנם אני רואה בקלות, הכל מתנגן בדמיוני כמו סרט (עדיף לא של טרנטינו), אבל רבים אינם רואים. למה הדבר דומה? לאמן שחמט שבא ומדבר בפני קהל מזדמן, ומתחיל לדקלם  משחק נפלא ועיניו בורקות: "ה2 – ה-4, רץ ג'3 – ג'5+ …" וכו', ומצפה שכל מאזיניו יתרשמו מגדולת המהלכים. עצם העובדה שאותו אמן מסוגל לתסרט הכל בדמיונו כתוצאה מנסיונו וכשרונו, אינה מבטיחה כלל שגם קהלו יוכל לעשות זאת. הקהל דורש לראות את הכלים נעים על לוח השחמט!

משחק שחמט - גם זו חווית משתמש

משחק שחמט. ה- mockup החי (והמוות הנוכח).

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

איך אנחנו עושים mockups להדגמת תכנון ממשק משתמש ועיצוב ממשק משתמש? זה תלוי, לעיתים ב- WPF בשימוש ב- expression blend, לעיתים ב- Flash, לעיתים ב- HTML. הכל לפי אופי ה-מוקאפ והאיכויות המצופות ממנו.

עוד על הדגמת חווית משתמש באמצעות mockups  - באחד הפוסטים הבאים.

- יורם

GUI Design לאפליקציות מורכבות

21 באוגוסט, 2010

חברת 5IVE // עיצוב ממשק משתמש – בפוסט על GUI לאפליקציוות מורכבות – – – זה לא סוד שיש לנו ב- 5IVE התמחות חזקה באפליקציות בעלות מורכבות, סיבוכיות לוגית. אפקליציות אלה מתאפיינות באזור אפור רחב ידיים בין המעטפת החיצונית (ממשק המשתמש) לבין ליבת הלוגיקה של המוצר (הלוגיקה העסקית). GUI Designers "רגילים" לא מסוגלים לטייל גם בתוך האזור האפור הזה, ולכן בעצם, הם די מנוטרלים בעת הנסיון לגבש ממשק משתמש ראוי, לוגי, הולם, למוצר.

GUI Designer ממוצע - אחרי שנחשף למערכת מורכבת (מתוך edgewatertech.wordpress.com)

אביא דוגמא: יש לנו לקוח שמערכותיו הן סופר מורכבות, עוסקות ברישויי תוכנה, DRM; לוגיקת הליבה שלהן סבוכה מאד, כוללת הרבה מאד מקרי קצה, rollbacks, תמיכה בשדרוגים ובשינמוכים של רישוי וכדו', כאשר כל פעולת משתמש משליכה בבת אחת על אוסף גדול מאד של אובייקטים – שלהם יש יחסי הכלה ואסוציאציה מורכבים כרגלי תמנון… ובכן, כדרך הטבע, רק כאשר מישהו (כלומר ה- GUI Designer) מתחיל ללנסח את תהליכי העבודה של המשתמשים – מתגלה המורכבות במלוא הדרה, ומתעורר הצורך להשלים את הלוגיקה העסקית, לטייב את הלוגיקה העסקית, להתאימה לפעולות שמשתמשים באמת רוצים לעשות, לפעולות שמשתמשים יעשו. ובכן, פה נדרש מתכנן ממשק משתמש שאינו מהסוג "הרגיל", אלא כזה שיוכל – בלי חשש – להכנס לתחום האפור בין הממשק ללוגיקה העסקית, לצעוד בו בבטחה, לייעץ, לכתוב מפרטים הכרוכים בלוגיקה דוקא ולא בממשק, להציע שיפורים במודל המוצר (ולא, לא במודל הממשק), ולהיות בעל יכולות כאלה כך שהלקוח יכיר בו כבר-סמכא גם במישורי הלוגיקה העסקית ומודל האובייקטים.

צריך לומר את האמת: 99% (אני עומד מאחורי זה) מה- GUI Designers אינם בעלי היכולת לפסוע באזור האפור (אולי יותר נכון לומר – לפסוע שם בלי להראות כמוקיון). לכן אני משתאה לעיתים כאשר חברה בעלת מוצרי תוכנה מורכבים לוקחת יועצי חווית משתמש מחברות "רגילות", כאלו שיכולות להציע גרפיקה מרשימה, אבל נאטמות כאשר נוגעים בלוגיקה. לדעתי – זה נובע מתאום ציפיות משונה: לא רק שמתכנני ממשק משתמש אינם מצפים מעצמם ליותר – גם הלקוחות שלהם אינם מצפים מהם ליותר, "תעשו לי את זה יפה, ותעשו לי את זה שימושי ברמת פריסת הפקדים על המסך". אז לא, חברת תוכנה יקרה, ו- לא, יועץ ממשק משתמש יקר, לא תצליחו כך להפיק מוצר איכותי: אתם מגבילים את עצמכם לרמת היופי ולרמת ה- micro-usability, שם, אם אתם טובים, תצליחו להפיק את מלוא העשרים אחוז שימושיות שגלומים שם. עלהשמונים אחוז שימושיות, שגלומים במאקרו, ויתרתם מראש.

בתקווה לפוסטים פחות תוקפניים,

יורם

עיצוב ממשק משתמש ב- WPF

18 באוגוסט, 2010

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

"לא, מה פתאום מאוחר," ענינו.

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

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

פרויקט כיפי ב- WPF

27 ביולי, 2010

חברת 5IVE // עיצוב ממשק משתמש בפוסט על עיצוב WPF – – – בימים אלה אנו מבצעים פרויקט כיפי ב- WPF. המדובר באפליקציה שנועדה לתרגל כבדי שמיעה בשיפור יכולת השמיעה שלהם. עיצוב האפליקציה מודרני וקליל – רקע לבן עם אימג'ים גדולים כשצריך, תוך שליטה של צבעי כחול וחום. אוורירי מאד. המימוש ב- WPF הלך מהר יחסית: הקמנו מסך ראשון בעזרת Expression Blend, השתמשנו ב- tab control כדי ליישם את מנגנון החלפת ה- views, ובחרנו שהכל – אבל הכל – ימומש באמצעות window יחיד. הנחינו את תוכניתן הלקוח למתג את תכונת ה- visible של grids שונים לפי ה- state של היישום, כך שאותו חלון מחליף תכולה בפשטות ובמהירות.

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