It occurred to me that Scrivener would be a good way to assemble documents for a wiki.
Has anyone has used Scrivener for that purpose?
Pandoc can convert md or html into Wikimedia format.
I’d like to see Scrivener smooth out some of the wiki functionality to make it faster and easier to create a locally-stored Zettlekasten notes system. You could also use it to create a small Zettelkasten within a project for world-building and brainstorming.
This is probably quite a ways off of what the original poster was intending to discuss here, but out of curiosity, what sort of streamlining are you thinking of? I’ve done a fair amount of thinking in this area, and while I do not use ZK itself, my own bespoke system is quite similar, and I found Scrivener to be very useful for managing the kind of information and networking you would expect of it.
Bearing in mind of course that this technique, and mine, were both designed to work well with nothing more than a box of index cards, the bar is not very high—but there are some very cool techniques Scrivener brings to the table.
1 Like
I’d just like the experience to be lower friction. Look at Hypernotes . It does ZK very smoothly. Unfortunately, it’s cloud-based and unencrypted, so I can’t use it for sensitive information, like when I’m working on material owned by a media conglomerate.
The obvious bumps I’d like to see Scrivener smooth out:
-
When you create a hyperlink for a page that doesn’t exist, Scrivener pops up the dialog box asking where the page should go. I’d prefer to set that in a preference, and have the page created without the interruption. Often, I’m typing a sentence and I make a link for a thought I want to expand upon later, and the dialogue box interrupts my train of thought. Small beer, I know, but I can just fly along using Hypernotes.
-
I’d prefer that the backlink was a hyperlink in the text, in addition to being a bookmark. Additional hyperlinks would be bookmarks, but the originating page would be the hyperlink at the top of the document.
-
I know this won’t be happening in Scrivener, but I do like in-line collapsable outlining as an option. It’s becoming a thing with modern idea processors. From Roam Research to Dynalist, there are a lot of SaaS apps that mix word-processing with outlining.
-
Since I don’t expect L&L to code a full-blown hyperlink map like you see in many ZK apps, I’d settle for some implementation in the corkboard. A way to navigate through the hyperlinked documents using the index cards.
I understand this is just a thought-exercise; I’m not holding my breath. Thanks for asking, anyway.
Cheers.
When you create a hyperlink for a page that doesn’t exist, Scrivener pops up the dialog box asking where the page should go.
While you can’t get rid of the dialogue, there are some things you can do to make this easier. This is roughly how I work:
- In Behaviors: Document Links, set Open new document links in: (Do not open).
- Create an “Inbox” folder in the binder somewhere, and the next time you get asked where to put a new link, target it.
- From now on just hit the Return key immediately after typing in the closing “]]” to make a link. Since each project remembers the last folder you used to create new sections into, that’s it.
It becomes a habit eventually, and something you don’t really think about.
Since I don’t expect L&L to code a full-blown hyperlink map like you see in many ZK apps, I’d settle for some implementation in the corkboard. A way to navigate through the hyperlinked documents using the index cards.
Yeah, some kind of link visualisation would be very nice! But probably not on the corkboard as there are too many competing ideas there. The best link maps I’ve seen are those that have algorithms to automatically arrange things so that lines don’t overlap, and neither freeform nor grid view would work with that model.
That sounds even better.
What about my original question? I’ve got a Scrivener project that is basically a wiki, containing names, dates, references and then loads of research–pdf’s and photos. I can compile everything into a Word document, or even a web page, but what about a wiki?
For a wiki, you’re creating a web site, not a single page, and so you need a format that keeps the documents separate and preserves the internal links between them. That sounds like Pandoc or similar, potentially with some third-party scripts to manipulate the output.
And there ends my own expertise in the matter, so I’ll leave it to people who know more. But I’ll move this thread to the Markdown/LaTeX space, where people might actually see it.
I’ve done this sort of thing myself in the past (back in the v2 days), when the L&L website had a wiki. As it was intended to be collaborative where users could help contribute, I had a need for easily incorporating updates from the server.
To get one thing out of the way, how such content would be exported is going to be along the lines of wiki markup in .txt files which can then be somehow brought into the actual wiki itself. One big exception are the rare wikis that are file-based for their content rather than solely using a database. DokuWiki is one such system that works that way, and it is in fact what I used for our website because of that advantage.
That aside, I think it is best to set your expectations more toward copying and pasting out of a text editor and into a website, though, as most wikis will not be able to do much with a bunch of .txt files (to the extent that making that a goal seems secondary to me).
Broadly speaking there seems to me three different approaches for maintaining a wiki from Scrivener source, with different pros and cons.
Pure syntax workflow
This is most often what I recommend to those looking to use Scrivener to maintain an external repository, using some kind of markup system, where the most important factor is round-tripping the data back into the software at some point. It is the method I used the past (before Markdown had effective WikiMedia conversion).
The main question this approach answers is: why build an elaborate conversion workflow when it is so easy to just write directly in WikiMedia or whatever? It was after all designed to be written with, like Markdown.
Details...
Pros
It is simple and effective, with no complex and potentially lossy conversion required, which means very little setup, if any. It’s so basic you can copy and paste out of Scrivener itself and into the website—that’s exactly what we do from our project used to maintain the knowledge base. There’s a lot to be said for having a level of simplicity and transparency like that, and Document Bookmarks can greatly ease the workflow since in some systems you can store a URL to the edit function of the page that binder item corresponds with online, as well as the read-only copy.
It also means the External Folder Sync feature, which is Scrivener’s take on the watch folder concept, is a viable part of the workflow. That may be convenient in some cases where additional tools are desired in the workflow, or if your wiki uses file based content, it could even theoretically be used to sync via FTP semi-automatically (I just used export and FTP though, as one has more up-front control over the file names that way).
Cons
The first downside with this approach is that it does limit some of what you might think to use Scrivener to do—but perhaps not as much as you think. I would say the main downside to me is the binder item = page limitation, i.e. being unable to use the outliner to organise longer articles more effectively. I suppose you could still do that, with the intention of only updating parts of a page on a regular basis (as many wikis make it easy to do).
Another impactful downside with a stricter round-trip protocol: it would limit how much you do with the compiler, if you choose to go that route instead of export/file-sync/copy-and-paste. For example, one might think to use styles to help generate wiki markup—you could certainly do that with ease, but it would be a somewhat one-shot in that there is no “decompiler” that could be configured to turn that markup back into styles. The same would be true of using the outliner to generate article heading depth with section layouts. Without some intermediary conversion to a format Scrivener can split on import back into hierarchy, you’d “lose” that capability after one generation and would have to turn it all off.
That’s just a general truth for the most part, applicable to almost everyone that uses Scrivener. We call it compile for a reason. It’s taking source data and turning it fundamentally into something else, that generally cannot be used to “reverse compile” back into source. That is not a practical reality in most cases, especially given the breadth of what can be done with it.
Wiki syntax production
This alternative builds off of the downsides in the previous and leans into them. Obviously, for this approach it is only one you would want to take if round-tripping is completely undesired, and more of a would-be-nice factor.
Details...
Pros
This is a capability that we put a lot of design thought and development into, when coming up with the various tools in the compiler and their integration with how a project can be structured, both at the outline and text level. A good practical example of that can be found in the Non-Fiction template category, when creating a new project, with the “General Non-Fiction (LaTeX)” template. Obviously the exact implementation here isn’t to produce wiki page data, but all of what that is doing to generate .tex files is a matter of configuration. Scrivener itself has no knowledge of LaTeX. By extension of that principal, one could build a complete wiki syntax exporter using the same methods it uses.
All around I would say this is the best way of using Scrivener in a markup oriented environment, if you don’t need round-trip. It’s extremely powerful, to the point that you could program the compiler to interact with the wiki’s API and even have Scrivener publish the updates directly for you, as noted above.
Plus, with a suitably style-based approach where little markup if any is found in the editor, one source could generate Markdown, WikiMedia, LaTeX, XML or any other plain-text output you might desire, and maybe even some rich-text stuff as well if you plan ahead for it.
Cons
An approach like this is very powerful and for some it will be more comfortable than the above, but it’s definitely premised upon the basis that the material is being written from scratch in Scrivener and is being produced outward only; not coming back into the software. That does not at all mean that’s the end of the line for the project of course, one can continue to create new updates from it indefinitely.
One downside is that by depending upon the compiler to produce page data it will in most cases mean compiling page per page rather than dumping the whole thing out into individual files per pages. There are of course some ways around that which involve scripting to split a single file into many, but that does increase the overhead of what you’d need to do to make your project functional for this workflow.
I don’t consider this a major downside though in practice, because it is worth considering that in most cases compiling a single page’s data from a portion of the draft will be fine, as you won’t be updating many articles at once offline. It’s probably only the initial export where there would be a degree of manual labour, and unless you are using something like DokuWiki, no matter how you slice it (or don’t slice it), it’ll result in about the same amount of copying and pasting. Doesn’t matter if you’re doing that from one file with obvious separators, or 30 files.
Pandoc aided conversion
The next alternative is to use Markdown on the writing side, which Scrivener has more extended native support for than the above. With this it would be possible to use Pandoc to convert Markdown that you write (or generate) with Scrivener to wiki syntax. This is the method I would use today, if I were maintaining a wiki server.
Details...
One advantage to using Markdown as your basis is that Scrivener does parse headings optionally, and can split a document back up into a nested outline. I have never been a fan of that workflow since it means dropping nearly everything Scrivener does outside of the text editor—snapshots, keywords, bookmarks, internal links… you lose all of that if you essentially start from scratch with every round-trip cycle. But for some it might be worth the sacrifice, particularly if they do not use much of those to begin with.
One could even convert wiki syntax back to Markdown and import it into Scrivener, to create a round-trip friendly environment. However this is going to be necessarily a bit “lossy” and may require some tuning to get a truly symmetrical conversion. All around if this were a priority, I would consider the “purist” approach first.
Something else to consider is that some wikis run on Markdown, or have mods that make them capable of taking Markdown source instead of wiki syntax. Prioritising a server that can provide that capability might make a round-trip Markdown approach much more viable as you are no longer hoping the conversion does what you want (or spending time fiddling with Pandoc templates to make it do so).
Where there is a stronger argument for using Markdown at the source is if you intend to publish to a variety of forms. If the wiki is just one possible avenue for getting this material out there, I’d stick with wiki syntax, but if you want to have a downloadable PDF or an eBook, then Pandoc is a good choice.
1 Like