WordPress.org

Make WordPress Core

Opened 19 months ago

Last modified 9 months ago

#21947 new defect (bug)

Fix 3-column dashboard display

Reported by: belg4mit Owned by:
Milestone: Awaiting Review Priority: low
Severity: normal Version: 3.4
Component: Administration Keywords: has-patch needs-refresh
Focuses: ui Cc:

Description

Issue #20015 'enhanced' the dashboard with a pure-CSS based multi-column dashboard. Excellent.

The CSS used makes gross assumptions about how many columns are appropriate for different-sized displays. Double plus ungood.
Users should be left to decide how many columns they wish to use.

There was considerable discussion of this when 3.4 was released, but no remedy yet, other than to hack away at the CSS of one's install, precluding upgrades; I've changed @media only screen and (min-width:800px) and (max-width:1200px){ to @media only screen and (min-width:800px) and (max-width900px){ in wp-admin.css to get a usable interface.

Attachments (10)

dash3.png (60.6 KB) - added by belg4mit 16 months ago.
3 column dash on "small" screen
dashboard-900px-3col.png (47.0 KB) - added by azaozz 16 months ago.
dashCols.patch (2.2 KB) - added by belg4mit 16 months ago.
Disentangle 3 & 4 column settings, lower size thresholds, allowing user to make best choice for him-/herself
dash-601px.png (41.6 KB) - added by azaozz 16 months ago.
dash-901px-3col.png (45.7 KB) - added by azaozz 16 months ago.
dash-901px-4col.png (41.8 KB) - added by azaozz 16 months ago.
patched-3col.jpg (216.0 KB) - added by belg4mit 16 months ago.
Patched 3col in FF10 ESR
patched-4col.jpg (259.8 KB) - added by belg4mit 16 months ago.
Patched 4col in FF10 ESR
unpatched-3col-chrome.png (366.4 KB) - added by belg4mit 16 months ago.
Chrome column folding issue in unpatched CSS
column-overlap.patch (639 bytes) - added by belg4mit 16 months ago.
Secondary patch to fix overlapping columns with expanded menu

Download all attachments as: .zip

Change History (32)

comment:1 SergeyBiryukov19 months ago

  • Component changed from General to UI

comment:2 SergeyBiryukov16 months ago

  • Component changed from UI to Administration
  • Keywords ui-focus added

comment:3 azaozz16 months ago

  • Priority changed from normal to low

The current css tries to maintain min-width for the dashboard postboxes/widgets. Yes, the values in @media are averages. In some cases it may seem that 1200px is too much depending on what postboxes are shown. In other cases it's just right.

Thinking that preventing overlapping postboxes (broken looking dashboard) is better UX than allowing more columns on narrower screens (keep in mind that relatively few users change Screen Options).

If we need to change the trigger values in @media, would be nice to see some screenshots with the proposed changes in action.

belg4mit16 months ago

3 column dash on "small" screen

comment:4 belg4mit16 months ago

It makes no sense to me that screenshots should be required when the principle of least surprise dictates that the change should not have been made in the first place; don't take away features, and leave the user in control. Nevertheless, I have uploaded a snippet of my dashboard, showing the effect of customized CSS to allow 3 columns.

comment:5 follow-up: azaozz16 months ago

Related #17586.

If I understand this correctly, you propose to reduce the width where 3 columns are possible to 900px. This is what I see with 3 columns @ 900px: dashboard-900px-3col.png​.

In any case that css is in need of improvement. It should separate 3 and 4 columns the same way it separates 1, 2 and [more]. @belg4mit would you be willing to patch that?

comment:6 in reply to: ↑ 5 ; follow-up: belg4mit16 months ago

Replying to azaozz:

Related #17586.

...

In any case that css is in need of improvement. It should separate 3 and 4 columns the same way it separates 1, 2 and [more]. @belg4mit would you be willing to patch that?

That's an odd screenshot, but as you noted in the other ticket, the purpose of the multiple settings is to let the user pick the best one, especially since browsers differ in their interpretations of CSS i.e; the column margins should prevent that, given that that there are no positive min-widths for their contents. Added is a patch to disentangle the 3 and 4 column options. Setting additional columns is left as an exercise for the reader.

It also lowers the threshold for two columns to match the absolute minimum of 300px per column for the dashboard itself, not the editor. And it removes some (seemingly) redundant code:

        #dashboard-widgets #postbox-container-3 .empty-container,
        #dashboard-widgets #postbox-container-4 .empty-container {
                border: 0 none;
                height: 0;
                min-height: 0;
        }

Which is covered by:

.metabox-holder.columns-1 .postbox-container .empty-container,
.columns-2 #postbox-container-3 .empty-container,
.columns-2 #postbox-container-4 .empty-container,
.columns-3 #postbox-container-4 .empty-container {
        border: 0 none;
        height: 0;
        min-height: 0;
}

Last edited 16 months ago by belg4mit (previous) (diff)

belg4mit16 months ago

Disentangle 3 & 4 column settings, lower size thresholds, allowing user to make best choice for him-/herself

comment:7 SergeyBiryukov16 months ago

  • Keywords has-patch added

azaozz16 months ago

azaozz16 months ago

azaozz16 months ago

comment:8 in reply to: ↑ 6 ; follow-up: azaozz16 months ago

Replying to belg4mit: It's not going to be that easy :)

Some screenshots with dashCols.patch:

Dashboard @ 601px:

Dashboard @ 901px with 3 columns selected:

Dashboard @ 901px with 4 columns selected:

