Posted by Bojhan on November 4, 2012 at 8:03pm
12 followers
| Project: | Drupal core |
| Version: | 8.x-dev |
| Component: | views_ui.module |
| Category: | bug report |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | closed (fixed) |
| Issue tags: | BADCamp2012UX, Needs followup, Usability, VDC |
Issue Summary
Problem/Motivation
During testing we found a problem when people clicked the "view page link".
‘View page’ link goes to the home if the path isn't set, causing confusion because people think that is what they created when in fact its not.
Proposed resolution
This is an interesting challenge, because we basically create a link that instead of helping people picture what its about. I don't necessarily want to create a solution where we provide a disabled button just to inform the user, because disabled buttons make people go crazy.
Instead I propose we only show it when a path is filled out and its saved. For the wizard workflow this is easy, for the non-wizard workflow it might be a little trickier.
User interface changes
Remove view title when there is no path set.
| Attachment | Size | Status | Test result | Operations |
|---|---|---|---|---|
| view-ui-view-page.png | 16.44 KB | Ignored: Check issue status. | None | None |
Comments
#1
It doesn't really make sense to disable the button, because the dropbutton exposed other options,
so what about just hiding this part?
#2
I don't think the links should be gray? they should remain blue?
#3
I am slightly concerned that the Views pros will click 'clone page' out of habit and become annoyed. Could you replace 'view page' on unsaved views with 'save and view page'.
I agree that the links should remain blue.
#4
No idea, but this seems to be another bug and not related to this issue, sorry, i guess #1826574: Move Views theme-specific CSS to their respective themes caused that.
#5
Yeah, also I think some other css was removed from core recently. I'm not sure it's anything we have done in views.
I'm not sure about the 'save and view page' as you don't really have to save the view when leaving the page.
How about we change the order to be more logical? So the order (for enabled) is disable, clone, delete. To me this makes the most sense operationally. I have also added a check to see if the view is enabled before showing the 'view page' link, as there is no point in having this if a view is not enabled.
#6
Sorry, amend to the above, I get it now, We mean before the view has ever been saved! That's not a bad point..
#7
Sounds good to me too.
#8
+++ b/core/modules/views/views_ui/lib/Drupal/views_ui/ViewEditFormController.phpundefined@@ -378,9 +378,9 @@ public function getDisplayDetails($view, $display) {
+ elseif ($view->isEnabled() && $view->get('executable')->displayHandlers[$display['id']]->hasPath()) {
This is a good point!
+++ b/core/modules/views/views_ui/lib/Drupal/views_ui/ViewEditFormController.phpundefined@@ -391,6 +391,16 @@ public function getDisplayDetails($view, $display) {
+ if ($is_enabled) {
+ $build['top']['actions']['disable'] = array(
From a user perspective it seems to be for me that cloning or deleting a display is used way more often then disabling a display. You either want to have a display or get rid of it.
This patch also hides the link as long the view is not saved yet.
#9
Can you post a screenshot?
#10
Patch in #8 seems good to me.
#11
I've applied this patch and I think having 'clone' as the default is better, although if they're moving fast, they'll create a clone (or 2) of their page without meaning to.
@ damienkloip, in comment #6 are you saying that the suggestion for the link to be 'save and view page' when the view hasn't been saved is a good one? I don't know what it would take to achieve this, but I'd be interested in testing it out.
#12
We can remove the check if the view is saved or not since views are all saved when they are created now (#1848836: Change Views Wizard's primary button to 'Save and edit' and remove 'Save & exit' button).
#13
Awesome!
#14
Screenshot please. :)
#15
Add novice tag to make a screenshot.
#16
#12: 1831696-12.patch queued for re-testing.
#17
View does not apply to latest pull of 8.x. Requeued for testing to confirm problem.
#18
The last submitted patch, 1831696-12.patch, failed testing.
#19
Rerole against.
#20
Attempt to create screen shot but following error after applying patch when clicking save & edit.
Fatal error: Cannot use object of type Drupal\views\DisplayBag as array in /Users/jimhollcraft/Documents/IdeaProjects/drupal8/core/modules/views/views_ui/lib/Drupal/views_ui/ViewEditFormController.php on line 388.
After removing patch, this error does not occur.
#21
#22
Good observation!
#23
Right you are, this displayHandlers have changed.
#24
Damian's version is a bit better, so let's RTBC it (as always it should be green).
#25
Worth having a test for?
#26
Yeah why not.
#27
#28
This works, but testing it, I noticed something odd with the link styling. (This also occurs in HEAD, so not related to this patch.)
Path is saved:
Path is not saved:
Why are they different colors? Bad a:visited styling? Folllowup?
We should also file a followup to sentence-case these operations (and those in the dropbutton for the view).
#29
#30
I'm reasonably sure that those aren't links. They're buttons. Must have lost some CSS somewhere.
#31
Over in #1965910: Remove enable/disable entity operations Xano is calling them links.
#32
The enable/disable links for the View config entity are links.
Since these are part of the ViewEditFormController, these are for the *display* and are submit buttons.
#33
Committed 763caef and pushed to 8.x. Thanks
#34
Automatically closed -- issue fixed for 2 weeks with no activity.