Mouse over menus and delay

Just been looking at menus, not for the first time nor the last. One thing i picked up on in Jakob Nielsen's Alertbox is his opinion that mouse over menus should appear after a half second delay, this is to reduce the irritating flicker you get when moving the mouse around a page. I've only seen this implemented a couple of times, can't remember where, but I totally agree with this approach.

I'm much more of a clicky menu person myself, but if you must go mouse over then, delay before showing and delay before closing too!

Related links

• http://www.useit.com/alertbox/mega-dropdown-menus.html
• http://www.smashingmagazine.com/2009/03/24/designing-drop-down-menus-examples-and-best-practices/
  

JavaScript support levels

Generally, i breakdown JavaScript support into 4 levels. This makes life much easier and as i'm a lazy bas****d it suits me to keep development time down to a minimum.

I'm using something like this...

 window.user = {
 jsSupportLevel : 0,
 init: function(){
  if(!document.getElementById){return;}
  var ua=navigator.userAgent.toLowerCase();
  var platform=navigator.platform.toLowerCase();
  var isPC = (platform.match('win32')||platform.match('win64'))?true:false;
  var isDeskTop = ( ua.match('firefox') || isPC || platform.match('macintel')  )?true:false;
  var support = 1;
  if (window.XMLHttpRequest){support = 2}
  if ( support==2 && isDeskTop ){
   support = 3;
  }
  this.jsSupportLevel =  support;
 }
};user.init();

This will give you a js global "user" and you use it in your js to determine whether to do some enhancements or not.
e.g.

if (user.jsSupportLevel>1){
   ... attach Ajax related event handlers ...
} 

Example support levels

0 = user-agent doesn't understand DOM (!document.getElementById)
1 = user-agent DOM enabled
2 = user-agent has native ajax support (window.XMLHttpRequest)
3 = user-agent is probably a desktop browser

You can use the above to deliver the appropriate level of JavaScript support to users, e.g. Don't implement any JavaScript if the support level is 0, only do very basic JavaScript for level 1, do pretty much everything for level 2 and level 3 is level 2 with transitions and opacity (stuff you wouldn't want on a mobile/hand-held).

This will only work if your using progressive enhancement of course!

Expression Web SuperPreview

Having a play with Web SuperPreview from good'ol Microsoft and I have to say i'm a little disappointed.



It very much aimed and a px by px comparison of two browsers, which in my experience is pretty much a waste of time. I've never had a support call were someone is upset about the look and feel being slightly different on a different browser.

Focusing on minor UI display differences results in designers insisting on using graphic buttons and DHTML scrollbars and code forking in the CSS in order to achieve pixel perfect adherence to the visual design on various target browsers. Not a road that I want to go down.

I think I'll be sticking to IETester and VMs, for now anyway.

Also, i may be missing something blatantly obvious but I couldn't workout how to trigger a control or even follow a link in the preview panel so couldn't inspect any dynamic page elements. I assume that's just me being a twat. The product would have no value at all if you can't interact with the page, but it's not immediately obvious how you do (well, not to me anyway!! : ).

Related links...

• http://www.sitepoint.com/blogs/2009/03/19/microsoft-superpreview-website-tester/


• http://www.sitepoint.com/blogs/2008/12/04/adobe-meermeer-will-change-the-way-you-test-web-sites/


• http://www.my-debugbar.com/wiki/IETester/HomePage


• http://browsershots.org/

Icons and image replacment

Generally speaking i'm not a fan of image replacement, but for inline icons it seems to work a treat. We had this issue that users with screen readers where struggling with our icons that we use liberally in our pages. For example, the "More information" icons that we use on some links to indicate that there is more detailed information available, looks something like this.





Although this looks quite reasonable it was causing problems for screen readers as they list out all images which means the user will get a list of images all saying "More information" (so a bit like having a list of links all saying "Read more..."). This is a problem with using images as text (an icon is really short hand text) if you look at them out of context they don't make sense.

Using image replacement as a way of hiding images from screen readers works quite well, as they are background images and not img tags. If we look at the same link using image replacement...





I tend to use nested spans for image replacment, you may prefer to use a single span with a combination of overflow hidden and a text-indent value, depends what browser support your after. If you don't need backwards compatibility you could just use the CSS "content" property instead.

Are DOM browsers the edge case?

I think the answer might be Yes.

You want your application to work on the web so you write it to output semantic HTML, if you do this without using script (or noscript tags) your site should work on pretty much any browser that understands HTML regardless of platform, OS, browser version etc... that's quite a lot of different user-agents running on, mobiles, iTV, games consols, PCs etc... A subset of these user-agents will understand javascript to some degree, and a sub-set of these will understand DOM. If you then think of DOM browsers as a edge case (albeit an improtant one) everything falls into place.