Define + Architect Wiki functionality

I tested the D7 versions of some related modules:

http://drupal.org/project/wikitools

D7 stable. Useful for easing the process of finding and creating wiki pages.

http://drupal.org/project/freelinking

D7 stable. Useful for linking to other wiki pages.

http://drupal.org/project/tableofcontents

D7 dev. Works well to auto-create TOC in a block, but the input filter doesn't work yet.

http://drupal.org/project/pearwiki_filter

No D7 work at all. If we need to do more than freelinking can do, and assuming we want to use a standard syntax, something like will need to be ported.

I'm not optimistic about allowing Markdown input along with WYSIWYG and embedded media. Media module only works with WYSIWYG currently, so that would need a new implementation with Markdown, something I've tried before, but gave up on. Beyond media embedding, all other HTML content would need to be converted to Markdown before anyone with the Markdown preference could use it. The best approach to that is Markdownify, which only has a D6 sandbox project currently.

In general, I think adding Markdown to WYSIWYG would introduce way more problems than it would solve.

Hi folks.

I would like to suggest one step back. Let's try to find how many people actually are using extra Wiki features (that are provided with Wikitools and freelinking modules).

From my personal experience as user and community manager / support / site builder although everybody knows what Wikipedia is, people are not aware of underlying technology / implementation.

Even less people will use special wiki features, once they dig that the main purpose of Wiki content type is collaborative editing.

My proposal is to go with only one content type, and implement something like #1543114: Edit options on nodes. But, I'm aware that this is not easy task and somewhat utopistic. :/

So, from more realistic point of view, IMO it would be great to have:

• Consistent content creator / editor experience through Discussion and Wiki content types (i.e. only one text input format - WYSIWYG)
• Clearly visible notification on top of the wiki nodes that you can Edit it! (like on GDO)
• TOC
• Book module integration out of the box

IMHO, Wikitools module is really not neccessary, and Linkit is providing way more better experience than freelinking.

My two cents..

Updating requirements.

We are planning to use this on a company intranet. To say that some of the folks are technically challenged is a massive understatement. They don't care about wiki syntax. At all. The best thing would be to use a normal wysiwyg and mark it as editable. So Mario, I agree with you totally. When people say wiki, they mean collaborative editing, not the guts.

I agree, whenever I'm trying to explain what a wiki is, I use the example of wikipedia, and usually when I'm talking to non-technical types I find they don't even know that the idea behind that is collaborative editing.

Big +1 to "Clearly visible notification on top of the wiki nodes that you can Edit it! (like on GDO)"

I also like the idea of Linkit.

Not mega-fussed about book module integration - what I really like on wikipedia is the little table of contents you get on the top of the page, under the summary, that points to each of the H2 elements (for that reason I like the idea of utilising 7.x ability to have a separate summary to body). Really helpful for traversing a wiki document... but do you really need book module for that?

Further to #6, maybe book module isn't a bad choice, but I've never liked its default behaviour of having those backward/forwards links at the bottom of a page. When I first came to Drupal I couldn't figure out how to navigate documentation for ages (but maybe I was just being dumb) and even now find it a little awkward. I suppose for examples like http://drupal.org/documentation/structure it's a fair enough solution to catalogue a vast number of guides relating to the same heading, but for a simple wiki document I like on wikipedia how even though a page is still built using separate section pieces, the page itself forms one complete document.

The following modules appear to achieve the sort of functionality I mentioned in a simpler way than book module would have to be configured to do it:

http://drupal.org/project/edit_section
http://drupal.org/project/tableofcontents

Edit: edit_section looks pretty stable in 7.x but not the same for TOC whose 7.x port is a young dev, and appears to have particular problems with panels http://drupal.org/node/1424896#comment-6010322 but I'm sure it would benefit from a boost by way of incorporation into Commons.

Update requirements

Woohoo, lightsurge and crimsondryad, thanks for the feedback! :)

Updated issue summary based on provided feedback...

I guess we are aiming at 2) Average Joe / Jane use case then, right?

Regarding book module, I look at it as another very important way of organizing content: by hierarchy. We have tags and taxonomy, but, I found this also helpful. I agree completely with you that book navigation sucks - maybe this could be addressed via theme layer? Or some extra nice little book UI module. ;)

BTW, I used TOC at one knowledge base site - it's really nice to have it.

