Problem

Overlay is overly dressed up with various distracting items. It is overused for all admin items.

Proposal

Simplify the overlay for more focused short interactions. See #1882482: [meta] Unify editing approaches in Drupal for the whole stack and other related proposals.

Before patch (note overlay used as a general admin browser, elements like tabs, shortcuts, breadrcumbs, dark background):

After patch (same page never displayed in an overlay, because its not a contextual action):

After patch (sample screen of a form for which this new overlay is designed; no tabs, no breadcrumbs, close button and title inside, lighter background, drop shadow):

CommentFileSizeAuthor
#87 20.modal-dialog.png42.41 KBLewisNyman
#82 core-simpler-overlay-1889150-82.patch6.79 KBnod_
#69 bottom-padding-gap-2.png32.88 KBjessebeach
#69 interdiff_65-to-69.txt411 bytesjessebeach
#69 simpler-overlay-1889150-69.patch12.96 KBjessebeach
#65 simpler-overlay-65.patch12.03 KBGábor Hojtsy
#60 Screenshot_3_8_13_2_50_PM.png146.27 KBGábor Hojtsy
#60 Screenshot_3_8_13_2_48_PM.png116.88 KBGábor Hojtsy
#60 Screenshot_3_8_13_2_49_PM-3.png99.33 KBGábor Hojtsy
#59 simpler-overlay-prototype-59.patch12.39 KBGábor Hojtsy
#58 simpler-overlay-prototype-58.patch12.4 KBGábor Hojtsy
#55 simpler-overlay-prototype-55.patch11.11 KBjessebeach
#55 interdiff_52-to-55.txt2.12 KBjessebeach
#52 simpler-overlay-prototype-52.patch9.65 KBGábor Hojtsy
#52 interdiff.txt417 bytesGábor Hojtsy
#50 OverlayChanges.png73.03 KBGábor Hojtsy
#50 interdiff.txt4.04 KBGábor Hojtsy
#50 simpler-overlay-prototype-50.patch9.61 KBGábor Hojtsy
#37 ContextualDelete.png21.9 KBGábor Hojtsy
#37 NoDeleteButton.png35.72 KBGábor Hojtsy
#37 NoCancel.png21.33 KBGábor Hojtsy
#37 interdiff.txt1.92 KBGábor Hojtsy
#37 simpler-overlay-prototype-37.patch6.43 KBGábor Hojtsy
#32 simpler-overlay-prototype-32.patch5.6 KBGábor Hojtsy
#32 interdiff.txt3.9 KBGábor Hojtsy
#32 ConfigureBlock.png102.16 KBGábor Hojtsy
#32 EditTools-1.png72.01 KBGábor Hojtsy
#25 ViewsPopupSeven.png61.08 KBGábor Hojtsy
#25 ViewsPopupBartik.png53.08 KBGábor Hojtsy
#10 EditMenu 2.png51 KBGábor Hojtsy
#10 simpler-overlay-prototype-10.patch6.81 KBGábor Hojtsy
#9 simpler-overlay-prototype-9.patch6.7 KBGábor Hojtsy
#9 interdiff.txt1.8 KBGábor Hojtsy
#6 interdiff.txt585 bytesGábor Hojtsy
#6 simpler-overlay-prototype-6.patch6.49 KBGábor Hojtsy
simpler-overlay-prototype.patch6.35 KBGábor Hojtsy
SimplerOverlay.png103.55 KBGábor Hojtsy
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

Wim Leers’s picture

That looks very nice!

I particularly like the fact that the tabs are gone. I've always had a blank spot in my eyes/brain whenever tabs appeared on the overlay, I'd never find those. I also like that the breadcrumbs are gone; I've never ever used those in the overlay.

Why are form actions now aligned to the right instead of the left though?

Finally, some esthetic remarks: I think there's a too much whitespace:

  • below the title; I'm not sure what's best here though
  • below the buttons; the whitespace beneath the buttons should be equal to the margin to the left of the form
  • to the right of the buttons; the whitespace to the right of the buttons should be equal to the margin to the left of the form, this already seems to be the case if I look at the "Description" textarea, which makes me suspect the buttons have a right padding that you'd want to override for the last button (button:last in LTR)
David_Rothstein’s picture

I might be missing something, but if you remove the tabs how do you get to them? Type in the URL? :)

Simplify the overlay and/or remove it in favor of using modal dialogs only for more focused interactions.

I've seen this sentiment before and I don't understand it. Modal dialogs are indeed good for very focused interactions (like confirmation forms). But the overlay is about maintaining context while administering your site. For example, you need to edit something, so you click a link to do so, then while editing you realize it's related to another administrative change you need to make, navigate around for a while to find that, etc., and then at the end want to go back to the page on your site you were originally at. This is how people are using it.

One is not a replacement for the other, and they can even be used together. For example, D7 Media module opens up a dialog on top of the overlay when you are uploading a file to in-progress content, and it makes perfect sense to do so.

LewisNyman’s picture

Is the plan here to prevent users from being able to add these pages to shortcuts?

Gábor Hojtsy’s picture

@David, @lewis: indeed, as per the designs posted in #1882482: [meta] Unify editing approaches in Drupal either the overlay would go away entirely or be used only for very focused tasks. Not as an all-purpose admin navigation piece on top of your site, but more like a focused modal dialog that only pops up when needed. Because it was easier to skin the overlay to look like (and behave like) on the mocks, I did a patch for that vs. introducing a solution without the overlay to do in-context administration for blocks, menus, etc. As-is it would lack navigational elements (such as adding to shortcuts or navigate away to somewhere you wanted on the admin interface). Indeed an alternative to reach the goals outlined there is to not use overlay at all and just use modal dialogs.

Wim Leers’s picture

#2 obviously makes good points. I was distracted while posting my remark, which is why I forgot to ask those important questions. Why can we safely get rid of the tabs, the breadcrumbs, and the "add shortcut" icon? The "close" icon is safe to get rid of for non-screenreader users, but for screenreader users, we'd still need an invisible "close" button. Overall; how will the reduced functionality be replaced, or why are they safe to be removed?

I think that's at least partially (though superficially) explained in #1882482: [meta] Unify editing approaches in Drupal. What we need though, is a clear, textual explanation in this issue why we can make the changes proposed.

