Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
Participant had difficulty understanding the concept behind "read only" commenting. "locked" was suggested as an alternative.
Comments
Comment #1
ultimateboy CreditAttribution: ultimateboy commentedCross referencing: http://www.drupalusability.org/node/56
Comment #2
cwgordon7 CreditAttribution: cwgordon7 commentedComment #3
cwgordon7 CreditAttribution: cwgordon7 commentedBefore I start a patch, how does this sound:
Comment #4
yoroy CreditAttribution: yoroy commentedLooking at other sites I saw "comments closed" more often than "locked". For example: http://www.markboulton.co.uk/journal/comments/drupal_7_redesign/ ;-)
Comment #5
yoroy CreditAttribution: yoroy commentedtag…
Comment #6
yoroy CreditAttribution: yoroy commentedhttp://www.googlebattle.com/?domain=%22comments+closed%22&domain2=%22com...!
Comment #7
cwgordon7 CreditAttribution: cwgordon7 commentedOk, so the revised proposal is:
Any thoughts/recommendations?
Comment #8
ultimateboy CreditAttribution: ultimateboy commentedI like "closed". In conjunction with #394494: Comment settings on node form has no description, I think the issues regarding comment settings are solved.
Comment #9
wretched sinner - saved by grace CreditAttribution: wretched sinner - saved by grace commentedWouldn'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.
Comment #10
cwgordon7 CreditAttribution: cwgordon7 commentedI 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.
Comment #11
bsherwood CreditAttribution: bsherwood commentedWhat 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'.
Comment #12
yoroy CreditAttribution: yoroy commentedI'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?
Comment #13
bsherwood CreditAttribution: bsherwood commentedI would use either:
Open/Closed
or
On/Off
As always, tack on 'Hidden' for 'Disabled'.
Comment #14
grandmaa CreditAttribution: grandmaa commentedGrandmaa 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 ?
Comment #15
yoroy CreditAttribution: yoroy commentedBlaming 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?
Comment #16
Damien Tournoud CreditAttribution: Damien Tournoud commentedI like "Open, Closed, Hidden".
Comment #17
grandmaa CreditAttribution: grandmaa commentedGrandmaa 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.
Comment #18
kika CreditAttribution: kika commented+1 for Open, Closed, Hidden
In ideal world each radio option should have their own #description.
Comment #19
cwgordon7 CreditAttribution: cwgordon7 commentedYou *can* give radio buttons descriptions, it just looks ugly. I'll submit a patch both ways, though, with screenshots of each attached.
Comment #20
beeradb CreditAttribution: beeradb commentedI 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.
Comment #21
YesCT CreditAttribution: YesCT commentedI like open, closed and hidden as in #11 and I like descriptions for each one.
Comment #22
bsherwood CreditAttribution: bsherwood commentedI 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?
Comment #23
yoroy CreditAttribution: yoroy commentedAnyone up for writing the actual patch now? :-)
Comment #24
cwgordon7 CreditAttribution: cwgordon7 commentedI'll do it tomorrow, I need to get sleep now though. :)
Comment #25
wretched sinner - saved by grace CreditAttribution: wretched sinner - saved by grace commented@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.
Comment #26
wretched sinner - saved by grace CreditAttribution: wretched sinner - saved by grace commented@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.
Comment #28
wretched sinner - saved by grace CreditAttribution: wretched sinner - saved by grace commentedGrr. Remove git diff cruft (can anyone help with auto removal?)
Comment #30
wretched sinner - saved by grace CreditAttribution: wretched sinner - saved by grace commentedTake 3 - it helps to have a current version of HEAD to diff from!
Comment #31
wretched sinner - saved by grace CreditAttribution: wretched sinner - saved by grace commentedComment #33
wretched sinner - saved by grace CreditAttribution: wretched sinner - saved by grace commentedSpot the noob!
Last attempt before I give up!
Comment #34
catchLooks good to me, very small nitpick -
2 = open (read/write.)'
shouldn't the period be outside the parenthesis?Comment #35
cwgordon7 CreditAttribution: cwgordon7 commentedWe 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).
Comment #36
cwgordon7 CreditAttribution: cwgordon7 commentedAttached are patches and screenshots for both putting the description on the parent fieldset and putting the descriptions on the individual radios.
Comment #37
yoroy CreditAttribution: yoroy commentedDescriptions 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.
Comment #38
cwgordon7 CreditAttribution: cwgordon7 commentedThese 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.
Comment #39
cwgordon7 CreditAttribution: cwgordon7 commentedHere's an additional screenshot and a patch for the indentation on the individual descriptions.
Comment #40
yoroy CreditAttribution: yoroy commentedThanks, looking very good now.
And yes it would be great to hide options that don't make sense!
Comment #41
cwgordon7 CreditAttribution: cwgordon7 commentedHere's an updated patch that hides the "hidden" option if no comments exist.
Comment #43
bsherwood CreditAttribution: bsherwood commentedI retract my earlier comment about descriptions per option looking ugly. It actually looks cleaner than having a bunch of text at the top.
Comment #44
cwgordon7 CreditAttribution: cwgordon7 commentedSorry about that, $node->nid is not set when the node is new. New patch attached, should be working now.
Comment #45
YesCT CreditAttribution: YesCT commentedShould it (can it) also change the description on closed, so it doesn't mention existing comments if there are not any?
Comment #46
catchI 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.
Comment #47
yoroy CreditAttribution: yoroy commentedAgreed 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.
Comment #48
catchThis would look a lot nicer in the initial building of the array:
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.
Comment #49
Dries CreditAttribution: Dries commentedExcellent. 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!
Comment #50
Dave ReidIt'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.
Comment #51
Dave ReidQuick revision that puts the comment options all in the same order, both on node forms and content type forms.
Comment #52
beeradb CreditAttribution: beeradb commentedEdge 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)...
Comment #53
catchWithout 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.
Comment #54
cwgordon7 CreditAttribution: cwgordon7 commentedIf 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.
Comment #55
catchIt'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.
Comment #56
catchRemoves 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.
Comment #57
Heine CreditAttribution: Heine commentedIs 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.
Comment #58
wretched sinner - saved by grace CreditAttribution: wretched sinner - saved by grace commentedCurrently 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?
Comment #59
Bojhan CreditAttribution: Bojhan commentedDoes any of this still apply?
Comment #60
wretched sinner - saved by grace CreditAttribution: wretched sinner - saved by grace commentedMoving back to needs review to get more eyes on this again.
Comment #62
dodorama CreditAttribution: dodorama commentedI 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
Comment #63
amc CreditAttribution: amc commentedI'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.
Comment #64
Bojhan CreditAttribution: Bojhan commented@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?
Comment #65
amc CreditAttribution: amc commentedYes, 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.
Comment #66
Island Usurper CreditAttribution: Island Usurper commentedAs 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.
Comment #67
Island Usurper CreditAttribution: Island Usurper commentedActually, 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
Comment #68
Island Usurper CreditAttribution: Island Usurper commentedAnd I completely forgot to mention that I added http://drupal.org/update/modules/6/7#comment_node to the list.
Comment #69
Noyz CreditAttribution: Noyz commentedI noticed a recent post on this topic and was hopeful the terminology was being rethought.
Open/Closed/Hidden are terms optimized for the use case of turning comments off after comments have been added, versus the more common use case of creating a content type and deciding if comments should be enabled or disabled. New users trying to do this will hit a wall, e.g. "I just don't want comments - is that closed or hidden?" I'm an experienced Drupal user and the existing terms confuse me every time. This list would be much more understood if the labels were
Enabled (AKA open)
Enabled but no longer accepting new posts (AKA closed)
Disabled (AKA hidden)
Comment #70
tkoleary CreditAttribution: tkoleary commented+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
Comment #71
Bojhan CreditAttribution: Bojhan commentedSorry, UI freeze. This is not a critical issue.
Comment #72
Noyz CreditAttribution: Noyz commentedBojhan, I understand how code/bugs could be marked critical, i.e.,, a feature is broken. But how are you saying that a usability issue isn't critical? If a feature cannot be completed by 100% of users (even though it worked functionally), would you say that's not critical? I hope not, but given your answer, I think the answer is yes.
Heuristically speaking, I can tell you that the majority of new users will struggle to figure out how to enable/disable comments - a fundamental feature of Drupal.
Comment #73
Bojhan CreditAttribution: Bojhan commented@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.
Comment #74
Bojhan CreditAttribution: Bojhan commentedPatch please :) We can now get this in, sorry I had to be so though in the UI freeze phase..
Comment #75
chrowe CreditAttribution: chrowe commentedI 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.
Comment #76
aubjr_drupal CreditAttribution: aubjr_drupal commentedMy 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.)