Wiki improvement – Split content into multiple sections?

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

That makes sense for Meta, but do you see the potential value for Discourse users who do want to maintain longer wiki content?

I’m curious about the resistance to this idea. I love reading really long posts on Discourse with multiple headings, it feels very nice. Is there a specific argument for why editing really long posts with multiple headings shouldn’t also feel very nice?

If Discourse supports writing an enormous post in the first place, why wouldn’t we also want it to support a more convenient way to edit such a post?

2 Likes

Technically you can do anything with any software. You can write a novel on Twitter if you are willing to squeeze it out in an interminable series of 280 character replies-to-replies. That doesn’t, however, mean writing a novel is in any way the goal of Twitter or even a good idea.

Discourse has light wiki aspects, yes, but trying to turn it into a full blown Wikipedia substitute isn’t the goal.

5 Likes

That’s reasonable, but it’s also blowing the request here a bit out of proportion.

Let’s ignore the wiki aspect of this for a second though: at the core this feature request isn’t about wiki-functionality at all, it’s about post-editing.

Let’s say I write an announcement post in my forum about a release I do, and it’s just a long post by its nature. It’s not a wiki post at all, just a really really big post, with multiple headings.

The idea described here would make that much easier to work with, and Discourse supports the creation of that kind of post in the first place. Why is it a bad idea for Discourse to not support easier editing of such a post?

1 Like

Nope, I‘m not asking for rocket science. I‘m looking for a composer function (?) to collapse and expand (= hide) content I‘m not willing to edit. I‘d like to stay focused on some specific section - and - if possible:

  • The opportunity to link the specific headline
  • and have an always up2date automated TOC
3 Likes

No such features are on any of our known roadmaps.

3 Likes

Thank you @codinghorror for the clarity on direction.

@terraboss fwiw I think “wiki” in the topic here is causing some undue bias against your feature request. After reading here and thinking about this, I’ve realized that:

  • This request doesn’t have anything to do with wiki functionality. It’s a request for post-editing that could apply to to any post with multiple headings.

  • Post-length isn’t the primary factor that drives this need. A post with multiple sections, regardless of length, would benefit from section-specific editing.

  • The #release-notes topics here on Meta have some good examples where one might imagine the ux improvement to be gained. I hope the Discourse team might consider that such an improvement would be warranted (and yes, even a good idea) for a non-trivial amount of us who write and edit similar posts on a more frequent basis.

2 Likes

Note that release notes are broken up into several posts in the topic… as previously described…

2 Likes