Gábor Hojtsy’s picture

Updating the *prototype* code to only react with opening overlays if the link came from a contextual menu. This better demonstrates the proposal. I believe @tkoleary is/was working on a fuller explanation already. Yes, as per this prototype, the overlay is not used anymore as an admin navigational feature and only ever used for contextual operations.

tkoleary’s picture

@David Rothstien

"navigate around for a while to find that, etc.,"

Interesting point. People are currently using it that way, yes, and maybe it constitutes a regression to remove that. But let's explore this by asking a few questions.

1. Why are people "realizing it's related to another administrative change they want to make"?

I think the reason for this lies in the fact that we throw up the entire form as well as the navigation. The fact that all of these options are present shifts the users mind from the context of the page they are on to the context of the structure of their entire site.

2. Is this "shift of context" a good or bad thing?

If a user editing a page opens a modal to add a link, sees a link to something else and follows it, we have just succeeded in distracting our user form their primary task. The assumption I am making is that we should not simply present users with a broad and neutral range of options but actively guide users towards the most effective use of their time. I understand that this approach may strike some people as paternalistic but, in reality, every design decision guides the user. The question is not "do we guide the user" but "do we guide the user into a library and ask then to pick a book or do we ask the user what kind of book they want and guide them directly to it".

3. What if I want to make administrative changes to something that presents no contextual link on my page?

Open the menu and navigate to the UI you want to work in. Now you have made an intentional shift of context into the administrative layer.

3. Well what if I go to the admin layer and make changes in several pages then i want to return to the site page I was last on? I can no longer just close the overlay and land back on that page.

True. But is that is the entire purpose of overlay? If so it's a pretty heavy handed approach to solving that user problem. A back arrow in #branding followed by a link to the last visited front end page would do the same thing.

Gábor Hojtsy’s picture

See http://drupal.org/node/1882482#comment-6942376 for a merged patch with many of the other moving pieces to demonstrate the functionality. It is far from complete or final, merely a demonstration of the direction.

Gábor Hojtsy’s picture

Some more appropriate styling to be more admin theme agnostic. Still just a prototype and not meant to be used as-is.

Gábor Hojtsy’s picture

- Made the Cancel button appear on the left of the overlay.
- Made non-primary buttons disappear (such as menu delete, block delete, etc).
- Made action links and operation links keep opening in the overlay. Rest of admin links still not (eg. on custom blocks, the description field's description has such a link to test).

sun’s picture

Erm... Can anyone explain why we need Overlay module for this goal?

The screenshots essentially show how jQuery Dialog looks without any customizations...?

I once wrote a OverlayNG module for D7 that injected jQuery Dialogs for all administrative links... in ~40 lines of code. Including full #ajax support for forms in dialogs and whatnot.

The only reason for why we have that complex monster of Overlay is the original goal of "retaining context" (which I always disagreed with).

Wim Leers’s picture

#11: Nobody says (AFAIK) that we need the overlay. It's just that contextual links currently use the overlay (when overlay.module is enabled, of course), and thus that is the shortest path to demonstrating how we/Kevin envision it could work.

From the issue summary, emphasis mine:

Simplify the overlay and/or remove it in favor of using modal dialogs only for more focused interactions. This patch implements a prototype of the proposed simplified look so it is easier to user test and see a fuller solution stack altogether.

With that in mind — what would your feedback be on the concept? :)

sun’s picture

Well, that boils down and translates to: "Let's remove Overlay and just use Modals/Dialogs."

We're not inventing some new rocket science here, or are we? :)

+1 for getting rid of it.

On the latest screenshot: We can skip the futzing with Cancel buttons. Users are known to search for & click the X in the upper-right corner of dialogs. Dialogs have one. Modals obviously not. :) Ideally the form buttons shouldn't be realigned either; the actual form elements are on the left, so why make the user go from the far left to the far right? ;) In essence, if your form elements are on the right, put the Save button on the right. If they're left, keep the buttons left. (KISS :))

LewisNyman’s picture

@sun

The shifting buttons feel a bit strange but that could be because we are used to a previous layout. It's a pretty common application of Fitts Law to reduce mistakes, you don't want to fill out a form and accidentally hit cancel because you missed the submit button.

Users are known to search for & click the X in the upper-right corner of dialogs.

Let's back this up with some references, I can think of some certain OS users who have never clicked on a top-right close button ;-). I do think it's worth considering leaving it in though depending on how long forms can get, maybe we could call the cancel button out with a strong colour and/or an icon?

Gábor Hojtsy’s picture

@sun: indeed, the point in using the overlay for the prototype was since it was already there, and I don't have your 40 line OverlayNG in hand :D The proposed setup with #1882482: [meta] Unify editing approaches in Drupal that overlay as a general navigational administration page layer would go away. Instead very task focused context sensitive forms would show up in dialogs/modals/popups/whateveryouwanttocallits which are much simpler vs. the overlay with its shortcut support, tabs, breadcrumbs, etc.

Also in reviewing the functionality, Dries/webchick/tkoleary indicated in their review that certain operational navigation should still keep the user in the modal/popup/etc. So if you open the "Edit menu" modal which is combined with #663946: Merge "List links" page into "Edit menu" page contains the list of links in the menu, if you click "edit" or "revert" on a menu item, you would keep being in the modal/popup/etc. Not sure if your 40 line OverlayNG has this kind of navigation capability inside the modal.

Secondly, when using this ugly implementation above, we figured out that responsive tables would naturally work in an iframe context, because they have their own media query context. That might again be too small of a reason to keep an iframe based overlay, but is a worthy point considering.

Finally, I'd not say there is wide agreement even in the Spark team on suggesting to remove the overlay from core. Dries said he believes it was a good addition to Drupal 7. It was admittedly coupled with an admin theme introduced, so it might be hard to separate which one people attributed to their improved user experience.

So I don't think the question of removing the overlay or not is done at all. If we do have overlays and modal popups combined, at least we should work on unifying them as possible/appropriate. Eg. Views modals will not look like ckeditor modals which don't look like the modal look proposed by this patch. That is to some degree a technology question as well as a styling/perception question.

eigentor’s picture

