Wiki improvement – Split content into multiple sections?

Especially in case using Discourse as knowledge-base, it becomes clear, that some design decisions could struggle authors to unorthodox solutions. I love to use Discourse as the most advanced “notebook” and wiki in 21th century.

But if the topic become more and more complicated and structured, it would be great to have the option to edit the sources section-wise. Even the “good old” MediaWiki supports editing sections, without struggling with prior and upcoming content.

At the moment, I simply answer myself and link the posts at the first post with the TOC. It’s not ideal, but has the huge advantage to see which other post is referring to it and I’m able to better keep track on versioning.

That's how MediaWiki / Wikipedia solves this ...


What’s your opinion on this?

Thanks in advance!

5 Likes

Use multiple wiki posts rather than putting all the content in one giant wiki post. Boom. Problem solved. Now you can edit “sections” at will.

tenor

3 Likes

Does not work with the brilliant discoTOC, which works only for OP :wink:

5 Likes

You don’t need a TOC when you can link to different posts in the topic directly by URL…

1 Like

I made a similar request in the DiscoTOC plugin topic.

4 Likes

I still do so. Problem unsolved. Information overflow :wink:

image

I feel a lot of this request could be summarized as “Doctor, it hurts when my arms do this.” Well then… don’t do that :wink:

2 Likes

We‘re still talking about wikis?
Have you ever read long Wikipedia articles?

I think, sectioning would help a lot

1 Like

So section it into multiple posts as I suggested. Far more logical.

2 Likes

@codinghorror Thanks, I still do so.

There are several issues with that workaround:

  • discoTOC don’t work across multiple posts

  • I can grant access for others just for the category. If I allow others to post inside any topic, they destroy my structure and interrupting flow :wink:

  • Another good reason to have everything at the top and structured: The browser reader can’t handle post, that will be loaded some time later and they where split into multiple posts…

However, Discourse brings a great community experience. But wikis by their nature have some level of deepness and complexity.

2 Likes

You don’t need TOC when the URLs themselves are the TOC. The TOC would be a set of links in the first post, to posts in the topic.

Do you mean post privileges? Why are they creating posts? Aren’t you creating the topics? That’s no different than you creating the topic and replies to the topic?

I cannot understand this sentence? What is “the browser reader”?

I prefer some automation :wink:

discoTOC is a great example for a real need and restrictions, we can’t adress at the moment.

I mean, people with category access are able to post inside the knowledge base / wiki topics while it’s under construction. They should ask questions but not everywhere and everytime.

https://developer.apple.com/library/archive/documentation/Tools/Conceptual/SafariExtensionGuide/WorkingWiththeReader/WorkingWiththeReader.html

Firefox and other browsers have similar readers

1 Like

This is context worth understanding:

The question is, should wiki-posts support more article-like features? Why or why not?

@codinghorror your suggestion is practical, but leaves me wanting more. Both as a reader and as a content editor.

Yes, we can split an article into different topics but that doesn’t mean that’s the best solution for readability or ease of editing.

The fact that DiscoTOC - automatic table of contents exists at all (and has 87 like as I type this) is proof enough that Discourse users have a valid use case for wiki-article functionality that extends beyond what the default wiki-post offers.

What is “far more logical” is situational, as is the need for a dynamic TOC.

As a wiki-editor who loves Discourse’s implementation but sees potential in the idea described here, it feels more like I am asking the doctor for an X-Ray because moving my arm naturally is hurting and limiting my ability to function, when it arguably shouldn’t.

In that situation, the advice to “don’t do that” is ignoring a potential solution. :slight_smile:

3 Likes

I just need to quote Voltaire … he was a real genius :joy:

Doctors are men who prescribe medicines of which they know little, to cure diseases of which they know less, in human beings of whom they know nothing.

and

When the doctor walks behind his patient’s coffin, sometimes the cause of the effect follows itselfs. (free translation)

Just to clarify here, I was referring to something that happened during a quick brainstorming session. There’s no guarantee - implied or stated - that such a thing would ever be worked on and that’s why I said “not currently on any roadmap.”

2 Likes

Yup - I totally accept that. I just put that idea out there as a pipe dream, in case someone had an idea for implementing it, but I am not passionate about it.

I know @nbianca succeeded in respecting the cursor position when inserting canned replies. This fix has been a huge time saver and much, much appreciated on my end. More pipe dreaming, I am sure, but I wonder if it could be possible to do something similar with section headings, e.g. provide a link next to section headings to edit the post and take the cursor directly to that section.

1 Like

If the wiki features aren’t what you’re looking for, what’s stopping you installing mediawiki?

1 Like

I‘m not looking for a dedicated wiki. I really like the fusion of community features (60%) and knowledge-base (30%). The rest is optional :wink:

The right solution for knowledge exchange is the intersection of „records management“ and some kind of healthy / civilized participating.

2 Likes

Well you’ve got a couple of options here I guess:

  • accept the wiki behavior of discourse
  • develop a discourse plugin to extend the wiki functionality
  • deploy a separate wiki

At the point where your wiki post is so enormous that editing it is awkward, and you feel the desire to create a three level nested table of contents for it… I suggest either

  • breaking it up into multiple posts in the same topic

or

  • breaking it up into multiple interlinked topics

or

  • using a different software altogether that is designed first and foremost as a Wikipedia clone

The reason we don’t run into this here is because we don’t write enormous wiki topics.

4 Likes