An interview with Notational Velocity developer Zachary Schneirov

For those who use it, Notational Velocity needs no introduction (and for those who don’t, trying it out is the best way to really understand why it has such an ardent following).

It’s a simple application for taking, storing and searching text notes. Its range of features does not extend far beyond those core capabilities, but it is the expert and minimal implementation of each that makes it such excellent software. Its utility comes not from a plethora of features but a high level of attention to each, and an adherence to key principles like modelessness and general simplicity. It is consistently lauded by those who use and write about the Mac and other Apple products, and being open source, its inner workings are no secret. But Zachary Schneirov, the man behind it, is less publicized, content to remain in relative obscurity.

Interested in finding out more about the developer of one of my most-used apps, I contacted Zach earlier this year and interviewed him over email.

Let’s start simple: Who are you, besides the mastermind and developer behind Notational Velocity?

I’m a software developer for and an alumnus of Northwestern University in Evanston, IL (a suburb of Chicago), and a native of the midwest. I’ve been writing Cocoa programs for almost 10 years and have been using Macs for even longer (when I was ten I implored my parents to purchase the Symantec THINK C compiler for our Mac SE/30, but hit a dead end with the Mac Toolbox APIs).

What kind of development do you do for Northwestern University?

I create courseware, web sites, and client-server systems to support language-learning and the humanities within NU’s College of Arts and Sciences. The largest of these projects is licensed externally by a number of high schools and universities across the U.S.

What draws you to Cocoa and Mac OS X development?

I’ve always preferred the Mac OS over other operating systems (despite the increasingly bad UI decisions Apple’s been making since the introduction of OS X), so Cocoa, being the premier development environment for OS X, is the natural choice for me.

What coding languages do you primarily use?

I use Objective-C as it’s native to the Cocoa framework, and I’ve found its dynamic typing and message-passing incredibly useful when debugging and building quick prototypes. C, Perl, Awk, Bash, PHP, and Python are quite handy, too.

What was the first app you developed?

Aside from various conversation simulators that autonomously trolled chat servers at night, it’s probably Installer Observer, which is a program that would detect file and directory changes by comparing a full index of the file system. The main use-cases were identifying extension (“INIT”) conflicts and generally figuring out exactly how an installer had hosed your system.

Briefly, what are some of the UI decisions you see as bad in OS X? [The final version of Lion had not yet been released]

Generally, the forced use of animations for basic UI actions (e.g. minimizing a window into the Dock or displaying a sheet) essentially punishes the user for mis-clicking (or mis-tapping) by making them wait at least twice the time duration of the animation just to return to the previous state. Sadly, Apple seems to be making such animations only more ubiquitous, and now encourages their use by third-parties through the Core Animation framework. Of course there’s also the non-spatial Finder, preferring file extensions over file types, and other unfortunate changes that have been there from the beginning (read John Siracusa’s 2001-era reviews at Arstechnica for better commentary).

But in terms of specific features, I think integrating the iTunes blue “source list” visual style into almost every application is one of the more recent mistakes — not to mention most interface changes that were new in 10.5 including Coverflow, the addition of a search field to every Help menu (which creates a very reliable and frustrating delay each time the menu is displayed), and removing the volume and position controls from the Finder’s media preview panel, among other things. In 10.6 Apple has tried to force Exposé (which incurs an unbelievable overhead in video memory for anyone with more than three windows open) on users by tying it to the Dock, leading to horrifically frustrating scenarios where, for example, an application begins allocating memory in an infinite loop (as Chrome and Safari like to do on occasion), and in trying to force-quit it from the Dock, you hold down the mouse just a little too long, enabling exposé and setting into motion the mother of all swap-storms as OS X is forced to read gigabytes of paged-out apps in tiny 4KB increments.

And (even if the NDA permitted it) I couldn’t even begin to talk about how unusable they’ve made OS X 10.7. Some of the changes are simply beyond my comprehension.

(Sorry, I guess that was more a rant than an answer)

Excellent points, I can definitely agree. Another baffling recent change is the vertical close/minimize/maximize buttons in iTunes, especially from a company that preaches consistency. I’m definitely skeptical of the convergence of iOS and Mac OS X, although I haven’t used 10.7 yet.

With a deteriorating UI that’s becoming “unusable,” do you think you’ll still remain loyal to Mac OS X for the foreseeable future? If so, what’s keeping you?