Having a clear distinction between general administrative tasks and quick edits feels like a good idea.
The overlay/modals shine in quick edits. Most criticism of the concept always came from performing longer administrative tasks inside it. And also this introduced the technical burden of that huge iframe/page duplication over another page.

In that I am with tkoleary with just not allowing the user to do that.
The visual distinction of being in the admin section by having the big black frame that is the overlay I always found good, though. But I guess it is possible to keep a clear visual distinction if it is just for that.

This entire issue takes care of the stuff that was meant to be taken care of in the D7 cycle but time did not allow it. Having modals just for quick edits brings the idea to its true meaning. A quick edit can very well be editing a view in the full Views UI, as long as you do not navigate away from it. I bet Tests would reveal people have lost context the moment they do that (navigating away).

Gábor Hojtsy’s picture

Re @sun once again in #11, I think we should come to a decision as to what we want in terms of underlying technology. Some problems include:

- ckeditor, views, media module (contrib), etc. using various popups with different designs, fonts, buttons, icons; not making Drupal have a coherent platform feel
- the unified edit system proposing yet another use for "popups" with small forms for task focused interactions

The unified edit proposal has a distinct design for the popups (see invision prototype in #1882482: [meta] Unify editing approaches in Drupal) with the hope that other popups could adopt it's design and optionally the technology. There is no decision on the technology and this issue is just a prototyping playground for using overlay. Key requirements about the proposal for unified edit's popup/modal:

- NOT serve as a general navigational tool around the admin area (no tabs on top, no breadcrumb, etc)
- BUT allow for certain minimal navigation like if an overview of items is shown (eg. menu), clicking the edit link or another operation should open in the modal
- primarily targeted at small focused interactions (and therefore reusable in terms of looks at least for views popups, ckeditor modals, etc)
- the overall admin-navigational nature of overlay as we know it from Drupal 7 would go away (depending on the technology for the popups, maybe the whole overlay goes away altogether)

For easy fulfilment of the navigational need and the natural media-query friendliness of the iframe based overlay (so eg. tables or layouts displayed in the modal can adjust to the size of the modal vs. the size of the parent page), we prototyped the solution with the overlay. However question is if we should really use technology like the overlay or architect our own client side library to handle these operations via a "simpler" modal. We need more feedback about that given that we really need to go move on this into much more of a practical (vs. theoretical) territory!

@sun, does your 40 line code work for the outlined scenario for this modal/popup?

Bojhan’s picture

@Gabor How can we decide on technology, when the UX principles around this are far from evaluated yet?

Gábor Hojtsy’s picture

@Bojhan: I've been asked to push on figuring out technology in parallel to user testing, since we have like 18 days before feature freeze.

sun’s picture

FWIW, I digged out the code I once wrote out of my archives and pushed it into a sandbox:
Administration Dialog (admin_dialog)

Only quickly tested its base functionality, but didn't touch it otherwise — sorta guaranteed to contain bugs, since I developed it before D7 was released.

jessebeach’s picture

sun, the code in the sandbox from #20, the admin_dialog module. It's essentially just routing the content for an admin form to a jQuery UI Dialog, right?

ksenzee’s picture

Gábor asked me to weigh in here. I don't have much to offer, except that we started out with jQuery Dialog for overlay module, and ended up switching away from it, primarily because of accessibility issues IIRC. That's been some time, and I'm sure jQuery Dialog has evolved since then.

In general, if I were evaluating whether to use an iframe-based solution or not, my main question would be whether you ever need to show a different theme in the dialog or modal. If so, you absolutely need an iframe. If you're sure it'll *always* be the same theme, with no need for conflicting css, then you can probably get away without iframes. It's also worth noting that navigation inside the dialog or modal is one thing iframes are quite good at.

webchick’s picture

Interesting. Yeah, we definitely do want to display these in a different theme than the front-end theme... it should use the theme defined as the admin theme (see #10). That actually makes a fairly reasonable case as to why we might need both Overlay and Dialog API in core, though making them both match visually (since users obviously won't know when they're viewing one vs. the other) will be very hard, I fear. Though I suppose you could also say the pop-up in #10 is just the front-end theme's own styling of dialogs. Hm. Wonder how jarring that would to end-users be if pop-ups from contextual links (front-end theme) looked different from pop-ups from the Views interface, for example.

jQuery UI has indeed done a lot of work on their accessibility in the most recent release, but it's still not released yet AFAIK. But we added a dialog API to core on the expectation that it would be ready by code freeze. Scott Gonzalez hangs out in #drupal-contribute and might be able to provide more details on the jQuery UI roadmap, etc.

Thanks a lot for chiming in, Katherine! :D

webchick’s picture

Issue tags: +Spark

Tagging.

Gábor Hojtsy’s picture

FileSize
53.08 KB
61.08 KB

Made two quick tests with views modals with Seven and Bartik. These are indeed degrading the experience, and Bartik buttons are not that different from Seven buttons, so there are not really that big of a difference. Views popups would only show up above admin pages (unlike contextual links which are supposed to show up above the front end theme).

Views modal on top of Seven:
ViewsPopupSeven.png

Views modal on top of Bartik:
ViewsPopupBartik.png

Gábor Hojtsy’s picture

Given that we want to control the experience of the popup, seems like not using iframes could be challenging.

LewisNyman’s picture

The only other way to to achieve this without an iframe is to use CSS scoping. The support right now is really poor — it's working it's way through the webkit engine but not currently in any browser — but there is a polyfill that would need a bit of work to get it working well with IE and there's also a Modernizr detection script for the feature.

If we're looking at adoption more than a year from now, I'd seriously consider CSS scoping to achieve this without an iframe.

sun’s picture

I don't see why presenting the dialog in the same theme would "degrade" the experience in any way.

If you want themes to ship with and have a dedicated, optional "administrative" look & feel, then we add an .admin class.

The entire theme switching madness is a terrible thing that should simply go away in the first place.

jessebeach’s picture

I agree with ksenzee in #22. Using an iframe bestows on us several benefits over a dialog that lives in the same document as the caller.

  1. It gives us an impermeable-ish layer between the host page and the overlay. This allows us to employ CSS and JS without dealing with conflicts from the host page.
  2. Media queries are fired independent of the host page (As Gábor mentioned in #17)
  3. We can use a theme that isn't the site theme for styling.

Some of the JavaScript APIs in Overlay could be refreshed to allow greater control of the overlay from the host page (acknowledging that they're quite good to begin with!). For instance, there are few knobs to size and offset the overlay.

I wrote a (now somewhat bit-rotted) patch that makes the overlay responsive that we can resurrect: #1829326: Convert Overlay to leverage core breakpoints and media queries to determine its presence and styling.

Plus, the overlay module already exists, it's been tested over years, its more accessible than anything we'd start building from scratch and the code is really clean -- we can refactor it quickly.

eigentor’s picture

Using the same theme for popups is kind of a no-go if the popup is actually taking on the themes styles. Imagine people designing a fancy theme, not thinking about Drupals Admin stuff and ending up with ugly to un-usable Popups. If there is any technique to make this consistent, fine.
Themers should not be forced to think about admin stuff and how their shiny new theme is wrecking it.

I have been struggling with Toolbar and admin menu taking on different font sizes because of the font size of the theme. Also very funny are contextual links that go all bonkers because you accidentally drop in some overconfident CSS. This has always bothered me as looking unprofessional.

What might be done is make the core CSS for this so heavy on selectors a frontend theme normally would not override it, so this might nail the visuals down to what we want them to be. There may be people opposed to this.

So why not an iframe. I guess an iframe itself must not be evil, I guess it is more the full admin area inside it nervewrecked poor ksenzee, davidrothstein and others who put so many hours into it.
But as probably all kinds of problems have been solved by that effort, slimming it down while keeping iframes would not be so bad.
Maybe iframes _are_ evil and the drawbacks should be listed (Performance? other stuff?). Easy use of the admin theme indside it is a big upside for sure.

Gábor Hojtsy’s picture

@sun: themes can already affect the overlay, they can include an admin subtheme if they want to. I'd be surprised if many themes would want to affect admin looks as well, that is why we separated the two :)

Gábor Hojtsy’s picture

Some changes based on design reviews:

- removed feature that overlay closes on click on background
- added back close X instead of Cancel button among form buttons
- fixed shortcuts bar to hide shortcut link even if the page is already among shortcuts

This makes less changes needed in fact to the overall overlay experience. The cancel feature is also necessitated by recent changes in button styles and placement.

Configuring a block:
ConfigureBlock.png

Editing the tools menu:
EditTools-1.png

The patch makes NO changes to the actual forms displayed those would display the same without the patch. The patch only affects the wrapping overlay (width, title display, lack of breadcrumbs, tabs and shortcutting).

Status: Needs review » Needs work
Issue tags: -Spark

The last submitted patch, simpler-overlay-prototype-32.patch, failed testing.

Wim Leers’s picture

Status: Needs work » Needs review
Issue tags: +Spark

#32: simpler-overlay-prototype-32.patch queued for re-testing.

tkoleary’s picture

Status: Needs review » Needs work

@eigentor

What might be done is make the core CSS for this so heavy on selectors a frontend theme normally would not override it, so this might nail the visuals down to what we want them to be. There may be people opposed to this.

I'm not sure why people might be opposed. It sounds sensible to me. We could also specify all font sizes in "admin things" that display in the front ent, in px so that they they dont inherit from a parent in the front-end theme or the front end theme's root em. @jbeach what do you think?

Wim Leers’s picture

Status: Needs work » Needs review

#35 was probably a crosspost; adjusting status.

Gábor Hojtsy’s picture

Updates based on feedback from @koleary and @aspilicious

- Removed "danger" buttons from overlay view because that is not directly tied to in-place editing
- Made block deletion available in the contextual links for consistency with nodes
- Hidden the cancel link on confirmation forms *in the overlay* which looked very odd since we already have the close button
- Made the node edit contextual link actually take over the page and NOT launch a full node edit in the overlay (the overlay is for simple task accomplishments)

New contextual operation on blocks:
ContextualDelete.png

Editing block in overlay:
NoDeleteButton.png

No duplicate cancel on confirm:
NoCancel.png

LewisNyman’s picture

What might be done is make the core CSS for this so heavy on selectors a frontend theme normally would not override it, so this might nail the visuals down to what we want them to be. There may be people opposed to this.

Dangerous, and the mobile initiative is working to ensure the exact opposite in Drupal 8. Core CSS should be easy for themes to override.

Another option is to have an exact clone of Seven's style.css but with something like #overlay prepended to every selected. Using SASS this would be incredibly simple using nested imports.

dasjo’s picture

some pointers to arguments regarding the iframe vs modal css problem so far:
#22, #27 to #30 and #38.

i don't have a clear opinion here, but performance-wise modals just feel a lot better. in terms of css complexity, i think we would need to discuss some real world use cases where conflicts can arise.

@lewisnewman #38, i like the idea of using nested imports, but that should be done carefully to avoid explosion of css file sizes.

catch’s picture

fwiw I don't really think stripping down the overlay should be blocked by feature freeze, seems like more of a code freeze change to me (i.e. removing features rather than adding them :P). I didn't review the patch in detail but as someone who always does drush dis -y overlay after a new install this seems great to me.

dasjo’s picture

i have added a support request to clarify on our strategy for using modals and overlays on mobile:
#1909678: Clarify on the strategy for modals and overlay on mobile

Gábor Hojtsy’s picture

BTW this is included in Spark 8.x-1.x — go to http://simplytest.me/project/spark/8.x-1.x to give it a try with all the other patches (edit toggle, touch friendly contextual links, integrated edit in place, etc). It should make a lot more sense with the other components and make it clear where the overlay is used (only for focused contextual tasks, not for node editing for example) and where it is not used (admin toolbar, browsing admin backend, etc).

Bojhan’s picture

I played a little with the latest spark, honestly I do not get at all where this is going - it seems that we are removing functionality even more randomly now. I think simplified, means more and more - ascetically cleaner, and not so much more usable. I think its sad that the strategy is to continue technical prototyping, eating up contributors time while its clear there is no consensus at all yet on the UX front. I think this in the end will just come down to #13, and I think that is a badly thought through idea.

andypost’s picture

The Modals and Overlay are the same for most end-users.
Tested new D8 Edit module within drupalish people I get that most of all see and name it overlay.

Other points that not taken into account:
- JS injection into modals. For example switching wysiwyg within modal has a lot of issues.
- Is there any clear way to separate links on page is they are for modal/overlay/ajax?

+++ b/core/modules/overlay/overlay-parent.jsundefined
@@ -574,6 +574,15 @@ Drupal.overlay.eventhandlerOverrideLink = function (event) {
+  // Only open links in the overlay if they are contextual links (but not the
+  // node edit link), or if the link is an action link or dropbutton link
+  // that is already in the overlay.
+  if (!($target.parent().parent().hasClass('contextual-links') && !$target.parent().hasClass('node-edit')) && ¶
+      !$target.hasClass('button-action') && ¶
+      !$target.parent().hasClass('dropbutton-action')) {
+    return;
+  }

Ugly hack that does not make sense.
This assumptions does not have solid separation (context)

+++ b/core/modules/overlay/templates/overlay.tpl.phpundefined
@@ -23,14 +23,8 @@
-    <div id="overlay-title-wrapper" class="clearfix">
-      <h1 id="overlay-title"<?php print $title_attributes; ?>><?php print $title; ?></h1>
-    </div>

And we open another box of worms - some pages displayed without titles...

Gábor Hojtsy’s picture

@Bojhan:

I played a little with the latest spark, honestly I do not get at all where this is going - it seems that we are removing functionality even more randomly now. I think simplified, means more and more - ascetically cleaner, and not so much more usable. I think its sad that the strategy is to continue technical prototyping, eating up contributors time while its clear there is no consensus at all yet on the UX front. I think this in the end will just come down to #13, and I think that is a badly thought through idea.

We are attempting to get feedback more concrete than "I think that is a badly thought through idea". Since we did not get there with designs only or through Dries' blog posts, etc. we figured we need a working prototype at least that we can test with people and gather more feedback. We can alternatively sit around and wait for people to come without doing anything to entice them. That did not work before.

I believe your proposal for a different quick edit interaction in #1874664: Introduce toolbar level "Edit" mode that shows all contextual links followed seeing prototypes and experiencing the sea of pencil buttons and other problems, and your proposed design is now implemented there (which lets us figure out how to solve going out of quick editing for example, and just generally see if that works). So as far as I see our approach to work on prototypes and get changes in as possible worked out to make progress.

We are trying to get more concrete critiques and alternate proposals like the one in #1874664: Introduce toolbar level "Edit" mode that shows all contextual links and we are clearly very willing to work towards a solution that works based on these user tests and reviews as far as I see.

Any more concrete feedback that can help us move forward?

@andypost:

The Modals and Overlay are the same for most end-users.
Tested new D8 Edit module within drupalish people I get that most of all see and name it overlay.

I think you are mixing some things up here(?). Edit module is the in-place editing feature that do use a box for fields where real-real in-place editing is not possible. Anyway, the naming is not really important I guess. We keep refering to this feature as the popup/modal/overlay/dialog/whatnot because the name does not really matter, its the simplified and more focused functionality that matters.

Ugly hack that does not make sense.
This assumptions does not have solid separation (context)

Well, in this model, the role of the overlay is ONLY to show up for some of the contextual operations, more precisely for those, which need a short form to accomplish. More elaborate forms (eg. node edit) would show in the full page. So not sure how to separate concerns, if this is the only role of the overlay, then we obviously need to put the logic there. We could theoretically figure out a server side solution where we put classes on links that are eligible, but reality is we don't have the contextual information to do that on the server side most of the time. This JS can be swapped out to attach event handlers to links instead. That was previously found to not be performant due to the number of links possibly affected (especially as more things become blocks and have contextual links). That is why Drupal 7 changed the overlay click handler to work on the document and have the logic within for performance.

And we open another box of worms - some pages displayed without titles...

I'm not sure I'm following. The current Drupal 7 overlay generates the page title *twice* in the output, and then hides the regular page title with CSS. The patch here removes one of the instances of the title and shows the title that the Drupal 7 CSS hides away. Are generating two titles for the page and hiding one with CSS superior?!

Bojhan’s picture

@Gabor I gave a review like that in other issuess, because there are like 4 around one topic - all feedback is scattered. I wouldn't mind copying it over and diving deeper into why I think its a bad idea, but I definitely have given many examples in calls and in the issue queue to elaborate my position. I feel what is happening here, is that you do get concrete feedback but that its quickly dismissed and often with "we need testing to confirm" which I think is oke, if we would do thorough tests - but we do not, and so far haven't tested any of this beyond first impression as far as I know.

I feel like the base concept of this idea, is simply faulty and working around a disease like noticed in the other issue about this, and therefor making an simpler overlay is not necessary - because its only a aesthetic fix and not a usability one.

dasjo’s picture

regarding in LewisNyman's comment in #1909678-11: Clarify on the strategy for modals and overlay on mobile

Currently you can edit a view on mobile, the problem with removing the overlay is you loose that "jump in, jump out" modality the overlay gives you. This feature has value and I'd love to see a modal designed for small screens

i have tested the jquery mobile dialog examples. they offer such "jump in jump out" functionality by scrolling back to the original position after closing the dialog.

by activating font zoom 200% i could simulate more complex dialogs which exceed the height of the device. in those cases the dialog performs like a standard website - you can vertically scroll to reach all content of the dialog.

regarding the views use case, i think this could work quite well. the only thing is that scrolling might get cumbersome in some cases. for example when adding a field in views, you get an inner, scrollable div to select from the possible items. but i believe this kind of problem needs to be adressed within those modules that provide content for the dialogs.

one thing i'd seek for clarification is overlay vs. modals. is it correct that we currently use both and still are about to figure out in which cases which is more appropriate? or is this issue essentially about merging the two concepts into one?

tkoleary’s picture

Hi Bojhan,

Reegarding

I feel like the base concept of this idea, is simply faulty and working around a disease like noticed in the other issue about this, and therefor making an simpler overlay is not necessary - because its only a aesthetic fix and not a usability one.

I feel like you are lacking a little background on the process that got us to where we are with this so let me take you through it.

The first versions of this design that we put together were reviewed by the Spark team and commented on heavily. Extensive revisions were then made and we took the resulting design into an invision prototype. I built the prototype to match the device width of a iPad, loaded it on my iPad and walked it around the office doing five minute tests on people in our finance, sales, marketing and HR departments who have minimal experience with Drupal. This rough, quick testing immediately surfaced many issues with the recognizability of affordances (which lead to the pencils) the discoverability of edit mode (which lead to pulling it to the right) as well as other issues around understanding the functionality of the forms in the modals.

After revising the design and reloading the prototype I did this hallway testing three more times with different users each time. Each of these tests again surfaced issued that were then revised in the design. The final hallway tests were all 100% positive with users experiencing zero confusion about how to discover, open, and perform operations on blocks and nodes in the prototype.

After all of that I brought the designs back to Dries and the rest of the Spark team. We reviewed the design again proposed some additional adjustments and decided to share the concept with the rest of the community in the form of the video that I made and the prototype (which if you recall I had already shared with the usability team).

You know the history from there on so I don't need to elaborate, but as Gabor remarked, you have been involved in this issue form the point of our sharing the prototype and we have been open to your input and incorporated much of it in to the feature. You know that Dharmesh has done a full test of the feature which produced positive results (despite the fact that not all of the functionality was yet present), and that those results have also been shared with the community. You also know from your interaction with Wim on your (valuable) contribution to unifying the dropdowns, that we have faced some rather thorny implementation problems that have driven the design in new directions which required rethinking some of the experience.

So given all this I am struggling to understand the position you are taking now. I think we all want you to be part of the process of making this better but you are going to have to be more specific on what you mean when you say that this is "an aesthetic fix and not a usability one". Otherwise we don't have a clear action item or even a discussion topic.

hedinfoto’s picture

The block edit window looks awesome and I love this direction for the overlay module!

Our admins asked us to build something similar about two years ago. Once we built a custom module to this in Drupal 6 then later updated it to Drupal 7 most of the I hate drupal gripes stopped.

One small thing on the block edit dialog is the save button should be on the right side like the menu ones for consistency.

Nice Work!!!

Gábor Hojtsy’s picture

Updates to patch include (closely tied to overlay presentation):

- close X inside overlay and gray as per design (I thought this would affect Views modals but they use a different X and styled custom so no direct relation)
- lighter background gray (pointed out by tkoleary)

Might be more appropriate in the Seven theme(?)

- more spacing around title in the overlay
- border under #branding to separate from page

Overall:

OverlayChanges.png

Gábor Hojtsy’s picture

As usual, the latest patch is easily testable at http://simplytest.me/project/spark/8.x-1.x (among other related change proposals).

Gábor Hojtsy’s picture

And now a box shadow on the overlay that I missed from @tkoleary's design earlier. See in action at http://simplytest.me/project/spark/8.x-1.x

tkoleary’s picture

@Gabor Hojtsy: Shadow looks great!

Wim Leers’s picture

I agree that it looks better.

Problem with the "close" icon in the top right: the image is 21x21 pixels but it's displayed at 26x26 pixels; so it's stretched/blurry.

jessebeach’s picture

I fixed the button issue that Wim Leers mention in #54 and added some ARIA attributes.

andypost makes a good point in #44 about the contortions in the JS to prevent the overlay from opening on complex forms.

Gábor, you mention in #45...

More elaborate forms (eg. node edit) would show in the full page. So not sure how to separate concerns, if this is the only role of the overlay, then we obviously need to put the logic there. We could theoretically figure out a server side solution where we put classes on links that are eligible, but reality is we don't have the contextual information to do that on the server side most of the time. This JS can be swapped out to attach event handlers to links instead. That was previously found to not be performant due to the number of links possibly affected (especially as more things become blocks and have contextual links). That is why Drupal 7 changed the overlay click handler to work on the document and have the logic within for performance.

We could take the approach that any link decorated with a class overlay-compatible or something like that, would be brought up in the overlay. Any other link would not. We can still capture these clicks at the document level. The default behavior in this case is to not use the overlay. Is the difficulty in specifying what forms would get that class on the backend?

jessebeach’s picture

I just attempted to simply wrap the overlay in a jQuery UI dialog. I got it to function more or less well. I can't see the advantage of the approach though. The dialog doesn't give us much more than the ability to resize the overlay and a close button.

I think we can easily replicate the behavior of a jQuery UI dialog (resizeable, more flexible) and have the benefit of the iframe approach that already exists, namely that we can use a different theme to display the contents.

When the day arrives that we have Shadow DOM nodes (a functional polyfill) and CSS Scope, we can ditch the iframe and go with a less heavy solution.

Gábor Hojtsy’s picture

@jessebeach: I realised that we could put in classes as well to serve as an intermediary. That would let people to remove / add classes as applicable. That sounds like our best bet for now to make this more "alterable". We can move the logic from the click handler then to a Drupal behavior that would now dress up the links based on the conditions with classes instead of the elaborate checking logic happening on click.

Gábor Hojtsy’s picture

Rerolled the patch for current overlay. The close button changed in another issue to use CSS rounded corners, so the patch needed an update. Since we move the close button inside the overlay, that means more CSS removed.

Gábor Hojtsy’s picture

Here is a quick reroll. The previos patch did not apply cleanly anymore.

Gábor Hojtsy’s picture

New images for updating issue summary. Cannot upload direct to summary.

Gábor Hojtsy’s picture

Issue summary: View changes

Edited for current visual state.

Gábor Hojtsy’s picture

Title: Prototype simpler overlay look focused on short task accomplishment » Simplify overlay look, *only use for contextual operations*

Retitling for current state. I believe we arrived in the above to using overlay due to some advantages. Also trying to make sure people get one of the two main goals of this issue that this overlay would not be used anymore as a general admin browser.

Bojhan’s picture

I will review this and provide specific points, however I'd like to see some of the research results - because hallway testing, is not valid for the impact this would have. And I am afraid, the 30 minutes tests we often do, do not accomodate tasks that fall under the breath that this impact has.

Gábor Hojtsy’s picture

I'm not sure what would that test concentrate on? It sounds like you are looking at more elaborate tests with some grand setup of things to do going through different parts of the admin UI. (If 30 minutes is not enough, given how much we could cover in 30 minutes on prior tests).

tkoleary’s picture

Dharmesh dis a full test of tis on several participants. We can review results on Moday in UX office hours.

Gábor Hojtsy’s picture

FileSize
12.03 KB

Patch did not apply anymore (in overlay-child.css). Rerolled.

@Bojhan/@tkoleary: any news from the UX meeting?

Bojhan’s picture

Nope, I haven't seen the results or anything. Unless I have missed a meeting somewhere

dcmistry’s picture

Goal: To uncover usability issues with the blocks shippable UI

Methodology: Tested 6 internal Acquia employees. 3 of the participants were new to Drupal and 3 were “high” experience Drupal Sitebuilders

Issue Summary

The interaction pattern works well; The pencils provide an intuitive guide to participants to carry out the tasks and the hover makes this process easy.

There weren’t any major red flags with the interaction pattern (except if only one fieldset should be expanded at a time or not). That being said there are a lot of small issues (listed below) that can be implemented to improve the experience.

ISSUES SPECIFIC TO THE NEW USERS

Although the pencil interactions gets the foot in the door, the legacy Drupal issues (listed below) continue to be a pain point:

1) What is Block? (Terminology issue comes up again!) Since they don’t know what is a block and what it does, they go for pogo sticking and trying to see what sticks.

2) How do I know what is “Sidebar first” vs. “Sidebar second”? Participants resorted to trial and error to put the block in a different region. It is recommended to provide a visual to inform them and avoid trial and error method.

3) What is a Path?

Participants do not necessarily read the help instructions. They thought “URL” or “Link” would have been better labels.

EXPAND/ COLLAPSE FIELDSETS

New users preferred to see only one fieldset expanded so that they are not overwhelmed with options.However, the expert users wanted to see multiple fieldsets to be expanded. It provided a breadcrumb trail of what they have changed or to see the default options. The problem is also because they don’t necessarily notice the current default settings. The current settings aren’t immediately noticeable and visual hierarchy could be improved.

Recommended Solution

- To move the current settings below the fieldset label

- To provide a better scan-ability of information.

Before: (Pages: Not restricted, Content types: Not restricted, Roles: Not restricted)

After: (Pages Not restricted, Content types Not restricted, Roles Not restricted)

PLACEMENT OF PENCIL IN THE OVERLAY

Pencil should be on the right side on the overlay like everywhere else. Participant complained and said that we read LTR and this indicates it’s the primary action that isn’t the case

OTHER ISSUES THAT AFFECT THE USER EXPERIENCE

MAKE IT EASIER TO CANCEL

Skitch: https://www.evernote.com/shard/s134/sh/9bb24d00-f90c-45e0-9439-9834e0e69...

There is no cancel button, just the icon. You have to travel ⅔ of mouse pad to cancel. Plus, Cancel target is too small with no padding.

IMPROVE “EDIT MENU” EXPERIENCE

1) The “Enabled” column should be the first column

Skitch: https://www.evernote.com/shard/s134/sh/2ce460fb-45e0-4192-a6f4-14f63bbd3...

2) After changes are made to the page, the warning message isn’t grammatically correct or readable.

