Windows Live Quantum Mechanics : Rants

My Content, My Tags

dthorpe — Wed, 16 May 2007 20:36:16 GMT

Tagging online content with categories or keywords is a great idea. I love GMail's use of labels instead of folders. I tag all my Flickr photos six ways to Sunday.

What I'm not so excited about are sites that encourage others to put public tags on my stuff. Who are these people? And no, stupid, that photo is not a parrot, it's a penguin. I should know, I was there!

This sums it up quite nicely:

Avoiding Popup Blockers in Your Web Apps

dthorpe — Wed, 16 May 2007 00:51:39 GMT

Tim Heuer laments the growing number of otherwise reputable web sites that instruct their flocks to disable popup blockers in order to complete some task within that web site.

Having stumbled into popup blocker hell myself only a few months ago with the Windows Live Contacts Control I can certainly attest to how easy it is for the blissfully ignorant (me!) to get snared by a popup blocker. However, I agree with Tim that popup blockers provide a valuable service and disabling them should not be part of anyone's standard operating procedure, especially when the target audience is the non-technical consumer.

When a web site asks you to lower your shields in order to complete an online order or do some other mundane task, it seems a little odd. But when you consider how easy it is to avoid tripping popup blocker alarms, asking the consumer to disable them is just plain sad.

The purpose of a popup blocker is to block popup "spam" - windows that pop up without the user's consent or request. Some of the more irritating sites throw up dozens of popup windows all at once, leaving the viewer lost in a forest of trash. Some toss up a popup window when you leave their site.

Why do the popup spammers do it? To artificially inflate their page view counts. A browser popup window showing a particular HTML page counts as a page view, whether the consumer is looking at it or not. Most banner advertisers consider that action a form of click fraud, and at a minimum grounds for termination of your ad serving account.

Here's the deal: Popup blockers in web browsers don't block all popup windows. A popup window that is opened in direct response to a user action, such as a button click, will not trigger a popup blocker alarm. If you do a window.open() in a JavaScript button click event, the window opens without issue. If the same code executes in a timer event, it will trip a popup blocker alarm. Why? Because a timer event is not the direct result of a user action.

The same goes for page loads, page unloads, XMLHttpRequest events, or anything else that is not a direct user action implying consent. Mouse clicks are user actions. I haven't tried this, but I'd be willing to bet that mouse hovers over an HTML element do not qualify as a user action. If anything, waiving the mouse around on the screen indicates indecision!

Different popup blockers have different degrees of sophistication in how they determine whether a window.open() is happening in response to a user action. Some may tolerate a call to window.open() being made in a subroutine called by a click event, but for best results across the board keep the window.open as close to the click event as possible. Meaning: keep the window.open in the click event itself.

We tripped over this in the first iteration of the Windows Live Contacts Control's WriteAPI. When a third party web app submits contact data to the Contacts control, we need to make sure the user is aware of what the third party app is doing, so we need to show the submitted data to them and ask for their approval of the action. There isn't enough screen real estate in the control itself to display the potentially large data, so a popup window is justified.

Let's say the user clicks a button on the third party web page to send data into the contacts control. The web app calls a method on the Contacts control, which is actually JavaScript from our library executing in the context of the third party app. Our code sanity checks the data, then bundles it up and tosses it over the domain barrier to our code that lives inside the Contacts control iframe, hosted on a Microsoft domain. Our code on the inside checks the data again, then opens a popup window to ask the user to review and approve the submitted data.

That's where we got caught - the JavaScript code opening the popup window was not directly tied to a user click. In our minds it was the direct result of the user click, but in the reality of the browser there were far too many call frames and other indirections between the user action and the window.open for the popup blocker to determine a causal relationship between them.

One solution that came to mind (very briefly) was to display the confirmation popup window from our code that executes in the context of the third party web app. This has many problems, not the least of which is that we cannot trust code that is executing in the third party domain context. We can only trust code that executes in the context of our own domain. Besides, given that our code would still be at least one function call removed from the actual user action event, this approach is likely to fail with less sophisticated popup blockers.

Our solution? Display a message inside the Contacts control to inform the user that data had been received from the web app, and prompt the user to "Click here to review the data". This solution has the downside of introducing an extra user click into the chain of events, but that click is what enables us to display the popup window from our JavaScript running in the context of our Microsoft domain without offending the popup blockers.

So, we should allow some measure of understanding for a web app that stumbles into popup blockers unexpectedly. The web developer is only guilty of a little ignorance and lack of testing.

But a web site that actively instructs you to disable popup blockers to use their site? This is where making ignorance into corporate policy has become easier than understanding the problem and its usually trivial solution. Show them no mercy!

Why More Websites Don't Support Opera

dthorpe — Tue, 07 Nov 2006 20:43:00 GMT

Two words: No debugger.

Part of our charter here in the Windows Live team is to support as many browsers as practical. I'd received reports that our Windows Live Contacts control doesn't do much in an Opera browser, so in the calm following the signing off our most recent "sprint" I indulged in a diversion to trek off to Opera land to install their latest incarnation.

It's a great looking browser - slick UI, slick PR packaging, slick photos of monochrome Scandinavian 20somethings suffering from incurable coolness. And red hats. For a browser, it does what it needs to do well - it browses.

When a JavaScript app throws an exception or blows chunks, the Opera error dialog is definitely a step up from IE's typical vagaries. Instead of something like "Object doesn't support this property", Opera will tell you which object and which property, and which line number, and so forth.

But what do you do when your JavaScript code doesn't fail badly, and doesn't succeed? A spiffy error dialog is only helpful when there is a fatal error. How do Opera advocates debug program flow logic and other intangibles in flight?

I couldn't find a debugger in the Opera options or add-ons, so I looked in the FAQs and questions on the Opera community forum. No dice, other than an item in the FAQ heralding Opera's error dialog as infinitely better than IE. It's true, it is a much better error dialog. But an error dialog is reactive, and after the fact. A debugger is proactive, and lets you look around inside the box. You can learn more about a program's actual execution in 5 minutes in a debugger (with an inspector window / expression evaluator) than in a week of staring at source code. Diagnosing problems by looking at source code is speculative, based on your assumptions about the execution environment. Diagnosing problems by looking at them execute is as close to touching binary reality as we're going to get.

So I created an account on the Opera community forum to ask the question.

(Curious: the Opera community account creation confirmation email to my Microsoft email address never arrived. The confirmation to my home address arrived in a matter of minutes. Is that an Opera filter banning messages to Microsoft or a Microsoft filter banning messages from Opera? I can't tell from this end.)

The response? Opera doesn't have a script debugger. Opera advocates recommend strewing alerts or output statements throughout your JavaScript in order to get a picture of how execution flows through your code. The phrase "put an output statement after every line of code you're interested in" was actually uttered.

That's nuts. What would normally be a 5 minute spelunk through the code in any serious browser suddenly becomes hours of crawling around in a haystack. I'd love to add Opera to our list, but it's not worth that much effort. Omission of script debugging support may not be a show stopper for hacks working on small apps, but it definitely presents an obstacle for large, complex web apps. Without a script debugger, Opera does not scale.

All hope is not lost, though. I know Opera gets lost somewhere in the Atlas initialization. Perhaps the Atlas team has a newer build we should be using, or some other opportunity to divert / share the pain of diagnosing this Opera issue.