back to the blog with MarsEdit

As I’ve noted several times over the years, I do almost all my writing in a text editor, BBEdit. But when I write a blog post in BBEdit, the process of getting it onto the blog is not as straightforward as it might be. I write a post in Markdown, convert it to HTML, and copy it to my clipboard. Then I open a browser tab for the relevant blog/blogging platform — WordPress for my personal blogs, Blogger for this one — paste in the text, add some tags, and hit Publish. 
I can do all this very quickly, and save a step or two with Keyboard Maestro, but even so it’s not ideal. The estimable Dr. Drang has written some scripts to post directly from BBEdit to WordPress, but I lack the skills to make those work for me, and I can’t even imagine having the skills to write an equivalent script for Blogger. So… 
I’ve owned Daniel Jalkut’s blogging app MarsEdit for a long time, but just recently have dedicated myself to using it every day — and it’s great, a marvelous piece of software. You can write in rich text, HTML, or Markdown (the last slightly awkwardly, but it works) — it even lets me edit a post in BBEdit if I want. MarsEdit offers very convenient options for pasting in links, and also serves, if you wish to download your previous posts, as a backup for your blog. 
For me, one of the most useful features of MarsEdit is the ability to draft a post in any of my blogs and then with a dropdown menu change it to a different blog (this feature aids in cross-posting also). 
When I’m done drafting and adding tags, I click “Send to Blog” and it uploads flawlessly, every time. 
MarsEdit has been around a long time, and I hope will be around for a long time to come. Frustration with most of the dominant social media platforms has led to a mini-revival of blogging, which I hope will become a full-scale revival. Austin Kleon has been blogging daily for several months now; Dan Cohen has gone “back to the blog”; Gordon White recently wrote, “Last night, sitting by the outdoor fire, drinking and ranting into a wordpress window as in the days of yore was joyous.” The great Warren Ellis has noticed: “My RSS reader is starting to get nicely repopulated, and the more people who notice this, the better the world gets.” 
Let’s do this thing. Let’s bring back the blog. And if you have a Mac and want to make blogging as simple and seamless as possible, use MarsEdit

digital culture through file types

This is a fabulous idea by Mark Sample: studying digital culture through file types. He mentions MP3, GIF, HTML, and JSON, but of course there are many others worthy of attention. Let me mention just two:

XML: XML is remarkably pervasive, providing the underlying document structure for things ranging from RSS and Atom feeds to office productivity software like Microsoft Office and iWork — but secretly so. That is, you could make daily and expert use of a hundred different applications without ever knowing that XML is at work under the hood.

Text: There’s a great story to be told about how plain text files went from being the most basic and boring of all file types to a kind of lifestyle choice — a lifestyle choice I myself have made.

If you have other suggestions, please share them here or with Mark.

Anthropocene update

I promised a kind of summary or overview of my current project on Anthropocene theology, but that will need to wait a while. This post will explain why.

I understand the Anthropocene as an era in which some human beings are effectively the gods of this world but also are profoundly disoriented by their godlike status, while other human beings languish in the kinds of misery long familiar to residents of this vale of tears. That is, I think of the Anthropocene not only in terms of the power some humans have over the animate and inanimate worlds, but also in experiential and affective terms: what it feels like to be so empowered or, equally important, to be powerless in the face of other humans’ power.

The idea of articulating a theological anthropology adequate to the Anthropocene era occurred to me when I realized that my interest in writing a technological history of modernity and my interest in writing a book about the theological implications of Thomas Pynchon’s fiction were one and the same interest. And all of these topics are explored on this blog, but of course in no particular sequence. I therefore needed some way to find a thread through the labyrinth, to put these random explorations in some kind of order. So what tools did I need to make this happen? As long-time readers know, I am deeply committed to living in plain text: all of my instruments for writing and organizing are plain-text or enhanced-plain-text apps. So my first thought was: Emacs org-mode.

Org-mode is an exceptionally complex and powerful organizational system, one that I have fooled around with a good bit over the years — but I have never managed to commit fully to it, and it’s the kind of thing that really does require full commitment: you just can’t make it work to its fullest extent without embedding those keystroke sequences in your muscle memory. And further, it requires me to commit to the Mac (or Linux) as opposed to iOS, and I have been wondering whether for the long haul iOS will be the more stable and usable platform.

