First, my apologies for not giving this blog the attention that it deserves. Since I last wrote about 2010 in review, I’ve been busy with a number of projects — the most pressing of which is the release of iBank 4.2. This new version of iBank includes a slew of enhancements and bug fixes. Here are some highlighted changes/additions that I think users will be most excited about.
1) New transactions default to the last date edited. This has been a feature request since iBank 4 came out. It was a behavior in iBank 3 and I’m happy that we’ve brought it back. Users that save up their receipts and enter a number of transactions at once will really appreciate it.
2) Improved split editing. When a user is editing splits they generally either want one of two behaviors. First, they want the “main transaction” amount to adjust itself automatically so that it equals the sums of the split items. Or two, they don’t want the “main amount” to adjust, but instead they want the split to balance automatically. And frankly, some users want both of these options, depending on whether they are editing a transaction they are about to import or adding a new transaction. So to please both camps, we’ve introduced this:
Split Editor for 4.2
You’ll notice there is an option to “adjust main transaction” that lets you toggle between the two modes. We’ve also moved the + and – buttons to below the table and just made that table flow a little better (and now the focus ring draws as it should!).
3) In-line calculations. This is a BIG one. Ever need to put in that a total for a receipt was 23.76+44.61 ? Well now you can without having to open a third-party calculator or use Spotlight. The new in-line calculation formatter allows for addition, subtraction, multiple and division and supports multiple arithmetic operations. Just note that you should use brackets [ ] for nested operations instead of parenthese ( ) as parentheses are used for many currencies to denote a negative value — e.g., ($12.34) is -$12.34. The other good news is that you can pretty much use the built-in calculations anywhere you are editing an amount.
4) Complex import situations. Some banks generate QIF files that contain very little useful information. For example, a check might have for the payee “Check.” The problem with iBank 4.1.2 is that if you have two or more of these transactions in a single import session, when you go to edit one, the other can change because iBank is trying to be “smart.” This behavior was bad, because it would be too easy for users to miss what transactions where automatically changed based on the newly created import rule. To alleviate this, we’ve added a dialog to iBank asking you if iBank should create an import rule:
Create Rule Dialog
If you choose “Create Rule,” the other appropriate transactions will be changed. If you don’t, iBank will only change the transaction you are editing and subsequent encounters of that specific payee will NOT prompt the dialog again. For users where this is way too much control, press the checkbox to “Always create rules for me” and you won’t be bothered anymore.
5) This one is actually for us. We’ve added a built-in crash reporter to help us with those emails we get saying, “I don’t know what I was doing, iBank just crashed.” As these types of emails are a little too frequent, a built-in crash reporter will help us improve the stability of iBank. If it crashes, the next time you launch iBank you’ll be greeted with a window asking if you want to submit the crash report to us.
Those are the main features that justify the 4.x bump. But rest assured that we’ve fixed numerous bugs as well, as 4.2 will deliver improved downloading from Fidelity, improved report calculations, improved check printing, improved British “localisation” and many more enhancements.
We expect to get this release out for download within the month, with the Mac App Store update to follow (since there’s a lag between submission to Apple and approval). I hope this version really polishes the iBank 4 user experience for everyone.
-Ian
.
