Creating this issue as a fork from #659488: Properly test the overlay to determine if it belongs in core or contrib as per webchick and ksenzee's request.

As I said in that issue, I am optimistic about Overlay overall. It makes simple tasks easier to complete, especially if you need context for them. It works well with in-line editing in this regard.

However, aside from the concerns over people losing work in it, accessibility, and compatibility with some browsers, I believe that it is a critical issue that overlay shows on admin/modules & admin/build/block. Those pages already have a tendency to be slow and adding more JS to them is going to cause serious issues for some people, I suspect.

If it doesn't cause issues for people now, just imagine what will happen if people have >50 modules or blocks. And that is definitely going to happen, especially considering things like Ubercart and CCK, which can have so many. The Open Atrium distribution would be another example.

Therefore, I suggest that the admin/modules & admin/build/block links in Toolbar, etc. not load into Overlay, even when it is enabled. Rather, they should just go directly to the page. I think this better supports people's mental model of those tasks, in any case.

Note that I think that configuration of individual blocks can still happen in Overlay, if they are being in-line edited, especially. But the full blocks page already can crash Firefox on Drupal 6 just with the sorting JS, if you have enough blocks.

Comments

Bojhan’s picture

Bojhan commented
Category: bug » feature
Priority: Critical » Normal

Honestly, I do not see your point at all. Yes its adding overhead, then again - anything we would add to those pages is adding overhead. Would we disable anything that adds overhead to those pages? no.

Also, please consider the user experience - if you have some pages with overlay and others without. It will be very confusing, if there is no clear reason for doing so.

This is most certainly not a critical bug report, it is not preventing people from working with it. I find it somewhat a false argument, that it would not scale - those pages by default do not scale, the overlay is not really adding much to it.

EvanDonovan’s picture

EvanDonovan commented

Bojhan: I understand your point of view. However, sometimes it is *necessary* to disable things that add overhead to particular pages. I've had to do theme overrides to admin/build/block before just because the tabledrag.js was making the page hang.

I wish I could come up with a test case to attempt to prove my point - does anyone know of a module that generates loads of fake modules and/or blocks?

I will not change status back, since you have been working with Drupal usability far longer than I. Hopefully, some others will weigh in though.

Note to those who might comment in this issue: Don't use this issue to discuss feelings of dislike for the Overlay generally. This issue is specifically about two pages that I don't believe should be in Overlay, even when it is enabled. It could be expanded to cover a few other pages though if they are: 1) resource-intensive, 2) complex, 3) don't feel like "front-end" kind of tasks.

Of course, the third criteria is somewhat subjective. But essentially, my argument is that when people administer modules, and, to a lesser extent, administer blocks, they are doing something that they don't need to preserve their previous context on the site "front-end" in order to do. Thus, it is not a great loss if the page doesn't show in Overlay, and it has some advantages. More specifically, the page will load more rapidly, and scrolling won't be as awkward. Also, it won't be as easy to lose work. Note that, as several people have commented previously, page loads appear to take longer subjectively in a modal dialog than the main browser window.

EvanDonovan’s picture

EvanDonovan commented

If I can't convince others of this, then I will possibly be the author of the "selective overlay module" module which would hook_menu_alter to disable overlay on particular paths. :)

kiphaas7’s picture

kiphaas7 commented

Did those UX studies show that overlay needs to loaded for all tasks? I'm leaning towards agreeing with argument #3, overlay should guesstimate what are the short, quick tasks (overlay), and the long, tedious tasks where you do want to change context (no overlay). Usually, one enables 1 or more modules, and then proceeds to configure those. Not a "quick" task.

However, just configuring a module is an example of a quick task.

IMHO :).

Pages that shouldn't load overlay should be (again, IMHO):

  • The main administration page. Reason: if one clicks to go main admin page, he/she does not know where to go (so at least 2 clicks), and to get their bearings would benefit from having this new context. OR: just wants to do a lot of stuff. Anyway, it would also make a lot of sense for the direct link to the main admin page NOT to open in overlay.
  • the modules page, for reasons mentioned above.
  • ..?

