-
Notifications
You must be signed in to change notification settings - Fork 40
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[UX] Add vertical tabs and permissions to vocabulary edit forms #38
Comments
Do we want to do the same for user accounts (admin/people/create)? E.g. have tabs for Status, Roles & Notifications? |
I'd steer clear of the user account form. There are a number of special cases for user forms that could make that hairy. It's also a form very likely to be modified by end-users already, so I'd say leave it alone in the name of compatibility.
Taxonomy terms are pretty sparse compared to nodes, are these really necessary? I do think the Taxonomy term form looks a bit odd just one item after the other, but vertical tabs might not be the best fit for the need there. Thanks @BWPanda for the PR at backdrop/backdrop#518. I'd say the same thing about the menu item form. It's so short it might not be a good fit for vertical tabs. |
Vertical tabs are a UI pattern that says to the user "Ignore everything in here, these have sensible defaults and should only be changed by people who really need to muck with the details". After we get our Human Interface Guidelines ironed out, this should also become more clear. On all entities, we need a way to visually indicate which things can safely be ignored (path, redirect, etc) instead of just throwing all fields equally onto the edit form. Without vertical tabs (provided by core), contrib has no way to indicate that fields being added are less important than the actual (entity) content.
Status, Roles and Notifications are not things that should be ignored when creating a user, they are quite the opposite. If we follow our HIG then these should be prominent, and only things like Path aliases and Redirects should be in vertical tabs.
I'm also not sure we need vertical tabs on the menu item form. Can someone point to contrib examples where additional less-important fields are added to menu items, and would benefit from being in vertical tabs? |
I just pushed a PR that 1) adds vertical tabs on the vocabulary form and 2) adds the permissions matrix onto the vocabulary form, in that vertical tab set. There is also some work in this PR that should help pave the way for #382 as it will now be easier to add additional permissions per-vocabulary. |
Optimistically changing milestone? |
Per the feedback in backdrop/backdrop#1209 (comment), looks like this added permissions to the form but isn't actually saving them. (Thanks @docwilmot) |
Updated submit handler, and rebased for latest 1.x |
When we added the permissions to the node type form, we added tests as well to check that they worked. We'll need tests here as well, obviously they would have failed if the permissions weren't getting saved from the vocabulary configure page. |
Saving confirmed working |
tests on the way! |
Pushed a new PR with tests (thanks @docwilmot I stole / modified them from the node tests) |
Fixed in backdrop/backdrop#1209. Thanks @jenlampton for putting this together at the last second. And @docwilmot for providing most of the code that we swiped from the Content Type form. 😉 This is the last item on the docket for 1.3.0. |
Woohoo! Well done to @quicksketch and @jenlampton and everyone else. It's been a marathon couple of weeks. Good work. |
I'm very happy with everything that finished for 1.3.0. I'll be making articles and hopefully a screencast this weekend so we can tell everyone all about it. 😄 |
We have design patterns for the node form that should also be extended to other entity forms. For example, taxonomy terms can also have Paths and Menu items, so the same UI to add these things should be present in both places.
The text was updated successfully, but these errors were encountered: