Communicator phones sneaking out

When Microsoft first announced the Unified Communications strategy & partnerships last year, one of the pictures that was shown off was of a prototype “Communicator phone” – a networked device which could be used to make phone calls through the Office Communications Server, and would show the presence of the user’s list of contacts, as held on OCS and normally manipulated through the Office Communicator client.

I’ve had a play with one of these prototype devices (courtesy of Mark Deakin) and although it still has the air of an unfinished product, it’s a really interesting idea – sign in to the phone and see the presence of all your contacts, or search the AD directly from the phone so you can dial people by name rather than a number.

I saw a slide the other day with a photo of a device that Polycom is building – and came across the same picture on Tom Keating’s blog too… it’s starting to look very interesting device-wise. Word is, further details will be available soon, so watch this space…

Thread Compressor for Outlook – do you want it?

Here’s an appeal – nearly 8 years ago, I wrote* a little COM addin for the-then new Outlook 2000, which “compressed threads”. The idea was that it could take an email thread (eg a discussion over a period of time and a number of responses, from any number of people, and typically sent to a distribution list for the purposes of discussion), and compress that thread down to the salient points. It has evolved over a few iterations since but has been largely dormant for the best part of 5 years – it does everything I need it to do, so I’ve never developed it any further (and if truth be told, a hard disk crash blew away the source for the last version and I could never face going back to a previous beta and re-developing the changes I’d made).

I’d like to understand if anyone else would like it.

The basic assumption with Thread Compressor is that when people reply using Outlook, they tend to add all their comments at the top – some do inline replies, but most eschew that – and don’t edit the original contents. If this assumption holds true, then it would be possible to compress all discussion threads down to only holding onto the final email or the final post (to a public folder) since it will contain the entire history of that branch of the thread. Of course, there may be multiple branches of the thread, and Thread Compressor handles that.

The first time many people run TC on a large folder, it will routinely get rid of 50% or more of the content, so proves useful in slimming down folders where you archive stuff, or folders where distribution list contents are sent by Outlook rules, never to be read but to be indexed by Windows Desktop Search or similar.

In my last run, I scanned almost 1Gb of email and the Thread Compressor discovered about 21Mb of mail which could be removed… not quite as dramatic as 50%, but it saved me reading over 1,000 emails and it reduced my mailbox size a little…

There are a few obvious benefits to thread compression…

  • It reduces the size of your mailbox, so keeps you under-quota
  • It removes spurious email so you have less stuff to plough through
  • When searching, it reduces the number of hits since it won’t return every mail in a thread which contains the same word(s)

… but some obvious potential downsides…

  • The assumption at the top of this post. If I reply to someone’s email, but change the contents of their original message in the reply, then TC will retain the modified version and it will look like the originator really said that. There may be ways to work around this limitation now, but I never bothered to figure them out.
  • Legal compliance – maybe you need to keep a copy of every mail for compliance purposes: if so, users programmatically deleting messages could be a *bad thing*.
  • erm, can’t think of any/many more…

If you think this kind of functionality should be either built into Outlook or available as an opt-in addon, then please let me know. We have many thousands of regular users of Thread Compressor inside Microsoft. It would be cool to think of millions more outside as well…


* The really smart bit of TC was actually put together by a guy called Peter Lamsdale. All I did was take his algorithm – which I still have difficulty understanding much less explaining – and strap a UI around it. An earlier version of TC was published (unofficially) on a website and an article was written about it by Evan Morris. There is even an unconnected MSDN bit of sample code which is nowhere near as effective (IMHO)

Blackberry outage – worrying for mobile mail junkies

I just read news of an 11-hour outage in RIM’s Blackberry infrastructure on ZDNet – ouch. Not only did email stop flowing to the devices during the outage, but the backlog of mail which built up is taking time to clear.