Enter OmniOutliner. Yesterday I went through all my posts tagged antheo, THM, and Thomas Pynchon and copied them into one large OmniOutliner document. This was a very slow and painstaking task, since I needed to turn every paragraph of every post into a discrete row, and along the way I needed to think about what order made the most sense.

Those decisions about order were rough-and-ready, not definitive, because the whole point of the exercise was to get my ideas into a format that would allow me easily to alter sequences and hierarchies — something that OmniOutliner makes very easy, especially since the keyboard shortcuts for moving a given row up or down, in or out, are the same on both MacOS and iOS. Once I had everything in the document, and had decided on a provisional structure, I went through and color-coded the different levels so that that structure would be immediately visible to me.

So now I have an outline of about 70,000 words — goodness, I’ve blogged a lot — and will need to take some time to figure out what its ideal organization will be, where the holes in the argument are, and so on. But even with just the one day’s work, I am pleased at how the thing seems to be coming together. I think this really could be a book, and perhaps even a useful one. There will be a lot more reading and thinking to do, but as I do that reading and thinking, I have a strong outline into which I can place new ideas.

So I’m not ready, right now, to give an overview of the project. I need to meditate longer on the structure that I have and on what its deficiencies are. But I’m going to keep on exploring these issues, and some of that exploration will happen right here on this blog.

on Workflowy and the Tao of outlining

So when I think about software that could seriously alter the way I write, one of the first examples that comes to mind is Workflowy. Now, Workflowy seems to have been designed largely as a task manager, but I’m intrigued by it because its design brings a certain degree of desirable structure to what Giles Turnbull once memorably called the big-ass text file, or BATF.

The BATF idea is simple: put all of your thoughts, ideas, plans, tasks, and drafts in one, well, big-ass text file, and then search inside of it when you need to find something. No folders, no nested hierarchical stuff, just text — though possibly fitted out with tags or other searchable metadata to make it easier to find stuff. (And then, perhaps, move something into its own file when a draft is completed. But only if you want to.) The primary virtue of the BATF is that you eliminate the time spent creating new files and deciding where to put them. You just type. So there’s less friction between the idea and the act of recording it.

(By the way, the Drafts app for iOS has a command for appending the text you type to a selected Dropbox file, which would agreeably strengthen the BATF method for people who use iPhones and iPads: just type out your thoughts and tap that command, and the text, helpfully date-stamped, is added to your BATF and will be visible when you next open it on your computer.).

It seems to me that Notational Velocity and its higher-powered clone nvALT offer a slightly more sophisticated version of the BATF idea: you don’t have just one file, but you have one window into which you type, and searching replaces sorting. I love nvALT and throw almost everything textual into it — I’m typing in it right now, though at some point I’ll probably move this over to BBEdit, just out of ancient habit.

It is the nature of the BATF and nvALT to be unstructured, which is why you might have to think about how to create relevant metadata. And there’s no really visible structure, which can sometimes be disorienting. And here’s where Workflowy comes in.

A Workflowy document is an outline: if you want to use it well you’ll need to master just a handful of keyboard shortcuts for indenting and outdenting and moving up and moving down, but once you do that you’ll be free just to type your ideas. You can, as with all other outliners that I know of, expand or collapse nodes, so you can focus better on what you want to work on. But Workflowy has a distinctive feature that I haven’t seen in another outliner: the ability to zoom in on a single node and make everything else disappear, just by clicking on a handle — and then zoom out again, just by clicking on a word or phrase.

Here’s a screenshot of a part of my Workflowy document:

This is from an in-progress outline of the book I’m working on. Here I’m working on the section of the preface to the book in which I’m identifying the book’s chief theme. Nothing else is visible on screen, except, at the top of the document, its higher levels: I can click on “Preface” to see the whole of the Preface; or on “Christian Humanism and Total War” to see the complete outline of the book; or on “Home” to see everything I’ve put into this document, which might include everything from grocery lists to upcoming travel plans. And then from that Home view I can drill down into any the document at any depth I choose. In other words, Workflowy could become, if I chose, a BATF with an adjustable-view organizational structure. Which is pretty cool.

