הסיפור הבא מבוסס על מקרה אמיתי... (אנגלית).

"שוד ושבר": שלא כמו במצגות פנימיות שערכנו לחברה, במחשב המנכ"ל, אפליקציית ה-Web שפיתחנו הוצגה בצורה בעייתית, מה שגרם לחוויית משתמש מפוקפקת. מבחינתנו, הבעיה הייתה ברורה וצפה מיד: המנכ"ל גלש ב-IE8 במצב "תאימות לאחור" (Compatibility View).

חברת פרופר מספקת שירותי אאוטסורסינג וייעוץ בתחום .NET לחברה מסוימת בתחום האבטחה. בין השאר אנו מפתחים אפליקציית Web, שמטרתה להיות ממשק משתמש לבעלי התפקידים השונים. האפליקציה כתובה ב- ASP.NET 4 תוך שימוש בגרפיקה עשירה מאת מעצבים מקצועיים, מרובת Themes ו-Ajax לטובת חוויית משתמש טובה, נינוחה ומהירה. בשלבים מתקדמים בפיתוח ולקראת יציאה של גרסת התנסות ללקוחות, נקראנו למנכ"ל החברה, אשר ביקש להשתמש באפליקציה כפי שהיא נמצאת בשרתי הבדיקות, ואז צצה הבעיה המדוברת - בעיית התאימות בדפדפני IE.

על מנת להבין מהו Compatibility View, כדאי לתת מספר מילים לגבי פיתוח אפליקציות Web ומלחמות הדפדפנים. פיתוח אפליקציית Web שונה מהותית מפיתוח אפליקציות רגילה, בכך שהמשתמש לא עובד עם תוכנה ייעודית המותקנת מקומית, אלא באמצעות הדפדפן. כך שחוויית המשתמש תלויה בצורה חד-משמעית בסוג הדפדפן שהוא משתמש וכמובן בגרסת הדפדפן: בדרך כלל, ככל שהדפדפן מעודכן יותר, כך חוויית המשתמש צפויה להיות עשירה יותר ומהירה יותר. אלא שהיו הרבה תהפוכות לאורך השנים, והדומיננטיות של דפדפן Microsoft Internet Explorer, עקב הימצאותו כחלק ממערכות ההפעלה מסוג Windows, גרמו למיקרוסופט עד לפני מספר שנים לנסות להכתיב לשוק סטנדרטים משלה. התוצאה: שנים רבות של פיתוח לפי דפדפני IE הדומיננטיים, גרמו לכך שאתרים רבים פשוט לא עבדו בצורה תקינה על גבי דפדפנים מתחרים. על מנת שהאפליקציה תעבוד בצורה תקינה הן על גבי IE והן על גבי דפדפנים מתחרים, נדרשו מאמצים הכרוכים לרוב הן בהוצאה כלכלית על זמן הפיתוח וההתאמה, ולעתים אף דחייה בשחרור גרסאות של אפליקציות שונות.

אך מה שהיה נראה כמו ניצחון בטוח של מיקרוסופט על המתחרים, השתנה עד לפני מספר שנים עם יציאתם של דפדפנים חזקים מתחרים (Firefox, Safari, Google Chrome ואחרים), אשר סיפקו מענה הולם לצורכי המשתמשים, בעוד מיקרוסופט זנחה את התחרות ובחרה במשך תקופה ארוכה שלא לפתח גרסאות חדשות ומתקדמות ל-IE. דוגמא פשוטה לכך היא גלישה באמצעות טאבים, שפשוט לא הייתה זמינה עד סוף 2006 (ב-IE7), בעוד שאצל המתחרים זו הייתה תכונה מובנית מזה מספר שנים. מיקרוסופט בשנים האחרונות מבינה שהיא טעתה בהזנחת המשתמשים, וחשוב מכך, בהזנחת הסטנדרטים, ועושה מאמצים רבים לפתח דפדפנים עדכניים ותחרותיים אשר תומכים בסטנדרטים העולמיים המקובלים. לראשונה ראינו זאת ביציאת IE8, אשר היה בבחינת אבן דרך משמעותית בהליכה לקראת הסטנדרטים העולמיים (אבל עדיין מרחק רב מהרצוי), ובקרוב אף ייצא IE9 שאמור להיות קפיצת דרך משמעותית, הן בתאימות לסטנדרטים והן מבחינת ביצועים.

הבעיה שמיקרוסופט הייתה צריכה להתמודד עמה, היא אותם אתרים אשר נבנו במשך שנים לפי גרסאות קודמות של IE, שכזכור, נבנו שלא לפי הסטנדרטים העולמיים. גלישה לאתרים אלה ב-IE8 עלולה לגרום להם להיות מוצגים בצורה לא תקינה, בדיוק כמו בדפדפנים המתחרים. כמו במקרים אחרים, מיקרוסופט פתרה את הבעיה על ידי שילוב של מצב "תאימות לאחור" (Compatibility View) - ובלחיצת כפתור, משתמש IE8 יכול לצפות באתר שבו הוא נמצא, כאילו הוא גולש לשם בדפדפן IE7, ולראות את האתר בצורה תקינה.