To-do:

  • 600px is too narrow to switch to two columns.
  • 900px is too narrow to switch to three columns.
  • When switching from four to three columns the forth column should move under the third (same as when switching to two or one column).
Last edited 16 months ago by azaozz (previous) (diff)

belg4mit16 months ago

Patched 3col in FF10 ESR

belg4mit16 months ago

Patched 4col in FF10 ESR

comment:9 in reply to: ↑ 8 belg4mit16 months ago

  • 600px is too narrow to switch to two columns.
  • 900px is too narrow to switch to three columns.

No, it's not. Just because some are using browsers which squish things together does not mean others should have their options unnecessarily limited. If someone is using a browser that causes column overlap that they cannot tolerate, they can simply select one fewer columns or resize the window. Those of us that are using browsers which behave nicely can have more columns e.g; Chrome and Firefox ESR. See original screenshot dash3.png for an example of three columns at 900 px in Firefox ESR.

That is the whole point of this ticket: return power to the user.

  • When switching from four to three columns the forth column should move under the third (same as when switching to two or one column).

It does that already/still in FF, but it seems in Chrome the 4th column contents can be in either the 2nd or 3rd column, depending upon the width of the window. This issue exists even with the original CSS. Webkit--

Patched 4col in FF10 ESR
Patched 3col in FF10 ESR
    Chrome column folding issue in unpatched CSS

Last edited 16 months ago by belg4mit (previous) (diff)

belg4mit16 months ago

Chrome column folding issue in unpatched CSS

comment:10 follow-up: nacin16 months ago

Note that all of your screenshots have the admin menu collapsed, while azaozz's does not.

comment:11 in reply to: ↑ 10 ; follow-up: belg4mit16 months ago

Replying to nacin:

Note that all of your screenshots have the admin menu collapsed, while azaozz's does not.

Ah, good catch! With an uncollapsed menu (blechh) I can also get overlapping columns. I will poke around, but the width triggers are then dependent upon whether body.folded is set, and that's not accessible in a media query.

comment:12 in reply to: ↑ 11 azaozz16 months ago

Replying to belg4mit:

...but the width triggers are then dependent upon whether body.folded is set, and that's not accessible in a media query.

Yeah, that's the catch... The menu is non-folded by default. It auto-folds at 900px but the user can unfold it. So we will have to support non-folded menu on all widths.

comment:13 azaozz16 months ago

Looking at this more: we can have different trigger widths for @media that also depend on body.folded and body.auto-fold. Even re-think/re-code the whole css that auto-folds the menu and moves dashboard columns around. A bonus: @media rules don't work in IE < 9, so we don't care about these (no IE7 compat, yay!).

Last edited 16 months ago by azaozz (previous) (diff)

belg4mit16 months ago

Secondary patch to fix overlapping columns with expanded menu

comment:14 belg4mit16 months ago

The column-overlap.patch should be applied atop the first. It changes the left-hand menu to be position: fixed, like the admin bar, thereby allowing us to replace margin-left of the content container with a left position. This seems to work fine for me in FF ESR and Chrome.

Last edited 16 months ago by belg4mit (previous) (diff)

comment:15 belg4mit13 months ago

Any chance this simple fix can get a little attention and make it into 3.6 since it wasn't in 3.5.1?

comment:16 helen13 months ago

  • Keywords needs-refresh added

comment:17 azaozz13 months ago

Related #21795 and #23817.

The best enhancement here is to take into account whether the menu is collapsed when calculating how many columns to show. This is quite tricky as the menu can be collapsed and expanded by the user (with css class) or from responsive css. Implementing three-way switch for collapsing the menu (and always having a class to tell us which option is set) would simplify this.

Imho this should be handled together with the above two tickets.

comment:18 belg4mit13 months ago

Those tickets are not really related as far as I can tell.

Please also see previous messages in this ticket.
These patches already handle expanding and collapsing of the menu (#14 above).

comment:19 azaozz13 months ago

These patches already handle expanding and collapsing of the menu...

I may be missing something but applying both dashCols.patch and column-overlap.patch breaks the Dashboard badly when a user folds/unfolds the menu.

Also the setting for columns switches from 4 to 3 at about 1200px but if a forth column is displayed it stays as-is and the columns overlap. The forth column should move under the third column in that case.

comment:20 belg4mit13 months ago

Would you mind providing some detail as to the platforms on which you are experiencing a "badly broken Dashboard", or even a screenshot? The patched CSS works well for me on FF10 ESR, FF18, Chrome, Chrome OS, and IE10... regardless of the state of the menu, or it being toggled once the page is rendered.

Under some circumstances the columns may overlap by a few pixels, but I do not think "badly broken" would be a fair characterization of the situation, which is an artifact of different rendering engines handling CSS differently; it does not occur universally. Regardless, it is central to the whole purpose of this patch: The *user* should have the power to control their dashboard display, as they did pre 3.4. If a user wishes to sacrifice a small amount of "beauty" for functionality, they should be able to do so. If a 4-column interface is too muddled for them with their particular browser and window-size, they can opt to use 3 columns. This allows more people more options, versus the situation inflicted on users since 3.4, in which those whom have the ability to display 4 columns well (see screenshots) are precluded from doing so by arbitrary constraints.

The 3.4 change was made to remove JavaScript dependency. These patches preserve that, while restoring the full range of functionality previously available.

Last edited 13 months ago by belg4mit (previous) (diff)

comment:22 mercime9 months ago

  • Cc mercijavier@… added
Note: See TracTickets for help on using tickets.