Welcome to Codidact Meta!
Codidact Meta is the meta-discussion site for the Codidact community network and the Codidact software. Whether you have bug reports or feature requests, support questions or rule discussions that touch the whole network – this is the site for you.
UI question: how should the "post" button behave in restricted categories?
Most of the time, any logged-in user can post a new top-level post (question, article, maybe other types). Categories can restrict this posting access, however. For example, on the Meta blog, only moderators and administrators can post.
Everybody sees a "create post" button. If you aren't allowed to post in that category, clicking the button takes you to a new page that shows an error like the following:
(The "trust level" wording pre-dates the abilities system, in case you're wondering.)
This is not a great user experience. What should we do instead, keeping in mind that we want the software to work on touch interfaces as well as on desktops with mice (so we shouldn't rely only on tooltips)?
Here are some options that have come up in a discussion on GitHub:
-
Show the button in a disabled state. This is similar to what we do for comments or posts that are too short. Downside: this doesn't explain why it's disabled. (Comments and posts show a character count, so you can make a guess.) I think buttons that we show disabled are usually temporarily disabled -- you need to do something and then they become available.
-
Don't show the button at all. This is similar to the options under posts; you don't see "close" and "delete" until you can perform those actions. It is dissimilar to some other things, like voting buttons which are always shown. Would the absence of the button make people think there's a bug?
-
Show different text, either replacing the button or as different text on the button. This would have to be short to not break the layout -- "why can't I post?" might be too long (especially on a phone). There's also a concern that this puts a negative message at the top of every page on a restricted category.
-
Keep the button, and on click, show an in-page message instead of navigating away. (I'm thinking of, for example, what you get after you submit a flag -- a short overlay that you have to dismiss.)
-
Something else?
Some additional considerations
The text of the "create post" button is customizable. On many communities it's set to "ask question". The Code Golf sandbox uses "create draft". One category on Cooking uses "post recipe".
We should think about the case where a user who would otherwise be able to post is temporarily restricted, for example due to a suspension. "Policy" language probably mitigates this (for example, "X is required" versus "you can't because you don't have X").
The options for restricting access are not aligned with abilities (which came later). Here are the possible settings for "who can post"; I am not sure of the definitions of the second and third (will need to ask). Perhaps these options should be revised, but that's a separate issue.
- anyone with a user account (default)
- all but new users
- veteran users
- moderators only
- staff only
> Show different text, either replacing the button or as different text on the button. We could put something like a …
1y ago
With many different Codidact communities and more being proposed, along with other organisations that have their own ins …
10mo ago
The mechanics of what you do now is best. The wording could be a little softer with better explanation. A grayed but …
1y ago
3 answers
Show different text, either replacing the button or as different text on the button.
We could put something like a lock icon . This would immediately signal to the user that this is something that requires some kind of access.
We could leave the button enabled, so if a user clicks on it anyway, they will receive the page that explains that the action is restricted to those with the relevant ability.
0 comment threads
With many different Codidact communities and more being proposed, along with other organisations that have their own instances of the QPixel software, it seems unlikely that any single one of these suggestions will be consistently the best approach. Each occasion may have a different approach that would be best, so choosing one approach would make some occasions a compromise.
I suggest that all of the options that might sometimes be best be added to a site admin page where administrators (and possibly moderators - this could be a setting too) can select which approach to use for this particular category.
This is more work to implement, but meets the needs of communities that don't even exist yet, so saves having to make fine tuning changes over time.
0 comment threads
The mechanics of what you do now is best. The wording could be a little softer with better explanation.
A grayed button or missing button will cause questions or bug reports.
Dismissing an overlay is annoying, especially when ESC doesn't dismiss it. Going back to the previous page is easy and always works (ALT left-arrow). Most other things require using the mouse, which makes them much slower.
0 comment threads
0 comment threads