Recently, Kim started using Evernote. While many tech people and websites that I follow and, for that matter, respect, continue to sing its praises and those of its many add-on capabilities, I must confess that I just don’t see the point.
The main problem is that I don’t know what it does. Or rather, it does so much that making a succinct argument for why one might need it is a losing fight. In and of itself, this is much less a failing of Evernote and more a certain amount of curmudgeon factor on my part. I already have tools to do everything that Evernote does. They are all very good, if not particularly integrated and they are part of my business process. I’m probably not going to become an Evernote convert.
But that’s not really what this post is about. Nor is it about Notesuite, another (seemingly very good and, again, well-reviewed by people I trust) notekeeping-and-the-kitchen-sink app. Notesuite, however, is the catalyst for this post. From the TUAW review:
NoteSuite is available for Mac and iPad, and despite the lack of an iPhone client it is putting a number of apps on notice. In particular, a lot of the stuff I do with Evernote just got replaced by NoteSuite — and I don’t have to pay a subscription to do any of them. NoteSuite is a suite, in a way, but also a tightly integrated application with a ton of well thought out, useful and efficient tools. Imagine a PDF annotation app, note-taking app, reminder app, drawing app and outliner rolled into one. While there are a number of “multi-tool” note apps out there, a few features put NoteSuite far ahead of the competition.
Wow! That’s a lot of features packed into one application. To be fair, I suppose it even calls itself a “suite” so, I should not be surprised that it is attacking, with Swiss Army knife utility, a host of note-like problems. My concern here is that it likely does it with Swiss Army knife effectiveness as well. We’ve all used multi-tools. They’re great to a point. Convenient. An excellent stop-gap or fill-in when the “right” tool is not at hand, but I doubt any of us really want to spend much time driving screws, punching leather, sawing or even cutting with a Swiss Army knife as our only tool.
Steve Jobs and Apple have gotten a lot of press for their focus on design and simplicity. They’ve angered users by producing newer versions of software that remove features that existed in previous versions and they have frustrated potential buyers an tech writers alike with myriad “features” that are either missing or very late to implementation. However, their stuff works. There are no halfway-implemented options that no one uses and the capabilities that are there work as designed.
Simplicity in the design of software didn’t start at Apple, however. Long before most of us were programming, Doug McIlroy provided a UNIX philosophy. While the original 1978 (!) version is a bit longer, his 1994 summary follows:
This is the Unix philosophy: Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface.
Now, that’s a philosophy, not an operating manual. It takes a bit more explanation to get from those 3 sentences to working design patterns, tools and finally an application. Fortunately, someone was kind enough to do that leg work for us and publish The Art of UNIX Programming.
I’ve taken the title of this post from Eric S. Raymond’s wonderful book by that name; The Art of Unix Programming is a wonderful read. It’s available online in .html format and for purchase and I’m sure you can find .pdf and epub versions if you do a little digging.
I strongly recommend reading it. At least through Chapter 1. The collected wisdom includes hundreds, if not thousands of programming man-years of experience. Most importantly, the truths are universal. Most people might take some offense at, for instance the “handle text streams” portion above when clearly, now, we should be exchanging XML or some other meta-data rich content stream. There is probably some truth to that. Of course, there’s no reason that XML stream shouldn’t be stored and exchanged as text…
How many of the applications we use actually follow this philosophy? How many are, instead, a cruft-laden wasteland of rotting features and unused menu items? How many times have we re-implemented the same function even though a perfectly good (or better) implementation is already out there?* How many applications that you use on a daily basis can ingest and export data in useful formats from/to other applications, or are they all closed silos of obfuscated binary formats?
On the one hand, much of this is still just my curmudgeonly attitude. I believe that the philosophy in the Art of Unix Programming is the one true way. There may be (probably are) other perfectly valid ways to design.
On the other hand, as we move away from this design philosophy, we give something up–probably without noticing it until it is too late. Those siloed, obfuscated binary formats and complicated “suites” that don’t talk to anything else are holding your data. How do you export all of your Evernote data to something else? What happens if they decide to no longer support the app on your platform or get bought by some multinational who cuts features you depend on?
What happens to your data?
Google cancelled their Reader service recently. That hurt. Lots of people (myself included) had to scramble to find a replacement service for our RSS aggregation needs.
But here’s the thing: there were plenty of services available. Reader did one thing and did it well. It worked together with other programs and it saved its data in plain text (actually a OPML file). When the time came, moving to another reader was trivially easy and we didn’t lose any of our feeds. Most services even knew where we left off reading on Reader.
Take a look at your favorite programs—at all those cloud-based services you depend on every day. How many of them provide a way to get your data out? How easy is it to export? Heck, where is your data? If you wanted your stuff back, could you get it at all?
Curmudgeon or not, it’s my data and I will control it.
…and get off my lawn. 😉
* for a long time, there were only two spell checkers in Unix/Linux: pspell and aspell. If you built a word processor or a text editor, you didn’t build your own spell checker, you just implemented one of those! If they didn’t do what you wanted, you worked to improve them and the entire user and programmer communities benefited from a better spell-checker.