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?
Comment | File | Size | Author |
---|---|---|---|
#56 | 1278456.55.png | 18.46 KB | stBorchert |
#51 | Screenshot from 2013-05-24 19:13:46.png | 121.9 KB | shanly |
#48 | 1278456-48.patch | 2.51 KB | damiankloip |
#41 | 1278456-41.patch | 2.5 KB | damiankloip |
#41 | interdiff-1278456-41.txt | 1.07 KB | damiankloip |
Comments
Comment #1
dawehnerThis 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.
Comment #2
mstrelan CreditAttribution: mstrelan commentedSuch as a reduced opacity? Or "excluded" would be more consistent than "hidden".
Comment #3
mstrelan CreditAttribution: mstrelan commentedAlso 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.
Comment #4
mstrelan CreditAttribution: mstrelan commentedHere 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.
Comment #5
dawehnerPersonally 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.
Comment #6
mstrelan CreditAttribution: mstrelan commentedWould this CSS help with readability when there are line breaks?
Personally if I was annoyed by the length of a field title I would edit the administrative title to something shorter.
Comment #7
modulist CreditAttribution: modulist commented+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.
Comment #8
tim.plunkettTriggering the testbot.
Comment #9
dawehnerThere 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.
Comment #10
MHLut CreditAttribution: MHLut commentedI 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.
Comment #11
tim.plunkettComment #12
xjmComment #13
Bojhan CreditAttribution: Bojhan commentedThat'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.
Comment #14
damiankloip CreditAttribution: damiankloip commented#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.
Comment #15
dawehner@bojhan
Are there fundamental issues with using [hidden] (or something similar) in front of the fields?
Comment #16
damiankloip CreditAttribution: damiankloip commentedI 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.
Comment #17
Bojhan CreditAttribution: Bojhan commentedI 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.
Comment #18
damiankloip CreditAttribution: damiankloip commentedHere 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?
Comment #19
damiankloip CreditAttribution: damiankloip commentedSo 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 :)
Comment #20
damiankloip CreditAttribution: damiankloip commentedComment #21
Bojhan CreditAttribution: Bojhan commentedI 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.
Comment #22
damiankloip CreditAttribution: damiankloip commentedok, 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...
Comment #23
Bojhan CreditAttribution: Bojhan commentedThanks :)
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.
Comment #24
damiankloip CreditAttribution: damiankloip commentedhehe, 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.
Comment #25
dawehnerI 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 :)
Comment #26
mstrelan CreditAttribution: mstrelan commentedNot 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.
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".
Comment #27
tim.plunkettOpacity 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.
Comment #28
Bojhan CreditAttribution: Bojhan commentedI 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 :)
Comment #29
dawehnerLet's add some tests and get this done.
Comment #30
dawehnerRerolled the patch.
Comment #31
tim.plunkettThis was already given a usability review, and its good to go if it comes back green!
Comment #32
catchThe 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.
Comment #33
dawehnerComment #34
damiankloip CreditAttribution: damiankloip commentedRerolled.
Comment #36
dawehner#34: 1278456-34.patch queued for re-testing.
Comment #37
attiks CreditAttribution: attiks commentedvariable is not used
trailing comma?
variable should be used here
Comment #39
attiks CreditAttribution: attiks commented#34: 1278456-34.patch queued for re-testing.
Comment #41
damiankloip CreditAttribution: damiankloip commentedThanks 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.
Comment #43
attiks CreditAttribution: attiks commented#41: 1278456-41.patch queued for re-testing.
Comment #44
attiks CreditAttribution: attiks commented#41 replacing with the variable will make it easier the change the view used for testing, but it's not a real deal breaker.
Comment #46
dawehner#41: 1278456-41.patch queued for re-testing.
Comment #48
damiankloip CreditAttribution: damiankloip commentedRerolled after views_ui test move.
Comment #49
dawehnerAdded a task to add a screenshot: http://drupalofficehours.org/task/2266
Comment #50
damiankloip CreditAttribution: damiankloip commentedSteps 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
Comment #51
shanly CreditAttribution: shanly commentedThe "[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.
Comment #52
damiankloip CreditAttribution: damiankloip commentedThanks for the screen grab.
@shanly, please read the rest of the issue thread. The choice of brackets and the placement has been discussed.
Comment #53
shanly CreditAttribution: shanly commentedWhoops, sorry about that!
Comment #54
catchNot entirely sure about this but it's useful even if still a bit ugly. Committed/pushed to 8.x, thanks!
Comment #56
stBorchertI 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.