9/20/2010Browser Wars and Internet Explorer’s Compatibility View issue.

The following story is based on true events... (Hebrew).

“Crisis”: Unlike the different internal presentations, on our customer’s CEO computer, the web application we’ve developed appeared broken, causing poor user experience. For us, the problem was clear and known: the CEO was using IE8 set to Compatibility View.

Proper Development provides outsourcing and consulting services in the .NET development framework for a certain company dealing with security. Amongst other activities, we develop an extensive Web Application designated to be the front-end interface for the different product users. The application is developed in ASP.NET 4, using rich graphics from professional designers, and includes multiple ASP.NET Themes and MS ASP.NET Ajax usage for a better and faster user experience. In advanced stages of the development, towards the oncoming pre-release version, we were called to the CEO’s office, who attempted to use the web application as it was installed on the QA servers, and that’s when the problem occurred - the IE Compatibility View Issue.

In order to understand what Compatibility View is, several words are required in order to understand Web Application development and Browser Wars. Web Application development is inherently different from developing regular desktop applications, as the user is not using a local installed application, but an Internet browser. The user experience depends explicitly on the type and version of the browser used. Usually, the more updated the browser is, the better user experience. But, there had been many changes throughout the years, and the fact that Microsoft’s Internet Explorer was incorporated within Windows helped it become the worlds most dominant browser (at least on PC machines), and had Microsoft try to lead the browser market by developing their own standards, not following the common worldwide standards. This caused many web sites to break on competitor browsers, as they were developed targeting IE only, and a lot of effort had to be invested (time & money), or even postponing product deliveries, in order for the web site to be compatible to both IE and non-IE browsers.

But what seemed to be like a certain victory for Microsoft over the competitors, changed several years back with the arrivals of strong competitors browsers (Firefox, Safari, Google Chrome etc’), which provided a more reasonable solution for the customers growing needs, whereas Microsoft neglected the competition and chose not to develop more advanced versions for IE. A simple example for this would be tabbed-browsing, which wasn’t available till the end of 2006 (in IE7), whereas the competitors had this feature “built in” for years. In the past several years, Microsoft understands that neglecting the users, and standards, was wrong, and is investing a lot of effort to develop more advanced and competitive browsers, which support the world wide standards. We saw this first with the emergence of IE8, which was a major milestone towards implementing the world wide standards (but still, very far from it), and the near coming IE9, which should be a major upgrade, both as far as standards go, as well as performance.

The problem Microsoft was facing, ironically, were exactly those same web sites which were built for years targeting older IE browsers, and not according to world wide standards. Browsing to these websites using IE8 could cause them to break, just like in competitor browsers. As in other cases, Microsoft solved this problem by incorporating a “Compatibility View”, and with a click of a button, an IE8 user can view the currently displayed website as if using IE7, viewing the website correctly.

This was the case for our CEO customer. He was using IE8 which was set to Compatibility View, and actually viewed our application as if he was using IE7. The web application was developed to support IE8 and Firefox 3.5, in order not to spend precious “time to market” development time in making the application IE7-compatible, and that’s why it broke on his machine. With click of a button, we switched back his browser to IE8 view, and the problem was gone. But this didn’t solve the true problem at hand: any user could tackle this exact problem, and accidentally browse using Compatibility View. The common programmable solutions, which suppose to help IE8 understand that it’s supposed to display the website not in Compatibility View - don’t always work, for example in cases where IE8 could be configured so that intranet sites always display in Compatibility View. More over, there are users who actually browse using IE6 or IE7, and their user experience could be quite bad.

The ideal solution was allegedly simple: lets support all the browsers! But this is probably the non-recommended option. The time and effort required to support older browsers, including QA and postponing product releases - is not always worth the effort, except for uncommon scenarios. In a world where browsers constantly become more and more advanced, that leading websites decide to stop older IE support (google, YouTube and Facebook Chat), and that Microsoft recommends to upgrade to IE8 - you have to have a good reason to continue financing support for IE6 or IE7. Over 70% of Internet users don’t use these older versions, as of August 2010.

