Shane O'Sullivan's technical blog… really ties the room together

Archive for the ‘Internet Explorer’ Category

Click, change then animate: My self imposed rule for a fast & smooth UI

Posted by Shane O'Sullivan on October 14, 2012

A few months ago I joined the Ads Interfaces team at Facebook, after almost two years on the mobile team, and am very proud of being part of the group that shipped a full rewrite of the Ads Create Flow ( last week.  The application is highly complex, with many varying user interface elements, lots of data floating around, validations and so forth, so it made sense to write it 100% client side in JavaScript. 

In many ways it’s a standard MVC application with

  • declarative view definitions, so you can easily relate the code to what you see in the Web Inspector
  • well defined data models which can be observed for changes
  • bidirectional bindings between views and models to keep the UI in sync with the data.  That is, if a piece of data changes, the UI should just update itself.  Of course, it is also possible to add code in between any binding if some more complex processing is needed.  For example, when changing the top level objective (clicking one of the huge buttons), I wanted it to animate the change, so rather the transference of the data update is delayed.

My New Rule

One of the primary lessons I took away from this is that asynchronous data fetching is one of the leading causes of users feeling like a UI is “webby”.  That feeling where the interface suddenly, with a jerk, jumps around and changes size.

This is often caused by images loading, or by an API call returning, resulting in the UI being redrawn.

I decided on a new rule to apply to interfaces I work on:

The UI can change suddenly when the user interacts with it.  All other changes should be smooth.

What this means is if the user clicks a link or a button, it’s OK to immediately change the UI, since they can see the causation.  However if new data comes back, or a large image loads shifting the entire UI up or down, this should be smoothly animated. 

I’ve found that this both gives an interface a more polished feel, but also draws the users eye to important information.  In addition, if they were already reading something, trying to make a choice of what to click next, if that jumps even a couple of centimeters they have to start searching for it again – it may have gone below the bottom of the screen.  However if it smoothly moves there over 300ms, they continue without much interruption.

It’s important to not go overboard with this of course.  Don’t animate everything, as it’ll feel gratuitous.  I’ve found that sticking to animating only asynchronous operations leads to an application feeling both fast and professional.


Some examples in the Ads Create Flow are the large image that loads for Sponsored Stories (the bottom picture), and the entire Ad preview that loads as a result of a data callback (under Right Hand Column Preview).


One caveat is that on IE 8 & 9, you’re going to have a bad time.  I chose to not bother with janky timer based animation solutions, both in the interest of saving time, and from a healthy disdain for legacy browsers.  So, I advise to stick with CSS3 animations, and let the users of old browsers have a working but less attractive application. 

Posted in Facebook, HTML5, Internet Explorer, Javascript, Technical | 4 Comments »

Navigating in an IE Modal Dialog

Posted by Shane O'Sullivan on December 31, 2007

Internet Explorer has a nice feature where a new window can be opened modally using the window.showModalDialog function, meaning that the page that opened it cannot be accessed until the new window is closed. This can be useful in many situations.

However, the main limitation of IE Modal Dialogs (other than being non-standard), is that any hyperlink clicked in a modal dialog causes another, non modal, dialog to be opened, rather than opening the page linked to in the same window, as would happen in a normal pop up window.

The key to solving this problem is to note that a modal dialog only opens another window when a GET request is made, not when a POST request is made. However, an anchor tag automatically causes a GET request, so the solution is to:

  1. Catch the click on each anchor tag, cancel it,
  2. Submit a dynamically created FORM element, with it’s method set to ‘POST’ and it’s action set to the URL of the link clicked.

While it is possible to put a listener on each anchor tag to achieve this, such an approach will not scale well. Instead, place a listener on the body tag. The example below is done using methods from the Dojo Ajax Toolkit, since that the toolkit I use the most, but you can of course use whatever methods you like to achieve the same result:

<script type="text/javascript">
dojo.connect(dojo.body(), "onclick", function(evt) {
if( != "A") {return true;}
var form = document.createElement("form");
form.setAttribute("target", ? : "SrPopUp");
form.setAttribute("action", url);
return false;

This method assumes that you have control over the content of the page being shown in the modal dialog. It would also make sense to add a similar listener to the body tag for key events, as a user can trigger an anchor tag by tabbing to it and hitting enter.

Thanks to Danny Goodman and Steiner Overbeck Cook for coming up with this solution.
Share this post:digg it|kick it|Email it|bookmark it|reddit|liveIt

Posted in Dojo, Internet Explorer, Javascript, Technical | Tagged: , , , | 16 Comments »

A IE-native module

Posted by Shane O'Sullivan on March 6, 2007

The Dojo Ajax toolkit contains a module called which can be used to store large amounts of non-cookie-based data on the client side. This can be useful for all manner of reasons, which you can read in Brad Neuberg’s announcement on his blog. uses a very high-level API that hides the details of how exactly the storage is implemented. This is necessary because each browser forces an application to store it’s data in completely different ways. Because of this, the primary storage mechanism used in is Adobe Flash. Flash allows you to store up to 100K of data per page (more that 100K if you allow it), however, while Flash has a very impressive install base of over 95% of all browsers, this unfortunately is not 100%.

Because of this lack of full coverage, the WhatWG storage provider was written, which provides native storage support in Firefox 2 without Flash.

This leaves poor feeble Internet Explorer out in the cold however. So, to fix this, I’ve written a module that supports client side data storage in Internet Explorer. It is based on native capabilities in IE 5+ described here. I’ve submitted it as a patch to Dojo, and hopefully it’ll make it into the build over the next couple of weeks.

For those who can’t wait (and are wise in the ways of Subversion), you can download the patch from which you can apply to the nightly code. It was created against the 0.4.2 build. Note that this is probably not the exact code that should make it into the build, as the review process may change it slightly. However, I have tested this with IE6 and IE7, and it seems to work pretty much flawlessly.

Update: It seems that the patch was submitted too late for the 0.4.2 release, so for people who’d like to use the IEStorageProvider  with the 0.4.2 release, you can apply the patch above, or download the dojo/src/storage.js and /dojo/src/storage/browser.js files. Make sure to put them in the /src and /src/storage folders respectively.

All comments/feedback/bug reports welcome, just add a comment to this post.

Posted in Ajax, Dojo,, Flash, Internet Explorer, Javascript, open source, Technical | 3 Comments »

%d bloggers like this: