Could Markdown go mainstream to supercharge our web content entry?

[Malcolm Davison]

There is belief among a growing number of writers who have discovered the benefits of Markdown, that it could soon go mainstream - and be embodied as an option within web design editors and CMS software. It’s meteoric growth means that, at the very least, as content strategists we need to be familar with it.

Writers find they can create web pages faster - simply by adding a few easy-to-remember characters to their text. Their enthusiasm stems from the fact that it is actually quicker than using the styling features built into CMS systems and web design programs.

If you would like a fuller explanation with examples you may like to read my latest blog article, and even try the system out:

http://writingfortheweb.tumblr.com/post/98297649853/supercharge-your-web-content-entry-using-markdown

Markdown has been the preserve of academics, scientists the medical world, enthusiasts and some bloggers. It attracts followers where high volume content production or speed are the priorities.

It’s especially useful where scores of pages of pre-written coding needs to be styled for the web - perhaps reworked legacy content. Most CMS systems allow HTML to be pasted in, so some writers are doing this from their Markdown editor, and saving time in the process.

Complex web pages complete with headers, metatags and footers can also be easily generated by using scripts or shortcut software such as TextExpander.

Perhaps it would be ironic if, by adopting Markdown, we went full circle back to the days when the WWW was originally conceived with programmers hand coding HTML - but this time using a simpler and smarter markup system.

Malcolm Davison 

[Destry Wion]

I don't know why anyone would not want to learn Markdown or Textile (or like me, know both) because they offer so many benefits (to many to bother listing). Even if you don't need them for work on a daily basis, you're going to have the opportunity sooner or later, especially in collaboration. And once you learn one, the other, or both, you'll start using it all the time and wonder why you never did. But, basically, knowing how to use one for when it's needed is no different than keeping a plain text editor on hand for when you need that too. It offers a lot of utility, and especially if you're keyboard-inclined.

I also don't know why Markdown became more popular than Textile because Textile syntax is far more intuitive and easy to use. I.e., it's a lot easier to remember. My hypothesis on that, however, is that Markdown's creator (John Gruber) has kept a much more active presence and reputation online versus Textile's creator (Dean Allen), who's managed to botch both, unfortunately. This lead to old-school tools like WordPress adopting Markdown early on, and the rest is history. Now all the latest collaboration editors like Editorially, Penflip, Draft, Feuill.es, etc all use Markdown and not Textile, unfortunately. In fact it seems like every new editing app coming out anymore integrates Markdown, and understandably so. The next release of Textpattern, another old-school publishing system, which supports Textile natively, will allow you to choose either one on an article-by-article basis, so contributing authors, for example, can use the one they prefer. That's how it really should be for all of these tools.

Google seems to slowly adopt aspects of these editing shortcuts too, though a peculiar mix. For example, in Google+ you can use Textile to create strong, emphasis, and strikethrough (the last one being a little pointless, IMO):

• *strong*
• _emphasis_
• -strikethrough-

And they recently implemented lists in Google Documents via a Markdown-like move: Start a line with an asterisk and space and it starts a bulleted list. Do the same with a "1." and a space and it starts a numbered list. That is really nice compared to how you had to click, click, click to make lists before. So, yeah, these kinds of editing syntax are great for those who like keyboard editing, and who like too write and format their web copy in a quick and tidy way. 

The neat thing about Google Docs implementation (what little there is so far) is that syntax renders near instantaneously right on the spot. This is unlike every other tool I've seen that uses Markdown, for example, where there's an extra click-to-view step or side panel view needed to see the rendered effect. Google Docs seems to be the first that has eliminated that. And I want more! They should just adopt the full scope of Markdown or Textile as an option to the menu editing. 

For collaborative or personal drafting efforts outside of Google Docs, however, you'll often need the non-rendered form of the copy to paste into the publishing system (or automated if you know API use) which then renders the formatting when published. In this case you wouldn't want Google's version of the trick in every text editor. It's nice in Google Docs, though.  

-dw

[Noz Urbina]

Is there a list of benefits anywhere that I could look at?

I am open to it, but I just don't get the point. I feel like Markdown is a flavour of pop music that I just don't understand the appeal of.

On my keyboard * is shift+8. Why is shift+8 [my word] shift+8 that so much better than ctrl+b? Because you don't need ctrl+shift+arrow key to select the word?

I would say that the only use case that it makes is when I am speed-blasting content emphatically on social media or email. In a professional context, I add emphasis and formatting when I am going over the work, not as it's written. Is that just me? Am I missing the point?

I would like to join the dance but I don't seem to be able to catch the beat. There must be something to it to get so many fans, but it's going over my head.

--
You received this message because you are subscribed to the Google Groups "Content Strategy" group.
To unsubscribe from this group and stop receiving emails from it, send an email to contentstrate...@googlegroups.com.
To post to this group, send email to content...@googlegroups.com.
Visit this group at http://groups.google.com/group/contentstrategy.
For more options, visit https://groups.google.com/d/optout.

[Cruce Saunders]

FWIW, there are free Markdown extensions for some popular existing CMS / CEM platforms, for example:

Drupal - https://www.drupal.org/project/markdown

WordPress - https://wordpress.org/plugins/wp-markdown/

Sitecore - http://getfishtank.ca/blog/module-markdown-for-sitecore

Many authors do have Markdown options in place today, but few use it.  

I've increasingly seen Markdown as a wishlist line item on job descriptions.  I assume the employer popularity may be due to productivity improvements within the publishing workflow.  E.g. 'command line' authoring inline is likely measurably faster than WYSIWYG.  Have not seen benchmarks supporting that however.

-Cruce

--

You received this message because you are subscribed to the Google Groups "Content Strategy" group.
To unsubscribe from this group and stop receiving emails from it, send an email to contentstrate...@googlegroups.com.
To post to this group, send email to content...@googlegroups.com.
Visit this group at http://groups.google.com/group/contentstrategy.
For more options, visit https://groups.google.com/d/optout.

--

Cruce Saunders

c...@simplea.com

512-646-2100 x 305

--

We are [A]

simplea.com

[Noz Urbina]

Are these transcribers? I may have missed the boat because in most of the processes I see actually getting on the screen is an insignificant bottleneck. Mostly the problem is figuring out what to write and making sure it's quality. What are the use cases? And yes some metrics would be nice.

[Don R Day]

On 9/26/2014 7:41 AM, Noz Urbina wrote:

Is there a list of benefits anywhere that I could look at?

For WCMS content entry and maintenance, having Markdown as the stored format ensures separation of concerns between the managed side of the content and the rendition of it on request. Publishing is always via conversion to HTML (although an unchanged rendition can be cached, so it is not a huge penalty for this conversion on demand). The converters implicitly validate and normalize the data model, with the happy effect that the generated HTML is squeaky clean for publishing.

That's on the publishing side. On the authoring side, HTML for entry has always had two primary sources of introduced pain. First, users have a hard time creating clean HTML for myriad reasons, but these all narrow down to basic HCI: markup systems are designed more for computational benefit than for direct human involvement. Ah, but WYSIWYG editors should solve the HCI issue by being the interlocutor between writers and the code that actually gets saved, right? That brings in the second pain point: nearly all HTML editors, whether standalone or built into CMS interfaces, are browser based and depend on native editing capabilities within browsers, none of whom have the same underlying data model or output representation. Saved HTML out of any two compared browser-based editors will almost never be the same for the same authored, visual model. Even simply reloading a saved version and saving it with no changes may end up with markup deltas in the source.

So my techie assessment is that everyone involved in a Markdown-based tool chain is seeing improved workflow due, if for no other reason, to the fact that they don't have to go back and fix source issues normally inherent in the markup-based workflow (the rollup of solving the two previous pain point simultaneously).

You know that I am an XML proponent, but everything I've described above are exactly the same benefits one gets from having an XML-aware authoring tool and publishing tool chain. That is because Markdown really is a form of markup (SGML actually formalized a schema notation for recognizing omitted and shorttagged markup events!), so I can rationalize its use for content that does not have a deep requirement for semantics or structural sophistication. For the sake of keeping things simple for the vast majority of content creators, I would even recommend not making Markdown any weightier with new semantic or structural rigor--that is moving it out of its sweet spot and back into the domain where XML-controlled authoring makes much more sense.

Except for the cost issue; the final huge benefit of Markdown is the relatively low cost of the involved software. Even licensed Markdown tools with improved authoring assist features such as enabling use of Ctrl-B to insert '*bold*', are cheaper than most XML editors that work through browsers (a reality that I am deeply disappointed with and wish I could help change).

For the right project that has the right level of expectation (static content publishing for example), Markdown is an elegant consideration, like a light roast coffee. For creating content with the necessary structure, metadata, and semantic richness for adaptive publishing, you'll need to go espresso, as it were.

--

• Don R. Day
• Principal Consultant, ContelligenceGroup.com
• Founding Chair, OASIS DITA Technical Committee
• LinkedIn: donrday   Twitter: @donrday
• About.me: Don R. Day   Skype: don.r.day

• "Where is the wisdom we have lost in knowledge?
• Where is the knowledge we have lost in information?"
• --T.S. Eliot

[Andrew Gent]

Hmmm... I was going to stay out of this. But feel compelled to correct some things.

>>  So my techie assessment is that everyone involved in a Markdown-based tool chain is seeing improved workflow due, if for no other reason, to the fact that they don't have to go back and fix source issues normally inherent in the markup-based workflow

There are a few problems here. The first is that Markdown is not a structured language, so assuming there is no "fix-up" required is likely to get you in trouble some time in the future. 

More importantly, although markdown claims to create XHTML output, it is only talking about its own tag translation. One of the key "values" of markdown is it is a simple language which allows (or even encourages) use of raw HTML in the sources for anything Markdown can't do. (see Markdown syntax > inline HTML). I think we all know what happens when users enter HTML by hand...

Finally, Markdown syntax is relatively well defined, but interpretation of that syntax is not. Wildly differing output/presentation has led to a separate effort to standardize this after the fact. (See "standard markdown")

Having said all that, I would like to give one case example for incorporating Markdown into your content strategy: developers love it. My current development team maintains a number of engineering documents. They refuse to use WYSIWYG tolls (too proprietary) or XML (too complex). So the maintain their documents in markdown. They are not the first group I have encountered with this bias. 

To incorporate these documents into the overall content strategy, I have developed a process for converting them to Docbook and then integrating them into the publishing stream. This is neither a simple or a reliable process. Lack of structure is one issue. Hand-coded HTML tables are another form of hell. But it is simply a cost for having them maintain the content which they "own". 

--Andrew Gent

[Noz Urbina]

Ok. Thanks, Don.

I can see that.  I thought it was principally an authoring benefit and that we were expected to learn a tagging language just so we could do raw coding for the sheer joy of it, rather than wysiwyg editing.

As a clean, unstructured storage mark-up I guess it makes sense. If the editor still renders my headings like headings and my bold as bolds then whether it stores markdown or html is really immaterial to me. I just didn't see the point adding extra keystrokes and looking at unformatted text while I write. "I kept thinking harder to write *and* read? Sign me up!"

Ironically typing on my phone with one thumb I have no formatting, so *this* is actually faster.

--

[Noz Urbina]

You burst my bubble,  Andrew! I was almost getting it there.

