Ever since the “foresight” of Steve Jobs decreed that wired ethernet ports were obsolete and henceforth would be absent from all new Macs (on behalf of network engineers all over the world I curse you, Steve), those of us who need those jacks (because we’re responsible for getting wireless systems to work in the first place) have had to purchase add-on USB/ethernet adapters to do our jobs.
Until recently, I’ve been using this USB-2.0/Fast Ethernet dongle from Monoprice (#6150, no longer available). It has worked fine, but it’s very awkward to use in the field with my laptop, where I literally have to use my lap, because the long, inflexible packaging continually threatens to angle downwards (or upwards, if the Mac slides off my leg) and damage the USB port of my laptop.
Since the amount of junk I have to shovel into a new router to make it work is getting larger, not smaller, I decided to find a USB3/GigE adapter, one where the end connectors were joined by a flexible cord, so as to eliminate the “big lever” effect.
Since I’m a fan of Monoprice’s products, I tried their #11195. Networking-wise, it worked perfectly, but there was one major flaw: either the Ethernet (RJ45) jack was a hair too shallow or its rim was shaped badly, to the result that any Ethernet cable inserted (with very few exceptions) would not lock into the jack no matter how hard you pushed it. In the workshop, it would stay connected pretty well (it didn’t jump out or anything), but in the field it was next to useless, disconnecting all the time. I bought two of these units at the same time, and both suffered from this defect, so it wasn’t just one bad unit.
When I finally got tired enough of picking my cables out of the dirt, I went hunting again. I found this unit sold by OWC. Since it looked suspiciously similar to the Monoprice, I wrote them before buying, to ask if they were rebranding that unit, and explained why I was asking. I got this reply:
This adapter is one that we manufacture ourselves and we have no connection to Monoprice. Newertech is actually owned by OWC and is our own in house accesories brand. Unfortunately our adapter functions like the Apple adapter and the Monoprice one in which the cable will slide in, but it does not “lock” in place like what you are wanting for it. I do not believe that this adapter will be able to fit for your needs. Please let me know if you have any other questions.
Seriously? The $29 Apple adapter (which I’ve admittedly never tried) has this same, basic flaw?
I just can’t comprehend this.
Since they were invented in the 1970s, “locking” has been on the spec list of every RJ45 connector ever made. Other than when a plug has had its prong snapped off, I have never experienced an issue locking any RJ45 plug into any RJ45 jack.
It seems incredible to me that in my search for one particular product (a USB 3 to Gigabit Ethernet adapter) I uncovered three different, independent units in a row suffering from an identical flaw never before encountered—and not even a functional flaw, but a purely mechanical flaw, in a commodity component. What are the odds?
In case you’re wondering whether my search ever succeeded, I eventually found this product (which turns out to widely available from many outlets, both domestic and foreign) offered by a Chinese jobber for the ridiculously low price of $6.24 and free shipping (it took ages, but it was free). The guts (Realtek 8153) are precisely equivalent to all the other GigE adapters I found, but this one actually lets Ethernet cables lock in.
Ah, all the competitors who screwed up… for want of a nail.
Afterword (May 19): I’ve edited the link to the final dongle to point to what I believe is a similar, authentic dongle (which, you will notice, properly admits to being USB2.0, not 3.0) at another vendor. The dongles I received from China worked for a couple weeks, then went belly up. The square logo on the wide end, which says “GIGABIT” on authentic dongles, says “GLAABIT” on the dongles I received, leading me to believe they are cheap counterfeits. Given that it took over six weeks to receive these units to boot, I refuse to recommend the vendor any longer.
I finally got where I needed to be by trying cable after cable in my Monoprice dongle until I found one that would lock in… then left it plugged in and put everything back into my computer bag. A kludge solution, but ultimately effective.
In October of 2014, discovery of the POODLE exploit caused financial institutions around the globe to disable the SSL 3.0 communication protocol practically overnight, effectively killing Intuit’s Quicken 2007 for the Mac, insofar as users who needed to be able to download transactions from their financial institutions.
Intuit, whose reaction to problems in their Macintosh software was always glacial at best, showed practically zero interest in solving this new problem, given that they could finally point users to their new Quicken 2015 product. Their response to POODLE boiled down to, “buy Quicken 2015, or go back to fetching all your downloads by hand (WebConnect).”
Given that my accounting records consisted of three separate Quicken files, one going back a decade, the conversion was bumpy at best. Dozens of times, I ran into the lack of familiar features that I took for granted in Quicken. Still, I was willing to push through the process because IGG Software offers responsive support, including direct e-mail and online chat. (Compare this to Intuit’s deadly lame offering, which is to refer you to an online knowledgebase, and when that fails to work, to dump you into a forum of other users, whom they expect will solve each other’s problems with zero effort on Intuit’s part.)
So here I will endeavor to present one Quicken defector’s experience with the iBank product, in order to give fellow Mac users some ideas of what issues they may encounter if they decide to defect as well.
Things that won’t convert at all
iBank won’t even attempt to convert Quicken scheduled transactions. If you make abundant use of scheduled transactions (I had over 100 active in one file), you will have to reenter them all by hand in your new iBank file. (See below for why the “automatic” creation feature for scheduled transactions isn’t a good substitute.)
Account reconciliation records are also not transferred from the Quicken file. This forces you to do reconciliations over again, especially in the hunt for bogey transactions (described below).
Similarly, no attempt is made to convert stored reports into their iBank equivalents.
Taken together, these three lapses translate into a lot of manual work for the defector. In my case, it took about one and a half full work days to get my iBank files up to the same content and quality as the Quicken files from which they were derived.
Another feature lapse hit me relatively hard. Quicken 2007 knew how to figure out and apply loan amortization, both for loans you took out and for loans you made. One of the advantages that iBank touts over Quicken 2015 is that it can do loan amortization, while Quicken 2015 can’t. This bullet point led me to believe that iBank could handle the writing of loans — after all, if you’re taking out a loan, knowing the amortization is nice and all, but if your calculations disagree with those of your creditor, his rule and yours drool. On the other hand, if it’s you writing the loan, then you have to be able to provide accurate amortization calculations to the borrower, and track the incoming principal and interest properly for the taxman.
As it turns out, iBank has no clue how to handle your writing a loan. If it sees loan asset accounts in a Quicken file to be converted, it doesn’t recognize them as loans or even allow you to specify that they are loans. This is going to force me to do additional manual work each month until this feature can be added to the package, and is probably the major basic shortcoming of iBank with respect to the accounts I have to manage. Apparently, a lot of users have asked for this feature, so hopefully it won’t be long in coming.
Things that won’t convert correctly
The “cleared” indicator of every transferred transaction was set, regardless of whether or not it was set in the original Quicken file. Thankfully, mishandling of the “cleared” indicator seemed to be limited only to the conversion process.
Like Quicken, iBank urges you to categorize every transaction. However, Quicken allowed you to leave most securities transactions uncategorized because it supplied an automatic categorization implied by the transaction type. For example, a long-term capital gain distribution had the transaction type “RL”, and Quicken automatically supplied and entered the category of “•Long CapGnDst”. Somehow, these categorizations get lost in the conversion process, such that every securities transaction ends up uncategorized. iBank doesn’t complain about this, but you start getting bizarre report results (e.g., a pie chart showing that the fifth largest component of your annual income is “Uncategorized”). This forces you to manually edit every transaction in every securities account (at least for the current year, if not more) in order to keep the tax man happy.
In Quicken, it’s possible to use the name of the current account as a category for a transaction, so that you can avoid selecting (or creating) a specific income category without leaving the category field blank. For example, in your Discover account, you could categorize rebates to your bill from Cashback Reward transactions as “[Discover]”.
Such transactions give iBank the vapors. Attempting to “do the right thing” accounting-wise during the conversion, iBank will invent and insert into your account a compensating transaction for the inverse of that amount. Of course, this causes your account not to balance any longer. You have to find these bogey transactions by hand, recategorize all the original transactions, and delete the added ones.
After the conversion process, I also found a number of other strange bogey transactions that were unrelated to the category name issue. These also have to be rooted out by hand, typically by performing years of account reconciliations to narrow down where these transactions have been inserted (because your old reconciliations were not transferred).
In creating these bogey transactions, iBank will sometimes insert an account name as if it were a category name, at which point it will add a “1” to your account name and complain about “duplication” if you try to remove it. Despite what one might expect, I discovered that the transaction that triggered this behavior was not even one that had the account name in brackets in the category field, but one that had an entirely blank category in the original Quicken file! Again, you have to manually re-categorize these transactions, then delete the offending category, before you can correct the account name.
(In the process of searching for transactions that contained non-account “categories” created from existing account names, I used both the “Smart Account” and “Reports” feature to locate such transactions, and discovered a bug where neither feature would identify any transactions that were split transactions, which is how iBank created most of them.)
Operational and Preference Issues
Quicken allows the user to define single character “operators” to modify transaction amounts. For example you could define the letter “t” to signify multiplication by your local tax rate, and “m” to signify multiplication by the standard IRS mileage allowance; then have Quicken compute the deduction for an 85 mile trip simply by typing “85m” in the amount field.
Similarly, Quicken has a set of defined abbreviations for date fields, such as “t” for today, “m” and “y” for the beginning of the current month or year, and “+” and “-“ to nudge a transaction date forwards or backwards.
I couldn’t find support for anything like these in iBank, and I miss them sorely.
It’s worth mentioning that iBank does offer the same basic feature of “calculator math while entering amounts” that Quicken does.
A Need for Speed
Compared to Quicken, iBank bogs down. Enter, change, or delete a transaction, and your machine freezes up for one to 15 seconds before it listens to you again. (It’s not because I’m running marginal hardware; my hardware is maxed up.) Type the first letter into the category field of a new transaction, and your entire machine grinds to a halt while iBank looks through the list of all defined categories. (Seriously, I don’t have that many—use a hash table, guys?) It doesn’t even echo the character you typed until the hang is over!
Some of this speed differential may be due to the fact that unlike Quicken, where account names in category fields were indicated by surrounding square brackets, iBank puts categories and account names in the same namespace. This increases the number of strings that will match the first letter or two of user input in a category field. This is neither good nor bad, but may contribute to the speed issue.
But some of it is just poor prioritizing. Ten minutes into an iBank session, it suddenly decides to “update all accounts.” It pegs the CPU meters (I’ve seen 120%) while almost totally ignoring user interaction. When it’s in this mode, and you’re trying to enter a new manual transaction, it keeps asking you if you want to save your changes—if you say yes, it closes your current entry with whatever incomplete data you already had in it.
If you open iBank with the intent of entering a manual transaction or two, be prepared for iBank’s default processing to get in your way. First, it will download everything from all your financial institutions (even if it’s already done that earlier in the day). If it’s the first time you opened iBank today, the scheduled transactions will appear and demand to be processed, derailing your train of thought. Only after all iBank’s bookkeeping is done can you finally get around to yours. This is what I usually refer to as the “Microsoft model” (“what our software wants to do with your computer takes priority over what you want to do”), and I’m not a fan of it.
iBank’s report feature allows you to specify which categories should be included or excluded, and provides you a handy button to “flip” all the checkboxes. It also allows you to specify which accounts should be included (default is all, and you can’t choose “excluded” instead), but fails to provide the handy “flip” button. This means that if you want to create a report on one or two accounts only, you have to scroll down and click off every other account line. Similarly, the choices for reporting period are rich, save for the absence of one crucial one—”all transactions”—forcing the user to type in a “custom date range” instead. All of this slows down the interface, and should be trivial to address.
User interface issues
This is by far the largest class of issues. Each one is small, and none of them is a show-stopper, but hopefully we will see some of them fixed soon in an upcoming release.
Which hand giveth?
In Quicken, whether a transaction is a deposit or a withdrawal depends entirely on what column you put the amount in, and you are free to use either column when entering a new transaction. In iBank, each transaction is additionally marked individually as a “deposit” or “withdrawal,” which is not only redundant, but often contradictory. In many of my iBank ledgers, I have transactions marked as deposits whose amounts are in the withdrawal column, and vice versa, along with other transactions whose types match their columns. This is true of both converted and new transactions.
For now, I have given up predicting whether my manual entries in any given ledger should be characterized as deposits or withdrawals — I try both to see which one opens up an amount field in the proper column, and then stick with that one.
Time to move on
Like Quicken, iBank will show you the possibilities to complete what you’re typing, but unlike Quicken, if you hit tab to accept one of them, it will simply finish the entry and leave you in the same field, instead of finishing the entry and moving you to the next field. This is a less-then-optimal choice that slows down the typist, and occurs in a number of other contexts as well.
On a similar topic, iBank is not at all consistent in providing you with a useful cursor focus. For example, when you are attaching an account to an online financial institution, iBank asks you to type the name of your bank, and supplies a field. You begin typing, only to hear “plonk! plonk!” because your cursor is not actually in that field; you first have to hit tab or click inside the field, an unnecessary effort. Similarly, you are in “no field” when you create a new manual transaction, and in a number of other iBank interactions.
Some windows are more equal than others
Quicken allows you to bring up windows for several accounts on your screen. iBank allows you to pull up auxiliary windows for additional accounts, but they don’t have the same functionality as the “main” window. For example, you can delete an existing transaction only in the main window–the auxiliary windows will ignore you if you try it.
In fact, the delete operation is even more problematic: even if you select a transaction in the main window and try to delete it, you will be ignored unless you have actually placed your cursor inside an individual field in that transaction—then the transaction will be deleted.
Spread (out) sheet
Quicken has always suffered from an annoying “menu bar” across the top of the screen that limits where you can place any of their account windows, even when it is not the frontmost application. This limits your screen layout flexibility when you are trying to compare a Quicken account with some other ledger (like a screen shot from another account file).
iBank’s “Open in separate window” has a much smaller no-man’s-land area in this regard. Unfortunately, each iBank ledger line is about 50% taller than its Quicken counterpart, so fewer of them fit on a page, making ledger comparisons more unwieldy after all.
Strictly lunar logic
Earlier, I mentioned that scheduled transactions won’t convert and have to be reentered by hand. Now, iBank does have a shortcut method of allowing you to choose existing transactions and convert them to scheduled transactions, but the results are often less than satisfactory unless the bulk of your scheduled transactions are monthly.
The shortcut simply adds one month to the original date, and schedules the transaction every month. If you have a significant number of annual, twice-annual, or quarterly repeating transactions, it’s almost more effort to correct the resulting entry by hand than it would’ve been to type it in from scratch.
Let automatic be automatic
In Quicken, it’s possible to create scheduled transactions in a “just do it and shut up” mode, whereby the transactions are automatically entered on the correct date without requiring any human interaction. Unfortunately, iBank requires human interaction for every scheduled transaction. It allows you to choose how far in advance this human interaction will be solicited—if at all—but if you don’t remember to go in manually and process them, they won’t be processed.
Quicken also allows you to indicate that a transaction is due periodically, but that the amount will vary, so it will ask you for the correct amount before entering it. iBank has no concept of varying amounts– if you schedule a transaction, it will be for a constant amount.
Quicken’s approach to downloading information from your financial institutions is that you request a session manually, after which it presents you with a list of new transactions it found, and asks you to do the proper thing with each of them.
iBank provides a lot less handholding — it automatically downloads your information every time you open an account (somewhat less efficient), but then depends on you to remember to perform the necessary post-processing.
Dude, where’s my transaction?
iBank’s approach to searching is much less comprehensive than Quicken’s. If you want to find all transactions from “John Cooper,” you type that into a search field at the top of an account window. But if he appears in more than one account, you have to open each account individually and do this for every one. And some windows, like “Scheduled Transactions,” have no search field at all, so you are stuck searching by eye (resorting by payee helps). Quicken, in which you can just hit command-F and search pretty much everything and anything, gets the nod here.
Please sir, can I have no more?
To signify that there are new downloaded transactions that require your attention, a number appears next to each account name with new transactions you need to review. Unfortunately, there’s currently no way to indicate to iBank that you have acknowledged or approved any given transaction — so if you are conscientious about addressing accounts with non-zero numbers, you will often find yourself reviewing, over and over, the same acceptable transactions you have already reviewed. The numbers next to the accounts won’t reset until the next day’s download.
Similarly, in the Quicken world, each individual transaction was downloaded exactly once. Once you decided what to do with a downloaded transaction, you never saw it again.
In iBank, if the recipient of a check waits several weeks to cash it, iBank won’t “match” it to your manually-entered transaction from several weeks earlier, but will present it as a new transaction.
If (using the Quicken method) you delete the “duplicate” downloaded transaction to make it go away, it will keep reappearing every time you download transactions. You have to drag it down to the original transaction to “merge” it and keep it from reappearing. (This is a handy feature, it’s just that the connection between using it and making a transaction stop appearing over and over is non-intuitive.)
Quicken enters automatically-scheduled transactions in alphabetical order of payee, an aid to certain tracking strategies. iBank enters them in no particular order. (But a bonus: iBank allows you to drag transactions within a given date to rearrange their order, which Quicken doesn’t.)
iBank’s scheduled transactions let you choose a period of weeks, months, or years… but not days! If you have a biller who bills every 30 days (he says, “this is a normal business standard,” but I’ve never seen another biller do this), you’re out of luck.
Here are the aspects in which I find that iBank shines compared to the old regime.
For online connectivity, iBank is the champion. It can communicate with every financial institution I deal with, including PayPal and one credit card holder that Quicken has never been able to talk to, plus an investment firm that Quicken hasn’t been able to talk to for about six months. True, some of these institutions are reachable only through IGG’s “Direct Access” pay service, but I find the annual subscription rate reasonable for the work I save and the 100% connectivity I achieve.
iBank has a control that allows you to view only the “uncleared” transactions in an account, which is a great timesaver. It would be an even better feature if it recomputed the “totals” column to reflect the uncleared total, instead of just reprising the useless account total figure from the original transaction position.
Similarly, iBank allows you to “reconcile” any account you define; as opposed to Quicken, which only let you reconcile bank, credit card, and securities accounts. I’ve wanted this capability forever, and will be making good use of it now.
iBank’s “check number’ field is long enough to store the “transaction codes” and “validation codes” you get when making online payments or transfers. Quicken 2007’s fields are tiny—inadequate for today’s e-commerce environment.
In the same manner, iBank can handle bank password requirements as they are defined today. Many institutions are now imposing longer minimum lengths and minimum numbers of digits and/or symbols in your passwords. Quicken 2007 is still apparently enforcing the limitations these banks had back in 2007, which were much more modest. When choosing passwords, people who still use Quicken 2007 are being squeezed by the ever-eroding common ground between the requirements of the bank (“it can’t be too short or simple”) and of Quicken (“it can’t be too long or complicated”).
iBank allows you to have more than one account file open at the same time. How many years I wished that Quicken could do that, but it was utterly incapable. I keep separate files for two family-owned businesses as well as my personal accounts, and whenever I had to transfer money between them, the resulting ethnic fire drill was ludicrous.
Finally, iBank offers you a 30-day free trial period of both their software and their “Direct Access” service. Intuit wouldn’t do that for Mother Theresa.
It should be clear to anyone who has read this far that iBank is far from a “Quicken clone.” IGG Software has constructed their own unique philosophy of what approach works best for bookkeeping, and it has significant differences from Intuit’s.
Expect a non-trivial learning curve and a non-foolproof conversion process, but look forward to an experience mitigated by the refreshing ability to get the immediate support that you never, ever could from the purveyors of Quicken.
Making OS X—and occasionally iOS—just a little clearer for you.