Problem/Motivation

Since we have made the node edit form two columns the same logic behind doing that—reducing scroll, simplifying experience, progressive disclosure— also applies elswhere, for instance here in place blocks modal.

Following the beta guidelines the issue qualifies for inclusion in 8.0 since:

  • It's not a feature
  • It's unfrozen (CSS and markup)
  • It's a prioritized change (usability)
  • It's impact outweighs disruption. No disruption, it's an isolated change.

Currently even with only core default form items the modal extends below the fold on most desktops.


Current appearance

current

Proposed resolution

Proposed changes include:

  • Expanding the default width of the modal to accommodate the new column
  • Removing extra padding around the column tabs so that they "mortice" to the edges of the adjacent divs
  • Removing extraneous styling from the column to simplify the experience and reduce unnecessary noise (this also has a WCAG benefit in that the open tab background becomes a darker color)
  • Using an accordion behavior so that a) the modal does not expand to force scroll again and b) we remove the awkward behavior where a collapsed set can be in focus while an adjacent uncollapsed one is not in focus.
  • In order to maintain scannability when going to an accordion we add back the summary text from vertical tabs, as well as some of it's styling.
  • Additionally we move the region setting to right below title since it is the primary action of the modal.

User interface changes

Normal state

normal

Expanded and in focus

expanded focus

Expanded and not in focus

expanded not focus

API changes

This makes #2061863: Make two column node CSS reusable even more important.

Remaining tasks

Contributor tasks needed
Task Novice task? Contributor instructions Complete?
Update the issue summary Instructions Yes
Design review
Create a patch Instructions
Add automated tests Instructions
Draft a change record for the API changes Instructions
Improve patch documentation or standards (for just lines changed by the patch) Novice Instructions
Manually test the patch Novice Instructions

Comments

tim.plunkett’s picture

Status:Active» Needs review
StatusFileSize
new129.01 KB
new137.6 KB
new4.88 KB
PASSED: [[SimpleTest]]: [MySQL] 58,037 pass(es).
[ View ]

Here is a first attempt.
However, I'm honestly not sure if this is an improvement.
Because this will usually be opened in a modal, splitting the available width between two columns leads to it being rather squished.
In addition, we lose the "summary" for each tab, like what roles or content types it is visible for.

Current in HEAD:
Screen Shot 2013-09-01 at 1.59.18 PM.png

With this patch:
Screen Shot 2013-09-01 at 1.59.20 PM.png

Bojhan’s picture

I agree with tim here, that the benefit seems quite low. Its visually a little cleaner, but because it is such a confined area it looks rather cramped. The veritcal tab, allows for at least vertically a more focused UI. Sidebars tend to work really well when the main column is long, when its short - like this, the benefit is lower. I also have no clue how this stretches to a pattern across core/contrib.

tkoleary’s picture

@Bojhan

I agree with tim here, that the benefit seems quite low.

Really? I think this is a HUGE improvement. Yes, it is less imperative on a smaller dialog like this but your last comment "how this stretches to a pattern across core/contrib." is where the real benefit will be as we get into longer and more complex forms.

@Tim.Plunkett

Because this will usually be opened in a modal, splitting the available width between two columns leads to it being rather squished.
In addition, we lose the "summary" for each tab, like what roles or content types it is visible for.

I think the "squishing" issue has to do with the default width of the modal being too narrow.
On the "summary" question I would add them back. I definitely think they add value.

tkoleary’s picture

StatusFileSize
new64.56 KB

@Bojhan, @tim.plunkett

Here's a rough estimation of how it should ultimately look with Seven style patches applied. Hacked together with Chrome inspector but all possible with current markup.

IMHO looks much better than before taken in totality.

image

tkoleary’s picture

@Bojhan, @tim.plunkett

Angie commented that the machine name still wraps. This can be solved by increasing the size of the modal (currently 700px), or by setting a min width on machine name and making it display inline block so the whole thing kicks down below the title field at his width.