Current message “*previewing, save blocks to confirm Changes made in this table will not be saved until the form is submitted.”

Recommended message: “Save the form to implement changes.”

Skitch: https://www.evernote.com/shard/s134/sh/ce8e50a8-1360-45fd-adf8-6a9e6227b...

3) Two call to action buttons with no visual hierarchy. Issue worsens, when the participant has to scroll to get to the second call to action.

Skitch: https://www.evernote.com/shard/s134/sh/4a6b8e9c-1207-4181-8a8f-d9d717998...

“CONFIGURE BLOCK” EXPERIENCE CAN BE IMPROVED

Skitch: https://www.evernote.com/shard/s134/sh/d7c0cb5c-f8ae-42c8-8b12-d08f30d1d...

1) Show Parent link is confusing. One participant changed it and did not understand why the newly added link landed in the main menu instead of the “Tools” menu.

2) Weight is rarely understood or used

OVERLAY TITLE

The title of the overlay is too thin, too light (Need to check for accessibility)

Skitch: https://www.evernote.com/shard/s134/sh/02de714a-9391-4071-a7f9-851b04774...

Gábor Hojtsy’s picture

Issue tags: +sprint

Those user tests have intertwined results for this patch and #1880168: Introduce top-level sections for all forms. (Most results actually apply to that issue, not this one).