Without wishing to gloat (really), users of Windows Mobile devices for push email wouldn’t suffer something like this (with the possible exception of their mobile carrier having a major network outage, which would affect Blackberry users as well and would be unlikely to last so long). Once you’ve deployed a real mobile mail solution, having any kind of serious outage is a worrying thing – especially if users are giving up laptops in order to rely on their mobile devices…

There are some architectural documents which outline the approach to using Windows Mobile and Exchange – such as the one in the Deployment Guide.

If you’re interested in how Direct Push works, you’d do well to check out these posts on the Exchange Team blog too:

Outlook 2007 update – performance improvement on large PST/OST files

I’ve been beta-testing this update for a little while and it seems to make quite a difference to the performance of Outlook 2007 (especially at startup) when you have large PST files, or a large offline cache of a mailbox. The Outlook team released it live, yesterday.

I’d highly recommend giving it a go – it’s one of those updates where you might not really notice much positive improvement after you’ve installed it, but you do notice that there are less of the times where you notice there’s a performance problem 🙂

The day I met Tony Blair, talked about online healthcare

I am feeling under the weather at the moment.

Been off work for a couple of days with what seems to be some kind of chest infection. I finally decided to stop waiting for it to go away on its own, and went to see the doctor – starting by looking at the website of the surgery, since I’ve moved house in the last year and haven’t had a need to register with the new place yet.

Just as a precaution, I went off to NHS Direct to see what was wrong with me – they have a wizard that asks you about the symptoms you might be experiencing, after you give it a steer. So I thought, “Breathing difficulties in Adults”, yep… then filled out the next set of answers… 

Now my lips aren’t blue (as far as I recall), I can talk OK but now and again do have a bit of a wheeze, so that sounds about right..

YIKES. Anyway, I’m pretty confident I’m not in the midst of a heart attack so I’ll ignore that advice for now.

Having a look around my doctor’s website, though, it turns out they are now offering appointments which can be made online. Now that seems like a great step in the right direction for busy people. It set me thinking about the time when the UK’s Prime Minister, Tony Blair, and his wife & entourage, dropped in to see us in Microsoft UK.


The Blairs visit

This was in the run up to the June 2001 election, and the Labour Party had asked if Tony, Cherie & co could come and see us on the day they launched their business manifesto. Of course, Microsoft said yes, and went ahead arranging an event in our central atrium where we would do a few demos to the PM and Mrs Blair, on some forthcoming technology (Office XP) and some future directions stuff.

I was asked to do one of the demos, and with a colleague concocted a mock-up of a system that might be imlemented some time in the future, but in this case was using a Pocket PC with Wireless LAN (then a PCMCIA card in a Jacket that clipped to the back of a still-shiny Compaq iPaq).

(that’s me at the bottom in case you haven’t guessed)

The demo was a little app which a health visitor might use if doing a home visit to a couple with a new born baby, notices the baby’s a bit off-colour. The app would:

  •  issue a prescription of the appropriate medicine
  • let the parents chose which pharmacists they’d like to have the prescription details sent to automatically (advising back when the prescription would be ready for collection)
  • arranged a date of a follow-up appointment with a doctor at the surgery, based on their availability and the parents’ preference of time.

SIx years ago, this might not have looked like rocket science to IT people but could really change the way healthcare is delivered. Now, it looks like a straightforward thing to do technically, what with advances is size and power of mobile devices which would be 3G connected or similar.

I stepped through the wizard on the device, which was being shown on Plasma screens all round the place, and the deal was that I’d give the device to Mr Blair at the end of the wizard, so he could sign the prescription (as the parent, obviously – at this point, the Blairs had a fairly young baby themselves, so that scenario seemed plausible).

The trouble was, in order for the signature to be visible on screen, I had to remember to tap in a specific place (to set the cursor at the right point, actually) and in the nerves of the situation, forgot – so I handed the PM the device, asked him to sign, which he duly did with a flourish… but nothing came up on the screen. He did look a little bemused (and smiling) while handing the device back, but said nothing … he’s either a total pro, or had literally no idea what was going on… I’ll leave the judgment to yourselves 🙂 I just mumbled something about the signature being secure etc, and moved on quickly…