[Tony Chung]

Andrew brings up a number of points, the best being that MarkDown allows HTML when MarkDown "just isn't enough". This brings us back to the age old scenario that authors are gonna do what authors are gonna do.

I learned how to link to headings in MarkDown while editing my BitBucket wiki. But I had trouble when I renamed the headings afterward. I'm unsure whether MarkDown can handle filtering attributes and processing instructions without inserting HTML.

At the end of the day, all we'd achieve would be an easier way to get unstructured content into a structured system. This is the same problem explored in the discussion of DITA-wiki round tripping.

Our tools need to be sophisticated enough to recognize the editing form in use, and convert to a structured format that applies to "the rest of the world".

-Tony

[Don R Day]

You are correct, Andrew, about the nature of interpreters leaving their own scent on the results. What the standardization effort may lead to is something already available on the Python side of things with the reStructured Text initiative which includes a standard toolbox (everyone gets the same results--and I'll add "usually" as a disclaimer for what I don't know), and includes an XML export tool that formalizes the underlying DOM implicit in the rSt data model. If this tooling and community existed in the Markdown world, basically all our processes could get behind one common expectation.

I respect your opinion that Markdown is not a structured language. I happen to see implicit structure behind the general parsing of Markdown into a data model that gets serialized into HTML. With a given Markdown interpreter to HTML and some XSLT crafted to finish the uplift to a preferred final structure, I can manage the up-conversion in a way that is nearly impossible for arbitrary HTML. A different use case and selection of tools may produce a different result, but that result will be relatively regular within that use case, which I submit is why it appeals to developers.
--
Don

--

• Don R. Day
• Co-Founder, ContelligenceGroup.com

• Founding Chair, OASIS DITA Technical Committee
• LinkedIn: donrday   Twitter: @donrday
• About.me: Don R. Day   Skype: don.r.day

[Kevin Mahoney]

I believe Markdown is an appropriate response to the increasingly overwrought systems of content authoring and generation, where architects get too bogged down in the process looking to invent solutions to problems that can be solved more efficiently.  Markdown is a great solution to problems that do not require absurd amounts of data granularity.

