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’.”

Thanks much for all the help guys.  After several days of plugging away at outstanding little niggles I think both the PC and Mac versions are in a releasable state — and particularly with regards to the Mac folks in the audience, I couldn’t have done it without you.

I’m pumped about seeing my results in the coming months — with 400+ new cards, improved functionality (including one of my most-requested features), and general improvements, I think this could quite possibly kick me up another notch or three.  I’m also interested in seeing whether natively compiled .exes beat Java-requiring versions in a head to head test.

If you want to go to http://www.bingocardcreator.com and check to make sure I haven’t done anything stupid for your system, I would be obliged.  Here is an example of something stupid: four days ago, I used svn update to upload a  controller (the C in “MVC framework”) file to my site to fix a bug on one of my sidebars.  I neglected to notice that the same controller also implemented the split test for windows downloaders, which broke downloading the free trial for 4 days.  Argh.  Oh well, no sense crying over spilled milk.

I also went ahead and did something I’ve been threatening for a long time now: raised prices.  Or, rather, announced that I will be raising prices in about a month.  We’ll see how that works out.  And, as always, I’ll keep you posted.

Now after 14 hours of day job and pushing out a release in the same day I richly deserve a nice warm shower and a few minutes of the new Naruto game before bedtime.  (It’s awesome.)  Good night!

Hideho everybody.   Thanks for the help with the beta testing.  This is a quick list of the issues that were reported and which I have confirmed fixed.  I’d be obliged if Mac users could try executing the app again and see if the permissions got kept by the zip file this time.  If Windows users want to kick in any comments, I’m always obliged.

Windows version (requires Java 1.4+ installed)

Windows version (native — doesn’t require Java)

Mac version (shouldn’t require anything you don’t have)

• Purpose of plus/minus buttons is unclear.  Rewrote description of functionality on main page of app.  (Both buttons were already mentioned, but if you guys didn’t see it that is my fault.)
• Two included bingo cards, written in Spanish and Japanese, could not be loaded properly.  Fixed.
• Mac menu bar does not appear where Mac users expect it to be.  I believe this to be fixed.
• Windows resize when wizards are selected.  I appreciate the feedback, but this is by design.
• Resizing the window such that the sample card is not totally visible, then resizing it again, causes text on the sample card labels.  This is related to the Swing library’s implementation.  I will study the feasibility of fixing it later, but at the moment it is a cosmetic issue which is easily recovered from and happens only in edge cases.
• Changing word wrap causes the sample card to shuffle.  I appreciate the feedback, but this behavior is by design.
• Mac users do not expect to use the Ctrl key, but the program does.  I believe this to be fixed.  
• Mac users do not expect mnemonics.  I’m sort of loathe to remove functionality, particularly functionality that a few hundred paying customers may be using already.  I’m not exactly a Mac UI partisan and most of my users aren’t, either, so I’m going to put off changing this one.
• “Upgrade to full version now?” dialog is wider than my screen.    Fixed.
• The text in the Advice frame is selectable with the mouse.  Hard to fix due to Java implementation of text boxes, no impact on customers, postponing until I am very bored.
• Small screen + extraordinarily long words on card (e.g. names of famous plays) = card extends off screen.  Low impact and rare circumstances, but I will address this eventually.
• Save/Open defaults to application folder, should be elsewhere.  Suboptimal but kept for backwards compatibility.  You may be interested in knowing that applications can write to Program Files in Vista.  Really, try it — MS hacked around their own security system to avoid breaking legacy apps.

nota bene to Ant users: the zip tasks discards permissions.  If you need them to come out intact, you need to put the files requiring extra permissions in <zipfileset filemode=”755″> blocks.  In particular, if you are zipping a distribution which includes a jar wrapped up as a Mac application, the JavaApplicationStub file needs to be marked as filemode=”755″.  Much love to the testers that discovered this before my users did.

So for the last several years, I’ve had a free trial which generated the majority of my sales.  The free trial includes the following three restrictions:

1. It can’t import text files (except the free cards provided by me).
2. It can’t save files.
3. It can’t print more than 15 cards.

New in BCC 2.5, which should be out in the next few days, I’m adding a new difference between the free trial and the registered version: the registered version entitles you to automatically download new bingo cards as I release them.

So that’s the background.  What is the oversight?  I have, for a long time, tracked whether people get to my purchasing page via coming from the trial or not — but I have never tracked from where in the trial.  It could be because they hit the Purchase Now button, or it could be at one of the prompts which pops up every time they hit one of the restrictions.  It would be very, very helpful for me to know which of those restrictions are most effective at driving the sales… but I never thought of tracking it before, at least not enough to spend the 8 minutes it took me to add that in.

Do you know what drives people to upgrade from your trial?