Unfortunately Windows and most Linux desktop environments seem to be following closely behind, so clear alternatives are hard to see. I guess I at least need to give this emerging touch-pad-centric system of navigation a try. Or maybe I’ll just have to switch my OS to Emacs. ;)

So I’m guessing you’re not a fan of iOS? It seems to be a part (or perhaps the catalyst) of this trend.

Oh, iOS is alright — it’s certainly the most advanced mobile OS for the moment, but I personally don’t find it compelling enough given the current data plan rates, so I can’t provide a user’s perspective.

Now the first company to sell a mass-market wearable computer with a glasses-mounted display would get my money in an instant.

They’d probably give it to you for free — ad-supported! Although until self-driving cars are ready, notifications would be quite dangerous…

Let’s talk about Notational Velocity. When you first released NV, did you have any inkling of an idea how popular it would become, especially among Mac power users and writers? I don’t know anything about Notational Velocity’s “mainstream” popularity, but among bloggers and other Mac aficionados, I see it mentioned all the time.

Well, I wrote the first version of NV in 2002 to solve my problem of keeping track of short, unrelated snippets of information. In the original Mac OS I had used the Note Pad desktop accessory heavily, and when OS X debuted I needed a place to keep notes—but all existing apps either tried to place a multi-document drawer on TextEdit with a slew of buttons, made you file information into discrete fields or categories, had very imprecise searching, or weren’t secure enough for storing passwords (the encrypted database was mandatory in the first version). And while I was proud of my resulting solution to the problem, I never expected it to gain any genuine popularity.

In 2004 Merlin Mann at 43folders noticed NV gave me the idea to have it synchronize its notes with a folder of text files, but I didn’t end up releasing that next update to the program until late 2009 after I became inundated with complaints about NV requiring the Rosetta component in Snow Leopard (it was that old). Within that span of time Simplenote appeared, created (initially) as an homage to the app, and following the renewed interest in NV, Mike Johnston (co-creator of Simplenote) proposed that NV adopt Simplenote’s synchronization API.

I guess given some bloggers’ early promotion and consequent direction of its development (I’m very grateful to Giles Turnbull as well as Merlin), it makes sense that they would continue to see value in NV as a general-purpose writing app. So the fact that a note-taking program / password manager also happened to appeal to bloggers almost certainly helped spread the word.

Excellent, and that answers my questions about the history of NV as well as whether you originally built it for yourself (that seems to be how the best apps come about).

I think the fact that notes can be stored as files in a folder is one of the reasons it maintains popularity, because there’s no lock-in. Anything created in NV can easily be moved, manipulated, or even migrated to another program, without relying on NV to do it. Patrick Rhone mentioned this (Enough — The Minimal Mac Podcast - Episode 2) as one of the advantages of NV over advanced “everything buckets” like Yojimbo and Evernote (personally, I’d love to see a program like one of those that accepts tons of filetypes, but still keeps everything organized in folders, not some giant database).

Simpenote sync also seems to be a big hit — the NV-Simplenote combination is legendary. I use it all the time.

In a response to a user request on Github, you linked to the section on Monotony in Jef Raskin’s The humane interface: new directions for designing interactive systems. One passage stood out to me as prophetic of NV’s popularity: “If I am correct, the use of a product based on modelessness and monotony would soon become so habitual as to be nearly addictive, leading to a user population devoted to and loyal to the product.” I think this explains the status NV has reached (and perhaps devices like the iPhone as well).

I’m glad you noticed that post, actually. I read The Humane Interface twice from end-to-end while planning the first version of NV, and it motivated me to explore Raskin’s ideas of modelessness and monotony in a Mac OS X application.

The combined search/create behavior is one example of the employment of these concepts in NV, though there are a few places where users badgered me until I reverted certain gestures (as per Raskin’s definition) that had previously been monotonic and/or non-modal. For example, turning the “Show-NV” global hotkey into a “Show/Hide-NV” toggle forces the user to observe the state of the screen to determine which behavior will be invoked. Previously, you could bring NV to the front in a single gesture and hide it in another (Command-H) regardless of the order of key-presses and mouse-clicks, but apparently this was not as valuable to people.