The only failing I ever found in Markdown was the lack of a golden standard for parsing it.  It was originally developed by John Gruber and was documented just enough for people to run with it… but it never took into account several formatting edge cases meaning that different MD parsers would format data differently.  Recently, however, Jeff Atwood (he runs CodingHorror and co-founder of StackExchange) managed to get John Gruber’s blessing to establish a standard for Markdown, and it’s called CommonMark (http://commonmark.org/).  As paradoxical as it sounds, now that Markdown has a standard it can be effectively used to write unstructured content—or write structured content using a certain set of guidelines.  Going forward, I can only see Markdown making more of an effective dent in the world of processed content.

The last part of that sentence really dovetails into the other thing about Markdown that becomes lost on people… and that is the fact that I’ve dealt many people who assume that Markdown is some wild west, Satan-speaking-if-you-play-it-backwards affront to structured content.  Nothing in this world is all-or-nothing and the same thing applies to Markdown.  When using Markdown for structured content, it simply places faith in the author to abide by the rules. This makes it very easy to deviate from the rules when exceptions do arise, because the user isn’t locked down by form fields.

In the developer world, this faith put in the developer to follow certain patterns has already shown to be just fine.  We have Github, for example, a site that translates all README.md files in a project into formatted HTML for the front page of each project.  If the HTML looks wrong, you just edit the Markdown file until you get it right.  Similarly, in continuous integration environments, they can scan README.md to find section called # Build instructions and perform the appropriate commands for each list item.  Once again, if it imports incorrectly the user can make adjustments to either the source Markdown file or the imported build script.  Human beings are amazing at iteration, and I think we’ve gotten to a point where we spent most of our time iterating on ways to stop iterating on other things (like building a silver bullet CMS—I’m looking at YOU, Adobe Experience Manager).

And, like all things, Markdown is not an answer to every content problem (or even most content problems). But I think as a formatting language it’s being continually sold short.

Also, since I couldn’t really find a place in my rant to sneak this in, I’ll just put it at the end: unstructured content has recently undergone quite the surge of popularity in the developer world.  We’re starting to see data stored less in traditional relational databases (where each facet of information on an entity is stored in a separate table and all linked together by a common entity id).  Once again, it’s a great solution when applicable (like when the structure of data can vary from entry to entry, or when you need performance boosts).  And I think the best thing to come out of unstructured data is something called Javascript Object Notation (JSON).  I’m sure it’s a language people have heard of, but it’s a very lightweight way to wrap data that is easily transferred and manipulated.  It’s not the best to write long pieces of content in, however, but you can always write XML and transpose it to JSON.  In any case, I think that it’s a great method for storing content and we use it all the time, especially for smaller blobs of content and data.

Sorry for the long-winded response to this. I usually lurk these days in this group, but this thread certainly made me want to add my two cents.

Cheers!

-- 

Kevin Mahoney

kab...@gmail.com

360.584.2635
Sent with Airmail

[Mark Baker]

For me, the principle attractions about the Markdown style of languages is not in the initial writing. It is in the editing.

 

With WYSIWYG HTML or XML editors, first drafts generally go fairly smoothly. It is when you want to start editing – moving things around, promoting and demoting things, changing tagging of existing text, that things get ugly. There is often no easy way to do some of these operations. With HTML, you can end up silently creating a mess in the source. In XML you can often be stymied trying to do an edit without creating multiple validation errors. In both cases you often end up in text view trying to sort out the tags. With Markdown style languages, you are always working in the source. There is no magic, and no interpretation of your actions, going on behind the scenes. You can make the edits you need to make without the system fighting back or biting back.

 

After the first draft in HTML or XML, you end up having to work in two worlds: The world of the structure, which is unreadable, and the world of appearance, where you can’t see the structure. Markdown lets you work in one world where the content is readable and the structure is visible.

 

We do still have a very large author community that has been trained in the principle that if it looks right, it is right. For them, WYSIWYG is going to remain more popular than Markdown. But for an author who comes to accept the principle that if it is structured right, it is right, then a form in which both the content and the structure are visible (and the formatting is not) makes perfect sense. It should come as no surprise that developers are among the first to accept this principle, and therefore to adopt this style of language.

 

Mark

--

[Noz Urbina]

Hi Mark

That's a very compelling point.  Restructuring in both HTML/XML is a total pain and something I bitched at XML authoring tools makers to address for years.  Unfortunately it has very little impact on their ability to sell licenses so I can see little hope there in the near future.

[Joe Pairman]

Great discussion. Very good point from Mark about round-tripping / editing. I do like Markdown — I do my blog posts in Markdown and build the blog in a static site builder, Pelican. The posts are stored in Dropbox, and any time I want to draft one or edit an existing one, I just open it up on any device and then edit it (though of course I need to publish it on a machine with my Pelican installation and themes set up).

Markdown also makes a lot of sense in code repositories, particularly in a DVCS system such as Git or Mercurial. Again, you have all the content on any machine that has the repository, and you don't need anything other than a text editor to work with it. Github and Bitbucket handle it really well — when you preview a Markdown file on those sites, you see the generated HTML for that file.

I would say that Markdown is the VHS of lightweight markup. A dominant system among others which are technically stronger. ReStructuredText and AsciiDoc are more consistently specified and arguably more intuitive, but Markdown is certainly more popular and widely used. And as Kevin mentioned, the CommonMark initiative looks set to provide some clarification and consistency at least around the core of Markdown. 

Just one small correction: it's overstating matters to say that CommonMark has John Gruber's blessing — what has his blessing is simply the new name "CommonMark", as opposed to the original name of "Standard Markdown" which he objected to because he feels he has the right to the Markdown name and doesn't like the initiative. The reason he doesn't like it is because he feels that Markdown is popular precisely because of its ambiguity. According to Gruber, developers like standards; ordinary users like simple guidelines that they can tweak or extend as necessary. It's an interesting point, and certainly standards can get bloated, difficult to understand, and expensive to implement (e.g. SVG!) I do think that Markdown can benefit from a clear definition of the core markup, though — the expectations around lists, linebreaks, etc. That way everyone from everyday users to Markdown parser implementers can be sure of what the output is for a given input.

Joe Pairman

Senior Consultant

Mekon

[Mark Baker]

Hi Noz,

 

I share your frustration, but it is a hard problem. In XML there can be half a dozen container boundaries between one line of visible text and the next, and depending on what you want to enter next (new para in this list, new list item, new para after list, new section, etc) you have to get you cursor (or paste your text) into the right container. And in WYSIWYG mode, those container boundaries are invisible.

 

A lot of the time when you edit in WYSIWYG mode, you don’t know exactly what structural unit you have picked up and you don’t know exactly which structural unit you are dropping it into. Oxygen (disclosure: they are a partner and a client of mine) does every trick in the book to help you get it into the right place, and if someone suggested a better trick, I am pretty sure they would implement it. But I can’t think of one.

 

XML makes whitespace meaningless, which gives it a very high level of generality. The genius of Markdown (and similar languages) is that they use line breaks to indicate the end of blocks, and indentation to indicate subordination – which is exactly what we have always done in written text, even fully formatted written text. This makes the structural relationships between things immediately visible, and makes cut and paste and other editing functions straightforward.

 

The downside, of course, is that these syntaxes are far less general than XML. But then, XML has given way to other less general formats in other domains already, JSON being the primary case in point.

 

In particular, these syntaxes all have fixed semantics and no capacity to use a schema to define specific structures. (Given which, what Joe  reports about Gruber’s attitude to standardization makes sense: you can vary the semantics of a markdown-like language by varying the parser  -- in other words, the parser is the schema – specification by implementation.)

 

Or, you could design a version of this syntax capable of expressing different semantics, and of having its structure specified by a schema. Anyone interested in this kind of thing is invited to check out my little side project at https://github.com/mbakeranalecta/sam. (No schema support yet, though.)

 

Mark

[Malcolm Davison]

Thanks for all the expert and thoughtful feedback to my thread, some really interesting contributions here. To sum up, everyone seems to broadly agree that Markdown is great and would be a beneficial addition to the content creators’ armoury. 

And we seem to agree that Markdown will benefit preliminary styling and uploading large volumes of HTML coded text. The only flies in the ointment are structured coding and ongoing editing using the system.

Can styled text coexist safely within supporting tagging and still remain editable in Markdown? Here you need to address the pros an cons of XML, DITA etc. for a specific web project and question why it is needed and the physical location of the tagging relative to the text.

If you are talking about implementing rich snippets and the semantic web (schema.org), the embedded nature of the code could be a step too far for Markdown editing to coexist (that concurs with Kevin’s point). Without doubting SW virtues, there will remain questions as to the ROI of the additional editing time to microtag the data to this level. 

More broadly, considering the benefits and drawbacks of XML, there has been much dialogue on this forum and elsewhere already. In some implementations such as broadly classifying news items on a news website, Markdown entered text may neatly embed within the XML and allow text to remain editable this way. A peaceful coexistence of XML and Markdown. This may also apply to other large volume text / information sites. But this may not be possible if tagging goes to word or phrase level, unless they can be held in tags away from the body text.

But for product promotion sites: extra XML coding can be helpful. But where each patch of promotional description text or headline is delivered in a given style - Markdown may simply be unnecessary. Text can be entered into a CMS form box and displayed in a pre-determined type style. Although Markdown may have a useful role to play on other site supporting pages.

If XML has been adopted for a whole website on the basis of its importance of delivery to smartphones, or benefit positioning on Google then maybe the arguments need to be re-assessed. The ROI for XML may have been over-stated. If not, and it proves to be fully justified and the nature of the tagging is intrusive, then this may preclude the use of Markdown. 

But it could prove to be a financial ROI face-off between XML and Markdown: with techies and writers jousting for supremacy.

I think Markdown editing could still be WYSIWYG, Mark, one window for Markdown text entry, the other for viewing or perhaps even allowing web object manipulation. It's vital that the writer sees and edits text in the context of the look of the completed page.

Thanks Destry for your mention of Penflip (www.penflip.com), it’s a great way to try Markdown coding and editing for free. No excuses for not trying it! An article link there is worth a read: Markdown is the Future of Writing by Robby Ingebretsen digital designer and developer founder of Pixel Lab in Seattle.

As for metrics, Cruce, you can experience the benefits at Penflip yourself very quickly - but selling the concept to others probably does need evidence from case studies. I am interested in these too. But we still seem to be in a ‘discovery phase’ and awaiting the software manufacturers to build the feature into our favourite web editor. I am surprised that Markdown is only moving towards mainstream some 10 years after its inception.

Malcolm Davison 

www.writingfortheweb.co.uk 

[Mark Baker]

Malcolm,

"It's vital that the writer sees and edits text in the context of the look of the completed page."

This is one approach to designing an authoring workflow, but it is not the only one.

Every authoring workflow needs a way for authors to assess doneness. 

If you are cooking a steak, one way to assess doneness is by looking at it. Another is by using a thermometer. The latter is more complex, but less likely to lead to food poisoning.

The WYSIWYG approach to authoring makes correct appearance the standard of doneness. If it looks right, it is right. This has the advantage of immediacy and simplicity. 

It also had numerous disadvantages, such as:

* Inconsistency -- what looks right to each author may be quite different

* Lack of reusability -- the content may not be easy to reuse in other media or in other contexts

* Lack of audit capability -- there may be no way to guide the author to create all the desired content or to audit the content to ensure compliance

* Lack of automation -- in this approach, everything is done by hand.

If you want these things, you need to give the author another standard of doneness -- one based on structure rather than appearance. And since authors are used to "if it looks right it is right" you need to take appearance away from them if you want to them to work to the new standard. (Merely putting XML under the covers is not enough -- I have yet to see a documentation set created in a WYSIWYG XML editor in which all the pages were really correctly structured.

For an authoring workflow to be successful, it is vital to give the authors a clear and unambiguous standard of doneness. 

The look of the completed page is one standard of doneness. Conformance to a specified structure is another standard of doneness. (One of the biggest mistakes of the structured authoring movement, in my view, is that it has tried to get structure while maintaining a "looks right = is right" interface. People will adhere to the most obvious standard of doneness you give them.)

Both are useful standards of doneness, depending on what the rest of your workflow is trying to achieve. 

Mark

--

[Malcolm Davison]

Thanks for those observations Mark. I agree with some of them but not all of the disadvantages.

It reinforces my argument about adaptive and responsive page delivery. Eye-tracking research shows us that positioning of material on screen - headlines, text, images directly affects the user response. So the look and feel of pages delivered to other screen sizes needs to be optimised, ie edited for each screen size. Does anyone do this, even to a basic level? Very few I would suggest.

Pouring text onto a page of a different size without further editing simply damages page effectiveness.

Authors can be trained to a consistent look and feel approach. And for site consistency that's important. That's part of what I do.

I need more explanation to understand your 'lack of audit compatibility' point. Does any of this auditing metadata need to clutter up and be embodied within the body of the text itself?

'Lack of automation' - I don't entirely agree. Standard look and feel can be automated to some extent, although additional light touch editing will be needed. Whether any web software incorporates this intelligence is doubtful. Besides quality writing is 'done by hand' so - crafting a good 'look and feel' is part of the writer's skill. I have a phrase I regularly use 'Writers are also designers of text'.

Certainly the 'behind the scenes' coding must not dictate or compromise the editor's approach to look and feel and the editing process itself. You can't have the tale wagging the dog. It may well be that the whole approach to structured coding needs a rethink to embody Markdown.

Malcolm

[Mark Baker]

Editing the content for different screen sizes is certainly one possible
workflow. The economics of it are a bit daunting, though. Not only is it a
lot more authoring work, it could potentially delay rollout, and there are
all sorts of issues of screen size vs resolution and the sheer number of
different screen sizes out there.

I would argue with your general statement that pouring text into different
sizes damages page effectiveness. I certainly damages some layouts. Of those
it damages, many were probably unnecessarily designed for a fixed size and
could be equally effective in a size-independent or size-adaptable layout.
Those that are necessarily size dependent should certainly be hand-fitted to
different sizes, but we should make as much of our content size-independent
as we can, if only to free up the resources to deal effectively with the
size-dependent content.

Authors can be trained to produce a consistent look and feel, but it is more
difficult to maintain and enforce than is commonly supposed. The problem is
that the only feedback the author receives is from their own eyes. There is
no short-cycle independent feedback to tell them when they are being
inconsistent, and without immediate feedback, the effects of training tend
to fade over time. The greatest athletes and performers in the world still
have coaches: we cannot do consistently good work without immediate
independent feedback.

But the bigger problem with training authors to produce a consistent look
and feel is that it reduces your pool of authors, which can lead to
bottlenecks and delays, which have an opportunity cost associated with them.
Done right, structured authoring can extend you pool of authors by taking
those issues off the table. (Done wrong, it makes them worse,
unfortunately.) It can also shorten cycle times, allowing you to realize
opportunities more quickly.

Lack of audit capability: The reader needs a certain set of information.
Without guidance, the writer will often write only the information they
have, and not realize that the reader needs more. Or the author may assume
that some information is obvious and omit it when in fact the reader needs
it. Structured authoring can provide a template that reminds that author of
what is needed, and can allow an automated process to go through a body of
work and detect potential omissions or deviations from the approved form.
This can greatly improve the quality of content. If authors are "designers
of text" then auditable structure enables you to capture, refine,
standardize, reuse, and enforce those designs.

" Besides quality writing is 'done by hand' so - crafting a good 'look and

feel' is part of the writer's skill." -- I just fundamentally disagree with
this. This view is a product of the desktop publishing revolution. No one
before PageMaker regarded look and feel as part of the writer's skill. This
association is not inherent in the craft; it is an accidental artifact of
the current tool set. Structured writing is very much about breaking this
false association. The commercial appeal of desktop publishing was not that
it produced better content or better design (it did neither) but that it
shortened cycle times. Structured writing, done properly, can shorten them
further.

There is a continuum here, of course. Some content benefits from being hand
crafted. Some content benefits from being structured and engineered. We
don't need one tool or one workflow for all content. We need the right tools
for the job in each case.

Mark

-----Original Message-----
From: content...@googlegroups.com
[mailto:content...@googlegroups.com] On Behalf Of Malcolm Davison
Sent: Saturday, September 27, 2014 9:16 AM
To: content...@googlegroups.com
Subject: Re: Could Markdown go mainstream to supercharge our web content
entry?

[Malcolm Davison]

We'll have to disagree Mark on the impact on the reader of unmodified content on different screen sizes. And, as you confirm, it can't cost effectively be done on any scale. But spending time with usability researchers, as I did recently, using eye tracking software can be very sobering.

'consistent look and feel' - I think we are digressing from the principal topic of Markdown. But quality standards can be maintained - just check out the consistency of hundreds of authors working for GDS Gov.UK delivering hundreds of thousands of web pages. And it's not easy, I agree, but there are control procedures and training that will ensure that it does work.

'audit capability' - OK I see now. A structured approach to writing content could be managed by templating but shouldn't be beyond the wit of the experienced writers to manage without.

"Crafting a good 'look and feel' is part of the writer's skill. -- I just fundamentally disagree"
You are right that writers in the past were almost exclusively involved with delivering text. But that should not be the case today in today's digital world. Tuning text to the layout and providing an acceptable 'look and feel' is a core element in my web writing training. Failure to do this directly affects readability. There's not space here and perhaps not practical for you to attend from the other side of the pond, but if people in the UK want to know more I am running web writing courses in Edinburgh and London next month which explain how.

I agree about 'right tools for the right job'. I often see sweeping generalisations about XML, SEO, web writing, content strategy and much more - now we are beginning to see tailored approaches for specific communication applications. And that is probably the most sensible way forward.

Malcolm Davison
www.writingfortheweb.co.uk

[Mark Baker]

I would just caution about which metrics we pay attention to. For a reader,
the primary user experience is getting the information they want when and
where they want it. The experience of the media is important, but
secondary.

We have only to look at airlines to see that the destination, not the trip,
is paramount. Air travel keeps getting more and more inconvenient and
uncomfortable, but people keep on flying because the primary experience they
are looking for is being where they want to be or seeing the people they
want to see. No one travels to a less desirable location where they don't
know anybody just to ride a more comfortable airline.

For users of content on mobile devices, the destination is knowing what they
want to know at a moment when a mobile device happens to be the only device
they have available. A good mobile interface may be desirable, but not if it
comes at the expense of not getting the information they need. I'll
sacrifice readability for access to information any day, and so will most
folks. This is why I detest sites that deliver less content to mobile, or
that organize it different.

Structured writing may not always give you optimal readability on every
device, but it can make far larger volumes of information more complete,
more reliable, and available sooner, across more devices, for far less cost.
That is the right economic tradeoff most of the time.

Metrics are wonderful, and eye-tracking studies can tell us a lot, but let's
make sure we are measuring the right things.

Mark

-----Original Message-----
From: content...@googlegroups.com
[mailto:content...@googlegroups.com] On Behalf Of Malcolm Davison

[Joe Pairman]

On Sat, Sep 27, 2014 at 5:50 PM, Mark Baker <mbaker....@gmail.com> wrote:

For users of content on mobile devices, the destination is knowing what they
want to know at a moment when a mobile device happens to be the only device
they have available.

Very true, and this goes further than many think. It's not only when people are rushing across an airport or stuck in a waiting room that a mobile device is "the only device they have available". It's also when they're on the sofa and their laptop is in another room in the house. For reading information, tablets and phones often happen to be the most convenient thing wherever you are.

[Geoff Froh]

Apropos, ArsTechnica ran an article today on the controversy over the CommonMark fork of the Markdown project. Hard to believe the Markdown codebase hasn't been updated significantly in more than 10 years!

http://arstechnica.com/information-technology/2014/10/markdown-throwdown-what-happens-when-foss-software-gets-corporate-backing/

--

[Joe Pairman]

I was a bit disappointed by that article. I don't think very many people are using Gruber's Perl script, so the thing about the codebase not being updated is a bit of a red herring. GitHub, StackOverflow, and Reddit aren't using the original implementation, and none of the other Markdown tools I've used are either, as far as I know. The term Markdown normally refers to the syntax, not any particular implementation.

Then there was the idea that Gruber didn't like the CommonMark initiative because GitHub, StackOverflow, and Reddit are "big corporations". I've read pretty much everything he and Atwood have written on the subject over the last couple of months (and before), and he's never implied that. The big problem he had with the initiative was its intention to be the standard for Markdown, as opposed to just another flavor. He's always held that Markdown is better without a standard, and points to the W3C as an example of unhelpful standardization.

I'm in favor of the effort to define the core syntax unambiguously, though I'm a little wary of the CommonMark initiative's intentions regarding extensions beyond that. (They're not tackling extensions such as table / footnote syntax just yet, but haven't ruled it out in the future. That's where the standardization effort really could get a bit labored.)

[Mark Baker]

I'm much in sympathy with Gruber on this. Standardization in this industry has become more of a marketing device than anything else. Standards should be used where they make things easier. But today people seem to be doing things the hard way just for the sake of using standards.

[Kevin Mahoney]

I’ve had the displeasure of dealing with different processors handling Markdown output differently.  While CommonMark certainly goes far beyond the usual scenarios I run into, but if the effort is to standardize the language it would look pretty bad to just “half-ass” it.  I see no evidence that this particular circumstance is a marketing ploy—I see it as an attempt for Markdown’s avid users (chiefly developers) trying to fix some of the most common problems that they’ve had to deal with.  While I certainly have sympathy for Gruber for being beleaguered about this, at the same time he has never come across as an amenable individual, so his comments about "big corporations” is a lot of hogwash in my eyes.

Now, no matter how big of an asshole I think Gruber comes across as (especially after that 5by5 debacle), I still think he was 100% entitled to keep Markdown as is, and I still think that he made the right call stating that Markdown is better without standards.  That’s a moral call and people should stick to their guns on that.  The outcome of CommonMark not being a successful commandeering of Markdown sits much better with me, because people like me still want standards but not on the broken back of someone who developed the language for entirely different purposes, and who reserved the rights to maintain it.  If anything, I’d say it’s a legitimate fork… or about as legitimate as it can get.

Kevin Mahoney

kab...@gmail.com

[Rick Yagodich]

I have stayed out of this conversation so far, mainly because I have been travelling… but as Mark has provided such an obvious in, I will have my say.

The important issue here, all along, has been to do with "making things easier." The contenders in the ring have been XML and Markdown.

The truth of the matter is that XML is an order of magnitude simpler than Markdown. This is not saying that it is easier to hand-craft.

XML has a few very simple rules: the structure of a tag, and that anything that constitutes one tag's content must be fully contained within that tag (you can't have overlaps like <b><i></b></i>). It is inherently flexible and extensible.

