Posted by Xano on August 26, 2009 at 7:01pm
13 followers
| Project: | Drupal core |
| Version: | 8.x-dev |
| Component: | user interface text |
| Category: | bug report |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | needs work |
| Issue tags: | #d7ux |
Issue Summary
The current description of Field UI is User Interface for the Field API.. Firstly, non-technical users don't know or want to know what an API is. Secondly, even if users know what an API is, where is it? The attached patch changes the description to Allows fields to be added to content, users, etc..
| Attachment | Size | Status | Test result | Operations |
|---|---|---|---|---|
| field_ui_description.patch | 851 bytes | Idle | Passed: 14481 passes, 0 fails, 0 exceptions | View details | Re-test |
Comments
#1
Hm, technically, it's field API that "Allows fields to be added to content, users, etc."
Field UI lets site admins do that in a web interface. But without field_ui, nodes, users, etc. still have fields.
#2
True, but users don't (have to) know that. That's developer stuff. What about Allows users to add fields to content, users, etc.?
On second thought, while this is entirely correct, it might suggest that this feature is meant to be accessible to regular (low-level) users as well.
#3
"But without field_ui, nodes, users, etc. still have fields" - Users do have to know that IMO ;-). Your fields don't go away if you disable field_ui.
Other core modules use "Allows administrators to do X...".
"Allows administrators to add custom fields to content, users, comments, etc." ?
#4
We should be very, very careful with using the word administrator now we have an actual administrator role in core. To prevent confusion we shouldn't use it in contexts that are not about that role.
We need a definition of fields for end users. The difference between fields and fixed data storage is that fields can be added and deleted through an API. Users don't need to know about the API, so what remains is that fields can be added and deleted through the UI. From a user's point of view without Field UI fields are identical to fixed storage.
True, what about using the verb manage?
#5
"Manage fields attached content, users, etc."
"interface for attaching fields to content, users, etc."
"Allows fields to be added to content, users, etc. via the UI"
#6
I like something along the lines of "Allows fields to be added to content, users, etc. via the UI".
#7
How about this?
+description = User interface that allows fields to be added to content, users, etc.#8
The last submitted patch failed testing.
#9
Manage fields for content, users, etc.
No babble about any UI, just short and simple.
#10
I think a clearer distinction needs to be made between the "out of the box" fields and any fields that are added through the Field API. In one sense "Manage fields for content, users, etc." is incorrect - or at least misleading - because it doesn't allow you to manage all fields. How about
Manage is a little bit of a weasel word - it could be more specific - but it's probably better than "Add" as the Field API lets you do more stuff with fields than just add them.
#11
I like 'custom'.
#12
How about 'manipulate' instead of 'manage'?
#13
Users don't know there are non-custom fields.
#14
Customize fields on content types, users, etc. ?
#15
re#10: Field UI does allow you to tweak module-defined, non user-defined fields. The exact extent of what you can change depends on whether the field is 'locked', but you can always at least change order, label, display settings, etc...
#16
OK - then "Manage fields for content, users, etc" kind of gets my vote. It is a little rough around the edges though. "Manage fields" is enough for technical users; "Manage fields for content, users, etc." doesn't really do a good job of explaining what a field is. We need something more than "Manage fields" but I'm not quite sure what.
#17
1. All core modules (er, except toolbar, bug) use a 3rd person verb: Allows X, Adds Y, Enables Z...
With that pattern, we cannot use the verb 'manage':
'(Field UI module) manages fields for content, users, etc' is incorrect, it doesn't manages it for you, it allows you to manage them.
2. users vs administrators - compare:
Menu: Allows administrators to customize the site navigation menu
OpenId: Allows users to log into your site using OpenID
I there's a clear distinction between 'generic users' and 'admin users'.
So why not follow what we have for Menu and go for 'Allows administrators to customize fields for content, users, etc.' ?
#18
Sounds good (and consistent), but isn't there now an administrator role in core? And couldn't this cause confusion if the same word is used with a potentially different meaning? This is problematic with a number of the descriptions. Rather than "Allows administrators to...", what about "Allows users with sufficient privileges to..."?
#19
Just applyed the patch, which went fine (I assume this is unnecessary now that we have the testing sytem, but well, first time I review a patch for core).
About the change, thinking form the end user perspective, I think it would be more explanatory to say something like:
"Provides a user interface for managing fields for content, users, etc.", or "Allows users with the necessary permissions to manage fields through a user interface for content, users, etc."
Just my two cents, I think the current patch is a bit too simple and might confuse end users.
P.S. Valiantly switching the status to needs work :S
#20
All in all, i think we should drop this 'Allows [foo] to..' alltogether. IMHO all these entries should use the Imperative, i.e. Manage, Edit, Customize etc. [bar]. This avoids any possible confusion about administrator rules and such, as users who have the permission will see it, others will not. No need to pick names there!
#21
In a sense the user/administrator distinction is a false one and it's impossible to draw a definite line between the two: users on some sites will be able to do more stuff that users on other sites; administrators on some sites will be able to do less stuff than administrators on other sites.
This means that the description for the Book module, "Allows users to create and organize related content in an outline", is a bit off. It doesn't necessarily allow all users to create and organize relate content.
So, I agree with emPee584. Drop the "allow" bit and go with the imperative: the description for book should be "Create and organize related content in an outline"; the description for field should be "Customize and manage fields in nodes, user profiles etc".
And yes, I prefer "Customize and manage" to either of those two words on their own. Customize implies change and add; manage implies move, hide etc.
The only other thing to consider is whether "nodes" is changed to "pieces of content"; there is a separate discussion regarding whether the word "node" should be changed to "content" at http://drupal.org/node/544320.
#22
Kick.
#23
BUMP.
I just hit this. I knew what I was looking for and still could not believe that "Field UI :User Interface for the Field API." was the way the best bit of our wonderful content management is described.
Very unfriendly, and not at all intuitive - even for me as a developer!
Nicer words, please!
If we are still bikeshedding it ...
What's the etc. ? I don't know, and would love to hear.
#24
That's the point, nobody does. Core has some fieldable entities, but contrib can add more.
#25
The model description for enabling the Views UI is:
Other modules UI descriptions are tautological or redundant. e.g., Imagecache UI is: "ImageCache User Interface"; Notifications UI says: "Provides an UI to notifications"
The Views UI text is a good model. The suggestion is that the views will still be there, you just can't create/edit them without this module. And it doesn't try to explain roles or permissions. And we don't have to worry about the fields on taxonomy terms or fields anywhere else they may pop-up. It's a description of the interface.
Describing what the interface does, in all it's complexity is outside the scope of this description. The user should enable this interface, and in that location the page can describe the functionality of the interface.
Before:
After:
I think if we find a good solution, these changes in reference to 'user interface configuration pages should be changed on modules. It might be something worth adding to User interface best practices to guide other modules.
#26
Let's assume most users won't even know what the field API is, because they're no developers. In this scenario they will also not know fields can still be added programmatically without the field UI. Administrative interface for fields is okay, but still doesn't tell what exactly this module allows you to do. Without this module... only explains what the user cannot do, but not what he can.
I am still positive about suggesting entity types in the description, because that will give a better explanation of what fields are exactly. Something like Administer fields attached to content, users, etc.. Administer basically describes all CRUD operations. Content and users are two entities that will always be available in Drupal 7 and they are simple and concrete. We could also use taxonomy terms for this example, but as many of you will know terms are one of the more abstract and hard to grasp entities. etc. indicates that fields are not limited to content and users. We could replace it by entities like, but then we'd need to find a good replacement for entities, because that will only confuse non-technical users.
#27
It occurs to me, that from the user point of view, entities are just parts of a form. So why not something like this:
If we want to remark the fact that contributed modules can also exploit the Fields UI, we can use "…user and other forms". But I think it's confusing, since it leaves the user wondering what forms we are talking about.
#28
bump