jessebeach’s picture

Overall I love this direction. The Overlay looks much more modern with this styling. It gives off a feeling of stability that the current styling in 7.x does not.

I added padding:0 to the h1 in the overlay to protect against theme style bleed. It closes up this gap in the Seven theme.

Screenshot of the Overlay open on the search block configuration form. There is a small gap of 10px below the title h1 of the overlay that makes the spacing look unbalanced.

webchick’s picture

I'm honestly perplexed why we're being asked to do more extensive testing of the "only show Overlay on contextual links" part of this patch.

#659488: Properly test the overlay to determine if it belongs in core or contrib is an extraordinarily painful read (I recommend not doing so ;)), but one thing there was there was clear consensus that showing the Overlay unconditionally in all aspects of site administration was the wrong thing to do:

http://drupal.org/node/659488#comment-2392698
http://drupal.org/node/659488#comment-2392936
http://drupal.org/node/659488#comment-2393128
http://drupal.org/node/659488#comment-2394124
http://drupal.org/node/659488#comment-2431298
http://drupal.org/node/659488#comment-2438152
http://drupal.org/node/659488#comment-2439622
http://drupal.org/node/659488#comment-2443628
http://drupal.org/node/659488#comment-2640634
http://drupal.org/node/659488#comment-2774750

To me, this aspect of the patch is just fixing a bug we introduced in D7 and never cleaned up.