Markdown is a hash of effectively random symbols that attribute various meanings. There is no underlying rationale why * at the beginning of a line, with a space after it, indicates a bullet, but * elsewhere without the space and paired with another one later in the same line indicates bold, except convention developed through reuse. There are more elements to learn to understand Markdown. Markdown does not provide inherent flexibility through extension. Markdown is complicated.

XML on the other hand, due to its inherent simplicity and nested nature, then becomes complex. This is why it is harder to write by hand. (Well, that, and that is is more verbose.)

And as this discussion of Markdown vs CommonMark demonstrates, the reality is that Markdown is only a dirty (and inconsistently processed) way of getting content in, which is then translated to XML or something similar under the hood.

Why do we not have a simple editor that provides the word-processor-like interface that requires no specific knowledge of what is underneath, but enforces semantics? Why do we not just have WYSISMUC? Why is there an insistence on getting people to learn a complicated formatting model like Markdown?

It is Markdown's complicated nature that will always be its barrier to mass adoption.

 - R

[Joe Pairman]

Lots of good points there, Rick. I do think there's a lot to be said for WYSIWYM-style authoring, and regarding inline semantic content I still think we need to get to the level of usability of Facebook's mentions UI (see below). 

However, we can't ignore the fact that lots of writers and developers like Markdown. If I think about the popular new writing/publishing tools I've seen recently such as Ghost, Draft, and IAWriter, most of them support it or are based on it. They may tend to be used by tech-oriented circles than others, but it seems that on the whole, people *are* becoming more tech-savvy. So why do they like it?

On Tue, Oct 7, 2014 at 7:51 AM, Rick Yagodich <ri...@think-info.com> wrote:

Why is there an insistence on getting people to learn a complicated formatting model like Markdown?

It's actually very simple to use — that's one of the reasons it's popular. The other, I think, is that you can trust it. There are no hidden codes; there's no danger that your bolding and rebolding of overlapping sections of text or your lists with embedded paragraphs are going to result in horrible markup and problems when publishing. Despite a few inconsistencies (which have been exaggerated here though I support the effort to iron them out), it's pretty easy to look at a piece of Markdown-formatted text and know where are the headers, lists, bolded items, and so on. That also means that you can store your content in Markdown and be confident of using it in any supporting platform. That's partly why I chose Pelican for my blog; all the posts are Markdown files and if I choose to move away from a static site builder to something like Ghost, I can just import them over. No transformations needed.

Of course, Markdown is only simple because it's unambitious. The core of Markdown — the bit that Gruber originally defined and the CommonMark initiative is trying to standardize — concerns itself with simple sections and formatting. Images are there, but tables aren't. Wherever more complex semantics are needed, it's up to implementors to define that additional markup. This has worked pretty well up to now, though I think there's a tipping point at which complex extended Markdown is no longer appealing to authors.

Back to the point about trustability: if we can implement structured authoring systems where people can not only add semantics easily but also be confident that their intention is understood by the system, that's half the battle. Mark and I discussed this after this post of mine: http://blog.joepairman.com/2013/04/is-structured-content-missing-a-trick.html

In that discussion, I mentioned Google+'s mentions UI. However, I think Facebook does it even better. Start typing a name (person/company/page) and you're presented a list of matching entities: thumbnail images and descriptive text. After you've chosen one, mouse over that mention at any time to see what exactly it refers to. That's the kind of experience we need to aim for, in my opinion.

[Malcolm Davison]

Thanks Geoff, Joe, Mark, Kevin, Rick for your interesting contributions. I agree Joe keeping it simple is crucial - that was why it was invented.

IMHO Markdown dialect is unimportant. Let me explain why. The key tags (syntax) that your average writer needs are (and these are pretty much standard across the dialects):

## heading two (etc)
* bulleted line
1. numbered line
*italic*
**bold**
[link text](http://example.com)

That will style 95% of the web page text. Writers will inevitably pick up and use a few other useful tags.

If anyone hasn’t done Markdown before - you could now go to the free Markdown editor at http://markdown.pioul.fr (the link is an editor coded into the browser page) and try these out. Enter on the left window - and view on the right (click Preview top right).

Here is my vision. Markdown is added as a toggle on/off feature in CMS working in tandem with the in-built CMS tools to create tables, insert pictures and media, etc. Using Markdown as you are keying in (or styling cut and pasted content) would be substantially faster than using the CMS features for the whole styling process.

I would resist the idea of training writers up to developer-level use of Markdown, it’s just not needed and would slow down some writers.

For the last two years UK's Government Digital Service has been pioneering new standards in delivering huge volumes of government web material. It has been using as a basis a dialect called Kramdown which is an MIT-licensed superset of Markdown. Here is the GDS vocabulary: http://tinyurl.com/ophf26y. So maybe we could say Markdown has already gone mainstream!

For further GDS (and other) links, and more background you need to get back to my blog at the start of this thread at http://tinyurl.com/mjlstpa - I also mention semantic mark-up too.

Malcolm Davison

[Malcolm Davison]

PS: My email software has added an error in my previous posting the syntax for a hyperlink should be:

[link text](web address)

all entered as plain text.


Malcolm

[Mark Baker]

Rick, 

While this is largely true, there is another factor. XML is abstract; Markdown is concrete. Markdown may be messy, but its immediate concrete relationship to direct formatting effects that people understand makes it simple to understand. XML's syntactic simplicity, on the other hand, comes at the expense of semantic abstraction. There is no direct concrete relationship between XML syntax and a direct formatting effect. That is by design, of course, but the abstraction makes it difficult for people to know what they are going to get. 

Abstractions are hard. The curse of knowledge often prevents us from remembering just how hard they are, but simple and abstract will almost always lose to complex and concrete. Markdown is an order of magnitude more concrete than XML.

And this is why we have not been able to devise a "word-processor-like interface that requires no specific knowledge of what is underneath, but enforces semantics". Such an editor would be providing a concrete interface to an abstraction, and that is very difficult -- perhaps impossible to do. You can hide the tags; you can't hide the abstraction that the semantics represent and still get the semantics you are looking for. 

We can note that creating word processor interface the produce XML is not in itself an issue. Word and Libreoffice both do it. The difficulty is a word processor interface that produces semantically abstract content. 

The real solution, I believe, lies not in the choice of syntax, but in the semantics that we attempt to collect. If we can make the semantic information we collect as concrete as possible, we will improve our chances of getting well structured content. The formula is: the simplest and most concrete semantics necessary in the most natural syntax. The rest we can handle on the back end.

[Adrian Howard]

On 7 Oct 2014, at 07:51, Rick Yagodich <ri...@think-info.com> wrote:

> It is Markdown’s complicated nature that will always be its barrier to mass adoption.

Any yet, over the last three years, zero clients of mine have been using XML for content (unless you count XHTML in a couple of cases).

Many any have used Markdown in various forms.

Curious that…

Adrian

--
adr...@quietstars.com / +44 (0)7752 419080 / @adrianh / quietstars.com
(CSSTWP.com the product team certification programme you can trust! ;-)

[Destry Wion]

Great discussion this turned out to be. 

It's probably safe to say that the value one finds with something like Markdown or Textile (M/T) largely depends on the nature and scale of your work (e.g., enterprise level authoring vs. blog post). If you're dealing with corporate content M/T might not make sense to you. But if you're dealing with smaller projects and make use of any number of lightweight web publishing tools out there, M/T has a lot to offer. But even still, you corporate types probably have your own blogs (WordPress, no doubt) and will find some relief pecking out your posts with M/T rather than WYSIWYG buttons. Or you might write an article for a publisher that uses M/T in it's editorial workflow. If you know the M/T ropes a bit, you'll get along with the publisher more. So, again, it's just something to know that can potentially benefit you, and it's widespread use in tool development is irrefutable.

Anyway, a few trivialities to thrown in... The focus has largely been on Markdown, understandably, but I'd like to come back to Textile a minute just for comparison.

There's been comments about Markdown's complexity. I wouldn't say Markdown is complex, and MDavison is right, you only need a few tricks for 95% of the content (though I think the more you learn, the more you find ways to use it, by my experience), but Textile is even easier and the syntax does seem a little more logical if you look at it. Btw, like Markdown, there are different implementations of Textile, and the most progressive is probably the PHP version that is diligently maintained on Github for Textpattern. And this is the test site (txstyle.org) that links out from the editing panel of a Textpattern installation; the same version maintained at the Github location.

TEXTILE BASICS:

 __italic__ (i)

_emphasis_ (em)

**bold** (b)

*strong* (strong)

Notice there are differences for italic/emphasis and bold/strong, respectively, and that the syntax (underscores and asterisks) is consistently used respective to the type of visual result (slanted copy versus weighted copy). Now look at how Markdown does it...

_emphasis_ (em)

*emphasis* (em)

__strong__ (strong)

**strong** (strong)

Markdown provides no distinction between basic formatting elements like (i) and (b) and semantic elements like (em) and (strong), which screen readers, for example recognize. So if you wanted to italicize all your use of Latin, like I do, or you're titles of foreign work, they would all be read as emphasized when they only need to be italic. And the fact Markdown duplicates the way you create the two styles by using two different marks doesn't help with the learning and memorization process, IMO.

HEADERS:

Markdown uses octothorpes, one for each level of heading, for example...

# (h1)

## (h2)

### (h3)

etc.

By the time you might get to an h6, you're using six characters of type (and you have to remember that it's an octothorpe). But Textile is more intuitive by suggesting the header level, and consistent in character use...

