Properly test the overlay to determine if it belongs in core or contrib

I posted the same thing a few minutes after you. Here's what I said in #659492: Move Overlay Module to Contrib

I'm opening this ticket to try and stop overlay.module from getting into the final version of Drupal 7 core. I have no idea why this shouldn't be a contributed module (what's the gain in forcing this onto every Drupal site?), and given the large amount of other critical bugs still left to be tackled for D7 I think the best thing to do is move this into contrib and consider adding it to Drupal 8 core, if it's used and the demand is there. But to add a buggy module that fundamentally shifts the UI to such an extreme at such a late date seems like a recipe for disaster.

Here are the issues that David_Rothstein noted in #610234: Overlay implementation:
#655368: Editing a shortcut causes it to jump to the end of the list
#655376: Node previews are messed up in the overlay
#655388: Many ways to lose data on form input in the overlay
#655416: "Demonstrate block regions" bugs with regions, navigation, overlay
#655448: Horizontal scrollbar shows when overlay is enabled and screen is resized
#655464: Add a "Help on" toggle to the overlay
#655470: "Add to shortcuts" button flashes briefly on the page before jumping out to above the overlay
#655490: The back button does not change the active shortcut link (when overlay is being used)
#655492: Clearing cache and hitting the back button in the overlay gives a 404 error
#655508: Certain node-related pages aren't defined in hook_admin_paths() when they should be
#655514: Usability issues with overlay close button
#655518: Tabs do not appear correctly in the overlay in IE6
#655526: Make sure that the overlay is accessible
#655542: Links in overlay on Firefox 3.5 are half-rendered after they fade in
#655562: Use border-radius throughout core in addition to Mozilla and Webkit-specific properties
#655600: Small Code cleanups in overlay module
#655614: Changes made by submitting a form in the overlay are not reflected when the window automatically closes
#655722: Changes made in an overlay session are not reflected when the user closes the overlay
#655736: Other modules are not made aware of core page elements that are intended to display in an overlay
#655740: Fix small JavaScript issues in the overlay module
#655746: Display bugs with the overlay on Safari 4

I also added one more: #659480: Per-user setting for the Overlay

Can anyone give a good reason for this not going into contrib?

Also note that a couple of JavaScript/AJAX masters are already working on http://drupal.org/project/dialog, which may or may not supersede this Overlay implementation soon.

From a development perspective does it make sense to move to contrib? This module (at this point) is plagued with pain points. It isn't close to being ready for prime time. Would it be better to move to contrib where a 2.x branch could be made from lessons learned, drupal core is not held up while this is being worked on, and something all together better could go into D8?

Or, are there some PHP and JavaScript ninjas who are going to drive this one home for D7 in a reasonable time?

But to add a buggy module that fundamentally shifts the UI to such an extreme at such a late date seems like a recipe for disaster.

The original spec was drawn out a good 8 (?) months ago, it's been mentioned as a code freeze exception numerous times...

afaik it was committed to get more eyes on it, but instead of those eyes trying to fix it, they are too busy looking for reasons to get rid of it
seems like an easy way out to me

frankly, if this makes it in, I will probably turn it off every time, but I trust the UX team when they say this will improve the experience for new users (if perfo is fixed ofc)

We don't have to "trust the UX team". We can and should test the overlay with real users. I believe that was always part of the plan and I really want us to stick with that.

I'll add that "disabled in the default profile" is another option beside 'move to contrib'.

Personally, I can't stand the jerkiness when the overlay is loading a new page. If it were very fast and stable, I might like it more. I know that lots of talented people designed and implemented this. Thanks to all of you. Still, its a pity that the final product is not a great UX improvement. Sometimes that happens. Look at the code registry and the deletion API. Both were removed from core after massive effort.

suetji- your comment is neither helpful nor informative. Just because there was a spec laid out 8 months ago doesn't mean a thing (take a look at the # of open issues, there's lots of talk). Not everyone can be expected to be aware of every single change taking place in core. The fact remains that this is not a demonstrated need for core, and while the UX team is doing great work, but "user experience" cannot come at the expense of Drupal's most important user group: i.e. developers and site builders. This is not ready for core, nor do we lose anything from having it in contrib, and it should not be allowed to become a stumbling block to a full release of D7.

This is especially misinformed and unhelpful:

instead of those eyes trying to fix it, they are too busy looking for reasons to get rid of it seems like an easy way out to me

There should be glaringly obvious reasons to put something into core, so there shouldn't be a burden on those who want to stop this from reaching core, but rather there need to be reasons to put something untested and (imo) pretty much unneeded into core.

I'll ask again: can you give me one good reason that this shouldn't be in contrib? Is there some harm to the user?

yea ur right, there were absolutely no unconstructive comments like "this kills kittens", etc.
but don't worry, my motivation is pretty much killed & buried

@5: until we have a testable product, we have to trust the spec or options proposed, no?

Please go ahead and user test it.
We have done this way too little and in reoccurs to me that we should do it.

Any of our discussion is not worth too much withouth that backing.
Do A/B testing with and without Overlay, and observe the behaviour, make a screencast.

So we might get hard data that is badly needed.

I do not have any particular preference, but I'm interested to know what happens... Subscribing.

I'd vote to move to contrib just because it's the kind of module that is going to need a lot of ongoing maintenance (as browsers change, bugs are uncovered, new modules ask for new features from it, etc.).

My random personal feelings is that the overlay is something non-hardcore Drupal Admins will like. It creates a feeling of "Real bit of site vs Administration bit of the site". One of the biggest issues I've had with drupal is that it isn't obvious when I can see things because I'm an admin and when something is what my users will be able to see.

I think the Overlay provides a good psychological separation between "administration" and "the site itself" in a way that is different to the way wordpress and joomla do things (Where they just have a completely seperate section). I have a feeling that this overlay fits in with drupal modular and flexible nature much nicer then the admin panels of phpbb3, joomla and wordpress.

Finally the reason why I think its good to have in core is that this is the kind of issue that is biggest for complete newbies to drupal. I'm assuming experience drupal administrators have gotten quite used to the way drupal works and which modules they want to install. So if this overlay is any use, it is going to be of use to the kind of person who probably won't install it as a module. Whereas the experienced people who probably won't care for this psychological help will more easily be able to turn things off.

Though I can understand #10 so I'm just talking from a drupal user point of view, not developer

@yautja_cetanu No one releases a drupal site with just core modules. Even if something is moved to contrib it may be used on many sites and even distros. The two reasons to move it to contrib (imho) are:

1. It will hold up D7 significantly because it has so many issues.
2. It looks like the module will undergo lots of changes, functionally, that would be good to roll out on D7 sites.

Re: David's look at the issues, the node system has more critical issues for D7 then the overlay:

http://drupal.org/project/issues/search/drupal?text=&assigned=&submitted...

http://drupal.org/project/issues/search/drupal?text=&assigned=&submitted...

6 vs. 9.

(This is a sarcastic subscribe post where the commenter avoids to take sides but calls out misdirections in arguments).

the node system has more critical issues for D7 then the overlay:

Move node to contrib! ;-)

I'll be performing some user tests (also) on the overlay in the coming week. Will link the videos here. There are already are some on the D7UX group on vimeo, even if not A/B without overlay.
http://www.vimeo.com/tag:d7ux

Can you also try your user tests with site builders and developers? We're users too!

@David_Rothstein - Thanks for clearing up my first point in #12.

Will the user testing make for actual changes that will be added to the overlay module before D8? If not, why remove it?

Another question I have is this: can someone point me to one site that uses such a heavy-handed approach to "user experience"? Has there been a single test to make sure that this doesn't make things LESS usable? It certainly makes it less usable for the site builders and developers I've talked to, and I can't imagine that it's going to make things easier for end-users either, given that it's a totally new (to the best of my knowledge) way of handling things. (Note: I know that many sites use lightbox/thickbox on certain sections of a site, but I've never seen anything close to this comprehensive/overbearing)

For me, the main argument is in #10. Browsers will change. Maybe Firefox 3.7 breaks the overlay, maybe IE8 gets an overhaul and is brought completely up to standards compliance, maybe pigs will fly. The point being, this is a pretty finicky module. It is primarily javascript + css, which are two of the things that us developers have the least control over how they are rendered. For example, I just found out that $().html() can break forms in IE8 :(

So, I am all for Overlay going into core (especially if user testing shows its a +1 for end-users), with the caveat that there needs to be a plan to keep it up to date and playing well with browsers and contrib modules. If we think that can be done via core's usual release schedule, then great, otherwise contrib may be the safe route.

@te-brian Keeping up with browser versions is something core will do. If a release of IE9 breaks the site core will have an update.

@mfer But will it be fast enough? Drupal releases are typically one or two months apart, and if a new browser release (which breaks Overlay) falls just after a new Drupal release, chances are we'd be waiting at least a few weeks for an official Drupal update to fix it. On the other hand, a module could roll a release that same day.

@mcrittenden There is a lot of js in drupal already. We've been dealing with these situations for some time. That is not a reason to not have the overlay module in core.

#22: New browser releases are preceded by beta and release candidates (yes, even IE). So there is most likely enough time to find out that certain parts fail. Plus, using jquery and jquery ui makes sure a lot more people than just drupal users test it, and most of the drupal js code is plain jquery (ui) code.

Our arguing is wasted breath - we are way to deep in the project to see anything how the users we want to reach out to see it.

It is a shame we have no tradition in user testing - but it is the same in most client projects - people think the time and money is wasted, reality will tell anyway - and so it does :P

I am really not sure why everyone is picking on the overlay just now or wait - I am sure. The situation is: as long as it wasn't committed, it _was_ in contrib all the time. Now it is committed and in everyone's face. Webchick committed it exactly for that reason and to get more force behind fixing the bugs.

The people behind it like David, Gabor and Katherine have done an amazing job so far and fixed tons of bugs worse than the ones that are left now. So why not ironing out the remaining ones? (including UX bugs)

I'll throw my 2 cents (CDN) in here. I found this page while searching for a way to disable the overlay.

I've been working with Drupal since v4.6. I'm a Drupal developer/administrator, currently migrating a site with ~70,000 lines of code to Drupal 6 (boy, that's fun). I'm used to working with a site with about 1.5 million words of content, sharing node content between 15 different databases. So, I'm not new to Drupal, but am new to Drupal 7.

Out of curiosity, I downloaded Drupal 7 today. At first the overlay was a surprise, but interesting. However, the feeling of poor responsiveness quickly became irritating. Overlays that were taller than the browser window caused some odd scrolling issues. When loading an admin blocks/menu page with lots of entries, to me it was perceived as more sluggish than the standard page load. That the overlay appeared everywhere was frustrating. I wanted it *off*.

The overlay idea (effectively a modal dialog) is useful, but not as a replacement for every administrative action. Like the 'lightbox' effect, it seems like it's the technique du-jour and I question whether it's really useful all the time. I can see its beneficial effect for limited dialog boxes but beyond that, I'm not convinced.

(And granted, I'm used to the 'old' way of doing things. I'm certain there's a bit of bias there.)

I don't disagree that it's an impressive piece of work, but from my limited experience with it, I'd suggest moving it to contrib at this point in time.

@kpander is that because of it being sluggish? Because you don't want it enabled by default? Or, something else? Why move it to contrib?

There is an issue about the performance problems and it is being worked on.

@mfer: Sorry for not being clearer about that. The sluggish-ness contributed to me wanting to turn it off. Other usability issues were frustrating. e.g.,:

1. Visual distraction: A dimmed background is still more distracting than a page with no dimmed background.
2. Repeated options: The overlay header is the same as the admin panel/bookmarks that are already on the page, so all of those options (Dashboard, Content, Structure, etc.) appear on the page twice now (a visual distraction).
3. Unexpected behaviour: Clicking the 'open/close drawer' link on the -overlay- cancels the overlay (I assume this is just a bug, not the intended UX).
4. Recursive overlays:
   • Click 'Structure' in the top 'admin' bar. This displays an overlay.
   • Click 'Blocks'. This switches to a new page in the overlay.
   • Cick 'configure' on any block. This opens an additional overlay on top of the existing one.

   I now have an overlay on top of an overlay. It's *messy* (probably not the intent of the lightbox-style overlay approach). See the attached screenshot.

5. Modal look, but not feel: The page will scroll based on the page size, not necessarily the overlay size. So if I have a page with a tall background with a short overlay, I can scroll the overlay completely off the page.

So, why did I suggest it should move to contrib? I don't think it's ready for prime-time yet. Its performance isn't quite 100% yet, but more importantly I don't think the UX is fully considered. In my opinion, it looks like it's been implemented as a one-size fits all solution for all tasks. For quick configuration changes, I can see it being useful. As the primary means of administering the site (or nodes, or menus), maybe not. I don't know that it's a necessary core feature (that's really a matter of opinion).

Hope that helps a bit...

@kpander - I know that at least 2, 4, and 5 are known bugs. Realize the overlay is a system with bugs that are being worked out. There is a difference between the final intent and what is there now. Recursive overlays are a bug. The header inside the overlay is a bug. These are known.

No. 1 is debatable. It was the UX effort that suggested the overlays. They should be the experts on that so I defer to them. Some of them were paid experts. Is there a UX reason to remove it? Something from experience, testing, research? Something you can articulate?

No.3 is where I think you mean the X on the top right of the overlay. That is meant to close the overlay. What else would you think that would do?

The target of this system is not site builders. The target is the people who use the sites the builders create.

2. and 4. is a bug that is worked on here: http://drupal.org/node/649004 but indeed very annoying for someone that tries the overlay the first time. Clear caches on admin/config/performance and this is gone.

5. The eternal scrolling into the black is naughty and I think there was an issue for that somewhere, but not sure. If it is not, an issue must be filed, for especially a novice user loses all orientation when the entire content area gets black and he does not know how to get back.

We are all not too sure about the UX of the overlay, so your feedback is welcome.

3. open/close drawer - ah give me a hint, what do you mean by that?

1. well, that could be valid, though all user tests run on that so far did not indicate users being distracted, personally I feel the white area gets even more focus because of the strong contrast.

ah, mfer was quicker than me :)

Hey,

3. 'open/close drawer' -- this is the downward facing arrow to the left and below the 'X' (at the right side of the overlay). It's just above the 'edit shortcuts' text label. Clicking it on an overlay seems to have the same effect as clicking the 'X' or pressing escape.

I understand the UX intent of the overlays, I just think they may have gone too far. We're effectively putting full-page forms inside windows. For small, quick interactions, I think it makes sense. For a large configuration form (or complex node creation, or menu item re-arrangement where there are > 100 menu items), I don't see the benefit.

I guess for me, in its current state, I hope there's an 'off' button. Then again, once the known performance/usability issues are out of the way, it may be a different story.

