I have dumb-as-rocks logic on my dashboard that straight-line predicts sales out to the end of the month.  Currently, its suggesting I’m likely to have $3,000+ sales in February.  What is scary is that number is increasing every day — i.e. the projection keeps going up because the last day’s sales beat the straight-line projection.  (Or, in some cases, shattered it.  Today was my best day ever.)

What’s doing it?  Well, its a witches brew:

1)  Early indications are that the new cart that I was so excited about kicks royal buttocks.  There is an A/B test running at the moment.  Suffice it to say that if I told you the improvement I am seeing you would not believe me.  I’m not even sure I believe me.  The results are not statistically bulletproof yet and, against all my instincts to cry it from the rooftops, I’m going to wait until they are to show off.

2)  I am having good results from a really simple change to my Check for Updates page, which is seen by a large portion of trial downloaders.  The basic idea is simple: as long as I have you on my webpage because you’ve demonstrated that you care about having the latest and greatest, why don’t I sell you on the benefits of getting the latest and greatest forever?

3)  I’m having fairly decent results with the testing of the version of the software packaged with Excelsior JET versus the stock Launch4j wrapped executable.  It isn’t quite the murderously one-sided contest that the shopping cart appears to be, but hey, improvements are improvements.  I’ll wait until the test is over to unveil the results, although I gave an interim update here for those interested. 

4)  I made some changes to BCC 2.51 to make it more usable and, at the same time, make it sell better.  One alteration which might slip the notice of programmers was to the UI.  Can you find the change between these two screenshots?

Old version:

New version:

Give up?  Click on the second image and you’ll be taken to the annotated version, with the two important bits called out in red.  Or you could highlight the following text: [The number one reason to buy my software is to get randomly scrambled bingo cards.  Despite the fact that I hammer away at this on my website, many people don’t actually know that the program does this.  I get asked sometimes “How do I scramble the cards?”, which indicates that the whole Sample Cart element was an epic failure at comprehensibility.  Hence the clarification by it.  Similarly, users perceive a need to get unique bingo cards.  There are 24! bingo cards possible from the smallest possible word list.  That is 620 septillion bingo cards.  But users are worried that if they print some insanely big number, like twenty, they will get a repeat.]

Incidentally: if there is an exceptionally nice person out there who could reproduce the first image for me on a machine that has Windows XP on it, I would be very obliged.  Just open any of the Language Arts -> Reading -> Dolch Sight Words lists, and show the program with the word list opened and scrolled down, as that image does.   Thank you, Chris.

5)  BCC 2.51 includes a “soft” timed trial mechanic.  Here is how it works: the user gets to use the software for forever, as they always have been.  The software prompts to be updated once every 15 days, as it has for quite some time.  If a user says they want an update, the software then displays the following dialog after popping the website: 

Yes, that spelling mistake is in the original.  Sigh.  Just noticed it as I was grabbing this screen shot.  I’ll fix it tomorrow.  Anyhow, the idea here is that while nagging first time users of the application would be a little gauche, someone who has used the application for 15, 30, 45, etc days is clearly happy with it and just needs a bit of a nudge over the finish line.  So I offer them an incentive for registration.  

The nice thing about this one is it sounds like “getting something extra” rather than “getting something which was taken away from you”, like the ability to print 16+ cards or the ability to save, both of which are disabled in the free trial.  The upsell screens that pop up when those are triggered still account for the lion’s share of sales from the app, though.

Alright, that’s enough writing for one day.  I’ll keep you aprised as the month moves on.

I wrote up approximately everything I know about shopping carts, plus everything I learned from my recent experience rewriting one, and made a proper article about it.  It ginormous.  It is also probably one of the best things I have ever written regarding my uISV, so if the topic interests you, go have a gander.

It includes a bunch of high level theorizing, some stats from BCC, and more code than you can shake a stick at.  (I released the whole cart into the public domain.)

Why put it on my site rather than the blog?  Well, it uses live data and integrates directly into the site, for one thing.  For another, I’m kind of hoping folks will say “Ooh, that is some wonderful stuff” and link to it.

Hello, Google searcher!  I spent 2 hours so you don’t have to!

