Archive for February, 2009

User What? How to Alienate Your Colleagues with Live Meeting.

Monday, February 23rd, 2009

I am not a Microsoft basher, or at least I wasn’t until Vista stole a year of my life in its troublesome pre-SP1 version. However, my recent experience with Live Meeting 2007 has me questioning any remaining pro-Microsoft sentiment that I have been nostalgically harbouring.

It was a simple enough problem: set up a half-hour webinar and invite participants without publishing all of their e-mail addresses to everyone attending. With the Live Meeting plug-in, it even looked deceptively simple. The most complicated part appeared to be creating a distribution list to prevent individual e-mails from being shown. But it’s a steep, slippery, downhill slope from there.

The first problem is that Outlook creates a ‘dummy’ message for you to send to attendees. Users are supposed to realise that they can add their own text at the top of the message but the bottom part of the message, where the important details like telephone numbers and Web URLs go, will actually be entirely replaced when the message is sent. So, if you want to correct the phone number (the one supplied had a superfluous zero) or add details for local numbers in other countries, you can just type it all in and then have it discarded without notice. Simple huh? Happily, I discovered that in a test meeting I created beforehand.

For the real meeting, participants were signing up over several days. The initial invitation went out correctly but on opening the calendar entry to add further recipients, I discovered the distribution list was gone, having been replaced by a list of individual e-mail address.  What’s a user supposed to do at that point? Update the distribution list or the calendar entry? I may never know if I guessed wrong, but when I started getting two or three separate acceptance e-mails from participants, I suspected that all was not well.

On checking my Live Meeting account, I discovered to my horror that there were now three separate Live Meetings: the original, plus one for each time I updated the attendee list. They had separate meeting codes, so what would have actually happened on the day is that the lucky attendees who were invited first would get to see and hear about card sorting in its full glory, while those in the other meetings would be in an expensive state of limbo (since the calls and webinar connections were all being charged for through Live Meeting). The only remedy was to send an apology to everyone, cancel all the meetings and start again from scratch.

It may be that some of these problems were caused by the Live Meeting plug-in for Outlook as it’s hard to guess how this functionality is divided. What I do know is that if I try to send invitations from the Live Meeting website, I get precisely the problem I wrote about in my last blog entry: the Microsoft server pretends that it is sending e-mail messages from me and it isn’t authorised by our Sender Policy Framework (SPF) to do that. So any e-mail server doing SPF checking will reject the message as forged. And since the Outlook-based e-mail invitations work so badly, I had to devise my own mail merge and calendar entries to be certain that none of this was going to happen again.

It is almost as if some parts of Microsoft have never heard of user experience. And they’re not the only large organisation with this problem. But they really, really should know better.

Be my Sender Policy Framework?

Saturday, February 14th, 2009

My wife and I expected to find each other’s e-cards in our inboxes this morning, it being Valentine’s Day. (Yes, I know they’re not very romantic but they are inexpensive and environmentally sound. Besides, we’ve been married for quite some time!) However, we found personalised Non-Delivery Reports instead. It is a problem that I have come across with quite a few websites attempting to send e-mail on behalf of a customer. The sites fail to take account of something called Sender Policy Framework (SPF). This is an extension of domain name information to include a list of computers that are allowed to send e-mail for a domain (see Wikipedia and the SPF web site.) So, for our fairly small domain, we list our two servers plus the system that hosts our website. If you receive an e-mail from us and have some form of SPF checking, your e-mail server can look up our domain to check that the computer that sent the message is actually allowed to. And therein lies the rub.

The Hallmark.com website, amongst others, pretends that the customer is the sender of the message. However, a check of the SPF data for that customer will alert the receiving e-mail server that Hallmark is not actually a valid source of e-mail for that address. I raised this problem with Hallmark last year and they appeared very eager to fix it, but regrettably have not managed it as yet. So, instead of confirmations that our e-cards had been read, we each received a report that Hallmark.com is not a valid source of e-mail for our domain.

SPF is quite a useful tool for reducing spam, but only if it works. Unfortunately, it will not work if organisations sending e-mail on behalf of others completely ignore it. Certainly Hallmark and other e-cards vendors need to be sensitive to this since non-delivery can be a serious embarrassment. (I am hoping to still be married by the time you read this!) But, news, social networking and similar sites need to deal with SPF intelligently.

The joy of Plesk

Monday, February 9th, 2009

I was as surprised as anyone to discover last week that my blog, admittedly underused, had disappeared from our website. We have our own WordPress installation and like an increasing number of organisations, this is hosted on a Virtual Private Server (VPS) where we share the resources of a UNIX/Apache server with about 50 others.

To try to make the VPS idea workable for mere mortals, our hosting provider uses a product called Plesk. This is a graphical interface for setting up clients, websites and domains for each VPS. At first sight it appears very pretty and fairly well organised. Unfortunately, its attractiveness is literally skin deep – it is a “thin” interface on top of a set of fairly complex underlying technologies.

And therein lies the problem with the disappearing blog. I was foolish enough, when trying to resolve an unrelated problem, to click on the Updates icon. After some wrestling and heart-stopping moments where I was informed that the update on my remote virtual server had failed and it may therefore be inoperable (they were only kidding) I finally managed to get the latest version of Plesk installed (9.0.1). Unfortunately, this didn’t actually solve my problem and left me with missing icons in the graphical interface (wherein lies another story). However everything else seemed to be working.

Then the panic set in. A week later, clicking on a link to my blog produced only a message that the MySQL interface had not been installed. This is an essential component for WordPress and had certainly been present earlier. Not only that, on examining the status of the MySQL database for the blog in Plesk, I was informed that no databases existed. Indeed, even as you read this blog Plesk insists that it does not exist. (Perhaps carrying virtualisation a little too far!)

The problem is not a new one for user interface designers. In this case, the relatively lightweight Plesk GUI had its own ideas about the state of the system, and was not robust enough to carry these forward through a major upgrade. On using the PHP tools for managing MySQL, I discovered that the blog database was indeed present and fully functional. The problem turned out to be that in the process of upgrading PHP, Plesk had defaulted the configuration to exclude MySQL functionality. A one line change to the PHP configurations file fixed this, but as you can imagine, the overall user experience was not a happy one.

If nothing else, this does serve as an excellent example of the perils in oversimplification. There were many aspects of the underlying system that Plesk was trying very hard to hide, but at the expense of considerable confusion when problems occurred. Maybe Parallels (the developers of Plesk) will eventually put in the effort required to make the interface work for the intended semi-technical audience. But until they do, it is not for the faint of heart.