Perhaps both.

tim.plunkett’s picture

My screenshot of the new modal bumped the width up to 800px.
What is the largest we can safely make a modal?

The "summary" JS isn't natively compatible with the details elements in the style, I'll have to play with it more.

tim.plunkett’s picture

StatusFileSize
new756 bytes
new4.89 KB
PASSED: [[SimpleTest]]: [MySQL] 58,418 pass(es).
[ View ]

Still at 800px, I adjusted the proportions, and added the inline-block for the machine name.

The padding on the top and right of the modal is really out of normal control of the content, so I'm not using any crazy tricks to make the right column flush just yet.

Wim Leers’s picture

StatusFileSize
new141.94 KB

Screenshot of #7:

Screen Shot 2013-09-06 at 16.30.56.png

tkoleary’s picture

@Tim Plunkett

The padding on the top and right of the modal is really out of normal control of the content, so I'm not using any crazy tricks to make the right column flush just yet.

Nothing "crazy" is needed :). Just:

.block-secondary, .block-list-secondary {
  position: absolute;
  right: 0;
  top: 0;
  border: 0px;
  border-left: 1px solid #999;
  height: 100%;
  overflow: scroll;
}
tkoleary’s picture

StatusFileSize
new50.67 KB

Above code produces this:

image

Note: The scroll on the column is so that you don't scroll the main form out of view.

tkoleary’s picture

Sorry,

The selector was too specific. Should be:

ui-dialog .block-secondary  {
  position: absolute;
  right: 0;
  top: 0;
  border: 0px;
  border-left: 1px solid #999;
  height: 100%;
  overflow: scroll;
  background: #eee;
}
Jeff Burnz’s picture

Just a comment, which may or may not be out of scope here, because I can't scroll the modal it can be obscured by both toolbar and the fold (current design in head), the new design proposed here would not escape this problem - if I can't scroll it away (like I can with Views) then I might not see the submit, or a field, aka its hiding behind the toolbar/tray etc.

Users need control over the scroll, like Views allows, so if stuff don't fit vertically I can just scroll to see it all. I dont wanna be zooming in/out to submit etc.

FWIW I like the current design in head more than the two columns proposed here, the second col is cramping up stuff and vertical tabs are so common in core as a UI pattern, they make sense imo.

jessebeach’s picture

Status:Needs review» Reviewed & tested by the community

The padding on the top and right of the modal is really out of normal control of the content, so I'm not using any crazy tricks to make the right column flush just yet.

I have to agree with Tim here. I've very reluctant to set a column like this to position absolute in a one-off way. Absolute position is meant to place an element in a very specific location, not to defeat padding or get around default styling. If we want to have elements like this flush with the edges of its container, then we will need to flip the padding on the container to margins on the contents. That's a very big change. This is also something a theme could do in order to achieve a very specific visual style. But for core, it has implications beyond this form. If we absolutely position just this one piece, then it will no longer flow and might potentially break responsive layouts of the form elements.

The major issues I'm having with this patch all have to do with the persnickety, naughty and opinionated behavior of the Drupal dialog. It jumps around and won't resize well.

We have an issue to deal with collisions with displacing elements like the Toolbar:
#2067263: Drupal dialog placement must take displacing viewport elements, like the Toolbar, into account when calculating placement

Z-indexing issue:
#2072037: Drupal dialog modal background z-index is set too low to reliably occlude core UI components

And resizing issue:
#2083703: Resizable Drupal dialog refuses to resize if given a specific width option

These are all tagged with modal placement
https://drupal.org/project/issues/search/drupal?issue_tags=modal%20place...

The code in this patch involves simple template updates that leverage core systems. I don't want to go solving core problems here or hacking in overrides. The more pain we expose through using these systems, the more pressure we'll feel to address them during UX polish.

jessebeach’s picture

Status:Reviewed & tested by the community» Needs work

