Sunday, March 27, 2016

Mint.com without the bitter aftertaste

Mint.com looks pretty nice, but one thing I find irritating to the point of abandoning it is the way they botch the transaction descriptions read in from my credit union's records.

Consider some typical transaction descriptions from my statement, the way they are listed by Mint:

FEB 29   L Time Date   $43.41
FEB 29   L Time Date   $17.83
FEB 29   L Time Date   $6.43
FEB 29   L Time Date   $11.38
The "L Time Date" just happens to be the same on most of the transactions, and comes from a parse of strings that look like the following:
Statement Name: Point of Sale Debit L118 TIME 03:35 PM DATE 02-16 WM SUPERC WAL-MARRALEIGH NC
It isn't too difficult to see how the uselessly ambiguous description is derived, at least, functionally. The actual implementation steps may be different, but the net effect is that the first couple of phrases are excluded, and the next 30 characters or so are chopped and then stripped of non-alphabetic characters. I won't call that simplistic, because for all I know they've got some pretty signification inference algorithms going on back in the weeds somewhere. But when no one size fits all, there needs to be a method of tweaking the methods used.

The pain point here? Intuit has had years to address the issue, but still does not provide one alternative to manually editing a meaningful transaction description.

One might conjecture that Intuit has decided that nobody with technical skills is going to spend time on that particular issue. That would be be rather stupid, if it were true. Judging from the Mint Community comments, they've been ignoring the obvious and painful flaw for years - and grabbing this information is a killer benefit at which Mint is supposed to excel.

The problem cannot be that hard to address, with just a smidgen of imagination. In fact I did a proof of concept that solves the problem just fine for my purposes. If you are a Mint user, or a disgruntled Intuit developer who thinks the people making decisions are idiots, take a look:

jQuery('#txnEdit-merchant_input').on('click', function(e) {
  var truncateAfter = 66; // grab text after this many characters
  this.value = jQuery(e.target).closest('table').first().attr('title').substr(truncateAfter);
})


This Javascript fragment was typed into the developer console in Chrome, while viewing the problem transactions page on Mint.com.  A click on a description highlights it, and configures the merchant input for editing - as Mint normally works. This handler catches any subsequent click on the input, and stuffs the rightmost part of the corresponding statement description into the input. A little tweaking and a little greasemonkey is all it would take to make this a full blown solution, sans Intuit's helpless support.

Now, I have no idea how long this little snot of a handler will continue to work, but it took me just a few minutes to put it together after poking around on the page to see what worked and what didn't. It is a trivial adaptation to use a regexp based match, or provide any other parsing and automation for editing the string for that matter. The information is all there present in the HTML page.

Post a Comment