Exporting information for external readers

sbts

Hi,
I realize that publishing data from my knowledge base costs me more time than I want.

• Copy and paste information, convert from markdown syntax to Office like structure. This is my main concern that I want to address in this post.
• Requirement to produce plain text from small snippets of thoughts and bullet points. I know that this is probably the actual issue, where everyone has their own personal limits...

I personally am using vimwiki. I often have already structured text inside my wiki, so I am not following a dedicated ZK method, where I would provide very small pieces of information, as I have read it in your introduction.
Maybe the topic is known to you anyway. I could think that if you have only small snippets of information on your pages, the problem might be even worse. Or eventually better as you can copy and paste very small snippets of text(?).

I am currently working in an environment where the documents for external partners need to be written and shared in MS Office and the internal documents with LibreOffice. I personally often share textfiles internally, but there are some that don't like this, and latest when we have a kind of official internal meeting, I "quickly" convert my initial text into Office document.

How do you effectively export things from your knowledge base into documents that you want to publish eventually having the following points in mind:

• Efficient working: Information that is gained during writing the document to be published might also be needed to be transferred into you your knowledge base - duplicated information
• Markdown syntax is not powerful enough to e.g. handle tables, so there is cumbersom reformating when moving data. Vimwiki syntax is not supported externally. AsciiDoc is a kind of strange to me. Multimarkdown was not fully supported by all my tools.
• Laying out a document in MS Word or LibreOffice is for me a very time consuming process, when I copy plain text into it.
• I tried several conversion methods like for example
  • exported html from vimwiki into word
  • several tries with pandoc (e.g. to LibreOffice)

Thank you

sbts

related: https://forum.zettelkasten.de/discussion/1870/how-do-you-organize-and-refer-to-your-final-work

Will

@sbts
I don't know about vim wiki.
I do love working in a UNIX-like os. Currently, I use X-Code in macOS but have a fondness for Debian.

I'd recommend two approaches.
1. Pandoc is your friend. It is a powerful document converter with bazillions of options. There is a steep learning curve to getting things to convert in the format you want, but in the end, it is magical. I'm only a beginner, but I've had some great successes.
2. I sometimes use GUI tools to help with document conversion. A markdown editor with document export is what you want to look at. Linux has a few apps that preview markdown and allow export in various formats. 10 Best Markdown Editors for Linux

I made a crud demo of how I do this and posted it here. Marked2 is my preview tool, and The Archive is where I store my notes. This may give you some ideas. I hope you wouldn't laugh too hard at my feeble video skills.

ctietze

.@sbts You could soothe your vim needs by installing Emacs with evil-mode, or go straight to Doom Emacs, and then get some auto-conversion of text files to docx by employing tools automatically for your notes as you write and edit them.

Emacs aside, Pandoc truly is your friend. I recently converted a long document to DOCX for sharing and ended up with the Pandoc default style because all GUI conversion tools I also had produced abysmal page settings or ugly typography. The Pandoc defaults are good enough for a quickstart. Over time, you'll want to spend an hour or ten customizing the export options to fit work expectations, though.

To convert e.g. 100 small notes into 1 big document, use "file transclusion" (some engines support that, i.e. you write an index file that lists the files to concatenate), or run Pandoc on a list of files directly or use cat to concatenate on the fly.

If you get transclusion to work for you, you get similar benefits from structure notes: next to the mere list of references to other notes, you can sub-divide the overall document with headings, add text in between file references, etc. -- so you really get to edit the final document structure itself.

GeoEng51

@sbts I do some of what you mentioned. My main ZK is in The Archive, but a lot of my commercial work is done in Scrivener. You produce plain text documents with their own embedded formatting instructions, but then conversion to Word or PDF is a breeze.

As an aside, going from your ZK to a written article or report isn't a simple process. Sure, your ZK has all sorts of good ideas, but you still have to write that article, organizing and tying together those ideas, and maybe introducing new ones. That's a whole, new creative process. Don't think you can somehow automate it. Lots of previous discussion on this topic in the forum.

sbts

@will, your video looks impressive and shows the workflows, I would think of.
The Archive and marked2 look impressive on a first view, I think that you have already spent some time in tweaking it.

I have the following doubt: Lets assume, we can use small snippets (zettels) that you expand into a final document. Probably you will need to change the content of the texts slightly to fit into the article. Will you edit the final expanded document or will you modify the zettels? In the latter case you will probably change their content, so they would not fit into a previous document, where you already might have used them. Or is it just duplicating the text snippet, before you actually are using it into your text?

@GeoEng51, I think you just address this point when telling, that transfer from ZK to written article isn't a simple process.

I think, Christian, (@ctieze), you also pointed out, that the process would be to finalize the structure first and then start to edit the final document to add some prose.

---

One big issue for me is, that I am using my notes very often in team meetings. So my chain is:
personal knowledge base (text) -> libre office (hand out), edit inside this document with team members ---> back into my personal knowledge base. Things get even more complicated as additional trackers and kanban boards are used in the company, where duplication of information might also be necessary.

Will

@sbts said:
Let's assume we can use small snippets (zettels) that you expand into a final document. Probably you will need to change the content of the texts slightly to fit into the article.

Maybe. Maybe not. Depends on the clarity of the notes for the purpose of the final output.

Will you edit the final expanded document, or will you modify the zettels?

It depends on what is easier and how difficult the change is. Does the change modify my idea as expressed in the note? Then, by all means, change the note. If the change is cosmetic, it can be changed in the output document. But remember, once you start changing the output document, you can't re-export without losing something.

In the latter case you will probably change their content, so they would not fit into a previous document, where you already might have used them. Or is it just duplicating the text snippet, before you actually are using it into your text?

Any note referenced in the primary note used as the target outline with the correct format can be modified. The modifications will be automatically posted in the Marked2 document, ready for export.

One big issue for me is, that I am using my notes very often in team meetings. So my chain is:
personal knowledge base (text) -> libre office (hand out), edit inside this document with team members ---> back into my personal knowledge base.

The workflow I tried to demonstrate kept the "document" in my ZK, so I didn't have to go back separately and update the notes.

GeoEng51

@sbts

Some people use their ZK to write articles in an integrated way with a final product, but then you run into some of the problems you have described. I think that process can work when you are the only person involved and have complete control over both your ZK and your final product.

I find it much easier to write a final product somewhat independently of the content of my ZK, using Scrivener as an intermediate tool, as mentioned in an earlier post. It is very simple to bring zettels (as snippets of text) into Scrivener, each residing as their own text file, but amalgamated into a larger file. You can then move the various ideas around and write intermediate / bridging text, and edit whatever you want.

This is particularly important in a work environment, where you have to interact with a number of people and where the "final" product may go through several sets of revisions, reviews, edits, etc., before it is actually final and published in some way. In that case, I export what I have written in Scrivener to Word and send the article or report on to others. All the final edits are done in Word.

@Will mentioned Pandoc, which I also like and have used a bit. But I don't use it in my normal work flow, preferring instead Scrivener, which does many of the same things as Pandoc (plus more).

On occasion, writing some article or report as described above may suggest new or modified ideas, in which case I modify or add to my ZK. In a way, I see my ZK as an "original" depository of ideas and then the articles and reports as derived products. I don't want to conflate the two.