Opened 11 years ago
Closed 9 years ago
#21947 closed defect (bug) (wontfix)
Fix 3-column dashboard display
Reported by: | belg4mit | Owned by: | |
---|---|---|---|
Milestone: | 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)
Change History (33)
#4
@
11 years 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.
#5
follow-up:
↓ 6
@
11 years 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?
#6
in reply to:
↑ 5
;
follow-up:
↓ 8
@
11 years 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; }
@
11 years ago
Disentangle 3 & 4 column settings, lower size thresholds, allowing user to make best choice for him-/herself
#8
in reply to:
↑ 6
;
follow-up:
↓ 9
@
11 years ago
Replying to belg4mit: It's not going to be that easy :)
Some screenshots with dashCols.patch:
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).
#9
in reply to:
↑ 8
@
11 years 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--
#10
follow-up:
↓ 11
@
11 years ago
Note that all of your screenshots have the admin menu collapsed, while azaozz's does not.
#11
in reply to:
↑ 10
;
follow-up:
↓ 12
@
11 years 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.
#12
in reply to:
↑ 11
@
11 years 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.
#13
@
11 years 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!).
#14
@
11 years 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.
#15
@
11 years 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?
#17
@
11 years ago
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.
#18
@
11 years 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).
#19
@
11 years 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.
#20
@
11 years 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.
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.