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.Compare:
Content types (3 tabs: edit, manage fields, display fields)
Users (3 tabs: settings, manage fields, display fields)
Taxonomy (5 tabs: edit vocabulary, list terms, add term, manage fields, display fields)
We desperately need some consistency here. I think we should get rid of the "list terms" and "add term" tabs from taxonomy, change "edit vocabulary" to "edit" (I can already see from the title what I'm editing IMO), and make "list" and "add" operations you can only do from the main listing. This would be consistent with content types, which people have been using for years with CCK and no one complaining.
For users, I think we should make "User profiles" its own section and stick manage and display fields tabs there, de-coupling them from settings which really has nothing to do with anything.
| Comment | File | Size | Author |
|---|---|---|---|
| #9 | taxonomy-vocab-tabs.2.png | 18.53 KB | sun |
| #9 | drupal.taxonomy-admin-tabs.9.patch | 12.79 KB | sun |
| #8 | taxonomy-vocab-tabs.png | 18.97 KB | sun |
| #7 | drupal.taxonomy-admin-tabs.7.patch | 12.79 KB | sun |
| #5 | drupal.taxonomy-admin-tabs.patch | 1.9 KB | sun |
Comments
Comment #1
yched CreditAttribution: yched commentedWell, Field UI is not really responsible for the tabs that pre-exist besides its own tabs...
Does "being fieldable" mean "you have to wipe all your UI tabs and move them somewhere else to make room for Field UI's ?"
The question behind this is : 'what's the general pattern for Field UI pages and how do they attach to the various existing UIs for fieldable entities". It's the 1st design issue I outlined in http://groups.drupal.org/node/23545, and I don't think other parts in core or contrib show a similar need.
I personally don't really have more suggestions other than primary tabs.
Note that I *think* a clever use of vertical tabs should let us merge 'Manage Fields' anb 'Display Fields' into one screen.
Comment #2
yched CreditAttribution: yched commentedComment #3
sunTaxonomy works differently. We cannot remove those tabs.
But I agree we can strip down the tab titles.
I'm also horribly annoyed by "list" not being the default tab. The proper order in terms of human logic is:
- list
- edit (vocab)
- manage fields
- display fields
Note that "Add" is now an action, not a task.
Comment #4
sun.
Comment #5
sunSee #3
Comment #7
sunI'm glad this is covered by tests.
Comment #8
sunComment #9
sunList?
We don't do that elsewhere?
TRUE!
Comment #10
Bojhan CreditAttribution: Bojhan commentedI do not have a preference for View nor List, but we do not apply list very consistently in the interface so I assume view is better. I do want to put at end to view vs list mania someday - but probally not this issue.
Eitherway the only real change in this patch is removing, the add term tab which is a good move. I do not think, we should remove list as that is a primary action. So RTBC
Comment #11
webchickI would actually advocate keeping "List" here. Normal "View" pages are just that; the place you go to *view* an object of a given type. You do not also modify its properties in View, and in this case, you are adjusting term weights, and their place in the hierarchy which are edit operations (though of a different type than editing the vocabulary itself). I would expect a "View" link to take me to taxonomy/term/1.
Also, while you can't see it atm because it's broken, the Blocks page is also similar to this where you're re-ordering/configuring on the same page you're looking at the stuff and it is also called "List." (or at least this is so in 6.x.) So there I believe re-using "List" here leads to stronger UI consistency.
Therefore, committed #7 to HEAD.