אם כן, זה היה המצב שבו היה נתון מנכ"ל החברה - הוא גלש לאפליקציה שלנו בדפדפן IE8, שהיה מכוון למצב "תאימות לאחור", ולמעשה צפה בו כאילו הוא גלש בדפדפן IE7. האפליקציה שלנו פותחה כך שתתמוך ב-IE8 וב-Firefox 3.5, על מנת שלא להשקיע בזמן פיתוח מיותר ב-IE7, ולכן לא נצפתה אצלו במחשב בצורה תקינה. בצורה פשוטה החזרנו את הדפדפן של המנכ"ל למצב IE8 והדברים הסתדרו. אך זה לא פתר את הבעיה האמיתית: משתמש ארעי עלול למצוא את עצמו בדיוק באותה סיטואציה של המנכ"ל, ולגלוש "בטעות" בדפדפן IE8 במצב IE7. גם הפתרונות התכנותיים המקובלים לכאורה, אשר אמורים "לסייע לדפדפן IE8 להבין שהוא אמור להציג את התוכן שלא במצב IE7" - לא תמיד עובדים, ולו רק בשל העובדה ש-IE8 עלול להיות מכויל לכך שאתרים פנים-ארגוניים (Intranet websites) יוצגו תמיד במצב של תאימות לאחור. יתרה מכך, ישנם משתמשים אשר עדיין גולשים בדפדפני IE6 או IE7, וחווית המשתמש שלהם צפויה להיות מאוד לא מוצלחת.

הפתרון האידאלי לכאורה היה פשוט: יש לתמוך בכל הדפדפנים. אך בפועל, זהו כנראה הפתרון ה"פחות מוצלח". משך ההשקעה בזמן פיתוח והתאמה לדפדפנים ישנים, כולל בדיקות QA ודחיית יציאתן של גרסאות - פשוט לא תמיד שווה את ההשקעה, אלא במקרים יוצאי דופן. בעולם שבו הדפדפנים מתקדמים בקצב אדיר, שאתרים מובילים בשוק מודיעים שהם יפסיקו תמיכה ב-IE ישנים (google, YouTube ו-Facebook Chat), ושמיקרוסופט בעצמה ממליצה לשדרג ל-IE8 - צריך סיבה טובה לממן המשך תמיכה ב-IE6 או IE7. למעלה מ-70% מהגולשים השונים לא עובדים בגרסאות ישנות אלה, נכון לאוגוסט 2010.

לכן, בסיכומו של דבר היו שתי אפשרויות פעולה בעבור משתמשי IE בגרסאותיו הישנות:

1. לכלול תמיכה ב-IE7 (לגבי IE6 "ומטה" מעולם לא היה ספק, שלא תהיה תמיכה) - מה שכאמור היה גורר מאמצים בפיתוח ובבדיקות, ופותח פתח לבאגים ותחזוקה עודפת.

2. לאתר את סוג דפדפן ה-IE של המשתמש ולפעול בהתאם:

   1. במידה ומדובר ב-IE 6/7 - לספק למשתמש מסך הסבר עם המלצה לשדרג את הדפדפן  (פתרון זה טוב גם עבור דפדפנים אחרים שאינם נתמכים באופן רשמי).

   2. במידה ומדובר ב-IE8, במצב תאימות לאחור ל-IE7 - להציג מסך למשתמש עם הסבר לגבי מצב "תאימות לאחור", הכולל המלצה לכבות מצב זה ולעבור ל-IE8, כולל הנחיות כיצד לעשות זאת.

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

חשוב להבין שהאפשרות לספק תמיכה ל-IE7 יכולה להגיע גם בשלב מאוחר, לאחר קבלת חיווי מהמשתמשים עצמם. תמיד אפשר לקבל תגובות מהשטח ולקבל החלטה בשלב מאוחר יותר, להמשיך ולהשקיע בפיתוח והתאמה לדפדפנים ישנים יותר. עוד חשוב לציין, שההחלטה לתמוך בסוגים מסוימים של דפדפנים אל מול ההחלטה לוותר על דפדפנים אחרים, בפרט IE6/7 שהם עדיין דפדפנים נפוצים, אמורה להיות החלטה אסטרטגית ברמה הניהולית, ולא צריכה להיות החלטה של צוות הפיתוח בלבד (אם כי בהחלט יש להתייעץ עם צוות הפיתוח לגבי המשמעויות).

במקרה המדובר הבחירה בסופו של דבר הייתה לוותר על IE7, עד אשר ואם תגיע דרישה מהמשתמשים אשר תיתפס כמחייבת, ולספק הודעות מתאימות אשר יעודדו אותם לשדרג ל-IE8 או FF 3.5 ומעלה. במקרה שבו משתמש גולש במצב תאימות ל-IE7, נספק הסברים כיצד לעבור ל-IE8.

קרא כיצד לבצע לבדוק בקוד האם דפדפן ה-IE רץ במצב Compatibility View.