Often to achieve composite fields in Views I add a few fields that are "excluded from display" and then add a "Global:Custom Text" field to join the hidden fields together. To keep things neat I usually edit the administrative title of the hidden fields to begin with "[hidden] ". This makes it easy to instantly recognise when a field will not be displayed. I think it would be wonderful if Views automatically did this for me, or alternatively the administrative title could have a reduced opacity in the Views UI. Does anybody else agree?

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

dawehner’s picture

Status: Active » Needs review
FileSize
805 bytes

This sounds like a valid feature request.

In general i'm wondering whether "[hidden]" is the right name for it, or should it be some kind of visual character.

mstrelan’s picture

In general i'm wondering whether "[hidden]" is the right name for it, or should it be some kind of visual character.

Such as a reduced opacity? Or "excluded" would be more consistent than "hidden".

mstrelan’s picture

Also I feel that should we use a string such as [hidden] or [excluded] that prepending is neater than appending, particularly when you have several excluded fields you can immediately see that a whole bunch of fields are excluded. See screenshots, and feel free to disagree.

mstrelan’s picture

Here are some more screenshots. First is with reduced opacity, I don't think I like it, and it could have issues with different themes or with visual impaired users. Second is with a visual indicator stolen from Photoshop. I like this, but it could clutter the interface, particularly for users who rarely use excluded fields. It would be cool though if you could click the icons to toggle visibility.

dawehner’s picture

Personally i believe the hidden text is the easiest to read/understand solution, but there is an issue with the amount of space availible here. It's already breaking in certain cases, but with [hidden] this might even happen more often.

mstrelan’s picture

Would this CSS help with readability when there are line breaks?

text-indent: -2em;
margin-left: 2em;

Personally if I was annoyed by the length of a field title I would edit the administrative title to something shorter.

modulist’s picture

+1

I find myself appending the string (hidden) manually every time I exclude a field from view.

Also, it would be quite helpful to have the existing text for the Administrative Title already in the input text field. This way, a user is actually editing the Administrative Title instead of writing it from scratch. It would also make the field's purpose more obvious to novice users.

tim.plunkett’s picture

Triggering the testbot.

dawehner’s picture

Status: Needs review » Needs work

There was another issue which added some css classes: #1405648: Visually distinguish excluded fields
Maybe this patch could then concentrate to provide usuable css or let's mark it as simple duplicate.

Sorry for not getting this in before, but there are so many different patches it's hard to keep track of them all.

MHLut’s picture

I prepend "(Hidden)" to all my hidden fields, but to do that, I have to repeat the field's name inside the administration name text input. I'd either like the prepending to be automatic, or the ability to give up prefixes and suffixes for the administration title.

tim.plunkett’s picture

Version: 7.x-3.x-dev » 8.x-3.x-dev
Issue tags: +Needs backport to D7, +VDC
xjm’s picture

Project: Views (for Drupal 7) » Drupal core
Version: 8.x-3.x-dev » 8.x-dev
Component: User interface » views_ui.module
Issue tags: +Usability
Bojhan’s picture

That's a bit ugly :x - both options. I would almost consider this a won't fix, if it wasn't a WCAG violation to use color as the only indicator.

damiankloip’s picture

#13, I think we should try to explore options for this. I think this would make a big difference from a UX perspective for views editing.

Any suggestions or ideas on this would be appreciated.

dawehner’s picture

@bojhan
Are there fundamental issues with using [hidden] (or something similar) in front of the fields?

damiankloip’s picture

I think we should try to get some consensus on this issue; This is something that will (imo) improve the UI considerably. Having any implementation of this is better than none at all.

Bojhan’s picture

I am on board with placing this after the label, I don't think we want to place it in front of labels nor we want to use icons/fadingout. Placing it after the label is more suitable, because when you don't have [hidden] fields below each other its going to create a lot of misalignment, making it hard to scan -- by placing it after, you don't run into any of these issues, it might be a little harder to spot the [hidden], but given that its a rather small usecase I imagine that's oke.

damiankloip’s picture

Status: Needs work » Needs review
FileSize
1.02 KB

Here is a new patch, needed to be re rolled anyway, but as we are appending to the link text, we can add this to the link text when we add the hidden css class to the link too?

damiankloip’s picture

FileSize
5.35 KB