Anyway, the visit seemd to go well, and the whole demos were broadcast live on Sky News (where the news presenter said, on coming back to the studio after my piece, that he felt sorry for the PM after receiving “an ear bashing like that”!) There was a little negative commentary from the usual places, but otherwise a day to remember – for me at least, if not for the guests of honour!

The Design of Everyday Things

In part 2 of my book post about design (part 1 was earlier this week), I’ll revisit an old title which is still great reading for anyone interested in cognitive theory or design. It was written by Donald Norman, and first published nearly 20 years ago as “The Psychology of Everyday Things“. The author found that bookshops & libraries tended to lump the book in with all the psychology textbooks, so a later edition was re-released under the modified title of the Design of Everyday Things.

The book itself looks at lots of good examples of where a designer has clearly thought about a problem and taken account of it in the design, but the more interesting (to me, at least) cases are where the usability of a system is so totally shot just because the designer didn’t take a simple thing into account.

Examples of the kinds of scenarios that Norman deals with are cookers where the layout of controls for the burners is different to that of the burners themselves (eg the burners are 2 x 2 but the controls are in a line of 4 – very common) or light switches which seemingly bear no resemblance to the layout of the lights they operate. I’ve lived in houses for years, and still kept getting the switches in the hall round the wrong way, so I know where he’s coming from there. In fact, in my house right now, the left hand switch operates the lights at the right side of the room and vice versa – I really must get round to rewiring that switch one day.

My favourite examples in the book are of the humble door, however. Here are some example photos I’ve taken on a camera phone (my new Orange E600, a version of the HTC S620 which Darren recently raved about).

The first 2 pictures are of a fire door in Microsoft UK’s TVP campus; the point about design here is that there are no instructions on the door about what to do. If you walk up to a fire exit door, for example, and it has a horizontal bar across it, you would be drawn to grab it and do something – quite possibly pull on it, but when it doesn’t move up, you’d push, and the door would open.

Similarly, when you walk up to a door which doesn’t have any handles, the only thing you can do is push, so that’s what you’ll do, right? 

To make it a little easier, a good designer would put a plate of some kind on the door, to underline the fact that there isn’t a handle for a reason (ie it hasn’t fallen off or anything).

Conversely, when you see a handle, you’ll instinctively grab it and pull. So a well designed door will have a handle on the side that needs to be pulled, and nothing (or a plate) on the side that’s pushed.  The only other marks on these fire doors are signs saying that the door is to be kept closed. Interestingly, they was part of the original Thames Valley Park campus which opened in 1997.

Now if we move to a newer part of the campus, there are nicer-looking glass doors, but their design is less clear – there are handles on both sides which look swish, but offer no affordance – ie they don’t give the user any clue which way the door is going to open. Maybe you could look out for hinges or the likes, but it’s very common to see people walk up to a door and pull it when they should be pushing.

To try to avoid that confusion, the door company puts a little sign saying “Pull” or “Push” on the door – something that still evades many people’s attention, a bit like The Far Side cartoon of the School for the Gifted.

Here are just two examples…

Even the old part of campus has plenty of glass doors, but they are designed correctly. Evidence:

There is nothing on this door other than the furniture – a piece of design which looks good, doesn’t have anything superfluous, and yet is easier to use than the more fussily “designed” items.

It’s books like DOET which give you a new perspective on the mundane things you’d not normally notice, and as a result, are well worth a good thumb through even if not an exhaustive read.

When interaction design goes bad

For various reasons, I’ve been testing & driving several different cars lately, a process I quite enjoy – getting to know the foibles of the car’s cockpit, playing with the various toys and gadgets, as well as actually learning how to drive each one according to its size, performance etc. It’s really pleasing to find a well thought out design in some bit of car UI (Audi’s MMI system is just sweet), but even more frustrating that some companies can spend $100ms developing a car but overlook some really basic functions which will just make the driver crazy (like the clock which looks very smooth and lovely but has no obvious way of adjusting the time… I’m currently driving around in a loan car which is 1 hour adrift of real time because I haven’t figured out how to move the clock forward to Daylight Saving Time, and haven’t yet gotten around to RTFM).