(As an off-topic comment, I'm amazed at how much D7 has improved with respect to usability already, independent of this issue.)

Kendall

I said this elsewhere, and I'll say it again here.

I don't want to make the developers feel bad, but I've been using Drupal daily as an admin and then as a developer since 2005, and the first thing I looked for after installing D7 was a way to turn overlay off. It feels like a gigantic modal dialog, and it's simply not clear what value a page on top of a page adds. I don't want an admin interface that looks and feels like a lightbox, complete with spinner.

My vote, in order of preference:

1. Make it a contributed module.

2. Turn it off in defaults.

3. Give me a button (and not a buried one, either) to make it go away.

Thanks, and sorry if I offend.

Here's a great quote from Dries' post today Speed Matters

Based on their observations, Google suggests site builders to think twice about adding a feature that hurts performance if the benefit of the feature is unproven.

Where's the proof? If this has been studied, I'd love to take a look at the methods and #s, because I'm about 99% sure that this will hurt usability under a number of common conditions.

@shunting Do you not like the overlay because its a major change to the Drupal you are used to or because you have a reason you can explain in more detail.

The overlay is here to create separation between the admin tasks and when someone is viewing the site. Part of the goal was to give it an application like feel. Some systems like Joomla! and Wordpress have a different area of the site you need to navigate to. Drupal sort of does this with the path /admin.

The idea here it to put these tasks at a site maintainers fingertips all the time. And, that you don't need to navigate away from the page you are on to preform admin / content management tasks. You might want to take a look at the goals and recommendations of the UX effort.

While I'm not saying I agree or am against it, this is a major change with some good goals. Are they not being met? Is there an error in the goals? Is there a better way to meet those goals? The way Drupal has been doing things can use a bit of improvement. This is a shot at that.

@Alex UA how will this hurt usability? Can you explain some cases how usability will be lower than it previously was and/or how the change hurts future usability improvement?

No, I think that's not entirely correct. We have a new admin theme called Seven to visually distinguish between administrative areas/pages and regular stuff.

The Overlay's purpose is different. Although I don't really know what its purpose is...

Well said. We already have a visual distinction by setting admin_theme.

So the overlays' purpose can only be to better maintain your current context when performing quick actions. Problem is, we use it WAY too often and it has never worked smoothly. Can folks name their favorite place(s) where it makes sense we just use overlay there by default.

@mfer in general I think it will hurt usability because it doesn't work like anything else users encounter while they use the internet. I've asked over and over for an example of something similar "in the wild", and nobody can point to anything remotely similar. Since we're talking UX, something that is not specific to Drupal, that should be a big, bright, flashing red light that tells you something is wrong.

Second: if the idea is to differentiate between the "front end" of the site and the admin areas, then why is it popping up when I create or edit content? Is creating content the same as administering a site in the mind of most users? I really doubt it (totally different type of task), though I can see how this one might be more of a toss up.

Third: the implementation is inconsistent and doesn't seem to have much logic to it. Some quick examples (found after one minute of clicking around) If I edit a node it pops up, but on either "outline" or "track" it doesn't. Here's another: click on your user name. Click on edit. Again, no overlay, which is really extraordinarily bad usability, since clicking "edit" on the node page does bring up the overlay.

Is there a reason for this, or is it just because this is a new, unused, and untested module? Does it matter? Either way (and sorry to repeat myself) I will wager that this module performs worse on usability tests of different types of users under a number of common conditions.

@mfer 35 I'm not sure what kind of detail you want, so I'll restructure.

1. The value of the overlay is not clear. Why is this "page on top of a page" even there?

2. A modal shift and a wait for no value is not a good idea. "Complete with spinner" means that the overlay is telling me to wait.

3. "Like a lightbox" is a combination of (1) and (2). This is how it feels to this user, and how it was done technically. That is:

When I have an image, the value of a lightbox is clear: Thumb to full size. The wait and the modal shift are worth it.

But there's no such apparent value for the overlay. So, there's a wait and a modal shift, but with no perceptible value add. So, it's not worth a wait, or the modal shift.

As for separating administrative tasks from content: I understand and agree with the requirement, but that sounds like a theming issue to me. So what's the justification for an admin lightbox?

NOTE If a more "application-like" feel is the goal... Well, there are an awful lot of applications out there, and I'm not sure that all of them are successful from a usability standpoint.

@Alex UA 38:

I agree that using the overlay to edit nodal content is not a good idea (and posting to drupal is also something I'm way past the 10,000 hour threshold on).

As an author, I don't want to be separated from my content! I want to be unified with it, since writing, even the most mundane writing, is an expression of my thoughts, feelings, plans, desires... In no sense is creating content an administrative task, so if the design goal of the overlay is to separate administrative tasks from other tasks, then using the overlay for content creation puts creative work in exactly the wrong bucket.

And then there's the basic fear that every writer who's typing into a text box online has: Loss of data. Any time there's a mode shift like this one, there's that fear. (The fear would exist even if all the bugs were fixed, because it's the mode shift that causes it. Personally, I wish the modality of the Edit tab would go away, so I could edit directly onto the page. That would eliminate both the fear, and remove another layer of separation between me and my content...)

To put this another way, if the goal of the overlay is to make D7 more "application-like" (and I'm not sure I agree with that goal), then ask yourself this: When you edit in Word, does Word make you click on a paragraph, and then edit the paragraph in a modal dialog? Or does Word allow you to type your content directly onto the page?

@ moshe weitzman 37:

The overlay is also one of the very first things that a user encounters after doing a fresh install. It's a bit of a shock (and I think the "page on a page" would be a shock to anybody, not just an experienced user. As @Alex UA 19 points out, there doesn't seem to be an precedent for this UI anywhere else on the Internet. So it's not clear whether overlay is even good for newbies, who presumably would not be comfortable with novelty).

+1000:

So the overlays' purpose can only be to better maintain your current context when performing quick actions.

* * *

Just brainstorming, since there are all kinds of issues with this idea too, and maybe it violates the idea of code freeze... Would it be better (and even "application-like") if, instead of one massive overlay that usurps the entire screen, we had non-modal floating palettes a la some Adobe applications? (Even though Adobe has created its own usability issues by proliferating palettes).

OK, I really think we should invite Mard and/or Leisa to discuss the matter here.

I actually quite like the overlay. Of course, there are still a couple of annoying bugs, but these will (hopefully) resolved until release. But in general, I think the overlay is great. It lets me do administrative tasks without losing the context. I think especially the combination of contextual links and overlay is a huge step forward in Drupal's usability. Statements that the overlay makes you wait I don't think that these hold true. Without the overlay, when clicking an admin link, the page has to load as well and the time should be the same.

Anyway. I don't think this discussion will lead to actual results this way. There are people who like the overlay and think it's a great step forward in Drupal's usability (there are lots of them, Mark&Leisa of course but also the people who worked on the overlay a lot obviously think it's a good thing), and as this issue shows there are people who do not like the overlay.

Now, we have no idea how represantitive each camp is and I don't think we will find out by raising pro and con arguments here (this would be something to find out with formal usability testing).

Also. The overlay being in core forces nobody to use it, it's easily turned off.

@Franco 42:

1. If a user sees a spinner, the user is waiting -- or, more precisely, perceives themselves to wait. Therefore, "statements that the overlay makes you wait" are, in fact, true. I grant that a page build also takes time, but (a) that's expected so there's no spinner, and (b) I'd like some evidence that the overlay is the same speed or faster. Is it?

2. The overlay is not "easily turned off" especially if we're talking about newbies (who are the target audience, yes?). The user has to know that the overlay is a module, and to be found in the modules tab under Configuration and Modules. I'm not a newbie, and when I tried to turn it off, I went to Appearance first (is it like theming?), then to Structure (is it like a menu?), then to Configuration (is it a system thing?) and only finally arrived at the Modules tab.

That's why my third choice at 33 is "give me a button (and not a buried one, either) to make it go away."

I don't understand the "context is preserved" statement. Do you have an example of what you mean? For me, the penalty of the modal shift is not worth the benefit, because I don't see any benefit. Understanding this might change my mind.

If people have questions on why I'd suggest they head over to http://d7ux.org and do some reading/searching. We shouldn't rehash conversations that have already happened. Even if you disagree you'll have a better understanding of how we arrived here which will help in moving forward.

Off topic to kpander:

There are many ways that D7 is a joy to use -- I love the vertical tabs for node settings, and the CCK fields are vastly improved. It's really starting to look polished.

@mfer 44 I went to D7ux and searched on "overlay". From one of the three hits, I found this:

The ‘overlay window’, the example of which shown is ‘add content’ (in a very sketchy and unfinished state, I hasten to add!). We see the overlay as a fantastic way to provide a clean interface for these tasks whilst keeping the user in the context of the site for which they are performing those tasks, rather than taking them away into an ‘admin section’. Obviously we would need to allow for users who are not using JavaScript (in which case they probably would have to go into more of an ‘admin section’).

I think the comments on this thread are more current and detailed. Is there some place else I should be looking? Thanks!

OK, Time for some lobbying for the overlay from a practical perspective.
In Tests so far, Users did not show any enstrangement to the overlay. They used it just as it came as the admin area, I did not get comments "why is there a page behind the page". You notice a lot later and don't even see it at the beginning.
http://vimeo.com/groups/drupalux/videos/7219023

The loading takes a second, but this should be way fast enough, on a lot of web

I just checked what mfer said: quick editing of a block, just switching it from the left sidebar to the right sidebar.
Yes, this is where the overlay begins to shine: you just edit your block, save, and you are still where you started. Fun!

Another thing: try editing a a node, which is possible now even from a teaser view: you discover a typo or wanna change the text: you click edit, change your text, save and back you are. Sure this is the same with the edit and view tabs, but the feeling of "being back" is much stronger.

It also helps with very short admin forms (which are few in Drupal :) ), like say you have Descriptions for admin items turned off and you click "Structure". Very short form, surrounded by black, very good for focusing on the content, better than when having a giant white page, as without overlay.

And as many people already said: the hardcore users, like ourselves, who browse around in the admin area a lot (this is indeed a bit annoying with the overlay turned on), can turn it off, and as an issue exists http://drupal.org/node/659480 this will also be possible role-based.

But for new users, it is one step to help with the "where am I" problem, which was the biggest issue through all tests in Minnesota, Baltimore and later. It helps in two ways: by keeping the node you started from open and also by the strong visual distinction through the black color. Also the Javascript effect makes it feel more "temporary" so you get a stronger feeling that the frontend is "your real site". Frontend Users (Content Editors) do not use the admin area a lot.

The seven admin theme without the overlay has too much white for me which makes the pages harder to scan and I am missing borders or limits of the site. But no wonder: it is designed for working with the overlay, and needs to have no borders and be white for that purpose.

@eigentor 47

1. Well, all I can tell say is that when this user tested it, I experienced what I wrote about. Like others, I found this thread by searching for how to turn overlay off! Sorry!

2. Am I really paying an extra second every time I load the overlay?

3. My reaction is based on a clean install and I'm user 1, so that's was my introduction and my starting context. There's a suggestion above to turn this off for user 1. Maybe that's a good idea?

4. I'm clear on the "Where am I" problem. I'm not clear on why overlay is the solution. Why is this not a theming issue? Or a dynamic breadcrumb issue?

Let's take the use case for the advantages.

I just checked what mfer said: quick editing of a block, just switching it from the left sidebar to the right sidebar.
Yes, this is where the overlay begins to shine: you just edit your block, save, and you are still where you started. Fun!

Acting as a user, though not filmed, I start out in a post (my context):

a. Hover over block in sidebar, get the dotted outline, click on the cool gear thingy

b. Configure "page on page" comes up (with spinner: one one thousand, two one thousand, three one thousand... )

c. Shift block to a new region.

d. Look for Save button, realize I have to go out of mode to scroll the window down, not the overlay, scroll.

e. Save block.

f. Overlay closes (am I not seeing a confirmation message? Where will they appear?), I am where I started.

[I try again. Weird. Where before I was getting the entire page, including sidebars, now I'm getting the form only, no sidebars. What have I done differently? Did I accidentally recurse?]

It looks to me like I'm trading one use of the browser back button for three seconds, a modal shift, and a confusing scroll. Still not sure it's worth it. Especially when the overlap between administrating and posting probably isn't that great.

And as for editing content (and see my comments above) I click on the edit tab in the page. Then I get the overlay with the same tabs, just with a different design treatment. Confusing! I don't see the value add. Editing in place would be different and wonderful, but this is not that.

The overlay is not ready to be evaluated yet, this due to the following reason :

1. The interactions are slow and buggy, these are critical bugs I see fixed in the upcomming weeks.

With this in mind I would like to respond on a number of concerns raised in this issue. The value of the overlay is different then the visual distinction that "Seven" brought. The value is :

1. It allows the administrative user to stay in context of his site, this mostly to allow low-level administrative duties to be preformed without losing context.
2. It elevates the user interface brand of Drupal amongst others, this because it introduces a concept of staying in context - without changing the mental model of an administrative interface.

I hope this clears some hesitation towards this module, and also explains that the goals of this are admirable but yet to be achieved.

Please tag issues with 'usability' if you want ux team to take notice. I don't really have an opinion on overlay yet, because like bojhan says it's just not there yet.

I'll ask again: can you give me one good reason that this shouldn't be in contrib?

Generalizing a bit, the overall impression I'm getting from the nay-sayers here is that this is fiddly fragile front-end fluff. This is certainly more a feature of the core CMS, not the core framework. One of the lessons from d7ux is that building excellent UI is hard, maybe harder than building a great framework. Overlay is just one example of the stuff core *must* learn how to deal with on its quest for world domination etc. It's hard and painful, but imo we have to make these kind of things – a framework for building UI – core's problem to solve, not contrib.

(with spinner: one one thousand, two one thousand, three one thousand... )

is this how pageloads are measured? o.O

looking at the code, I don't rly see how it could take more than 400ms more than a regular pageload, 200 from overlay fadeIn, 200 from overlay content fadeIn after the page was done loading

granted, the first time u click a link that opens the overlay, u'll have an extra tiny loading of the js... after that it's cached locally and there should only be those fades

comparing the actual loading times:
a first-time load of the front-page (on a localhost) averages around 1900ms for me (600ms of that was actual document loading time)
a first-time load of an overlay page (I took dashboard) averages around 2400ms for me, including the fades and js files (650ms of that was actual document loading time)

breakdown:
first load time of an overlay page will add about 500ms (400 from fades and ~100 from loading overlay js and stuff)
from then on, it'll only add 400ms

if u think 400ms is too much to live with, I gladly invite u to make an issue to remove the fading animations or make it so that the pageload doesn't wait for the first fade to finish, bringing it down to 200ms

I am on a fence on this: while I value the novel context-preserving idea behind overlay, I feel our D7 overlay is "simple web modal dialogs pushed too far".

This means it's great for dialogs what are small and popup-like (confirmations, formatting hints etc) but for heavy, fullscreen admin task overlay seems too fragile (loading times, nonstandard scroll, hard-to-explain feeling being cramped). Have anybody seen multipage modal dialog what requires scrolling outside Drupal 7?

Looking around it seems D7-like "super-overlays" are not too popular, instead, recent web applications seems to use combinations of in-place editing, live preview, toolbars and split admin panes / ribbons.

http://www.squarespace.com/tour
http://www.edicy.com/tour
http://acquia.com/blog/drupal-gardens-pre-alpha-screencast

CMS UX evolution timeline:

D6--->classic wp/blogger->D7------->squarespace/edicy/gardens

D7 admin overlay UX is a bit more advanced variation (or odd sidestep -- depends how you look at it) of Wordpress/Blogger classic "admin screens / live site" UX but still way behind the smoothness and intuitivity of the advanced webapps in the right of the timeline.

The question is: is d7 overlay advanced variation or odd sidestep? If former, it's all good, let's keep overlay and make it better for D8. If latter, let's disable overlay and fall back to wp/blogger ux what is ok as well, and lets go back to drawing board for d8.

sub

I think I'll open a separate issue for this, since I still believe this should be moved from core, but I've been reading through the D7ux stuff again and rereading the comments here and in other threads and I think I know why this feels so wrong. IMO, the big problem is the "in context" editing of admin settings, since it's not respecting the context of "just administering" or "just building" a site. When I click on the admin menu links in the header or on the sidebar my intention is to go to those pages, in other words the context is admin, not the front page (or whatever other page I'm coming from), so I should be sent to that page. I guess I could see how this might be useful when you are within a content creation form...

Here are some places/contexts where the modal dialog seems appropriate (just some thoughts, and not exhaustive):
- The user login form
- When I am on the front page and click on a block to edit that block and/or its settings
- When I am on an admin page and click on links within that page. So for example, the following links:

• When I'm on the People page the "Add User" or "Edit" links
• On the "Content" admin page the "Edit" and "Delete" links, and possibly the "Add Content" within this content, though I don't think that creating content from the "create content" link on the front page should open in a modal dialog
• Any of the links on the Category, Taxonomy, Appearance, admin pages as well as all of the "Reports" admin pages

Anyway, if this is going to stay in core I really think we'd be wise to have more discussion over where and when it should be used. Since we're so late in the game I hope that we can, at the very least, remove it from some of the places where it is sure to cause current Drupal admins a lot of heartburn and lost hairs.

Can you please name where those heartburn and lost hairs will happen, and why?

Bojhan- have you read through this thread?

Yes, I couldn't find which exact pages this would trouble - combined with why, other then reasons that are caused by technical bugs that are yet to be solved.

Bojhan- I'm sorry, but I can't read the thread for you. If you take 10 minutes and skim it you'll find a bunch of complaints, and you'll get a lot more once more current admins/site builders start using it.

My opinion is that this will most likely be a pain for current Drupal admins, site builders, and people who don't like overbearing javascript. Are you saying that our opinions don't matter? We're not users?

Who benefits? Some potential future user? People who are currently confused that links lead to other pages? (I mean, who ever heard of going to a different page when you click a menu item?)

So, to sum, you are basically going to confuse most current users of Drupal, including non-hardcore developers (i.e. site builders and admins of various levels), for the benefit of some future potential user (who can't figure out how to use the d.o. module page and/or the new update manager).

And, most importantly, can you (Bojhan) or anyone else advocating for this in core point to a single site or application that uses this heavy handed approach to "user experience" (I guess bad experiences are user experiences too)? I've asked about five times here, and can't seem to get an answer.

We build sites for non-technical people every day, and I am constantly advocating for making the lives of site users easy, but this is not going to help. We (Zivtech), and I'm assuming most of the other shops that are out there, are not going to use this, so you're just going to make it harder for people who've decided to build a site after working on a professionally built Drupal site (I was that person 5 years ago, and this would have been really annoying then as well).

#51 seutje quotes and asks:

(with spinner: one one thousand, two one thousand, three one thousand... )

is this how pageloads are measured? o.O

It is if you're a user, yes!

If you're going to default all admin and content creation tasks into what looks and feels like a lightbox, then you're going to get the look and feel of a lightbox, which includes a spinner, and hence both the reality and the perception of delay.

(Now, if the intrusiveness was cut back, so we got overlays from the gear icons for forms only, I think overlays make a lot of sense. But building a page on top of a page? Way too much. And -- to turn this argument around -- a big risk to the Drupal brand.)

@Alex_UA : I don't want to be hard, but I still didn't see an answer to my question? Read the thread, is an suggestion - I did, multiple times now.

Not sure I can answer to your question, as I explained this is indeed a new pattern we intend to introduce - and its new to the web. Makes for a whole lot of bads, but also possibly for a lot of goods - I am not shying away from taking this risk just yet - as explained previously.

I seem to be unable to convince you of it being "all-hands-down-bad" - so I am not attempting anymore :) I believe shops can find the - disable this module link if they desire to do so.

If you could please outline which pages, or experiences within administrating Drupal would hurt from this I am all ears. This is not a personal thing at all, but every new UX element that has been introduced got - "oh my god this is the worst thing in Drupal" yet - so I look for rationale arguments, that we can work on.

#57 Bojhan:

The technical issues are side effects of the design, which is to default all admin and content creation* tasks into what looks and feels like a lightbox. The heavy handed and intrusive nature of the design would remain, even if all the technical issues were solved.

And picking with Alex UA #58, if "preserving context" is the rationale, I think we have a litmus test for when context is worth preserving, and when it isn't. When I'm clicking on a management menu link, that signals my intent to change context. No overlay. When I click on a gear, I have no intent to change context. Overlay, with form only (not complete page) relevant to that gear only. That wouldn't seem intrusive at all.

__________________________

* Using a lightbox for admin tasks makes me crazy. But as a content creator, using a lightbox for content creation makes me want (and I think this is the term of art, here) to kill kittens, for reasons stated above.

So from your argument, I agree that some tasks are more heavy - less context sensitive tasks. Is that you want to apply overlay to some, and not to others?

Given your opinion on lightbox, I agree it can be intrusive - the thing is, whether you like this or not - totally up to the person. We are here to make an assumption, on what most people will like - and although you might not like it, we think most people will. I can't battle - every decision in Drupal core over what everyone likes, that makes for a very inconsistent user interface. I try to make a concise decision from an UX perspective and a community perspective, but as history has thought us - new UX features are criticized heavily.

At the end of the day we need to balance all the people who use Drupal, not just shops, content editors, weekend-warriors, developers - but all as a whole. Thats a very though call, so please don't assume we rush to conclusions - but sometimes we need to take risk to get in a different UX level then we are now.

#60 Bojhan

"I am not shying away from taking this risk."

That's fine, but it's the drupal shops and the current admins and users who are going to be paying the price for the risk you want to take and can't seem to justify. That seems a little asymmetrical to me. And if you want to introduce something "new," that may only "possibly" work, then I think the burden is on you to prove the benefit. There's plenty of feedback on this thread for you to synthesize; I think people have taken their responsibility in filing reports seriously.

UPDATE Can you give me a link to where the "tough call" was made? I'm not hearing the justification on this thread, so I'd like to read it. Thanks.
_______

Incidentally, if you want pages/overlays, which URL do you want? Because there are always two.

#62 Bojhan

#62 is, in substance, #4, which has already been responded to. See moshe at #5.

As for my "opinion" of lightbox... I'm all for lightbox, when the use case is right. It's not a matter of "opinion" that lightbox involves a mode shift and the perception of delay; that is its nature as an application. Those facts lead me to question -- based on my own experience as a user -- the appropriateness of defaulting admin and content creation tasks to something that looks and feels like a lightbox.

@shunting Oke, so what is you want from me? I am totally lost here, I have given my rationale in #49 - just like Alex_UA you dont seem to agree with that? I can't really help that, and that will make continuing this type of discussion futile.

The rest of the application appropriateness, to me seems a more philosophical discussion - and I can refer to my rationale in #49 - that it is indeed a new pattern.

f you feel its irresponsible risk please direct your questions to commiters.

I am out of this issue, I am not going to be part of a yay/nay fight. My rationale is clearly explained in #49 .

Re-Checking the overlay in navigating through admin pages I indeed found something that is very annoying. I described it as "Flicker effect" in this issue: #664450: Heavy flicker effect due to white background rebuilding every time when going to new page within overlay and show it in this short video: http://www.vimeo.com/groups/19583/videos/8294255

When you navigate through admin pages within the overlay, the white background (with all content, for sure) keeps disappearing and reappearing before the dark grey / black background. This is annoying and unneccessary. Sure it is a bit tricky to fix, but should be doable.

I guess that some of the users being on the con side of the overlay relate to that effect. This needs indeed to be ironed out.

A few things to consider...

1) If you are a site builder you are not in the normal content of a site maintainer. These are different roles and a site builder (like someone who works at a drupal shop) who is a maintainer is different from a maintainer who it's a site builder. I wouldn't use the admin_menu module for regular site maintainers or content contributors. It's great for site builders but not others. So, when we discuss who the overlay would be effective for we need to consider the roles it would or would not be good for.

If someone things the overlay would be ineffective for something please articulate how and why it's not effective for a particular role. We need usable data otherwise its empty complaining.

2) Performance is not a reason here. There are bugs hampering performance in the overlay just like there are in other parts of drupal. They are being worked on. There may be a time when performance is a legitimate reason. Since there are performance issues being worked we are not at a point where that can be used a as a reason.

3) There has been a bit of user testing in labs. Usability experts were brought in to give their opinions. We are where we are for a reason. Drupal has for a long time had usability that could use massive improvements. Many of us are used to how Drupal does things. That doesn't make is usable. To make real usability improvements we need to make changes and many of those will be uncomfortable for those of us who know Drupal well.

If we are going to recommend changes from where we are (that includes the overlay being in core) than we need to make a logical and reasonable case with a foundation in something. A case that UX experts can be willing to entertain and can be tested.

So far this thread has provided little to work with. Some good things have been pointed out but they are bugs.

Anyone want to perform some user testing of the overlay? Anyone want to bring a UX expert in the loop to help? Anyone want to provide use cases with a better way and why? Anyone want to articulate specifics of what is wrong with how and why it's wrong that goes beyond our individual preferences in this change?

If someone doesn't want to include the overlay in their default they can create their own install profile and even share that as a distribution. There is no one way to make everyone happy. We are talking about the default drupal install and the drupal download.

To chime back in, I have some more confidence in the performance issues being worked out. I know they can, and I know there are people working very hard on it. It might mean a few sacrifices (box-shadow), but I think we can get the load and scroll performance to an acceptable level.

Going along with the arguments that context of a task effects whether or not the overlay is appropriate, I think that is right to some degree. If I am looking at a list of users and I click to edit one, then the overlay makes perfect sense. I am performing a sub-task. A task where I will likely want to regain my previous context. If I am on a blog page and go to the modules configuration page, I am definitely not doing something that will likely return me to the blog page. I have decided to go do a completely different administration task. In this case, the overlay might not make a whole lot of sense. Ultimately its not stopping me from doing what I needed to do, but the context is a little wacky. Now, determining and reacting to these contexts is a big ole can of worms, and I don't think its something we would be able to get done in D7.

On the issue of Overlay being an opportunity for Drupal to better brand its interface, I think this is a valid argument. Decisions should not be made solely based on this, but we are trying to build a "product" that needs to "sell" better than the competition. We want people to want to use Drupal. Part of that is having a smooth, interesting, "screen-shottable" admin backend. If we can get it to work great, Overlays definitely offer an opportunity to add a little "wow" factor to the default Drupal install.

Interesting discussion. It started asking if the Overlay module should be part of the core, has gone through some pain points with the module, onto the perceived benefits of the module and finally ended up with some posts sort of saying that it's purpose includes better branding of Drupal.

As regards Overlays, I'm with the people that say this should be part of theming - it's to do with look and feel so why is it to be part of the core modules instead of an alternative core admin theme? Is part of the intention here to encourage sites to adopt the same admin look and feel so that content creators know they're using Drupal?

I'm a seasoned developer but a Drupal newbie. For me the "user experience" (UX) encompases much more than how something looks and feels and I have to say my UX with Drupal has not been an entirely plain sailing. Navigating hasn't been a problem - it's what I've (not) found when I get there that's been the primary issue! 14 additional modules and one semi-customised module to implement a very basic site with members and some protected content, and I'm not done yet! Changing how I access the admin pages won't improve that experience.

If the UX team are primarily focussing on the "user interface experience" and not the overall Drupal user experience, then that's a real shame. Most of the posts I've read over the last couple of months are not about how to find stuff in the Drupal admin section, but how to do things that are missing from the core modules. Sure, you can probably find a module that extends the functionality of one of the core modules, but isn't that what UX should be about? The D7UX page says "design for 80%" - how about "code for 80%"?

In software development we have to contend with "release creep" - Drupal seems to be suffering "module creep", where limitations of the core modules means we have to find, review and perhaps customise a variety of other modules to build a working site. That makes for a less than ideal UX! Is there a second UX stream that is focussing on functionality, consolidating contributed modules into the parent core module so that Drupal presents a more complete UX out-of-the-box?

@regisit
While this is not the really the place to discuss this, a lot of what you are talking about has happened and is happening. Just look at this short list of modules that are now in core that you do not need to download every time you make a site:

1. CCK (Now Fields API)
2. ImageField
3. Filefield
4. ImageCache
5. StreamWrappers ?
6. A proper admin theme.
7. An administrative toolbar.
8. I can go on.

Drupal 7 is much much more capable for most average sites now (code for 80%). You can set up decent image and file handling, configure some content types, and hand your site over to the client with a clean administrative area. Anyhow.. back to topic of this thread, if there even is a clear one anymore :)

So to summarise a bit, here is how I perceived the situation around the Overlay.

1. Allow editorial and administrative tasks to be executed without leaving the front-end context of the administrator

\ Usability Studies have shown that "orientation problems" are a big issue.