h1.

h2.

h3.

etc

LISTS:

Markdown does bulleted lists like Textile using asterisks...

* list item 1

* list item 2

* list item 2

etc.

But Markdown also allows pluses (+) and hyphens (-) to do the same thing. Some may see this as options. I see it as confusing for people trying to learn because there's no single consistent way.

Numbered lists are a easier in Textile, and it's here you use the octothorpe just like using a asterisk for a bullet. And don't overlook the fact an "#" often means "number" to people...

# list item 1

# list item 2

# list item 3

etc

Compared to Markdown...

1. list item 1

2. list item 2

3. list item 3

'm betting 9/10 times people will quickly pick up the Textile way for numbered lists easier. And what if you have a list of ten items and want to move their positions around later. Now you have items lined up like this, for example: 1., 5, 3. 2, 8, 6. etc. Sure, they may render correctly neverthless, but that doesn't look very logical to the author. Will it drive them crazy and make them edit the numbers to be in sequential order? Probably. With a single octothorpe you don't have that distraction.

Textile provides for definition lists, just like WikeMedia syntax...

; Title (dt)

: data item (dd)

: data item (dd)

: etc 

Markdown doesn't provide for them, as far as I know.

BLOCKQUOTE:

Textile blockquote:

bq. Paragraph text here...

or

bq.. If the blockquote is more than one paragraph...

Continue next paragraphs without any leading syntax at all...

p. Then begin first paragraph after blockquote with an escaped paragraph (p.) to return to normal.

The thing to note here is the intuitiveness of remembering what syntax to use because of the relevance to spelling "bq = blockquote". Easy to learn/remember.

Markdown blockquote:

> Pargraph here

or

> First para here...

>

> Second para here...

Markdown's blockquote isn't hard to type, but it's probably not easy to remember that a 'greater-than' bracket is required. It could just as well be a mark for a bullet, considering all the options for bulleted lists already. Not intuitive.

BLOCK CODE

In Markdown you have to indent each line you want marked as code.

In Textile you just use one intuitive mark to start, just like with blockquotes...

bc. code here...

If you have line breaks in the code, use this...

bc..

Then escape it on the next normal paragraph as done with blockquotes...

p. New normal paragraph

HARDRULE:

Again, Textile goes with a lettered option that is easier to remember due to it's relation with the real HTML element...

hr.

You can even add a class to a hardrule if you want to target one for aesthetic reasons...

hr(slick).

Markdown has you type a series of various characters. Again, not consistent and thus perhaps harder for new learners to remember.

OTHER EXTENSIONS:

Textile can do other things too like Tables and Footnotes, which you can see in the Textile test site mentioned earlier.

Footnotes are pretty slick, but in my opinion, tables are the one thing where these syntaxes fail. I can actually create a fully-structured table in HTML much easier than using Textile. The Textile version is certainly cleaner in the editor, but the specifics of the syntax is quite hard to remember if you don't use tables much.

Textpattern has a Textile plugin one can use that makes a formatting button bar for Textile markup. I don't use it myself, but I can see where a table button would be useful here where you simply indicate how many columns/rows you want, click the button and it gives you the table framework done in Textile to copy/paste into place. Then you just remove what you don't want (e.g., title, tfoot, whatever) rather than struggle to remember how to peck the syntax in. Tables are the antithesis in this case to markdown-like syntax.

With the move to HTML5, there's been more requests for Textile to do things like figures and figcaptions in combination, etc, but this seems to be hitting a limitation point because so far no one has been able to figure a way to do it.

But because Markdown and Textile works interchangably with regular HTML, you can put a figure in HTML format right in flow with copy in Textile and it still renders like it should.

Anyway... one for the Textile camp! ;)

[Mark Baker]

Interesting comparison. It occurs to me that Markdown and Textile each belongs to one the two traditional camps on this subject WYSIWYG vs semantically explicit. 

Markdown is essentially a WYSIWYG approach based on text. It is supposed to be as close as possible to what you would write if you were writing in a plain text editor. Thus anything that looks like a list is treated like a list. 

Of course, no one would ever use six # in a row to indicate a level 6 header in a plain text document. If anything, I suspect they would use explicit heading numbering to express subordination. 3.2.4.6.1.8. I suppose ###### could be considered a generalization of that. 

Textile, on the other hand, seems to be much more in the explicit semantics camp. It would seem to be much easier to understand the intent of the markup in Textile, but harder to just read the document as text. 

I'm in the explicit semantics camp myself, but I have great sympathy for the WYSIWYGs camp's emphasis on the readability of the source. Content source, like code source, is read far more times than it is written, and the readability of the source matters a great deal. 

--

[Rick Yagodich]

On 08/10/2014 16:28, Mark Baker wrote:
> Content source, like code source, is read far more times than it is
> written, and the readability of the source matters a great deal.
>

Diverging the subject of the discussion a bit here (i.e. generalising,
rather than looking at Markdown et al.) and overlooking the word source
in there…

While I do not disagree with the facts of the statement, this mindset
that content is read far more than it is written is part of a much
larger problem in all levels of communication. The emphasis is squarely
put on the end-user experience (the reader) and it is considered
perfectly acceptable for the writer (author) to jump through additional
hoops to get the content ready.

This is a fundamental problem, because when the author has trouble
creating the content, they are unlikely to create the best quality
content. Which, of course, impacts the end-users' experiences… many
times over.

We cannot blindly consider dominance of usage: the roles various parties
play in the communication process have significantly different impacts.
Let's not forget the quality of the author experience.

Obligatory book plug: http://theAXbook.com/ - available to order in 5 days

- R

[Don R Day]

On 10/8/2014 9:45 AM, Destry Wion wrote:

With the move to HTML5, there's been more requests for Textile to do things like figures and figcaptions in combination, etc, but this seems to be hitting a limitation point because so far no one has been able to figure a way to do it.

I'll file that note as a tutorial for now Destry. Now I'm totally convinced that I can't carry both worlds in my head, so I'll choose to stick to the devil I know for now.

But you brought up a sticky point in the current design of HTML and the real value proposition that convertible markup languages (both lightweight and XML) provide for authors: the ability to model something simply and correctly in their domain, and then convert it into the best equivalent HTML representation.

And in this case, you've noted that HTML5 for the first time introduces the concept of labels into the language, but I'll add that the designers chose to use a domain-specific name of figcaption. Had the designers chosen the more generic term "caption" as the label name, then it could be used in the same way inside table for table captions, inside section for section captions, and indeed inside any other grouping where a label is needed but where it is not part of the discourse hierarchy. In an orderly document model, you can gather all fig/captions into a figure list, all table/captions into a table list, etc., but in the disorderly HTML world, it is very hard to discount a heading used as a label for such groupings.

The principle is that the convertible languages bring value because they could specify ONE construct for a label that writers can use consistently for figures, tables, sections, and any other exhibit that is not part of the discourse structure. During conversion, this gets converted into the most appropriate HTML equivalent (in a figure context for HTML5 output, it becomes a figcaption; for XHTML as the target output, it becomes <b>text</b><br/> or some other less worse choice than using a heading).

This highlights a key benefit for convertible languages--they do not have to be exact mimics for HTML, otherwise they are simply modeling bad design in both places. Done smartly, a convertible language like M/T (and even XML) can reduce markup inconsistency and represent common design patterns in content more regularly (including templates for regular content types--something that would unify CS goals with CMS setup). Alas, I don't see this happening as a design principle for any of the lightweight markup initiatives; they are nascent promises in danger of missing out on this high calling for elegance.

[Brutal Pixie]

I just read (skimmed) through most of this and it seems like it's something that technical strategists are more concerned about than someone like me, who works primarily on governance and business protocol.

