Another semi-useless spot on the web…
Well, my attempt to keep people from shooting themselves in the foot when upgrading to the beta version of ReceiptWallet has back fired. I’ve had few people download it (partly because of mistakes I made) and others have had problems reading the text. So, I’ve relented and now allow automatic updates. However, the first time a new beta version is run, the user is presented with a warning that hopefully makes things clear.
I’ll see how this pans out in terms of people trying the beta.
For my latest beta version of ReceiptWallet, I’ve specifically disabled the auto update mechanism by putting in a bogus link in the Sparkle feed for the actual update. Instead, in the text of the dialog, I tell people that clicking the Install Update button will fail, to read the text, and then have the real link in the text. I’ve done this on purpose as the new beta has some major changes and I really, really want people to back up their data before installing. If they can’t install the update, then their data can’t get hosed. This seems to be working. So far I’ve had 3 reports that people couldn’t install the update. This means that they didn’t read the text and just hit “Install Update”. Furthermore, whatever text I put in the dialog, no matter how large, it won’t be read. I even made the text real large as shown below. Even in the smallest window size, I think the large text would get people’s attention and then maybe they’d scroll down.
Hmmm. Is there any use in putting text in the update dialog if people just hit Install Update? Maybe not. It’s cool that I can put whatever I want in the dialog, but maybe all I need (for normal updates) is “See our website for information about this update.”
Should I abandon my over zealousness for caution and just let people install the update without reading? If I do, there could be data loss. If I don’t, the chances of people testing will decrease.
I’m extremely pleased to say that ReceiptWallet 1.6.0 b2 (and DocumentWallet 1.2.0 b2) are now ready for testing (b1 had 2 bugs in it). This version brings a huge change to the product in that you now can have more than 1 library. For users that don’t want more than 1 library, there will be few changes.
While the changes on the surface may look minor, I think it will bring a huge amount of flexibility to the products. People have been asking for the ability to start fresh with the new year. The multiple libraries feature will make that a reality. Each Library is actually a file package that contains the main database as well as folders for the receipts and thumbnails. Furthermore, you can copy the libraries onto a read only volume or burn to a CD and then be able to open up the library simply by double clicking.
I have gone to great lengths to ensure that everything works, but I’m sure I missed stuff. I’ve done most of my testing on Leopard, but done basic testing on Tiger.
If you want to give it a whirl, make sure you have the latest released version of the product, go into Preferences and change the Look for popup (in the lower right) to be Beta versions and Releases and then do a Check for Updates. When it says that there is an update, read the text CAREFULLY. You’ll have to click a link to download the beta; clicking Installing Update will fail as I want people to read. So far, the 2 people that I have had try the new version, failed to read the text which says to backup, so I think this is wise for now; a bit inconvenient, but better than losing data.
Feel free to send me feedback. I have a few more tricks up my sleeve, but they’ll wait for the next release.
I’ve spent a significant amount of time working on the new version of ReceiptWallet. One of the changes is that information about a Library is now in a floating panel. However, I’m not happy with the buttons/look of the panel. I’m looking for ideas that people may have. Please feel free to post comments on send me email with ideas. Thanks!
Here’s what it looks like:
I wrote almost 2 weeks ago about changing ReceiptWallet into a document based application. I’ve been hesitant to do so because there are lots of things involved. For instance, I have to lock out scanning when one window is scanning, I have to deal with each window having a Reports item, etc. I decided that the time was now to implement it, so a few days ago, I started the journey to switch ReceiptWallet to document based. Based on some work that others have done in making NSPersistentDocument work with packages, I created a test application last Wednesday or Thursday and proved that it was viable. So, I’ve been working like a mad man to get things done. I’m down to about 20 “items” on my list to work on and then I’ll start my own testing. I had to rip ReceiptWallet apart in order to do this, but I’m gradually putting it back together. I’m at least at the point where I can start using ReceiptWallet again; a bunch of pieces still don’t work, but I figure over the course of the next few days, I’ll have everything working and then can start external testing. Yeah! (Some things in the UI aren’t final; I’m not sure I’m going to keep the drawer for the details…I might goto a floating panel.)
Another part of my UI overhaul is to redo my preferences. They’ve completely gotten out of hand and everything has been in one window like this.
I like how iTunes and other apps (including the Finder) have a tabbed toolbar interface, so I went that route. Using Matt Gemmell’s SS_PrefsController as a base, I re-worked my preferences into different panes. The source uses plugins for the preferences which I don’t need, so I modified the code to embed everything. I’m waiting to hear back from my icon guy, but things are looking better. Ignore my icons for now.
Wow, what a huge difference a few tweaks can make to a program. I also turned on autohiding of the scrollbars. Due to some bugs in the OS, I had to do some magic to get things drawing correctly. Having a blank toolbar looks bad, but I didn’t want to deal with it before.
I’ve started to do some work on the ReceiptWallet UI based on some ideas I got this week as well as customer feedback. I found that I personally had a number of “recent” smart collections, so I decided to make them a standard part of the interface. Also, I used some features of Leopard to get the “Source List” view (it looks OK on Tiger, but isn’t as slick). For some reason, this was harder than it should have been; I had to verify that drag and drop still worked and lots of other things didn’t break such as contextual menus, adding/removing collections, etc. However, I think it is all working now.
I am still working on some things, but will be putting out a beta next week.
After looking at NEAT Receipts yesterday and a few other programs, I’m beginning to think that my decision to make ReceiptWallet a one main window application may not have been the best one. A huge advantage to multiple windows is that people can have data files for each year or one for work and one for home. Unfortunately, changing from the main window to a document based model is not easy. Unfortunately NSPersistentDocument doesn’t support packages, but a few developers have figured out how to get around this. What does this mean? This would mean that all the data is stored in one package and it would appear as one file, but would actually be separated inside. This is exactly what I’d want with the database file separate from the actual PDFs.
Hmmmm…