Wyatt Says...

2 months ago we released wyBuild & wyUpdate v2.5. This release adds a free automatic updater control for C# & VB.NET apps. And because we wanted to keep things simple we left the wyUpdate.exe to do all the hard work (checking, download, installing) in the background while the AutomaticUpdater control is visible on your app’s main form.

We wanted the AutomaticUpdater to be able to control the update steps, view progress, and cancel the updating. But we also wanted to keep all the updating logic in the wyUpdate.exe. For this to be successful we needed a way for the AutomaticUpdater control to talk to wyUpdate.exe while it’s running.

The Answer: Inter-process communication (IPC)

Inter-Process communication is a fancy computer science way of saying “processes that can talk to each other”. Google Chrome uses IPC to communicate between tabs of the browser & plugins. It’s a simple way to keep parts of your program isolated from crashes.

For instance, if a tab of Google Chrome crashes only that single tab is killed. The rest of your tabs will continue to function normally.

Lots of bad ways to do IPC

Now that you know what inter-process communication is, let me tell you the worst ways to do it.

• Shared memory: Difficult to set up & difficult to manage.
• Shared files / registry: Very slow due to the writing & reading to/from disk. Difficult to manage.
• SendMessage / PostMessage: Locks up the UI thread while the message is processed. Messages are limited to integer values. Can’t communicate from a non-admin process to an admin process. Assumes that your processes have a window.

Named Pipes

Inter process communication using named pipes is what Google Chrome uses and what we use for wyUpdate and the AutomaticUpdater control. Let me teach you about named pipes.

“Like Mario’s pipes?”

Exactly like Mario’s pipes. Except, instead of jumping Mario through the pipe, you push data through the pipe:

What do you put in the pipe?

You can transfer any data between your processes. So what data should your transfer? The answer is “it depends”. The rule of thumb is to keep it short, and keep it simple. Here’s what we do with the named pipe between wyUpdate and the AutomaticUpdater control sitting on your application:

• Command codes: The AutomaticUpdater can command wyUpdate to check for updates, download the updates, extract the update, and install the update, or cancel any current progress.
• Responses: wyUpdate can tell the AutomaticUpdater if there’s an update available, what changes there are in the update, and the progress of the current step (e.g. downloading).

With this simple setup the AutomaticUpdater control that’s on your application is completely isolated from wyUpdate.

Get the C# source

Download the named pipes C# source. It works with .NET 2.0, 3.0, 3.5 on Windows 2000 – Windows 7.

There are two files that do all the work: PipeServer.cs and PipeClient.cs. We use the PipeServer.cs file inside wyUpdate, and we use the PipeClient.cs file inside the AutomaticUpdater control.

Also included in the zip file is a simple messaging program to demonstrate communication between two separate processes:

Tell me what you think in the comments. I want to hear from you.

This week I was doing work on LimeLM that involved virtual machines. In particular preventing piracy in an environment where the whole PC can be duplicated bit-for-bit. As you can imagine this meant installing and using many virtual machines; VMware, Virtual PC, Virtual Box, Hyper-V, Parallels, and every other obscure VM.

When I ran Parallels the first time it reminded me of a split test I ran on wyBuild a couple of years ago. Here’s the first run of Parallels:

You’re seeing this right – 4 windows stacked on top of one another. They’re even polite enough to welcome me twice.

No one reads dialogs.

The worst part is that I still haven’t read what the dialogs say – and this is even after I cropped & arranged the dialogs in Photoshop, proof-read this article 3 times, and written this very sentence. They could say some pretty vulgar things and I wouldn’t even know.

If a dialog has more than 3 words I just look at the buttons and guess what the dialog says. Here’s what I read:

I clicked OK on the last dialog, and a new dialog popped up:

Oh God, they’re breeding. I’m sure “Copyright Notice” is real page-turner, but I have better things to do.

What can you learn from Parallels’ Mistakes?

By this point I’ve forgotten what Parallels Workstation is. I think it’s a dialog generating machine.

What can we learn from Parallels’ horrific design?

• Their developers haven’t read The Elements of Style. Rule 17: Omit needless words.
• The Parallels developers don’t do clean installs of their programs.
• They haven’t sat a user down and had them use Parallels from start to finish (from setup to the first virtual machine).

“Ok, but what can I apply to my own work?”

