Find your next scenic drive!

June 14, 2011

Internet Explorer 8 Compatibility Mode...

Earlier today, myscenicdrives.com released our road trip planner which I am really excited about. There are several more features that I want to build into it, but this was a really nice time to release it and get some feedback from real users.

For the last week, we have been doing some usability testing, optimizations, cross browser testing, and polishing it all up before the press release earlier today. With the final push going out the door late last night, we did our final round of testing and under Internet Explorer 8, I got that dreaded, “A problem displaying [site] caused internet explorer to refresh the webpage using compatibility view.” This resulted in a huge effort to figure out where that message from coming from.

The majority of the testing was done in the latest version of all browsers, which I was really pleasantly surprised at how standards compliant Internet Explorer 9 is. While I had to do a few tweaks specifically for it, it was relatively easy and no more than what I had to do for other browsers. When I cracked up Internet Explorer 8 (via Microsoft’s virtual machine image), it required a lot more tweaks but in the end, it seemed good.

This is why I was really surprised when I loaded up the page last night and saw the compatibility view message. Unfortunately, that message does not provide any insight into what the problem might be. The Microsoft documentation on the matter states that your pages must have a DOCTYPE and validate, but they also hint that there are other undocumented reasons — this makes finding the root of the problem orders of magnitude more frustrating.

After changing things I thought might be suspect, endless googles for any hints, and etc., I started commenting out various chunks of code trying to make it go. At the end, I had a simple empty page with nothing between the opening body tag and the closing body tag, and it was still happening! But this was illuminating because right above where the body tag came out was one little optimization we had done recently.

When usability testing, we noticed that there was a lag in images being displayed which was not user-friendly. To help prevent that problem, we looked into image prefetching techniques, and fell upon the CSS technique:

  1. body:after {
  2. content:url(image.png);
  3. display:none;
  4. }

This made a world of a difference in testing. According to my research, this technique is suppose to be ignored by browsers that do not support the :after clause and so it felt safe. Since the images in question were very specific to the application being developed and the page in question is not intended to be read by search engines, we decided to inline this code on the page.

Could this be the cause? Well, in trying to narrow it down further, I did comment out the entire style-tag and sure enough, my page did not go into compatibility mode.

This fixed my compatibility-mode problem and hopefully it may help someone else out there.

April 24, 2007

Firefox 2 and Thunderbird 2 on a Single-Button-Mouse Mac...

If you use a Mac with a single-button mouse and you have recently upgraded to Firefox 2 or Thunderbird 2, you may have noticed that holding the button down no longer brings up the context menu. While you could use the control key when clicking, that is not a perfect and seamless solution. Instead, you can get the same behaviour back by enabling the ui.click_hold_context_menus option.

In Firefox, type about:config in the address bar and press enter. Under the filter, type in context, find the ui.click_hold_context_menus item, and double click (the line should be bold and the value should be true).

In Thunderbird, go to the Thunderbird pulldown menu and select Preferences. Under the Advanced section, choose the General tab, and click the Config Editor button. Under the filter, type in context, find the ui.click_hold_context_menus item, and double click (the line should be bold and the value should be true).

With this simple recipe, you should be back to your old browsing habits.

January 15, 2006

Thoughts on Mobile Web Best Practices...

It has been reported in several places that this year will definitely be the year of the mobile web, and thus, it is only fitting that the W3C has released a draft of the Mobile Web Best Practices 1.0 on Friday. And while there is a good number of advice that is particular to mobile browsing (many of which dovetail nicely with my own complaints), I find that most of the content could be summarized by design with web standards.

What is nice about this best practices is that it starts off by discussing some of the requirements, one of these includes highlighting user’s goals, where there is more focused browsing than on a desktop. I agree with this completely, especially since a desktop computer typically has tabs or windows where you can open content. Most mobile web browsers do not have this ability, or in browsers such as Minimo, it is not as easily used as on a desktop.

But in reality, this is not the only or even most important of the issues. The major issue is that a good number of sites render horribly in the mobile web browsers, such as making a paragraph that is one centimeter (or one word, which ever is greater) wide and billions of lines long, surrounded by inches and inches of pure white, unused screen real estate. I think this curves my own browsing techniques to looking for particular information.

Two other issues that are highlighted are advertising and scrolling, both of which I would personally group together. Most of the scrolling that is required when browsing on a mobile device is related to advertising, where many of the advertisements cause substantial vertical scrolling in order to get to the content that you are actually interested in. One such site is PocketPC Thoughts, where if you choose the Pocket Internet Explorer One-Column layout, you are forced to scroll 80% downwards to get the content of the site.

