Provide consistency to the way field UI is presented
| Project: | Drupal |
| Version: | 7.x-dev |
| Component: | field_ui.module |
| Category: | task |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | closed |
| Issue tags: | Needs usability review, Usability |
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.
#1
Well, 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.
#2
#3
Taxonomy 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.
#4
.
#5
See #3
#6
The last submitted patch failed testing.
#7
I'm glad this is covered by tests.
#8
#9
List?
We don't do that elsewhere?
TRUE!
#10
I 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
#11
I 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.
#12
Automatically closed -- issue fixed for 2 weeks with no activity.