התאמת עיצוב אפליקציה ל-iPad ולטאבלטים אנדרואיד

התאמה לטאבלטים: היכן הממשק מתפרק

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

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

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

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

מה נותנת פריסה מעובדת מחדש: אפקט במספרים

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

מהירות מעבר התרחיש

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

חזרות לשלב קודם ופניות לתמיכה

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

סוג התקלות שנעלם

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

אפשרויות התאמה לטאבלטים: השוואת גישות

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

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

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

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

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

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

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

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

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

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

ערכת מוקאפים, מפרטים וכללי פריסה

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

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

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

מקרה בוחן: אפליקציית שירות הועברה לפריסה דו-פאנלית

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

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

החטאות ברכיבי שליטה — נגיעות מחוץ למטרה ולחיצות שבוטלו — קרו בטאבלטים בשיעור גבוה בהרבה מאשר בטלפונים, ולתמיכה כתבו בעיקר על ניווט ולא על נתונים.

מה שינו ומה מדדו

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

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

גרסת הטלפון קיבלה את אותה לוגיקה דרך מעברים בין מסכים — הפריסה ב-Android-טאבלטים וב-iPad נבנית מאותן קומפוננטות.

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

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

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

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

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

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

שאלות נפוצות על פריסות במסכים גדולים

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

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

איך בודקים התנהגות במכשירים של יצרנים שונים?

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

מה יקרה לגרסאות האפליקציה שכבר פורסמו?

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

מי אחראי על התוצאה ולוחות הזמנים?

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

נדבר על המשימה: מה מבררים לפני אומדן העבודה

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

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

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