So at the moment, it looks like this.

@Bojhan, if we have a text indicator, can we also have a colour indicator too? Just a slightly different blue or something?! Anything really :)

damiankloip’s picture

Title: Prepend [hidden] to administrative title of excluded fields » Append [hidden] to administrative title of excluded fields
Bojhan’s picture

I am not very excited about adding color, this is already a cockpit UI. Adding different colors to it, will make it even more so. This usecase seems small enough, that people will go the extra mile to spot the [hidden] text.

damiankloip’s picture

ok, I don't really mind. Not enough to fight for it anyway.

The use case is not as small as you think though, I would say ALOT of people use hidden fields. They are used all the time in areas and in rewritten output of other fields etc...

Bojhan’s picture

Thanks :)

It would be worthwhile to do an inventory of which functionality people use in Views, with that we can give it accurate attention in our efforts to optimize the UX. Because with a user base as Views (Core now) you will find that almost everything has a large number of users (even 10% is like 60.000 people), and that you can quickly get biased by polling those primarily in the issue queues/irc.

damiankloip’s picture

hehe, I'm not sure why you think I only base this on the issue queue and people I know in the drupal community all the time :) We do need to stick up for those people though...

I get this a lot with clients and colleagues I work with who aren't in the community. I would say more like 50% of views users will use this functionality at some point.

dawehner’s picture

I don't see a proper way to find out which functionality is used by which percentage of the users, but believe me, hidden fields + rewrite is used by A LOT OF people, this is basically the first thing you use after getting beyond the "simpleviews" usage.

From my experience in the issue queues everything is used by a lot of people :)

mstrelan’s picture

I am not very excited about adding color, this is already a cockpit UI.

Not sure what's the big deal about slightly reducing the opacity of the text, eg http://drupal.org/files/issues/views-hidden-opacity.png but with [hidden] as well. You mentioned it's a cockpit UI, but if novice users are unlikely to hide fields they won't be confused by different colors, and users who do hide fields would instantly appreciate the visual indication of the hidden fields.

I don't think we want to place it in front of labels nor we want to use icons/fadingout.

What specifically is wrong with icons? Icons would be great if they could be used as a toggle to show/hide a field.

All I'm saying is I think all approaches so far are valid and we shouldn't disregard them based on "we don't want this".

tim.plunkett’s picture

Opacity would almost certainly violate WCAG color contrast.
Someone would have to come up with an icon first, and we'd have to test it. That's still an option, but it would take someone to volunteer to do that.

Bojhan’s picture

I think just appending will be fine, I am OK with anyone RTBC'n the current patch.

@msterlan There are many reasons why fading out doesn't work - 1) it has serious accessibility issues, as it decreases the currently optimized contrast 2) it is a one off, we don't do it anywhere else in core, 3) it creates a visual imbalance, using different tones of blue rather than one draws a lot of focus to the one just "off". Icons are great when universally understood, sadly that only applies to a few, sadly similar to fading out icons draws a lot of attention, they are non-standard and would require rigorous usability testing to determine whether it communicates the value we want to communicate (I have tested a lot of icons, and users rarely straight out get them - finding a perfect icon for this, and testing it - is not a 1. priority of the UX-Team).

I am sorry for not expanding on it, but I am involved with many many issues - especially for smaller issues, I do not always see the need to expand on it. It often turns into long discussions where I end up explaining many visual design concepts, which is fine - but I hope you understand - very time intensive. In this case its a small detail, we are working on so - if you still disagree, we can always discuss further, but please understand we have about 3 designers on 800 programmers :)

dawehner’s picture

Let's add some tests and get this done.

dawehner’s picture

FileSize
2.51 KB

Rerolled the patch.

tim.plunkett’s picture

Status: Needs review » Reviewed & tested by the community

This was already given a usability review, and its good to go if it comes back green!

catch’s picture

Category: feature » task
Status: Reviewed & tested by the community » Needs work

The idea is good but the square brackets should not be in the translatable text, or they could be normal parenthesis instead.

Also this might break a bit in RTL language - it may be better to change the entire string for more context.

dawehner’s picture

Status: Needs work » Needs review
FileSize
2.53 KB
2.06 KB
damiankloip’s picture

FileSize
2.5 KB

Rerolled.