It seems like NV development fluctuates a lot, depending on interest — often a year goes by without an update. And then it picks up, like when Simplenote was released, and now, after various popular forks in 2010. With your post on development, and a paid version coming to the Mac App Store, do you plan to start more steady development?

Unfortunately I can work on NV only on in my spare time, so the pace of development has tended to be a function of other things (or an absence thereof) that I’m currently doing. That said, over the past couple of years I’ve updated NV at least several times a month, as you can see from the commit history. So if you were really interested in my progress you could have downloaded the source code at any point and compiled your own copy of the app. And in fact, several of the NV forks did just that, releasing these builds ahead of when I had planned. So the appearance of new changes and bug-fixes may have given some people the impression that development of the program was being continued by others.

Once I begin selling a paid version, however, it will be much easier for me to justify time spent on the project, so I anticipate things changing somewhat.

Do you think you could eventually be working on NV (or doing other independent development) full time, if the paid version is popular enough?

I’d definitely like to do independent development “full-time”, though I very much doubt that a note-taking program alone would generate enough income to make such a lifestyle worthwhile. Fortunately I have several much larger products/projects that I would pursue, and NV would certainly play a role in that.

I for one hope that you transition to full time — especially because I’d like to see what other projects and ideas you’ve got. Can you reveal anything about them — for example, are they in the vein of NV (modelessness, monotony, simplicity, etc.), or something entirely different?

And what’s prevented you from pursuing them so far — is it just a matter of available time?

Me, too! I expect the largest project will be an evolution of the language-instruction system that I’ve been building at my current job. But as far as Notational Velocity goes, I can at least talk about which major problems I’m planning on solving. In the short term, I’ll integrate and refine the most useful features from current and upcoming “forks”, as well as finish up the most important existing feature requests. In the medium term, I hope to have a means of both maintaining the same set of notes in several places without losing any information and without needing to trust system administrators of so-called “cloud” services, as well as accessing those notes on Linux hosts natively and securely. In the long-term, I’d like to apply that solution to the emerging field of “cloud”-based services in general, which (save for a few like Dropbox) are a massive step backward in terms of user-control, privacy, and OS-integration, from what the Internet used to be 20 years ago. And more speculatively, I think NV could be succeeded by an application with even greater flexibility, simplicity, and adherence to those metrics that Jef Raskin championed. Such an application would work a bit differently, perhaps constituting a kind of infinitely associative n-dimensional text-editor.

Pursuing these ideas is a matter of refinement, prioritization, preparedness, and planning — it’s simply a lot of work and time.

Language-instruction – would that be for learning a foreign language?

How would such an anti-cloud system work (anti-cloud seems like a suitable name)? Would the user need to leave one client open and online all the time, or it would it be hosted on a personal server instead of a third-party one?

Right — primarily as a real time, in-class collaborative teaching tool for foreign languages.

But there are all kinds of networking schemes that would be well-suited to building robust “anti-cloud” systems. Here are a few interesting projects I’ve seen:
Syndie and other apps built on I2P
Freenet
GNUNet
RetroShare
Camlistore
TeleHash
MogileFS
CouchDB (Currently used on the desktop as part of Ubuntu One)
YaCy

And of course there are far more basic options available once we move away from the notion of “consumers” and “service providers”. There’s absolutely no reason a community group, organization, or collection of friends couldn’t share everything they needed using protocols and servers that have existed almost since the dawn of UNIX. And with federated protocols like XMPP (on which Google Wave was built) there’s also no reason that such services couldn’t “scale” to include progressively larger circles of contact. In the end, the need for profit can only ever add unnecessary and unwanted side-effects to our medium of communication, whether it’s omnipresent and invisible tracking of everything we read and say, a visual landscape overrun with advertisements, or software that disappears and takes our data with it once we stop paying rent. The “cloud” model is becoming popular first and foremost because it enables new forms of profit. However with just a tiny amount of work and responsibility, we can make the Cloud’s few advantages redundant, re-possess our information, and finally move to an era of worldwide, decentralized, participatory digital democracy.

Impressive list of projects — with a lot of potential. If you’re not already a fan, you might be interested in Eben Moglen’s ideas. He gave an excellent talk at FOSDEM about distributed networking, and the dangers of trusting centralized services motivated primarily by profit. The emphasis was on social networking, but the concepts are just as relevant to any cloud service. I actually wrote an article about the talk, which summarizes it nicely.