However, I don't understand why you'd need to train authors in this at all. Any large organisation doesn't allow its authors to publish without some level of review or sign-off; any small organisation doesn't have the skills or ability or time to think about any of this and uses something very simple that they understand (hence why WYSIWYG systems are so popular - they replicate these people's every day function, as learned by their other programs). And in any case, your system should determine the appearance and style, not the author. And if clicking a button verses uses a shortcut is a big deal to an author, then their priorities are the wrong way around.

What benefit does this have to the business users and not the content or software specialists? None, right now, as far as I can see. Authoring speed has never yet been the problem in any business I've gone into (including high-volume publishers) - it's approval streams that are the issue. No system on earth will fix that if the approver doesn't give it the importance it deserves.

Forgive me if I've missed the point of this. In all of the discussions it appears that for devs it's a big deal, but I haven't yet seen a compelling reason for anybody for whom content, websites, or technical detail is not their core job, to use it.

[Adrian Howard]

On 8 Oct 2014, at 16:39, Rick Yagodich <ri...@think-info.com> wrote:

> On 08/10/2014 16:28, Mark Baker wrote:
>> Content source, like code source, is read far more times than it is written, and the readability of the source matters a great deal.
>
> Diverging the subject of the discussion a bit here (i.e. generalising, rather than looking at Markdown et al.) and overlooking the word source in there…
>
> While I do not disagree with the facts of the statement, this mindset that content is read far more than it is written is part of a much larger problem in all levels of communication. The emphasis is squarely put on the end-user experience (the reader) and it is considered perfectly acceptable for the writer (author) to jump through additional hoops to get the content ready.

Which "reader" are we talking about? I took Mark to be talking about the author reading-more-than-writing, not the end user? Hence the analogy to source code…

Adrian

--
adr...@quietstars.com / +44 (0)7752 419080 / @adrianh / quietstars.com

- Get the Agile & Lean UX newsletter here > http://bit.ly/agileleanux -

[Rick Yagodich]

>>> Content source, like code source, is read far more times than it is written, and the readability of the source matters a great deal.

>> Diverging the subject of the discussion a bit here (i.e. generalising, rather than looking at Markdown et al.) and overlooking the word source in there...

>>
>> While I do not disagree with the facts of the statement, this mindset that content is read far more than it is written is part of a much larger problem in all levels of communication. The emphasis is squarely put on the end-user experience (the reader) and it is considered perfectly acceptable for the writer (author) to jump through additional hoops to get the content ready.

> Which "reader" are we talking about? I took Mark to be talking about the author reading-more-than-writing, not the end user? Hence the analogy to source code...
>
> Adrian
I don't think the scale matters. At every step up from initial creation
through editing, then aggregation to the end consumer, there are almost
always more readers than writers (with reader and writer being relative
to each step). And given the weighting of numbers, the onus to bend over
backwards is almost always put on the writer, instead of providing
technology to make their lives easier, less error-prone, and more
productive.

- R

[Mark Baker]

Rick, I really think you are missing my point. My point is that the writer
themselves reads their content more times than they write it. Therefore how
easy it is to read the authored source is an important part of the authoring
experience. Far from arguing that it is more important to focus on reading
than writing because there are more readers, I am arguing that you can't
separate ease of reading from ease of writing during the writing process
itself.

Mark

-----Original Message-----
From: content...@googlegroups.com
[mailto:content...@googlegroups.com] On Behalf Of Rick Yagodich
Sent: Wednesday, October 8, 2014 5:25 PM
To: content...@googlegroups.com
Subject: Re: Could Markdown go mainstream to supercharge our web content
entry?

[Destry Wion]

Brutal Pixie,

You offer a fair perspective, and an important one that discussions like this need to address if a "tool" like Markdown/Textile is to be appreciated the right way for what it is.

For my part in this thread, I specifically pointed out that Markdown (or Textile) is probably not relevant to content development processes in large organizations, and I'd add especially for those having love affairs with MS Word. Anyone would be amiss to try and seek a specific justification for using Markdown and dismiss it entirely if they can't. What I gather from this thread, what is certainly my outlook on Markdown (and Textile), is that it won't hurt you by knowing a few basic forms of it's use, whether you need it for work (regardless of company size) or not.

Independents and people that work in digital agencies would probably have more opportunities for using Markdown/Textile than otherwise. Nevertheless, I'm sure there could be a business case for Markdown (or Textile) in lesser-size companies and team situations (perhaps millions of such companies and team situations around the world), and particularly where people are using WYSIWYG. I can't tell you how many times I've had to clean up content that was carelessly copy/pasted from Word into a CMS, or content that was edited and re-edited with the WYSIWYG editor (for both good- and bad-intentioned reasons), only to wreak havoc on the underlying markup, creating a veritable tag soup, and leaving the clueless author wondering why they can't get an image to position correctly or remove that "mysterious blank space" from between two paragraphs, or whatever. 

Someone has to fix that silly kind of thing, which is unproductive and costly. That's clean-up editing that should never have happened to begin with if better authoring/workflow protocols had been in place (i.e., diverging from a Word-to-web workflow, or a WYSIWYG-editing process). And while that labor is still at the technical level, someone above the copywriter and technical editor — say a governance person, or a strategist — must actually realize there's a problem at that level in the workflow and account for it with better protocol, process and/or policy, whether they are directly involved with the technical editing or not. 

The nice thing about Markdown (and Textile) is that they produce markup exactly as desired (no adulteration of markup with extra rich-text cruft), and with just basic understanding of Markdown (and Textile) use, under the right guidelines and workflow, most authors can produce clean, web-ready content the first pass, saving a lot of editing or tech processing by someone else, and thus potentially adding to great savings overall for the company. I don't know if the CEO or General Manger is who you mean by "business user", but those types would certainly be concerned with the concept of work productivity and company savings. But if business user means the office desk jockey who's job is to post a couple blog articles a month, then Markdown/Textile still has a lot to offer by being easier and quicker to use.

Of course, we can't make sweeping generalizations about what tools/processes would be good or not for any single company, let alone entire segments of industry based on size. We should know that every single project is unique and tools and processes must be evaluated respective to prevailing objectives, stakeholders, etc, etc.

Don,

That's a really good point about 'captions'. I wonder why it never even crossed the minds of the HTML5 lords; or if it did but there was a technical reason it couldn't be done; or if it could be done but politics got in the way. I have no clue of the status of such things. But I do wish more structured-author types would get involved with the HTML5 mail list and speak up. Yet I think the demise of XHTML by W3C's own hands says a lot about who's leading the direction of HTML: web designers and browser manufacturers. The same circles in which Markup is rapidly being adopted, oddly enough.

[Noz Urbina]

Brutal Pixie,

That was exactly my original reaction too. Thanks for bringing it back up.

I have enough technical understanding  that I read through this thoroughly for a while. While I nearly saw a point, it got dashed eventually by counter points.

I take Destry's point that a bit of knowledge never hurts, but as I have never had a wiff of a commercial reason to gain that knowledge in 15 years of content work, I wouldn't do it for professional ROI reasons.  I have learned enough from Destry now that I can say I prefer Textile and if I have a little blog tool that supports it, I may toss some in.

In short: after a deep discussion I am back where I started, which is right with you. I am an independent, but I am a "corporate type" by virtue of the clients that I work with.

Destry, Textile FTW when it comes to sensible markup.

BUT

Exactly as per Don's caption comment, I'd like to point out that I really don't like languages that have explicit title levels (h1, h2... vs title, title).

This *is* something that has been an incredible pain for me when dealing with HTML. A bunch of stuff gets coded at a certain heading level, then you want to shove it up or down in tg the hierarchy because it's appearing on a different page, or you are rejigging your output template and suddenly all you h2s need to be h3s. I have had cases where they needed to be h2s AND h3s depending on what page they were being viewed on! For me this is a very common extremely annoying aspect of non-transformation friendly languages.  It can be 3 years before it comes up, but when it does you may have quite a but of unwieldy content on your hands.

This is legacy from the days when we wrote whole web pages in a single file. Now that navigation and content are abstracted, this whole idea becomes an anachronism. I haven't looked into HTML5 deeply enough to see if it's solved this, but for M/T it's the thing that still sticks out as an issue for me.

[Malcolm Davison]

Hi Leticia (of Brutal Pixie), to sum up:

Entering text into with Markdown there is no delay in moving your hand to the mouse highlighting text and then clicking on styling icons in the tool bar. The hands don’t leave the keyboard and styling becomes part of the text entry process.

So Markdown is quicker than just using the features built-into a CMS editor.

That’s why some (arguably) of the world’s largest web content project teams (GDS and DigitalGov) are using Markdown. And GitHub now hosts a repository of all Germany’s rules and regulations, all in Markdown.

Steven Aquino, freelance technology writer based in San Francisco, neatly sums the benefits up in his blog article ‘The Markdown Payoff’ (http://stevensblog.org/the-markdown-payoff):

The key to Markdown writing is that you focus on the content. Structure, format, look and feel are all secondary. It’s pure distraction-free writing. Which means that you have no choice but to write and think about writing and focus on the content. Which encourages you to become a better writer. The other issue with writing is that it takes time, but the payoff of Markdown is that you land up spending less time doing it. With no distractions and fast tools, more writing gets done.

Or from Gray Brooks a senior API strategist at General Services Administration (GSA) in the United States government, who wrote this in a Google Group posting:

In terms of my writing, all of what I write is for the Web. Whether freelancing or writing for my personal blog, I, like many others, compose everything in Markdown. I’ve been using Markdown for a couple of years now, and I absolutely adore it. I’m so familiar with it that it feels like second nature ... No longer do I have to work in bloated word processors with toolbars galore, or worry about rich-text formatting. Discovering Markdown has been liberating in the truest sense of the word.

As law is your subject area at Brutal Pixie, you may like to check out this link to a Legal Markdown editor at http://code.esq.io/legalmd/

So Leticia, why not learn just six shortcuts, whatever dialect of markup language you choose, and try supercharging your styled web text entry?

Malcolm Davison

www.writingfortheweb.co.uk  

[Malcolm Davison]

Just a PostScript Leticia,

Dictation systems (eg Dragon Dictate) are especially good transcribing legal, medical text with its lengthy words and phrases.

Or if you were using a Mac for example, you could use the dictation feature in iOS to speak the text into Byword or Markdown Pro, adding the odd Markdown keystokes as you go. TextExpander software could also assist so that you can enter frequently used phrases and terms with a couple of keystrokes. Then cut and paste the HTML into your CMS system.

With all that techy support you will have slashed the writing time to a fraction of the traditional approach.

Malcolm

[Destry Wion]

I take Destry's point that a bit of knowledge never hurts, but as I have never had a wiff of a commercial reason to gain that knowledge in 15 years of content work

Noz, 

If I may point out the obvious, you seem to be dismissing Markdown by only looking at it in terms of your corporate client work, and that's not the full picture, as has been stated or demonstrated (e.g., Joe's use case) several times in this thread. The value isn't just with how you can fit it in with client work.

Two examples:

Personal use: Do you have your own blog? (Yes you do.) Do you use WordPress? (Yes you do. BuiltWith says so.) Then you could benefit from working with Markdown, unless what you're really saying is that you actually enjoy WYSIWYG editing, in which case you start losing friends and respect. ;)

Collaboration (someone else's sandbox and rules): (This goes to you too, Leticia. Remember our book review conversation?) Maybe you want to contribue an article to CSF sometime. Guess what? We use Textile in the editorial workflow. And when Textpattern 4.6 comes out providing a Markdown filter too, we'll offer authors their choice of Textile or Markdown on an article by article basis. Sure, you can stubbornly ignore the drafting aides at bottom of the page table, and I or someone else will peruse the draft for problems before publishing, etc, but with every pass on copy that is done with respect to the final form it needs to be in, even if not perfect the first time, everyone's lives are a little easier (and you're efforts are appreciated more) through the full process. Overall, mistakes are likely to be found pre-publication rather than post due to more minds working together.

So, it's not just about client work, or a specific scale of work. It's about producing content from your brain/fingers that will be published on the web for whatever reason or under whatever context. I've just described two. In that general way of thinking about it, these kinds of filters offer people a lot of value. Clearly many in the industry are seeing this, by evidence of tools supporting them.

 

[Leticia Mooney]

Hi all,

I appreciate what you're saying, but it has no value to SMEs for whom the issue in creation is not the creation it's the approval stage. There is no way I would be able to sell it to clients, for example. Or rather, I could, but it would not add value to them - it's just another thing they have to learn.

In terms of publishing, having worked as an online publisher for a long time, I would have had to train every new writer who came my way, make sure it was being used properly, and spend too much time and effort just doing something that is unnecessary and adds no value (in terms of value-stream management, I mean).

It's a great idea but I don't see it becoming mainstream in any sense in the foreseeable future. By far the majority of businesses don't even have websites yet, and don't even understand how to blog - so the idea of mainstreaming is realistically a very, very long way away.

Just by two cents. :)

Content Strategist at Brutal Pixie

Essayist and critic at Biodagar.com

www.brutalpixie.com

www.biodagar.com

--
You received this message because you are subscribed to a topic in the Google Groups "Content Strategy" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/contentstrategy/XWBk9-3ZY2I/unsubscribe.
To unsubscribe from this group and all its topics, send an email to contentstrate...@googlegroups.com.

[Malcolm Davison]

I appreciate what you're saying, but it has no value to SMEs for whom the issue in creation is not the creation it's the approval stage.

I agree Leticia that it won't suit all applications - and that includes some SMEs. Quality control is crucial and this technology can't help.

There is no way I would be able to sell it to clients, for example.

The benefit of Markdown is speed of content entry, but the clients need to be entering a significant volume of text entry to benefit.

Or rather, I could, but it would not add value to them - it's just another thing they have to learn.

But it only takes 10 minutes. Have you tried it yet? Webbies after all first adopted the system.

In terms of publishing, having worked as an online publisher for a long time, I would have had to train every new writer who came my way, make sure it was being used properly, and spend too much time and effort just doing something that is unnecessary and adds no value (in terms of value-stream management, I mean). 

