Make Field UI description more user-friendly

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.

"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." ?

"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"

I like something along the lines of "Allows fields to be added to content, users, etc. via the UI".

How about this?

+description = User interface that allows fields to be added to content, users, etc.

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 custom fields for content, users, etc.

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.

I like 'custom'.

How about 'manipulate' instead of 'manage'?

Customize fields on content types, users, etc. ?

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

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.

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.' ?

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..."?

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

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!

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.

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

Allows administrators to add and manage custom fields for content and user profiles

What's the etc. ? I don't know, and would love to hear.

The model description for enabling the Views UI is:

Administrative interface to views. Without this module, you cannot create or edit your views.

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.

It occurs to me, that from the user point of view, entities are just parts of a form. So why not something like this:

"Provides an administrative interface for customizing the fields of content, comment and user forms."

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.

bump

I am closing this issue.
Please review this i have added following line. I hope it suits you all.
User interface which allow fields to be added to content, users, comment etc.

Any update on this issue ?

If you are asking for English proof-reading...

> 'User interface which allow fields to be added to content, users, comment etc.'

should be:

> 'User interface which allows fields to be added to content, users, comments, etc.'
(+s +s, +,)

But using a more "active voice" (see doc the writing style guide) could be :

User interface for adding custom data fields to content, users, comments, etc.

..still bikeshedding I guess.

Maybe we can get even more specific, less technical by giving examples of what custom data fields are:

Add specific fields ( for text, images, dates, tags, etc.) to content, users, comments and more.

Adding new patch as suggested by dman.

Looks good to me. Moving to RTBC.

This is unquestionably better than the previous text; however, it will break translatable strings, so moving to 8.1.x instead.

Also seems like we still need to discuss this string a bit more, see yoroy's comment for example. (Also "etc." in general is a bit lazy. :))

@Webchik

Hows it

User interface for adding specific fields like text, image, date, tags to content, users, comments and more.

Can you please suggest ?

Yeah, something like that would probably work, tho it's a bit long. Might want to wait for someone on the UX team to chime in.

I hope i am making sense this time.
Please see attached patch.

I think roy's text here is better.

"Add specific fields (text, images, tags, etc.) to content, users, and more."

Done as suggested by #42

Since this is an 8.1.x issue, it should be explicitly postponed. Thanks!

The field UI module description was updated in Feb 2020 in #2570985: Update the module descriptions on the Extend page.

I think this can be closed as outdated.