Thinking about all of this reminded me of two great books which, if you’ve any interest in design at all, I’d highly recommend. I’ll do this review in 2 parts, this one being, as it is, part one.

The Inmates Are Running the Asylum: Why High-tech Products Drive Us Crazy and How to Restore the Sanity

The Inmates Are Running the Asylum: Why High-tech Products Drive Us Crazy and How to Restore the Sanity Alan Cooper

This is a fascinating book which talks about the doom-laden scenario of everything we use being computer controlled (and since the book was written around 10 years ago, shows a fairly decent grasp of the future, some of which has already come to pass), discusses the design of User Interaction, and a model which Cooper has used successfully for a number of years, centred around “Personas”.

Note the use of the term User Interaction as distinct from User Interface (UI)… in this case, we’re talking about the whole way that people interact with a system or device, not just the UI of the software – extending the user interaction model to include only as much information as required, without being stupidly modal (eg the same button doing different things at different times based on what mode a device is in, especially bad when the device doesn’t make it obvious what its mode is).


A great example of good user interaction is the iPod – good UI in software, but it works so much better because the device complements it totally. Bad user interaction design is evident in many remote controls – they have lots of identical buttons with confusing labeling (what *do* all those symbols mean?) and the software they’re controlling on the TV/DVD player etc, is sometimes less than intuitive and not helped at all by having a control that needs the manual to be open in front of the user to make any sense.

There’s one great example of good design that jumped out from reading the book – and that was Cooper’s commission to design an interaction model for a new airline video on demand (AVOD) system. Various attempts were made to get something that could display quite a lot of possible options (since there were many films & TV shows which could be watched at the user’s demand), without having to give any instruction on how to use the thing, even to people who weren’t familiar with what they might expect on modern consumer electronics or computer systems.

After selecting and rejecting various ideas, Cooper settled on a simple UI of a rotary dial positioned directly below and in the centre of the screen, combined with thumbnail views of the film/show. Show someone a rotary dial or knob (suitably designed – maybe one with serrated edges and no obvious way to pull it out) and they’ll instinctively turn it before trying anything else. (This is a topic also covered by the 2nd book in this series: it deals with how a device naturally affords itself to the user – eg if you pick up something with a single, raised button, your first instinct would be to press it rather than try and pull it off – it affords being pressed more than being prised).

If the user turns the dial back and forwards, the list of titles pans that way, and if they turn it more quickly, the list moves quickly. When they find something they want to watch, they press the button. End of user interaction model.

Again, note the distinction between user interaction and UI. As far as the user is concerned, they turn the dial and push it to pick stuff. The UI can later deal with minutae like what to do if the user selects something by mistake… how do they go back? How do they control the volume or screen brightness etc? Maybe other buttons or controls might be required for that… unless they got into some modal system where the dial would control volume… but that could just confuse things more than adding an extra button or two.

Alan also introduces Personas as a key way of focusing designers and developers on how to address the specific needs of a specific type of user; rather than being generic (“the users”, or even saying retired people, or young mothers, or teenagers or tech-savvy twentysomething males, is still vague), the concept means they actually embody a persona with characteristics as if it’s someone they really talked to – here’s John, he works in a small business IT provider, so he knows a good bit about technology but lacks the time to do lots of reading about how to implement it, etc etc.

The Exchange development group in Microsoft was one of the no-doubt many who have adopted personas when it comes to designing software – so the needs of a whole group of disparate people can be met, hopefully, by using more holistic design processes, than simply concentrating on making it look and function well to the people who’re doing the designing.

More info on Alan Cooper’s personas

Adjunct: There’s an amusing article courtesy of SAP, on Golden Rules for Bad User Interfaces – if you’re going to sit down and design a really bad UI, follow these rules and you won’t go wrong…