for new users, it is one step to help with the "where am I" problem, which was the biggest issue through all tests in Minnesota, Baltimore and later. It helps in two ways: by keeping the node you started from open and also by the strong visual distinction through the black color. Also the Javascript effect makes it feel more "temporary" so you get a stronger feeling that the frontend is "your real site". Frontend Users (Content Editors) do not use the admin area a lot.

2. Elevate the user interface brand of Drupal amongst others

3. Follow the principles of:

1. Make the most frequent tasks easy and less frequent tasks achievable.
2. Design for the 80%
3. Privilege the Content Creator
4. Make the default settings smart

4. You will be able to turn the overlay off. There could also be distributions shipping with a deactivated Overlay.

5. There are bugs in the overlay just like there are in other parts of drupal. We're not even in alpha with Drupal 7. You cannot expect the Overlay to be perfect already, especially considering how much the different OS/Browser combinations affect the development. It needs broad and extensive testing which is mainly provided now that the Overlay is in core.

No, scroogie, that isn't a very good summary. Here's my summary:

1) The overlay is a new concept, and as such has many conceptual/philosophical problems that make it (imo) *worse* for usability. There is not another example of this on the web, which it is claimed is due to the fact that we're being "cutting edge" but which I assume is due to it being a really bad idea (at least as it is now implemented).

2) The overlay as a concept is unproven and untested, and has been instituted for the sole reason that some "usability experts" said it was needed and one or both of the core commiters agreed (along with the fact that--lets be honest--a prominent company paid good $ for it). If there was a demand there already would be an overlay behaving as this one behaves in contrib, and yet there's nothing. Why wouldn't you prove this out in contrib (as most modules do) before forcing it upon the entire community?

3) One of the key problems is that the concept of "context" has been handled very badly. The "context" for users clicking on a menu item is that they want to go to that page. There is no "site context", in fact the problem of having no clear differentiation between the back/front ends of Drupal and between content creation/management and site administration is one of the problems this was supposed to address and instead it has made things much worse.

4) The overlay is performing poorly at the moment (and no, it cannot be disabled by users at the moment, except by turning off the module for User 1 and/or turning it off for everyone in the affected role), but that is not the main reason that I/we want it out of core. There are lots of other bugs starting to pop up in the overlay (pun intended), but there are bugs in lots of places. This is holding up D7, there's no question (it's one of the code freeze exceptions, so this isn't really surprising), but so are lots of other items.

