The IE CSS Bug That Cost Me A Month’s Salary

//
I run a small business selling software (downloadable and online) which lets parents and teachers make bingo cards.  It is October, which is the busiest season on the educational bingo calendar, largely because Halloween is coming up.  Kids in school + candy-fueled frenzy + secular(ish) holiday + desire for fun activity = bingo bonanza!

However, due to an IE CSS bug, my Halloween experience is best described as “bobbing for poisoned apples”.

The Design Improvement That Wasn’t

On September 21st my designer and I got together and we created a new candidate design for my sign up and login pages, which are both critical to conversions for my business.   The intent was to A/B test the new pages against the old design.  One critically important niggle that didn’t bother me at the time: while ideally an A/B test would test exactly the old HTML against exactly the new HTML, for obscure implementation reasons we ended up testing the old HTML plus one little change versus the new HTML.

That one little change was replacing the old sign up button (the stock HTML form submit one) with a graphical button.  I thought this was such an obviously beneficial change that it was not worth taking on extra coding complexity to keep it the old way.  Stupid, stupid, stupid.

Thanks to the magic of subversion I was able to recover exactly the HTML that was displayed on my site after the upgrade.  (This is one of the two A/B alternatives but it is exactly identical to the other one in the area that is relevant.)  Feel free to open that in your browser and see if you can spot the problem.

At this point I have to mention that I generally use IE8 or Chrome, and my designer uses Firefox.  This means I had never seen the new version of my site in IE6 or IE7 until trying to do tech support from an Internet cafe last night.  (Being a proper Japanese salaryman, I had missed the last train and stopped at the cafe to answer customer emails prior to staying at a hotel.)

Whereupon I discovered a slight problem.  In IE7, the site looked more like:

New Version Of Site in IE7

Hmm, the signup form has no visible sign up button.  The log in form also had no visible log in button.

I started panicking but was in no position to fix the bug at 2 AM in the morning from an Internet cafe, although I made a game attempt to do so.  (Word to the wise: trying to fix a Rails application by editing files in vi through a web console to your Slicehost VPS is not recommended.)

How Well Do Forms Without Buttons Convert?

Answer: not well at all.

You can still submit a form by hitting the Enter button even if you can’t see the submit button.  This is, however, not standard user behavior in my niche.  Let’s see what that did to conversion rates.  Using custom segments (a power-user feature from Google Analytics that I’ve literally never had any useful purpose for before), I’ve graphed the conversion rates among IE8 users (orange line), IE6/7 users (green line), and the site average (blue line).

As you can see, IE6/7 and IE8 are pretty much neck and neck in the month before the bug is introduced.  This makes sense, as we would not intuitively assume those two user populations would be very different from each other.  You can also see that they both track the site average reasonably well, which is practically true by definition as IE users make up the majority of visitors on my site (about 65%, give or take).

Then, after the bug gets introduced, the conversion rates for IE6/7 take a nosedive relative to IE8.  The site average in blue also declines, solely because it is being pulled lower by the underperformance of the old IEs.

In concrete terms, the conversion rate of IE6/IE7 users was 3.40% after the bug.  (Note that this is not the conversion rate among people actually viewing the login/registration screens.  Google Analytics doesn’t let me conveniently break the numbers down for that.)  The conversion of IE8 users, by comparison, was 9.53%.  In other words, if you trust my intuition that IE6/7 users are about as likely to convert as IE8 users all else being equal (which you should, just by eyeballing that graph), then I lost about 64% of my conversions since September 21st.

Putting The Damage In Economic Terms

I’m a glutton for punishment so I’m going to do the painful math.  Between September 21st and October 23rd, when I fixed the bug, I had roughly $4,500 worth of sales, of which IE6/7 users comprised about $2,080.  Since the IE6/7 bug is essentially meaningless after you get through registration (since the overwhelming majority of users pick Remember Me and never see either the sign in or sign up forms again), I’m going to make the simplifying assumption that the bug ripples straight to my bottom line.

