Clean up term form UI

Attached is a patch for this text. I was a little torn on weather to indicate that the inputs did not have any functionality by default, but after spending a while figuring this out myself, it seems like it might be an important piece of information.

changing status to CNR. Also fixed a misspelling in the patch. Correction attached.

Thanks, karschsp!

wow, guys we are trying to decrease the amount of help text not increase it. I have to give this a thorough review, but few people really had trouble understanding the concept, as soon as they actually did it. So I think its save to assume, this issue although exiting might be solved by something else then a lot of help text (changing labels?)

@bojhan What would you recommend for the help text on each of those fields?

Here are my suggestions for the text. The "relationship" information is based on the correct terms for semantic relationships in controlled vocabularies. See more at: http://www.slis.kent.edu/~mzeng/Z3919/4relationship.htm

1. Parents
Relationship: hierarchical. Items will exist below (or within) the parent(s) you select.

2. Related Terms
Relationship: associative. Items will exist alongside the ones you select.

3. Synonyms
Relationship: equivalent. Items entered will behave as if they were identical to one another. Enter one term per line.

I'm not convinced it makes sense to repeat the phrase, "X has/have no core functionality, but may be extended by other modules." I think there is a better place to put this information. What if Parents and Weight were grouped, and "Related Terms" and "Synonyms" were also grouped?

The problem with improving things, is that Drupal does not appear to use the advanced options without third party modules. In the opinion of the UX-2009 Sprint team it would be better to move the advanced settings (without weight perhaps) to a third party (support) module.

Adding tags.

Ignore last patch. We need the text a 3rd party module is necessary only once.

And this patch renames "Advanced options" to "Relationships" as that is basically what it is.

changing d7uxsprint tag

Screenshots before and after the patch #13

before:

after:

This patch removes the Identification fieldset and all redundant element descriptions. It also renames "Related terms" to "Similar terms", to prevent collision with the "Relations" fieldset and because parent terms are also related. #504078: Synonym collapsing in core adds a description to the Synonym textare explaining what it's used for.

Looks good, please fix the patch.

Bump. Xano, still on this?

Before & after.

Nice. I like 'relation's here - since that's what the fieldset has, and if I don't care what relations is, I don't need to open it, whereas you can never tell with 'advanced'.

Yup, agreed - good terminology.

What catch said. RTBC

Rerolled patch from #21

back to rtbc

We might even want to get rid of the "Optionally (...)", because the asterisks indicate required and optional fields anyway. No commit blocker, just nitpicking.

We'll leave it in here. Without it, the sentence reads very 'required'.

Committed to CVS HEAD. Thanks.

The term form is pretty broken still:

Related issue for the position of URL alias textfield: #678590: Path alias link is below submit button on taxonomy term add

This is a bug.

All we need to fix is the location of the url alias? The rest seems to been fixed, the breadcrumb is a larger issue - not meant to be fixed here.

Also, this bug isn't really critical anymore

This form has Field API 'fields'. The order is defined by the admins on admin/structure/taxonomy/%tid/fields.

Reordering doesn't play nice when there are fixed-weight items in the middle of user-reorderable items.
So the consequence for other, non-Field elements in the form is that :

a) Either they declare themselves as 'reorderable' as well, using hook_field_extra_fields(). They just provide a default weight.
That's the case of 'Name' and 'Description' : see taxonomy_field_extra_fields(), and the result on this screenshot.

Should be done only if we see value in letting users tweak their position. Having too much stuff available for reordering only adds confusion for users.
I'm not sure this is the case for 'URL alias' and the 'Relations' fieldset.

b) Or they stick with a fixed position at the bottom of the form, with a reasonably high weight (100+) so that they stay out of the range of weights of the reorderable items
That's what the buttons container does.

Currently, 'url alias' has an implicit fixed weight of 0 (path_form_taxonomy_form_term_alter()), and 'Relations' has a fixed weight of 10. Both are wrong.

I think its perfectly reasonable to let users re-order fields whenever they want. For the URL alias field, see #687994: Add hook_field_extra_fields() implementation to path module

Won't fix it is then?

Won't fix it is then?

Not yet. See my reply in #687994-7: Add hook_field_extra_fields() implementation to path module.

At any rate, "something" needs to be done for 'URL alias' and 'Relations'. Either a) or b) from #37 above.