5) There hasn't been *one* good reason given for keeping it in core (other than the fact that Dries and/or webchick put it there already), nor has anyone said why it would be so difficult for a new user to use the new admin bar, the coming module page on d.o., and the download manager to install it once they've installed their site. (I can guess why they wouldn't. See #1 and 2 above)

And please, can everyone stop assuming that "usability experts" who came up with a good back-of-the-napkin concept know best here (without some real research/studies--i.e. I want cross-tabs--on its benefit for us to review)? Many of us deal with users of Drupal each and every day, and claiming that we don't know what users want/need is extremely insulting (esp. to those with advance degrees in related fields--my Masters is in communications/psych-- and/or years of experience dealing with users). I don't need lectures on usability- I am on the front lines with users everyday- I need some rationale for blowing up the normal browser "user interface" and putting Drupal's amazing gains for D7 at risk without any clear gains.

Alex UA: I just summarised the bits of this thread that seemed official intentions, reasons and arguments around the Overlay. I'm fine with anyone else summarising the contra position. I thought it would be helpful to collect this as a starting point for more focused discussion. I think you're reacting quite unfriendly to me, although I didn't take a stand at all.

1. Yes, in your opinion it makes things worse. This is also contained in other points, so I'll only answer to the second point: "There is no other example of this on the web". I don't think this is really true. The concept is in my opinion simply that of a dialog window. This is a concept that has been with us since the first desktop GUIs. It's being picked up a lot in Web Applications, e.g. Google Docs. Create a new document with Google docs. If you insert a table, image or any other object, or change the document settings, you're always presented with a dialog on top of the main window.

2. For a usability feature, who else would you ask instead of usability experts?
"If there was a demand there already would be an overlay behaving as this one behaves in contrib"
There is a demand for endless amount of stuff, but not everything is solved in contrib. Otherwise, Drupal core could stop development. Not everyone can or likes to code. Also, some things are very hard to do in contrib.

3. I partially agree with you here. It might need better differentiation. The context is not always needed. On the other hand, I don't see how keeping the context behind the dialog hurts, though, and this is what you should proof if you want to make that point.

4. Yes, it is in development. D7 is in development. It's not even in alpha yet. You can't say it's "holding up" D7. Dries and Webchick have the responsibility to plan and manage the release, and they are doing a really good job with it. They set priorities and evaluate whats worth spending time on, and what's worth extending deadlines. That's normal. There are also caching bugs all over the place. Do you want to remove caching completely now? There are also bugs in the Field, DB and menu API. Do you want to remove them completely to not hold up D7?

5. All the Pro-Arguments are arguments to have it in core. If you have a feature with good implications and someone implemented a fine patch for HEAD, arguments for getting it into core or leaving it for contrib are evaluated. What are the arguments for leaving it out of core?

I think that with your masters in communications/psychology and experience with Users, you yourself would be qualified as a usability expert. You could very well be in the position of the usability experts that you're currently cursing. I don't think anyone is trying to deny you knowledge or experience. I guess that once the Overlay is deemed more mature, there will be usability studies. Why don't you carry out a small one yourself? Perhaps you would surprise everyone with your results. On the other hand, you should be open to the possibility to be surprised yourself.

@Alex UA If you have issues with the overlay please provide more than your opinion. An evidence based case it what is needed. Let me address a few of your points though...

#2, I am aware of 3 contib modules for D6 and have worked on one site in D6 that had it's own overlay system. While none of them were as extensively implemented as the drupal overlay they were used for many different features. The problem of implementing them to the extent the overlay module has is due to the architecture of the implementation. 2 of the 3 have some major flaws and the 3rd needs to have a method setup to manage the admin links.

So, this is a problem being worked on. It's not new. The overlay module in core just takes it to a much more wide spread usage than previously implemented.

#4, there are lots of bugs popping up all over Drupal. This is the time where it's being vetted so it's expected. Bugs in the overlay, unless they are architectural and you can sell a case on that, are not a reason for removal and should just be dropped form the conversation.

#5, this isn't about keeping something in core. The case needs to be made to remove it. The starting point is the overlay is in core. Change is to remove it. Change is what would need a case made.

Think about it this way, the overlay is here in an attempt to solve a problem found in usability testing. It comes from highly respected user experience experts and brings brings a certain branding to D7. If it is going to be removed there needs to be a case made that this increases the existing problem or that the UX experts were wrong and there is a better way to solve the problem. Providing opinions isn't going to be enough to do that. Complaining isn't going to be enough to do that. A case based in testing, expertise, and who knows what else would need to be made.

If this thread is going to be a bunch of people providing their opinions or how it's not like what they are used to then it does not serve the title of the thread and I'll stop following it all together. At this point no one has made a worthy case for it to be removed.

@mfer:

It comes from highly respected user experience experts and brings brings a certain branding to D7.

I haven't read up on the original usability test sessions, but maybe something can be clarified here. As I understand it, the 'loss of context' was the identified problem, not the lack of the overlay system. i.e., The overlay is a new untested idea, created as a response to 'loss of context'.

I think a number of clear explanations about why it is considered to reduce usability have been made (see 38, 39, 40 above).

(As an aside, I feel the argument about branding is a red herring and can be ignored. That it's mentioned sort of saddens me... but that's another issue.)

It feels as if the overlay is being treated as something that exists and works, and we need evidence to prove why it should be removed. Yet, there's no evidence to indicate it should even exist to begin with. All we know is that in the tested version of Drupal 7, there were loss of context issues for users. Shouldn't that be our starting point?

While I'm thinking about it (and, apologies if this has been discussed elsewhere), if javascript is disabled, does that mean we haven't then begun to address the loss of context issue? The point being, loss of context is an interface design issue, not a technology issue. If the solution requires javascript, then maybe the real problem isn't getting solved...?

All we know is that in the tested version of Drupal 7

To be clear, that should be Drupal 6.

+1

Yes, please remove it (to contrib, if necessary)

There's one important interface + usability issue that has been mentioned before and somehow got dismissed, but which was very reasonable, and since people keep on asking for concrete problems, let me quickly re-iterate it:

Duplicate scrollbars

While it is true that there are web applications that heavily use dialogs and overlays, they always use them for targeted forms and interfaces only.

For example, Twitter uses a lot of dialogs. But the content in dialogs always fits into the available size. Hence, no duplicate + confusing scrollbars.
Likewise, someone mentioned editors. The same situation there: The content never exceeds the dialog's size, and if more options and controls are required, tabs are used.
On a similar note, Dreditor implements a very similar overlay. In very early versions, it did not take up the full browser window size (just like the Overlay) and that really was a weird + confusing interface experience due to the scrollbars problem. It now "takes over" the full browser window, but the scrollbars are still weird sometimes.

In Overlay, however, this interface and weird scrollbar behavior seems to be part of the design-decision though - "so users don't lose context". But then again, this premise invalidates itself, because all kind of links are opened in the Overlay, regardless of whether they belong to the same context or not.

Not sure what you are concerned about, but for me it boils down to those two issues: Overlay interface (scrollbars) and only using Overlay for stuff where contextual tasks are really performed (so there is actually a context that could be lost).

Speaking of lost: Another issue that was raised above is that performing actual work in overlays/dialogs always makes a "fragile experience". You never know whether you'll be able to save or whether there might be a JS error. Life in a box, basically.

Lastly, silly question: Why do we have and need a Seven admin theme when it is almost never displayed?

Lastly, silly question: Why do we have and need a Seven admin theme when it is almost never displayed?

@sun — That *is* Seven in the overlay. Change the admin theme with the overlay on, and you'll see whatever shows up. Which is cool — you can totally retheme the overlay if you like. For those of you who love and miss Garland, try putting Garland in the overlay. :P

Props to the team that did Seven, designing it to work both in the window and in the overlay.

Fixing one theme and hard coding one theme for admin very much takes away the flexibility and choices (for which Drupal has been renowned). There should be choice and out of box possibility of adoption of any theme for Admin purposes, the super admin can make enable yet another theme for common end user purpose to offer that much hyped about 'distinction' ( a mimicry of Joomla/WP).

@jensimmons - If I misunderstood you I am sorry. If I understood you, it means a dozen 12 sites develped for 12 clients will be "forced" to have the same admin look, devoid of a variety and a variety that works smoothly.

Admin module and overlay when together has funny, weird and complex buggy situations but since no one was listening to put that module in core, its pointless pointing those.

That logic/argument is flawed. If you just hide any regions from any theme, then any theme's main content area is "suitable" for presentation in the Overlay. Nothing else happens in Seven. Garland works perfectly fine this way, too. My point is that we barely display Seven anywhere currently, because almost all administrative pages are presented in this new "browser in a browser" experience.

That said, the theme region handling that was introduced to support the Overlay leave a very hack-ish feeling behind, primarily, because it probably won't scale. Doesn't necessarily belong into this issue though.

fixing one theme and hard coding one theme for admin very much takes away the flexibility and choices

Yeah, kaakuu, you misunderstood me, and you misunderstand what is actually happening with the overlay. Nothing is hardcoded. Turn off the overlay module, and the overlays are gone. Change the admin theme to whatever you want — and you have *all* the flexibility that D6 has.

Where did you get the idea that Seven has been hardcoded into D7, and isn't easily changed? If anything is *easier* in D7 to change the admin theme, because the setting to do so is presented on the theme page and not in a separate, hard-to-find place.

What I was saying is the opposite of what you are thinking. You *can* use the overlay with any theme you want. Even the overlay isn't hardcoded with a single visual presentation. Make your own admin theme for the overlay. Or use the public-facing theme in your overlay. Or screw the overlay and put a Halloween-black-and-orange theme for your admin. You can do whatever you want.

People — go install the latest version of D7 and try it out! Don't just react to what you read in this thread. Go see for yourself what Drupal 7 does and doesn't do. It is not helpful for people to comment negatively and say no to things that aren't reality.

Let's discuss the real Drupal 7 overlay, not a bunch of misunderstandings about it. The overlay has changed a lot since it's original inclusion in core. Go look at the latest version.

@jensimmons- where is this flexibility you speak of with the overlay? If it is on for your role, you cannot turn it off. If it is on at all you can not turn it off for user 1. You cannot turn it off for pages it makes no sense on (See above). I'm also guessing that this means that you can't even take advantage of the API, if it's worth taking advantage of, without turning on the module.

Here's my big question here: why didn't we just make a theme with black outlines, add in some redirects, and pretend it was was all javascript?

And let me ask you this: why exactly would we be here complaining about the overlay if we hadn't tried it and come to the conclusion that it is not a good module for the vast majority of drupal sites and users? Do you think we just sit around the issue queue waiting for a thread to jump in on and complain?

Let's discuss the overlay, by all means, but please do not tell us that we aren't really seeing what we see. I know designers love to see shiny stuff pop up all over the place, but that doesn't mean that the overlay was designed and/or implemented in a way that will improve usability one iota.

I haven't read this whole thread, seems pretty heated. Just wanted to point out that overlay also breaks the Update manager:
#649224-9: Cannot run certain batch processes (tests, update manager, etc) with the overlay enabled which IMHO is a much more critical UX improvement for the D7 site admins that the overlay is apparently trying to target. I'm organizing an Update manager code sprint tomorrow, and the last thing I want to do is spend the entire day messing with overlay trouble. I have far too many other important bugs to fix, so I'm just going to have to tell everyone at the start of the sprint: "Step 0: disable overlay.module". :(

just installed latest d7, and saw the overlay for the first time. its a bit too ubiquitous. makes me feel like my admin links dont work, in that every time i click an admin link, i expect to load a new page, but the darn thing pops up. i really, really believe the overlay would be fantastic for node edit pages, and perhaps other editing areas, but not for every admin function.

certainly, when i install drupal and i login the first time, clicking "administer" i expect should TAKE me to an admin section, not conjure one from thin air.

i am not a coder, or even a designer, by any means, so speaking as a simple user, i feel that things should popup to perform one particular purpose (alert, display pictures, present a simple form etc), not to present an entire website subsection in a large floating box.

and duplicating the bar at the top in the overlay i hope is only temporary, since it would be ridiculous otherwise.

please, those who have influence, tame the beast. thanks.

How about if we add a checkbox somewhere somehow that only shows up if contextual links is enabled that says "Only open up Edit pages in the overlay" or something like that. That way, it's easy to make it so that node/block/menu/whatever edit pages pop up in the overlay (which IMHO is the only place where the overlay really shines) but any other admin functions just skip the overlay. Seems like that would be a good compromise. Thoughts?

we had overlay- and non-overlay- admin pages before. The problem is: this induces three different views.
1 Front-End-theme
2 Admin pages with overlay
3 Admin pages without overlay

This makes for more confusion than clarity, because the "where am I" issue gets boosted again, since Seven with overlay looks very different from without. In that case a unified look makes for a better UI.

Generally the concept with overlay only for certain screens may be good.

Still: some pages may be opened better in the overlay in one situation, and better not in another contect (say blocks admin page)

Problem 2: with some experience in the issue queue you may have a faint imagination of how much discussion this will cause and how much energy would go into that that is badly needed elsewhere.

The present situation with the ability to switch the thing off completely (anyone complaining about the lacking ability to do this role based also for user 1 go and write the patch, it won't be that hard) is a viable solution.

Any other solution would need an interface to switch on and off overay for every and any admin page (including 4000 contrib modules, I wish you a lot of fun) to experiment with this.

Any kind of start in this direction needs someone to build a functional prototype. Go ahead, show us a working solution that works better than the present situation.

I rather opt on working on the overlay to make it less visually fluffy and more every-day-usable.
http://drupal.org/node/669378

It may be interesting to know whether overlay contributes any other usefulness except 'solving' the "where am I" issue. This issue, to my mind, is
- a much blown, hyped issue, there has not been enough d.org user generated real issue w.r.t this
- test users who may have felt this issue are just test users, not much of real life users (those who hunt for a cms, download it, test it, use it)
- this issue comes from the joomla/wordpress mindset while already a huge population are comfortable with 'drupal' mindset and there is no reason future population will not be

"where am I" could be easily solved with the Admin bar module - that adds a distinct and useful bar for the admin or admin-type users, and almost every other user (who admins a site) downloads and use it.

@kaakuu and anyone else who wants this removed....

First, if you want to discuss the overlay and how it's implemented this is not the right place. The people making changes to it are not going to look this issue over for ideas. This thread is not a meta-issue about ideas for the overlay. If you want to discuss improvements or changes to it please seek out a discussion venue where these are happening.

Second, this issue is about removing the overlay. The starting point for that discussion is the overlay is part of D7. It was designed by highly regarded UX experts and designers with a specific purpose. There was research put in before the overlay was created. If you want it removed you have to make a case based on something other than opinion. It this is just an opinion based thread the words will not make a difference.

I do not like sounding harsh but, a thread of people giving their personal opinions on a set feature and design in place isn't going to change it. The alpha is going to be released in a couple weeks. A case needs to be made soon based on researched evidence and/or expertise that can rival those who created the overlay.

Since no one has done that or attempted that here I'm considering this a dead issue. If you do not like the overlay or it does not work for your use cases than turn it off. You can even create and install profile that does this.

And remember, most of us do not use all the drupal core modules all the time. How often do you use the forum module? Or the color module which is enabled by default?

@mfer I am sorry. I just meant that this is at best removed, and if thats not possible remove to contrib which is the topic of this thread.

I have said my take on the "research". And about what you say on "opinion" - the research on the usability thing is a collection of opinions. How user Joe has opinion about something X is in WP, so it should be here also - just to say an example. I am also an user, and do know a handful of users - based on that I support moving the overlay module.

This and other threads have already made many specific issues why the overlay is best kept away, and your example of color module is a bad one, as this or forum module does not interfere by default the way overlay does.

There is already more evidence than any expert can gather but no one is really paying heed to that, yes - I ahve posted issues on that. The thing is that for Admin jobs people really use the Admin_menu module, nothing can be more practical fact gathering than that - either you have not looked at the usage stats or are just ignoring that. Have a look at the download statistics. Thank you.

PS : Postscript portion edited after getting mcrittenden's confirmation. Thanks.

Re: D7 alpha, see http://webchick.net/node/73

I guess I'm confused as to why UX reports from users on this thread are "opinions".

How are these UX reports different from UX reports from users that are recorded in videos?

Do I really need to post a video of my UX on my own site in order to be heard?

To reiterate, I didn't seek out this thread, I found it. Like others, I found it because I felt that the UX of the overlay was so obtrusive and overbearing that the very first thing I wanted to find out was how to turn it off. Having found it, I documented what I felt was going to be a real problem for my users and, more importantly, for D7. I was under the impression -- perhaps mistakenly? -- that this was how the Drupal community was supposed to function.

And I must say that I'm coming to find the ubiquitous argument from authority (#4, "trust the UX team; #29; "They should be the experts on that so I defer to them", #89, "highly regarded UX experts") more than a little overbearing. As Moshe wrote:

We don't have to "trust the UX team". We can and should test the overlay with real users. I believe that was always part of the plan and I really want us to stick with that.

The history of software engineering is replete with examples of highly regarded experts whose work was ultimately rejected by users, or where users forced changes on the experts. Designing software is hard. So is designing user interfaces. But this issue is not about the UX team. It's about the users -- among whom I number myself -- and Drupal.

(I meticulously read the whole thread)

my user experience:
- I share all the negative impressions described above (not taking bugs into account)
- I can't find any positive impression besides "what a piece of work, they showed off"

Lets fix the remaining perfomance problems, get the alpha out and user-test the hell out of it. UI _can_ change after serious issues found in testing: remember notorious Safari "title bar tabs" what were present in 4.0 beta but never found the way to 4.0 final. But lets get the proof first.

#94 kika writes:

get the alpha out and user-test the hell out of it

Despite several references to videos of user testing that has already been performed (for example, #47), actual examples of user testing seem to be a little thin on the ground. (There are plenty of tests that show problems, but there seems to be very little that shows why overlay is the best solution to those problems.) And the one long video that's linked to here doesn't really seem to be as strong a proof of usability as overlay advocates claim.

For one thing, when you've got a developer stepping a user through an overlay on a site with sitename "drupal-overlay" you're likely to find bugs in the overlay, but I doubt very much that you're going to find the user questioning the rationale for the overlay in the first place -- but that's what a lot of the users on this thread are doing.

For another, I don't see anywhere that overlay has been tested against alternative designs, whether in development or in the wild. It's an issue of opportunity cost; by fixing on overlay to the exclusion of all other alternatives, what are we losing? It's not enough to say "It works"; it's not even enough to say "It's better than what we've got" (and many question this*). What would need to be shown, and has not been, is that overlay is better, as a UX, than alternatives. Typically, that evaluation takes place exactly in the contributed module space; the best survive and adapt, and the others are abandoned. (Which is why overlay should be contributed, and should not be in core.)

Looking at this thread from the outside -- and I would be very glad to be wrong on this -- it looks like this process of due diligence has never taken place, because the process was optimized to bring overlay forward, to the exclusion of whatever alternatives would have evolved as demanded by the community. Was it Donald Knuth who said, "Premature optimization is the root of all evil?"

* I've started using Seven for context shifting; in combination with the dashboard for the links I use the most, it saves me steps and doesn't feel fragile.

Define Users. You'll find there are several categories. There are site builders who like tools like the admin_menu. There are content maintainers, too. These are different than site builders and admins. There are content viewers who are different as well.

When you define users they need to be put into buckets and how the overlay affects that group.

The overlay, as I understand it, is there to help the content contributors and managers. This is a different user group from site builders and admins with different needs and a different way to target those needs.

If the issue is with site builders than the argument can be made to turn it off for user 1 or some other role site builders are busing. If the issue is with site admins than the same argument of a by role setup can be asked for. This does not mean the overlay needs to be removed but the target user groups needs more refinement.

I think of the overlay the same way I think of the wordpress admin area. The admin area is usually used by bloggers (content creators and content managers) and is targeted in that way. The same thing applies here.

So, what user story for that of a content creator/manager sees the overlay as being bad UX and in what way?

I'd suggest anyone wanting to make a case against the overlay take a little time to read the history, user stories, research, and opinions of the UX people who have come before. That will help in creating a useful case to have it moved to contrib.

Personally, I'm not sure I'll use the overlay in the sites I build. I have yet to make up my mind. But, I have not seen a compelling case to remove the overlay from core.

mfer writes:

I'd suggest anyone wanting to make a case against the overlay take a little time to read the history, user stories, research, and opinions of the UX people who have come before. That will help in creating a useful case to have it moved to contrib.

Links, please. I've been through the links suggested by overlay advocates on this thread, in particular the only video given. And I've looked at the Baltimore material, but that's about problems, not solutions.

So, I don't mind educating myself, as you suggest. Where would you suggest that I look? Thanks!

This is a little bit off topic but I've always wondered who takes this kind of decision (in this case moving the overlay to contrib or not). Is it Dries? the core committers? Let's say that a bunch of users and developers want this to happen who do we have to "lobby"?

@dodazzi: in most cases, if the community more or less comes to a decision, then Dries/webchick will go along with it (unless it's either too late or they just have some overwhelming opposing opinion).

if the community more or less comes to a decision

Probably "community" means here those who participated in such a particular issue thread.
A majority of forum posters and posts are possibly not taken into account as Drupal despite being a CMS there seems no way to manage/filter/sublime those posts or community thoughts and ideas. Not criticizing at all here but just stating a fact.

Sometimes the "opinion" in an issue thread is clear, sometimes it is blurred. Since there is no poll or points, that is, no statistical count taken (this may be the policy, not criticizing, just stating a fact) the blurring remains blurred and confusion remains how the decision was taken. I had such experience with at least one issue, the issue with the Admin_menu module where apparently even if the community wanted (ref: actual download stats plus forum and issue threads) it was not adopted in core but the overlay was.

> And please, can everyone stop assuming that "usability experts" who came up with a good back-of-the-napkin concept know best here?

I would be interested to read initial proposals for overlays. I assume the UX people explain their reasons for proposing it, such as the benefits.

My opinion is that overlay (along with toolbar) is going to get disabled as the first thing I do on any new D7 install, and therefore its move from core to contrib seems like a good idea. But I am prepared to be convinced otherwise.

kaakuu: This is true. Such a system to comment and vote on ideas could be a sensible extension of the D.o infrastructure.
Examples that come to my mind:

KDE's brainstorming: http://forum.kde.org/brainstorm.php#cat83
OpenSUSE's OpenFATE: https://features.opensuse.org/
Ubuntu's Brainstorm: http://brainstorm.ubuntu.com/ (based on Drupal?)

I would still like some links to the UX proposals and design documents, or at least something other than the argument from authority that would explain why overlay is the way that it is. When all the bugs are gone, what would we test against? What are the expectations?

I mean, mfer at #96 says "Define Users" (all of whom have stories). But wouldn't that be written up somewhere as part of the iteration that brought us where we are?

I looked at the following URLs:

http://groups.drupal.org/node/11011
http://groups.drupal.org/usability

http://www.d7ux.org/?s=overlay
http://www.d7ux.org/d7ux-initial-concepts-direction/
http://www.disambiguity.com/d7ux-user-research-usability-testing-propose...

And:

http://buytaert.net/search/apachesolr_search/overlay
http://www.webchick.net/search/node/overlay

And I'm not seeing what mfer calls for. Am I missing what's right in front of me? Or do I need to look somewhere else?

@Shunting - "Define Users" was done somewhere in D7UX project. However, in reality in our current scenario there are 3 main classes of users - only the second of this has many 'buckets'
These are -

I wonder if anything new has been done for the last class.

The MAJORITY of the class two users in the above classification actually use Admin_menu module - download stats say so and see also this issue - http://drupal.org/node/543914

So I think you are not missing anything which is not there. If this is one of the decision that is taken at "overwhelming opposing opinion" level (quote:mcrittenden) perhaps you need not look much at "somewhere else" and waste your energy :)

please check out the latest version of Drupal Head, then apply this patch http://drupal.org/node/669378#comment-2424806

This is working on getting a compromise between having an overlay and not getting it too much in your face.

I think the screen shots make the overlay look nicer, which is a good thing, but I don't think that opacity and width have much do with the issues discussed on this thread, which are more about the mandated interaction with the overlay as such, rather than its appearance. Can you elaborate on the rationale for the patch?

Well, without reading through the entire thread, the things the overlay is accused of are as follows:

1. It slows down loading time and shows a spinner while doing so

2. It adds unneccessary visual fluff where most people just want a plain page

3. It confuses the user by mixing up two windows because the frontend site shows through in the background.

There are issues that treat problems with losing data, but these are treated here: #655388: Many ways to lose data on form input in the overlay
Any other bugs are treated like bugs that belong to general D7 debugging. If I forgot something important please add that.

1: Thanks to the excellent work in #655388: Many ways to lose data on form input in the overlay I hardly see the spinner anymore, the overlay is reacting very fast. So I see this as solved. Especially as there are always loading times on the web and you do not expect Drupal to be able to react in nanoseconds. Calling the pages without overlay also has loading times.

The patch treats 2. and 3.
If you would create a dark grey background for the seven theme and not use an overlay at all, this would pretty much look the same. The "visual fluff" is limited to some fading out and fading in, that is done pretty fast. Scrolling is also fine now. This is nothing compared to the extensive animation e.g. Lightbox2 does when opening images.

The background frontpage site is only faintly shining through so you hardly see it. Thus it does not distract you. Also the increased width of the main content covers much more of the transparent background and makes it less distracting.

Together (I guess we can improve performance even more) this looks hardly different from going completely to the admin page without overlay (given the black background) but keeps the advantage the overlay taking you back to your starting point when you close it, which is the biggest win of the overlay. So it could be the best of both worlds.

#107 writes:

Together (I guess we can improve performance even more) this looks hardly different from going completely to the admin page without overlay ...

Which is good work, except that we already have the admin page that the overlay is coming ever-increasingly to resemble as the bugs are ironed out. Why the redundancy? To which the answer is....

... (given the black background) but keeps the advantage the overlay taking you back to your starting point when you close it, which is the biggest win of the overlay.

But this begs the question of whether the context is worth preserving in the first place. "Not reading the entire thread" might cause this to be missed. Alex UA at #54:

IMO, the big problem is the "in context" editing of admin settings, since it's not respecting the context of "just administering" or "just building" a site. When I click on the admin menu links in the header or on the sidebar my intention is to go to those pages, in other words the context is admin, not the front page (or whatever other page I'm coming from), so I should be sent to that page.

Exactly. At least for the admin pages, a new context is what is desired. There is no context worth preserving. I'm just as likely, after completing an admin task, to want to go forward to some new task, rather than backward to where I was.

And that's before we get into the question of whether overlay is good for content creators at all....

It's not an issue of bug fixes. It's an issue of the premises of the module, even if all the bugs were fixed. Along with other users on this thread, I've been rolling along quite happily with seven to tell me when I'm doing admin and when I'm not. And if I want to restore context, I've got the back button and history.

NOTE 1 I'm accepting the idea here that "the biggest win of the overlay" is context-preservation. But again, there's no documentation of what a "win" would look like that I can find, or that overlay advocates have as yet delivered. Nor are there any user tests that validate the claims (except for people posting on this thread, which seem to be ruled out a priori as "opinions.") Can somebody help with this?

NOTE 2 On speed: There are two issues with doing admin chores in a lightbox (#39). One is performance (the spinner, and I'll wait for tests on that). The second is the modal shift. To repeat, with a lightbox there's a clear win that's visible to the user: From a thumbnail to a full-size image. With overlay, there is no such visible win. So the modal shift takes my attention and creates a new page... Why? Surely (see Dries at #34) unproven benefits are bad, even if they don't impact performance? They've got to be coded, documented, maintained, supported... And for years.

I 100% agree with shunting's drill-down in #108.

It clarifies what has been mentioned earlier. Without limitation to contextual actions, Overlay is a web browser in a web browser. Something no one wants, because we have Firefox, Safari, Opera, and others for that. This leads to a unexpected and unintuitive interface interaction, and Overlay gets more often in the way than to solve an actual need.

As of now, all of the current bug reports are trying to solve this underlying problem somehow, but in reality, we are fixing the triggers, but not the cause.

Usability experts include Mark Boulton and Leisa Reichelt. They were hired by Acquia to work on D7 usability and specifically target high level issues rather than small things. Whether you agree with them or not they are considered experts in this area.

Going through this process they did quite a bit of research. Some of it was to find people complaining about usability on twitter and seek out more detail. Some of it was in usability testing with test subjects. I can't remember where this is detailed out.

They attempted to figure out the Drupal audiences. You can see them at work at http://www.youtube.com/group/drupal7ux#p/a/49/_Al-0nUNARc. OH, and much of the initial work they did on paper. Being design (and design by committee being a very bad thing) they attempted to do the design with the community. It was lead by them with much of the work being done offline. This is normal for design.

Anyone coming in at this point needs to be respectful of the work that was done and the people who did it. That means watching the videos on youtube.com about this and reading up on d7ux.org. It means finding the old posts on Leisa's blog and learning them. I wish I could provide more detail about where to go to find the info. Much of it I learned in IRC.

As for what goes in Drupal core, that is Dries call. He has said no to some things and yes to others. He has delayed some things for a version. Some parts have needed to be lobbied to go in. Webchick defers to Dries on anything major. In this case Dries wants the overlay in. He made it an exception to the code freeze as it was not completed when the freeze came and went. He has talked about this going in for some time.

So, for this to be removed from core a great case needs to be made. One that will change the mind of the project lead who wants this in Drupal 7 and has gone to great lengths to see UX change in D7. His company put money out for expertise the community would not have otherwise been able to have and he gave it exemptions to code freezes so it could go in.

I am not for or against the overlay being in core. My mind is not made up on using it or not. If I choose not to use it I will simply turn it off. If I choose not to use it I don't care all that much if it is in core. There are a number of modules in core I don't often use. This would be another one.

If you do not like it you can turn it off. The case needs to be made to remove it because it is bad for those who would use it.

Especially as there are always loading times on the web and you do not expect Drupal to be able to react in nanoseconds. Calling the pages without overlay also has loading times.

Still, the browser says the page is loaded and you "experience" the page itself telling you to way a little longer, which is not what users are used to experience unless there is a substantial gain like lightbox does giving you an "advance preview" instead of a full sized image which would take longer to load.

also there is the "expected experience" when clicking a link

People who are currently confused that links lead to other pages? (I mean, who ever heard of going to a different page when you click a menu item?)

moreover the feeling about being caged/sandboxed

neither of those are bugs, but UX flaws

mfer #110:

The argument from authority ("Usability experts include...") has already been answered (see #5), so I won't repeat. To be clear, there are many UX improvements in D7 that this real user is ecstatic about. Overlay is not one.

Thanks for, at last, the link to the YouTube from March 9 of last year. (Since videos aren't searchable and content within them can't be linked to, I really needed someone to help.) I don't see anything there that shows me why the overlay I'm seeing now is a 'win.' I did see two very creative people talking about how kids will "mix and match" what they're playing with. That seems about as far from a "browser within a browser" (sun) as it is possible to be.

Again I ask: What is the clear, visible, demonstrated benefit from overlay? In a change of this magnitude, that everybody is going to have to live with, for years, it is for its advocates to make the case (see #63). If there ever was a good case, this should be simple: Give me the link to where the case was made!

NOTE The "his company put money out" point is an argument from "sunk costs" (here, the money that was spent in development). Humans are very often reluctant to let go of sunk costs, often to their detriment. Seth Godin:

The most important decision-making rule you learn in business school is still largely misunderstood.

When making a choice between two options, only consider what's going to happen in the future, not which investments you've made in the past. The past investments are over, lost, gone forever. They are irrelevant to the future.

You have two pieces of land. One you bought for $1,000,000, one for $10,000. On which one should you develop a gas station?

I know. The one that's right next to the huge subdivision being put up, not the one next to the condemned shopping center. Does it matter how much the land cost to buy? No. Not at all.

The argument from sunk costs is no stronger than the argument from authority. Why are we putting something into core when there is no good case to be made for it? (Maybe the case is out there -- on chat, or on IRC, or in a video, some other than drupal.org. If so, I'd like to see it!)

So, where are the people saying "I love the overlay and it has to stay"? I am not hearing that, even from the consistent supporters.

1. Boyjan #49: "the goals of this are admirable but yet to be achieved"
2. kika #52: 'I am on a fence on this: while I value the novel context-preserving idea behind overlay, I feel our D7 overlay is "simple web modal dialogs pushed too far".'
3. mfer #110: "I am not for or against the overlay being in core"

Please don't quibble with my quoting. The pattern is pretty clear across this thread. If someone loves the overlay, please speak up. The lack of love is an indication to me that it needs to cook some more before shipping as an enabled module in default profile. I'd prefer it to ship disabled or in contrib.

If you do not like it you can turn it off. The case needs to be made to remove it because it is bad for those who would use it.

@mfer - of course we can all disable the module. its a touch insulting to suggest that as a solution to our concerns. many of us have dedicated many hours to this project and we care deeply about the out of box experience. we don't use the default profile, but its contents matter deeply.

shunting #112

Since we are going round & round, I will try to say for the last time

See this. The UX "experts" were not familiar with something as complex as Drupal and,imho, their efforts were thus not fruitful - not being anyone who is just "coming in at this point" but having 'read' through all those videos and posts while making #543914: Administration menu or admin_menu should be in core, as far as I remember the videos or the 'works' they did were much debated and not agreed at several times, neither the community here was exposed to those nicely as they were a scattered all over the net. And, even if you have shot a video it may not prove an issue always.

That said, in short, you keep on asking for something which is not there. See #99 mcrittenden above. I think that's the crux.

@moshe I mean no disrespect. The topic here is to consider moving the overlay to contrib. Dries seems to be behind this being in core and enabled by default. I wonder, what could change his mind?

@shunting a benefit of the overlay is, as noted earlier, "We see the overlay as a fantastic way to provide a clean interface for these tasks whilst keeping the user in the context of the site for which they are performing those tasks, rather than taking them away into an ‘admin section’." (http://www.d7ux.org/d7ux-initial-concepts-direction/)

One of the design principles was to "Privilege the Content Creator".

Can anyone show that the overlay is detrimental to keeping the user in context of the page they are on? Or, can someone show how the "content creator" is less privileged?

@kaakuu the admin_menu module serves a different user group than the drupal toolbar. It's great for site builders and advanced admins. But, typical site users are content managers and the admin_menu module is not for them. Different user groups. I would not use the admin_menu for the content managers of a site.

The work the UX experts did were hotly debated. This is in part because they called for change. Partly because the drupal community is a mass majority devs and not UX/Designers. Partly because of who the UX should be targeted towards (Leisa blogged on this one). And, partly a lot of other issues. It was due to be debated and I'm not sold.

But, Dries seems to be sold enough for it to be included in core and enabled by default. The topic here is to move it to contrib. Moshe put out the idea of it not being enabled by default. One of the nice benefits of an alpha coming out in a couple weeks is the overlay will get some mass usage from a larger group. I'm hoping that usage will make some things more clear within the UX and the overlay.

mfer #115 writes:

[A] benefit of the overlay is, as noted earlier, "We see the overlay as a fantastic way to provide a clean interface for these tasks whilst keeping the user in the context of the site for which they are performing those tasks, rather than taking them away into an ‘admin section’."

A repetition of points made and answered. See here on context that is not worth preserving. Anyhow, if "a browser within a browser" isn't a separate admin section, I don't know what is. And note the point on sunk costs. Do you agree?

"Lisa blogged"? Got a link? It's like Moshe's asking "Where's the love?" and I'm asking "Where's the case?" and we keep not getting answered...

NOTE Regarding the oft-repeated argument from authority: Here's the definition. It's another consistent theme on this thread.

mfer #115

the admin_menu module serves a different user group than the drupal toolbar. It's great for site builders and advanced admins. But, typical site users are content managers and the admin_menu module is not for them.

For whom is the default Drupal shipped? I am not sure but I think "Site builders" could enable overlay if they think that suits their sites' "content manager"s :)

This page says the following and I, like many, whole-heartedly agree with it.

It's (Admin_menu module) a helper for novice Drupal users coming from other CMS, a real time-saver for Drupal site administrators

So clearly different people have different ideas/opinions/inferences - in such situations many software (see#102) have more reasonable ways to sort out things. But I am not arguing, just stating some facts again.

Usually in clinical trials, tests or subject groups are divided into two (or more) blindfold groups. Regarding the "nice benefits" you say, imho, the really nice and proper scientific benefits would be if there were two alpha flavors - one with the overlay and one with admin_menu module.

Seems to me that the argument for adding admin_menu to core should be a separate issue. This issue is about moving overlay to contrib. As previously mentioned by another commentor, I'm not at all sure the overlay.module and admin_menu.module is a correct comparison. It would seem to me that the the toolbar.module and admin_menu.module would be the correct comparison. Unless I'm missing something in that respect. Which is always possible.

I disagree with the idea that drupal should have two separate versions (alpha or not) or a major version of drupal. That would cause mass confusion I'd think. I'd also disagree with another install profile which essentially adds a single module.

note: I use admin_menu religously.

VM #118

"argument for adding admin_menu to core should be a separate issue" - I agree fully. It arose as a side-discussion, and perhaps, as a secondary point why overlay should be removed when we already have something better.

Drupal should have one version for sure, but when you do scientific tests often there are blindfold groups testing two things separately. Whether we want to extend "UX expert" tests to "scientific"tests is another issue, may be.

I use admin_menu religously.

Noted :)

yes, please keep admin_menu out of here. It's not in D7 core, and won't be, and perhaps that's good, because it goes far beyond imagination. I made sure that D7 allows it to work in the way we want it to work, which was quite a pain, but is finally done (some stuff could be back-ported to D6 to make it finally work).

Attached patch solves this issue.

@#120 +1

PS: also I vote in favor of moving it to contrib

Everyone that has a little experience reviewing javascript patches... please please please help to get those overlay issues fixed that prevents you making up your mind.

I don't know if this is the right place to discuss about usability, but doesn't the "overlay" breaks the "back/forward" browser navigation?

Maybe we'll find out that overlays are bad, in which case we can remove them. But we don't know yet. A handful Drupal experts (that I respect greatly) complaining about the overlays does not justify removing the overlays from core. We know for a fact that not having overlays confuses the hell out of new people (watch almost all of the usability testing videos), and the overlays were specifically designed to avoid that. We'll have to do more user testing to figure out what to do with the overlays. For Drupal experts, like those in this issue, it is easy enough to disable overlays. Talk is silver, actions are gold. Testing and improvement the overlays is what we need to do first.

#123 there is already a patch for that in the queue

Dries #124

Videos may be "fabricated". See this. Are there videos that show overlay eases confusion, where videos were made by a different expert group on different (global location-wise) set of users ?

Rather set up two set-ups online, rather than closed door labs, test with current users, new users, all sort of users - online tests can broaden the scope of "test"s and then take a poll (see #102) to see which was liked better.

Edited - added this: there seems to be much ado on the link I posted. What I said is a "may be", not always - and this was said by someone else here, I posted the link only, which suggests that video results can be at times "tuned" to what the person taking the test personally believes or the belief he is purchased to and wants to promote. This does not mean it happens always but it can happen sometimes and we should be on alert for that.

These videos show that Drupal 6 is unusable. They don't show that overlays improve usability, but overlays were designed and implemented to address that confusion. We need to do usability testing to make sure that the overlays accomplish their goal. However, we know for a fact that not having overlays is very confusing for people.

Dries #127

Thanks. This means there will be actual real-life (not just test users) usability tests (if it is broad online then better) plus minus a poll before the overlay goes in the final versions of Drupal 7. So this overlay is sort of a trial ? However, we also know for a fact that such an overlay as is now in Drupal is not used for administrative or similar task in any other web script or similar software. So this is confusingly new instead of an easy known thing from the beginning for an user.

This post contradicts videos that show that Drupal 6 is unusable. An unusable product cannot get so much success!

#125 : Thanks VM, that's good! A lot of users uses back/forward buttons while navigating :-)

I think the overlay is great - just needs some (more) love.

One thing that gets my tits up is that I completely loose the ability to use the web browser in the same way that I do for every other site out there. 90% of the time, I Ctrl+click on links to open them up in a new tab whilst keeping the original page in the previous tab. However, with the overlay enabled, ctrl+clicking on a link in the toolbar does result in a new tab with the overlay, but also pops up the overlay in the original tab (Id rather the original tab was untouched since I have specifically asked for the content of the link to be opened in a new tab). Ctrl clicking on a link whilst already in the overlay does nothing (no new tab) forcing be to navigate through the admin pages in a liner fashion - which I hate.

IMO, If Overlay issues (like the one I just described) can be addressed and fixed properly then I think overlay should stay in core. If not, it should be removed.

ps. Is there already an issue for the problem I briefly described (strange Overlay behaviour when using browser tabs)?

#668104: Make overlay respect other click handlers

@kaakuu there has been a lot of usability testing on D6 inside formal usability labs. One example is the testing done at the University of Baltimore. This highlights the problems we are having and this happened long before the d7ux efforts. Basically, we have known there is a problem for a long time.

Dries pointed out the Drupal is unusable and you point to the success. The question is, unusable for whom? Which target audience? Where is the success of Drupal and where is it being driven to go?

As someone who builds Drupal sites I'm not a fan of the UX for the people I had sites off to. It takes work on my part to bend it to something better and there are limitations that shouldn't be there.

#124 Dries writes:

We know for a fact that not having overlays confuses the hell out of new people (watch almost all of the usability testing videos)

Do we really know that? The usability test videos show that D6 has big usability problems. But are big usability problems and "not having overlays" the same? [UPDATE No dries #127]

#124 mfer:

It's the same point as above. D6 has big usability problems. I've very grateful for many other UX improvements that have been made. However, the fact that D6 has usability problems does not imply that overlay is the (or even a) solution to those problems. That's like saying the solution to rain coming in the window is to nail a piece of plywood over the window instead of just shutting it, putting up a curtain, checking the gutter outside to see why it's not working, etc.

#123

Do we really know that? The usability test videos show that D6 has big usability problems. But are big usability problems and "not having overlays" the same?

Dries already answered that in 127:

These videos show that Drupal 6 is unusable. They don't show that overlays improve usability, but overlays were designed and implemented to address that confusion. We need to do usability testing to make sure that the overlays accomplish their goal. However, we know for a fact that not having overlays is very confusing for people.

@shunting the testing found certain characteristics about the usability issues. You'll need to read the reports to get those. The overlay was put in place to help solve some of those. Without the overlay some of those issues found in testing are still present.

#135 "You'll need to read the reports..."

I would love to. Link, please.

@shunting plz don't update your posts all the time. We won't be able to know what you changed...

#134 Thanks, yes. I updated my comment to reflect that. Now for more coffee ;-)

#137 Casey, roger that! Ciao!

mfer #132

Thanks. I read that before. One interesting thing, did you note, that the number one in that list is "WYSIWYG in core". And for that neither Baltimore should have been needed nor the wait till Baltimore would have been required, if we are paying heed, listing, sorting what the users here have been crying in forums, issues etc from a long time ago. We have the wealth of info on user/UX needs from actual user usage and user posts. If its difficult for Drupal as a CMS to sublime those, easy feature-needed polls or idea polls could have been done. Collective expertise is at least not worse than a handful of "experts". I have seen buddypress do that nicely and its not a shame.

University of Minnesota also did usability testing and came to many of the same conclusions as University of Baltimore. Many of us have learned to work around some of Drupal's quirks. In some cases grown to love them.

Saying that drupal needs a wysiwyg editor is fine. Yes a percentage of users have been hollering for it for a long time. It's not like drupal can't utilize an editor. HOwever can it utilize it effectively? To ship with core an editor needs to be GPL and work correctly under all circumstances in core. None of them do in my testing and reading of comparison documents already created. ckeditor may become the first but that editor for all intents and purposes is a newborn. I don't know much PHP code at all, have less experience with javascipt and databases baffle me. That said, it's easy for me or anyone who doesn't write a line of worthwhile code to want a specific something without understanding the amount of work involved in bringing that something to fruition.

I'm not at all sure that 51% of the vote dictating through polling what the .01 - .02% of the community who develop core should work on is a way forward. I'm just not sure that would allow devs to have any fun or be interesting to them nor allow them to use their skillsets in the way that makes them want to work on core. In turn that could increase the likely hood that those features don't get completed anyway. Though I've no statistical data to back up that theory.

51% of the vote also makes me leary because thats how crappy leaders of countries get elected and usually through voting manipulation. : ) Though that's another story .... or is it? : )

Dries (and others) trust the data that he (they) have seen from the usability tests. Dries (and others) trust the individuals working on the project in every capacity, including DUX. It's a little saddening to me to see his (their) judgement being called into question while they are working so hard at trying to make Drupal better. Maybe not better for you, or you, or me but for someone.

It's similar to slaving away in the kitchen for a loved one trying to cook them a meal to remember and when they walk in the door they ask. What the hell is that nasty smell?

@shunting Please read up on the history of our usability testing or watch the many videos (example: http://buytaert.net/usability-usability-and-usability). There is a lot of hard proof that users are confused about what is the front-end and what is the back-end. At this point in time, overlays are our best solution to address that, but as indicated, needs more user testing. If we come up with a better solution, great, but we haven't to date.

@kaakuu Let's stay on topic. We've always listened to our users, and we'll continue to do so. I've organized idea polls and feature ratings at the beginning of every major release cycle and will continue to do so. It's just that no one stepped up to submit a WYSIWYG editor for inclusion in core. We did, however, made some improvements in Drupal 7 to help improve support and integration of the various WYSIWYG modules. Either way, this is off-topic for this issue.

VM #141:

It's a little saddening to me to see his (their) judgement being called into question while they are working so hard at trying to make Drupal better.

Really? I think that's encouraging. Drupal would be nothing without it's engaged and active community, and it's that community's responsibility to be a PART of Drupal's development, not just a group of spectators happily accepting what the leaders have said. That sounds less like open source and more like a dictatorship to me.

Maybe the overlay will prove to be crap, and maybe it will prove to be the most innovative thing content management has seen in years. But either way, it's our job to criticize it, abuse it, tweak it, break it, etc., until there's a clear decision to be made. That's the stuff that makes open source go round.

What Dries said. Please also keep WYSIWYG out of here. We are working on a core-worthy solution already and you can support that effort, if you want to see it happen earlier. I'll personally blame anyone who tries to put a single editor into Drupal core, for a multitude of reasons.

I guess we can stop following up in this issue until we have new usability testing data.

I thought having the new admin theme was our best attempt at distinguishing the frontend/backend since it's enabled by default for admin pages. It seems to me that we're trying to solve this with two concurrent solutions then, and IMHO only one should be enabled by default. I'd be fine with just removing Overlay from the default profile.

@143, break the module, I'm suggesting to try to avoid breaking the spirit.

per #142 and the desire to get this issue back on track. I'll bow out.

@Dries- I think we all understand and agree that there is confusion as to what is back-end and what is front-end, which is why an admin theme is a great idea. What I don't understand is how pushing every Content Creation, Content Editing, and every type of Administrative task into a lightbox does anything to solve the problem. I'm with sun in #109:
As of now, all of the current bug reports are trying to solve this underlying problem somehow, but in reality, we are fixing the triggers, but not the cause.
I know that this was done to improve the concept of "editing in context", but do you have any proof that it does help here (or at least doesn't hurt usability)?

I appreciate that you're saying that the overlays will be tested, but here's are my questions there:
- Are you/we going to define "in context?" Right now there is not much sense of context, since every single admin/content action takes place in an overlay. I find the lack of discussion around this in the original threads the most alarming, and the arguments for why overlay helps to be lacking. Kpander pointed to the logical fallacy of one of the main arguments in favor or overlay in #75 above:

As I understand it, the 'loss of context' was the identified problem, not the lack of the overlay system. i.e., The overlay is a new untested idea, created as a response to 'loss of context'.

- What types of users will you test?
- What alternatives for addressing the in-context-editing will be considered? (i.e. we also didn't have an admin theme or the admin module in D6- so it's possible that a lot of the problems are already addressed elsewhere)
- If one type of user gets a usability gain from the overlay, but two types of users find it less usable, will you ignore the detriment to the other two groups for the benefit of the first group?
- If during testing you find that the concept is solid, but the implementation needs a good deal of work, will you hold up Drupal 7's release in order to fix the issues that arise? If so, by how much?

And last but not least, can anyone please tell me why it would be such a hard thing for someone to use the DL manager (which overlay currently brakes) to download the overlay from contrib? If it's as good and needed as its proponents claim, then users can simply download and install it through that interface without much trouble at all, right?

Anyway, we (Zivtech) are willing and able to help out here, but until Sun's point in #109 is addressed, I'm not sure exactly what we can do to help (atm we've been adding preferences to disable it in certain spots, so that it's a little less overbearing).

@#141 nice point(s) for those who might come across this thread,
but I guess/hope most of us discussing the entitled issue are aware about how Drupal born and grew.
I don't (want to) interpret none of the above comments as questioning the "lead" (though the UX experts/tests have been questioned which is probably wrong as well)
Nevertheless, this is what is also called (and sometimes appreciated) feedback.

The final call about "core or contrib" has been made, confirmed and reconfirmed.
I guess this horrible thread (in the meaning of counter productivity) can be put away.

A fresh new issue might be opened if it worth something to discuss about not having overlays by default
(which might end up being the same heated discussion and shouldn't be afforded)
IMO, reasonable defaults should be provided to spare time-consuming configurations,
probably the reason why the "expert profile" is being provided, meaning "if you know what you want start from scratch"

@#145, #147 I'm with you, but this thread already got involved the VIP devs behind the decision and they stand their ground.
We might still want to hear good foundations from UX experts/tests to justify why overlays would solve the "in context" or whatever other reasoning might be debatable, but this is already a pretty dead end to the "move to contrib" or "take out of default profile" requests

Who of you guys is going to use the default profile when building a website? I know I am not... I am also pretty sure I won't be using overlay. But when this overlay helps beginners use Drupal, I think we should provide them a stable solution.

Lot of good questions in #147. Some of them can't be answered yet, some of them are not specific to the overlay (e.g. the context related questions are not overlay specific, they are also related to the administration theme). Anyway, let me re-summarize my current state of mind:

- I'm giving overlays the benefit of the doubt so it can mature some more. We're not throwing out overlays with the bathwater because we know that not having overlays is problematic. We should do user testing on the overlays to see if they address the critical confusing that new users have.

- We should focus our energy on fixing the remaining bugs in the overlay, and trying to clean up the loose ends. We've made good progress lately and more progress can be made. If you want to help, help make overlays work for you.

- Some features are not for everyone, and that is OK, as long we give people choice (i.e. the option to disable the overlay). We can choose to disable the overlays from the expert profile (if not already).

arhak I agree that 99.9% of the thread is constructive feedback. It's the .01% that concerns me when it elludes to the data collected through the UX testing as being manipulated or fabricated.

> http://buytaert.net/usability-usability-and-usability
> "How do I see the difference between the CMS and this site I'm making?"

There is none.
The lack of a split between front and back ends -- or rather, the way that editing pages appear within the main site theme -- has always struck me as a good thing in Drupal, and one of its strengths over other CMSes. The way that Wordpress (for instance) requires you to constantly switch between real site and back end with is rather annoying.
Perhaps we should conclude that the users flummoxed by this in the tests were too used to bad CMSes?

And like Alex UA says (#147), overlays is not necessarily the right answer to this problem anyway.

I'm not saying it is the right answer. I'm saying we need to do user testing. Please read my comments carefully.

It's also a very complex answer; there may be other, simpler answers. We are expending a lot of resources on getting this to work.

#151 "elludes to the data collected through the UX testing as being manipulated or fabricated."

Agreed that's just wrong. To be crystal clear: When I ask for links (thank you, dries) it's because I want to understand the primary sources for the baseline against which overlay is being evaluated, and not for any other reason.

I've organized idea polls and feature ratings at the beginning of every major release cycle

Are these on drupal.org persistently like the sites linked in #102 ? Can someone post the links ?

@VM's hint at my post, VM, what I said was just reporting a fact - that comment's poster may have or may provide everyone the details since she/he was an usability expert too. It is not what I cooked up. The rest of what you suggested is,imho, hero-worship and bowing to dictatorship, not scientific approach.

giving overlays the benefit of the doubt

Why not give the benefit of doubt to no-overlay or overlay-disabled by default ? At least that is what the voice of the community is in a clear way. Let us have that "idea poll and feature rating" here in drupal.org now on this. Can we ?

Interjecting 3rd party comments as support for this issue that you can't in any way confirm from a commentor that has no idea what was nor wasn't bypassed by DUX testing (and who was obviously biased by past employment experience based on their own comment) doesn't make it fact kaakuu nor scientific.

Yep all drupal devs are my heros. It's ok that you point that out. I won't apologize for appreciating the work that others do so people, yourself included can build sites with drupal without writing a single line of code.

VM #157

I have tried to be in every sense on topic and where I have given links or examples those are,if not primarily, secondarily or in a broader perspective linked to this issue or the way the issue is being thrust on many non-willing persons.

The comment was made by someone who was/is an usabilty expert and is a regular support member of this forum, and the comment was made in one of the issue sections of this very site - if you have objection to the word fact, I change the word to link for you. Regarding all those D7UX tests and the places where those video are hosted are also very much "3rd party". Aren't they according to your definition? Moshe and others have made useful comments regarding this, and this is the last time I respond to your personal attacks. Thanks.

guys.. come on, calm down, don't get warmer and warmer
the emerging (un)related issues aside, discuss them peaceful on another thread

http://drupal.org/node/204667 includes a list of very respected community members who witnessed the DUX testing for those who care to read. Sorry but I, myself, find it hard to believe these individuals who witnessed the testing were dupped by fabricated testing data.

#160 VM

Correct me if I'm wrong, but I don't think there's a dispute over the quality of the Minnesota and Baltimore testing.

But that testing was all about the problem, for which there is "hard proof," not the overlay solution, for which there is no "hard proof."

We don't know how the upcoming tests will be structured. Is there a process?

@ shunting
#126 points to the same comment linked in #156 : http://drupal.org/node/659488#comment-2432930 which calls the validity of the testing itself into question albeit from a different issue. It is the insertion of the comment here, along with a reminder that videos may be "fabricated" that got the hair up on my neck. It shouldn't have, I know, but it did. DUX team and their decisions should indeed be debated and not blindly trusted. It is not that idea that I am arguing. However, I do feel that the DUX testing team that witnessed users having usability issues know what they saw and that they weren't swayed or motivated by anything "fabricated".

Will the overlay.module fix some usability for those users who were having usability issues? I've no idea. For some maybe, for others maybe not. I tend to believe it is impossible to make everybody happy all of the time only some of the people happy some of the time. That doesn't mean one doesn't try their best to make everybody happy though. I agree that the testing should continue to be done as others do with and without the overlay or whatever else goes into drupal for as long as usability testing will be used. Personally, I found some of the results fascinating in some respects and in other respects not so much but in the end, I like many take for granted the fact that I have all my faculties. I know though that someday, with my love of technology, and drupal, I won't have my faculties like i do now and would still love to be able to play with drupal. Especially for my 85th birthday, provided it's still available.

For me option 1 without having to use the back button. I'd prefer to simply close the overlay, with a X or exit button, or whatever.

Rarely do I ever maximize a screen even in Ubuntu. However too much space around window may cause some users to want to drag the overlay around.

Having to use the browser back button to remove the overlay may be confusing for some users and they wind up simply closing the browser window?

Feature creep may be to have a setting? for one or the other. : x

#163

David, nice riposte. Since it's late, I won't get into whether browser =~ desktop (see #19, "site") and whether OS =~ CMS.

However, I will note that your analogy applies only to administrative tasks. Is it your view that overlay should be used only for administrative tasks? If not, and in your view overlay should be used for content creation as well, can you think of an equally powerful analogy?

I love how "this hasn't been done before" is even considered a valid argument and it just keeps popping up

perhaps it's better to copy an existing solution which is known to be broken

this type of mindset does not work in technical fields because it straight up kills innovation

if all the effort put into tearing this down was put into fixing it or coming up with a better solution, we'd be so much closer to our nirvana

Although I was in support of getting this done for code freeze, I think that the overlay has too many problems at this point to consider leaving in core. Performance is a big issue, and it's not even consistently reproducible. Not to mention the fact that most 'power users' won't use it. We should design for the 20% of the people that do 80% of the work, not the other way around.

As for "this hasn't been done before", I call BS. Seen the Buzzr demo video? http://blog.buzzr.com/blogmoo/buzzr-demo-video-making-drupal-usable
It's not quite as extensive as the Drupal 7 overlay, but administrative tasks are still done in a layer that sits on top of the page.

How about Acquia Gardens? Same kind of thing.

I think that if the two biggest Drupal companies are doing it, there's no reason core shouldn't do it.

My vote is this: remove the overlay from Drupal 7, fix it in contrib, and try again in Drupal 8.

> I think that if the two biggest Drupal companies are doing it, there's no reason core shouldn't do it.

Look those products more closely: they use more of the docked palette methapors than D7 "super-lightbox" and I think this works better. I pointed that out in #52. The problem of palettes is this: the demand total rengineering of our admin UI what was never planned for D7UX. Overlay tries to be a compromise: fitting age-old Drupal admin UI into novel fancy container. In some contexts it fits nicely, sometimes it breaks totally.

@sun RE: #168 isn't that both and overlay on the desktop and a browser. If you think of the desktop as a system browser this is the same "browser in a browser" experience you point out in #81.

While I'm still unsure of the overlay this is some great food for thought. This, also, reminded me of http://desktop.sonspring.com/ which an even more radical concept in the browser imho.

mfer: But application windows mostly represent a logically independent task / work and can be minimized, stacked, moved, resized, etc. I think my dialogue analogy fits better. Rightclick on one of the icons and select properties. This will indeed present you with a new window, where the context (file & location) is worth preserving.

@#163, #170
if I use "Active Desktop" to navigate (using Window's desktop as an IE browser) then we can compare

if I use browsers as restored windows, they won't cover all the screen area and overlay makes me feel caged
comparing it with a desktop it would be, if I use a VirtualMachine application (VMware, VirtualPC, etc) restored, how would I feel having restored windows within it?
certainly I would maximize any application within a restored VM/VPC app

VM alerted me to my comment in the other thread being used here as some sort of fact. I just wanted to pop in and set the record straight. My comment in the admin_menu thread was in no way intended to insinuate that drupal UX test results were being fabricated-- period. It was a general statement that test results can be architected in order to bring about the desired result. I never used the word 'fabricated' and i never referenced any actual tests being conducted by community members-- in fact i was lamenting that the decision that issue was discussing was apparently made without user tests.

My point was supposed to be that one must be careful to interpret and understand test results-- not just take them as some type of hard and fast 'fact'. When test results fly in the face of something like overwhelming usage statistics a closer look at the results and methodology are warranted.

#173 +1000. The testing methodology ("architecting test results") is critical, and also might provide rich data for future improvements. "Fabrication" is almost a red herring (and maybe a language issue?).

#169 +1000 for "docked palette metaphors." Less obtrusive.

All I know is that when overlays went in, it broke Media's modal popup browser, which is simply calling jQuery UI's Dialog (in core). I haven't dug too far in yet to fix it, and right now, we're just keeping overlays turned off until we're ready to tackle that problem. As I'm thus currently developing in d7 w/o overlays, I really have no basis to say aye or nay at this point to the concept.

I am concerned about the effect on other contrib modules. How well does this play with other existing overlay solutions such as thickbox, lightbox2, shadowbox, fckeditor, tinymce, etc? As evidenced, it already breaks jQuery UI's Dialog plugin.

And yes, I will certainly jump into the issue queue if and when I find other points of conflict; it would be good to make overlays play nice rather than to break every popular modal popup overlay (including that offered by Drupal core) and to force drupal forks of third party libraries to accommodate it.

I look at this as yet another poorly implemented idea being crammed into core for the sake of the cutting edge, and my job as a contrib developer will be to work around its flaws. But I have other battles to pick, and this is all I have to say here.

Latest patch in #668104: Make overlay respect other click handlers seems to fix issues with other jQuery UI's Dialogs. (argh why is it taking so long to get that patch in)

I have just read the entire thread, and wanted to add some analysis and 2 proposals that I think address the original UX problems in a much simpler and as effective way.

So - if we compare browsing with the overlay, to browsing Seven without it - the actual visual and functional differences are really quite small:
A: There is a large black border that faintly shows the original page you were on before you hit the admin area. Many people have noted that the underlying page is barely noticeable, and pretty much everyone was unanomous that it was too distracting when it was lighter/transparent.
B: There is an "X" at the top of the page that returns you to the original page when you click it.

It seems to me that (A) adds little value - it is too dark to provide much context (you can't exactly refer to the content on that page while in the admin area), and is too distracting as a border on a large admin window when made lighter. (B) does provide a useful function, but doesn't really provide context either. While proper A/B user testing would prove it for sure, it seems very unlikely to me that these 2 small visual/functional changes are going to radically improve the UX. Especially when you consider the volume and complexity of the code needed to support these 2 changes it seems that there has to be a better option.

So here are my 2 proposals (we could do either or both):

1: Make regular admin pages non-overlay, but provide a way for users to easily get back to the last non-admin page they were on after they are done with their admin tasks. This could use an "X" link or it could use a "Back to History of the Drupal community 2008-2010" link, perhaps floated right on the same line as the breadcrumbs. The latter, together with the new admin theme would seem to provide the context to users in an equally or more effectively as the black border. This could be implemented with the adapting the destination URL parameter (or a new parameter) so that url() passes it unchanged on admin paths, or using a (tab/window sensitive) session value - either way should be very simple.

2: Use a more traditional modal popup for lightweight tasks. By lightweight tasks I mean "single hit" tasks that generally you only ever expect a single route through, normally a single form, before returning to the original page. We could have a simple path textarea for site builders to configure where these show up - by default they would probably be the forms accessed via the inline hover links - node/*/edit, admin/build/block/*/edit etc, as well as */confirm. Any links inside the popup would either open in the same page, or in a new (actual) window - never in the modal popup. Most of the time the popup could have a much smaller window, which should (together with the fact that the user is only 1 step away from their current page) allow the context to be much more apparent. Because we can use a more traditional popup metaphor we probably do not need to gray out the background. This could use the core of the overlay code, but could probably drop much of the AJAX/URL complexity we use to keep admin links loading in the overlay.

@casey: it's not there yet, but at least i know the issue to watch now. thanks! (for the record, it may be that media's use of an iframe in a dialog might be bumping against overlay? no idea yet, but this would be an issue for shadowbox as well, and yes, there is at least one shadowbox on an admin settings page in contrib i'm aware of.)

shunting #174

Yes, a sort of language issue. And some other "general" issues where the "expert-tester" admits that videos are not always shot straight and as is like this.

+10000 for 1 at #178.

Whatever we do, I have to agree that we should have started to display simple stuff like confirmation forms in modal dialogs first. The absolute insanity is... that this triviality is not even covered by Overlay.

Hence, you still need to install Popups module in D7 to make any sense of confirmation forms...

Or in kika's words:

I feel our D7 overlay is "simple web modal dialogs pushed too far".

Yes, and, entirely skipping the much more pressing steps in between. :(

#178 makes some very good points in a very objective manner.

I feel like using the overlay, with a narrower width (say 650) for tasks that actually benefit from context, and kicking out to the admin theme for non-contextual tasks is the way to go (if not now, then eventually). It has been said before but the overlay is supposed to help people keep context on what they are doing, and yet the overlay has no context of its own. It happily chomps up every /admin link.

BTW, despite the heated debate here, everyone working on improving the overlay has been doing great. Its actually usable now :)

kaakuu - #180 Sure, anything's possible. As people on this thread are probably tired of hearing now, I'm not big on the argument from authority ("It's good because X says it is good!") But I do think that a robust community, like this one, is able to figure out what's not "shot straight" and deal with it, as a community.

when I suggested to advanced_help to use JavaScript popups instead of actual popups windows it got a "won't fix"

DHTML popup windows require javascript and cannot degrade. Therefore this solution is not acceptable.

#308304-1: use DHTML popup windows

which makes me wonder...

EDIT: copied full quote to avoid out-of-context misinterpretation

If I were evaluating the overlay module as it is now, I would agree with #178 and #181 that it is too heavy-handed, not mature enough, and not solving the basic "context" problem well enough (for things like confirmation forms), and that because of this, it runs the risk of making new users more annoyed with rather than happier with Drupal. And that in general, it's an aggressive gamble to put a brand new kind of module like this into core without it having first matured in contrib.

But, there's still time for its problems to be fixed, and maybe, by the time D7 is released, Dries's aggressive gamble will have paid off, and it will prove to be instrumental in helping an entirely new audience of users get over the intimidation of using a CMS like Drupal. Or maybe not, and as D7 gets closer to release, the calls to move overlay to contrib will grow louder.

I can understand the frustration that while in general, the Drupal convention (from what I understand) is to let modules mature in contrib first and then move to core (so, it's only in D7 that we have fields in core and image support in core, and we still don't have views, panels, or wysiwyg editing in core), overlay was fast-tracked into core. Why was it fast-tracked? My guess is that Dries (and maybe some other people) want D7 to be the first version of Drupal that enables someone evaluating Drupal for the first time (without knowing or wanting to bother with exploring the vast world of contrib) to feel like it's a usable CMS. Let's face it, this is new territory for us as a community. Up until now, no one has ever thought that Drupal is a usable CMS out of the box, and therefore, most people use Wordpress or Joomla. We Drupal users a minority, and we love Drupal, because its framework and contrib options blow the other CMS's out of the water. But the number of potential people out there who would benefit from Drupal, but who dismiss it after trying out a core install for a few minutes, is much larger than the number of people currently using Drupal. Do we want to reach out to those people? That's a loaded question, but software platforms do benefit from a larger user base. More users enables more developers, designers, testers, documentation writers, and all of that leads to more sophisticated and mature software, and in the case of Drupal, to more cool stuff being explored, developed, and shared in contrib.

Of course, there's other ways to solve the "Drupal sucks out of the box" problem, such as install profiles, and work is being done on that front. And we don't want to make the framework worse in order to make an out-of-the-box install more approachable to a novice user. But the inclusion of a module that can be disabled by anyone who knows how to install a contrib module hardly makes the framework any worse. In fact, work on the overlay module has contributed some nice improvements to the framework, even if most of Drupal's current users end up disabling the module.

I doubt that at this point we're going to get any modules like Popups that aren't already in core into core for D7. So where does that leave us? Well, people who are interested can try to improve overlay to the point where it accomplishes its intended goals and is less annoying. If that work proves successful, it really can end up creating a tipping point towards explosive growth of Drupal's adoption. People who've already given up on it can keep disabling it. As D7 release gets closer, if it hasn't been sufficiently improved, we can agitate louder for its removal from core (the work done on it would not have been in vain, because it's a totally awesome module for contrib, and with more maturity can be a killer feature for D8). And parallel to all that, people who like the suggestions in #178 and other comments can work on evolving those ideas with existing or new contrib modules.

By the way, having read some of this thread again, I want to say that I absolutely agree with #108: I do think whether or not overlay helps Drupal make the transition into out-of-the-box usable CMS or whether it just annoys people is whether it comes up when wanted, goes away when wanted, and when it goes away, if you're left on the page that makes sense for you to be left on. Failure to achieve this will make novice users more confused than they are without it, and will make non-novice users disable it. This issue isn't the right forum for debating how this can still be achieved, but if someone wants to reply with links to those issues and/or issue tags, that would be helpful. On the other hand, if the feeling is that this can't be achieved within the confines of what's in scope given where we are in the D7 cycle, then count me in the camp of wanting to see this taken out of core and moved to contrib.

Re #181:

Whatever we do, I have to agree that we should have started to display simple stuff like confirmation forms in modal dialogs first. The absolute insanity is... that this triviality is not even covered by Overlay.

Hence, you still need to install Popups module in D7 to make any sense of confirmation forms...

hmm... well, you can also use Modal Frame API. Here's a few examples:

http://drupal.org/project/modalframe_contrib (blocks administration, string translation in locale, dblog details, field/group settings forms in CCK manage fields screen, ...)

Aside... I would like to mention that I was surprised by the fact that Overlay was based on Modal Frame API, but it was mostly discarded that it would have to be coded as an API, and then implement 2 modules in core. One that provides the API, and another one that implements the API to do ...whatever.

If I'm on a "frontend" page and want to open a "backend" page, I can open in new window. If a different theme is automatically used for both sides, then that's pretty enough to me, even for the average use case, I think it is.

Real frontend/backend separation may require a bit more that just a simple different look, depending on the use case. For example, we're using multisite capabilities in Drupal to do so, where only the editors and administrators have access to the backend site. So the overlay will do nothing for us. On the other hand, modal dialogs implemented here and there, to increase the usability and event speed up certain operations, helps a lot.

[EDITED] Personal feeling around this: However, I do respect 100% the work being done to date around D7UX. I just think I do not quite understand the reasons behind the current approach in Overlay. Really. When I do not understand something, I tend to tell myself, well, maybe the time will help you see what others seem to see today.

One addition that should be added here is that Drupal has a high abandonment rate by potential users. These are people who come to drupal.org, download Drupal, take it for a spin, and then abandon it for something else.

Also, since the overlay has not been really tested to see how it tackles the problems it is supposed to improve having it on my default in the alpha should provide some good feedback from people other than those who work on Drupal core or are the site builders who check in from time to time to see what's going on. I hope we get some quality feedback when D7 hits the masses.

If it is going to be disabled by default the decision should be held off until we have some more data. Data that we should get after the alpha is released and more people get a first look at it.

I totally agree with #185.

And I think that pursuing overlays and trying to fix all its problems is throwing good time after bad (to paraphrase the expression).

I suspect that project management is considered an even dirtier word that roadmap, but some would have been useful when overlays module was embarked upon -- to help plan the amount of time needed to develop it, foresee the pitfalls and so on.

So new users are flummoxed by the lack of a back/front end split? They think that what they see is the back end? Ok. Some simpler ways to address that:

- Ditch Garland. Ship with a default theme that looks like a 2010 website.
- Create a tooltips module that's enabled by default. Have it pop up silly little bubbles that say things like: "This is the front page of your site as visitors will see it. There is no content to show here yet, but once you have created some /article/ content, the most recent of these will be listed here. You can choose to show something else as your site's front page: customize this here.' And so on. It would take what, a day of dev and doc sprint to write the code and the texts, without any horrendous bugs to chase up.

It would take what, a day of dev and doc sprint to write the code and the texts, without any horrendous bugs to chase up.

As this issue proves, it's not the work that takes the time, it's the arguments and debates.

- Ditch Garland. Ship with a default theme that looks like a 2010 website.

This should be a critical issue of it's own. Garland makes Drupal look like a pile of crap, why it is still being included as the default theme is way beyond me!

Also, since the overlay has not been really tested to see how it tackles the problems it is supposed to improve having it on [by] default in the alpha should provide some good feedback from people other than those who work on Drupal core or are the site builders who check in from time to time to see what's going on.

This, to me, is enough reason to leave it in for now. Moving it to contrib or disabling is easy. Getting feedback from people who do not already have an opinion is much harder. For all the calls to "get more user testing", we are the ones who have to do this. This is our software. It's everyone's responsibility to test it. Not just Acquia or ...

#192 +1

#192 +1: I agree with leaving it in for alpha, getting more feedback, and re-evaluating later.

Let's postpone on that for real then and come back later? We got constructive again right before hitting 200 comments, lets keep it at that for now :-)

@yoroy- given that the thread came up on the Development list and that this is very much an active topic, I'd appreciate keeping the Status set to "active" for now.

With that said, I was contemplating whether this would better discussed over at g.d.o, so if there's a consensus to move the conversation there, then changing the Status to "Postponed" would be fine by me.

Fine with either, if we can agree on the 'needs more info' part :)

I agree with Sun (comment #181). I've just been testing out Drupal 7 and i must say there are some amazing work being done on the overlay and a joy to use even though there still some bugs. But the point i want to make is that i think it's been way overused and this become very disorienting since anything and everything pops up into an overlay.

Would it not be better just to have the overlay for frontend editing and leave the admin pages alone or have a way to configure it to be turned off for admin pages only?

I am aware this module can be turned off in modules page but that leaves us with all or nothing?

duvien #198

Frontend editing ? I was an outsider and a new user to Drupal not very long ago, and the immediate convenience and comfort I felt was at the fact that adding or editing content was WYSIWYG with respect to the site, that is, I did not have to switch back and forth from admin to site view. Preview could be nicely done as WYSIWYG in site instead of in a pop-up or form or whatever others will not see.

Test users or new users are neither something of a rare specimen or God - all of us were "test users" at one time. And we do not have Alzheimer. Can we have a survey of what it felt to us, what we needed then when we were just outsider or just new ?
I am not speaking about Baltimore tests (which set other priorities to be chased first) but speaking about the other video tests I have come to know they are very very reliable. I have a question though. Will my (and those who had similar exp as freshers) ease with front = back be documented in the UX data?
WP is used more not beacuse of front!=back but because many of the set-ups have been done there automatically, and if not there are few tasks to do, as it is not CFM like Drupal. And more, they do not have to search or hunt an install profile, its one big nice prominent red 'download' button and what they download is what they use straightaway for their straight purpose which is simple blogging. ( OT but compare the complexity of the proposed redesigned home page of d.org with the simplicity of WP's home page)

As an old/new user what I still feel is not the front/back issue - this separation is actually killing Drupal's unique strength and the chance of the birth of a paradigm which was ripening over the years. It is the issue of finding things easily in the Admin area. What is the reasoning of the grouping of tasks - I mean I do not question the reasoning but its just not easy to find out as its neither alphabetical nor has a clear logic throughout. Module installation page is alphabetic while other pages are not. What is the sequence of titles within a group of task ? For example, after a site is set up with modules and all that when I need to run cron where do I find it ? ( I know it now but ask a 'new' user).
I disable the toolbar since it occupies too much of chrome and I am lost on how to add content. Even the thing hangs. There is no point in bug reporting for me now at this stage for me now as I have already responded with diagrams in other issues and created issue too for what would have been ideal and got a won't fix. Since this thread is now 'needs more info' I give my 2 cents info.

#190 it's not the work that takes the time

Well, that's the price we pay for being a community, eh?

#200, indeed, it's a blessing and on rare occasions a curse.

#201

... and on occasions, curse = blessing in disguise :)

Interestingly, @kaakuu is expressing the very same observations in #199 that I'm already stating for months now. Unfortunately, most of that doesn't belong into this issue. But since critics like us don't have a dedicated site like d7ux.org to publish and outline problems, and d7ux.org itself is like a closed-source institution, there's no room other than hi-jacking individual issues to at least get it into the wild.

With the first alpha being next door, I doubt that any of these issues can be properly fixed.

The only good news I can make out of this is that the new IA actually is a wonderful, aggressive marketing campaign for admin_menu. Thanks for that.

@duvien The overlay uses hook_admin_paths() and hook_admin_paths_alter(). If a path is removed using hook_admin_paths_alter() then it won't be displayed in the overlay (if I remember correctly).

We are free to have a module in contrib that alters the paths displayed in the overlay.

See http://api.drupal.org/api/function/hook_admin_paths/7 for more detail.

@mfer Thanks for that useful info.

FWIW i came across this post, then went and reinstalled my D7 test site to see this new overlay thingy and didnt like it; posted as such in #85. but since then its latest version its grown on me, and i think its kinda cool. i think firsttimers will like it.
whether should be core or contrib i dont quite know, but i'd probably keep it after all. my 2 cents, FWIW.

#203 "no room other than hi-jacking individual issues"

Seems to be an issue that comes up with a lot of online communities. Wouldn't filing patches work?

Aside from doing Drupal work, I work for a company that develops a small custom CMS that is novice oriented.
We tried the overlay approach (jquery ui) in september 2008, and made around 10 sites with that version of the cms.

The overlay proved to be impractical, and my first thought when I installed Drupal 7 Alpha was that it was bad for several reasons:

1) Do we want a separate admin panel with it's own theme, or an admin panel controlled through overlays and launched over the main site theme?
Having both is a user experience and support nightmare.
2) It is resource heavy when IE is concerned. We tried a overlay + tabs + wysiwyg editor, and internet explorer cries along with the user who is trying to use it.
3) The current overlay is just not polished (looks unfinished to me). Does more harm than good for Drupal's image.

In my opinion, the overlay should be used for smaller screens, that don't stretch way beyond the user viewport.
No scrolling! Having double scrolls is not good.

Don't get me wrong, I love Drupal and think it's one of the best things since sliced bread, but this is only worsening the usability issues by looking like an attempt to be modern but giving little in return.
I'm sure the overlay idea can be done right, but not in the Drupal 7 timeframe and not by using the "include the whole admin panel" approach.

We are taking huge steps forward with Drupal 7, let's think hard before taking a step back with the current overlay implementation.

I'd propose listening to the comments of sun carefully not only because he made points long time ago that turned out right eventually but also because his contrib modules offer a good basis for adding functionality with other contrib modules on top of that. That is one of the strengths if not the most important strength of Drupal.

I haven't developed incorporating overlay yet and there seems to be only one contrib developer ran into a fundamental problem with overlay as written in #176 or in #692678: Play nice with Overlay (however no details provided). But in this discussion I miss experience reports about writing contrib modules with the current implemented overlay (in case I missed those please point me to them).

I was surprised by the overlays and frankly found them a bit confusing, mostly because I could not immediately fathom any justification for them -- since they clearly add complexity to the process of making the UI consistent and usable across different browsers/platforms and at the same time don't really seem to bring any usability benefits (e.g., nothing happens more quickly with overlays enabled). Perhaps I've missed the point of them?

Separately, can anyone point to information as to why the overlay module was fast-tracked? I'm curious about how that decision was made.

I don't like it, it's too slow on my system, although I can see it's appeal. Still, having a separate layer on top of an existing one doesn't make much sense to me. Is Drupal about simplicity or about complication, one that that makes Drupal unique is that it makes use of the active user space for just about everything.

I found this thread on search. There was not sufficient answer in the forums.
I want to delete it. Is there any file manager to do it or one has to do by FTP? What are the folders to be deleted? We are developing 43 sites and have time for version 7 to come out. There are as many as 167 sub-admins and editors who just do not like this or wants to delete it as it interferes with their user experience or admin and editing jobs. Please provide the names of folders to delete.

From my personal perspective as a single blind screen-reader user who has been working with D7 on and off since July I can say that I will be disabling the overlay on any site where I have the ability to do so.

I haven't done a full or methodological accessibility audit recently, but my recent experience with using overlay and the most recent release of the JAWS screen-reader (11) and Firefox 3.6 left me with a feeling of poor usability and inconsistent behavior.

I can't point to any specific critical issues from a screen-reader user's perspective, but it is definitely a regression in user experience.

@atemsid: best practice is not to delete the files and folders, but rather to disable the module. On a single site, you can disable the module by going to the /admin/modules page (or clicking the "modules" link in the top black toolbar), and unchecking the box next to the module name ("Overlay"). Disabling the module fully removes its presence in the site: there is no benefit to also deleting the folder. If you want to automate the process of having it disabled for all of your sites, you can modify the "profiles/standard/standard.info" file and put a ";" in front of the line that says dependencies[] = overlay. Then any new sites you install using the "standard" profile will not have it enabled after install. If you have any other questions on this, please create a new forum post, and add a link here, so discussion on that can move away from this issue, leaving this issue for a discussion on what the default should be rather than how people can change the default for their personal use.

A few specific issues that I feel need to be addressed to ensure that the overlay provides a comfortable user experience for screen-reader users:

#716604: Escape key closes overlay dialog without requiring confirmation
#716612: Overlay is not accessible to screen reader users
#717810: Some screen-readers do not respect overlay as 'modal' dialog

At this time I don't see any of these issues as critical, but they can significantly degrade UX for users of certain screen-readers..

I have been using Drupal for 3 or so years and I just reinstalled D7 using the standard installation profile and the overlay module threw me 3 or 4 times in the first couple minutes of use. The wow factor that newbies find using this will disappear fast after a very very short time.

Negatives
You loss context as the overlay is not limited to singular task.
You loss screen real estate.
Minimal load time reductions are probably insignificant in relation to a good admin theme like Seven. The JScript + load delay seemed as slow as a full page load.
Seems to be buggy as
Most significantly, it seems to be sucking a lot of developer time.
issue search on open D7 overlay

Positives
A two minute wow factor?!

I think a poll of users would instantly kill the overlay module in its current form. The only useful modals, IMHO, are popups that have a singular task and are related to the page that triggered the action. I was glad when this trend for modal windows started to decrease in the last decade, replaced with targeted popups, such as logins or 1 to 3 field forms. If the community really wants to get ahead of the rest, did anyone consider targeted inline editing?

I'm not against modals generally, they are great for one off tasks, like file browsers / galleries, but if Overlays could not be turned off, I would switch to another CMS (Actually I'd hack the core as I love Drupal!).

I use a simple rule of thumb here: If the overlay has a component that would require a modal window, then having the main modal window is really questionable.

If this does somehow stays (if the powers above can not see the negatives) please consider adding a kill link in the modal window itself to disable it. It will be a common request for help by newbies

Sorry for being so negative, but I personally find it a shocker. And if your reply is to help out, consider my main objection given above. If only this effort was directed into the Profile module...

Peace

@ Alan D - I apologize in advance if I am wrong but what I feel this is a dead issue.
If you read all the posts in this thread you find that Dries wants this and that want is supported by so called user tests that were done or so called user tests that will be done in near future to prove that this is a must for the core :)

Long story short, this is going to stay!
I wish I was out of this as this keeps on popping on my tracker with no way to delete it.

There are a lot of overlay issues containing patches ready to be reviewed...

I guess that it does require strong UI testing, but my (limited) experience was from trying to populate a Drupal installation with data - terms, menu items & nodes for a site that I hope to get up and running in 4 months. Too early to consider a production site... I was planning to bypass early alpha issues bypassed via exports and imports - upgrades between the cvs versions seem to create strange unique bugs.

If this does stay, there are issues about scrolling that may need to be investigated. I had difficulties with the scrolling of the overlay / browser when both had scrollbars in in FF3.6 with the firebug console open. I think that was a couple minutes before writing the issue above and was the straw that broke the camel’s back with this module.

By the way, I just loving everything else that has made it into Drupal so far. This is going to be a pure joy to work with, and some of the core menu issues appear to be addressed in core. And fields are going to change that Drupal installations are put together. Great work all involved.

@David_Rothstein Re: #220: "It is not sucking up developer time..."

Most of what you've said is true, but I can't let this slide. ;) You can say many things about the overlay, but that it hasn't sucked up developer time is not one of them. I have personally spent at least 10 hours dealing with issues trying to get the overlay to work properly with the Update manager, and it's still not working. The best solution at this point is #679190: Overlay breaks the Update manager workflow. That's 10 hours and counting I could have been spending on Update manager critical bugs unrelated to the overlay (which basically no one works on other than me, and I have 100 other responsibilities, so it's a real problem). I've watched dozens of conversations in IRC where core developers are figuring out how to try to get parts of D7 core working again and looking at all reasonable with the overlay enabled. Not to mention the literally 100s of hours that the overlay team has spent getting it into core and dealing with the direct fall-out. And, as more people port their contribs to D7, I'm sure yet more problems will emerge and countless more developer hours will be spent getting everything working with the overlay. Maybe all the effort is worth it for some mythical, unproven usability improvement that no one has any real data to support (or refute). I'm not making any claims about the overlay from the UX standpoint, since all I have is my own opinions of how confusing it is to use, no usability testing results to share. But, let's be honest about the cost that we're paying to "buy" this improvement, if such an improvement exists at all.

p.s. A brief glace at http://drupal.org/project/issues/drupal?component=overlay.module tells me that we're spending a lot of developer time on overlay. ;) There's no getting around that fact.

The point here is we need data and evidence to support the assertion that all that time is worth it. It seems like the onus should be on the people most strongly advocating to keep it in core to provide this data. In the past, that's how big changes in core had to happen -- if I propose a performance fix, it's up to me to provide benchmarks that prove it's an improvement before my patch goes in. Yes, someone needed to build an overlay to have something to test against, but I don't see why it had to be in core to be tested. Overwhelmingly, our (successful) model from the past has been to build new concepts in contrib, let them simmer for a while, let other approaches to the problem develop, and finally find the best solution and put it in core. Hence we have Field API based on our real experience with CCK over years, not some hacked version of flexinode. Hence, we have imagefield and imagecache in core, not image.module. Hence, we have a real token API in core based on everything we learned from having it in contrib for years. Update status/manager started life in contrib, and was mostly re-written from the ground up in the 5.x-2.* series before it went into core. I could go on and on... This model has served us well in the past. I've never seen a clear statement about why this model shouldn't apply to overlay, and why it needed to be fast-tracked into core without any evidence that it was going to help. We haven't even seen a statement about why it was designed the way it was to try to address the problems it is trying to address, so we can't really do legitimate usability testing relative to other approaches to solve the same problems. If we don't have a hypothesis to work from, we can't really run any good experiments...

I've never seen a clear statement about why this model shouldn't apply to overlay, and why it needed to be fast-tracked into core without any evidence that it was going to help. We haven't even seen a statement about why it was designed the way it was to try to address the problems it is trying to address

"Answers" in this same thread

http://drupal.org/node/659488#comment-2431314
As for what goes in Drupal core, that is Dries call. He has said no to some things and yes to others. He has delayed some things for a version. Some parts have needed to be lobbied to go in. Webchick defers to Dries on anything major. In this case Dries wants the overlay in.

http://drupal.org/node/659488#comment-2431608
The work the UX experts did were hotly debated. ...It was due to be debated and I'm not sold.
But, Dries seems to be sold enough for it to be included in core and enabled by default.

http://drupal.org/node/659488#comment-2432898
Dries
Maybe we'll find out that overlays are bad, in which case we can remove them. But we don't know yet. A handful Drupal experts (that I respect greatly) complaining about the overlays does not justify removing the overlays from core. We know for a fact that not having overlays confuses the hell out of new people (watch almost all of the usability testing videos), and the overlays were specifically designed to avoid that.

And to repeat myself

I apologize in advance if I am wrong but what I feel this is a dead issue.
If you read all the posts in this thread you find that Dries wants this and that want is supported by so called user tests that were done or so called user tests that will be done in near future to prove that this is a must for the core :)

I would prefer to see the overlay in contrib, but instead of adding fuel to this fire I want to make a point.

Even though the overlay module cripples my server, it does not hurt much to have it in core. I can take the 15 minutes needed to disable the module after installing and it's as good as gone. It is at most an inconvenience.

Of course, I won't be helping anyone if there is a conflict with any modules I'm working on.

I can take the 15 minutes needed to disable the module after installing

I'm assuming you mean 15 seconds.

No, I meant 15 minutes. Like I said, it cripples my server.

@#226 what you're not taking into account is what happens to users visiting a site which does have overlay enabled (because someone didn't spend 15 minutes, or didn't have a crippled server)

#221

Also, the ability to use the overlay is already a permission (i.e., configurable by role), so it's not like everyone who has permission to create content has to do so in the overlay. And there are other issues in the queue about potentially modifying this a bit (e.g., to allow it to be per-user).

and that would be the first time in a lifetime that I'll be asking for less permissions granted because an usability issue instead of wanting less responsability
and/or will be the glorious era of autoassignrole

Everyone please read the title of this issue.
Here is a clean start, though I got stuck in other stuff before completing it: #685046: Test Plan for the Overlay

Please provide some hard data.

Please, please let's start testing. User testing has no History whatsoever in Drupal, but this is not surprising as it has not in other projects. Problem is to be non-biased while doing the testing, more severely so as anyone doing the testing will be either pro or con. But a video uploaded on vimeo should help find out any biased user influencing :)

Subscribing. Will try to test overlay this week. I am a regular user of D6, but not a usability or development expert, so I think I am the kind of person who would be good to test...

Regarding modal dialogs and accessibility for screen-reader users. I have written a blog article Can a modal dialog be made to work properly for screen-reader users on the web?. The short answer is kind of, but not really. I would have posted the entire article here, but it is a little to long for that. It explains the objective problem, as well as the subjective experience.

My preferences for Overlay would be:

1. Overlay is disabled in the default profile.
2. That a alternative profile be available when isntalling Drupal 7 which is Default minus overlay
3. That Overlay is made a contributed module (I don't really like this one)

Considering that many Drupal sites need to be built for accessibility, and that I'm hearing some concerns about Overlay and accessibility, I would concur with the suggestions in #233 as probably the best alternatives. I don't know if WSAG 2.0 addresses modal dialogs, though it should be an easy discovery. Still, it might be best to be pro-active in this case, especially considering there may be (and probably are) at least a few Drupal developers and administrators using screen readers; why make them jump through a difficult hurdle just to install and configure their sites? At the very least we should make an accessible profile available.

Everett somewhat already mentioned this but after reading http://www.w3.org/TR/wai-aria-practices/#dialog_modal I think that overlay shouldn't proclaim itself being a dialog.

I also think this should be discussed here: #716612: Overlay is not accessible to screen reader users

Tried it. Hate it.

Don't understand why Drupal admin pages need a "...machine that goes ping!" overlapping them.

I agree with #233, but I prefer option 3.

Making this CMS more usable has nothing to do with cleverly scripted devices and shiny new toys. A better move would be to create cleaner, crisper documentation. Simplify the way everything works. Make things more logical. Etc.

Hello all
I am not sure this contrib will be really useful but scroogie saw my post on another thread and thought it might be valuable here. It was written a bit harshly so I apologize for the tone but I have no time to rewrite it right now.
I perused the thread here and I must say that I am sometime surprised by the logic at hand, It looks to me that Overlays where put in core and then most arguments revolves around " prove it does not belong there", but as far as I remember it is up to the people that come with something new, a new idea or new theory to prove it right, or I could spend my life debunking others pretensions or ideas. I call that the "Nessie theorem" : "that is the people that pretend to have seen Nessie (the loch ness monster) that have to prove it exists, and not to me to drag the entire Lock Ness lake to prove it does not exists. In fact I should not even be bothered with it. And in my book it should be the same with generalized overlays.

Here is what I posted in the other thread :

I am well known as a negative kind of man so you can dismiss my comment entirely if you want, besides it does not help to boot, but I feel like you are trying to solve an unsolvable problem (in an elegant and intuitive way).

The root of the evil (to me) seems to be : "overlay" is a modal concept and it introduce artificial state.

First Modal dialogs are generally seen as bad UI design for many reasons , but especially because nobody knows what happens when you do "something else" and with tabs in browsers, you can loose tab focus and loose application focus (application switch) and what the user is expected to implicitly understand that will make him feel good about its "data half-typed in the overlay" when he switch or some other bad designed application take the focus on its desktop or mobile phone ?.
No arm done when you are browsing picture (but even "pictures browsers overlays" are inconsistent in what they do when you click outside the "frame" or press ESC) but when you are inputing datas ????

Second : modal introduce layered context/state, and that context as a local implicit meaning that is sometime and often opposite to the general context. That's the trouble with the "X" close button : does it mean save ? cancel ? and it should not mean the same in the overlay's overlay dialog box ("you have unsaved work ...") were "cancel" is of dubious meaning ...).

All of this troubles for what gain ? I think the problem goes goes well beyond "ready for core" or not, it is, in my book, one of these "fashionable" false good ideas. I am quite sure I would turn them OFF ASAP in any Drupal 7 installation. And I could take bets than Drupal 8 will not have them because they will look so "cliché" and "dated".
I don't want to dismiss the work that is done (especially because I am not doing much to help), and I am sure overlays can be a good and sexy addition to some use cases but certainly not the general use case.
I understand that the more one invest in something the more reluctant one is to "throw" away or pull back the stuff or reduce its scope, that's the only reason I wrote this even knowing my voice matter very little, for good reasons ....

PS: the more I think about it the more I think it is a bad solution to one big real Drupal problem : its lack (I would even say refusal) of containment and hierarchical context : that means lacks of context for "actions" witch then leads to the problem overlay are trying to solve : when you do some action you can't be easily brought back to the place you were initiating the action. That applies to many user actions when adding content, working with lists, and administrative actions : when I am adjusting sub feature D of A(admin root menu)->B->C->d I am never brought back to C but A, unless the developer provided me special shortcut links to C (but never B since B is rarely part of the module C->d are the administrative part of)... but if he does , then what happens when I "apply" the changes on page D... but I digress.

There's no need to re-invent the wheel. The Word Press already has the most sophisticatedly simple spread of any CMS. All Drupal needs to do is use it as an example and do it better. Drupal doesn't need more code or fancy widgets, it needs more simple logic that makes sense along with faster navigation and fewer clicks. The problem is programmers are running the show and all they can think up is complexed fancy scripts and illogical actions. This overlay example was obviously thought up by a programmer, it's a performance waste.

@espirates Wordpress is a specific app designed around a specific set of assumptions (blogging and simple cms). Drupal is an extensible and module system meant to be built upon. The challenge of creating an administration area is different. The wordpress admin was not designed to really extend. For example, at sxsw last year there was the cms showdown. Wordpress, which had been extended, had an admin experience rated lower than drupal.

Different assumptions and different uses provide different challenges. Do it like Wordpress doesn't work here.

I highly doubt that if Dries hadn't been so strongly supportive of Overlay that it would have progressed as far as it has. There just doesn't seem to be a good way to get Overlay to a place where it is working so that it can be usability tested (with hopefully positive results) without the emphasis of putting it in Core. Sure, Overlay could have been usability tested via a low-fidelity prototype, but the lack of interactivity would have had a significant effect on the user's experience and understanding of what Overlay is for and impacted the results. Whether or not Overlay makes it into Core for Drupal 7, it is important that we act like it is a priority. If Overlay goes into contrib will Overlay be responsible for working around what is currently the Drupal way? Or will Core have to adapt to Overlay anyway?

So I guess in my mind the question is moot. We can't know if Overlay is a true usability improvement until it's finished being implemented, and it can't be implemented unless it's a priority.

Well, I've finally gotten around to testing Overlay some (on CVS checkout of Mar. 27, 2010). Here's my initial thoughts:

* I love the concept, and on Firefox 3.6, at least, the basic functionality works well. I haven't done any cross-browser or accessibility testing.
* Overlay+Toolbar definitely makes it easier to navigate the regular admin pages, Since no one stays for a long time on the "By Task" or "By Module" page, it makes sense to click the toolbar, click on a link in overlay, and then get to the actual form.
* It really needs some sort of "dirty forms" support, to warn people if they have unsaved changes. I just lost a change to a content type configuration form, because I clicked away and it didn't warn me. Is there an issue for that?
* It works well for simple tasks like creating nodes, but the more complex the form is, the more difficult it is to complete the task in the overlay, and the less necessary the overlay is, imo. People's mental model of doing things like "administering modules" or "administering blocks" is different than their mental model of "editing a node" or even "editing content type settings" or "clearing the cache."
* It was confusing at first that the scrollbar for the overlay is the scrollbar for the window. But Heine's explanation to me in IRC (Fitts' Law, two scrollbars would be worse) makes sense.
* When people have loads of blocks or modules, then the overlay JS is totally going to kill those pages. That alone is a reason to not have overlay on those pages, but to keep it for other, "lighter" pages.

In conclusion, I think Overlay definitely belongs in core, if the pending issues with it can be resolved. I have worked with Drupal for 2 years - in an editor role on 5.x, then an admin/developer role on 6.x. I have also trained other editors on 5.x & 6.x, and wrote documentation. The presence of Overlay will make things easier for the vast majority of Drupal users, and will help open up Drupal to new markets where people would be considering things like WordPress/BuddyPress exclusively.

I hope to continue my testing at some point in #685046: Test Plan for the Overlay, which should be more rigorous and less subjective.

Should this issue be closed at some point soon? I think it is about played out, and I am sorry I was so late in getting to it.

Oh, forget to mention: It's been said before, but the pages themselves can take a while to load (especially blocks & modules), which is more painful when they are modal than when they are regular pages.

Thanks for this.

"It works well for simple tasks like creating nodes, but the more complex the form is, the more difficult it is to complete the task in the overlay, and the less necessary the overlay is." matches my experience with it as well. As long as you are in the 'tweaking things concerning the front-end' modus, it works well. Configuring base Drupal-system style settings feels better in Seven admin theme directly in the browser chrome instead of in overlay.

If the replies consist of decent feedback like this, based on actual usage etc. then it's fine to keep commenting here IMO.

Thanks, yoroy! :)

Perhaps rather than pushing overlay to contrib, where I think it will remain unused by many people new to Drupal, and where it probably won't get the attention it needs, we could consider something like the following:

Ship with 3 install profiles, instead of 2.

* Standard - the default (this would include Overlay+Toolbar, for the full D7UX experience)
* Old-style - for people familiar with Drupal 6 and/or people who would prefer a different admin UI solution (this would still have the Seven administration theme, probably, but not with Overlay & Toolbar enabled; probably if this were to be created, it would have to have a better name)
* Minimal - just the bare-bones modules that core requires to function

@EvanDonovan

I absolutely agree that Core needs to ship with an standard installation profile where Overlay is not enabled. I like the three suggestions you have made, although I could go either way on toolbar being disabled in the second profile.

Overlay can cause significant accessibility challenges for screen-reader users, particularly those with older technologies or for users not familiar with the glitches in accessible rich internet application (ARIA) support in their modern technology.

The presence of Overlay will make things easier for the vast majority of Drupal users, and will help open up Drupal to new markets where people would be considering things like WordPress/BuddyPress exclusively

Vast majority of Drupal users ? ? ? I seriously doubt that and what does a popup admin screen have to do with opening up new markets ? ? ?

It slows the admin down, that's what it does, therefore it should not be in the core.
I can say with certainty that Wordpress users would not switch to Drupal for the Overlay, when the WP Admin is by far the best on the CMS planet.

Drupal should focus more on being usable and improving performance rather than fancy bloat code that uses up resources unnecessarily. Only then will people start looking at Drupal as a serious alternative.

@espirates:

I was referring to end users, not developers. End users will benefit from something that makes the interface easier for them to use.

Furthermore, I'm not saying WordPress users will switch; if the software satisfies their needs, they wouldn't switch for a different admin experience, especially since it's not like the one with which they are familiar. Rather, I'm saying that people who would otherwise not consider adopting Drupal might feel safer in doing so if they know that its admin interface is more usable.

Finally, if the overlay slows the admin interface down on your install, then disable it. It is totally optional. But this issue is about whether it should be in the core at all. My argument is that if it is in contrib, it won't be part of the UX for enough users of Drupal that module developers will cater to it.

Rather than continue to argue our respective opinions, we should probably focus our energies on seeing the results of the user testing in #685046: Test Plan for the Overlay. As far as your suggestion in a previous comment that we should just do what WordPress does, I don't think that is a viable option considering that Drupal can do much more than WordPress. Also, WordPress, due to its historic roots as exclusively a blogging platform, has a very rigid distinction between front-end and back-end (though not as rigid, imo, as Joomla's).

As I see it, the D7UX setup of Overlay, Edit-in-Place, Toolbar, and Shortcuts was intended as a unit. If you take away Overlay, then the others are not nearly as useful, since the user's original context is removed. On the other hand, when they are kept together, then I believe Drupal manages to accommodate the expectation users of other CMS's have that there will be a back-end interface, while still keeping them in the flow of their work.

I have used Overlay a little more this weekend, and I still agree with my initial judgments about it. Some things about it I have gotten more used to - like the way the page scrollbar relates to it. Some things remain a problem - like the "dirty forms" issue. (This is particularly bad when you click the "Find out more about input formats" link. Is there any way that patch can still make it in.) I definitely think Overlay is a flawed method of completing multi-step tasks: when I do something like create & configure a new input format, I don't really need my original editing context preserved, because I am putting on a "site admin" hat for a while.

So in conclusion, I think two things should be done:

1) Have an install profile in core that has the regular Drupal modules enabled, but has a UX more like the one for D6, for people who prefer that for whatever reason.
2) Only have the more basic administrative pages show up in the Overlay. Of course, one would have to determine which those are.

It really needs some sort of "dirty forms" support, to warn people if they have unsaved changes. I just lost a change to a content type configuration form, because I clicked away and it didn't warn me. Is there an issue for that?

See #655388: Many ways to lose data on form input in the overlay

@espirates Be careful in the directions you take this. It seems like there are elements to this you are not aware of.

For example, Wordpress admin area is a very controlled area not designed to expand drastically. The admin area in Drupal does and needs to be. When put to the test with some extending the Drupal admin area came out above the Wordpress one. How could that be? Because they have different purposes with different constraints.

That being said, the Drupal admin experience still needs A LOT of improvement.

I have heard issues about the performance. Is there any quantifiable data to support that? Or, is this conjecture? And, for what groups does this issue arise with? There is a difference between end users, content managers, site admins, and site builders.

@amc: Thanks for the link; I knew there was something already. I'll check that issue out.

@mfer: Agreed, agreed, and agreed :)

I think yoroy was saying on IRC that there were performance issues he'd experienced on his test environment. I assume most of these are client-side, due to JS, and thus probably variable on what browser you use also. Is there an issue for performance/resource usage testing of overlay?

@EvanDonovan Performance should be gauged at points in the source history. For example, when jQuery 1.4 went in there should have been a measurable speed improbement because jQuery was faster. The overlay used to be much slower than it is now.

@mfer: Ah, makes sense.

My 2 cents

I like the overlay and bar.

#1 Rule: Don't design by committee. You have a clear vision, one leader, one singular goal. You work with demonstrable data and you iterate quickly and as best you can and then ship.

You can see a recent example of this in the Ubuntu community railing against the new purple theme. It contains major color, fonts and layout changes. As expected, trolls and flame wars posts (500+!) clog up the bug report. Yet, Mark Shuttleworth is sticking fast and not getting sidetracked.

As others have said, money has been spent. Clear, credible UX/UA leaders were tasked to redesign the admin based on data from usability tests. Without hard usability data, people who put down the overlay as unusable especially this late in the game don't have a strong argument.

That said, overlay needs more love.
+ There is a reasonable compromise for turning off the overlay in minimal profile. I would even go as far as making "minimal" the default profile. This may make developers/smallcorers happy.
+ It can be *turned off*
+ In contrib, this module will die, forgotten, out of sight. We know this.
+ Overlay and toolbar is the new face of Drupal's admin. It's been shown everywhere. People are already training on it. People are writing books on it. People are speaking and podcasting about it.
+ If it takes more time, so be it. It'll be ready when it's ready. Moreover, Panels and views 3 probably won't be ready when D7 ships anyway along with a whole host of smaller but necessary modules.
+ There's something to be said about having a new, fresh look & feel. It may be insignificant technically, but IMO, first impressions matter for reaching a bigger audience.

@momendo:

I agree with you 95%. However, note that the "minimal" profile is really just the "bare-bones" modules needed to run Drupal. I don't think making it the default would give most Drupal users the best experience. This is why I suggested having 3 install profiles, instead of 2, in #244.

By "I would even go as far as making "minimal" the default profile. This may make developers/smallcorers happy.", this is the one area that kills newbies. As soon as they need some functionality, this is the point that they will stop using Drupal - I've seen this many things on many different systems. No matter how good the interface is, the concept of modules is very alien to new users.

So the question should be, can overlay be used by newbies without confusion? If it doesn't work when they try and do something more complicated than to create a node, they will get a negative impression of Drupal which would be a real shame. And it is these users that will struggle as they try and turn it off.

Personally I'm 98% against having overlay, there are so many better ways of doing things. (Inline editing or simple AJAX frames). I'm planning a world trip, so I can not start anything, but an inline editor would make the Drupal interface absolutely amazing. So any takers?

E.g.

A registry of form / pages.
A page alter to append context sensitive links to individual elements
An AJAX form callback to load this element form section.

Any talk of speed is out the window, a 1K AJAX data load for the element and maybe a 100B submit load. You would be able to edit a title before a standard browser would even have registered the JQuery window. Maybe in 2 years I'll start something in contrib for Drupal 9 if no one else has started this.

PS: Has anyone actually tried overlays with real module combinations - WYSIWYG and IMCE need additional popups to work, so there are going to be potentially 4 popup windows/divs to upload a file va IMCE! Say no more!

Clear, credible UX/UA leaders were tasked to redesign the admin based on data from usability tests. Without hard usability data, people who put down the overlay as unusable especially this late in the game don't have a strong argument.

Sorry to interrupt BUT
- people have put overlay as unusable from day one in the game.
- Read d7ux site, this site and many other sites.
- There is no usability data, no feature request, no user poll, nothing that supports the birth of overlay.
- It seems to have arisen de novo, assuming that with overlay everything is going to be okay.
- Usability data so far( read this entire thread at least) suggest against overlay.
- UX/UA leaders were neither clear, nor credible, not even 'leaders' perhaps - read all past posts w.r.t this issue scattered all over
- Spending money does not justify a thing unless there are other justifications
- >> It can be *turned off* Most people are not finding the OFF button easily
- >> in contrib, this module will die, forgotten, .... We know this. - Why ? How ? All the great modules that makes Drupal famous have made it from contrib to core.

For the main Admin job Admin module is the most used one http://drupal.org/project/admin_menu, if you want to have a look at the real usability data. A single leader is good unless he drowns the ship. Only time will tell. An easy test of time will be : see after one to two years, still how many people are downloading Admin module. Since overlay and Admin module are sort of incompatible, you will able to make fair judgment about the usefulness of overlay for the main or major Admin tasks. Still then this thread is purely useless as Drupal, as determined by Dries, is going to ship with overlay on as default. Nothing is going to change that. If debating, without results, is fun we can of course invest our time in it.

@kaakuu
A few thoughts:
- People have a status quo bias so it's no surprise that some people have been screaming about such a radical change from the start. Change can be painful.
- I personally don't have an issue with the credibility of the UX/UA leaders. They conducted usability testing, identified a problem, and provided a possible solution. In my mind, they used the identified issues from the usability testing results to focus their expert evaluations to provide Drupal with possible improvements. Expert evaluations rely on the expert's learned knowledge of UX/UA so there would be no hard data to show that Overlay would be beneficial. So if you have a problem with the credibility of the UX/UA people you will never accept Overlay until it can be tested.

I'm all for trying something new. I cringe every time I have to think about training clients on how to use Drupal to manage their content.

BTW, I also personally hate the admin menu, but that might be because it's difficult for me to navigate drop downs that also fly left. It's hard to move a mouse precisely horizontally when you only have a small vertical area to stay in and you have to move quickly enough that the menu doesn't disappear, but I digress.

I think tyabut is absolutely right about admin_menu. Dropdown menus have their own set of usability issues. And they don't scale to very complex Drupal installs because the menu gets too long.

My favorite UX so far is the Admin module v. 1.0 for Drupal 6. But obviously that's not an option at this stage in the game.

This is getting a little off track, but the usage statistics don't even come close to bearing that assertion out. I've used both admin and admin_menu and far prefer admin_menu (as do over 100k sites it would seem). Yes the drop downs get long but mega menus can fix that. It has a long history in contrib which has allowed it to mature and work out lots of issues. Sun has done an amazing job with it.

The larger point here is that there will often be as many opinions on an issue like this as there are developers, designers, and users working on it. The only real way to sort it out is with usability testing.

To my knowledge, and I could be wrong since I lost track of this issue once I started disabling it automatically with drush, the overlay was fast tracked to core based on opinion and not data. Bypassing contrib means that there's very little in the way of maturity and kink smoothing based on real world usage in the wild.

I think this thread servers no purpose anymore, it has become a place for everyone to vent their rage and frustrations, but it's unproductive, since it doesn't really change anything.

Looks like this is the first big item that has divided the community opinion, it will be interesting to see how it plays out (who gets to say "I was right" in two years)

There actually is one new piece of information to add: With Overlay module on by default, Drupal 7 fails to conform with international accessibility guidelines or to comply with United States law. For more on this, read 775084: Allow users to opt-out of the overlay during installation for accessibility.

In time, the maturation of ARIA and the adaptation of screen readers to ARIA could conceivably make it possible for the interface produced by Overlays module to be accessible. But that is not going to happen in the timeframe Dries mentioned Monday (in his plenary session at DrupalCon in San Francisco) for finishing Drupal 7 — not even under the worst-case scenario.

To me, that's a pretty strong argument for moving this module out of core. The technology simply is not there to enable it to work as a core component of Drupal 7. Give it time in contrib for everything to mature. And in that time, let developers figure out the best ways to use overlays.

@Cliff & everyone: This discussion relates to user testing the overlay only. Please stay on topic. There are enough issues already to cover the other arguments for/against overlay.

@Dave Reid - screen reader users are users - the results of these users tests are equally valid to those of sighted users, in the context of this issue :)

Of course if we can fix the overlay for screen readers, or come up with some other reasonable workaround to allow screen reader users to install and use Drupal, then this would no longer factor into this issues discussion.

@Owen: I think the point is that we don't want to fork the discussion about accessibility into both places, because it's harder to follow. If the result of #775084: Allow users to opt-out of the overlay during installation for accessibility is "we can't possibly make this accessible", then we will remove Overlay on that basis (or make it opt-in or whatever we decide). *This* issue is more about the question of usability for sighted users, and trying to get data that can help us decide whether or not it actually improves the UX for them.

You are 10000% right.

So obvious that this is definitely NOT about any shred of reason.
Just people stuck in the hole they dug.
I respect the digging part, unfortunately this time it is not the right hole, no treasure inside it.

I sound a bit bitter simply because I am afraid this will really shot Drupal down big time.

Drupal lacks context and containment above all and this really goes further in the wrong way.

Just coming in to cast my vote against overlay in core. Even if there weren't myriad (critical) issues surrounding it, as a user I feel like it's unpolished and seems ghetto. It makes me a little queasy when in the discussion of 'does overlay belong in core' people are SERIOUSLY discussing whether we should create an install profile with everything but the overlay. Sadly, it reminds me of this which I saw today on reddit: http://www.reddit.com/r/WTF/comments/bwsyx/home_depot_delivery_guy_is_a_...

I know everyone wants to make Drupal easier for people to use, but at what cost? I'm also a user of the D7 critical issue queue and don't appreciate aving to step over overlay's corpse every time I come in. Does that count?

Put it in contrib, let it mature.

I happen to really like the overlay, but that's neither here nor there.

One thing I haven't seen is a good alternative. The overlay is a solution to a specific, pervasive usability problem that was identified through user testing. Namely, the testers were consistently disoriented -- the "Where's my site?" problem. Traditional out-of-the-box Drupal uses the same theme for admin and non-admin tasks, and many users have trouble understanding what's user-facing and what only the administrator can see. We could use a different admin theme, but users have trouble understanding how to get back & forth from the admin to the site (or at least to the page on the site that they were last looking at).

Therefore, if overlay is being seriously considered for removal, user testing could test a range of options and solutions which actually address the issue. Then, if the overlay has problems, we could devise creative, alternative solutions or hybrid approaches which are effective at solving the very real problem that the overlay was created to solve.

Hehe, this issue is fun. I am still waiting for the first person doing a user test.

@eigentor: I did, at #241. Then, I realized this issue was getting nowhere. There is a testing plan for the Overlay issue - that's the one where any future user tests should go, I think, if we want people to read them.

One thing I haven't seen is a good alternative.

Sorry, but the whole point of this issue is that there is no solid evidence that overlay in fact 'a good alternative' either. Testing identified a problem, overlay was proposed as the solution to that problem, then for some reason, which I'm still at a loss to understand, it was simply accepted that it would definitely solve the problem and it was full steam ahead on creating a brand new module for core without any time in contrib to mature.

Personally I'm not a fan of overlay or toolbar but in practice it doesn't really affect my workflow much either (adding drush dis toolbar overlay and drush dl admin_menu drush en admin_menu to my install script required zero effort). My only concern is for best future of drupal and I'm just sad that so much core talent was spent on something that has yet to prove itself worthy.

Festun

@David_Rothstein: Oooh, interesting. I missed that. That might cool, even for people who don't ever want overlay enabled. Will try to test soon.

@David_Rothstein, I agree that your approach would work. In fact, from a design standpoint, it makes more sense than an overlay. With an overlay, all pages with the same border could look the same, or at least similar enough for the user to goof. And that really won't show up as a problem until you have a lot of users working with it on rather large sites — in other words, sites with many pages that are similar in overall format.

With your approach (if I understand it correctly), there is a unique identifier in the link text pointing back to the page on which this work is being done: The title of that page. It's a simpler fix at all levels, and it's accessible.

If that approach were adopted, would Overlay be removed from core because it would no longer be necessary? Or would it simply be turned off by default?

eigentor
Hehe, this issue is fun. I am still waiting for the first person doing a user test.

Unless you are stuck to your own definition of user test and want to see some made up videos only, many have already done this 'test' and reported against this but to deaf ears. Actually people have discarded this and are using the Admin Menu instead - have a look at the download stats.

amc -

One thing I haven't seen is a good alternative. The overlay is a solution to a specific, pervasive usability problem that was identified through user testing. Namely, the testers were consistently disoriented -- the "Where's my site?" problem. Traditional out-of-the-box Drupal uses the same theme for admin and non-admin tasks

Are these WP users or brand new users? If brand new, how can they have 'disoriented' experience as all the daily software they use like MS Word, Photoshop have same interface for all purposes. If they are WP users or the like, we already have D I FF E R E N T admin theme by default. So what extra does the overlay achive?
Having to use WP for a site, I and others have been constantly nagged, bothered to hell and aghast at the fact that in WP one has to switch and back and forth, back and forth between 'admin-mode' and 'site-mode' to actually see how the actual site looks to the actual visitor.

Duped by so called usability tests and experts Drupal LOST a great chance to make its original admin format the industry standard. It will be several versions before D realizes this and returns to the D5/D6 root. In the meanwhile what is poison to us can be 'fun' to many, I guess!

Define User Test.
In my eyes it is you watching someone else using the software.
http://en.wikipedia.org/wiki/Usability_testing

The difficult part is being non-biased. This is practically impossible, but there are means to get a better chance. Recording a video makes sure that other people can look at your test and draw their own conclusions.

The thing is no one can be sure a product works until it gets released into the wild. Thus a user test is maybe a try to simulate this. So you try to test people with different backgrounds in order to get representative results. As D7UX is mainly geared at Drupal beginners, this scope is more focused at those.

Then you try to put up tasks that reflect real-life use, which I tried in the test plan. Try a test, and you'll be surprised. Last time I was sitting anxiously there because I wanted the tests to be favorable of the overlay. Try it out with two or three people that do not or hardly know Drupal and you will be surprised.

Anyone (including myself) that knows the software well and even has some assumptions how it should be disqualifies as a testing person.

I have a feeling everyone's gonna come out of the woodwork against this one, but I had the idea so I made it happen and figured I'd share it.

This patch adds a new function, drupal_get_breadcrumb_back(), which returns the path that David ascertains with his current patch. That code has been updated in a couple ways; it doesn't act if the user is anonymous, and only adds the back link if the back path is different than the front page (as that would be redundant with 'Home').

So, I'll let the image/patch tell you the rest.

Oops, copy paste is bad mmkayy...

Great proposal, but:

1) I think it warrants a separate issue, this thread is way too lengthy to work on

