Posted by Bojhan on November 4, 2012 at 7:22pm
8 followers
| Project: | Drupal core |
| Version: | 8.x-dev |
| Component: | views_ui.module |
| Category: | task |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | needs work |
| Issue tags: | BADCamp2012UX, Novice, Usability, VDC |
Issue Summary
Problem/Motivation
During the testing at BADcamp we noticed all the participant disabling the "Create a label" checkbox. For tables this makes sense, but for most of the other format settings it doesn't make sense.
When adding a field, “Create a label” is checked by default but we observed most people deselecting this. It’s only mostly useful for table display. (P4, P6, P7, P3).
Proposed resolution
We propose that this default is removed, arguably there are cases where a label is the 80% for instance with a table. We might want to do something more smart there, but in all other cases its likely you don't want it.
Remaining tasks
- Remove default setting
User interface changes
The checkbox is not checked by default.
API changes
-
| Attachment | Size | Status | Test result | Operations |
|---|---|---|---|---|
| create-a-label-by-default.png | 7.85 KB | Ignored: Check issue status. | None | None |
Comments
#1
#2
There is currently one way of behavior for checkboxes in views: they all just toggles options in the actual UI.
Let's say when you uncheck the label checkbox and hit save, the actual value of the label internally get's removed (if the user might have entered something before).
When we do now hide the label by default you will never have a proper default value for the label, which would
be probably a problem. It seems to be that we really have to store the actual checkbox as well?
#3
-using solutions as issue title.
#4
This patch enables labels by default for tables, but disables them for all other styles.
#5
Good try to bring the snapshots patch in as part of a UX improvement :)
#6
The last submitted patch, drupal-1831674-2.patch, failed testing.
#7
Some of tests used no label, so let's add them.
#8
#7: drupal-1831674-7.patch queued for re-testing.
#9
While manually testing this, creating a view with table as the style plugin didn't create a label by default. We should add tests for that, and then fix it.
#10
Just to be sure, did you created a view and choosed table in the wizard or did you created
a view and then switched to table? It feels odd that when you switch to table that the lables are switched then.
#11
I tried both, I didn't expect it to change for a built view, but from the wizard it didn't work and I expected it to.
#12
Wait i even remember when i wrote that.
#13
The current patch actually disables the feature for tables, see interdiff :)
#14
The last submitted patch, drupal-1831674-13.patch, failed testing.
#15
#13: drupal-1831674-13.patch queued for re-testing.
#16
The last submitted patch, drupal-1831674-13.patch, failed testing.
#17
#13: drupal-1831674-13.patch queued for re-testing.
#18
The last submitted patch, drupal-1831674-13.patch, failed testing.
#19
The problem seems to be that by initializing the Style Plugin and querying for defaultFieldLabels() you miss the right configuration of the fields handlers, because they actually uses the override method of handlers. It seems to that we might have to find a better way to initialize the groupby handlers but well this is for sure out of scope of this issue.
#20
Is there a better way to do this? Seems like this might create quite an efficiency boost.
#21
Rerolled, let's see how much fails after 4 months.
#22
The last submitted patch, drupal-1831674-21.patch, failed testing.
#23
Could this get another reroll? It would be nice to see this in core.
#24
This looks like something anyone could do.
#25
Going to make this a task, since we are doing this for usability purposes. Its not really a feature.
#26
Okay lets see how this does.
#27
The last submitted patch, drupal-1831674-21-reroll.patch, failed testing.
#28
#26: drupal-1831674-21-reroll.patch queued for re-testing.
#29
The last submitted patch, drupal-1831674-21-reroll.patch, failed testing.