Participant had difficulty understanding the concept behind "read only" commenting

Cross referencing: http://www.drupalusability.org/node/56

Before I start a patch, how does this sound:

• Enabled
• Locked
• Disabled

Looking at other sites I saw "comments closed" more often than "locked". For example: http://www.markboulton.co.uk/journal/comments/drupal_7_redesign/ ;-)

tag…

http://www.googlebattle.com/?domain=%22comments+closed%22&domain2=%22com...!

"comments closed"  	8,480,000 (view)
"comments locked"    	22,500 (view)
Total Pages Searched: 	8,502,500
GoogleBattle winner is 	"comments closed"

Ok, so the revised proposal is:

• Enabled
• Closed
• Disabled

Any thoughts/recommendations?

I like "closed". In conjunction with #394494: Comment settings on node form has no description, I think the issues regarding comment settings are solved.

Wouldn't Open be a better alternative to Closed? i.e.

Open
Closed
Disabled

We could then provide further information in a hover tip such as:

Open - Users can read existing comments and post comments.
Closed - Users can only read existing comments.
Disabled - Comments are not available.

I agree with the renaming suggested in #9 (Open/Closed/Disabled) - that makes more sense. I'm thinking I'll add the description of the options to the "Comment settings" fieldset, if that makes sense.

What about using 'Hidden' instead of 'Disabled'?

Open - users with 'post comments' permission can post comments
Closed - users can not post comments
Hidden - comments are hidden from view

I like the 'Open/Closed' wording since they are antonyms of each other, although I would rather use 'Locked' instead of 'Closed' since a lot of forum and blogging software uses this wording.

Also users may have a hard time deciphering the difference between 'Closed' and 'Disabled'.

I'm all for using simpler words so +1 on "Open". Might as well go all the way then and use "Off" instead of "Disabled". Then, do we really still need descriptions?

I would use either:

Open/Closed

or

On/Off

As always, tack on 'Hidden' for 'Disabled'.

Grandmaa asks what is wrong with Read only ?
A node that is read only from beginning and the author or the system did not want comment
has no meaning with comments "locked" or "disabled"

May be the participants should have IQ boosters and this can start with "read only" Eh ?

Blaming stuff on users is weak. See this tweet from one of the observers during the testing: http://twitter.com/beeradb/status/1260512737

Try and keep it constructive will you?

I like "Open, Closed, Hidden".

Grandmaa says "training" not equal to "blaming"
One or several tweet does not prove anything.
My construction : Keep "Read Me", that way already 10,000,000 users have learn it -
new ones will also. Changing it will add confusion.

Usually this is an admin or admin like options. Most of them know FTP and terms like Read only.
Most of them even know to right click a file property and find "read only" option.

+1 for Open, Closed, Hidden

In ideal world each radio option should have their own #description.

You *can* give radio buttons descriptions, it just looks ugly. I'll submit a patch both ways, though, with screenshots of each attached.

I have to agree with open/closed/hidden. I'd also agree that having a description for each one would be nice, but if that's horrid, just having a single description for the entire radio group would work.

IIRC one of the issues there is that there is no label for the actual radio buttons, instead the label currently exists on the fieldset. When using vertical tabs (as we did in testing) the label is moved over to the left so it's not directly above the radio buttons, which are left without context. This is probably something best suited in the vertical tabs issue queue, but it's worth mentioning here to understand some of the motivations for the issue.

I like open, closed and hidden as in #11 and I like descriptions for each one.

I don't have a problem with adding a *short* description. As cwgordon7 said earlier, having descriptions for each radio button is ugly and bad design. Maybe having a quick breakdown above/below the radio buttons?

Anyone up for writing the actual patch now? :-)

I'll do it tomorrow, I need to get sleep now though. :)

@cwgordon7 I hope I haven't stepped on your toes with this :)

Attached is a patch which renames Disabled / Read Only / Read/Write to Hidden / Closed / Open.

I haven't rolled a second option with descriptions on the individual radios, as I couldn't easily see how to do it.

@cwgordon7 I hope I haven't stepped on your toes with this :)

Attached is a patch which renames Disabled / Read Only / Read/Write to Hidden / Closed / Open.

I haven't rolled a second option with descriptions on the individual radios, as I couldn't easily see how to do it.

Grr. Remove git diff cruft (can anyone help with auto removal?)

