I’m often asked why I’m so passionate about Dazzle, so I thought I’d blog about the origins of Dazzle, and help explain why I think this approach gives a better user experience and reduced cost.

Like the vast majority of Citrites, I use our software pretty extensively – and like most with a technical bent, I tend to use the early pre-alpha buggy stuff with all the extra goodness. It was one particular incident with this that lead directly to the first brain storming around Dazzle.

At the time I was in the middle of an important set of off-site meetings and my laptop and the pre-alpha software I was using was working well. Now it is never good to tempt the gods of software, but that is exactly what my “nanny knows best” software chose to do – it reconfigured my world – and in the process broke it.

Now all software can have bugs (especially early stuff) but the frustration I had wasn’t so much caused by the bug, but by a case of poor timing by ‘the system’. We have all seen people trying to avoid this – turning off virus scanning, avoiding networks – even refusing to logoff or power down incase that lurking update happens just before you get on a plane/enter the board meeting or whatever.

This particular incident propelled me into writing up a set of rules as to how the client software should behave. Here it is:

  • “Don’t remove (or update) software without asking”
    Users need confidence that if software worked yesterday it should continue to work today.
  • “Don’t give me stuff I don’t want”
    We all have to cope with the clutter of junkware we don’t want – and one person’s “really useful app” is another person’s junk.
  • “Citrix apps should behave like local apps”
    This was nearly true before Dazzle, but not quite – and every minor difference leads to helpdesk calls and user frustration.

These three things were the original motivation behind ‘Anthem’ – or Dazzle as it later became. The idea resonated with the ‘simpler’ and ‘user empowerment’ camps, and fitted in with ideas of reducing IT costs, both through less support (because the user is in control) and lower software cost – if users only get the software they want, IT gets higher visibility over what is needed, and can reduce the amount they over provision.

Of course this was just the start of Dazzle, and I’ll be talking about what else it does (and why) at Synergy in Berlin in talk SYN317 – Dazzle and Receiver vs. ICA clients – what’s the difference, why it matters and how to make the move. I’ll be joined by Simon Frost, the architect for Receiver who will be explaining how Receiver can make life simpler for the user whilst giving IT sufficient control to ensure that each user has exactly the right client side infrastructure and configuration, across a diverse world of Windows, Mac and other devices.

Hope to see you there.