Indie Life

There are 12 entries in this Category.

How to send smart Bug Reports

I just came across three nice articles on bug reports, how they are filed by customers, and what all customers (including programmers who are customers of others) can do to increase the likelihood of their bug being addressed. Luckily, I generally get good bug reports, and when they aren’t, it’s usually my fault (e.g. I currently get crash reports for the Moose, but I have no way to let users tell me what they were doing at the time, or to specify their e-mail address so I can ask them for more info). Anyway, on to the articles:

Most of these articles also have great comments. The Executive summary of them all would probably be: Remember to state your problem that you’re trying to solve, not just how you’d change the program to solve it. The programmer might just be able to surprise you and solve your problem with a much better solution.

Also, make sure your bug report covers the following three points in detail:

  1. What you did. In the form of actual menu item choices and what button was clicked, e.g. “Double-clicked my image file’s icon in Finder”, not as a short summary like “I opened a file”. However, do also include an additional higher-level summary of what you were trying to do, like “I created a PDF image and wanted to put it on the web. For this I wanted to run it through Frobnitz to defrobnicate the file prior to uploading it.”
  2. What happened. In detail. Not “it didn’t work” or “it disappeared”, but rather “the application Frobnitz’s windows disappeared from the dock and a window showed up ‘the application Frobnitz unexpectedly crashed…'”. And always try to quote error messages verbatim. Sometimes a program has several error messages that differ in one word only, and if the programmer knows the exact text, they can find the spot in their code where it actually crashed.
  3. What you expected to happen instead.

 

Update: Added a link to Daniel Jalkut’s entry on the topic.

Automatic Software Updates – Making User and Developer Happy

Executive Summary: Users want to achieve certain goals through using your software or web hosting service. During important projects, users often don’t want anything to interfere with their achieving these goals. Updates always have a chance of going wrong. So, make sure they are informed of any updates you perform, don’t update invisibly in the background, and leave them the choice when to update in case they’re in an important project right now. If you show respect to your users and what they deem important this way, not only will your app serve them better, they will also appreciate your work more, and consequentially be more likely to stay your customers.

I just came across a new article by Aaron Ballman asking why some users don’t update their apps, even when it’s a free update. Aaron argues that he spends a lot of time on his updates and fixes lots of bugs, and thus is kind of surprised why someone wouldn’t want all that free goodness.

A visitor named Steve answered that the reason is probably that they fear it will introduce new bugs, and could destabilize their system at an inconvenient time. Another visitor, Damon, mentions he took the route of a benevolent dictator and just made his app auto-update to make sure his users don’t have to live with bugs.

Damon’s method would make me drop that program quicker than a hot coal, exactly for the reason Steve mentioned: Never touch a working system. I may be using that app to work on a diploma thesis or another important project, and if the update introduces a show-stopper bug and thus makes me miss my deadline, I’ll get very annoyed.

Applications are tools to get work done. This work may pay, or it may better the world, or do whatever else I think is worth achieving. Usually that involves manipulating some sort of data that I spent a lot of time to collect or create. Since this is my data and my time, I also expect it to be my choice when to risk that data. By giving me the choice when or whether to update, application programmers show they respect my needs and priorities (even though most of them probably don’t share them).

From that results an obvious way to encourage me to update: Make it possible to install the new version independent from the old one and use both as needed, without either affecting the other. If I know that I can just launch the old version to get my production system back, or if I get an archive-and-restore feature, I’ll have much less qualms about updating. (I think there are some FTP clients out there who advertise that with every update.)

Another part of this is making it more convenient and less interrupting to install an update. If I only get a web site link, I’ll often wait a week or two, until I have some idle time on my hands, at least if I don’t see an immediate benefit to me in the announced changes (“miscellaneous stability improvements” are too vague, unless it keeps crashing on me right now). I may not update right away, but I’ll usually do it in a while.

Updates that at least download the file for me without having to click through a web page will be applied a little quicker, because it saves me time. I’ll have the file on my hard disk to copy over as soon as I feel like it.

Extrapolating that, self-updating apps should be a hit. But they only are if they respect my data and my needs: Can I easily revert to the old version, including all previous configuration files (Preferences, templates, patches)? Do all these features work reliably?

For example, sometimes Photoshop Elements takes hours for me to launch because it downloads a new version of the same three Adobe Online Something files, and even downright freezes during that. It costs me time and forces me to force-quit and restart PSE, often several times in a row (which sounds trivial, until I need to do that important change to a graphic in the next 5 minutes or it won’t make it into print). Even worse, it doesn’t provide me any visible benefit. I have no idea what these files do, and they certainly haven’t fixed any bugs for me yet.

Seen from this angle, an incomprehensible action on the users’ part becomes a very smart one when seen in a larger context. Show your users that you respect them: let them choose the time of their update. And since your users’ mind is obviously on a topic that is more important to them than your update, remember that they may have forgotten your update by the time they’re finished with that more important thing. So, offering a third alternative to Install and Don’t Install, like Ask Me Again Next Week may just get you those missing ten updates.

Oh, and by the way, this also applies to web hosters: While it is incredibly nice to your clients when you install the newest updates and security fixes on their server for them, it’s a good idea to give them some advance warning. Often, such small fixes have unexpected side effects. If I’m a web designer and I just sent out a few job applications containing a link to my web site, a PHP error caused or exposed by such an update – usually not a show-stopper – may decide between me getting hired or ending up unemployed under a bridge. If I, the client, know there will be a change, I may be able to set aside some time to examine my site for deficiencies once the switch has happened, and thus avoid most of the trouble.

In addition, keeping your users informed about what good deeds you’re doing increases their awareness of and appreciation for the work you’re doing. Customers that know you spend every odd week installing the newest security fix, scanning the file system for unsafe permissions or that you just replaced one of the hard disks on the RAID that was about to fail, will not see you just as some guy who buys a computer once, hooks it up to the net and from then on only cashes in checks and drinks lemonade on the balcony. They will know they’re actually getting good craftsmanship for their money. And when they know that, they’ll be much less likely to move off to another hoster that offers the same server features for a buck less.

Update: John Gruber just posted an article on a practical example of changing the user’s system without them knowing. He doesn’t quite express the value your user’s data point of view, but I think he basically means the same thing.