Parallels’ first-run faults seem easy to apply for web & desktop developers alike. But if you clear the front door – let users actually use your program – will you convert more trial users to paying users? What if you clutter the first run – do users care?

Yes, they do.

In wyBuild’s early betas (back when it was still called InstantUpdate Designer) I ran a split test comparing how long a person used wyBuild. Group A had a version of wyBuild with crap similar to Parallels Workstation; the user had to dismiss a couple of “useful” dialogs before they could use wyBuild. Group B had an experience similar to what we use today; a dead-simple first screen:

I foolishly thought the first-run dialog boxes would give users a better understanding of our product.

In retrospect the results aren’t surprising. Group B, the group that wasn’t interrupted, used wyBuild more than twice as long as Group A. More than that, the people in Group B were around 2 times as likely to save their project and build their first update.

So, the group that was bothered by a bunch of pointless dialogs often quit before they’d created their first update. (And this was back when wyBuild was free. The only measure of success was if the user actually used the product).

Because this data was collected remotely (it was opt-in, of course; I’m not a sleaze), we couldn’t ask the people in Group A why they gave up. If I were to guess I’d say their thoughts ranged from “It’s too confusing” to “I’ll do it later, when I have some free time” (i.e. never).

Anticlimactic lesson: Don’t waste your users’ time.

You almost certainly have a competitor that is faster, cheaper, better, or all of the above. So, the next time you add just one more dialog or just one more field to your order webpage, think about how many potential customers you’re losing.

Scratch that. Test to see how many users you’re losing.

Windows 7 will be available for download to MSDN and Technet subscriber in less than 2 weeks. I thought I’d introduce a few controls to make Windows 7 development easier for C# and .NET programmers. The controls will be written for .NET 2.0 & Windows Forms, but will obviously be compatible with .NET 2.0, 3.0, 3.5 and the upcoming 4.0.

The first control I want to give you is a way to use the new progress bar in your app’s taskbar icon. This is what the new taskbar progress bar looks like when Internet Explorer downloads a file:

Of course, what good is integrating this shiny new behavior into your apps if isn’t backward compatible with Windows 2000, XP and Vista? None at all. And since this taskbar behavior is included in wyUpdate & wyBuild 2.2+, backwards compatibility is a must. Here’s our Windows 7 Progress Bar running on Windows 2000 – Windows 7:

Don’t use the Taskbar Progress Bar

Like any new shiny piece of technology everyone wants to add it to their program. The flip side is that most of the times you shouldn’t use it. Let me quote the Windows UX guide directly:

Is the progress feedback useful and relevant while using other programs? That is, are users likely to monitor the progress while using other programs, and change their behavior as a result? Such useful and relevant status is usually displayed using a modeless progress dialog box or a dedicated progress page, but not with a busy pointer, activity indicator, or progress bar on a status bar. If the status isn’t useful when using other programs, just display the progress feedback directly in the program itself.

Correct:

Incorrect:

In the incorrect examples, the taskbar button progress bars aren’t very useful.

Is the task continuous? If the task never completes, there’s no need to show its progress. Examples of continuous tasks include antivirus scans and file indexing.

Incorrect:

In this example, a continuous task doesn’t need to show progress.

By the way, the Windows User Experience Interaction Guidelines is a must read for all Windows Developers. It’s a shit name (why not Windows Usability Guide?), but it has quite a few good tips. All I can ask is that you skim it once.

How we use the Taskbar progress bar in wyUpdate & wyBuild

We’ve integrated the Windows 7 Taskbar progress bar in both wyBuild & wyUpdate. Here’s wyBuild creating updates for Nero Burning ROM:

Here’s wyUpdate installing an update:

Further Reading

• Progress Bars from the WUXIG (Windows User Experience Interaction Guidelines): All you ever wanted to know about progress bars
• Windows 7 taskbar design guidelines from the WUXIG: Everything you’ve ever wanted to know about designing for the Widows 7 taskbar.
• Introducing the Taskbar APIs: C++ code for integrating your app with Windows 7

Get Windows 7 Progress Bar Now

The latest version of the Windows 7 Progress Bar C# source code, example projects in VB.NET and C#, and binaries are available on the open source component page.

If you have any questions, or find any bugs you can report them in the comments or in the wyDay forum.