tkoleary’s picture

webchick: Yes, Absolutely. Anecdotally, many people have commented to me directly that the first thing they do on install is disable overlay, and that now they won't need to because it's used in a sensible way.

David_Rothstein’s picture

Those are just random opinions. Don't we also have hours and hours of usability testing (that was done since then) showing the opposite?

I mean, it's hard to point to a specific usability test because the tests just had overlay enabled while participants did normal administrative tasks (they were not focused on a specific test of the overlay itself, such as proposed in #685046: Test Plan for the Overlay which is still open). But my memory of watching them is that people used the overlay close button all the time, to get back to where they were before. They would go off to do some administrative task, change their mind about what the right thing to do was, and then close the overlay to start over and try again. This seemed to me like one of the main things that prevented them from getting lost deep in the administrative interface. I do not believe it ever mattered how they got to the administrative interface in the first place (contextual links vs. clicking on a link in the toolbar); to the best of my recollection they used the close button frequently in both cases, although I was not thinking about this distinction myself at the time. Does anyone else remember this differently?

3. Well what if I go to the admin layer and make changes in several pages then i want to return to the site page I was last on? I can no longer just close the overlay and land back on that page.

True. But is that is the entire purpose of overlay? If so it's a pretty heavy handed approach to solving that user problem. A back arrow in #branding followed by a link to the last visited front end page would do the same thing.

