Tool Failure

So recently I mentioned that I have been using as a personal productivity aid — and thus far, it’s been good for dealing with some small items that had been issues. I’ve gotten very good at hammering away at the daily mundane items, such as taking my vitamins and fiber supplements, and other things that don’t require a lot of pre-planning or thought.

The tool, however, has some limitations, and I’m definitely realizing it — and I’m really considering building my own replacement for it (both web and mobile app). Moreover, it’s making me realize something about the software tools we use in our day-to-day lives.

The Toolbox Analogy

Like the toolboxes in my garage that are full of framebuilding equipment, my bookmarks bar has a slew of tools I use on a day-in-day-out basis. These include, Evernote, Kanbanize, FunctionPoint, and Pocket, among others. Some of these are for work, some are for home, and some of these blur the boundary between the two.

When working with physical tools, an okay mechanic is one who can employ each tool competently. A great mechanic can use multiple tools concurrently (or simultaneously). The big problem with web apps is that there are barriers to being able to use those tools concurrently.

The way I see it, there’s currently three levels of doing so.

The first is just being the King (or Queen) of Copy/Paste. This, I’d argue, is what most people do, and it’s a huge timesuck, leaves a ton of room for error to creep in, and is generally speaking the worst possible thing you could do.

The second is using a tool like IFTTT, which is probably pretty rare. IFTTT, for those not in the know, is a if-then based system that ties together some of the tools above (Pocket, Evernote), along with a few others, plus social media, using simple conditional statements to move data around. The downside to IFTTT is that it only allows for very basic logical chains between apps, has a limited subset of apps, and

Lastly, there’s the API, which I’m sure a lot of geeks were howling about the moment I started writing this portion of this entry, to which I say, duh. However, asking Joe Average Desk Worker that wants to join two tools together to fit his own workflow preferences to sit down and figure out how to get two APIs to talk together is ridiculous. While it’s a trivial task for an experienced programmer, Joe Average isn’t going to have the slightest clue, nor enough time to actually learn the process and then to apply it himself.

So What’s the Solution?

busted_wrenchI have some ideas here, but I’m only just starting to formulate them, seeing as most of this blog post was written off-the-cuff late at night while the kid was asleep and the wife was at work. I’m thinking that a universal standard for site authentication, and a basic scripting language that’s easy to understand and can be used to bring together two disparate tools in a way that makes sense for the end-user, rather than for the people running the web apps. Maybe something like that already exists — I don’t know.

Maybe there’s a philosophical standard that applies here? Again, I don’t know. I do know that if, as a CSM/PM, I want to tie two tools together and make them interact in a way that’s meaningful to me, I shouldn’t have to pull my hair out.