The wyDay blog is where you find all the latest news and tips about our existing products and new products to come.
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.
You’re seeing this right – 4 windows stacked on top of one another. They’re even polite enough to welcome me twice.
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.
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?
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).
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.
wyUpdate & wyBuild 2.0 are now out. This new version has several improvements, most notable is the speed increases in both wyBuild and wyUpdate.
Now you can build update patches and release them to your users faster than before.
Managing past and future versions of your software is simple. Just drag the files into wyBuild. Adding registry modifications is just a simple and intuitive. You won’t even need to visit the help documents or the forum (but they’re there just in case you get stuck).
New in wyBuild 2.0 is an improved tab bar for version management. Not bullshit market-speak improved either. Really improved.
What happens when your version tabs exceed the width of the tab bar? Popular browsers like Internet Explorer & Google Chrome squish down the text to unreadable widths:
“The” “w” and “Sou” are some of my favorite sites. Clearly IE’s and Google Chrome’s tab management approaches are flawed. We took the Firefox approach and kept the tabs at readable widths so can actually tell the difference between “1.0.3” and “1.0.4” (or as IE would show it “1.0…” and “1.0…”).
Plus, in wyBuild you can just hover your mouse over the version tabs and scroll your mouse to see all of the versions.
We’re thinking about releasing the C# source code to this. Tell me your thoughts in the comments.
wyUpdate now comes with full multi-lingual support. You can add, edit, or select any of the many languages in wyBuild and include them with wyUpdate. The correct language is then used when wyUpdate automatically detects the language of Windows and applies that language.
The wyUpdate source code is now hosted over at Google Code. You can now checkout the source code using subversion:
svn checkout http://wyupdate.googlecode.com/svn/trunk/ wyupdate-read-only
Or, if you prefer the zip of the source, just head over to our wyUpdate page.
wyBuild 2.0 solves a few major problems with patch creation. The biggest fix is that wyBuild now properly support patching files with Unicode filenames. This fix will be especially noticeable for our non-English speaking users.
The patches created by wyBuild are much smaller than just zipping files. And much much smaller than releasing a new installer for every update to your program.
An example to illustrate my point is Nero Burning ROM. Nero Burning ROM is CD/DVD writing software that has been popular for many years, and Nero is updated frequently. One big problem, though, is their lack of a good update creation and distribution method. Instead of using a program like wyUpdate, they release full installers as their updates. That’s over 300 megabytes for very small changes to Nero.
The graph below shows how enormous just the bare minimum installation of Nero Burning ROM program is. Notice the tiny size of the update when created with wyBuild (just over a megabyte!):
We’re now offering free licenses to people developing open source programs. See the details of the offer. This offer also applies to educational institutions.
Celebrating the 2.0 release, wyBuild costs only $20 until July 20th. Buy it now.
We released wyUpdate a few months ago. Or should I say we released wyUpdate Client, wyUpdate Express Designer, and wyUpdate Professional Designer. Which is what in this flurry of names? Why is everything called wyUpdate?
I know what will clear everything up – a new name! Or rather a re-brand. We’re renaming the “wyUpdate Professional Designer” to simply “wyBuild”. We’re also renaming the “wyUpdate Client” to just “wyUpdate”.
Much like in the middle ages the name describes the job: wyBuild builds the updates. wyUpdate updates your program.
We’re ditching the wyUpdate Express Designer. Not because we hate free software or because we eat puppies. No, it’s more complex than that (but puppies are delicious).
We were following the “freemium” business model: give away a limited (but still useful) version and charge for the pro version. This is stupid for one important reason. We were splitting our time trying to attract free users, when we should’ve really been making business better for our paying users.
Or to put it another way, we were operating our company like an absurd car dealership. That is, focusing our time giving away free Lexuses to customers in the hope that they would come back and buy a Jaguar. We should have just focused our attention on the Jaguar buyers to begin with.
The feeling most people associate with updates is anxiety. Updates break things: they stop half-way through, or an errors pop-up, or it’s so slow you can take 8 coffee break before the update has been applied. In short: pain.
Our job is to remove the pain and anxiety from the update process. We’re here to make your users associate a new feeling with updates: happiness. Happiness that they can use the latest versions of your software without dealing with finicky update programs or shoddy patches.
Buy our Jaguar, wyBuild – we’re here to work with you. We want your customers to be so happy that they’ll actively talk about your software and attract new users for you.
wyUpdate, the tiny updater program you include with your program, is still open source. Pop over to the wyUpdate page to download the C# source code.
You don’t need to, of course. We include a compiled and optimized version along with wyBuild. The source is there only if you’re curious or want to help out.
The main new feature of wyBuild 1.2 is that you can now build your updates from the command line. This way advanced users will be able to better integrate wyBuild into your automation. Read all about it here.
Also included with wyBuild 1.2 comes extra protection for your users. Namely, if your users shuts down their computer while wyUpdate is updating your program, wyUpdate will give them a friendly warning. This warning gives them a safe way to cancel the update and quickly roll back to the previous version of your software.
This protection is to ensure your users always have working software, even if they get impatient.
We’ve changed the way trial days are counted in wyBuild 1.2. Before we had a 20-consecutive day trial. That is, if you tried our program once at the beginning of the month, forgot about it for 20 days, then tried it again at the end of the month the trial would be expired.
We designed the trial for automatons instead of for humans. Normal people want to try a program for a few minutes, forget about it for a few weeks, then try it again. That’s why wyBuild now has a 14-non-consecutive-day trial. You can try wyBuild once a month for an entire year and still have two trial days left. Or you can use it every day for 14 days straight.
It’s your time, it’s your choice.
Plus, the trial is only a time trial – wyBuild is fully functional during the trial period. You can begin releasing updates to your users before you’ve even bought a license.
If prose isn’t your thing, we have a video introduction to wyBuild. You can use the closed captions if you don’t want to hear my New England accent.
If you have a question or want to report bugs you can jump over to the forum – you don’t even need to register to post.