Yes, see #787896: Add a link so that administrators can return to their most recently visited non-admin page :) However, I always assumed that would be an alternative to the overlay for sites that don't want to use the overlay at all. Mixing it with the overlay seems like a mistake to me because it would be inconsistent, wouldn't it? In some cases you'd click a close button to get back to where you were before, but in other cases you'd have a link/arrow.

effulgentsia’s picture

Mixing [a Back To link] with the overlay seems like a mistake to me because it would be inconsistent, wouldn't it?

Just another random opinion, but I don't see that as a consistency problem. Starting a general administration process and starting a contextual operation are two different things. So a back link to get out of the first, and a close button to get out of the second seems reasonable to me.

tkoleary’s picture

David_Rothstein:

I do not believe it ever mattered how they got to the administrative interface in the first place (contextual links vs. clicking on a link in the toolbar); to the best of my recollection they used the close button frequently in both cases,

Well yeah, because that was the available option. But does indeed matter how the user got there in the first place because users tend to return down the path they came. If I use a menu to navigate to a location in the administrative layer it is very likely that I will return to the same menu to find my way back. That's why a "back to site" link in the menu makes sense.

webchick’s picture

That's why a "back to site" link in the menu makes sense.

Isn't that just "Home"?

Those are just random opinions. Don't we also have hours and hours of usability testing (that was done since then) showing the opposite?