Search for the following line of code: 

els.overlay.style.height = height + ‘px';

Now add this after it.  Problem solved!

      //causes the overlay to scroll as the page scrolls — necessary for Safari/Chrome/FF3

      if (document.viewport && document.viewport.getScrollOffsets()) {

        var top = document.viewport.getScrollOffsets()[1];

        els.overlay.style.top = top + “px”;

      }

OK, back to regular readers of this blog: as mentioned previously, I’m testing a new shopping cart.  There were previously 3 known issues:

1. the overlay didn’t scroll
2. the price got all funky in Google Checkout under some conditions
3. the quantity and price were inconsistent if you switched the item after closing the cart

I’m happy to report:

1. I patched iBox to avoid this issue, and tested it in five browsers because I just have no life whatsoever.  Please see above code if you need it.
2. e-junkie continued their years-long practice of above-and-beyond support and corrected my misunderstanding of their API, which let me patch my code around this
3. I patched my code, in a ho-hum workmanlike fashion.

The more I use Javascript the more I feel that a) all websites I’ve ever used are missing massive opportunities to make their user interaction sexier than they can possibly imagine and b) I can understand why, because coding Javascript is the most painful programming I’ve done since C in college.  

Oh, God, the cross-browser issues!  The sheer complexity of the DOM model!  The paucity of good documentation available in my IDE next to autocomplete!  (Sorry, I will always be a Java programmer at heart.)

Anyhow, if you want to take a gander at the current version of the sample cart or compare it to the current cart, go nuts.  After I alter it a bit tomorrow to make the error handling sexier (i.e. for the disallowed multiple purchase through Google — it has never happened before but, eh, why not ship it right the first time), I am going to start the split test.

Yesterday I mentioned that I would be making a new shopping cart.  

I’ll be blogging about this much more extensively later, but after pouring 8 hours into the massive black hole of time that is Javascript (aaaaaaaahhhhh I hate you so), I got the new and improved cart working.  It isn’t quite user-ready yet and isn’t anywhere NEAR where I would consider releasing it as code for other uISVs, but you can go play around with it to get the general feel.

Known bug: e-junkie seems to have an issue when you override a price for an item and use a Google Checkout Buy It Now button.  I use this feature to move the pricing logic from the e-junkie servers to my Javascript, where it gets “bugs in your teeth fast” speed improvements.  I will probably delay releasing this until e-junkie fixes that issue or I decide to work around it with a business rule modification.

Known bug #2: If you pick a non-one number in the cart, then close it, then reopen it, your total is calculated incorrectly until you do at least one keypress in the quantity field.  I know what is causing this and will squash it fairly soon, but just feel like “I’m done for the day”.

Old cart, for comparison: Bingo Card Creator purchasing page.

New cart: http://www.bingocardcreator.com/purchasing-alternate.htm

How I feel:

1. The new cart is bugs in your teeth fast for loading.  Mission accomplished.  Currently it takes the same amount of time when you click Checkout as the current cart does, which needs to get disguised a bit better.
2.  Try adding a CD to your cart in both and tell me which you like better.  I think this is going to be worth significant money for me.
3. In general, I think the user interaction simplifies markedly.  The new lightbox-esque effect, provided by iBox (a wonderful piece of software with some significant teething issues I’ll talk about later) makes the “Continue Shopping” button redundant.  Gone.  Because I no longer incur an AJAX roundtrip to another server every time the user does anything, I don’t need to tie their updates to the Update Cart button, hence it is gone.  
4. I sort of like being able to customize the branding a little bit.  For example, while you and I know this is a shopping cart, I think that whole metaphor just confuses users.  Gone.  Instead, slap in logo and text.

Let me know what you think.  After I’ve sanded down the few issues I’m going to start the A/B test and then start packaging this so that other folks can use it.  Expect a very long “making of” post as well — I actually got to solve some fun technical issues for a change, so I’ll tell folks how I did it.

If you’ve been following the blog recently you know I’m running a split test on a self-contained executable (made with Excelsior JET) versus my standard wrapped JAR (made with Launch4j, requires Java installed).  The idea is to see whether the tradeoff of vastly increased download size of the native version makes up for eliminating the Java dependency.  Launch4j will prompt people to download Java if they don’t have a sufficient version installed, but that is one of those decision points where people might stop using the app.

