Saturday, February 25, 2012

Writing tools for phone (Android) and desktop (Windows)

I've previously mentioned the benefits of using future-safe notes.

On the desktop-side, I've been using Scrivener. It's a great application and I generally love it. (It stores things using XML and RTF files -- future-proof even if I need to hack together something to get the data from the XML bits.) The problem? I can only use it when I'm at my desktop. With the kids, this means I'm limited in what I can do while I'm away from my desktop.

While I've had good success writing by way of "draft" emails in Gmail on my phone and copying and pasting in to Scrivener, this only works for pounding out my word-count and totally fails when it comes to actually planning what will be written. It worked great for NaNoWriMo, but when it comes to serious planning restructuring it just doesn't work.

I tried EverNote. I had two problems with it: saving a link on my phone was slow (the app is generally slow to load) and it has a lot of features I didn't need. It's a semi-pay application, and the way they charge makes relying on it problematic without paying for it. I had existing tools which covered all other needs except link synchronizing between my phone and my desktop. In the end, I uninstalled it from my phone as it wasn't useful enough for the storage space it occupied.

I recently installed DropBox, and so I've been interested in applications that can make use of it. Link-synchronization using DropBox is easy and fast on my phone. This is particularly the case because I only care about browsing pages on my phone and saving them for future reference on my desktop. It's one-way synchronization and not two-way.

Actually, I installed DropBox because I had installed Ema Personal Wiki. It's Windows and Android software that uses Markdown for light-weight text formatting. It defaults to using DropBox to synchronize between the desktop and the phone. It's a little like ikiwiki, but it sacrifices features for a GUI. Unfortunately, Ema doesn't support directories and uses a different syntax for free-links.

Now, I have had Papyrus installed for some time. It's a super simple plain-text editor. The thing is -- using Gmail directly was generally more convenient. It's strictly offline, so copying things to/from Papyrus wasn't convenient. The addition of DropBox on my phone, means that copying things to my desktop got easier. However, if I'm using Markdown elsewhere, it makes sense to upgrade to a MarkDown-based editor.

On my phone, this led to the installation of Writer. It's a Markdown-based editor designed for writing documents -- complete with word-count functionality, and representing the text-formatting as-you-type. (Not quite WYSIWYG, you get things like *italic* and **bold**. Very useful if you find yourself sometimes using Markdown-special characters.) Writer currently has no preferences. It does not synchronize with anything, but there are plans to eventually support DropBox (and other) synchronization.

Compared to Epistle, Writer looks to be a little earlier on in the development process. Epistle -- while it doesn't have support for word-count -- supports DropBox to the point you can specify the folder to use, so you can have it access the same documents as Ema. (It doesn't do anything with the wikilinks.) You can enable "HTML preview of Markdown documents" which will get you a reasonably accurate representation of the rendered Markdown after it is saved -- but editing the document is purely plain-text, unlike Writer.

Of the two, I'm favoring Writer. If it had DropBox support with the capability to specify the DropBox folder, there would be no contest. I'm a little surprised I've not seen a clearly open-source Markdown file editor. (Ema is a personal wiki, not just a file editor. It just presents bare Markdown in a plain-text window. It would be nicer if it did some styling.)

Just a note, though, Papyrus, Writer, Epistle and Ema all load faster than EverNote did. They're all more responsive and more useful for general note-taking. Epistle (alone) supports "sharing" links. It does so with editable descriptions -- like EverNote provided -- except it is a ton faster. This combined with the fact I've the folder set to use my PersonalWiki folder will mean I'll keep Epistle installed for link-preservation if for no other reason.

With regards to ikiwiki... It's generally awesome. It's a wiki-compiler that can use Markdown as well many other light-weight formatting languages. It's plug-in based and already has more features than many competing products. It uses a real first-class version control system with all the functionality that goes along with that. It's also written in Perl and has some expectations of a Unix-like operating system.

If you used Linux or a Mac, you would get significantly more functionality if you used ikiwiki instead of Ema. Of course, to make it work with a phone would require a bit of work to get it to work well with DropBox and your phone-native Markdown editor. This would be totally doable, mind you. You need only a little more than what Ema already supports to be basically ikiwiki-compatible, and Ema is open-source. Extending it to support [[free-links]] instead of {free-links}, the .mdwn extension instead of the .txt extension, and basic directory support used by ikiwiki should be straight-forward. Most of the other ikiwiki extensions would then be handled by ikiwiki at compile-time.

Anyway, while exploring Ema, and adapting my Magic Door "beat sheet" to a format that Ema could use reasonably (it is where I need to spend some time), it occurred to me that the whole framework I use in Scrivener could be adapted toward a Markdown-based wiki. It would be better in ikiwiki, of course, but it would work in Ema. I'm going to check it out.

