Error Message of the Day

I have to admit that some of my error messages to users aren't that friendly, but I've tried to put in a message at least that says "Please contact support and report the above error.". Sometimes I can help users, sometimes I can't. I was using QuickBooks today and I received the following error message:

That's a huge help! It doesn't tell me what to do, what happened, or how to correct it. Personally I think it looks completely unprofessional to display build paths in error messages. While they might help Intuit fix the issue, I don't even have a clue where to start reporting that. Do I contact support@intuit.com or do I have to go through their web based system? I don't want an answer, I just want to report it.

24/7 Tech Support

I received an urgent email from a user today that had a slight problem with a registration code. I responded within a couple of hours (today is Saturday) saying that I tested the code and it works fine (I actually did test the code and saw that it worked) and said please try again and if you have problems, please send a screenshot so I can verify the code. The response I got back was "I am very disappointed with your response." Wow, it is those kind of users that make me want to quit writing and selling software. I generally get back to users within a few hours, 7 days a week; yes, I work a lot and some people appreciate that. Some support tickets take a bit of going back and forth and I'll work to solve problems as much as it takes. However, getting responses like this make me want to just pack it in.

I generally expect an answer within a few days to any email I sent. (I have, however, been waiting 2 months for a response from IRIS about returning my crappy scanner, but that's another store and I should just send them a certified letter and demand my money back as the product was falsely represented.) On weekends, I don't expect any response as normal companies don't have people working on weekends.

Oh, and ReceiptWallet 2.0 resets the 3 week demo period, so even if I didn't get back quickly, all users would still have time to use the app before the demo expired.

Uggh.

Background Apps and the iPhone SDK

Yesterday I wrote that I didn't think background applications were a good idea on the iPhone and I've seen some other posts that support my position; anything that makes the phone less stable is bad. A good friend of mine pointed out why a background app would be good, but also reminded me of how this was handled on the Palm OS. Notifications were posted. So an application would register for a notification or set an alarm for a specific time and then would handle that. While I'm not saying the Palm OS was perfect (if you ever wrote Palm OS software, you remember that notifications and alarm callbacks had to reside in the first 16K (or was it 64K) of the application thereby causing you to use jumps to get stuff to work. If you don't have a clue what I'm talking about, feel lucky.

The iPhone could do something similar (maybe it already does, but I don't know and even if I did, I couldn't say publicly until June). I'm sure that the iPhone SDK will mature as time goes on, but I hope that developers remember that the iPhone is a phone and music player first, and an application player second (or third or fourth). If anything takes away from its main purpose, it will hurt the platform.

When my code bites me on the you know what

I released ReceiptWallet 2.0 on Tuesday and the reception has been pretty good. Unfortunately, as with any major upgrade, there are bound to be issues. I've been handling the support issues on a case by case basis, and I've been scratching my head trying to figure out what could have caused the issues. This afternoon I received a phone call from my uncle who just upgraded and now his data was empty. The good thing about the upgrade is the chances of destroying the data are slim; ReceiptWallet, in most cases, can't find it. Having visited my uncle back in November and knowing how his system was setup, it made getting him up and running much easier. Then, this evening, it dawned on me the problem, so I tested my theory. In ReceiptWallet and DocumentWallet, I had a preference that let users move the ReceiptWallet or DocumentWallet data folder as people wanted to put it in Documents or on another hard drive. So I moved my data in ReceiptWallet 1.5.2, upgraded to ReceiptWallet 2.0 and saw that ReceiptWallet didn't find my data. Hmmm...at least I could reproduce it.

I started poking at my code and within a few minutes, saw this:

		[[NSUserDefaults standardUserDefaults] objectForKey:kOldDataLocation];

That's the whole line. Anyone who knows Cocoa programming knows that this does nothing. The line was supposed to be:

		dataLocation = [[NSUserDefaults standardUserDefaults] objectForKey:kOldDataLocation];

I somehow left off the assignment to the variable.

OK, simple fix. However, this doesn't really help the people that have already upgraded and our stuck. In addition, I'm not quite ready to put out a 2.0.1 version. So, I added a menu option that says "Open Prior Version Data" which does the magic to open the data file and actually executes the problem line of code from above.

So, I've posted the new version as a beta, put a Knowledge Base article about it and put a ReceiptWallet News item about it. I'm hoping that I can simply point people to the beta version and their problems will disappear.

I'll probably sleep well tonight having found the answer to one of this week's greatest mysteries.