This would be very useful! I would like to consider this as a small UI design pattern.
An updated screenshot would be nice.
1. Adding
🌱
Providing additional methods of navigating the admin interface
Active
for a similar situation.
2. Though the screenshots are old, current Claro designs also don't add a final horizontal line in these kinds of lists. This suggests that the link is part of the content of the last list item instead of a separate thing.
It's not a primary, not even secondary action, more like a helpful navigation hint: 'Oh, by the way, if you want to create your own version of these thingies, go here. Right aligned would work I think. It probably needs more top spacing or border to clearly separate it from the list items above.
Lets not be too eager here Roy!
The two obvious alternatives in contrib appear to be in good shape, both with releases made this year
https://www.drupal.org/project/autoban →
https://www.drupal.org/project/advban →
Lets just go ahead and do this? Removing the framework manager review tag as @catch opened this issue and @larowlan chimed in at #1570102-37: [Policy] Deprecate Ban module in Drupal 10 and move it to contrib for Drupal 11 →
This extension is being deprecated, see #[3376070] It will be removed from core and moved to a contrib project, 📌 [11.x] [Meta] Tasks to remove Book Active .
This is now Postponed. The status is set according to two policies. The Remove a core extension and move it to a contributed project → and the Extensions approved for removal → policies.
This issue may be re-opened if it can be considered critical, If unsure, re-open the issue and ask in a comment.
Probably good to mention here: 📌 [Policy] Move book to contrib in Drupal 11 Fixed Book will indeed be moved to contrib in Drupal 11.
Excellent idea, lets do this. Two questions:
- Provide or create? Maybe create is the simpler word? Lets also add 'a': Create a new menu item by default.
- Was this deliberately put at the bottom of this list of settings? I can also imagine it at the top, as the very first consideration and decision to make for this menu settings section.
(forgot I had attached an image, a version of that diagram is also in 🌱 New “content creation” menu proposal Needs review , with a previous ux maintainer reviewing it 🌱 New “content creation” menu proposal Needs review as "great idea, like a more opiniated shortcuts menu." :-)
For a such a modular system as core + contrib is, I think it's fundamental for the core part of the system to provide a mechanism for creating a customisable set of links to important/often used create/admin pages. Tools for navigating a Drupal application are not optional features but fundamental capabilities. I do agree that current Shortcut ux is not providing what is needed to do that well, but in the general sense, I think this capability should be provided by core.
No objections to remove it from core and hopefully have it prosper in contrib. As Gábor points out, an important part of what it does is already achievable with core menus. What Book adds to that in management and outlining have a very clunky UI that has received very little attention over the years.
I wanted to think that paging through a hand-picked selection of things (entity queue?) is in itself not an uncommon use case. There's even a Paging category → for contributed modules, but a quick look at usage numbers there shows numbers from 3000+ installs then tapering of quickly and mostly for older versions of core.
I think this does not implement a confirmation dialog? Which is fine, it's not deleting but removing so recoverable. Would be good to update the issue summary to reflect this.
Why a select list here when all the other variations of this use checkboxes?
https://www.drupal.org/docs/develop/user-interface-standards/interface-text → says to please not use please in UI copy :)
I was initially leaning to having just the one button "Save and manage fields", but in Slack, @ckrina correctly pointed out that managing fields is not always as important a next step for media, comments. So, lets do a "Save and manage fields" as the first and primary button, "Save" as the secondary button.
Good call @ckrina. I'm happy to provide a strong opinion on which one to use :-D
Is the issue about inconsistencies or about workflow? Lets not fix inconsistencies by introducing workflow changes, or at least be clear about how these impact eachother :)
Not saying it wouldn't be useful to add the "and manage fields" option, but then that should probably be the only button. I notice that editing an existing content type has just "save" and that's fine. So for content types we really are in the specific context of creating a new thing that very likely needs further work in setting up fields. If the same situation (editing existing is a different screen than creating a new one) applies to creating new Comment, Media, Block types, than "Save and manage fields" could well be the only primary button there.
> We might be even able to move the label to the second step of the process.
That seems to be the way to go. It's fine to commit this as is as long as we keep iterating but sounds like that's the plan anyway. E.g. the visual relationship between the main item and its subs could still be strengthened by dimming the other main items. But I'm especially wondering why the subs are shown at the bottom instead of spliced in right below the selected item.
Also, on the one hand: good to see a follow up for refining field descriptions, on the other hand, why introduce them in this really not yet great version? It's a bit uncomfortable to see this essentially big improvement introduce its own significant ux regressions.
Ok, done complaining :) This should be committed because it's a very big step in the right direction. Good work!
Thanks Lauriii for setting up this simplytest.me so that I could play around with this a bit. (https://master-nnmtgk55ieypf82fpkpcsj7mvgb6d0ez.tugboatqa.com/ for as long as it lasts)
I think I found a bug where going back and forth between selecting fields ended up creating a different field than what was selected on save.
Steps to reproduce:
- go to /admin/structure/types/manage/article/fields/add-field
- click 'Boolean'
- click 'Reference'
- select taxonomy term as the reference type
- click Save and continue
- This sends me to the field settings for a boolean field instead of for the taxonomy term reference I selected last
A usability issue that bit at least me *every time* I tried out this procedure is that I forgot to enter a label for the field. The fields types are visually so attractive that the poor little label field above got ignored.
Can we define a pragmatic approach that covers items 1 to 3 in #63, and establish what's needed to add the *hook for contrib* as suggested in #62?
Then, lets figure out if both can be done in this single issue here or if the hook for contrib part should be a separate ticket.
I'm wondering if the current situation really is a stumbling block for peope? Not to deny or disparage the initial report but over the four years since this was opened nobody chimed in with similar doubts about how this confuses them and this is certainly not fixing some currently broken situation.
Without further evidence on this being an actual problem I'm leaning towards a won't fix for this.
I did have a question :)
Could the error message list the fields in order of their appearance on the form, so 'name' first, then 'paste...' if both have errors?
Thank you for the screenshots, they help with reviewing UI :)
Could the error message list the fields in order of their appearance on the form, so 'name' first, then 'paste...' if both have errors?
(Unrelated to the actual bug being worked on here, but anyone else find that "Paste your configuration here" label reading weirdly in context of the error message?)
Describe this foo type.
These duplicate the label and are a bit bossy :) I think these can be left out.
Had a quick look at how Google docs and Gitlab wiki pages do this. Both explicitly *remove* the UI for editing when showing an older revision of a document.
Google docs adds a primary button to revert to this revision
Gitlab wiki only points back to the revision history overview
So I tend to agree with @29 in that we should not add the standard set of node local actions. Adding the option to directly restore to the currently shown revision seems useful. How's this for a new title for this issue?
Minor tweaks for consistency don't need explicit sign-off from usability topic maintainers.
Go for it.
How far should we go here?
Good question.
- To reduce the confusion, turning (123) into (ID:123) would already be a useful tweak.
- Forcing to show it in case of duplicates seems like the right thing to do. Adding the "id: " bit would also address the concerns in #60, no?
- The UI in #52 look very reasonable to me. Since this issue was always about hiding that confusing ID it would probably have to be unchecked by default :)
- Could the code in #52 be made such that it *supports* contrib in doing the fun things outlined in #62?
This is ok to add, but minor indeed. No need for an explicit usability review & signoff. Go for it!
Well yes, lets at the very least not add empty table columns :)
I'm wondering about the relative impact of this change. Did we find a little gap between a code comment that indicates a non existing UI, or is Actions module really in need of/would greatly benefit from categorizing individual actions? Also, "categories" is not really used elsewhere in core is it?
If it's only a code comment that hints at something we don't really miss, than the cheaper fix might be to rewrite that comment?
This is a complex topic and screen :) Before considering the proposed solution, it would be good to provide more concrete info on how the current sorting and grouping is causing problems. "Can be confusing" is a bit thin in that regard :)
I'm sure the current state can be improved, but not so confident that this proposal points towards a more managable situation:
- Already the core categories are a mix of "core-core" and additional topic/feature specific groupings (fields, multilingual, migrate...)
- Not all contributed modules add functionality on the same scale and scope. Commers or Groups introduce whole new concepts and would merit their own section, but would a contrib module that provides a new field type really add it's own section at the bottom instead of adding itself in the existing Fields section?
- Not sure how adding the version number helps here?
Main point is that it would be good to get a better grasp on the usability problems here before exploring possible solutions.
It's a pity these nice little usabillitytweaks get stalled. I would say this is fine to continue with. Content types, vocabularies, media types, menus all have their own description field, it's perfectly reasonable and useful to add similar for roles.
What I think I'm reading here:
- A single url/page as the location for presenting "things you might want to create" would provide a good "UI-infra" basis to build from.
- On which items to get there and how to get them there: [2377543-96], I like the thinking in the last paragraph:
we could just consider a hook and let other modules add their own sections here "by hand", might not even need to be content entities, could be anything sites consider to be things their editors typically add.
. This sounds like a nice approach that leaves things open for contrib to experiment with, which would be a plus I think. Leaving it to the architectural experts to come up with the right technical implementation for this :)
- The mockup in [2377543-94] would already be a good ux improvement as is. I'm thinking about additional features to star/promote items so that they show up as a select list under the "add" in the toolbar etc. But we would still want to introduce this basic page first. Lets focus on that.
Webchick! Thank you so much for your inspired and inspiring way of being and doing all the Drupal things. Such wit and energy!
Take care, much love, Roy.
quietone → credited yoroy → .
I would suggest to look at https://www.drupal.org/project/ideas/issues/3170260 → which outlines a smaller initiative around decoupled menus. https://drupal.slack.com/archives/C016N3HTHRD is the slack channel if you want to tune in.
Would love to test the patch that implements the above suggestion :)
subscribe…