2) Note that there is a similar UI proposal in the works what works other way around -- a special link getting _back_to_the_admin_page_ for "Demonstrate block regions" functionality. #655416: "Demonstrate block regions" bugs with regions, navigation, overlay and the mockup: http://img.skitch.com/20100421-xdnrpebeg4ty8g6ybyk1178cyp.jpg

This means the context-aware backlink needs to be nicely abstracted so in different scenarios different link content can be injected. Also, it should be bolted to permanent place in the page (likely docked to the menubar) and work both in admin and non-admin pages.

Agreed that we should move this into a different issue, and that we should have some reasonable abstraction.

I also think that we should probably steer clear of sessions, unless someone has a way of ensuring this works properly across multiple tabs. I was thinking more along the lines of a persistent querystring parameter (like destination=), or possibly a context style URL (e.g. news/drupal-7-released/admin/build/modules), where everything in front of admin is removed from $_GET['q'] and stashed somewhere for later reference, in the same way the language prefixes work.

In terms of UI, the "back" (<<) breadcrumbs are an interesting idea and do make sense to me. I am not sure if that is a bit to unusual from a UX point of view though - I was thinking more of just having a normal link, positioned vertically in line with the breadcrumbs, but floated all the way to the right.

For me, messing with breadcrumbs does not feel right and UX will start wildly differ in different themes. I'd go for a special (centered) docked element as suggested by yoroy http://img.skitch.com/20100421-xdnrpebeg4ty8g6ybyk1178cyp.jpg

