IGG, the makers of iBank for Mac, list banks that support "DirectConnect" (OFX transactions without website login). This is the kind of information I want when evaluating a bank. (Any bank that supports DirectConnect with (ugh) Quicken should also work with iBank.)
The list is dated 2008, but i'm told it's regularly updated. I hope that's true and that they market this more prominently.
I've been a Toodledo web app customer for years. I use their web task management service with Appigo's ToDo.app.
It's an old relationship born of historic necessity. Toodledo and Todo don't approach tasks and projects the same way, there's the usual awkwardness of dueling data structures. These days most people would want to use Toodledo's cloud service with Toodledo's iPhone app or Appigo's Todo.app with their Todo online.
I've lived with the two for a while though. I appreciate Appigo's elegant iOS client, and it rarely fails me. That reliability means a lot. I know what works with Toodledo and what doesn't; I only use what works. On the other hand, I admire Toodledo's wide range of task integration and data liberation policies, especially the ability to mail myself a task. That's huge.
On the other hand, I need Todo's full text search. I've been pestering Toodledo to provide full text search of my tasks for (literally) years. They won't do it. So I have full text search of tasks on my iPhone but not on the web. On the web I can only search within a field (default is the task title).
Frustrating. I'm ready to leave both of them for something better. Still, I'll make one last try to persuade Toodledo that they can give me 80% of what I want without abandoning their current infrastructure.
Toodledo, here's the search I want built using your save search function, where "term" is the string I want to search on.
See, it's not so hard. You can do this with your current infrastructure by
1. Let me save this search with a name.
2. Let me make the named search my default search.
3. Provide a checkbox that means "search all fields with this string". Check it and gray out two of the fields leaving me one to type in (there are more elegant UIs obviously, this one has the fewest changes).
Thanks for considering this!
Update: Even simpler. Just let us save this as the standard search.
Update 9/12/11: This time Toodledo had a different response to my inquiry: "This is on our to-do list, but it is our policy to not comment on our roadmap or delivery dates for future feature improvements or bug fixes.". Joy!
It's been almost five months since I implemented what I then called Google's two factor authentication. My original enthusiasmwaned significantly as I better understood what Google had done, and how they'd stalled.
Now I'm in a more or less grumpy but stable relationship with Google's "1.4 factor" security model. I wouldn't call it "enhanced" so much as "alternative". If you're not careful, you may end up less secure than when you started. It is definitely not for everyone -- indeed, it's for hardly anyone who uses anything but Google's web UI to access Google services.
I'll share here how I currently live with what Google calls 2-step verification. First, I need to explain what it really is. Disregard Google's labels and descriptions; they're dangerously misleading.
To begin with, consider two kinds of access to Google Services (mail, calendar, documents, etc):
When you sign up for "2-step" you get two kinds of authentication for browser based access to Google services and one kind of authentication for App based access (including many of Google's iOS apps, such as the brand new blogger.app [1]).
Yeah, it's a mess.
There are two kinds of password/token access to Google's browser based services, including the ultimate service -- your Google account security controls:
For App based access you use your Google Account to create one or more long (high entropy, secure if not captured) passwords. Contrary to Google's descriptions, these are not application specific. They're just alternative passwords for non-web services. You can create one and use it for fifty apps (iOS, OS X, XP, multiple machines, etc, etc) or you can create fifty. You can revoke these, but good luck figuring out which to revoke. In practice, if you think you've been compromised, you have to revoke them all. (It's possible that if Google thinks you've been compromised it would revoke only the password used. I'd still revoke them all.)
These Google-generated passwords are powerful. You can't use them for browser access, and you especially can't use them to get to Google Accounts, but you can use them for API access to all mail, all calendar, iOS access to Docs, etc. The more you create, the harder it is to keep track of all all of them, and the more vulnerable you are. Most of us, however, need these. Often.
So here is what I now do
See also:
-- fn --
[1] Wrong! It actually follows a newer practice. It uses a web UI for login. When you try a generated password it requests the browser password then redirects to a (crude) web UI for token entry.
My Eudora archive is in PC format. So converting to OS X is even more of a pain.
A pain I'll have to face sometime. As Eudora fades away conversion options narrow. So sometime soon ...
Today Adam Engst published the comprehensive conversion guide based on his experience with a million message archive. It's not pretty (emphases mine) ...
TidBITS Networking: Converting Email from Eudora: Why I No Longer Live at the P.O.
... Before you get started converting your Eudora mail, there are two cleanup tasks I recommend taking first (and another that I discuss in the Eudora Mailbox Cleaner section below). ... Before you convert your mail, you should compress your mailboxes, to make sure that any deleted messages that haven’t yet been removed from the actual mailbox file are not exported with the rest...
Second, if your Eudora Folder is anywhere near as old as mine, it dates to the classic Mac OS, where the / character was perfectly legitimate in filenames. If, like me, you used / in some mailbox names, you’re going to want to rename those mailboxes before converting them, since some utilities will see the / and create a new mail folder, thinking it’s a Unix directory...... Apple Mail features a built-in Eudora importer that provides the most obvious approach for importing your Eudora archive. If it were the only option, it might be acceptable, but in my testing, it missed converting at least some very old mailboxes. In those it did import, it failed to bring in attachments, messages status, and labels. Worse, in many mailboxes, it appeared to duplicate messages...
... Apple Mail can also import Unix mailbox files, so the question becomes, how do you convert Eudora mailbox files into Unix mailbox files (the two formats are similar, but not identical)? There are a number of options here, including the standalone program Emailchemy and a utility called EudoraExport that’s embedded in Eudora OSE. I had good luck with Unix mailbox files created by EudoraExport...
... now that I have my entire Eudora archive in Apple Mail, I think I’m going to leave it there as well, in case I ever want to move it somewhere else. I’ll stick with either the version of my Eudora archive created by Eudora Mailbox Cleaner (which maintained some message status, along with attachments) or Eudora OSE’s EudoraExport (which didn’t maintain message status, but did bring in attachments and which seemingly found about 120,000 more messages). I’m not a fan of Apple Mail, but its future is guaranteed and I don’t need to use it for anything but access to this email archive...
I'm surprised Apple Mail can handle an archive this large, though Adam tells us search is very slow.
See also:
