Improving usability of wiki post editing?

Feature
1

I would like to reopen https://meta.discourse.org/t/making-it-clearer-how-to-edit-a-wiki-post/18527, but didn’t know how, so added this new post.

So, I’ve just asked a friend to open this post I wrote, sending her a direct link: What are the things that need to be addressed to effectively feed Love and Peace thoughts and actions into America's presidency ? - Spreading Love - Dialogue to test how easy she would find to understand the text and edit it.

I just wanted that anyone - even non-used to forum users - coming to my forum could edit this.

She started by double-clicking my text to try to edit it. She couldn’t.
It was not clear (for her, through my eyes) she needed to register. She spent a while trying to write on the post, and I just said she needed to. She only realized how to register when she clicked Post a reply and the login window appeared (which she did reluctantly and after I requesting so, as I had written in the text for people to change text in specific places).

Ok, so, she logged in - perfect, read that an email was sent, activated the account - very nice and flowing.

And then she went back to the post and tried again to double-click it…
Meanwhile I was checking if the admin parameters I had set for a user to edit a wiki post would send some intuitive warning… Eventually they did, though we found the pencil edit icon before that, and after clicking the three dots icon.

So…
I wonder if somehow is possible to have this “edit on and where double-clicked” feature for wiki posts.

Any suggestions to get, with current features, some users participation on that topic I mentioned are also welcomed.

2

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

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?

The wiki indicator is intentionally subtle, because wiki itself is a fairly rare state. A giant screaming EDIT ME printed in 50 point blinking text superimposed over the post doesn’t seem warranted. Answer me this: how many people that end up on a Wikipedia page, end up editing that page? Maybe .001%? Less?

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

5 Likes
3

“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: W3Schools Tryit Editor
and a way to save changes: How to Edit Web Content with HTML5's Contenteditable Attribute - Hongkiat

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” ?

4

We added this little bit of CSS to make it more obvious:

.post-info.wiki::after { content: " Edit this wiki post"; }

8 Likes
5

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 ?

6

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.

7

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 ?

8

image.png843×360 19.5 KB

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
9

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

1 Like
10

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

11

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

2 Likes
12

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

13

I just added minor thoughts to point 3 in

https://meta.discourse.org/t/what-is-a-wiki-post/30801/8?u=almereyda

14

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.)

10 Likes
15

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
16

Hence the demoting :slight_smile:

17

(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

18

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.

3 Likes
19

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
21

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.

3 Likes