Yeah - that is more what I was thinking of.

I really like yoroy's design mockup. That might please everyone. We should move to another issue if we're going to have actual code, though.

Yeah, that's pretty sexy. My only concern is, is it too late to get in? Are we pursuing this as an alternative to overlay or introducing this in addition to the overlay?

Have we not been in that backlink-land? #546694: "Back to the live site" is misleading and incorrect #548806: No breadcrumbs in Seven ?

Actually, reading those I think what is discussed here is different, but I suspect closer to what Mark Boulton and co were aiming for. It looks to me that the mockups showed a "Back to front page" link and someone added that hard coded (which was pointless, as home is already in the breadcrumbs), but I think the intention was for that to be context sensitive to the last non-admin page you were on, which is what we are looking at here.

Either way, the main point is that the Overlay was intended to give the user a context about where they "are" on the site, but currently it just gives a thin dark border that makes the underlying site barely visible (especially anything specific to the actual page you were on), and an "X" button that takes them back to the last non-admin page they were on. My feeling is that a well placed "Back to "" link as described above would provide this context better than the current Overlay, as well as the same functionality as that "X". It could replace the overlay completely (we could then use modal dialogs for temporal interactions, such as confirmations - which I think is a more valuable use overall), but even if the Overlay stays at very least this link would at least help fulfill the underlying user requirement of context that the overlay is (IMHO) failing to provide.