Status: Needs review » Needs work
Issue tags: -Usability, -Needs backport to D7, -VDC

The last submitted patch, 1278456-34.patch, failed testing.

dawehner’s picture

Status: Needs work » Needs review
Issue tags: +Usability, +Needs backport to D7, +VDC

#34: 1278456-34.patch queued for re-testing.

attiks’s picture

+++ b/core/modules/views/lib/Drupal/views/Tests/UI/FieldUITest.phpundefined
@@ -0,0 +1,48 @@
+  public static $testViews = array('test_view');

variable is not used

+++ b/core/modules/views/lib/Drupal/views/Tests/UI/FieldUITest.phpundefined
@@ -0,0 +1,48 @@
+      'group' => 'Views UI'

trailing comma?

+++ b/core/modules/views/lib/Drupal/views/Tests/UI/FieldUITest.phpundefined
@@ -0,0 +1,48 @@
+    $this->drupalGet('admin/structure/views/view/test_view/edit');
...
+    $edit_handler_url = "admin/structure/views/nojs/config-item/test_view/default/field/name";

variable should be used here

Status: Needs review » Needs work
Issue tags: -Usability, -Needs backport to D7, -VDC

The last submitted patch, 1278456-34.patch, failed testing.

attiks’s picture

Status: Needs work » Needs review

#34: 1278456-34.patch queued for re-testing.

Status: Needs review » Needs work
Issue tags: +Usability, +Needs backport to D7, +VDC

The last submitted patch, 1278456-34.patch, failed testing.

damiankloip’s picture

Status: Needs work » Needs review
FileSize
1.07 KB
2.5 KB

Thanks for reviewing.

1. This variable is used, in most views tests. See \Drupal\views\Tests\ViewTestData::importTestViews().
2. Fixed.
3. I don't see any point in using a variable in this string. We don't really gain and the test is only ever going to use our test_view view.

Status: Needs review » Needs work
Issue tags: -Usability, -Needs backport to D7, -VDC

The last submitted patch, 1278456-41.patch, failed testing.

attiks’s picture

Status: Needs work » Needs review
Issue tags: +Usability, +Needs backport to D7, +VDC

#41: 1278456-41.patch queued for re-testing.

attiks’s picture

#41 replacing with the variable will make it easier the change the view used for testing, but it's not a real deal breaker.

Status: Needs review » Needs work
Issue tags: -Usability, -Needs backport to D7, -VDC

The last submitted patch, 1278456-41.patch, failed testing.

dawehner’s picture

Status: Needs work » Needs review

#41: 1278456-41.patch queued for re-testing.

Status: Needs review » Needs work
Issue tags: +Usability, +Needs backport to D7, +VDC

The last submitted patch, 1278456-41.patch, failed testing.

damiankloip’s picture

Status: Needs work » Needs review
FileSize
2.51 KB

Rerolled after views_ui test move.

dawehner’s picture

Issue tags: +Needs screenshots

Added a task to add a screenshot: http://drupalofficehours.org/task/2266

damiankloip’s picture

Steps for screenshot:

- Apply patch
- Go to field handler settings on a view
- Check the exclude form display checbox and save.
- See '[hidden]' appended to the field link on the edit page

shanly’s picture

Status: Needs review » Needs work
FileSize
121.9 KB

The "[hidden]" text should be at the beginning of the field for quick identification and visual distinction.

Also, we're using parentheses on other fields so that may be better than square brackets. We may want to be consistent.

damiankloip’s picture

Status: Needs work » Needs review

Thanks for the screen grab.

@shanly, please read the rest of the issue thread. The choice of brackets and the placement has been discussed.

shanly’s picture

Status: Needs review » Reviewed & tested by the community

Whoops, sorry about that!

catch’s picture

Status: Reviewed & tested by the community » Fixed

Not entirely sure about this but it's useful even if still a bit ugly. Committed/pushed to 8.x, thanks!

Automatically closed -- issue fixed for 2 weeks with no activity.

stBorchert’s picture

Issue summary: View changes
FileSize
18.46 KB

I know its very late to comment on this issue, but we are using this style for excluded/hidden fields in the Views UI:

Maybe its worth a reroll?

PS: the text "(Excluded)" in the screenshot is an left-over from previous attempts to mark excluded fields. We now stick to text-decoration: line-through; and a different color.