Solipsism Gradient

I was tabulating the income from XRay registrations and thought the graph might be interesting for other shareware authors:

The initial peak is probably due to the fact that I had a relatively long public beta period – about 6 months, if I recall correctly – so the product was already well-known when 1.0 came out. I suppose that software released without a public beta would have a registration peak some weeks after release. After such a peak, if the product is left alone, registrations fall exponentially, approaching but never quite reaching zero.

The 1.0.5 release seems to have been well-timed; the curve had already stopped falling steeply and there was demand for new functionality, so the new version attracted a number of new clients. Publicity was favorable and XRay had been included on several CDROMs (some of which published the previous version), so there was a new, shallower peak.

For various reasons I then stepped on the ball, as they say here, and essentially left the product alone for nearly a year, except of course for user support. I should have begun working on 1.0.6 (or even 1.1) immediately, aiming for a release date around November 2002, to jack the curve up again. When I finally went back to the old drawing board a couple of months ago, the initial buzz about the product had long died down, and some of the functions which made it attractive when Mac OS X 10.1.x was new had been gradually added to later releases over time.

So the slight peak for the recent string of releases is due solely to some new users attracted by the release notices; there’ve been no reviews for some time, though I believe a couple will come out now. So part of the lukewarm reception is probably due to a lack of proper publicity; the bulk of downloads, from what I gather from my e-mail statistics, was from already registered users.

So the correct strategy now seems to be, release 1.1 with sufficient additional functionality to attract a substantial number of new users, and generate sufficient publicity around it. I’m working on that…

So I spent a somewhat more relaxed day starting up my new application, <censored>, which will be the new killer app for doing <censored> to <censored>. (Sorry, can’t be more specific at this time – all I can say is that the name starts with an “Y” ).

As I said before, real Mac application development’s step one is to design the application icon (step zero is to design the T-Shirt, which I usually skip, as it makes no sense unless it’s a team effort). After making three mock-up icons I ended up with one which I liked, but some friends who saw it were less than enthusiastic. Perhaps I should make a design contest? Winner gets a free lifetime registration and About Box whuffie? Hmm…

Meanwhile, I found the story of my life in this comic reenactment. See how a fellow geek/marginal Asperger sufferer handles interpersonal relationships! This sort of thing happens to me all the time… (for the record, I did see “Maid in Manhattan”, on a plane, but thought it a little silly).

Ben Hammersley points at Umberto Eco‘s great essay Vegetal and mineral memory: The future of books:

Good news: books will remain indispensable, not only for literature but for any circumstances in which one needs to read carefully, not only in order to receive information but also to speculate and to reflect about it. To read a computer screen is not the same as to read a book.

…

After having spent 12 hours at a computer console, my eyes are like two tennis balls, and I feel the need of sitting down comfortably in an armchair and reading a newspaper, or maybe a good poem. Therefore, I think that computers are diffusing a new form of literacy, but they are incapable of satisfying all the intellectual needs they are stimulating.

Very true. I rarely look up anything in a reference work anymore, but reading fiction on-screen is not as satisfying as with a physical book – and the latter can be read at table or on the toilet, too

Well, it turned out that I had skipped step 16 on my long list of “just to make sure”, or rather, I’d neglected to do that after uploading a corrected image. For the second time.

No idea why it went wrong two times, but on the third everything seems OK. Meanwhile, new XRay users should download 1.0.9 again if they see a message “…Sorry, but to set everything up properly you must first run XRay once from an Administrator account.”

I woke up about 3AM to get a glass of water and on the way back from the kitchen I somehow felt I had to check my e-mail… I know that’s a symptom of something-or-other, but anyway it allowed me to see one user’s alert about my error several hours sooner than usual, and do damage control.

I posted the bug-fixed XRay today as 1.0.9. Bumping the version number was the best way to alert people that something had changed, and sites like VersionTracker (XRay@VT) and MacUpdate (XRay@MU) are geared to changing version numbers too.

Here’s the usual routine which I follow for publishing XRay, in case someone’s interested.

1- Check and rewrite the internal log I keep of all changes. Also check and rewrite all the help files, including the many screen shots.

2- In Xcode, “Clean all Targets” (which will delete the application and subsidiary things like the XRay Contextual Menu and the Developer Plugin).