You have a lot of interesting things to say about various topics related to technology — UI, Mac OS X 10.7, problems with the “cloud” — topics that a lot of people are interested in. You could write an interesting blog!

Speaking of which, many modern developers are very active online, with social media accounts on sites like Twitter, personal blogs, etc., but you don’t seem to be very public (even Google doesn’t turn up much, besides your obvious affiliation with Notational Velocity, and a bit on DiLL, Northwestern and Installer Observer). Your only current online visibility seems to be directly related to Notational Velocity (the main site, the blog, and github). Why is this?

That speech by Eben Moglen is terrific and I agree with him on every single point.

Regarding my presence on the web, maintaining an open source project requires a minimum amount of public engagement with users and other developers, and this effort is constituted by the github project, the web log, and the nascent mailing list. I’m not an independent software contractor, so maintaining multiple points of contact via blogs and social networking sites would thus contribute much more to vanity than professional development. And if you look hard enough you’ll already discover quite a bit about me online (this is actually the second interview I’ve done about Notational Velocity), so I’d rather not provide any extra fodder to would-be harassers, law enforcement, and domestic intelligence profiling systems. My preferred methods of communication are email and IM, where I can apply appropriate security measures (see http://lavabit.com/secure.html and http://www.cypherpunks.ca/otr/). And I try to respond to email messages, so that’s a much better way of reaching me.

I did do a little bit of searching before and during this interview, and along with Installer Observer and DiLL, I came across Cheese Lord Studios and even a picture. I missed the interview; I didn’t expect it to be in French (I’m assuming that’s the one). You just seem less interested in personal postings than many.

Given that you originally wrote NV for your needs, I’m curious, what do you keep in it?

Ha, good job.

I use NV to store passwords, various keys and account credentials, phone conversation notes, contact data, server configuration notes, and other short textual snippets of a sensitive, archival variety. I use the default “single database” format with encryption enabled and keep about 1700 notes in it.

Interesting! Unsurprisingly, your use is much more as intended than mine (I can’t help from creating some long notes, and I haven’t found another program that allows me to search through so many rich text files so effortlessly and effectively). Given that you recommend keeping notes in NV short, with “one detail/fact/item per note,” I’m again curious: what’s the longest note you have in NV (if that’s even possible to find)?

Well, remember that the longer your notes are, the more difficult it will be to find things in them using NV’s search-filter. If you stuck a long essay into a single note, for example, it would doubtless appear quite often for any given set of search terms. And the fewer notes there are to filter, the more NV’s functionality is reduced to a basic text editor. So if you can partition your data well, you’ll find that NV is quite effective both at drilling down to specific items as well as revealing those that are similar.

The longest note I can find in my database is about 3 pages long when printed, and is mostly Objective-C code.

I know that I’m not using it entirely as I should be, and I’ve definitely noticed that finding what I want is more difficult, but I haven’t found a suitable replacement (where I can search for certain keywords across a number of text documents, and jump from one instance to the next very easily). I take class notes and research notes and quotes, and I’d like to be able to find all mentions of a specific word or topic (or a relevant quote I remember), and in what context. The programs that do feature great search capabilities store everything in one database, and I want to search through rich text files. I wish there was an advanced rich text editor/document manager that took some cues from NV. But I digress.

We already talked a bit about modelessness and monotony, and the website says NV is “an attempt to loosen the mental blockages to recording information and to scrape away the tartar of convention that handicaps its retrieval,” with a focus on the keyboard, “data instead of documents,” and external access. What are some of the other low-level implementation decisions behind NV’s design (or more on the above)?

And speaking of the website, a totally irrelevant question: what’s the reason for the Chinese/Japanese (as opposed to links, like for French and Portuguese)?

In terms of technical decisions, I ended up avoiding many otherwise tempting Apple-provided frameworks and classes. Often they didn’t provide quite enough control, contributed excessive overhead, or were available only in the newest versions of Mac OS X.

Some examples:

Apple’s SearchKit and Spotlight frameworks have high latency, search on per-word boundaries, and are unreliable at returning and ranking results. Unfortunately most mainstream note-taking applications seem to rely on frameworks like these for finding information across notes. NV, however, has its own incremental filtering algorithm which never searches the same part of a note more than once and can find text at any location relative to a word. And its brute-force approach makes it quite predictable — there’s no “intelligence” to second-guess the user. I tuned it for faster than realtime performance with 1000 notes on a 500MHz G3 and it hasn’t been a problem since.

For maximum responsiveness, NV will never update the interface unnecessarily. This requires a fine-grained approach to tracking user-interaction, so that resources can be loaded and displayed using the least amount of work. Cocoa-bindings would certainly have saved me quite a bit of interface glue-code, but in mandating a design based on various Controller classes, it would have blocked not just those optimizations at the UI level, but also those at the data structure level, resulting ultimately in yet another mediocre and unremarkable affirmation of Apple’s Interface Builder technology.

Maintaining an encrypted database of notes was one of the main reasons I built Notational Velocity. And though CoreData makes it incredibly easy to persist an “object-graph” to disk, to this day there’s no way add a layer of encryption beneath it. So NV serializes all note-data to memory, compresses it, and then encrypts it before writing it all out in a single atomic operation that’s protected by the HFS+ metadata journal. And to handle incremental updates (i.e., auto-saving every few seconds), it uses its own incrementally compressed, encrypted write-ahead log.

Finally, in maintaining notes as separate text/rtf/html files, I was able to recycle some directory-scanning code I had written for an unreleased Mac OS X version of Installer Observer. This lets NV detect changes to files in the notes folder and synchronize those changes back to the database with no noticeable overhead, creating the impression that the user’s individual text files are linked directly to NV’s list of notes. In this way NV’s database acts both as a launch-cache as well as a backup of note-files.

Regarding the selective Japanese translations, they were added by my younger brother who designed the web site. We initially translated the application name as the literal “speed notation”, which we later changed (at the suggestion of a native speaker) to a more poetic combination of characters roughly equivalent in meaning to “surprisingly-fast note-taking”.

It’s very interesting to see some of the technology and decisions behind NV; a lot of thought obviously went into it. It wouldn’t be the same program if you had settled for existing frameworks instead of building exactly what was needed. What do you think of Apple-provided frameworks and classes in general — are they good, because they increase uniformity and make development easier, or are they ultimately negative, because they encourage developers to settle for what already exists, even if a better solution could be created? As you wrote, using only what Apple provided for NV’s interface would have resulted in “yet another mediocre and unremarkable affirmation of Apple’s Interface Builder technology.” You also mention reliance on frameworks for search as a weakness of many other note-taking applications.

Oh, I think Apple’s frameworks are great! Cocoa is one of the best SDKs on any platform and has been since the days of NeXT. And as for whether frameworks in general are positive, I’d say absolutely — not only have they saved society millions of man-hours through the sharing of code, but the right kind of uniformity can result in UI predictability and consistency across applications (contrast non-Gnome/KDE Linux apps with those on Mac OS).

My point was that some developers view frameworks as ends unto themselves, and programming as the act of gluing together modules whose functionality only superficially resembles the software’s use case, leaving large gaps in coverage. Yet with enough drudgery, aggravation, and reimplementation, such gaps can be avoided entirely and the resulting solution can become surprisingly, conspicuously better than the status quo.

That makes sense. That’s along the lines of what I was thinking — they’re a great resource, but when used appropriately, not as an excuse to avoid the difficult work behind a better solution. Like any resource, really.

In your recent blog post about development, you announced your intention to release a separate paid version, available in the Mac App Store, with some extra features. Will these new features remain open source, under the same GPL license, or will there be two version of NV, one open source and one proprietary?

I will probably need to create two versions, one open and one closed. But while they’ll have different sets of features, I will most definitely continue to maintain and improve the open source version.

How will you decide which features are only in the paid version?

Several frequently-requested features would take considerable time and thought to implement correctly. And other requested features would otherwise provide me with little motivation due to how I currently use the program. So it’s those features for which I will probably charge money.

Why did you decide to make this shift — to a freemium model, and away from entirely open source?

There are a few reasons. I’ve been getting many more requests for support and features, and these take time to answer. And though I’ve tried to clarify the app’s purpose and design as much as possible on the web site, I seem to have managed to cultivate quite a varied user-base. So I now find myself spending most of my NV-time maintaining features that just aren’t as relevant to me personally. And those things I do want to work on are continually getting pushed back.

On top of that, there’s the fact that I’ve been developing this iteration of NV on and off for the past six years, and have literally not collected a dime (it was never my intention to work for donations).

So my hope is that charging for a new app which takes these other requested features to their respective logical conclusions ought to make it easier to justify my existing and continuing investment in time. The additional income hopefully will also make it easier to pursue those other independent-business ideas I mentioned earlier.

As you mention in the blog post, one feature you’re going to add is Markdown support, which seems to be one of the most popular features of forks. Do you use Markdown? And will this appear in the open source version?

You also mention that it’ll be implemented in a new way — can you elaborate on that?

I write in Markdown when I participate on discussion sites that use it as a formatting language. Otherwise I’m not a writer, blogger, or workflow-ist. While Markdown doesn’t have much at all to do with note-taking itself, it is being increasingly adopted as a tool for writing on the web. And to aid writing is to aid note-taking. Moreover, for whatever reason Markdown-related features now seem to be expected of apps that synchronize with Simplenote. Search me.

I haven’t yet decided how I’ll release this feature and I’m not sure how well it will work in practice, but if I’m successful, I guarantee you’ll have never seen anything like this before. It will be completely original.

Markdown support is a feature I’m definitely looking forward to, and I’m also very interested to see your unique approach.

When there’s a feature you’ve decided you’d like to add (like Markdown, perhaps), how do you determine how to implement it? Not only technically, but from a design or creative perspective.

This is a tough question. The first consideration is whether it’s actually suited to the purpose of the application. It wouldn’t make sense to build into an MP3 player, for example, a system for distributing mobile applications (oh wait, never mind). But following that, I have to find the most appropriate means of revealing the feature’s functionality within the existing user interface. Ideally it needs to enhance existing behaviors while distracting from and intruding upon them as little as possible. There are dozens of perfectly relevant features I haven’t added to NV because they didn’t fit cleanly into its interface. And because the technical implementation flows directly from the design I choose, I could end up rewriting a lot of code if I guess incorrectly. Finally, the implementation itself needs to not, at least in the case of NV, 1) affect responsiveness while browsing/searching notes, 2) increase launch time (e.g., by tracking more information per note), or 3) require rewriting and/or reorganizing a significant percentage of the code (especially when the feature would provide uncertain value to most users).