So, eventually, there were two choices to choose from, concerning older IE users:
  1. Include support for IE7 (there was no intention to support IE6 at all in the case discussed) - this would have impact on development and QA, with more chance for bugs and support later on.
  2. To detect the version of the IE browser, and act accordingly in the following manner:
    1. For IE6/7 - display a message regarding the supported browsers, plus a recommendation to upgrade to those supported browsers (this method is also used for other non-IE browsers which aren’t officially supported).
    2. For IE8, in Compatibility View - display a message explaining what Compatibility View is, including a recommendation to switch it off, including instructions on how to do so.

    In any case, the user can “accept responsibility”, and decide to continue browsing using a non-supported browser.

    It’s important to understand, that supporting IE7 is something that can be added later on, upon customer feedback. You can always decide to support older browsers later on. Also important is the understanding, that supporting certain types of browsers and giving up others, especially IE6/7 which are still common browsers, should be a strategic management-level decision, and not the development team’s call (although the development team should take part in this decision making).

    In our case, the decision was indeed not to support IE7, till possible user feedback will demand such support (if at all), and to display those messages encouraging users to upgrade to IE8 or FF 3.5, or above. If a user browses using Compatibility View, we’ll provide explanation on how to switch back to IE8.

    Read how to programmatically check if the user’s browser is set to Comptibility View.

Currently rated 3.3 by 6 people

  • Currently 3.333333/5 Stars.
  • 1
  • 2
  • 3
  • 4
  • 5

Posted by: eladv
Posted on: 9/20/2010 at 1:54 AM
Tags:
Actions: E-mail | Kick it! | DZone it! | del.icio.us
Post Information: Permalink | Comments (0) | Post RSSRSS comment feed

9/20/2010How-to: Detecting IE8 with Compatibility View and general browser support.


If you decide to stop supporting all types of browsers, mainly older IE browsers, you’ll probably be required to detect the browser and it’s version using either client or server programming. Client browser detection can use viewed here. This blog entry focuses on an ASP.NET server side solution, which will allow not only to detect if the browser is supported, but on how to detect IE8 running in Compatibility View (optionally notifying the user on how to switch from this view to IE8).

The solution is quite simple - it relies on the user-agent string sent by the browser. Browsers send information to the server, one of them is HTTP_USER_AGENT, which describes the user’s browser. For example, IE browsers incorporate the keyword MSIE plus the browser’s version. So IE6 will show as MSIE 6, IE7 will show up as MSIE 7 and IE8 will show up as MSIE 8. But how will IE8 appear in Compatibility View (that is, IE7)? Apparently, the browser will send a string with MSIE 7. So, how can we tell whether this is really an IE7, or IE8 in Compatibility View? The answer relies also in the user-agent string: IE8 incorporates a new “Trident” token in the user-agent string, even in Compatibility View. So by combining a check for MSIE 7 with Trident, allows understanding that the user is running in Compatibility View.

In short, the following ASP.NET code will detect if the browser is running in Compatibility View:
bool isCompatibilityMode = (Request.UserAgent.IndexOf("MSIE 7") > -1 && Request.UserAgent.IndexOf("Trident") > -1);

Naturally, you may choose to refactor this code to “better looking code”, such as testing for IE first, and then testing for the major version of the browser etc’.

You can also combine this code in different scenarios: You can detect other browsers, you can block certain browsers, you can notify the users that they’re using unsupported browsers, and you can notify how to switch off Compatibility View etc’. It could also be a good practice to store the user’s decision in a Cookie, Session or some other Profile settings, in order not to process this code every time the browser makes a request.

You can read about the cause for this code in the first place in Browser Wars and Compatibility in Internet Explorer (Hebrew).

To see what your user agent is, click here.

 

Currently rated 2.4 by 7 people

  • Currently 2.428571/5 Stars.
  • 1
  • 2
  • 3
  • 4
  • 5

Posted by: eladv
Posted on: 9/20/2010 at 12:29 AM
Tags:
Actions: E-mail | Kick it! | DZone it! | del.icio.us
Post Information: Permalink | Comments (0) | Post RSSRSS comment feed

9/20/2010מלחמת הדפדפנים ובעיית התאימות של Internet Explorer

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


"שוד ושבר": שלא כמו במצגות פנימיות שערכנו לחברה, במחשב המנכ"ל, אפליקציית ה-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.

Currently rated 5.0 by 1 people

  • Currently 5/5 Stars.
  • 1
  • 2
  • 3
  • 4
  • 5

Posted by: eladv
Posted on: 9/20/2010 at 12:13 AM
Tags:
Actions: E-mail | Kick it! | DZone it! | del.icio.us
Post Information: Permalink | Comments (0) | Post RSSRSS comment feed