We can then use simple math to figure out how much the 64% of sales I threw away was probably worth.  Ouch, I am wincing as I type this: $3,750 in lost sales.  That unfortunately flows almost straight to the bottom line, since all of my major costs (advertising, hosting, etc) happen whether I make the sale or not — I probably lost in excess of $3,400 in profits.  That is more than my monthly salary.

How The Heck Do You Overlook That?

I wish I could blame Microsoft for my stupidity on this one, but aside from not testing the page in IE6/IE7 (which would have shown the bug immediately), I had ample opportunities to discover that there was a problem somewhere.  However, other things in the chaotic, fractally complex system that is a small business concealed them from me.

Indication #1: There are two types of signups on my site, trial signups (where I capture an email address) and anonymous guest signups (where I don’t).  Historically, I push the trial signups much harder, and my users signed up for them at a multiple of the guest signups.  (Guest accounts scarcely convert for me at all, which is why I don’t push them much.  However, an A/B test proved that removing the option didn’t increase the number of trials or paying customers, so I left the option in.)

Thus, when the mix of trial and guest users suddenly went from 880 : 350 to 792: 506, I should have said “Wait a minute, the guest accounts are getting much more popular.  Why is that?”  The answer to that is: Unsophisticated users, like the ones who make up most of my audience, will fill in their information and then see ‘Sign in as guest’ and ‘Cancel’.  Given only these two choices, clearly they want to ‘Sign in as guest’ rather than figure, “hmm, typically guest accounts don’t have usernames or passwords associated with them, I should email Patrick and ask what happened to the real sign up button.”

And indeed, I did see the explosion of guests on my stats, but I had changed the graphing option from showing daily counts to showing weekly counts, and the disparity wasn’t big enough to catch my sustained attention.  (The inflection point on September 21st is immediately visible on the daily graph.)  After considering the matter for a few minutes I said “Eh, Halloween is coming up, which always broadens my market.  Maybe it is bringing in some less interested folks.  Oh well, nothing to worry about.”

Indication #2:

I check my conversion rates on AdWords roughly once a week, largely because if they start to suffer Google stops running my ads and I lose a lot of money.  I then noticed that the numbers were below where I expected them to be (“Hmm, that’s funny, a few weeks ago I was getting 24 – 27%, now it is saying 18%… what is up?”) but I never ran the following graph to see the full range.

Yeah, just from eyeballing that, you can see the problem right?  Visualizations are wonderful for seeing problems that you already know to look for.  However, they are poor for informing you of problems that aren’t visible in the default visualization, since you won’t spend the time to slice the data to see the problem if you don’t know it exists.

Honestly, I don’t know why I didn’t immediately punch the panic button when I saw my AdWords conversion rates start declining.  Again, October always throws my numbers into a total mess, and I was very busy in my day job and in my various seasonal initiatives for taking advantage of Halloween.  So busy, in fact, that I offset most of the decline in sales, and so wasn’t given any advance warning by, e.g., having sales plunge to a fraction of normal.

Indication #3: What finally clued me into looking for this problem was a pattern in customer support requests, of all things.  As I mentioned earlier, guest accounts are historically rarer than trial accounts and they convert very, very poorly.  As a matter of fact, I think I probably had one sale to a guest account in history prior to the bug being introduced.

The code that I have which upgrades accounts in response to people paying me via Paypal and Google Checkout doesn’t handle guest accounts very well, because they’re anonymous.  It upgrades the account fine, but doesn’t register the email address they used for their payment with the guest account, which means the account still can’t log in after logging out.  (Since the guest account is still anonymous.)  However, since the system knows that the Registration Key issued to the purchaser is in use (on their guest account), if for some reason they log out or switch computers, they’ll be both unable to register a new account (because their Registration Key is in use) and unable to log into their guest account (because it is anonymous).  That is a pretty nasty Catch 22.