3- Remove the old copies of XRay, preferences and whatnot, to simulate XRay being installed on a pristine machine.

4- Build in “Development” mode and run under the debugger. Should anything untoward happen the debugger should show me where.

5- Quit and run again. Everything should be OK.

6- Quit, remove preferences and so forth, mount the disk image of the previous version and run XRay once from there to generate old preferences. Quit. Unmount the old image.

7- Run the new version under the debugger to simulate XRay being upgraded on a user’s machine. Quit again.

8- Copy XRay into /Applications, switch to a non-admin user account, and repeat most of the steps above again.

9- If some bug appeared at any step, rinse and repeat; if not, “Clean all Targets” again and build in “Deployment” mode. This mode builds a smaller, faster program without debugging symbols and other encumbrances.

9a- Currently, a bug in Xcode also builds a program without several essential components, which have to be copied in by hand. Curse and repeat until OK.

10- Copy the built program into /Applications, run just to make sure.

11- Run again from a non-user admin, just to make sure.

12- Fire up the trusty ol’ iMac DV/400, with its Mac OS X 10.2.8, and check if everything works there too, JTMS.

13- On the iMac, copy & paste texts from the help files into the text files that I put on the finished disk image. This has to be done under Jaguar because if I do it under Panther the resulting texts will contain URLs that won’t be readable by Jaguar users.

14- Build a disk image with all the requisite items on it. I use a mixture of tools to do that and I’m still not quite satisfied with the process.

15- Upload the disk image to my site via FTP.

16- Download it again, mount it and try to run from there, JTMS.

17- Edit all HTML files on my site that mention XRay, change the version number and the link to the new disk image, copy the release notes and other text that has changed with the requisite format changes.

18- Upload the HTML files to my site with FTP and check all in the browser, JTMS.

19- Go to the XRay support forum, close out the topic on the old version and open a topic for the new one. Check that all links point at the correct disk image etc., JTMS.

20- Go to the VersionTracker site, post an interim message that the new version is being published, remove obsolete messages referring to the old version.

21- Log in at the VersionTracker site (yes, a different login) and post the changes that will appear in the header and main text. (This time I was extremely surprised that someone at VT already had seen the update on my site and done most of my work for me! Thanks!)

22- Do same steps on the MacUpdate site.

23- Remove the old disk image from my site, at this point downloaders will already get the new image.

24- Loop over the VT and MU sites until the changes are published, then remove the interim messages.

25- Write and send out the press release concerning the new version.

26- Sit back and watch the dough roll in. I wish.

Well, all of this usually takes several hours and is extremely tiring. Unfortunately it’s very easy to forget and skip some of the steps, and of course Murphy is always ready to slip in a bug at that point. The last few releases I always either skipped a step, or inserted one I shouldn’t have: make a last-second change to some source code line or another. Thankfully, if that happens, some kind user always writes in and I get a chance to fix it fast, before too many people download the buggy version…

I also try to experiment with release dates, unless it’s one of those gotta-get-this-out-fast-before-they-notice releases like this last one. It seems that Friday noon (local time) is the best time to release new software; it still makes the news on Mac sites, but very little new software comes out afterwards, so XRay will stay on the front pages over the whole weekend. This also smooths out the first download spike, when most of the registered or regular users get wind of the update and download it; today (a weekday) there were something like 2000 downloads in the first four hours!

Now to get some sleep…

Rainer Brockerhoff wrote:

As Curly (of the Three Stooges) said, “I’m trying to think, but nothing happens!”

Some thinking happened, at least…

A few users sent in crash reports, I poked around various routines that get called when the window is closed, and there was a premature call to free the window’s memory. So I removed that, and it seems to work. I’m still waiting for confirmation for some of the users who complained, but I’m reasonably confident that that might be the correct fix.

The question is, if this is wrong, why does it work in Panther? Go figure…

Anyway, if all goes well, I’ll post a revised build of 1.0.8 sometime tomorrow – unless some other crash report comes in. I’d hate wasting a release number just for a small bug fix – well, I did a few other very small fixes too, but nothing serious. On the other hand, users won’t be alerted by a version change… hmm…

As the German proverb goes, “there’s no rest for the godless”. Just when I thought I could relax a little, several users found a crash in XRay 1.0.8 when running under Mac OS X 10.2.8. So, there we go again…

