For those of you attending TechEd Australia, if you are interested in application compatibility, there are two sessions you won’t want to miss tomorrow (September 1, 2011):
Troubleshooting Application Compatibility Issues with Windows Internet Explorer 9
When your website doesn’t work with a new browser, what do you do? In this demo-heavy session we explore the primary causes of application troubles, take a deep dive into the compatibility infrastructure in the browser, and give you helpful tips and tricks to accelerate your application compatibility troubleshooting and remediation.
Troubleshooting Application Compatibility Issues with Windows 7
In this demo-heavy session we examine a series of case studies for troubleshooting application compatibility issues with Windows 7. Using this approach, we show you more about how Windows 7 works and how to think about and resolve application compatibility problems based on real-world examples. In addition, we demonstrate the tools you would use to resolve these issues.
(Note that my session will have 100% more wombats in it than the typical TechEd session.)
Don’t have enough cash to attend TechEd Australia? Well, if you were really looking forward to the app compat content, I’ve got you covered. Tomorrow night (Monday, August 29), I’ll be speaking at the Brisbane Infrastructure Group up in (not surprisingly) Brisbane. The talk will go from 5:30 – 7:30pm, and will be as interactive as you can make it. It’s going to be held at the Microsoft office at 400 George Street.
For more details, or to register, see: The AppCompat Guy Talks (a.k.a. Chris Jackson). I hope to see some of you there!
OK, so it’s not as famous as e=mc2, but here is the rule I apply for when to test an application for app compat.
You should test your applications when:
cost failure × probability failure > cost testing
You should otherwise not bother to test your applications – just fix them reactively through your standard helpdesk processes. From a business perspective, it just doesn’t make sense to pay more to avoid a risk than it would to just march straight into it and have to pay that fine. I mean, if I offered you a “get out of traffic court free” card for $1000, and traffic tickets cost $100, how many would you buy from me?
In my ongoing efforts to clear out all of the low hanging fruit and leave behind all of the fun, gnarly, nerdy problems, my latest article on TechNet Magazine was just published. This one addresses Internet Explorer 9 application compatibility, and avoids much of the nerdy stuff I normally focus on to instead focus on having a great process and approach which gets us more efficiently to the fun debugging at the end of the yellow brick road. Feel free to send me feedback!
http://technet.microsoft.com/en-us/magazine/hh360991.aspx
I haven’t done a recap post since TechReady 9 for some reason, but I figured it was about time to take a step back and think about the state of app compat presentations, and how I could continue to make them better.
At TechReady 13, an internal Microsoft conference, I presented 7 breakout sessions, but only 6 of those received at least 10 survey responses. here are the scores:
In order to make the scores relative to competition, I rank ordered them and placed the rank order here – absolute scores aren’t terribly interesting, particularly given the severe skewness of scores at technical conferences. (The average score at TechReady is around 4.5, meaning that any person who rates you a 4 instead of a 5 is technically rating you below-average.)
Here are my conclusions, based on this data:
People think I know what I’m talking about
That’s good to hear – the top row is notably better, and thus people think I have some sense of what I’m talking about. I hope they’re right… I’m also doing well in terms of demos. Presentation skills is a little lower than I normally expect – I wonder what the underlying cause is there?
The case study refresh is helping scores come back up towards the top
The original app compat presentations were based on demo applications, and these have been around for a while. At the beginning of the year, I did a complete overhaul, and moved from having slides and demos to instead having a few introductory slides (since I still get about 1/4 of the audience new to the discipline), followed by a series of case studies. That’s right, real applications that we apply tried-and-true debugging processes to. That, in fact, was the entirety of the Debugging session, where my friends Trey and Andrew just went through studies of how to apply WPT and/or WinDBG to solve real customer problems.
IE is the harder one here, as I have been using live public websites, and as more and more people use IE9, more and more of these get fixed. I mean, that’s great from a web ecosystem point of view, but it does kill my demos. I spend the morning before the presentation going over everything to make sure it’s still broken that day, and I’m still crossing my fingers!
I still haven’t nailed the conversational format
Scores are coming up on my idea to have a great conversation between product engineering, the Microsoft field, partners, and customers. At TechEd 2011 North America, I had a customer panel, and scores weren’t so great. So, I reimagined the session, and instead had a product engineering panel, where I brought in Eric Lawrence (who is the PM Lead for Fundamentals for IE) and Adrian Bateman (who is the PM in charge of coordinating our HTML5 standards efforts across all of our products) and set about asking the hard questions that I receive from the field and from customers, and left lots of time for audience participation. I had some fun with it, doing it up like a talk show, commercials and all. Scores came up quite a bit, but it’s still the bottom of my session list. So, am I just not executing it right, or is the concept flawed?
Some people are insane
Despite having two of the finest escalation engineers I know doing live debugging – including troubleshooting a problem that Mark Russinovich hadn’t found! – I still had 2 (two) people rate the debugging session a 200-level session. Really? You think 75 minutes of pure demo with nothing but assembly language on the screen is marketing?
I need to figure out how to refresh
Typically, I only see people once a year. So, truth be told, most presenters have a set of sessions they deliver throughout a calendar year. I did my refresh in January, and figured it would last through 2012. I mean, creating a pile of sessions is HARD – and there isn’t enough time to do a pile of new sessions every couple of months plus do actual work. However, with today’s recordings at nearly every session and every conference available for free, I’m starting to get a lot of people complaining that they saw this content from the previous conference. So, given that it is already hard enough to do significant overhauls once a year, how do I do that every couple of months in order to meet this expectation, but still satisfy the people who have never seen me and need the introductory content (which is necessarily somewhat redundant)? I think this is going to be the hardest problem to solve for folks gunning for top slots. I’m already throwing in a few new case studies each time, but there is a lot of carry-over today.
One query that comes in quite a bit from the IT Pro community around IE9 is this: what happened to the zone indication from the status bar? Zone information, for both the Developer and the IT Pro, can be pretty important. It determines the security context the page runs in, as well as the application compatibility defaults.
I was pretty curious about this myself, so I chased down the answer from the development team.
In the initial development work, two themes were really coming to the forefront in IE9: performance and user experience. As performance work was taking place, somebody discovered that the zone display was not terribly well optimized – displaying that little icon and text, as it turned out, took about 40 million CPU cycles. Now, in the days of 2.5 GHz processors (what have in my vintage T61p), that’s only 0.016 seconds, so not the end of the world, but that adds up. We cut the display and got the performance back, but moved the information (which was still important) over to the properties page, accessible from a right-click on the page.
Could we have optimized that code so it was way faster? Of course we could have – it’s just code. But the time we spent writing code to optimize zone information display is time that we’re not making the JavaScript engine faster, or time that we’re not making Canvas faster, or time that we’re not making the platform more robust. While it might have been a good use of time, it wasn’t the best use of time, and shipping is about trade-offs.
We then came along and cleaned up the UI even more by hiding the status bar by default. This takes away still more of the browser chrome, leaving more room for the site, which is really what you launch your web browser to have a look at.
And this, of course, sort of nullifies the original performance argument – if the information isn’t shown until you ask for it, then the performance is no more an obstacle here than it is on the properties dialog. (And you could argue that the status bar, by removing all of the information from the status bar except for zoom that it really probably should be called the zoom bar now.) Could we have put everything back after making this decision? Of course we could have – again, it’s only code. But once again, that takes time – time not spent doing other things which arguably help the web more than building back up the status bar. Once again, we had to make a trade-off. Given perfect knowledge of how the UI would evolve, I imagine we would have left it as it was, but just hidden it. Alas, we lacked perfect knowledge.
So, by having two good intentions (make it fast and clean) we ended up having to retrain folks on where to find a bit of useful information. It’d be great if we could take that back, but now it makes sense to me how we got there, and hopefully this adds some perspective for you as well.