I’ve known about that Catch 22 for a while, but fixing it was not high on my list of priorities.  All of the following has to happen for it to actually bite a customer:

  • They start using a guest account.
  • They don’t give an email address when prompted by the fairly frequent upsells within the guest account.
  • They nonetheless purchase the software within their guest session.
  • They choose to use the online version of the software rather than the downloadable version (a not-insignificant portion of customers think the online version is the trial and the downloadable version is the “real deal” — well, if they pay me money, they can think whatever they please).
  • They clear their cookies.
  • They try to log in again.

Prior to the bug being introduced, I thought “This sequence of events is about as likely as flipping a coin and having it land on edge.”  And, indeed, it only ever happened to one person.  I fixed her record manually, looked at the code which caused the problem, and figured that an immediate fix was impossible.

<tangent>Why not just set their email address to the one the payment processor just gave me?  Well, Google Checkout has an option which it labels “Opt out of marketing email from this merchant” which, if the customer checks it, gives me an email address like “John.234982385@checkout.google.com” for them.  Obviously, my customers don’t know those random addresses, so using them for a login name is out of the question.  I was also worried that many people’s Paypal addresses are not the ones they use on a daily basis, so using them for logins was suboptimal, so I deferred finding a solution to the bug until later.  After all, it scarcely affected anyone, the cures were temporarily worse than the disease, and manually correcting their records was suboptimal but worked.</tangent>

Then I got emails from three people in the same day who were hit by the guest-purchase bug.  That was finally the eight sigma event that convinced me that my process was really, really out of control.  Whereupon I started investigating, beginning (fortuitously) with trying to log into my admin page on the site while on the Internet cafe’s IE7, and noticing that there was no login button.

Technical Mumbo Jumbo

If you’re a CSS geek, you might be interested in knowing why the buttons vanished.  Fair enough: the HTML input element had a background image specified and a text-indent:-9000px property applied to it, which puts the standard text for the button way off the screen, leaving only the background image visible.  However, IE6/IE7 treat text-indent as moving the background image as well, so the entire control essentially vanished, leaving empty, unclickable space where it used to be.

The fix was fairly simple.  I am truly indebted to Laurence at My Drupal Blog for posting about it.  He probably saved me an ulcer.  Essentially, I identify which browsers are using IE and then apply some sort of hacky stylings to make the background image display visibly, but cause the Sign Up text to be invisible by blending it with the background.  It is very hacky — sort of like patching a wound to your artery with duct tape – but you can’t be too choosy when you’re leaking over $100 a day and have the CSS skills of a vole rat.

On The Bright Side

I don’t want to give you the wrong impression: despite this very, very serious issue, my business has been doing very well in October.  The usual seasonal fluctuation, my seasonal promotions, and all the various improvements I’ve been making in the last few months will still make it my best month ever, and historically the last week of October sees a strong spurt in sales, so it might even be the best month ever by quite a margin.

I also got a much-needed kick in the pants to remind me to test all changes, even the stupid little one-line changes, in all the browsers my customers routinely use.  One positive lesson learned is that IE8′s compatibility mode reproduced this bug exactly, so that will be an easy way to do this going forward.  Ideally I’d have some sort of automated test suite set up to catch this sort of thing (using Selenium or what have you), but that isn’t in the cards at present.  At the very least, I’m going to upgrade my automated stats tracking put big red warnings on my dashboard when the business starts to fail sanity checks.  An obnoxious red warning about conversion rates would have caught this a month ago, within less than 24 hours of the bug going into production.

I hope you learned something from my experience, and am quite willing to take additional lumps in the comments if you have any suggestions for good ways of preventing a similar bug in the future. Happy Halloween!