I'm strongly against any kind of special markup - at least out of the box / default. And also, if I connected dots in the right way - this could be not so easy to achieve if we go via Spark WYSIWYG (editor) road. But, lightsurge, our commons (wysiwyg) secret agent @ Spark issue queue, can tell a little bit more about that. ;)

On second looks edit_section 7.x seems rather underdeveloped as well.

...and I'm not sure about the method of input filtering in either TOC or edit_section, seems like something that could break in some contexts and seems flimsy :/

Ack, any better way? Seems like such a pain to have to create a whole new node just to create a navigable section in a wiki. Or to have to edit the whole wiki just to add a tidbit more information to a subsection.

Yeah we could have wiki sections that are fields or referenced entities so we can deal with generation of a TOC and individual section editing in a more 'Drupalised' sort of way, but wouldn't this make full node form editing an awful UX? As a user I don't really want to add a new field or create and reference a new entity just to add a new section to a wiki - I just want to add a new heading.

As I recall from TOC 6.x you can adjust on the content type level to automagically have TOC on nodes...no need to input any data / tokens into content / wiki node.

And also, if I connected dots in the right way - this could be not so easy to achieve if we go via Spark WYSIWYG (editor) road

Yeah this is partly what I mean by 'flimsy'. Trying to get Drupal to inspect the contents of nodes and make increasingly complex judgements as to how a node 'might' look once it's submitted is like trying to imbue it with some form of artificial intelligence ;) http://drupal.org/node/1580210#comment-6068160

This is also relevant even without in place editing here though where you try to get TOC to construct some kind of hierarchical menu from some tag that a user has submitted (imagine h2s under h5s, h1s under h6s, because a user wants to make the text bigger... etc!). And in terms of edit_section where it tries to identify chunks of content between occurrences of heading tags, then reconstruct the full node to save... etc etc. It's like trying to teach Drupal to second guess intention from limited and volatile data when really we should be feeding it proper data, it's like trying to get my dog to cook his own dinner, I'm sure he'd have a go but he'd probably make a few errors and it would be messy clearing it up.

I like this TOC method using a jquery plugin:

http://fuelyourcoding.com/scripts/toc/examples/example2.html

...and the 'edit_section' bit could be achieved through In Place Editing, once that arrives.

Very nice example of a TOC here:

http://www.impressivewebs.com/demo-files/fixed-TOC-dropdown-jquery/

Oy vey....apparently I wasn't thinking this through nearly enough.

1. Yes, absolutely average joe use case.

2. Intuiting nav via Jedi Mind trick...not so much. I see what lightsurge is getting at with wanting subsections to have jumpable links. It just seems way complicated. Book does create nav out of the box and it also has the benefit of being in core, though I thought I heard for D8 it may be dropped? It isn't pretty but it does work, so +1 for the small module to theme Book.

I'm looking at the functionality of edit_section and tableofcontents. Looks like they are related but don't do the same thing. In that scenario it's an AND, not an OR.

There is benefit in having a hierarchy. Say you have a n00b in your office and you want them to learn a whole process. You can say "Read this entire section from 2.1 to 8.5". If a person doesn't know the keywords to search under, they may not find the appropriate resources.

We were looking at http://drupal.org/project/term_reference_tree for something else. Maybe that would help get closer? The problem I see with this approach is if a person is entering a new taxonomy term while adding the page, the dropdown may not have a place to list the new term.

Hey Team, I'm excited about what you're developing and REALLY appreciate all your time and effort. I would like to throw-in my 2 cents for a feature request:
Can there be moderated collaborative editing within the wiki structure you're proposing? i.e. the "originator/owner" of the page can accept or reject a subsequent user's changes wholly/individually (similar to track changes in Word, but not as fancy)?

@maguffinator: I believe that you are talking about revision moderation? In any case, it's a really good feature request, but, IMHO, doesn't belong to the default/expected Wiki behavior..

Also, this likely won't be part of the out of the box (at least not MVP according to Commons D7 user stories) version of Commons 3.

AFAIK this functionality could be achieved via http://drupal.org/project/revisioning module.

It also sounds a lot like Workbench Moderation. There's actually a suite of modules, including Workbench Access which would allow specific users / roles to only access specific sections of the site based on a taxonomy / path ( instead of just content types ).

That might be helpful in a wiki situation by saying role A can only edit the section about bicycles while role b can only edit the section about motorcycles ( for example ).

Sum up... -- m.m