Improving usability of wiki post editing?

“Mixing in “oops you gotta log in” isn’t really relevant is it?”

In this specific scenario/use-case it was, since trying to edit the post by double-clicking without knowing the need for login was a total waste of time (Besides knowing double-click wouldn’t take her where she wanted, if it was clearer that to edit the post the user needs to login, it would save her some time). Now a question raising is: Should this be the wiki-post creator responsability and inform the user on what they need (example, adding a line on top of wiki-post saying: to edit this please make sure you are registered) to be able to edit this post, or should discourse serve this built-in ? I think that the second option would be the most lean on the long-term

I don’t think “double click to edit” makes any sense at all. I am not aware of any place in Windows where that works. Also, how do you double click on a touchscreen?

I wonder if you are using irony on this :confused: . If so, pleas make it explicit.

She did it, so some sense it must have had to her. Also, she is running X, not Windows.
I believe its the “double-click to open” syndrome. When using a Window-system, double-click is quite common use for opening files to edit.
As for touchscreens (which I’m not sure if they are the most common media to access forums),
maybe if a wiki-post owner could have some inline option to create a link for the user to edit the post on that specific spot could work?

The wiki indicator is intentionally subtle, because wiki itself is a fairly rare state.

What makes you say it is rare? In which context is it rare?
Even acknowledging it may be rare in that context you are referring to, if the feature exists, how can the subtle be more intuitive to anyone who wants to edit that page ?

A giant screaming EDIT ME printed in 50 point blinking text superimposed over the post doesn’t seem warranted.

Not warranted at all. Blink tag was deprecated for some reason: Blink element - Wikipedia

Answer me this: how many people that end up on a Wikipedia page, end up editing that page? Maybe .001%? Less?"

Good question: Not so easy to answer though…A place where it may be possible to have an answer may be Wikipedia Statistics - Site map. Not so readable though.

Also, I don’t find Wikipedia so usable in what comes to editing content. And to add to that, chatting with moderators was definitely not intuitive the last time I was there. Discourse makes that way easier with name tags and reply to specific posts. Maybe Discourse could integrate with Wikipedia (wonder if you have thought of that?)

Some CMS text-editors do it by highlighting the container border and placing a clickable text on one of the corners (something like “Click to Edit” or just “Edit”).

By browsing I also found html5 contentEditable attribute:
and a way to save changes:

I wonder if anything like this could be made available for wiki posts ?

Also, we already added a much clearer “edit this” button to the revisions dialog, so once you get there you should be golden.

Pardon my ignorance, what is the “revisions dialog” ?

We added this little bit of CSS to make it more obvious: { content: " Edit this wiki post"; }


Definitely an improvement and certainly more intuitive. I will try and ask my sysadmin to add that too.
Though, in the specific use case I mention, and considering what wiki-posts really are, where the post is actually something closer to document editing, inline editing would be more effective.

@Tom_Newsom, as you seem to have had some thought on this, I would love to know what do you think of this inline-editing? Do you think it would bring value to you and your users?

Is there any other option that could make wiki-post editing more new-forum-user-friendly ?

Feel free to go into Admin, Customize, CSS, and add whatever you want for the wiki CSS styles in your instance if it is 120% wiki focused. This is particular to you.

Ah :smiley: , I feel I need to go learn more about discourse.

I wonder if you know of any way I could put contentEditable attribute html5 feature to this service only through these admin panels ? (without going more layers down into changing the source or going for plugins).

This is particular to you.

What is ?

So people can either click there, or click the to get to the edit button.

(The edit button shows by default on your own posts but does not show by default on other people’s posts.)

1 Like

Inline editing would be next to impossible with Discourse’s current architecture. I would push that out of your mind.

1 Like

Thanks for answering.
Want to give a bit more details about the why ?

Inline editing would be hard, but section editing is totally doable and solves 99% of the problem anyway.


Thanks Sam for answering. Would you care to explain how it might be implemented ?

I just added minor thoughts to point 3 in

I just add a support call to edit wiki. I think the easiest way (for users) to get the point would be to change the “reply line” for wiki posts so that it becomes explicit it’s a wiki by switching ‘edit’ and ‘reply’ buttons. Here’s a quick snapshot of what the line would look like (except I’d use the ‘wiki green’ for the button instead of gray.)


Oh I really like that. Wouldn’t necessarily have to demote the reply button to glyph-only, but for wiki pages we do generally want to discourage comments unless they’re properly on-topic.

1 Like

Hence the demoting :slight_smile:

(brb, signing up for a bunch of fake accounts so I can like that multiple times)

Oh, and it should go straight to edit mode, with the edit history still behind the edit count at the top of the post

Another UX issue came up: when you lose connection while editing and you save, you get a network error when you save, and ouch! People feel like they’ve lost their edit, because when the page finally comes up, they only see the previous version and not the editor with the current version they’ve been editing.

A few possibilities here, but the simplest would be to indicate that

Don’t worry about your unsaved edits: they’re still available in the editor. Try saving again when the network connection resumes.

Regarding the edit button, it would be nice in the history to keep the pagination and edit button visible when you scroll, so that you don’t have to scroll back up when you spot something worth editing.


This would be nice for the edit log regardless of if the post is a wiki. I could’ve sworn I suggested this before, but I can’t for the life of me find that post…

1 Like

I think it’s better for wiki posts to go ahead and hide reply behind the ellipsis and have the edit button “promoted” to the primary action position, consistent with what reply looks like:

You can still reply by expanding the ellipsis actions, of course. And all the other reply methods (to the topic, right gutter, etc) still work fine.

@eviltrout will work on making it so next week.


I think it would still be useful to write Edit Wiki, since it’s the current spelling for wiki posts, and when you refer to it to users, they will actually look for ‘wiki’ somewhere.

“- I turned the post into a wiki: you can edit it.”
“- I can’t find the wiki, where is it?”


A single word is more consistent, and editing is the actual activity.