Skip to content
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

Closed
jenlampton opened this issue Sep 10, 2013 · 14 comments
Closed

[UX] Add vertical tabs and permissions to vocabulary edit forms #38

jenlampton opened this issue Sep 10, 2013 · 14 comments

Comments

@jenlampton
Copy link
Member

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.

@ghost
Copy link

ghost commented Oct 29, 2014

Do we want to do the same for user accounts (admin/people/create)? E.g. have tabs for Status, Roles & Notifications?

@quicksketch
Copy link
Member

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 can also have Paths and Menu items

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.

@jenlampton
Copy link
Member Author

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.

Do we want to do the same for user accounts (admin/people/create)? E.g. have tabs for Status, Roles & Notifications?

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'd say the same thing about the menu item form. It's so short it might not be a good fit for 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?

@quicksketch quicksketch modified the milestones: 1.x-future, 1.0.0 Nov 24, 2014
@jenlampton jenlampton changed the title Add vertical tab features consistently on all entity forms [UX] Add vertical tab features consistently on all entity forms Dec 19, 2014
@jenlampton jenlampton changed the title [UX] Add vertical tab features consistently on all entity forms [UX] Add vertical tabs to vocabulary edit forms Jan 15, 2016
@jenlampton
Copy link
Member Author

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.

@jenlampton jenlampton changed the title [UX] Add vertical tabs to vocabulary edit forms [UX] Add vertical tabs and permissions to vocabulary edit forms Jan 15, 2016
@jenlampton jenlampton modified the milestones: 1.3.0, 1.x-future Jan 15, 2016
@jenlampton
Copy link
Member Author

Optimistically changing milestone?

@quicksketch
Copy link
Member

Per the feedback in backdrop/backdrop#1209 (comment), looks like this added permissions to the form but isn't actually saving them. (Thanks @docwilmot)

@jenlampton
Copy link
Member Author

Updated submit handler, and rebased for latest 1.x

@quicksketch
Copy link
Member

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.

@docwilmot
Copy link
Contributor

Saving confirmed working

@jenlampton
Copy link
Member Author

tests on the way!

@jenlampton
Copy link
Member Author

Pushed a new PR with tests (thanks @docwilmot I stole / modified them from the node tests)

@quicksketch
Copy link
Member

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.

@docwilmot
Copy link
Contributor

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.

@quicksketch
Copy link
Member

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. 😄

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants