Problem/Motivation

Text in the Views interface doesn't follow suggestions and guidelines documented in User interface guidelines: Interface text. Most of this originates from the desire to have descriptions for everything. Ideally there is only a description where its truly needed. I suggest at large we evaluate this help text.

This text can be found when you for example "Add fields", "Add contextual filters". "Relationships". Its the text in those UI's we are trying to solve.

  • Display all taxonomy terms associated with a node from specified vocabularies.
  • The date the content was posted.
  • Appears in: node:article, node:recipe. Also known as: Content: Image, Content: Picture of recipe.
  • Date and time of when the last comment was posted.

Proposed resolution

Evaluate and write new descriptions for all of this, we should quickly analyze what trends are going wrong. For example:

  • Post date:The date the content was posted. -> Remove description
  • Appears in: node:article, node:recipe. Also known as: Content: Image, Content: Picture of recipe. -> Appears in content types Recipe and Article.

At large it should remain within 140 characters a rule of thumb we use for most descriptions to make sure people read them and in this case also to make sure the table doesn't wrap.

Remaining tasks

This issue needs to be split off in achievable novice tasks. For example evaluating per category.

Files: 
CommentFileSizeAuthor
#32 shorten_help_text-1832858-31.patch8.73 KBdajjen
PASSED: [[SimpleTest]]: [PHP 5.4 MySQL] 91,379 pass(es). View
#30 shorten_help_text-1832858-30.patch9.57 KBdajjen
FAILED: [[SimpleTest]]: [PHP 5.4 MySQL] 91,532 pass(es), 3 fail(s), and 0 exception(s). View
#29 shorten_help_text-1832858-29.patch9.55 KBdajjen
PASSED: [[SimpleTest]]: [PHP 5.4 MySQL] 91,437 pass(es). View
#26 shorten_help_text-1832858-23.patch7.88 KBdajjen
FAILED: [[SimpleTest]]: [PHP 5.4 MySQL] 91,406 pass(es), 0 fail(s), and 24 exception(s). View
#21 rerollworked-21.patch7.8 KBnuwe
FAILED: [[SimpleTest]]: [PHP 5.4 MySQL] 89,197 pass(es), 0 fail(s), and 24 exception(s). View
#20 shorten_help_text-1832858-20.patch7.77 KBsidharrell
PASSED: [[SimpleTest]]: [PHP 5.4 MySQL] 84,459 pass(es). View
#12 1832858_00.patch712 bytesXano
PASSED: [[SimpleTest]]: [MySQL] 50,516 pass(es). View
#4 revamp-descriptions-1832858-4.patch2.61 KBeddie_c
FAILED: [[SimpleTest]]: [MySQL] 48,494 pass(es), 4 fail(s), and 0 exception(s). View

Comments

Bojhan’s picture

Title: Revamp descriptions of handlers » Revamp descriptions of items in handler listings
yoroy’s picture

Here's a first go at a couple of these descriptions for the 'Add fields' listing to give an idea of what we're aiming to do here:

---

## Current:

Content: Add comment link
Display the standard add comment link used on regular nodes, which will only display if the viewing user has access to add a comment.

Content: All taxonomy terms
Display all taxonomy terms associated with a node from specified vocabularies.

Content: Author uid
The user authoring the content. If you need more fields than the uid add the content: author relationship

Content: Body
Appears in: node:page, node:article.

Content: Comment count
The number of comments a node has.

Content: Comment status
Whether comments are enabled or disabled on the node.

---

## Rewrite

Add comment link
Display the standard add comment link used on content.

All taxonomy terms
Display all terms assigned to a piece of content.

Author uid
The user authoring the content.

Body
Used in the Page, X, Y and Article content types.

Comment count
The number of comments to a piece of content.

Comment status
Whether comments are enabled or disabled.

dawehner’s picture

Issue tags: +Novice

Patching these in seems to be a good novice task.

eddie_c’s picture

FileSize
2.61 KB
FAILED: [[SimpleTest]]: [MySQL] 48,494 pass(es), 4 fail(s), and 0 exception(s). View

I'd be happy to have a go at this. I have a few questions though:

@yoroy Do you really mean that it's better to leave the word denoting the filter category off the item name, e.g. "Content: "? It seems to me that we need that to distinguish between items with the same name in different categories, right? E.g. "Content: Title" and "Content revision: Title".

Also, for the Body item description - "Used in the Page, X, Y and Article content types." - do you suggest including a list of every content type that has a body? I know it does that at the moment but may be far too verbose with a lot of content types?

@Bojhan Would you suggest creating subtasks for this? Split by category - Content, Content Revision, Comment, Global etc?

I've included a patch with yoroy's suggestions - more to check that I've understood correctly than because I think it contains enough to be useful at the moment.

Thanks all!

eddie_c’s picture

Ah - it looks as though listing every content type a field appears on is well established functionality, so I guess that answers my question regarding the Body item description.

dawehner’s picture

