April 2009 Blog Posts

I’ve been running builds of Win7 on my 1525 for some time after doing an in-place upgrade from Vista 32-bit to the Win7 Beta. We recently announced that we won’t support build to build upgrades from Win7 Beta to Win7 RC (which will be available to MSDN/TechNet subscribers tomorrow) I could either revert to Vista and do another upgrade or install from scratch. I decided to take the opportunity to move to 64-bit and since that’s not possible when doing an upgrade from 32-bit Vista I installed from scratch. Although all the hardware was successfully detected, this left me without some of the Dell utilities including things like the Wi-Fi sniffer and full scrolling support from the Trackpad driver.

There’s a useful post on the TechNet forums about which drivers to use on a Dell Inspiron 1525 if you want to upgrade from 32-bit Vista to 64-bit Vista or Win7 and this helped get me up and running. It turns out that some of the 64-bit drivers aren’t listed for the 1525 but address the same hardware on other Dell machines and so work just fine.

Digital World Clock

I like to have a couple of desktop clock gadgets so that I can see the time in different time zones without having to think about it. A while ago I found a gadget that I like but there are lots of clocks in the Windows Live Gallery and so I’m never sure if I’m picking the same one when I install on a new machine. Sure, I could copy the file locally and make sure I just install that each time but that pre-supposes that I have access to the copy when I need it. Instead, I’m going to bookmark it here and then I know how to find my way back. It’s the Digital World Clock – thanks SARWAR.

Technorati Tags: ,,
posted @ Friday, April 24, 2009 9:31 PM | Feedback (0) | Filed Under [ Windows ]

The Visual Studio and Internet Explorer teams discovered an issue affecting some of the code wizards in Visual Studio after installing IE8. Visual Studio hosts the browser control to implement the code wizards and the custom security manager that is part of VS doesn’t expect a request from IE about an URLACTION that wasn’t previously routed through the security manager.

The Visual Studio team have posted a workaround on their blog.

Technorati Tags: ,,,
posted @ Friday, April 3, 2009 7:28 AM | Feedback (0) | Filed Under [ IE8 ]

For as long as I can remember (I think going back to IE3), Internet Explorer has displayed a ToolTip containing the contents of the ALT attribute for IMG elements. Other browsers including Netscape 4 also showed the ToolTip. In IE7, this looks something like this:

tooltipIn IE8 standards mode, the ToolTip is no longer shown. This is a change we made to be more standards compliant, more interoperable with other current browsers, and to encourage more accessible mark-up. ToolTips are still shown in quirks and IE7 standards modes.

The problem comes because having the ALT attribute displayed as a ToolTip encourages two behaviours that aren’t compatible with the accessible web. The first is that content authors naturally enough set their ALT text to be something appropriate for a ToolTip but not ALTernate text to represent the image in scenarios where users can’t see the image. The second is that content authors actively don’t put alternate text because they don’t want a ToolTip displayed. Neither of these is desirable.

The solution for content authors is to use the TITLE attribute if they want a ToolTip. The TITLE attribute applies to other elements with the same effect and not just images. The ALT attribute should be used for text that’s an alternative to the image.

Technorati Tags: ,,
posted @ Friday, April 3, 2009 5:46 AM | Feedback (0) | Filed Under [ IE8 ]

Back in December, the Office Sustained Engineering team wrote a blog attempting to answer the question, “Why doesn’t Office just fix all of the bugs before they ship?”. In fact there description applies to any product from Microsoft and in fact products from many companies.

The truth is, even for a project working on a quality driven release, at a certain point someone needs to decide on the ship date and figure out working back from that how to lock down and stop making code changes. If you don’t do that then you’ll never ship anything. This reminds me of a conversation I had with a friend when we went snowboarding earlier in the year. The ski lifts have a closing time displayed on them after which time nobody else will be allowed to get on the lift and anybody already on will be allowed to reach the top. We discussed how the staff would have to be pretty strict on closing at exactly the time displayed or else they’d never be able to close. If they let through “just one more person” then, given that new people arrive back at the lift all the time, at what point would you say “enough is enough”. How would you explain to the person that you stopped that you really shouldn’t have let the previous person go either because, after all, it’s now well past closing time.

And so it goes with bugs. On any product of reasonable complexity, we receive a steady stream of incoming bug reports all the time, every day. Many of the reports relate to bugs that have already been fixed. Some of them relate to issues that are hotly debated where there are disagreements about if the product is supposed to work that way by design or not. And of course some of them relate to previously unknown defects. At some point you have to say “enough is enough” and after that point only really critical issues (such as security vulnerabilities) are serious enough to get fixed. This is a really difficult time for the engineering team. Most developers are at least partly perfectionists and no one wants to ship a product with a defect that could be fixed. Might even be easily fixed. At some point, the tough decisions have to be taken though.

The Office SE blog goes into more detail on this and other areas.

What about the bugs that were in the last release and the one before? They keep getting reported and you keep shipping without fixing them. It’s true that there are some bugs that survive past multiple releases. Sometimes they are things that where there’s a disagreement about what the correct behaviour is. Sometimes, though, they are just seen as low priority and a decision is taken not to fix them. Of course, every bug is the most important bug in the product to the person that reported it, but if there are common workarounds and perhaps the bug is only cosmetic and easy for a user to ignore then it may never make the cut and get fixed. Most customers would be disappointed if they bought a new version of a product and the only difference was a large number of fixes for minor issues they’d never personally run into. There is always a balance between working on new features/functionality and going back and fixing the gripes that a few customers have in less common scenarios.