Previously, the approximate size difference was 13 MB versus about 1 MB.  However, with a little help from Dmitry over at Excelsior, I was able to shave 4.5 MB off of the installer for the native version.  Here’s what I did:

1)  Used the detached package option, described at “Java Runtime Slim-Down” in the User’s Guide. 

2)  I removed all of the packages which were given the green light to remove — this included Cobra, Management, XML, and all that enterprise-y cruft for my application.  Packages which get the green light are always safe to nix.

3)  Then I made a judgement call about packages which got the red light.  Red light means they’re referenced in some code included in your program but, importantly, if they’re never actually loaded you’re in the clear.  I was pretty sure I could nix the JSound and RMI packages, as I don’t use either and I have a very good idea of what my 3rd party libraries needed (certainly not access to the sound card).  

The JET packager thing gives you a test option so that you can actually run through your program and see if you end up needing the detached packages.  If you do, they’re downloaded at need from your website (you get to upload them yourself).  I would strongly prefer avoiding that, so I stepped through all my functionality to make sure it didn’t fire a download.

4)  I used the “deploy as a self-contained folder” option, which let me copy/paste BingoCardCreator.exe and the rt/ folder produced by JET and move them into my folder for InnoSetup to take a stab at.

5)  I used the same InnoSetup script I use for the regular (Java-using version), making sure to modify it so that the rt/ directory was included in the installer and removed by the uninstaller.  This worked fine, functionally, but 13 MBs is a lot.

6)  Dmitry got in touch with me and told me that they have a tool which compresses a particular JAR file that the JET deployment comes with, much much more efficiently than the ZIP algorithm can compress it.  So if you fire that tool once on your system, and then once at install time (to uncompress it), you can save quite a bit of space.  So I packed up the JAR on my system, and then edited my InnoSetup script to call the unpacker right before exiting setup.  Easy peasy.  I can barely tell the difference in install times, but slimming the download 4 MB is easily worth it.

How To Pack The Jar (assuming you detached packages): 

cd C:\some\path\to\distribution\directory\rt\lib

c:\jet\directory\goes\here\profile{use tab complete}\jre\bin\pack200 -g rt-0.jar.pack rt-0.jar

As long as we’re at it, you can take a gander at my Inno Setup script if you want.  It is no great shakes but it might help you if you want an example of the whole picture at once.  Feel free to create derivatives from it if that saves you time.  (You’ll note that it is optimized largely to remove as many screens from the installer as I possibly can — no asking where to install, no asking whether to deposit shortcuts or not, etc.  I have non-technical users and don’t want to fatigue them with decisions that they’re largely not qualified to make anyway.)

Well, after hours of fruitlessly trying to solve the problem in some clean way, I eventually dirty hacked my way around it.  Ironically, the “clean” solution required touching six files, the “diry” solution required touching 2 lines.  I don’t like it from a logical perspective but the extra burden it imposes on customers is minimal and would require them to have non-default settings to even notice, so I guess that is survivable.  (I also checked and out of 560 word lists it affects only 8 of them.)

I think I’ll chalk this one up to “Eh, sometimes you just have to ship it.”

Now to pay my penance for slackadaisical testing earlier: new CDs for six people, who each got one with the bug on it.

I just had my uISV nightmare happen:

If you combine the following two conditions:

• You have a free space
• You have exactly as many words as are needed for the card (i.e. 24 for a 5×5 with 1 free space)

and you try to print, the printing thread crashes silently, due to an ArrayIndexOutOfBoundsException.  This shows up to the user as the program simply ignoring the print command.

This is about the worst thing that could happen to me at 1:30 in the morning, short of a crash bug.  Without the capability to print, the application is useless.  Printing is always the thing I spend the most time testing, but I typically test by loading up Wizards and when picking randomly.  I rarely get one that has exactly twenty-four words in it.  

Unfortunately, that behavior (filling the card exactly) is really common in actual use.  Blech.  Memo to self: need to start using JUnit before I touch anything in the bowels of the printing code ever again.