No, those are very specific opinions, many of which were from various people who commented on that issue directly after trying the Overlay for the first time during the D7 cycle. I'm not sure why we would disqualify that from being usability testing data. (Note that I specifically selected comments related to this concrete aspect of Overlay, not just knee-jerk demanding "OMG REMOVE IT FROM CORE!!" stuff—those I think were random opinions. :D)

Recent usability tests I don't remember saying anything about Overlay one way or another, only enough to say it's not terrible (which I agree with; it's actually really useful for contextual tasks—another random opinion :D). I also tend to put less stock in those because they're typically for an hour or less, and not really enough to show the impact of Overlay for people trying to do serious site building.

tkoleary’s picture

Isn't that just "Home"?

Not if it automagically remembers the last site page you were on. If I had that I'd use it all the time.

Gábor Hojtsy’s picture

Status: Needs review » Postponed
Issue tags: -sprint

Marking postponed on #1953374: Implement Seven style guide for core overlay as trying to align better with the proposed Seven style guide, which in itself simplifies / improves the overlay a great deal.

effulgentsia’s picture

Related: #890288: Improve Overlay accessibility by using modal dialogs. There's a suggestion in that issue for Overlay to be based on modal dialogs, which I think is something that was also discussed here but rejected. @jessebeach: care to comment on that issue with your latest thinking?

nod_’s picture

Issue tags: +JavaScript

tag :p

tim.plunkett’s picture

Priority: Normal » Major
Status: Postponed » Needs work
Issue tags: -JavaScript

Yeah forget #1953374: Implement Seven style guide for core overlay, that's a feature. This fixes 90% of the problems I have with overlay.

tim.plunkett’s picture

Issue tags: -Spark +JavaScript

Tags

nod_’s picture

Status: Needs work » Needs review
FileSize
6.79 KB

Reroll, I couldn't get the images to update properly, I need someone with original sources to update this patch.

That patch makes me actually like the overlay.

Status: Needs review » Needs work
Issue tags: -JavaScript

The last submitted patch, core-simpler-overlay-1889150-82.patch, failed testing.

nod_’s picture

Status: Needs work » Needs review

Status: Needs review » Needs work
Issue tags: +JavaScript

The last submitted patch, core-simpler-overlay-1889150-82.patch, failed testing.

nod_’s picture

Status: Needs work » Needs review

testbot is drunk.

LewisNyman’s picture

Issue tags: +styleguide, +styleguide-add-icons
FileSize
42.41 KB

I just realised that the proposed modal dialog from the Seven style guide hasn't been posted here

20.modal-dialog.png

nod_’s picture

webchick’s picture

Priority: Major » Critical

We talked about this in IRC and I believe we decided to do this.

tim.plunkett’s picture

#87, that's for #1953374: Implement Seven style guide for core overlay, this is about functionality.

Bojhan’s picture

So, I love that you guys chatted over IRC - but can I see some argumentation? Because David, me and others have already chimed in against this. Webchick I know that you felt like it should be this way since ever, that we should limit it for contextual links only - but every time you said that I laid out why that wasn't a good idea.

Status: Needs review » Needs work

The last submitted patch, core-simpler-overlay-1889150-82.patch, failed testing.

nod_’s picture

Priority: Critical » Major
Status: Needs work » Postponed

From #91 doesn't look like there is a way to get agreement in the near future about this issue.

thedavidmeister’s picture

Status: Postponed » Active

@nod_ what is this postponed on?

if it's just discussion within this issue, it's active. Postponed would imply we're waiting on something specific. The only other option would be "won't fix".

saltednut’s picture

It appears that there is work happening as an alternative to overlay here: #787896: Add a link so that administrators can return to their most recently visited non-admin page
In tandem, this issue has movement #2088121: Remove Overlay

Should this issue be closed (wont fix)?

saltednut’s picture

Issue summary: View changes

Fix third image.

nod_’s picture

Talked with Gabor, closing in favor or related issues.