| Project: | Drupal core |
| Version: | 8.x-dev |
| Component: | overlay.module |
| Category: | task |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | needs work |
| Issue tags: | Needs design review |
Issue Summary
Disclaimer: this proposal fully acknowledges the UI freeze and the nearing beta status and focusing to the critical issues. It is just something what I need to get out of my system. I am totally ok with a ">> drupal-8.x-dev" status for this. I know this change is bold and might affect a lot: from eating up community energy to already working service UIs built on top of d7
But here is the dream: alter radically Drupal overlay look, to make it more polished and something that feels solid -- ditching the the current "huge lightbox with ears" concept and align it more to the lines of "os window / chrome tabs on header". There are sure lot of problems of this, starting from "too much gray in top of the page" to the "overlay development took almost a year, why break all this", but hold on just a minute.
Current state:
The proposal mockup:
(Totally optional) Subtle background gif animation when loading a page mockup:
I whipped up a simple patch: it's just some simple overlay-parent.css changes (revealing some jQuery UI styling beneath + some beauty tweaks) and changed modules/overlay/images/close.png (now without the white "ear" part, making it acually reusable in other parts of Drupal).
This is how the patched version looks in Chrome OSX:
Here's how to test it:
1. Apply the patch
2. Replace the modules/overlay/images/close.png with the close.png attached to this issue
This just in: Bohjan already noted that it's very likely too late. D8?
| Attachment | Size | Status | Test result | Operations |
|---|---|---|---|---|
| radical_overlay_1.patch | 1.72 KB | Idle | PASSED: [[SimpleTest]]: [MySQL] 20,048 pass(es). | View details | Re-test |
| close.png | 2.91 KB | Ignored: Check issue status. | None | None |
Comments
#1
Yeah, looks like a D8 issue to me. But let's definitely have the conversation then.
Side note which nobody may care about: The reason I agreed to maintain the overlay module in the first place is that I think Mark and Leisa's ideas deserve a release cycle where we implement them as faithfully as possible. I know we've already deviated from the design in some places where we had to, and in some places where the community simply revolted. But in general I would like to see their vision reflected in D7 so it gets some real mileage. For D8 we may very well be sick to death of it all, and itching for a redesign, in which case this issue will come in very handy. :)
#2
Yeah, I actually love the way this looks. It just feels much cleaner to me rather than an octopus window with tentacles/tabs everywhere. But I also agree that it's D8 scope for this at this point.
#3
Agreed that this is probably D8 in terms of scope (and changing the issue back to reflect that ;]), but I very much like the direction this is headed in. Kudos!
In the interests of discussion, however, it seems like the added contrast of the "+" button next to the heading demands quite a bit of visual attention, without any clear labeling as to what it's supposed to do in the first place (until it's moused over). I don't have any concrete, mocked-up suggestions yet on how to fix this, but just shooting from the hip, perhaps it could be grouped with the close button in the upper right?
#4
There is a (frighteningly) open issue at #685046: Test Plan for the Overlay for trying to test out the overlay with real people. I think we really need to start making decisions based on user testing. It doesn't really matter who designed it or what their ideas were, right? So, since there's a patch here, maybe if somebody goes through and tests out different scenarios (including one with this patch applied) and this proves to be the best, this issue could be moved back to 7.x.
Personally, I'm a little skeptical of it, though - I think it looks nice in some ways, but it makes the overlay take up even more space on the page than it currently does. At some point, it would take up so much space that there's no point in even making it an overlay :)
#5
If we ended up with hard data proving this was a significant, measurable improvement over the current design, it might be worth pursuing for D7. But frankly even then I would be skeptical. I do believe it matters who designed what, to the extent that our current admin interface was designed as a package, and I don't like the idea of redesigning it piecemeal late in the cycle when we don't have time to iterate on the changes.
#6
I wonder if the design here (with a different implementation) would help with #782656: The overlay title and tabs should be inside the child window, not the parent window? - I think it probably would. If so, it would fix a lot of bugs too :)
#7
subscribing
#8
I like the new look, the header could use a bit of sprucing up. I'm not a themer/designer, so I did my best to update the patch to HEAD. Now looks like this on Chrome/Mac:
Is it still up for debate?
#9
The last submitted patch, overlay-redesign_header-782096-8.patch, failed testing.
#10
Guess I need to include the --binary in the patchfile now?
#11
Work for me thanks kscheirer. nice work all!
#12
Has this been tested on all supported browsers?
I looked at it a bit (on Firefox only) and the shortcut module's "+" button (next to the page title) looks a little sloppier with this patch than without it. Right now, the button looks more like http://kika.trip.ee/files/radical_overlay_patch.png (the initial patch) than http://kika.trip.ee/files/radical_overlay_1.png (the proposed mockup).
I'm also not sure: Has this change received sufficient design review? I'm still a bit curious about why it's a good idea to cover up even more of the underlying page than the overlay current does.... In addition, playing around with it now I got the impression that maybe this will result in the tabs on the right hand side of the page being less visible? (Hard for me to judge that since I know to look for them, but this patch definitely results in a decreased contrast between the tabs and the background, which is why I thought it might.) If so, that's a concern too, since I think we might already have an issue with those tabs not being very easy for people to notice, even as they are now.
#13
I would like to see more designers weigh in here as well.
I see a change to a LTR line of CSS, but no corresponding change in the RTL file, so marking the patch as needs work. Also, we need screenshots from supported browsers for both LTR and RTL before we can mark this RTBC.