Take 3 - it helps to have a current version of HEAD to diff from!

Spot the noob!

Last attempt before I give up!

Looks good to me, very small nitpick - 2 = open (read/write.)' shouldn't the period be outside the parenthesis?

We also need to rename the constants - no point having COMMENT_NODE_READ_WRITE if there is no longer a corresponding option.

This time please don't work on it, it's mine for a few hours while I rename the constants and roll it both ways (with and without individual descriptions on the radios).

Attached are patches and screenshots for both putting the description on the parent fieldset and putting the descriptions on the individual radios.

Descriptions per options are much better and don't look ugly at all. Are these all li-items? I would want to indent the descriptions to align with the radio label. (look at how the lines wrap in the text format fieldset in your screenshot

"Comments are hidden from view" This suggests to me that there are comments but they are just not shown. Imagine you are creating a new node that has comments on by default but you don't want this particular node to have them. "Hidden from view" sounds weird then, no?
Or does it mean "Comment form hidden from view"? That would make more sense when creating a node but less when changing to this setting on a node that already has comments… Hmmm. Don't know which one of these scenarios is more likely.

These aren't li elements, but I can indent them if you think it'll look better.

Note that if a node has no comments, there is no difference between "closed" and "hidden." Perhaps we should disable the "hidden" option if a node has no comments because it doesn't make sense.

Here's an additional screenshot and a patch for the indentation on the individual descriptions.

Thanks, looking very good now.

And yes it would be great to hide options that don't make sense!

Here's an updated patch that hides the "hidden" option if no comments exist.

I retract my earlier comment about descriptions per option looking ugly. It actually looks cleaner than having a bunch of text at the top.

Sorry about that, $node->nid is not set when the node is new. New patch attached, should be working now.

Should it (can it) also change the description on closed, so it doesn't mention existing comments if there are not any?

I think it's better to leave the description as is - I don't want to read that description more than a couple of times, and if it changes depending on which node I'm viewing then I'd personally find that a bit disconcerting. Removing 'hidden' when there's no comments seems like a good plan though.

Agreed with catch. The word "existing" makes that clear enough.
I guess at 18KB this needs at least one thorough review by a human? UX-wise I'd say nice work and rtbc.

+    // If the node doesn't have any comments, the "hidden" option makes no
+    // sense, so don't even bother presenting it to the user.
+    if (empty($comment_count)) {
+      unset($form['comment_settings']['comment']['#options'][COMMENT_NODE_HIDDEN]);
+      unset($form['comment_settings']['comment'][COMMENT_NODE_HIDDEN]);
+      $form['comment_settings']['comment'][COMMENT_NODE_CLOSED]['#description'] = theme('indentation') . t('Users cannot post comments.');
+    }
   }

This would look a lot nicer in the initial building of the array:

if (!empty($comment_count)) {
  $options[] = COMMENT_NODE_HIDDEN;
}

etc.

Also it looks like this patch actually does change the description of the closed radio when there's no comments, as dicscussed already I don't think that's needed.

Apart from those looks ready to me.

Excellent. Committed to CVS HEAD. This marks a minor API change that will need to get documented in the upgrade documentation. Please mark this 'fixed' once it was documented. Also, feel free to come up with refinement patches if you want to. Thanks all!

It's really bad form to expand the radios ourselves. That's why we have #process! :) Here's a FAPI cleanup for adding the options to the comment settings radios. The plus side is we can also apply the descriptions to the content type settings as well now.

Quick revision that puts the comment options all in the same order, both on node forms and content type forms.

Edge case:

What happens here if the last comment from a hidden thread get's deleted... since hidden will disappear what will the resulting effect be on the next form edit? Any possible negative consequences there? (sorry, I feel like I should know this one)...

Without checking, I think you'd end up with two required radios, neither of them selected, and a required error if you leave them unchecked. That doesn't seem too painful for what is a fairly rare edge case, but worth knowing about.

If hidden is no longer an option, and $node->comment is set to COMMENT_NODE_HIDDEN, it will change the default value of the form element to COMMENT_NODE_CLOSED.

It's already in core, but I just found out what theme_indentation() does. That's horrible, we should just take that out and file a new issue for some margin/padding on radio descriptions.