Advertising is not the only cause of this unnecessary scrolling, but it one of the major offenders. Another group in this list are sites that use a predefined size for a div, but on mobile devices, this renders into a very skinny, long column, such as many blogs, including Asa’s blog.

Navigation is a huge one. Similar to desktops, frames should simply be avoided. For example, last week I was tracking the arrival time of my wife’s flight on Jet Blue, and I thought it was rather cool that she was going to be about 20 minutes early. I later checked the site by simply reloading the site in Firefox on my desktop, and that is when I noticed that they used frames, so instead of seeing that instead of being 20 minutes early, she was just going to be on-time, I was redirected to their start page. This is frustrating from a user experience perspective, for both refreshes and bookmarking, but on a mobile device, it gets even worst. In Pocket Internet Explorer, it usually ends up that the main content frame is the smallest frame displayed on the device; Pocket Internet Explorer deals with this by drawing huge border around each frame that allows you to (arguably) quickly resize the frames, or you can take your stylus on that frame, hold it down, and select Go To This Frame, which will focus the content that you want to read, but then you lose all the navigational content that you had previously. In other words, there is nothing that frames offer that make the user experience better; all of these techniques could be rendered with CSS and be significantly more usable and portable.

But navigation also includes buttons like Back and Forward, or even bookmarks, and the recommendations suggest that some devices do not offer these operations. I find hiding the back button a bit odd though. The Pocket Internet Explorer interface deals with this nicely, by making the back button easily accessible, and it hides the forward and refresh button under a menu. And for the few times that I have to use those buttons, I am glad they aren't using valuable screen space.

The lack of the Back, Forward, and Refresh buttons definitely changes design a bit. One of the places in the recommendations that they explicitly talk about this is in error reporting. The first part of the error reporting section is simply presentation, and it is just a matter of telling users what went wrong and what they can do about it in a language that they understand. It is still surprising to me how many web sites put these cryptic error messages that make web sites much less usable. But the other part of the error section is simply about giving the users some options of what to do with the error. Should the user press the back button and try again? If so, don't assume they have a back button, and give them something to bring them back, or even better if it relates to information in a form, do not bring them back, but rather allow them to change the erroneous input in the current page. Will a refresh help the condition? If so, give them a button or a link that will retry the link. And more importantly, give them links to bring them back to some index page based on what they are browsing or some home page, both of these options are basically to keep the users on your site.

Also related to navigation is searching. There are many sites that I do not find what I am looking for quickly, so I want to search their content to find what I am looking for. The way that many pages render on mobile devices, however, the search option can be difficult to locate and can require some scrolling. In my opinion, if your site has the ability to search, place it somewhere noticeable and towards the top of the rendered page, and this way, users will remember where the search is in the event that they want to use it (and yes, I know, this site does not follow that advise :-)).

In the adaptation section, there was some good separation between server, network, and client side adaptations. This is interesting to separate them out. A great example of a server-side adaptation is actually Google. When it detects that you are browsing from a mobile device, it throws you onto a lighter-weight web site for mobile devices. And while this is a great way to optimize for mobile devices, it is not the approach that I think the average web content developer will take, but I would love to be surprised here. I would imagine that most content developers will simply provide the content in a fashion that is, instead, friendly to most devices, only optimizing little things here and there. One aspect of Google’s approach that does not necessarily jive with the recommendations is that the URL is noticeably different, and thus, bookmarking a search that I did on my PDA will not change the presentation when I display it on a desktop, therefore, not making it transparent and compatible with the OneWeb vision.

An example of a network-side adaptation is actually Palm’s Web Pro. This web browser has the ability to use a proxy server that optimizes HTML and images for your device, and this makes a huge difference for mobile usability in my experience. Pages would load significantly faster and be far more usable when you used the proxy than when you didn’t. I would imagine that some mobile phones out there would also have a similar proxy.

Finally, examples of the client-side adaptations are numerous, but the one that I have been using the most lately is the Pocket Internet Explorer’s various views. You have the option to view the pages in its default mode, a one-column view, and a desktop view. In its normal view, you will typically have to scroll horizontally to center your content, then only have to scroll vertically, and your page is typically usable, though there are exceptions (such as the very skinny columns). In the one-column view, the page is basically manipulated to place all div’s so that they follow one another and are rendered as paragraphs. In the desktop view, the page is rendered closer to your desktop view, and therefore requires a significant amount of scrolling. The Palm Web Pro previously mentioned also has similar options.

