The Problem

Having participated in several painful group proposal writing efforts over the past six months, I started thinking about the best way to approach such an endeavor.

Of course, the programmer in me thinks the right way to do this is to use LaTeX for markup, put the source in Git, and get on with the writing task.

But this solution has several problems:

1. Not everyone knows LaTeX. This shouldn’t be a big issue, because the document skeleton can be set up by a LaTeX guru, after which the authors can add what is mostly plain text with a few markup tags like \emph{} and \textbf{}. However,
2. There are people who, it seems, truly believe that Micro$oft Word is the only way to create documents. Without a wysiwig interface, they can’t write.
3. Budgets require spreadsheets or something similar. It’s not so difficult to write scripts to convert the data in a spreadsheet to LaTeX, but capturing the data from the same Micro$oft devotees is a real pain unless you give them an Excel spreadsheet. Unfortunately,
4. Spreadsheets don’t play well with VCS unless they are saved as CSV format files, in which case the calculation capability is lost.
5. Git is conceptually beyond many programmers, let alone non-programmers.

A Wiki-based solution?

A simple wiki seems to have the potential to solve this problem:

• Wiki pages could be created for each of the major sections of a document; a proposal would have pages like:

  1. Concept
  2. Background
  3. Plan
     1. Work packages
     2. Schedule
     3. Resources
  4. Impact
  5. Consortium
     1. Partner A
     2. Partner B etc.

• a backend process would assemble the pages, export to LaTeX, compile in the budget and effort data, and produce a nice PDF document ready for uploading.

1. Some forms would be required to capture the budget and effort data. How hard would it be to add a special ‘form’ type of wiki page? This would also be needed for bibliographic references.
2. Markdown is incredibly easy to learn, but for the WYSIWIG crowd, it’s as incomprehensible as LaTeX. How hard would it be to create a customized version of something like CKEditor to create Markdown in WYSIWIG fashion (I know, it’s a crazy idea, but the WYSIWIG segment of the population is as brittle as cheap china).

There are some partial solutions to the latter problem. Among them:

• Itty Editor Not wysiwyg, but nicely minimalistic and the demo has a dynamic conversion feature that allows you to see what the rendered HTML looks like on-the-fly.
• MarkItUp! Also not wysiwyg. More featureful than Itty editor, but doesn’t get lists right (you have to know to put a blank line before and after a list; Itty Editor figures this out.). Also requires explicit preview, which would be fine for Gitit I suppose.
• MarkDownDeep Same as MarkItUp except it has a dynamic preview feature. Doesn’t get lists right either.
• WYSIWYG BBCode Editor No demo, but the screenshot shows WYSIWYG capability. Unfortunately outputs BBCODE, not Markdown.
• MD-WYSIWYG This is a cool, minimalist WYSIWYG markdown editor with a Python backend that converts html to Markdown. Might as well use CKEdit. Project appears to be inactive though anyway.
• widgEditor The HTML WYSIWYG editor that MD-WYSIWYG is based on. Inactive.

Table editing is another story. It seems the accepted approach is to use the table editing function of one of the WYSIWYG editors. But I’m thinking that for this application, a separate Wiki page for tables is more appropriate, as they would ‘float’ in the assembled document. The table code generator looks promising.