supersonic feet

I just uninstalled the DivX driver from my PC as it currently doesn’t work very well on Vista (slow and pops up with auth requests the first time you open a DivX video). On uninstalling, it opened a form in my browser asking for a bit of feedback on why I was removing the software.

This is good - it shows they might try and improve on whatever caused me to ‘leave’ and if I’m leaving due to minor niggles (yes in my case), I might now be inclined to check again in a few months to see if they’ve sorted it out.

So far, so good.

The first question had a number of radio buttons to choose from on why I uninstalled (bugs, just not liking it, etc.), but due to the wording none really fit, so I left them. Same with question 2 (’might I come back?’ I don’t want to bother answering that).

So I just fill in the last bit - a big textarea for my comments. I point out the Vista problems and that when they’re fixed I might reinstall.

Submit. Error pop-up tells me I must complete question 1. I bet they lose a good percentage of feedback there, but I’m not in a hurry, so I tick an answer and submit again. Pop-up returns telling me I must complete question 2.

Now given that the user is already presumably somewhere on the ‘upset’ scale, putting barriers in the way of them telling you why they’re upset and leaving isn’t good. If the textarea has been filled in, it’s much more likely to give actual useful feedback than a multiple choice question so let it go and ignore the others.
This is probably just one of those things that got overlooked, but if it was done right I bet they’d be getting much more useful feedback, or even some more useful feedback from people like me who just filled in the free text box with their actual opinion but then got irritated at the form validation and left (I did submit my feedback, but I’m a developer and know its potential use).

PS: I’m not just picking on DivX, just that theirs is the website I most recently (5 minutes ago) hit this problem with. It was a great idea to ask for my feedback, they just failed slightly in letting me give it to them.

At Gottabet, we’ve started to migrate the website to a cleaner, wider layout that I’ve been working on for the past few months. We started by launching a new homepage and a couple of weeks ago we trialled a new signup page (via A/B test) and then rolled that out for everyone. Yesterday we launched our new Bet Detail Page. This week I’m working on getting a number of the ‘basic’ pages ported over and after a great start hit one of the most frustrating IE6 bugs for some time.

On Gottabet we often absolutely position a ‘Bet on it!’ button over a bet image in listing pages - so it sits on a corner of the image. Most of the time this works absolutely fine - you have a div containing the bet image and the ‘bet on it’ link. The div is styled with position:relative and the ‘bet on it’ link is position:absolute, with the necessary top, left, right or bottom spacings for wherever it needs to sit compared to the image.

For the one page I was working on today though, it all went wrong. Very, irritatingly, wrong.

The problem: relatively-positioned elements on the page would move from their correct (effectively inline) position in IE6 and shift down a hundred pixels or so and right a bit. To confound matters further, I found that it depended on whether I refreshed the page while looking at the top or the bottom of the page in the browser. When scrolled to the top, the relative elements moved down on refresh. If scrolling to the bottom of the page and hitting refresh, on reload they’d be too high.

After searching for known issues with IE6 and position:relative, I found a couple of common problems that didn’t seem to apply to me: the peek-a-boo bug and hasLayout.

The hasLayout issue seemed close, but the div with position:relative was already triggering hasLayout thanks to having a specified width and float:left. The symptoms also didn’t quite match up (mine seemed much weirder). In the end, I resorted to what I should have done much earlier and set up a test page with an extremely stripped-down verson of the page content - only the bare minimum of the grid layout with no header/footer and only the CSS relevant to the part of the page that was breaking.

It worked fine. This was a good sign, because it at least meant there was definitely something causing the problem, so I started adding code (and the relevant styling) back in until it broke. Turns out a containing div had position:relative on its own, with nothing to trigger hasLayout in Internet Explorer. It didn’t affect the case where it was being used, but by the time it filtered down to the next relatively-positioned block things were going crazy.

After 3 hours (most of them going round in circles before I started the stripped-down HTML version - there’s a lesson), all it took was adding a width to that containing div to trigger hasLayout in IE and all was well once more.

So be warned: the hasLayout bug gets nastier when you have nested blocks using position:relative!