One of the topics that is mentioned in the recommendation is access keys; I would imagine that this feature would probably be more important on phones than on PDA’s, but not having every used them, it is hard to comment on them more than this.

Globally, however, I felt like the recommendations was like reading through Jeffrey Zeldman’s Designing With Web Standards, since most of the content of the recommendations are great for any environment. For example, designing towards web standards, avoiding tables for presentation and using elements to structure documents instead of focusing on presentation.  The OneWeb vision is simply to create web content that is accessible no matter what type of browser you are using.

An example of not being specific to the mobile web are forms, in that you should only ask for the information that you need, only require what you really really need, and make the difference clear. This is nothing specific to Mobile devices. As hard as pecking in information is on some mobile devices, there are a lot of users that do not like typing.

Another great, non-specific example is making links obvious, giving users a good description about what the link will give them, and possibly more important for mobile devices, but also for browser and operating system interoperability, noting the type of content that will be downloaded if the link is not to a web page. And what about web sites that open new windows? Nevermind mobile devices: desktop users are now using enough Popup Blockers that no web-content developer should really depend on new windows opening on a desktop. And finally, short and descriptive titles are ideal in any environment, particularly that in most desktop environments, the default bookmark text is the title.

In summary, I think that the recommendations are great, and I think that most of the recommendations are simply handled by generating web sites that use web standards and just generally designing user interfaces for great user experiences, regardless of their browsing environments.

December 8, 2005

Wells Fargo One-Look Discontinued...

When I recently moved back to the US, one of the things that surprised me was how much more prominent the Internet was, but I think this is actually more of an illusion. In reality, I think that when you move (and particularly more so when you move across borders), you get to setup all kinds of services, and compared to when I did this in 1998, everything is more on-line than then.

One of the sites that really amazed me was that of my bank, Wells Fargo. Their interface is particularly smooth, throwing you directly on an SSL connection, supporting web standards, the ability to display scanned images of your cheques (which they do for free, and I see that my Canadian bank now does this service, but charges $1.50 per cheque), but what really impressed me was their One-Look Service.

Now forget for a moment all those security and privacy concerns, this web application is a perfect example of what web services and web applications are intended to deliver: to aggregate information from multiple providers to make one seamless view to the customer. Their interface effectively allows you to see all of your bank accounts, regardless of the bank, and you can see your current balances in a nicely designed summary page. From the summary page, you can dig down and see the account activity, login directly to that organization's accounts (you must login) or refresh the current snapshot that it has.

The truly amazing part in all of this is how it was so interoperable. All of my 401K, mortgages, credit cards, brokerage accounts, and everything is right there in one place! In fact, the only account that I was unable to add directly was my autoloan, and well, based on their website, it aint surprising why you can't. But even for such accounts, it provides you an interface to manually enter information so that it is still available, albeit not realtime (I have never tried this; my impression was that it was not as powerful as it could be).

Unfortunately, however, Wells Fargo has announced that this service will be discontinued in February 2006. According to this, the service was started in March 2001, and Citigroup had a similar service that was discontinued earlier this year.

And while there are some security concerns around one site having all this information (especially given the number of banks that have "lost" customer information in the last couple years), the interoperability of this service and the customer's ability to get a great, quick summary of all their finances with an easy-to-use interface would seem to be the future of usability. It is unfortunate that this could not be secured sufficiently well to gain customer confidence.

November 9, 2004

The Default CSS File...

When working with CSS and HTML, it is easy to take for granted the default interpretations of tags across various browser vendors. Aside from the fact that some browsers are more standard compliant than others, I would have thought that the default CSS file was a standard. But of course, it is not. Whilst most vendors have similar interpretations to most of the tags, there are some tags that are significantly different amongst browsers.

Debunking the myth of style defaults by Michael Meadhra (mentioned here) talks about this issue. Some web browsers keep there default CSS files hidden away (such as Internet Explorer), and others make it easy to change (such as FireFox, which version 1.0 was released today). The article discusses how you can completely remove this file from FireFox and see how pages are rendered, and well, this may not be an option for everyone, but it certainly shows you how powerful CSS really is.

The article also discusses a few different approaches to ensuring that your sites are consistent no matter which browser is used, which is derived from a few different sources.

This is definitely a page to look through and to actually see what the default CSS files actually does. To paraphrase Effective Enterprise Java, portability must be tested. Just because you abide to standard tags and CSS, each browser can still display them differently, and this article is a good reminder of this. If you want your pages to look great everywhere, you have to test them everywhere.