No Responses to “The IE CSS Bug That Cost Me A Month’s Salary”

  1. Lorenzo October 23, 2009 at 7:43 am #

    Microsoft gives away VM with IE6/7/8 preinstalled so next time just install those:

    http://www.microsoft.com/Downloads/details.aspx?FamilyID=21eabb90-958f-4b64-b5f1-73d0a413c8ef&displaylang=en

  2. Tom October 23, 2009 at 7:44 am #

    Perhaps work a hosted cross browser test into your test process before you go live with a new experiment? I use http://litmusapp.com/. No framework to setup, just run it on a url.

    Sometimes you need to create a custom url, or stage a page with some JS to get it into the state you want to see, but it’s better than nothing.

  3. stakent October 23, 2009 at 8:28 am #

    Thank you for very valuable lesson.

    Why leave guest accounts at all if they generate one conversion per year? Maybe I’m missing something, but they make things more complicated and generate noise in you stats.

  4. Patrick October 23, 2009 at 8:32 am #

    I don’t generally see noise in my stats as a problem, certainly not a problem big enough to disable features for my users. At worst, it means I have to spend a little extra time thinking about stats collection when I set it up, which I’ve already done.

  5. mara October 23, 2009 at 9:03 am #

    Can you provide more details of the fix – a link perhaps – or better yet, an appendix with the actual code after the article? You don’t need to disturb the flow of your writing, just provide an easy way to get to the info.

    People are going to land on this page in the future searching for this problem and how to fix it. You are already intimate with what their frame of mind will be like. They’ll read all the way through to the end and wind up frustrated. Like I did.

    You TEASE!

  6. Joe Conyers October 23, 2009 at 9:28 am #

    Reminds me how important moving averages are for finding problems; another reason to make use of the Analytics API.

    Thank you for the lesson and write up.

  7. Browsera October 23, 2009 at 9:32 am #

    It would have been interesting to see if our new testing service, Browsera, would have caught this issue for you automatically. We have automated detection algorithms meant to detect these kind of problems. Do you still have the code so we can give it a try in our system?

  8. tuntis October 23, 2009 at 9:37 am #

    Very interesting story – thanks!

  9. Patrick October 23, 2009 at 9:48 am #

    Browsera: http://www.bingocardcreator.com/files/old-site/registration.html

    Fire away.

  10. ryan October 23, 2009 at 10:16 am #

    why’d you choose to use a background image on the input/submit?

    could you have just used an or ?

  11. Dan Lash October 23, 2009 at 10:17 am #

    You don’t even need a VM to test IE. This website allows you to run any browser instantly even if you haven’t installed it. Very valuable for cross browser testing.

    http://www.spoon.net/browsers/

    Also, you don’t have to go to such great lengths to style an html input button. This works well:

    Login!

    .button_with_background
    {
    background: url(/images/button_background.gif);
    }

  12. ryan October 23, 2009 at 10:18 am #

    oops. stripped the markup from my previous comment — could you have used a:

    input type=”image” or button type=”submit” instead?

  13. Dan Lash October 23, 2009 at 10:18 am #

    How about that, html didn’t come through in a comment … surprise!

    Take out the ‘.’s before using!

    Login!

  14. Dan Lash October 23, 2009 at 10:19 am #

    Ok one more time:

    button type=”submit” id=”btnSubmit” class=”button_with_background”
    span Login! /span
    /button

  15. some guy October 23, 2009 at 10:49 am #

    I can’t really feel bad for you at all here. why isn’t your designer (or you) testing your pages in all of your supported browsers? stats should not have saved you here, just very basic QA

  16. some other guy October 23, 2009 at 11:21 am #

    Hi there,
    I have followed your blog posts off and on. Generally when they show up on ycombinator. Thanks for sharing all your info over the months. Sounds like you have a great product in a great niche.

    From your post and from the page you showed, I have some advice. First of all, the page you link to in the blog post does not validate even for the transitional doctype that is specified. The most effective way to eliminate cross browser problems is to have your pages validate strict. It really isn’t any more work if you develop that way from the start. Once you know what you can and can’t do in strict, it is just as fast to develop and in fact having more rules about what you can and can’t do often helps to make the right coding decisions. If you aren’t using strict, IE will use quirks mode and the results will be unpredictable: http://www.quirksmode.org/css/quirksmode.html

    I have a hard time understanding why you don’t have a full browser test suite that allows you to test your site in all browsers, especially for the varieties of IE. This is your business and you are neglecting to test for something like what half of your customers are going to see. You need to do like what the guy above recommends by getting the VMs from microsoft. Personally, I have three VMs running in virtualbox where I can test IE6/IE7/IE8 plus some of the other browsers that run on windows such as chrome and opera. Every site that I have worked on has had issues that affect IE6 and IE7, often differently and has required extra testing and development to fix.

  17. The other guy October 23, 2009 at 11:53 am #

    I recommend getting: IETester.

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

    Neglecting to test a commercial website in all the versions of IE is no one’s fault but your own. Even though IE is evil.

  18. Phil October 23, 2009 at 2:38 pm #

    Don’t feel too bad, Google doesn’t test their sites with IE either (try surfing AdSense or AdWords with JavaScript error debugging enabled…)

  19. Pål Degerstrøm October 23, 2009 at 3:00 pm #

    That isn’t a browser bug, that’s a developer bug. If your developer doesn’t test everything in all the target browsers, find a new developer. If you’re serious about your online business, follow the suggestions of the other commenters and install the tools necessary to do the appropriate testing.

  20. Omar AlBadri October 23, 2009 at 3:17 pm #

    There are plent of tools and Library that you should have used prior:

    Have you seen the javascript Library that makes IE6 behave like IE7?
    http://dean.edwards.name/weblog/2008/01/ie7-2/

    Did you use products such as Browsera.com or other similar sites to test what it looks like in all browsers AND multiple resolutions?

    Failing to plan always means you plan to fail, with all the money you lost could have been solved by a little reserach and appropiate planning.

  21. Barry Melton October 23, 2009 at 3:33 pm #

    There’s a lot of noise in this thread, but I just wanted to endorse IETester as stated above. All versions of IE in a tabbable interface, in which each tab can be a different version of IE.

    It’s worth its weight in gold.

  22. Vineet Kumar October 23, 2009 at 4:13 pm #

    > I also got a much-needed kick in the pants to remind me to test all changes, even the stupid little one-line changes, in all the browsers my customers routinely use. One positive lesson learned is that IE8’s compatibility mode reproduced this bug exactly, so that will be an easy way to do this going forward.

    I think you had better re-read that first sentence again, then re-think that second sentence.

  23. Mischa October 23, 2009 at 4:48 pm #

    Hey — the way that I and a few other devs/designers that I’ve seen get around this is by wrapping the thing in a div, and doing the bg image for the div and the text indent for what’s inside.

    Also, I have a similar env to you (slicehost, rails, etc), and my rule for ie7/6 is this:

    If something is trivial, test it in w/e browser i’m using atm (ff/safari) and then deploy it. Then test it live in ie7 or ie6.

    If something is non-trivial, just keep ie7 or ie6 open ALL DAY (using wine and/or crossover) and use it as my main dev browser.

    Enough of my customers for my main app use ie that, as you mention, having shit not work costs lots of money.

    -Mischa

  24. Brian October 23, 2009 at 5:00 pm #

    My favorite alternative to this solution:

    [a class="submitButton" href="" onclick="document.formName.submit();return false;"]Login![/a]
    [input type="submit" style="display:none;" /]

    This allows the user to still be able to hit the Enter key and submit the form, while allowing for a fully customizable button through an [a] tag (excuse the brackets instead of less/greater than tags, they won’t show up in a comment).

    Hope someone finds this useful! Ah and don’t forget to put a display:block; or display:inline-block; on the [a] element so that you can give it proper height and width!

    Cheers!

  25. Keith Perhac October 23, 2009 at 5:37 pm #

    As the designer working with Patrick on this site, I feel absolutely horrible about letting this painfully obvious bug slip through. I’m usually very good about checking all my sites with IETester (Which many people mentioned above, is an amazing program), but somehow this page just slipped through the cracks.

    It’s always humbling when my designs get eaten up by ie6, and reminds me that we designers must be always vigilant against stupid mistakes and to always triple-check everything we design.

    As to why we were using a styled submit button instead of a ‘button’ image, we were planning on having a :hover mouseover effect on the button, but decided at the last minute that it would be better without it. (kind of like the submit buttons at the bottom of this form)

  26. Rob October 23, 2009 at 5:48 pm #

    As a long time web developer I learned this lesson years ago: Never, ever trust any version of IE to do ANYTHING right or consistently. It’s the worst browser on the planet by far and that’s including IE8. With Microsoft’s plans for IE9 being talked about on their blog, it’s easy to point out they are trying to catch up to where all the other browsers were 3 years ago.

    Never, ever, ever trust any version of IE.

  27. Patrick October 23, 2009 at 6:04 pm #

    Keith is, as is obvious from the above comment, a tremendously stand-up guy.

    Keith, don’t worry about it. We win some and we lose some. I got some good advice regarding places that will run a Selenium test suite in the cloud, so after I’ve spent a weekend on actually writing Selenium tests against the customer-visible functionality, this should be fairly easy to prevent from happening again.

  28. Dave October 23, 2009 at 9:19 pm #

    Ahem.

    http://browsershots.org

    Now you have no excuse for not knowing what your site renders like in all browsers.

  29. James October 23, 2009 at 11:44 pm #

    Let’s be honest…. there isn’t a single browser out there which is “bug” free… Actually, Opera is pretty good… I cannot remember a single website displaying incorrectly in Opera…

    IE 5.2 – IE 8, Chrome, Firefox, ect… they all have their own little problems which will get you if you don’t pay attention to them…

  30. Sir Snacksalot October 24, 2009 at 12:42 am #

    If you can code, write this well, and run a successful business, you should be making a lot more than $40,800 a year at your day job.

  31. Sir Snacksalot October 24, 2009 at 12:47 am #

    Sorry. I just read around your blog and realize you run this company as your day job. In which case, you are kicking ass with those sales, and will soon make a lot more than $40,800 a year. Keep it up.

  32. Dan October 24, 2009 at 2:54 am #

    I had to deal with the same bug once. Thankfully, for me it didn’t result in a financial loss, but it made my hate for IE grow even stronger. I’ve thought about sending Microsoft an invoice for all those wasted hours I spend on debugging HTML for IE(6).

  33. Chris October 24, 2009 at 4:40 am #

    Since you’re already using svn, why not do a quick checkout of the tag your releasing (or the trunk however you chose to do it), to a staging area to test.

    Also, virtualbox with an extra copy of XP is your friend. I wish IE6 would go away, but until it does, you probably need a vm sitting around with it on.

  34. Charles October 24, 2009 at 5:33 am #

    Thank you for the very informative post. Hopefully it was therapeutic to write.

    Also lots of solid info in the comments. Worth it despite the occasional brickbat.

  35. Rob October 24, 2009 at 11:24 am #

    @James,

    Yes, all browsers have bugs but IE and Microsoft ignore the standards. Although their CSS support is very good as of IE8 (finally – and the reason this problem wasn’t noticed – IE8 finally caught up with the other more modern browsers in that department) the rest of it is pure garbage and almost 12 years behind every other browser in standards support. There’s a reason it’s lost 35% market share over the last 5 years and it’s still falling rapidly. IE is a web developer’s nightmare.

  36. Nathan Wallace October 24, 2009 at 1:50 pm #

    Another great, honest and highly informative blog post from someone who is clearly a leading micro-entrepreneur. Thanks!

    It was disappointing to see the “how could you?” type comments above. All developers & site owners make this mistake at some point, but only the great ones have the discipline, insight and business skill to calculate the impact as you have done.

    I learn something from everyone of your blog posts and only hope that I can do half as much right as you do in your business.

  37. Mian Farhan October 26, 2009 at 3:30 am #

    Thank you for the very informative post.

  38. PhiLho October 26, 2009 at 6:19 am #

    Ouch! :-)
    What is amusing is to see some comments telling you that you should test in various browsers (at least, some point to useful resources). Obviously, you already learned your lesson, and you are kind enough to share this experience: most Web designers know it already, but such reminder is useful.
    Your designer knew it, actually, errare humanum est… :-)

    Thanks for the detailed analysis.

  39. Vivek M October 26, 2009 at 7:57 am #

    Hey Patrick,

    We have been working on Automated testing framework called Tellurium. It sits on top of Selenium but overcomes some of the problems found in Selenium… we can write some test scripts using Tellurium for you to do some automated testing… let us know

    Thanks,
    Vivek M

  40. Hedgie November 1, 2009 at 7:08 am #

    Uhm… I just thought I’d let you know: I’m STILL not seeing a sign-up button!

    I’m using Firefox on Debian Linux in high-contrast mode (admittingly not your target users’ platform). However, a simple () would never cause any problems on any platforms!

  41. Phil Newton November 4, 2009 at 6:56 pm #

    I made a similar mistake to this that only just fixed. I made a minor change to my site that broken a download form. After a few days of 0 conversions, I checked it out and fixed the problem. I’m still smacking my head.

  42. Greg Lambert November 2, 2010 at 6:08 am #

    I am really sorry to hear your news. Unfortunately, I am not surprised. We are working on IE compatibility and we had a real “corker” with a client. We analysed their primary website and found a number of IE8 related compatibility issues.

    The customer was surprised as they had not received any complaints. Upon further examination of the issues, we found that the Submit Button on the complaints page did not display under IE8. No wonder the number of complaints were so low. Noone could complain.

    And the issue was identical to the issue that you experienced.