(And once in the admin zone without overlay, off course overlay should never, ever be loaded!!!)

Blocks page, I'm not sure. That one could qualify as a quick task imho (edit block, get out and proceed with normal stuff).

David_Rothstein’s picture

David_Rothstein commented

I think this might quickly become a rathole, no? Certain clicks would randomly take you out of the overlay or back into it again with no warning. IMO the transitions are what's disorienting, and those should be minimized. (We already have too many of them - e.g. on the People page clicking on a username takes you out of the overlay and dumps you into a different-style page.)

See also:
#714464: Don't open a new overlay within /admin

kiphaas7’s picture

kiphaas7 commented

Yes, I agree with that when being in /admin, overlay should never, ever open (which has been fixed in a different issue). However, here I'm talking about paths that should lead directly to the admin zone without opening in overlay. Subtle difference, and worth it's own issue. It might be better to re-title this issue to a more broader "Paths that shouldn't open in overlay (for Performance & Usability)". Or something like that, I suck at thinking of descriptive titles.

The people page opening in overlay, and then taking you out of overlay for editing/viewing a user does sound bizarre. However, I've always found it a bit of a drupalWTF that editing/viewing users (other than your own) is not done in a more admin like section. So it not opening in overlay is also a direct consequence of the design choice made there.

Keeping that in mind, there should be another separate issue for dealing when already in overlay, some links magically take you out of overlay. That is weird and buggy behavior, even though there might be some good technical reasons behind taking one out of overlay.

EvanDonovan’s picture

EvanDonovan commented

David_Rothstein: It could easily become a rathole, which is why I am concerned primarily about the modules page and the blocks page (the page with all the blocks listed, not the configuration page for an individual block). I don't think that there's many other pages that take as long to load, or are as taxing in terms of the client-side Javascript.

I don't think there should be many transitions. That would definitely be problematic. It should simply be that when people click to go into the modules page or the blocks page that they are not in Overlay, and once they are not in it, they won't go back into it, until they are back at the front-end of their site.

Kiphaas7: Do you want to post the issue for paths that take you out of overlay and shouldn't? I agree with your reasoning. Perhaps editing users other than your own should happen in the admin theme, just as editing nodes does.

kiphaas7’s picture

kiphaas7 commented

They're talking in #714464: Don't open a new overlay within /admin about adding a switch (Bad idea IMHO, clutters the UI and isn't that straightforward for non-technical users). It's going to be either a switch to turn off overlay (like they are talking about in issue 714464), or this issue, where some paths lead you to the admin interface. So, 714464 and this one are related. Having both would be... unfortunate and confusing. Some links open overlay and some dont, and on top of that, you can make all admin links not open in overlay?

I'd prefer if someone else (with more knowledge on what paths exactly lead to leaving the overlay) starts the new issue. Luckily, that one is unrelated to 714464 and this one, and can (and should) be fixed on it's own.

catch’s picture

catch
he/him
Primary language English
commented

If you want to show a lot of modules on the modules page, you can uncomment the couple of lines which unset hidden and required in the page callback, then all core required + test modules will show up there.

For blocks would need to write a hook_block_info() which generates a tonne of dummy blocks.

I don't know much/anything about javascript profiling, but it'd be great if someone who does could do a before after on those pages with and without the overlay to see how much difference it makes. If it's going to vastly increase the likelihood of browser lockup then we should consider this, if it's only slightly worse, then people can disable it on their own.

casey’s picture

casey commented

#668640: Overlay shouldn't be based on jQuery UI Dialog landed which speeds up things. The modules page and blocks are perfectly usable inside the overlay. I don't think we should do this.

EvanDonovan’s picture

EvanDonovan commented
Status: Active » Closed (won't fix)

Fair enough. If I think it necessary, I'll do it using hook_menu_alter() or something.