All that said, I’m probably not going to be using Workflowy. It’s a web app, which means that my data is on somebody’s server, something I don’t like (though it does have nice export options). And I can approximate many, though not all, of its features in OmniOutliner and TaskPaper, which reside on my computer. TaskPaper is not a real outliner — more than a couple of levels of indentation and things start getting unmanageable — but its files are plain text. OmniOutliner files, by contrast, are basically OPML/XML — readable by multiple apps, but not as plain as I’d like. Plus, OmniOutliner is plagued by feature bloat that makes it hard to use well.

I’d love to see a desktop version of WorkFlowy — as far as I know, there’s nothing quite like it. There are plenty of mind-mapping apps, most notable among them being the venerable and much-loved Tinderbox, but those have never worked for me. The linearity of the outline seems to soothe my turbulent mind. A desktop zoomable outliner might stand a chance of genuinely changing the way I think and write.

are these apps changing the way we write?

I’ll admit to some disappointment with this essay on new writing tools by Paul Ford — Ford is a smart writer and the topic seems a good fit for him, but I don’t think he gets as deeply as he could into the legitimacy of the claims made by the makers of some of these writing tools.

As far as I can tell, the tools that he examines either aren’t really about writing at all — for instance, Ghost is an environment for publishing stuff online, stuff that you might write anywhere else — or they amount to taking already-familiar desktop writing tools and putting them online to make collaboration easier. That’s about it.

Not an inconsiderable achievement, mind you. Consider Editorially: it takes a practice that some of us have been following for several years now — writing in a plain-text editor with Markdown syntax which you can convert later to HTML or .doc format — , situates it in a super-attractive editing environment, and encourages sharing your writing with collaborators or editors. If I wrote regularly that way, I’d love Editorially.

Fargo does much the same for outlining — though outlining doesn’t seem naturally collaborative to me, so I’m not sure what the use-cases for Fargo are. But just as Editorially won’t be new to you if you’ve been following plain-text gospel, Fargo won’t be new to you if you’ve used, say, OmniOutliner or, if you’re a real oldtimer, the greatly-lamented DOS-only GrandView. In short, even if the tools you make are really cool, you’re not “reinventing” writing just by coding them in HTML5 and putting them in the cloud.

But I do think that a handful of recent apps have indeed made some significant innovations in writing technology, and I’ll talk about them in some near-future posts.

the plain text gospel revisited

For some years now I have been a big believer in the Gospel of Plain Text: eschewing whenever possible word processors, and indeed anything in a proprietary file format that creates documents I might someday be unable to open — or could open only by paying a hefty upgrade feed to a software maker. Plain text files are very small and fully portable: they can be opened on any computer, and are as future-proof as anything in this vale of tears can be.

But still, I read with interest a recent post by Federico Viticci that points to the limits of a plain-text-only workflow:

I came to the conclusion that, in spite of the inner beauty of plain text, some things were better off as rich text or contained inside an app’s database. By saving links to interesting webpages as plain text URLs, I was losing the ability to easily tap on them and open them in a browser; by organizing tasks in a plain text list, I started feeling like a GTD hippie, presumptuously denying the higher appeal of tools like OmniFocus and Reminders. Plain text is great…until it’s not. It’s silly to deny the fact that, in today’s modern Web, we’re dealing with all kinds of rich content, which gets lost in the transition to plain text or hierarchical file structures (such as Dropbox); managing tasks in a text list is an elegant, old-fashioned concept that I’m sure Don Draper would have appreciated 50 years ago, but that, today, I wouldn’t choose over smart features like alarms, notifications, and location data in my todo app. I didn’t drop plain text altogether: I chose plain text for some tasks, and started using other apps for different purposes.

I get that — but I think Viticci is neglecting a really interesting development in recent writing software, what we might call enhanced plain text. (Maybe there’s an actual name for this and I just don’t know it; if so, please let me know in the comments.) For instance, I am writing this post, in plain text, in a remarkable new iPad app called Editorial. But this is what I see as I type:

In Editorial, I create plain text files but, instead of a .txt file extension, I label it as .md, for Markdown, John Gruber’s simple markup syntax. Editorial then provides appropriate syntax highlighting, as you can see from the image, and when I’m ready it will, with a single click, convert this document to nicely formatted HTML, ready for posting.