Well because it takes so little time to pick up, the largest content creators (I gave GDS as an example) are adopting it. So authors are expected to learn it - but 'learn' is over stating it.

It's a great idea but I don't see it becoming mainstream in any sense in the foreseeable future. By far the majority of businesses don't even have websites yet, and don't even understand how to blog - so the idea of mainstreaming is realistically a very, very long way away.

My proposal was that this would be a toggle on / toggle off feature added to all CMS systems. Those that see the benefit would use it, those that won't benefit would ignore it. It's not intended for the webless businesses, but there are applications useful for us all ... 

Some people are using Markdown as a standard format for recording notes and drafting articles. These can be kept on the cloud and accessed by their different devices - phone, tablet, laptop / PC. Some software will even allow multi - author editing (eg Voodoopad) of Markdown files. The final draft can then be output as normal ASCII text, output to Word as RTF or styled HTML to be cut and pasted into web applications.

By the way, Voodoopad (sadly on Mac but at just $40) is great for creating wikis, as it auto generates links of previously created pages. For example, type in 'Christopher Wren' into an article about St Paul's Cathedral, and it will automatically hyperlink the name if it finds a page previously created about the architect. In conjunction with Markdown text entry this must be the fastest way to create wikis - either to be output as a suite of web pages or as a linked pdf. There's a great demo of creating a clinic notebook wiki on YouTube at : http://youtu.be/bQXr1UloMfc

Malcolm Davison 

[Adrian Howard]

On 25 Oct 2014, at 12:27, Malcolm Davison <in...@writingfortheweb.co.uk> wrote:
[snip]

>> It's a great idea but I don't see it becoming mainstream in any sense in the foreseeable future. By far the majority of businesses don't even have websites yet, and don't even understand how to blog - so the idea of mainstreaming is realistically a very, very long way away.
>
> My proposal was that this would be a toggle on / toggle off feature added to all CMS systems. Those that see the benefit would use it, those that won't benefit would ignore it. It's not intended for the webless businesses, but there are applications useful for us all ...
>
> Some people are using Markdown as a standard format for recording notes and drafting articles. These can be kept on the cloud and accessed by their different devices - phone, tablet, laptop / PC. Some software will even allow multi - author editing (eg Voodoopad) of Markdown files. The final draft can then be output as normal ASCII text, output to Word as RTF or styled HTML to be cut and pasted into web applications.

[snip]

The way that Markdown can be authored productively in pretty much anything that handles text is one of it’s advantages. One of the things I hear from folk using markdown based systems is how freeing it is that they can go write in their preferred tool, often in places where the base-system is unavailable, and bring it in with a simple copy/paste.

Another advantage is the relative ubiquity of the format. Folk only learn markdown once, and then it’s useful in lots of places.

Many times I’ve thought I’ll need to teach somebody markdown (a trivial task as you’ve already mentioned) only to find that they already know it.

Especially with folk who are more the digital native type. Because some forum, or bulletin board, or blog, or newletter system, or book writing software, or CMS, or wiki, or *whatever* has already trained them up in it.

Which, for me, is a sign that it’s already pretty mainstream in many communities. I certainly encounter a *lot* ,more folk using markdown than I do any kind of structured XML/SGML format (excluding [X]HTML).

Cheers,

[Kevin Mahoney]

Just to lightly accent this response about adoption by content creators, learning Markdown is pretty easy because most of us have used Markdown without even knowing it.  If anything Markdown is just a set of standards for the way that most of us have used formatting text when we don’t have a rich text editor.

In the old days, our headlines had a nice underline

======================================

## Prefixing our headlines with #(#####) is just a nice shortcut.

When we want to create a new paragraph, we just do hard returns.

When did blockquotes, we just indent our text manually.

> Or if we wanted to do it e-mail quote style, we’d use the > character at the beginning of each line.

When we don’t have access to italics, we just tend to *emphasize* words with asterisks.  When we want that bold emphasis, we use **double italics**.  When we don’t have access to lists, we:

* Write them out like this

* Each item with an asterisk

or

1. We manually make a numbered list

2. So it’s not really that different