…let’s hope my Digital IQ will be enough for fixing this. I actually had a similar crash happen a few weeks ago, but I thought I’d fixed it…

Big fat clue just came in: it crashes when closing a window with either the red close button or command-W, but never when using the “Close Window” menu command. This should probably lead me straight to the offending line in the program, but so far, nothing occurs to me.

As Curly (of the Three Stooges) said, “I’m trying to think, but nothing happens!”

Whew. XRay 1.0.8 is out.

Here’s what the finished batch panel looks like, to contrast with the first version mentioned below:

Much better, huh?

Everything was delayed nearly a full day, while I implemented some other stuff based on feedback from beta testers (thank you!). A puzzling crash led me to try to plug some memory leaks, but after messing around for some hours I decided not to tackle this right now; at least that particular crash could be fixed.

Then Xcode decided to go north on me, neglecting to copy parts of my nib files and not executing my copy phases; and this only in deployment mode, in development mode everything worked. After trying the usual things – quitting, cleaning, rebuilding etc. – I copied the @#$%^ things by hand in order not lose any more time…

Then, in the middle of transferring my updated files to my site, my provider goes off the air… after about an hour, it was back. Whew, as I said.

Now for dinner and some sleep… regular blogging may resume soon.

So here I was, practically all known bugs in XRay 1.0.7 fixed… just coasting a little before diving into the boring part of reviewing the online help files and updating the screen snapshots prior to publication… writing the part of the release notes explaining why (once again) no new plug-ins would be released with 1.0.8… writing e-mail to a user explaining (also once again) why 1.1 wouldn’t have a batch mode… piece of cake, really. Reviews were positive, but sales not really. How should I generate more user enthusiasm?

…when suddenly the proverbial light bulb flashed on and I thought, hey, if I do a simpler batch mode with a batch plug-in, keyed to work on all the contents of the folder being XRayed… hmm… I’ll work around all the arguments saying that I don’t have a proper user interface for doing arbitrary file lists.

So, off I go making a batch plug-in for XRay. First of all, of course, one must design the T-Shirt!

Hehe, just joking. First of all, a real Mac programmer spends at least one day – maybe two – designing the product icon:

…meanwhile, ye olde subconsciouse is chugging along, working out what the user interface might look like. Then, off we go into Interface Builder and try to build an actual user interface out of those musings…

Got it? The left column of checkboxes enables the items to the right. First, there’s a section with assorted items… looks rather jumbled-together and empty on the right side, hmm. Then, there’s a copy of the UI elements from the Type/Creator/Extension panel… then it would be nice to tell the user how many contained items there are in that folder… then we’ll need the recalculate/stop button from the main info panel… then it would be nice to affect files, folders, or both, and only on the first level… then we need a “Reset All” button to clear everything…

Oh my. This doesn’t look all that good, but writing some code usually will clear everything up. So I get to work, inserting outlets and actions and making sure all the little connections go to the right items. Then I see that my standard plug-in example code is outdated and I spend a day or so cleaning that up, and getting used to all the new fancy Xcode options for plug-ins. Cleaning up the .plist, compiling an empty plug-in to make sure it loads and all the options are right, and finding out why the Finder doesn’t show the new icon. OK, ready for some real action.

After a couple of days of trying to reuse some existing code and not getting anywhere – and moving stuff around in the window and making it even worse – and puzzling out the logic of the actual batch operation (which options apply to folders? Which to files? What if such-and-such?) – I concluded that it all was a big mistake. Would some user really wish to mark all the contents of a folder, to all levels, as “Purple”? 🙂 (Well, probably someone somewhere is just waiting for an utility to color his entire “/System/Library” folder and its contents purple, but should I really help this person further his/her/its wicked ways?)

After a sleepless night, I concluded that what users really need (as opposed to want) is just changing type and creator of a bunch of files inside a folder. So there. So let’s just imitate the way that the Permissions panel lets the user specify which permissions should be changed for contained items, but in this case with the type/creator fields and popups. Simple and direct.

So, that’s what I’ve been working on, instead of updating this weblog. I was going to post a screenshot of the current panel, except that – while capturing the image – I saw a way to simplify it even further! So, expect XRay 1.0.8 out in a few days, with (tadah!) limited batch mode. Isn’t it fun? Now excuse me, I need to oil my “delete” key…