Quicken Bakeoff, Part 3: iBankiBank is a
beautiful little application from IGG Software that has tried to
think outside the box when it comes to personal finance, competing with Quicken
without trying to copy it feature for feature.
Sometimes iBank’s “think different” approach wins and
sometimes it doesn’t—many of Quicken’s choices, I believe, are
simply the Right Thing To Do in a given situation—but it’s fun to
see a really different take on some common problems. I have to admit that all
during this bakeoff I was really rooting for iBank. I even paid the shareware
fee even though I hadn’t committed to it, partly because my review process
required more transactions than the trial version allowed, and partly because I
just want to encourage the creators.
I was willing to give up a few things for iBank, in order to make a statement (something like “I support underdogs,” which I do), but in the end there were still too many reasons left to go back to Quicken. Installation Just lovely. I downloaded a .dmg file, which Safari automatically unpacked, mounted, and opened for me, showing me a single application icon. Drag-and-drop install to my Applications folder, the way they all should be. Starting up iBank iBank was the fastest-starting of all the competitors. Comparing the startup times: GnuCash: 44 seconds (no password protection) Quicken: 12 seconds to password; 22 total seconds until ready to use iBank: 5 seconds to password; 10 total seconds until ready to use. Now that’s cool, and not a trivial win. At one time Quicken was conscious enough of this importance that they had a little app called QuickEntry that was trying to start faster than Quicken so that you could quickly enter a few checks and then quit. Setup Not as good. Spoiled by GnuCash’s amazing setup wizard, I was chagrined to find that iBank would not import a giant QIF file, and in fact, would not import accounts, categories, or anything at all except straight transaction data, and only for one account at a time. Moreover, even when I did restrain myself to just my entire Checking register, iBank seemed to really struggle with the number of transactions, becoming very sluggish and showing me the “Bite-Me Beachball” that every Apple user dreads. Because I was so motivated to see iBank win, I decided to lower the bar and only give it last month’s transactions for the purposes of the bakeoff. This was indeed a lot easier on iBank, and I was happy with the final result, although it took me considerably longer to set up my accounts, and made me realize that unless the QIF import gets as good as GnuCash’s, using iBank will require a fresh start and not a copy of my existing account data. One of the big obstacles was that because of this import limitation, transfers between accounts were not preserved and I had to go back and manually fix some of the important ones like credit card payoff. That was a big pain and something I only wanted to do once. View of the World iBank takes a fairly different view of the world than either Quicken or GnuCash. Rather than having a reconcile operation or a reconcile mode, for example, it has an instantaneous readout of your current “reconciled balance” for the given account. When you get a statement, you just check the Reconciled box for each cleared transaction until the readout matches what your bank says you have. What’s cool about this is that it reduces menu items, complexity, and screen real estate. What’s hard to get used to is that it’s an utterly different way of approaching checkbook balancing. After all, with both Quicken and GnuCash, there’s a way to bail out of the whole operation when you wrap yourself around the axle; with iBank, each change in cleared status is sort of permanent and you can’t distinguish transactions that were completely reconciled on the previous statement from transactions that are conditionally reconciled for the current statement. I’m willing to make a change in my process for iBank in this case. Nowadays I tend to download transactions more often than once a month anyway, and it might turn out that iBank’s approach is less confusing in the long run, as well as saving time. After all, it breaks it down to basics: there are transactions that you and the bank both agree on and ones that you don’t agree on yet. That’s all. Daily Use I didn’t expect this to be one of the more disappointing aspects of iBank, but it was. Lots of little obstacles erode its overall usability. One cluster of problems relates to the date of a transaction. When you create a new transaction, it assumes the current date, and you cannot tab to the date field (you can tab to all the others!) to change it if you are entering transactions from a few days ago. Instead, you must lift your hand, grab the mouse, and click on it, where you have the chance to either choose the date from a pop-up calendar or enter it by hand. The calendar pops up centered on the date, which sounds like a good idea except that new transactions are always at the bottom of the register, so…the calendar ends up being half-obscured by the Dock or simply goes off the screen. Near the end of the month this is a real pain. So I chose the preference to enter the date by hand, and discovered that there’s no date “shorthand”—I have to enter 4/6/04, in other words, not just “6” and have it figure out the current month & year. That becomes very annoying, particularly when one is entering a batch of transactions. Although iBank does completion of categories and payees, it’s a case-sensitive completion, so typing “groc” doesn’t complete to “Groceries”—you have to type “Groc”, and so on. It also won’t let you complete the group of a category. For example, I have the categories Medical:Doctor and Medical:Medicine. Quicken and GnuCash let me enter the characters “me:d” for the first and “me:m” for the second, completing the “Medical” part as soon as I type the colon. iBank requires me to type “Medical:D” and "Medical:M”, respectively. One of the worst problems, though, shows up in what iBank calls “sub-transactions” and Quicken calls “split transactions”. This is where you make one transaction as far as you bank is concerned, but the transaction is made of more than one category. Both Quicken and GnuCash ensure that the subtotals equal the transactions total, and shows the first payee and category when displaying the split in the register. iBank considers the sub-transactions to be more like comments; it doesn’t make sure that the amounts add up, but it does use their categories in reports. This is really easy to leave wrong. Example: I went to Albertson’s and spent $167.42, of which $50.00 was cash back. So I spent $117.42 on groceries and $50.00 on miscellaneous. I enter $167.42 for the transaction, payee is Albertson’s, category groceries. Then I add the two subtransactions: $117.42, groceries, Albertson’s, $50.00, miscellaneous. Now iBank’s report says that I’ve spent $284.84 on groceries! I have to carefully remove the Groceries category and payee from the topmost transaction, but now, in the register, nothing shows at all except an amount. These usability problems really accumulate annoyance because you cannot get away from them or ignore them; they are present in nearly every transaction I enter. This means that for day-to-day use, iBank is kind of annoying. Reporting Just as with reconciling, reporting is done in an instantaneous manner as well. In the lower right there is a pie chart of your largest half a dozen expense categories over the last two weeks, and as you enter transactions, the graph updates. Like other features in iBank, this makes it both easier to use but also “shallower”—I can’t zoom in on my Other category, for example. When you ask iBank to formally make a report, it first of all complains if you have less than two months’ worth of transaction data. I do not understand this restriction at all and I think it’s a bug. There’s a line plot to which I suppose it might apply, but it doesn’t make sense for the default pie graph. When the window does come up, it shows your transactions by category on the left. Not bad. Reconciling As mentioned earlier, this isn’t an operation you perform but something that is on all the time. Both the instantaneous pie graph and the reconciled balance are contributed to by the account list above them: whatever accounts you check are considered. Stability Like Quicken (and unlike GnuCash) iBank has no “Save” operation that you must perform. Instead, it opens, updates, and closes the data file every time for maximum data integrity in case of a crash. iBank did crash once during my review of it, when I selected a large number of transactions and asked it to memorize categories, but beyond that one incident was well-behaved. Conclusion I’m still rooting for iBank and I look forward to seeing the directions in which they take it, but I just can’t use it instead of Quicken, yet. I would be willing to change the way I reconcile, and I would even be willing to insist that my two downloadable credit cards either give me .QIF files (vs. Web Connect) or else go looking for other financial institutions who would. Except for the fact that iBank is still, unfortunately, not as usable as Quicken. Usability is the result of a thousand things done right, and Quicken has its usability polished to near-perfection. There’s also the fact that I’m not confident yet that iBank “scales up” for years of transactions, instead of weeks of transactions, based on how it underperformed when I fed it a four-year .QIF file. So there you have it, folks: Quicken is the last program standing, and based on real technical merits. I’d like to see some competition in the field improve Quicken’s stability and aesthetics—I can imagine a much better Quicken—but even with its problems, there’s no better personal finance program for the Mac that I can lay my hands on today. Posted: Sun - April 25, 2004 at 07:19 AM |
Quick Links
Calendar
Categories
Archives
XML/RSS Feed
Statistics
Total entries in this blog:
Total entries in this category: Published On: May 22, 2005 09:56 PM |
||||||||||||||