As for links, when we’re unable to make hyperlinks we often just throw the link in parentheses at the end of the sentence clause.  Markdown just takes it a step further by adding square brackets [for the text to be hotlinked](http://url.com).

So, in a sense, we’ve been using Markdown since the days of typewriters.  This is why Markdown is so easy to adopt for content creators.  All of the stuff I typed above is valid Markdown, and converts just fine to HTML (or whatever other format you wish to process).  I think it’s important not to understate just how conventional of a standard it is, and in the areas of language and communication convention *always* trumps logic.

—Kevin

--
You received this message because you are subscribed to the Google Groups "Content Strategy" group.
To unsubscribe from this group and stop receiving emails from it, send an email to contentstrate...@googlegroups.com.

[Rick Yagodich]

And that, Kevin, serves to emphasise some of the problems with Markdown.

Yes, some of those methods are intuitive (I'll come back to that), but others are _far from it_. Yes, that was an indication of italics. Putting single asterisks around something makes absolutely no sense as a representation of italics. Asterisks represent bold. We *should not* need to double-up to indicate what it really means.

And the less said about equal-underlined headers…

But back to the ways some of these syntaxes are usable even in environments you never realised you were using them in: If you start a new line with an asterisk and a space, or a hyphen and a space, or a number, a period, and a space… good old Word will convert them to the relevant bullet, dashed or numbered list automatically.

When word does this, it is only a shortcut to input, transformed immediately into its semi-semantic internal representation. Once converted, it is the new format. And therein, we have a usage that really does make sense - it allows the hands to stay on the keyboard, so not wasting valuable time thinking what to do, moving to the mouse, finding where to click, then releasing and returning to the keyboard. A process which, without doing a detailed count, probably amounts to 7 seconds. Markdown-style shortcuts for creating the formatting are then a good idea.

But it does need to get out of Markdown as quickly as possible, so as to be reusable.

 - R

[Kevin Mahoney]

Rick, you bring up some very valid points and I could not agree more on some of the inconsistencies.  Especially for italics! Traditionally, I had used /this/ for that.  I believe the / was not used for Markdown for parsing reasons (since it auto-parses URLs and non-urlencoded asterisks are easier than a / when trying to italicize a URL). Inconsistencies aside, I think it still serves well as a cornerstone for conventions we’ve typically used and it’s more intuitive than not.

There are text editors that do auto-format Markdown. I use TextMate for most of my text editing, and its markdown will automatically create a new bullet, maintain indents, etc.  It’s not a universal adoption for every editor, but most text editors have at least some form of limited MD support and I believe the issue there is just that there is a limited number of good markdown support for editors.

The futurist in me does not see this being a huge problem.  Younger generations have been learning to communicate using non-SGML formatting languages like BBCode, Markdown, etc. for online communication.  These technical skills, usually reserved for web engineers and LaTeX authors, are becoming more commonplace and accepted. I do not see adoption of these things dropping until that glorious day when WYSIWYG becomes less of a hassle to manipulate.

The reality is that a word processor will almost always be faster. Especially for tables, which is a Markdown “extension” that is covered neither in Gruber’s spec nor CommonMark’s.  The advantage to MarkDown is that you trade some of those creature comforts for more raw control over the content itself which is easier to manipulate, store and process.

Sent from my iPhone

[Noz Urbina]

Hi Destry,

I exchange content for my blog, but I am happier dropping whatever I receive into notepad and rebuilding the formatting than worrying about the mark up choices of my colleagues. "Collaboration" would be far too grandiose a word. Sometimes they review my stuff or I their's, in which case I have found nothing better than a Google doc for managing the process.

"unless what you're really saying is that you actually enjoy WYSIWYG editing, in which case you start losing friends and respect. ;)"

I think this is closest to the truth. I wouldn't say "enjoy" as much as "am perfectly fine with and accustomed to". I know and see users who sometimes end up with wonky mark up or get lost jumping into plain text, but that doesn't really happen to me much, and I doubt anyone else on this thread. I find its only the least digitally savvy users who end up having Wysiwyg editors go crazy on them (this is WP-style things. MS Word is of course a mine-field of stress).

ctrl-2, 3, 4, I, & B handle my headings and text decoration for me, and the rest is paragraphs and lists. Image insertion I hope we can agree is nicer with a dialogue controlling it and clicking on a thumbnail is nicer  than typing names and paths.

I select stuff with the ctrl, home, end, shift and arrow keys 98% of the time. ctrl-shift + left, ctrl + B is actually faster than ctrl + left, shift+ 8, ctrl + right, shift + 8.

Ctrl+3 is *significantly* faster than whatever it is to put in a load of #s.

So speed,  the most often quoted benefit, doesn't apply to me. And yes, I would do bold/italic in that order because as as much as I get and like Textile mark up (not Markdown for the kind of reasons Rick mentioned), I am not capable of doing things right-to-left, so I always go back and decorate something after the fact. I can't decide something should be bold until I see the phrase in context.

That's another thing... I often like to make these decisions in *full* context. If I'm creating thought out content (unlike this email) then I am going to do make an effort to avoid decorations and formatting until the text is nearing final state.  At that point,  jumping in the middle of a paragraph is actually far faster with the mouse.

So the speed benefit, because of my personal style, is non-existant. I know the codes, but they are *slower* than mouse/short cuts. I use them on the phone with my thumb, like now, but I only do real work on a real keyboard.

The only one which would be *really* nice would be not having lists go to hell when I copy and paste between evernote / notepad / WP so for that one thing if I could turn on support - in WYSIWYG  mode - then I would like it.

WYSWYG isn't cool, but, for me, it's definitely faster and more functional.  The cross-tool lists thing is broken, and I would like a solution, but it is not worth everything else I would be giving up.
The collaboration benefit isn't there because hearing about it on this forum is the only time any of my peers talk about these options and getting stuff out of Google docs is easiest via word or html.

I am not anti-Textile, I am just unable to find a reason to be pro- it.

@nozurbina / urbinaconsulting.com / +34 625 467 866

[Tony Chung]

A recent post in TechWr-l points to the use of Asciitext as an alternative to markdown for multichannel publishing. The article might be better suited to content strategy tech, but the current discussion warrants it:

On Tuesday, October 28, 2014, Cardimon, Craig <ccar...@m-s-g.com> wrote:

https://medium.com/@chacon/living-the-future-of-technical-writing-2f368bd0a272


Thoughts?


Cordially,

Craig Cardimon | Technical Writer
Marketing Systems Group
www.m-s-g.com<http://www.m-s-g.com/>

[Mark Baker]

Tony, thanks for pointing out AsciiText. It helps make further clear that what is mainstream is not one format or another, but fitness for purpose. Each of us chooses for authoring that format and tool which makes it easier for us to author effectively and without distraction. 

Because we have different tasks, and because we are distracted by different things, this means many different formats. It even means many different formats for each author individually, for use in different tasks. 

Insofar as XML, or any XML vocabulary such as DocBook or DITA has sought to become a universal format, they have manifestly failed. They have become another niche format for authors with particular tastes and needs. 

This does, of course, create a problem for content management (and therefore for content strategy). How do you manage such a diversity of formats, and how do you give direction and provide validation (and therefore governance) of all those formats? 

In the past, the attempts to address this problem have sought to impose a single authoring format on all content contributors. It is time to concede that that approach is not going to work.

The universal formats suffer gravely for their universality. They are large, complex, and often finicky. The are expensive to learn and expensive to use. They were not designed to suit author's tastes but to run content management and publishing tool chains. They are never the easiest way for an author to do anything.

However, we don't need universality (either of syntax or semantics) to get the structure and semantics that content management requires. It is perfectly possible to get it from individual domain specific formats that are optimized as much as possible to suit the tastes of authors. In fact, it is how most of the broad-based information gathering in the world works -- through custom forms specific to their domain and optimized (more or less) for the people who are asked to fill them out. 

What the proliferation of lightweight markup languages demonstrates is that domain specific languages (AsciiText for technical books, markdown for simple web pages, etc.) built for specific authoring communities can be very successful. 

Rather than deploring the proliferation and seeking to pick a winner, we should recognize that diversity is the real winning strategy, and start to think about how to work that diversity into our content management systems and into our content strategies.

--

[Tony Chung]

Thanks, Mark. I'm grateful to be involved in so many helpful communities who share from different experiences. Your point about diversity being the future resonates with my personal views as well.

I just finished watching a webinar on Scrivener, a writing tool for Mac and PC. I got to thinking how it would be great to use Scrivener as a free-form front-end, and export into topic chunks for use in a DITA management/publishing system. Or better, use Scrivener for authoring, editing, and publishing, with DITA as an invisible back-end.

A number of companies use various forms of wiki for documentation, as well as plugins for Word. The Word tools store data in different formats, on different types of servers or source code repos.

Wouldn't it be nice if all of us could just play nicely together?

I'm with you that the end goal of content strategy to determine how to produce content to fit to the necessary output streams, and not allow the technology to limit how we create and manage content. It's only when information needs to be exchanged (perhaps for white labeling documentation) that the storage format becomes important.

-Tony

There is no shortage of front-end tools

[Destry Wion]

H Noz,

Yes, I use Google docs too, and use keyboard formatting in environments like that, generally speaking. In fact, in the CSF articles workflow, a Gdoc is the first step for authors. Though we actually gives authors the choice of their tool (Gdoc, Draft, etc), so long as it's web-based (and free), provides version control, and collaborative editing features. No native clients at cost or platform specific.

And that was really my point, the more tricks you know, the easier it is to collaborate in various situations. In the CSF workflow, for example, a Gdoc is not the finish point before publishing, the text needs copied into the CMS, which doesn't use rich-text formatting (by design) to ensure we don't get a lot of ghost markup slipping in from the ported text. While Gdocs are better than most, they still slip in ghost markup or styling if you're copy/pasting it's styles into a rich-text editor. Particular problems I've noticed are with with respect to line-height and spacing. To avoid problems like that we don't allow rich-text in the CMS editor at all. So the keyboard formatting in a Gdoc has to be manually changed to some Textile or Markdown. We don't make authors do that part, but it's nice if they try and help from the start, and we even give them basic Textile formatting instructions to do so. None of of our contributing authors have complained so far. None of it is very difficult, after all.

Bottom line is, to each their own. I subscribe to Mark and Tony's position: you use what is right for the job, in the context the job requires (people, tools, workflow, etc.). And to my mind, the more tricks you know, the better off you are for that kind of variability. The content Boba Fetts of the web.

-dw 

[Noz Urbina]

Hi Destry,

I am down with "more knowledge = good". I think I may have said that in this vast thread. If it comes up, I'm happy to jump on board. I am just several layers deep in stuff that I want to learn and read about as it is, I can't make room for the things that are not regularly coming up in the field.

Your scenario sounds realistic and has come up when I have had people working on my website for me, but it doesn't come up enough (yet) to make it worth the change over.

The original subject line of the discussion was about "mainstream" and "super charge" and I have seen points to suggest that it'll maybe grow a bit and that it has some areas where it can be quite nice, but the rockets and excitement implied by the question didn't play out in the discussion.

My favourite part is now i know the two formats and the fact there's a difference, and I am happy.

*BREAKING NEWS*

For the first time ever, a prospective client just said that Markdown is a major requirement!

Ha!

Awesome. Thanks for the heads up, everyone! I still think 'mainstream' is calling a ripple a tidal wave, but I thought it was perfect that just as I was signing off this thread it actually came up!

[Malcolm Davison]

I still think 'mainstream' is calling a ripple a tidal wave

I do believe Noz, like Britain’s legendary monarch, King Canute who tried to stop the tide coming in, you are probably going to get your feet wet!

I agree it does seem strange to expect authors to learn shortcut coding - rather than using ever more ingenious UI clicking. But we know it’s a lot faster - office staff have been doing it since the introduction of the Wordstar word processing package in the early 80s. And as we have said Markdown needs just 10 minutes learning time.

In addition to 100 or more programs dedicated solely to Markdown text entry, the following 45 wiki, blog, web design and CMS software use markdown (a few need a plug-in):

Academic CMS, Anchor, ASF Content Management System, BBEdit, BlogEasy, CoffeeCup, Craft CMS, Dictator CMS, DropCMS, Dropplets, eBookBinder, Frog CMS, Ghost, Gollum, Grav CMS, GitHub, Jekyll, Kirby, Locomotive CMS, Markdown CMS, MediaWiki, md-cms, Nocs, Notebooks for Mac, October, Orchard CMS, Pico, Radiant CMS, RapidWeaver (web design), ScreenSteps, Scrivener, Sculpin, Sitefinity CMS, Text Wrangler, TextMate, Tiddlywiki5, Vestibulum CMS, Voodoopad, Vox CMS, Web Book Boilerplate, WikiMatrix, Wolf CMS, WordPress, Write, WriteMonkey.

OK many of the above names you may never have heard of, and neither had I, but why are so many software houses now supporting markdown? Are the major CMS systems beavering away at the moment to follow suit and then make it mainstream? Hence my post that kicked off this mega thread.

By the way, I see that the Guardian newspaper uses the alternative system Scribe as part of their CMS: http://tinyurl.com/o4fkw7m

And as I mentioned in one of my earlier postings arguably the largest European web project, GOV.UK uses a variant of markdown.

Such markup systems will become even more necessary when we start using rich snippets for the semantic web - as the likes of Google are encouraging us to do. 

Can anyone add to my list of software above, or identify any larger CMS or authoring tools that support Markdown?

Malcolm Davison 

[mbaker.analecta]

I wonder if a better question might not be whether lightweight markup languages will become mainstream -- regarding them as a team rather than as rivals. 

The whole argument for lightweight markup seems to me to rest on fitness for purpose. Give each author the simplest possible toolset for the task they have to pefform. Any markup system that seeks to become a universal standard will inevitably become large, abstract, and less fit for any one individual purpose. (See the entire history of XML and SGML.)

It follows that for lightweight markup to become mainstram, we will need many dialects, not one. And if we were to add up all the dialects, the stream would look considerably more main than it does if you look at markdown alone.

Perhaps the growing popularity of Markdown is simply evidence of the pendulum swinging back from the universalist principle towards the principle of fitness for purpose. (It will inevitably swing back; the grass is always greener, and the siren song of universalism never entirly loses its power to lure projects onto the rocks.)

Mark

Sent from Samsung tablet

-------- Original message --------
From: Malcolm Davison <in...@writingfortheweb.co.uk>
Date: 2014-11-17 6:40 AM (GMT-05:00)
To: content...@googlegroups.com
Subject: Re: Could Markdown go mainstream to supercharge our web content entry?

[Malcolm Davison]

I am sure you are right Mark. Those that don’t choose Markdown are doing so because of the limitations of the markup vocabulary. They are real enthusiasts who want to go a stage further and achieve more complex styling. And evidence is showing that some writers are happy to step up to the plate.

CMS systems may in future allow the users to go into their ‘Preference box' and toggle between several markup systems (or none at all) and so keep everyone happy.

Major corporate web projects may well create their own custom markup systems, which may also incorporate useful shortcuts to company and product names, and semantic markup.

The next 18 months should be interesting.

Malcolm

[Mark Baker]

I think that is one aspect of it. Some may find that Markup is too stylistically limited -- though in the end all markup languages are stylistically limited compared to full WYSIWYG, at least for ad hoc styling.

But I was actually thinking about semantic limitations. Some authors, and some organizations, will require a higher degree of semantic content than markdown can provide. You can provide a lightweight markup language for just about any specific semantics you like. Many of the other member of the lightweight markup team (such as wiki markup or AsciiDoc) can express document semantics that you can't express in Markdown. Javadoc expresses Java API semantics (@param, @return, etc.) that you can't express in Markdown.

Extending Markdown to express all these types of semantics would lead us back down the XML path. Thus the value of having a team of lightweight fit-for-purpose languages.

Mark

-----Original Message-----
From: content...@googlegroups.com [mailto:content...@googlegroups.com] On Behalf Of Malcolm Davison
Sent: Monday, November 17, 2014 8:56 AM
To: content...@googlegroups.com
Subject: Re: Could Markdown go mainstream to supercharge our web content entry?

[Noz Urbina]

I maybe should have said, the customer is absolutely unambiguous: the only reason Markdown is even getting a mention is that developers like it. It's technical knowledgebase project, and techies like codes. There's no interest among general authors.

So regarding the original thread and the 'mass market', I have no evidence to suggest Markdown or similar languages are about to cross the chasm or supercharge anything. It's simply that the developers like Markdown (which seems natural) and so the system should support people not having to shift off what they like. It's the same reason that the mass market doesn't really need to shift off what *they* already like (not Markdown).

Regarding the shift to simpler markup languages I would agree. I think that the world of more restrictive and verbose vocabularies of the traditional XML world and the uncontrolled wild west of the general web will meet in the middle. Lighter, more flexible, but will defined and reliably parseable (and extensible), languages are a happy medium that does what it needs to without creating too much overhead. That trends been trundling along for a while now.

--

Noz

Content Strategist, urbinaconsulting.com

Join me at Congility 2014, Jun 18-20: congility.com/2014

Co-Author of "Content Strategy: Connecting the dots between business, brand and benefits". In stores now: thecontentstrategybook.com

[Malcolm Davison]

There's no interest among general authors.

I agree Noz. The majority of web writers are not communication professionals. They are probably entering their text into proprietary CMS systems or open source software that can’t interpret the extra characters. Besides, without a techy knowledge they would be unlikely to have even heard of Markdown let alone be making demands for its use.

And you are right, it's the developers, and the experienced writing professionals who are using Markdown daily plus the exciting, experimental content projects that have beneficially switched to and are extolling the virtues of markup systems.  

For the software houses adding this feature, in coding terms, it's a very minor upgrade. They may be simply waiting for their next major update, or be hovering to decide which markup system to plump for. But they must be concerned that so many CMS systems can now handle Markdown or can be made to do so with a plugin. I suspect their university clients especially will be leaning heavily on them to implement Markdown.

You may be interested that the following larger CMS systems can be upgraded to handle Markdown with extensions: Joomla, Drupal, TextPattern, Contao, SilverStripe, Umbraco, Concrete5 and CushyCMS. There are probably many others. 

Content professionals now need to be asking questions about their own CMS software and consider whether employing more rapid styling with Markdown will boost their own productivity or not.

Malcolm