I tried fruitlessly to fix it, but there is little that can be done at 3 AM.  Thank God for Capistrano.  The whole shebang of my website, including the executables, can be rolled back to a known good version at the touch of a button.  And, while it is annoying as all heck, I had to push the button — the 2.5 executable is just an accident waiting to happen for anyone who downloads it, so I need to contain that and get to work on fixing it.

Memo to self: get ready to FedEx replacements to all four people who got CDs with 2.5 on it, and write passle of apologies to anyone who downloaded the trial in the last 24 hours.

One of my customers just got in touch with me to express their dissatisfaction with my Mac support, in particular how long it took me between updates, and asked when I was planning to release an update and if not how quickly I could have their money back.

Three thoughts went through my head:

1. Happily, I just released a new version and am putting out the inevitable minor brushfires to prove it.
2. Oh well, its perfectly reasonable that he hasn’t heard about the update yet, its only been out for 20 hours.  And my last major addition to the software  was almost a year ago.
3. My Mac support is, compared with my PC support, rather lackluster.  I don’t own a Mac, I have to rely on my blog readers to pull me out of the bacon for it, and while I think I’m probably the best bingo card creator on the platform I have plenty of room for improvement.

Then I looked up his registration details, because I was giving him instructions on how to install an update and I always read people their Registration Key when I tell them to install anything (just in case — shouldn’t be needed).  

Now, if you open up my Rails console and type in Customer.find_by_any_identifying_information(“whatever”), which I used instead of the web version (I had a shell open and am lazy like a fox), you get back an array of records.  Which, in Rails, includes all the fields in each record — including timestamps on when the record was created.  This customer’s timestamp was from March, 2008.  

Wow, that is an interesting take on the 30-day guarantee, I though.  Then I remembered, wait, I only started tracking these things in Rails back in March… which means his record might have been one of the ones created when I loaded the database with all my previous transaction records.

So I typed “customer.sale.time”, which gets the actual time of the sale rather than the time the record was written to the DB.

Tue Dec 26 04:27:28 UTC 2006

Wowza.  I really had not been expecting that one.  And then banged out  the following:

Hello $NAME.  You might be interested in knowing that I released version 2.5 of Bingo Card Creator for both the Mac and PC yesterday.  It includes approximately 500 word lists and a few new features that people have requested.

You can upgrade to it by going to http://www.bingocardcreator.com and …

Please tell me if you’re not satisfied with the new version.  I wouldn’t want to keep your money unless you’re happy.

One minor brushfire put out, two more to go.  Though it may seem unlikely in light of the instant circumstances, I mean it when I say it: I love this job.  In comparison with my day job, which is generally a pretty nice place to work don’t get me wrong, I have the absolute right to change anything I want to solve problems for myself and the customer, and oh is that intoxicating.  

It is particularly intoxicating after having to fight for authority to schedule myself to write design documentation in English to hand over to one of our outsourcing teams.  “Your time is too valuable to use on translation” is a lovely thing to hear, but I’m closer to the opinion that my time is too valuable to spend the next 6 months dealing with code that is totally orthogonal to the customer’s actual needs.  

This was richly demonstrated when, following the traditional “figure out what the designed behavior of the system is by pushing buttons and seeing what happens” documentation method, our outsourcing team filed a bug about the system being configured improperly, because they attempted to login with the credentials which we provided (after a week of laboriously setting up a copy of the system — without reference to English documentation, mind you) caused them to see a screen full of red text.

This resulted in my most amusing conversation ever about designed behavior:

“Are you seeing the error message above or below the weather report?”

“Why is the login screen showing a weather report?  That is probably a bug, too.”

“No, the weather report is not a bug.  If you flag an announcement with announcement_type = 5, then it shows up in big red text on the login screen.”

“That is the error message!  The big red text!”

“Oh, then this is expected behavior for the system.  The administrator has chosen to share it with the users, and it is in the test data and being displayed appropriately.”

“But why is it in huge red letters?!”

“Because the weather report reads

‘Typhoon Warning‘

 Closing this bug as ‘by design’.”