Sorry, didn't mean to RTBC. This design needs more thought. It requires a fairly wide screen to view the form. We're not going to be able to take advantage of Media Queries here because the viewport size is not a true measure of the available space. The dialog width is really the triggering bounding container. And the dialog width depends largely on the dialog contents.

If we really need this much interactive stuff in a form, then the form should be a page, not a dialog. This issue needs more design work.

tkoleary’s picture

@jessebeach

Thanks for the detail. That certainly puts a different perspective on it.

Having said that let me just clarify my thinking on this. First off the absolute positioning is a red herring. That was merely the most expedient method to get the desired appearance, I could have as easily used negative margin but that seemed even more hacky.

Fundamentally, the face that padding effects two columns is the problem. The purpose of padding (at least I as I understand it from a design perspective) is to provide space between content (text, images etc.) and it's container. The error here, it seems to me, is that we have padding on a container that contains two columns. Obviously the content on the left requires padding, but not it's parent, in this case #drupa-modal. All that is needed here is to remove the padding on #Drupal-modal, of course the implication of that is that anything that goes into #drupal-modal would require it's own padding. But if we agree that modals should be allowed to have two columns then the default should be at least one column with padding.

That seems far less hacky to me, and shouldn't adversely effect any of the above issues.

tim.plunkett’s picture

Assigned:tim.plunkett» Unassigned
Issue tags:+Needs usability review, +Needs design review

Not much I can do here until there is consensus.

tkoleary’s picture

@Tim Plunkett

Jesse and I discussed. This is not on the must have list so it's after whatever's on your plate anyway. Let's discuss in Prague.

Bojhan’s picture

Version:8.x-dev» 9.x-dev
Issue tags:-Needs usability review

Nothing to review here, it seems like its clear there are many issues from both a UX as a technical side.

catch’s picture

Version:9.x-dev» 8.1.x-dev
catch’s picture

Status:Needs work» Postponed (maintainer needs more info)
Issue tags:+Needs issue summary update
tkoleary’s picture

Now that we have the two column node edit form it makes sense to use the same pattern in other places as well, especially modals where the experience should be as compact and immediate as possible. The place blocks modal is a good place to start since this will be one that site builders will use quite often.

tkoleary’s picture

StatusFileSize
new34.39 KB
new37.14 KB
new38.08 KB

Updated issue summary

tkoleary’s picture

Updated summary

tkoleary’s picture

Issue summary:View changes
tkoleary’s picture

Issue summary:View changes
StatusFileSize
new28.99 KB
new30.36 KB
new29.67 KB
tkoleary’s picture

Issue summary:View changes
StatusFileSize
new36.36 KB
new37.26 KB
new34.19 KB
new37.26 KB
tkoleary’s picture

Issue summary:View changes
tkoleary’s picture

Issue summary:View changes
tkoleary’s picture

Issue summary:View changes
StatusFileSize
new247.94 KB
tkoleary’s picture

Issue summary:View changes
tkoleary’s picture

Issue summary:View changes
tkoleary’s picture

@catch

re#20 see the motivation section I added to the summary.

This seems to me to qualify. I think it will be a big improvement

YesCT’s picture

adding usability tag. updating the beta allowed and a typo in summary.

tkoleary’s picture

Issue summary:View changes
tkoleary’s picture

Issue summary:View changes
tkoleary’s picture

Issue summary:View changes
jibran’s picture

YesCT’s picture

Version:8.1.x-dev» 8.0.x-dev
Issue summary:View changes
Status:Postponed (maintainer needs more info)» Needs review

so, evaluating for beta seems to disagree with the version. changing the issue meta data.

note, the review needed here is of the new design.

Bojhan’s picture

If we reuse a pattern, please re-use the pattern. Don't add your own styling.

tkoleary’s picture

@bojhan

Part of the idea here is to remove an anti-pattern to the style guide and to do it everywhere. See referenced issue.

Bojhan’s picture

@tkoleary Sure, can we move that to that issue though - we don't have to sideline it in here.