What is missing to have an actual code? The backlink-storing is already in place, we just need a permanent place for backlink in templates and styling (I can help with the latter). Where this stuff should live at first place, file-wise? If it is bolted to menubar (toolbar is optional) then the presentation should be in the same place where menubar? How to make it work for #655416: "Demonstrate block regions" bugs with regions, navigation, overlay ? Does it need a special alter hook or render altering will do?

Try it out with two or three people that do not or hardly know Drupal and you will be surprised.

Eigentor

I tried out and these folks are hell lot confused. They have experience of computer and ordinary programs like Paint or Word where there are no separate admin and non-admin interface.

They are more than hell lot confused as why there are 3 screens to tackle - the admin theme, the overlay theme, the site theme. They will like to see directly how a page looks to a visitor instead of switching or right clicking. The most common question they ask - if its a different admin theme whats the point on overlay? NO acceptable answer to this, so far. Have you got one?

I can invest in videos BUT I need to know how many videos, what are the criteria (as Drupal is most vague on this) on which whose videos will be selected and accepted instead of a dictator-like denial on any ground.

@kaaku - thanks for the feedback from your user testing. i'd really love to see those videos

unfortunately, you will never get the clarity you seek about how many videos are needed. nor can you are you ever protected from "dictators". the cvs maintainers for drupal 7 are our current dictators. thats dries and webchick. that is as it has been, as it will be, and as it should be (IMO). we need an arbitrator when we cannot find consensus on an issue. these dictators are usually very reasonable and they read every argument and every video that gets posted here. so, post a video and give us all more basis for conversation. that conversation strongly influences the dictators.