But, as when you view an HTML file in your browser (HTML files also being plain text), what changes here is merely the presentation, not the text itself. If I ever find myself trying to open this file in a text editor that doesn’t recognize the .md extension, I just have to change it to .txt and my file will be perfectly readable. So an app like Editorial gives me the simplicity and portability of plain text with structural markup that makes that text easier for me to read and use.

Similarly, when I’m on my Mac I take all my notes in an app called nvALT, in which I use plain text files only — but the app recognizes links I paste or type in and makes them clickable, and in one note I can link to another one simply by placing its title in [[double brackets, like this]] — and now that title becomes clickable: a click takes me to that note. This, along with the use of tags, enables me to keep all my research for the book I’m working on highly organized and easily accessible — a major boon for me.

Or consider TaskPaper, an app that’s far too little-known: it’s a simple but very useful task manager, which can also serve as an outliner. In TaskPaper I can keep track of projects, tasks, and sub-tasks in a hierarchical list with clickable tags; and I can create a color scheme that keeps all these elements visually distinct from one another. And yet .taskpaper files are just text files: as with .md files, I can just change the extension to .txt with no loss of data.

And then there’s LaTeX, about which I can geek out so enthusiastically that I probably shouldn’t even allow myself to get started….

Anyway, I love apps that do this: that give the structural and visual appeal we typically associate with complicated and proprietary file formats while retaining the underlying simplicity and universality of plain text. So while there may be good reasons for going beyond plain text at times, those times don’t come around as frequently as many people think. I’m gonna keep preaching that Gospel.

“kill your word processor”

Word, Google Office and OpenOffice all come with a bewildering array of typesetting and automation settings that you can play with forever. Forget it. All that stuff is distraction, and the last thing you want is your tool second-guessing you, “correcting” your spelling, criticizing your sentence structure, and so on. The programmers who wrote your word processor type all day long, every day, and they have the power to buy or acquire any tool they can imagine for entering text into a computer. They don’t write their software with Word. They use a text-editor, like vi, Emacs, TextPad, BBEdit, Gedit, or any of a host of editors. These are some of the most venerable, reliable, powerful tools in the history of software (since they’re at the core of all other software) and they have almost no distracting features — but they do have powerful search-and-replace functions. Best of all, the humble .txt file can be read by practically every application on your computer, can be pasted directly into an email, and can’t transmit a virus.

— Cory Doctorow on “Writing in an Age of Distraction”. I don’t follow all the practices he suggests, but his advice is thoughtful and worthy of serious consideration by anyone who wants to write more and better.

the right tools

“Use the right tool for the job,” Walter Koehler says in response to this post, where I complain about having to use too many communications applications. That’s great advice for carpentry and auto repair, but I don’t think it’s always applicable to life on our computers. There are a lot of highly specialized software applications out there, and while specialization brings certain benefits, it has significant costs as well. A few years ago, I was using one application to write books, another to prepare class notes, a third for essays, letters, and so forth. Each of them was well-tailored for the jobs I was using it for, but I spent a great deal of time (a) switching between applications and (b) figuring out which tool to use for various projects. That got increasingly frustrating over time. Once I made the decision to write pretty much everything in one app my efficiency and clarity of mind increased dramatically. Whether I’m working on class notes or articles or blog posts or books, I’m in BBEdit — I even write a lot of letters in it, which probably doesn’t look all that professional, but hey, I’m a tenured full professor, what do I care? It’s amazing how much you really can do in plain text files if you put a little of your mind to it. And almost everything that I don’t do in plain text I do in my browser, where I have my email (Gmail), and my personal organization. Which means that I spend about 90% of my time in two applications. This simplifies my life, and that makes me happier. Of course, you can carry all this too far. I’m not going to go the Giles Turnbull route and put my whole life in one big-ass text file — though don’t think I haven’t been tempted — and I’m certainly not going to follow the example of those über-geeks who use Emacs for everything from basic text-editing to web browsing, email, life planning, and taking over the universe. Nor am I going to spend all my life in my browser, as some people do who write in Google Docs and have tricked out Firefox with fifty-seven extensions. But sometimes it makes a lot of sense to give up specialization for simplicity.