In its current form, Ghost satisfies an audience that wants a simple, frictionless, publishing experience.
Comparisons between Ghost and WordPress (or any other publishing platform, for that matter) that are intended to convince you that one is better than another are pretty silly. That said, this comparison post is interesting just to get a sense of what Ghost is if you are familiar with WordPress.
As for me, I like using platforms which let me just write and while Ghost certainly does that, I’m happy with WordPress. I even switched to the visual editor from the plain text editor. You know, just write …
I came across Hilton Lipshitz’s post titled “Standard Markdown” in my feeds that interested me. As you probably know, I use MultiMarkdown routinely and it has changed how I work. MultiMarkdown, of course, owes its origins to John Gruber’s original Markdown project and expands on the original syntax. I followed the link to the Standard Markdown link in Lipshitz’s post and found this:
We’ve been working on the Standard Markdown project for about two years now. As we got closer to being ready for public feedback, we emailed John Gruber, the original creator of Markdown, two weeks ago (On August 19th, to be precise) with a link to the Standard Markdown spec, asking him for his feedback. Since John MacFarlane was the primary author of most of the work, we suggested that he be the one to reach out.
We then waited two weeks for a response.
There was no response, so we assumed that John Gruber was either OK with the project (and its name), or didn’t care. So we proceeded.
Atwood’s original announcement post is “Standard Flavored Markdown“. He then goes on to outline how Gruber took issue with Standard Markdown’s name.
It was a bit of a surprise to get an email last night, addressed to both me and John MacFarlane, from John Gruber indicating that the name Standard Markdown was “infuriating”.
Gruber also seemed to have concerns about the syntax used, based on this tweet:
Atwood and his co-developers were asked to rename their project, shut down the “Standard Markdown” page, not redirect it and apologise to Gruber. They complied, apologised again, and explained how they arrived at the new project name, CommonMark.
Gruber has a number of supporters who have commented variations of this comment –
I think the Gruber has reason to be upset. Name it something other then ‘Standard Markdown’, make it clear that it is not affiliated with, or endorsed by Gruber.
The contradiction is caused by his rights reservation. You can’t reserve all your rights and then, at the same time, grant permissions in a license (which is what a license is). In any event it was probably an oversight on Gruber’s part.
The license permissions are the following:
Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met:
Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer.
Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution
Neither the name “Markdown” nor the names of its contributors may be used to endorse or promote products derived from this software without specific prior written permission.
Clearly the last part imposes a restriction on uses of the word “Markdown” “without specific prior written permission” which, based on Atwood’s post, he and his team never received so they should not have used the word “Markdown” in their project’s name. Gruber’s restriction is analogous to trademark protection and since it forms part of the Markdown license terms, anyone who wants to use the Markdown software in some way has to comply.
That said, from what little we know about Gruber’s response, it seems somewhat curmudgeonly and is one of those things that leaves a bad taste. Part of the reason for this spat is probably that Markdown was described in “open-source” terms and, to many that sounds a lot like “free to use with no restrictions”. That is certainly not the case here. If anything, this is a cautionary tale for developers who need to pay careful attention to the fine print in the fine print, even when it comes to seemingly “open-source” licensed code.
I have a largely unpleasant history with MS Word. I avoid using it as much as I can (and when I do use it, I use it primarily because other lawyers we deal with are using it and I pause my resistance when it can cost me excessive time and money). It is, however, the staple in the legal industry and because LibreOffice is not quite as stable as I’d like it to be, I will continue to have MS Word installed on my laptop for a while still. That said, I am actively exploring alternatives to Word, primarily for document creation on my side and, lately, I am exploring the feasibility of switching my document creation process to plain text with MultiMarkdown syntax. I’m just not sure MMD can do what it would need to do to be a feasible option.
Word will still have a role when it comes to reviewing and commenting on documents exchanged with other lawyers. It has all the markup options and commenting features typically used by lawyers. I wrote previously about using Scrivener for my document creation and that remains one of the better options, just after LibreOffice and, possibly, Pages. The reason I am really interested in MMD as an option is that it is entirely platform and OS neutral. If the syntax to support the document complexity we require in many legal documents is possible in MMD, it becomes possible to create legal documents on any device that supports plain text. That is appealing for a number of reasons:
It means that the cost of a “word processor” to do legal work drops to almost zero;
It means that if you sync your documents to a location that can be shared between devices, you become truly platform agnostic; and
Your risk of documents becoming unreadable over time drops to almost zero because plain text should always be readable and you may just need some sort of interface to translate the syntax.
What are the challenges?
Although the last stages of a document’s preparation and implementation will likely require Word-level reviewing and commenting tools (well, probably), legal documents can be created with just about any text editor or word processor that supports paragraph numbering and formatting, can be translated into a Word format (.doc or .docx) or even a PDF with commenting and markup features enabled (which opens the field a bit) and can handle a couple more complex functions which have become a pre-requisite for legal professionals.
It largely comes down to multi-level paragraph numbering and how referencing works in many legal documents. The starting point is a paper paradigm where legal documents are created with the intention that they are going to be printed out and still need to be functional. Because these documents often include internal references between paragraphs (usually this involves referring to one paragraph from another) and those references need to remain intelligible when printed out, the convention that has emerged is the one illustrated in the image with this post.
If documents were never going to be printed and could remain digital, then this referencing system could be replaced with internal hyperlinks which don’t need to be attached to dynamic paragraph references. In the current model it is important to be able to not only create a reference in one paragraph to another but to have that reference link capable of being dynamically updated as the paragraph being referenced changes position in the document. So, for example, in the image above, paragraph 2.1 includes a reference to paragraph 3.1. The reference in 2.1 can change if paragraph 3.1 is, say, moved lower down in the document to 4.1. When the document is refreshed, the reference in paragraph 2.1 will be changed to 4.1 and the link will remain effective (clicking on that link in 2.1 will take you to the paragraph it references).
The first question is whether it is possible to emulate this referencing model using MMD? It is obviously possible to create internal links in a document using Markdown and it’s forks but I tend to see those internal links being to paragraph headings more often than not. I saw something about internal links to specially tagged sections of the text (you can create footnote links in MMD, for example,), I’m just not sure if you can do something similar between sections of text.
The next challenge is extending the paragraph numbering syntax to accommodate multi-level numbering. Multi-level numbering can be painful if the structure becomes too complex (imagine a clause that extends down to 18.104.22.168.1) but it remains a common method of applying a hierarchical structure to legal documents with headings, sub-headings, paragraphs below each heading level and numbered lists thrown in for good measure. The numbering syntax in MMD seems to be fairly flat and goes up to 2 levels with bullets (not sure about numbered lists) but it would, ideally, need to be able to accommodate more complex paragraph numbering for legal documents. Well, I say that but I have also been thinking about changing that structural model and simplifying the numbered paragraphs somehow. Certainly, when it comes to Web-based documents, multi-level numbering just doesn’t work so I structure my documents using different heading levels, ordinary paragraphs and lists for the Web. If I didn’t have to cater for documents being printed, it would probably be feasible to move more towards a Web model but we are not quite there yet.
So the second question is whether MMD currently or could eventually accommodate this sort of multi-level hierarchy? I suppose a related question is just how much we need such a complex multi-level hierarchy in the first place, aside from being a sort of habit lawyers draw comfort from?
There are some moves in this direction, at least ones I have seen. One example I came across tonight is this tweet by Mike Linksvayer linking to something called Critic Markup which introduces a sort of annotation markup to plain text documents. It looks like this is already being integrated into MMD environments with support in MultiMarkdown Composer 2.1 beta.
Its still pretty rough but its in the right direction. So what I am researching is whether MMD could become a viable alternative, even if it is just to create the documents in the first place? Any thoughts?