Why haven’t you ever accepted donations, or any form of payment, until now? Many users would be more than willing to pay; in the responses to this post, people were asking to pay. And why did you now choose to create two versions, instead of accepting donations?

Unfortunately, collecting donations for the development of NV might be perceived by some users as a means of obtaining a guarantee of timely support and attention to their feature-requests. While I try to do this out of courtesy in any case, avoiding this exchange-dynamic helps clarify and reinforce the current relationship. Regrettably, it’s been demonstrated on many occasions that far fewer people pay for donationware than for shareware. So I want to avoid a situation in which an expectation of support and progress develops without any corresponding revenue stream capable of sustaining those activities. 

Of course I tremendously, enormously appreciate all the offers/requests to donate that I’ve received over the years, and this encouragement has already helped me to know that time spent on the project has been worthwhile. Nevertheless, I’d imagine that those asking to donate would rather see me continue to develop the software, and the best way to account for these increasing demands on my time is with an actual reliable stream of revenue.

How do you see the role of other developers in NV’s evolution and development?

I haven’t yet come to a firm decision on the matter; I’m still exploring various modes and methods of collaboration.

What’s your average day look like — and how does NV fit into it? Do you usually work on NV (and other side projects) for hours at a time, or in bits in pieces whenever you find the time?

I’m at work (or traveling to it) between approximately 9 AM and 6 PM, and the rest of my time is spent running around doing errands, preparing for all kinds of trips, arranging and attending assorted meetings, user-groups, dinner-parties, etc., and occasionally, every few weeks for a couple of days I might have enough uninterrupted time to work on one of my many different continuing projects. Unfortunately it’s futile to start any significant programming task unless I know I’ll have a long period during which I can be fully available to focus on it. So in so far as NV is concerned, I’ve generally ended up having only a couple of times a year during which it’s actually possible to develop major features.

Note: Unfortunately, Zach’s busy schedule got the best of him after this question, and we had to end the interview early.

Thanks very much for taking the time to answer my questions.

Read more on Being Efficient, Creativity and Creation, Ideas, Interviews, Life, Media, Opinion, Simplicity, Software, Technology, The Internet.