+++ b/core/modules/comment/comment.views.incundefined
@@ -525,7 +525,7 @@ function comment_views_data_alter(&$data) {
-      'help' => t('Display the standard add comment link used on regular nodes, which will only display if the viewing user has access to add a comment.'),

Oh yes, noone cares about that detail.

+++ b/core/modules/node/node.views.incundefined
@@ -384,7 +384,7 @@ function node_views_data() {
-    'help' => t('The user authoring the content. If you need more fields than the uid add the content: author relationship'),

The question is why this information is not helpful for the user? Many people struggle with that, so why not give them a hint here.

+++ b/core/modules/taxonomy/taxonomy.views.incundefined
@@ -372,7 +372,7 @@ function taxonomy_views_data_alter(&$data) {
+      'help' => t('Display all terms assigned to a piece of content.'),

Great improvement!

lisarex’s picture

Thanks eddie_c! Patch looks good to me so far.

As for splitting, Content is by far the biggest category, and since this is such a simple patch it might be easier to keep it as one issue for now?

Per #1832862: Make views add field scannable proposes to split category into it's own column (yay) hence why yoroy wrote the item names without the category in front.

lisarex’s picture

'The user authoring the content. If you need more fields than the uid add the content: author relationship'

How about something like 'The user that wrote the content. 'author relationship' provides additional fields'

dawehner’s picture

That's fine for me!

Bojhan’s picture

@eddie_c Yes, we need to split this up. Lets focus this one on "content". @lisarex Its simple/small now, but I assume if we start to fix more it will become quite large to review.

Xano’s picture

The first technical hurdle is probably to make descriptions optional in the first place. Views now sets a default "this item has no description lalalalaa" description for every handler in views_fetch_fields().

Xano’s picture

Status: Active » Needs review
FileSize
712 bytes
PASSED: [[SimpleTest]]: [MySQL] 50,516 pass(es). View

The attached patch prevents the default Error: missing help message from being shown as handler help.

dawehner’s picture

#12: 1832858_00.patch queued for re-testing.

dawehner’s picture

Issue tags: +Needs tests

But then we probably need some testing.

dawehner’s picture

Would be cool to have #1962234: [Change notice] Move views_fetch_fields into an autoloadable class in first, as it touches exactly the same code. Once it's ported writing tests would be potentially better to do.

Bojhan’s picture

Does it need to be? that issue has been stalled for a while.

dawehner’s picture

Well, bring people to the other issue, but this issue also just have a really old patch, which will not apply at all,
need tests, for some reasons etc. Well, let's work on both at the same time.

jibran’s picture

Status: Needs review » Needs work

NW as per #14.

jibran’s picture

Issue summary: View changes

add link to related parent issue

klonos’s picture

Issue summary: View changes
Parent issue: » #1832862: Make views add field scannable

...parent issues now have a dedicated metadata section ;)

sidharrell’s picture

Status: Needs work » Needs review
FileSize
7.77 KB
PASSED: [[SimpleTest]]: [PHP 5.4 MySQL] 84,459 pass(es). View

I went through the add field ui. I was hesitant to change some of the ones that were defined as descriptions instead of help, cause that text may show up somewhere else.
Note that removing descriptions may no longer be necessary, because of the table layout introduced in the parent issue. That may make it even more necessary to have short help text, to fit into a smaller space in the table column.
Didn't go through the remaining UI screens other than Add Field. Felt like I should get some feedback before investing more time into this.

nuwe’s picture

FileSize
7.8 KB
FAILED: [[SimpleTest]]: [PHP 5.4 MySQL] 89,197 pass(es), 0 fail(s), and 24 exception(s). View

i have rerolled the patch in #20 it was an automerge

Status: Needs review » Needs work

The last submitted patch, 21: rerollworked-21.patch, failed testing.

Status: Needs work » Needs review

rpayanm queued 21: rerollworked-21.patch for re-testing.

Status: Needs review » Needs work

The last submitted patch, 21: rerollworked-21.patch, failed testing.

dajjen’s picture

working on this on drupaldevdays

dajjen’s picture

Status: Needs work » Needs review
FileSize
7.88 KB
FAILED: [[SimpleTest]]: [PHP 5.4 MySQL] 91,406 pass(es), 0 fail(s), and 24 exception(s). View

I rerolled the patch from #21

Status: Needs review » Needs work

The last submitted patch, 26: shorten_help_text-1832858-23.patch, failed testing.

dajjen’s picture

Issue tags: +drupaldevdays
dajjen’s picture

Status: Needs work » Needs review
FileSize
9.55 KB
PASSED: [[SimpleTest]]: [PHP 5.4 MySQL] 91,437 pass(es). View

Made a new patch that also check if there is any description before trying to add it to the description field.

dajjen’s picture

FileSize
9.57 KB
FAILED: [[SimpleTest]]: [PHP 5.4 MySQL] 91,532 pass(es), 3 fail(s), and 0 exception(s). View

Re-roll patch from #29

Status: Needs review » Needs work

The last submitted patch, 30: shorten_help_text-1832858-30.patch, failed testing.

dajjen’s picture

Status: Needs work » Needs review
FileSize
8.73 KB
PASSED: [[SimpleTest]]: [PHP 5.4 MySQL] 91,379 pass(es). View

Another reroll

no_angel’s picture

Issue tags: -BADCamp2012UX

queued for re-testing

no_angel’s picture

Would be cool to have #1962234: [Change notice] Move views_fetch_fields into an autoloadable class in first, as it touches exactly the same code. Once it's ported writing tests would be potentially better to do.

Issue 1962234 Committed b15e921 and pushed to 8.x. But is Active: pending change record

Does this impact how the patch 1832858-31.patchis re-rolled??

Version: 8.0.x-dev » 8.1.x-dev

Drupal 8.0.6 was released on April 6 and is the final bugfix release for the Drupal 8.0.x series. Drupal 8.0.x will not receive any further development aside from security fixes. Drupal 8.1.0-rc1 is now available and sites should prepare to update to 8.1.0.

Bug reports should be targeted against the 8.1.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.2.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

yoroy’s picture

Version: 8.1.x-dev » 8.2.x-dev
Issue tags: +ux-interfacetext

Version: 8.2.x-dev » 8.3.x-dev

Drupal 8.2.0-beta1 was released on August 3, 2016, which means new developments and disruptive changes should now be targeted against the 8.3.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.3.x-dev » 8.4.x-dev

Drupal 8.3.0-alpha1 will be released the week of January 30, 2017, which means new developments and disruptive changes should now be targeted against the 8.4.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.