Trackbacks/Pingbacks

  1. The IE CSS Bug Which Cost Me A Month’s Salary: MicroISV on a Shoestring | My Web Development Bookmarks - October 23, 2009

    [...] Read this article: The IE CSS Bug Which Cost Me A Month’s Salary: MicroISV on a Shoestring [...]

  2. links for 2009-10-23 | Digital Rehab - October 23, 2009

    [...] The IE CSS Bug Which Cost Me A Month’s Salary: MicroISV on a Shoestring (tags: webdev css analytics browser bug development ie) [...]

  3. Segementing Reports In Google Analytics to Gain Valuable Insights | Online Sales - November 2, 2009

    [...] recently published The IE CSS Bug Which Cost Me A Month’s Salary and in it details a problem in which users in MS Internet Explorer 6 & 7 were not seeing the [...]

  4. Dashboard Design For Metrics-savvy Software Companies: MicroISV on a Shoestring - February 9, 2010

    [...] Logins Today / This Week: This is my “one glance health check” for the business.  I have a rough idea of what these numbers should be.  If they go down far below that, I have broken the login button and need to fix it immediately.  If they go high above that, it must be Halloween.  If they stay flat I might have broken the login button close to Halloween. [...]

  5. How A Half-Broken Halloween Promotion Smashed Revenue Records: MicroISV on a Shoestring - November 1, 2010

    [...] I did a bit of extra work getting the Halloween promotion to work this year, and also automating/systemizing so that I’ll be able to exploit similar opportunities without needing to take time off to do custom coding.  Some parts of the strategy worked very, very well.  Other parts lagged expectations.  And, naturally, I managed to make a critical CSS error and cost myself a few thousand dollars in sales… again. [...]

Loading...
Free video + email advice on making & selling software:
(1~2 emails a week.)