To convert the Scrivener notes in to something I can feed to Ema (and to convert back) I'll be using pandoc.

To create the Markdown, I've told Scrivener to export as HTML, then started off telling pandoc to convert from HTML to Markdown. (pandoc can not convert from RTF to Markdown.) The advantage here is that Markdown supports embedded HTML for things that can not be easily encoded in a lighter-weight markup. When the pandoc-generated Markdown looks incorrect, I can copy/paste directly from Scrivener's HTML.

To convert from Markdown to RTF, I'll use pandoc as well as it supports RTF as an output format. The RTF can be easily imported in to Scrivener. Of course, I'll need to verify the conversion works as expected, but the ad-hoc HTML use in Markdown is a key feature, so if that's missing it's really vastly incomplete. (And I'll have to import HTML documents in to Scrivener.)

I may not be using Ema to edit the individual files on the desktop. There are a couple other options for the (Windows) desktop. MarkdownPad is super pretty, but it looks like WriteMonkey totally wins out on features. While they both have basic word-count support, WriteMonkey supports "sprint writing" with count-down timers, a variety of customizable lookups, etc.

This is what I'm thinking so far, at least. I'll be adapting my "empty" Scrivener project with my various sections for novel development in to a set of Ema-linked Markdown-based Wiki-pages. The Ema-style-links can then be machine-converted to be usable for ikiwiki.


  1. Nice post!

    Did you consider wikimind?
    I'm surprised you didn't mention it
    Maybe its a new thing since your post

    The only thing it misses its dropbox
    but its my best experience with a markdown editor

    I will give writer a spin, to see what you are talking about


  2. Mish,


    I hadn't looked at WikiMind. I took a look at it just now.

    WikiMind doesn't do Markdown. It doesn't appear to advertise that it does. Some people comment about Markdown in the comments, but that syntax is some sort of (maybe custom?) Wiki syntax.

    I don't know if it was out when I originally wrote this article. Since it's a commercial application it fell outside of the products I was reviewing.

    Assuming it was a free application instead of a commercial application, (and it didn't have the nag/cripple/advert "features"), I would have rated it as being unusable due to the non-standard wiki syntax. Yes, it is possible to convert WikiMind syntax in to Markdown -- that's an entirely different conversion process, though, and one you'd need to figure out yourself. (And even though pandoc can covert from MediaWiki syntax to Markdown -- or straight to an ebook -- WikiMind does _not_ use MediaWiki syntax.)

    An application is only as useful as the file formats it supports. If something uses file formats that are hard to use with other tools it has a negative impact on the usefulness of the application.

    If WikiMind were patched to use a standard format supported by Pandoc, you could use it with the general approach I mention in my later post to draft an ebook and then create the ebook straight from WikiMind sources.

    With WikiMind using a non-standard syntax, even if it supported DropBox (or some other document sharing service) the usefulness of such shared documents would be extremely limited.

    Yes, you can easily archive your documents and you can read them with any tool that can read plain-text. That's just a core matter of being future-proof, though. Without a standard syntax you need to reformat any WikiMind document to get it usable in any other program.

    The whole point of using Markdown from the beginning and converting from Markdown straight to a Kindle and ePUB book is that you never need to convert formats and keep editing. You don't even really _convert_ to the ebook formats so much as just _compile_ the Markdown in to them. The Markdown remains the "source" documents from the beginning to the end.

    S. W. Black

  3. If I understand correctly, wikiMind uses wikiCreole ... a language that was designed specifically to address the problems you are mentioning. For more info:

    I totally agree with Mish. I use ZimWiki on my desktop (which is not wikiCreole) and wikiMind is the only android wiki manager I've been able to find that does a decent job of rendering it close to expectations... presumably because it was written with the goals in the link above.

  4. Wielder,

    Which problems? The problem of poor cross-application support?

    Goals for a project are one thing. Every project needs some decent goals. It looks like they are reaching their goal for wikis -- but writing tools are hardly about wikis. Some intermediary goals can be served by wikis, but not the core goal of "readers should be able to read my writing offline and in a book/ebook."

    I've heard of wikiCreole. Ikiwiki supports it. That said, when I went to the wikiCreole site to look at tools to convert Creole into something usable by other applications, I found... programing language parsers on a page showcasing how much less support Creole has when compared to Markdown. (No joke. This is on the "Converters" page.)

    I reiterate: How are you going to do anything with your Creole texts if there are no applications available that will convert them to an eBook/PDF for you? Can you reliably add an extra step of exporting the Creole as XHTML so that you can then pick _that_ up with the standard toolchain?

    S. W. Black

    Steven Black