Browser Behavior Audit: Mailto: links

I don't run a desktop mail client any more at home. I'm sure most users don't. It's because of this that I have no default mail client installed. Occasionally I click a mailto: link. Maybe I want to email someone from their contact page, or sign up for a mailing list.

I was a little surprised when I tried this in Chrome and nothing happened. No error, no dialog, no beep. NOTHING.



Let's do a quick audit of the current browsers:

Chrome 10: nothing happens. This sucks.

IE9: Error dialog:

This sucks, but at least it tells me.


Safari (latest as of this writing):

Similar to IE9...

Opera 11:

Much better. However, if I choose system default, nothing will happen once I click on links. It at least prompts me with options though - it receives a passing grade. Note: Gmail is not currently a web mail service option, or I would be more excited that it offers "web mail service" options. The built in mail client is nice, though, so it is a valid option.

Firefox 4:

Gold star Firefox. Gold. Star. Firefox not only prompts me, it has a gmail option. I'm already logged into my gmail in my browser anyway - if I am, it will directly open a compose mail for me. If not, it will bring me to a gmail login page. GIANT HIGH FIVE!!! Usability Win!

I was so delighted to see this screen with a gmail option, I drew a trophy for Firefox 4:

My drawing skills are lacking, but Firefox 4's user experience skills certainly aren't. I'm impressed. In fact, the more I toy with Firefox 4, the more I like it.

We live in a webmail age - I bet most people don't have desktop mail clients any more. Why is such basic functionality seriously lacking? Does nobody ever click a mailto: link? (I admit I only do so a couple of times a year). It may be a minor qualm, but I expect these types of simple usability cases to just work.

Port test websites rock

So you're at home, and you want to connect with a friend online. Maybe it's some Minecraft and you start your own server. Maybe it's an XMPP server for a little pair programming with Saros. Whatever the case, you've likely got multiple barriers to success. Your OS firewall. Your router firewall. NAT.

You try one thing, then hope it works. Then try again. How do you know it will work? An external port tester.

That's when a website like http://www.canyouseeme.org/ comes in. It will check if your port is open from the web or not, and save you time. Saving time is good. I think in the future routers should offer this functionality themselves. Let me pretend I'm outside, and I'll tell you if I can reach you. That would be sweet.

Hyper-V Server 2008 R2 Remote Disk Management from Windows 7 on a Domain

I'm in the process of migrating a build machine to a Hyper-V Server 2008 R2 SP1 setup. I'm relatively new to Hyper-V, and may also be comparing with other options. The Hyper-V Server is joined to the domain, all standard remote management options from the console are turned on. I could connect with the Hyper-V Manager from a Windows 7 machine fine, but could not remotely manage the disks in Windows 7. I read this post and here is what worked for me.

On the connecting machine, Windows 7, I had to add the following firewall rule:

netsh advfirewall firewall set rule group="Remote Volume Management" new enable=yes

Remote management of Services was working, and I had enabled Virtual Disk Service on the Hyper-V box. Following a reboot, I could finally manage the disks remotely.

Prior to this, I believe any servers on the domain could manage them - just not my Windows 7 workstation.


This is only the beginning of my hypervisor adventures, as I try to convert 10 physical build machines running Jenkins masters into a fully virtualized fleet, double the amount of builds that occur, and centralize to 1 hudson master. I'll try to chronicle my findings here on this blog.