Removes the use of theme_indentation() - separate issue to make radio descriptions look nicer at #412030: Descriptions on radios are ugly. Also reverted the change to the 'closed' desription when there's no comments - I think it's better to have it consistent rather than change it depending on status - removing 'hidden' as an option is enough there.

Is Open Closed and Hidden + a description the best we can do? Unless a lenghty explanation is required (eg "Not recommended. If you select this, the universe will end.") we should opt for clear labels.

Currently there are descriptions as to what each setting means. The three options, are IMO reasonably clear, but the descriptions gives more information for those who are unsure.

Can you suggest other phrases that would succinctly describe the different options?

Does any of this still apply?

Moving back to needs review to get more eyes on this again.

I still believe the actual implementation is confusing. If I set the comment to hidden when creating a content type that option is not there when creating a node because the "hidden" option is removed until there are comments. I believe we should revert to the previous implementation as in http://drupal.org/node/394374#comment-1393888

I'm not sure if any of this is still relevant, but it might be useful to add a one-line explanation of what "Hidden" means. "Open" and "Closed" are pretty obvious, but it isn't immediately apparent what "hidden" comments are.

@amc I think its pretty clear, you cant see them as in hidden.

I think you are arguing the possible technical confusion with user confusion?

Yes, I was referring to user confusion. For example, hidden from whom? From me, even if I'm logged in as the main administrator (user 1)? From users with specific permissions? Will users still be able to *submit* comments, but they'll just be hidden from view once submitted? (You may think this last one is silly, but it's a reasonable interpretation, since "Closed" is a separate setting.) I just think a short explanation beneath the selector would be helpful.

As per #49, we need to let people know that these constant's names have changed. This includes updating http://drupal.org/update/modules/6/7 and the developer mailing list.

Actually, I'm unhappy that the constants were changed. If I was looking through a module and saw COMMENT_NODE_OPEN, I don't think I'd immediately know what it meant like I would COMMENT_NODE_READ_WRITE.

It's far too late to be asking this now, but I would like to know in what way the participant found "read only" confusing. In the context of "read and write" and "disabled", it should be inferred that it is something halfway between those two extremes. I suppose in the case when there are no comments, especially on new nodes, there doesn't seem to be much difference between "disabled" and "read only".

How about something like this?
* New comments allowed
* Old comments visible
* Comments hidden

And I completely forgot to mention that I added http://drupal.org/update/modules/6/7#comment_node to the list.

+1 to

Enabled (AKA open)
Enabled but no longer accepting new posts (AKA closed)
Disabled (AKA hidden)

Also they should be radio buttons not a dropdown. This is the primary action for this tab and it needs to be more clear/discoverable

Sorry, UI freeze. This is not a critical issue.

@Noyz Sadly, in terms of usability standards you can't deny it's critical. But in the light of all the issues we have this is most certainly not critical, there are many other parts of Drupal even more fundamental which are hard to use/cannot be completed by 100% of the users. That is a hard consideration I have to make, but priorities are not on what can or cannot be completed but what will have the biggest impact in disrupting or preventing people from completing a task.

You can make a patch (I think you guys where on the right track) and hope it will be committed, but we are in UX freeze so consider it might not be committed.

Patch please :) We can now get this in, sorry I had to be so though in the UI freeze phase..

I was also confused.
I like the idea of radio buttons or check boxes

Radio:
Enabled/Open - Users can view and make comments
Enabled/Closed - Existing comments visible but no longer accepting new posts
Disabled/Hidden - No new comments allowed. Existing are hidden, not deleted.

Check:
Enable form - People can leave comments
Show comments - List of comments people have left.

The advantage of the checkbox option is more flexibility with a minimal UI.

My two cents - the status quo as of D7.14 sucks. In my case, I wasn't 100% sure about totally disabling comments in D7 until I read this thread and wasted 5-10 minutes of my life researching it.

"Hidden" totally sucks because it's too ambigious. Hidden could mean, "Commenting is still enabled but hidden," etc.

OTOH, "Disabled" is 100% clear - disabled means "comments are off".

* If the DDL options must be one word, Open/Closed/Disabled gets my vote.
* If they can be two words, #75 is best.

A bulleted explanation below it would help people out no matter what words are used (with the text being swapped out with jQuery UI for saving space)?

BTW - I don't mind the drop down (vs. radio - for space reasons, though having radio buttons would've made it clearer for those of us coming over from D6 to D7.)