you will never get the clarity you seek about how many videos are needed

Then there's no point or substance in proceeding.

they read every argument

I am happy to hear and I am sorry if I did any blasphemy.

#156
kaakuu - January 5, 2010 - 07:16

Dries: I've organized idea polls and feature ratings ...

Kaakuu: Are these on drupal.org persistently like the sites linked in #102 ? Can someone post the links ?

No answer

Now I am glad to know after so many days that it was being 'read'. I am not glad that it is 'read only' and not 'read-write', that essential suggestions are not accepted, and something which is part of other such community. So no point whether any one is reading it or not but thanks to you for pointing out.

#115
@moshe I mean no disrespect. - MFER

I repeat the same - saying these, I mean no disrespect.

I was just watching a video and noticed that the shortcut header has a drop shadow on the admin pages. I was thinking the shortcut header was the admin header, rather than an admin header over an admin page. Meaning, the shortcut header is an admin header over the rest of the site, but part of the admin section, not another admin section on top of the admin section on top of the front theme section.

There are technically four layers. In order: the front theme layer, the gray admin layer behind the overlay layer, the overlay layer, and the shortcut header layer. Also when we close the overlay, we don't go to the gray admin layer underneath, we jump right back to the front theme layer.

Also I kept wondering what was being hidden from me on the gray admin layer behind the overlay. Maybe the solid gray needs to be transparent to see the front theme underneath?

Conceptually I feel it's more to juggle in the brain. Has anyone else noticed this?

Here's the video:
http://learnbythedrop.com/drop/154

@kaakuu:

"essential suggestions are not accepted" - I would take strong exception to that. You may feel like you're not being heard, but webchick & several of the core maintainers were in intense discussions on IRC about how to resolve this very issue. Believe me, the core committers & contributors are aware of the community's opinions on this issue, and are trying to find a solution that is optimal for everyone.

Also, "talk is silver, code is gold," as Dries said in his keynote at Drupalcon. The work that kika, cha0s, and David_Rothstein have done should fork into a separate issue where it can get the discussion that it deserves.

The only thing more that should be in this issue, imo, is qualitative (and quantitative?) reports from user testing, as per eigentor's definition. By that definition, I don't think any of us have done user testing. That would be much more convincing to the core committers than personal opinions, whether mine or yours or anyone else's.

I would like to see some user testing with people with attention deficit disorder, dyslexia, and other cognitive impairments. Also people who, because of low or moderate low vision, need high contrast or use screen magnifiers.

My reading on usability testing with such populations makes me think that they will find Overlay, as used here, highly confusing.

On the other hand, they probably would find the approach @kika, @David_Rothstein, and @cha0s are working on to be quite usable.

Another condition to test: How well overlay works for people administering sites containing hundreds, if not thousands, of pages. How, in that narrow frame allocated to the underlying page, will we ensure that each page looks distinctly different?

@EvanDonovan -

Except unless I am mistaken THIS WAS TALK before being code.

And that is the MAIN thing reproached to this (in my book really BAD) idea : it was not a module, nor a contrib, and there was not even a similar module in the contribs, no past feedback, no experience and no maturation.

If some were following their OWN mantras, this should be a module, live in contrib for a while, and IF accepted and used and proved useful ,moved into Drupal main distrib, in core **optional** and probably NOT into "CORE" since it is hard to justify this a being CORE to the functioning of drupal.

It feels like Double standard and Double langage here I am sorry.

Great, Generous and very Valuable People are working their "ass off" under criticisms on this thing (something that should be really bad and though on them, and is a bit unfair) because of exactly that.

I hate to keep this thread alive longer than need be, but I'm curious: are there any plans to test Overlay before D7 is released? I'm guessing it would take a few weeks to a month to schedule, a few days to test, a week or two to analyze, and then who-knows-how-long to fix any issues that arise.

My big question here is: will this module be allowed to stay in core in lieu of tests that are probably not coming soon and given the contentious nature of this module?

For reference, currently 8 out of 78 critical issues (10.25%) are related to Overlay, and IMO many of the "normal" issues are still pretty serious. And mind you, this is before any issues that user testing might raise.

I'm interested in Alex UA's question being answered as well.

You see, it's great that we identified where users were having problems, and then thought up of a solution called overlay to solve the problem. The problem here seems to be that you are acting purely on theory at this point, and you haven't actually user tested the overlay because the reality is, it's not even done. Is this what faith-based development looks like?

Agreed that overlay requires testing so that it can be improved. Usability testing with overlay must include users with a variety of disabilities and who use a variety of assistive technology.

To connect this to another thread #716612: Overlay is not accessible to screen reader users, this quote strikes me as alarming:

We need to accept that barring a miracle, D7 is going to release with an overlay module that is not accessible to screen reader users.

Is this really acceptable? I believe it would make it unlawful for any gov't agency or university to use Drupal "out of the box", would open Drupal up to FUD attacks in sales to these orgs, and could potentially hurt adoption in many orgs that fear being sued for lack of accessibility. Most likely, users will be able to disable the overlay either at install or once they're using the site, but does anyone suspect that people selling proprietary garbage, or even other OSS products, will care much about that distinction?

To be clear: Overlay has been tested (by Everett and others) for users of screen readers and currently fails. It obviously fails for many/most current Drupal developers. So, two informal tests indicate it doesn't work and ...... tests indicate it helps solve the problem it set out to solve (which I have never been able to fully ascertain, but it has something to do with 'context').

I will like to add that there is widespread adoption of mobile devices starting from web enabled simple cellphones to ipads. While D6 and D5 admin interface had no major problem OUT OF THE BOX in such devices this Overlay (itself a bug, imho) either fails to work or works improperly or confusingly or hangs.
With emergence of new mobile OS and browsers on the rise and unpredictability of interactions of those with such complex thing as this overlay OOB experience becomes an unnecessary casualty.

I currently have no screenshots or videos but I think big brothers should test this aspect also. Better still, keep it off by default :)

Post with a bias (I dont like the Overlay)

It was my understanding that for a module to make it into core it first must have been tried and tested as a contrib module, and if there is a widespread adoption it can make it into core.

Exactly for the reason that Drupal is for the people by the people. Every installation is a vote towards a module, hence usage stats come in handy in such a decision... I dont believe such an "untested and unapproved by the masses" module should make it in, just because a few select people thought it would be cool.

I'll tell you one thing from somebody who didn't much like the overlay in D7 along with certain performance issues with Drupal. Ever since I bought a new computer Drupal has been amazingly fast :) the overlay in D7 too no issues. I take back everything I said about Drupal well almost everything he he. You really need a fast computer to appreciate it. Old computers no longer cut it, same for old cars and old gals doh!

OK, we really need some action here, as we're now in the beta phase already and have had no substantial progress on this for months. We should probably close this issue in favor of #685046: Test Plan for the Overlay since the most reasonable conclusion is that actual end-user testing results will determine the value (or detriment) of having overlay in core. Although many core developers hate the overlay, the overlay wasn't designed for core developers and scrapping the overlay without adequate user testing would be a mistake. Let's do this properly and move to #685046: Test Plan for the Overlay.

Ya know, being disqualified as a "user," even though I do some development and administration, really bugs me. Just saying.

Sadly, this issue has far outlived its usefulness. And, now that it's over 300 comments, it's a pain in the butt to even work with. The likelihood that more comments here will contribute anything to Drupal core are becoming vanishingly small. So, I'm locking comments on this thread.

Interested parties that actually want to help test the overlay should move here:

#685046: Test Plan for the Overlay

If you just want to voice your (justified) opinion that you don't like the overlay, please don't bother. :/

Thanks,
-Derek