Make WordPress Core

Opened 13 years ago

Closed 12 years ago

Last modified 12 years ago

#18198 closed task (blessed) (fixed)

Responsive Admin

Reported by: nacin's profile nacin Owned by: saracannon's profile saracannon
Milestone: 3.3 Priority: normal
Severity: normal Version:
Component: UI Keywords: has-patch
Focuses: Cc:

Description

The admin should be made more responsive for devices of various sizes.

Attachments (22)

18198.no-sidebar.png (85.3 KB) - added by SergeyBiryukov 13 years ago.
18198.wide-sidebar.png (109.7 KB) - added by SergeyBiryukov 13 years ago.
18198.has-right-sidebar.patch (786 bytes) - added by SergeyBiryukov 13 years ago.
narrow-column.png (95.5 KB) - added by scribu 13 years ago.
18198.save-auto-columns.patch (505 bytes) - added by SergeyBiryukov 13 years ago.
auto-column-collapse.png (40.0 KB) - added by DrewAPicture 13 years ago.
At about 680px, the menu collapses and the flyout is misaligned. Clicking on any other menu header restores the full-width menu.
18198.thickbox.png (89.4 KB) - added by SergeyBiryukov 13 years ago.
responsive-dashboard-patch.diff (2.0 KB) - added by saracannon 13 years ago.
CSS Dashboard Responsiveness When in "Auto"
18198.list-tables-posts.diff (1.9 KB) - added by helenyhou 13 years ago.
Responsive tables, pass 1 (posts/pages)
18198.list-tables-max-width.diff (609 bytes) - added by helenyhou 13 years ago.
Limit max width of widefat list tables, semi-arbitrarily to 2000px
responsive-cat-pages.diff (1.8 KB) - added by saracannon 13 years ago.
responsive category pages
18198.themes-css.diff (1.4 KB) - added by helenyhou 13 years ago.
CSS for theme screens, also limits plugin cloud tag width
18198.class-wp-theme-install-list-table.diff (5.1 KB) - added by helenyhou 13 years ago.
Modifications to the two list-table classes for theme screens
18198.theme-row-height.js (1.7 KB) - added by helenyhou 13 years ago.
JS to make each row of div's equal height on load/resize, from http://stephenakins.blogspot.com/2011/01/uniform-div-heights-for-liquid-css-p.html
18198.theme-screens.diff (6.4 KB) - added by helenyhou 13 years ago.
No borders, no JS
Screen Shot 2011-09-15 at 1.14.19 PM.png (153.0 KB) - added by andrewryno 13 years ago.
18198.theme-information.diff (380 bytes) - added by helenyhou 13 years ago.
Fix for theme information (install thickbox)
wpwhitespace.png (254.0 KB) - added by Viper007Bond 13 years ago.
18198.dashboard-whitespace.png (172.2 KB) - added by SergeyBiryukov 13 years ago.
18198.importers.diff (763 bytes) - added by helenyhou 13 years ago.
Import screen list table
18198-fix-tab-category-sidebars.patch (366 bytes) - added by sabreuse 13 years ago.
Fix for tab and category sidebars in post-new
18198-remove-table-maxwidth.patch (574 bytes) - added by sabreuse 13 years ago.
Per ui meetup discussion, remove max-width on tables (updated)

Download all attachments as: .zip

Change History (146)

#1 @ocean90
13 years ago

  • Cc ocean90 added

#2 @helenyhou
13 years ago

  • Cc helen.y.hou@… added

#3 @andrewryno
13 years ago

  • Cc andrewryno@… added

#4 @swissspidy
13 years ago

  • Cc hello@… added

#5 @sabreuse
13 years ago

  • Cc sabreuse@… added

#6 @saracannon
13 years ago

  • Cc sararcannon@… added

Initial discussion will be on the UI Blog: http://make.wordpress.org/ui

#7 @isaackeyet
13 years ago

  • Cc isaackeyet added

#8 @kovshenin
13 years ago

  • Cc kovshenin@… added

#9 @nerrad
13 years ago

  • Cc nerrad added

#10 @holizz
13 years ago

  • Cc tom@… added

#11 @tonyjansen_nl
13 years ago

  • Cc info@… added

#12 @jamalorg
13 years ago

  • Cc jmlworld@… added

#13 @azaozz
13 years ago

Possibly related #14423. We will probably need to address auto column switching for the dashboard and Write/Edit screens.

#14 @sbressler
13 years ago

  • Cc sbressler@… added

#15 @DrewAPicture
13 years ago

  • Cc xoodrew@… added

#16 @dremeda
13 years ago

  • Cc dre@… added

#17 @azaozz
13 years ago

In [18581]:

Auto column switching (post.php only for now), see #18198

#18 follow-up: @azaozz
13 years ago

Will need to select "Number of Columns: auto" from screen options to test the above patch.

#19 @kirasong
13 years ago

  • Cc mike.schroder@… added

This works well for me in (All OSX) Safari 5.1, Chrome Dev 14.0.835.18, Chromium Trunk (15.0.860.0 - Build 97745), Firefox 6, and iPhone iOS 4.3.3

#20 @GaryJ
13 years ago

  • Cc gary@… added

#21 @azaozz
13 years ago

In [18582]:

Auto column switching for the dashboard, see #18198

#22 @azaozz
13 years ago

Added the same method of auto column switching to the dashboard however it's not working well there. Moving postbox containers when they are empty is no good. Seems like we will have to rearrange the dashboard widgets inside the containers but that might be a bit too intrusive.

#23 in reply to: ↑ 18 ; follow-up: @westi
13 years ago

Replying to azaozz:

Will need to select "Number of Columns: auto" from screen options to test the above patch.

I got this auto-selected on one of my local test installs (maybe I had never selected an option previously).

I ended up with a new post page with nothing apart from a post editor and no way to publish posts :(

#24 in reply to: ↑ 23 ; follow-up: @azaozz
13 years ago

Replying to westi:

I got this auto-selected on one of my local test installs (maybe I had never selected an option previously).

Yes, the idea is to have 'auto' as default.

I ended up with a new post page with nothing apart from a post editor and no way to publish posts :(

This sounds bad... The current patch moves around the postbox containers, it doesn't care what's in them. Could you have a look in Firebug (or friends) and see where the postboxes actually are?

#25 @azaozz
13 years ago

Some more thoughts about the dashboard postbox placement: perhaps we can switch from having up to 4 columns to having one area with floated postboxes. This will automatically "push" them into 1, 2, 3 columns when the browser window is wide and back to 1 column then it's narrow.

We still can save the order of the postboxes, i.e. Right Now = 1st, Quick Press = 2nd, etc. and let the user rearrange that order. Then we can adjust the min-width and max-width with JS to force them to display in columns depending on the browser width.

#26 in reply to: ↑ 24 @SergeyBiryukov
13 years ago

Replying to westi:

I ended up with a new post page with nothing apart from a post editor and no way to publish posts :(

Same for me (see 18198.no-sidebar.png).

Replying to azaozz:

Could you have a look in Firebug (or friends) and see where the postboxes actually are?

Firebug shows negative margin, coming from wp-admin.dev.css:

.wide-screen .inner-sidebar {
    margin-right: -870px;
    width: 100%;
}

After switching to 2 columns, the sidebar is back, though it's noticeably wider than it was in 3.2.1 (see 18198.wide-sidebar.png).

@scribu
13 years ago

#28 follow-up: @scribu
13 years ago

After switching to 2 columns, the sidebar is back, though it's noticeably wider than it was in 3.2.1

I have the opposite problem: the left column doesn't extend all the way to the sidebar anymore: narrow-column.png.

#29 in reply to: ↑ 28 @SergeyBiryukov
13 years ago

Replying to scribu:

I have the opposite problem: the left column doesn't extend all the way to the sidebar

Turned out the sidebar is only wide right after changing the number of columns. After page reload, my screen is similar to yours, with lots of empty space.

#30 @SergeyBiryukov
13 years ago

Oh, that's only for two columns. For "auto", the sidebar is displayed with normal width during page load, and then fills the remaining space.

#31 @scribu
13 years ago

Indeed. However, switching to "auto" from post-new.php doesn't work.

#32 @SergeyBiryukov
13 years ago

18198.save-auto-columns.patch should fix saving "auto" columns number.

#33 @azaozz
13 years ago

In [18607]:

Improve auto column switching for post.php, see #18198

#34 follow-up: @azaozz
13 years ago

In [18624]:

Disable js moving of dashboard postboxes, add all of them in the first column on 'auto', see #18198

@DrewAPicture
13 years ago

At about 680px, the menu collapses and the flyout is misaligned. Clicking on any other menu header restores the full-width menu.

#35 @azaozz
13 years ago

In [18625]:

Toggle class 'responsive' on div.wrap when auto columns is toggled, see #18198

#36 in reply to: ↑ 34 ; follow-up: @nacin
13 years ago

Replying to azaozz:

Disable js moving of dashboard postboxes...

Wait, what? Are they no longer arrangable?

#37 @jane
13 years ago

They should still be drag and drop orderable.

#38 in reply to: ↑ 36 @azaozz
13 years ago

Replying to nacin:

Sry, bad wording of the commit message. Of course they are draggable/arrangeable, disabled the auto-arranging for narrow/wide screens as it will be handled in css (see today's #wordpress-ui chat).

@DrewAPicture think this may be caused by [18621] or stale cache.

Last edited 13 years ago by azaozz (previous) (diff)

#39 follow-up: @kirasong
13 years ago

Not sure how much of this is intended, but --

With this patch, when I switch to auto in the dash, it always moves to using one column, no matter the width.
When switching back to two columns, it adds the column, but all widgets in the dashboard stay in the first column until they're manually moved back to the second one.

#40 in reply to: ↑ 39 @azaozz
13 years ago

Replying to DH-Shredder:

Yes, @saracannon is working on the css atm, expect a patch soon :)

#41 @SergeyBiryukov
13 years ago

body { min-width: 950px; } from [18581] made thickbox windows too wide (see the screenshot).

#42 @saracannon
13 years ago

I've attached a diff that adds CSS3 Columns and responds with media queries when the dash is on "auto"

#43 @scribu
13 years ago

  • Keywords has-patch added

#44 follow-up: @scribu
13 years ago

Wouldn't it be better if the blocks inside media queries were indented?

#45 @saracannon
13 years ago

still got to test for browsers other than chrome.

#46 in reply to: ↑ 44 @GaryJ
13 years ago

Replying to scribu:

Wouldn't it be better if the blocks inside media queries were indented?

+1.

Sara's patch also needs the properties alphabetical as per the WP CSS standards, including putting the vendor-prefixed properties before their CSS3 standard counterparts.

#48 @ocean90
13 years ago

The CSS codings standard is still a draft. See ticket:16317#comment:8 and the following ones.

@saracannon
13 years ago

CSS Dashboard Responsiveness When in "Auto"

#49 @saracannon
13 years ago

Updated the Dash patch to make it work in FF by removing floats

#50 @azaozz
13 years ago

Trying to make responsive-dashboard-patch.diff play nice in all browsers but seems near impossible:

  • Chrome 'forgets' to add any vertical spacing on blocks that are inside a display:inline-block container, i.e. <p> has no top and bottom margins
  • Safari moves the content away from the container (looks quite weird)
  • Opera breaks in many different ways depending on page width
  • IE9 doesn't show columns at all...

Only FF seems to handle css3 columns + complex div with display:inline-block properly. What's even worse is that recent (not the very latest) versions of the browsers break in different ways too.

In that terms we should probably use some other styling to achieve similar results. Unfortunately that would mean we will have to use some minimal JS to help/trigger the css on page resize, hopefully not on page load.

@helenyhou
13 years ago

Responsive tables, pass 1 (posts/pages)

#51 @helenyhou
13 years ago

Just attached a very rough patch that starts maybe-responsive table stuff. Looks like this, except the tiny gaps between borders is gone (fixed it after I took the screenshot): http://cl.ly/063j2u3Y3I0G232l1p2Z

Things that I know about:

  • Checkboxes are hidden, so there's no bulk editing (and I can't seem to target just that select and button to hide)
  • Highly unlikely that it works in IE. At all. Haven't fired up the VM to look yet, but I don't see people using IE at 640px or narrower (the breakpoint I went with).

I think custom added columns should work just fine, but whoever adds them has to also use CSS to add their column label, as it's a pseudo-element.

This actually already looks okay in the other admin screens with list tables (plugins, users, etc.), but they'll need some specific tweaking for labels and some other layout things. Will keep playing with it.

Last edited 13 years ago by helenyhou (previous) (diff)

#52 @scribu
13 years ago

That's a really interesting layout, but I would choose bulk actions over responsive design any day.

What I'm trying to say is that we need those checkboxes somewhere. :)

Last edited 13 years ago by scribu (previous) (diff)

#53 @helenyhou
13 years ago

I think they can be brought back with some positioning work to make sense. Will also have to work on making Bulk Edit manageable at that width. Can anybody think of a way for a select all checkbox/link to make it back in? The thead/tfoot are hidden at this width.

#54 @scribu
13 years ago

I think the "select all" checkbox is not that essential, since you likely won't be able to see all the items at a glance, like you would on a normal screen.

Worst case, we use a little bit of JavaScript to show a custom control. It doesn't work without JS anyway.

#55 @helenyhou
13 years ago

I'd also lean toward not having select all, but we can get there later, I guess :)

Already have the checkboxes back in, right now positioned under the Title label: http://cl.ly/2Q062s1s2p1g271u0U03

Also, forgot to mention that I made the row actions visible, instead of a hover. Thought it made more sense for what are probably touch devices.

#56 follow-up: @jane
13 years ago

That's not a list anymore, though. You shouldn't have to scroll past each entry's metadata to read down the list on small screens.. that's actually making it *harder* to use. A better approach would be to not show all the columns by default at that size, so it can still be a list, with a toggle to display more or something.

#57 @jane
13 years ago

(And may I be struck with lightning as I'm agreeing with @scribu, but I agree the select all checkbox needs to be there.

#58 @jane
13 years ago

Oh, wait, I misread: scribu wants there to NOT be a select all checkbox, and I do. The world is right again. :)

#59 in reply to: ↑ 56 ; follow-up: @helenyhou
13 years ago

Replying to jane:

That's not a list anymore, though.

Very true. I'm a little conflicted, so just kind of experimenting with this approach. It's interesting, but definitely not quickly usable.

I think it would be pretty easy to remove all but the default core columns, but it doesn't seem possible to compensate for custom columns in terms of choosing which to show and which not to. For posts and pages, this might not matter a whole lot, but sometimes for custom post types you really need that information, or at least that's been my experience. I'm also biased toward wanting more information, though. Sticking with the standard table format would keep the select all checkbox, at least :)

Maybe the toggle for excerpt mode could switch between the two views? Would that be changing the effect of the button too much? It actually kind of visually represents the change pretty well.

#60 @DrewAPicture
13 years ago

You shouldn't have to scroll past each entry's metadata to read down the list on small screens.. that's actually making it *harder* to use.

+1

#61 @chexee
13 years ago

  • Cc chexee@… added

A pass at what the Menus screen for mobile might look like. I think this would be something for next cycle, but it got me thinking. Going to start on a tablet netbook optimised screens next.

Thoughts?

http://chx.mx//ao/w103mqp340wg0.png
http://chx.mx//13/pr6j4xmaas8oo.png

#62 in reply to: ↑ 59 ; follow-ups: @chexee
13 years ago

Replying to helenyhou:

Replying to jane:
I think it would be pretty easy to remove all but the default core columns, but it doesn't seem possible to compensate for custom columns in terms of choosing which to show and which not to. For posts and pages, this might not matter a whole lot, but sometimes for custom post types you really need that information, or at least that's been my experience. I'm also biased toward wanting more information, though. Sticking with the standard table format would keep the select all checkbox, at least :)

Would it be possible to make each "row" expandable (similar to how metaboxes work) where, by default they would only show only the title cell, but when tapped or clicked on they would expand below to show the rest of the meta data and actions?

#63 in reply to: ↑ 62 @sabreuse
13 years ago

Replying to chexee:

Replying to helenyhou:

Replying to jane:
I think it would be pretty easy to remove all but the default core columns, but it doesn't seem possible to compensate for custom columns in terms of choosing which to show and which not to. For posts and pages, this might not matter a whole lot, but sometimes for custom post types you really need that information, or at least that's been my experience. I'm also biased toward wanting more information, though. Sticking with the standard table format would keep the select all checkbox, at least :)

Would it be possible to make each "row" expandable (similar to how metaboxes work) where, by default they would only show only the title cell, but when tapped or clicked on they would expand below to show the rest of the meta data and actions?

+1 to this -- initial presentation on a small screen needs to have pretty compact rows, just big enough to be a good tap target; the larger (chunks? pods? sections?) don't look obviously enough like a list at all on a phone-sized screen and multiple selections will take a ton of scrolling.

And yes to select all!

#64 @markoheijnen
13 years ago

  • Cc marko@… added

#65 in reply to: ↑ 62 ; follow-up: @helenyhou
13 years ago

Replying to chexee:

Would it be possible to make each "row" expandable (similar to how metaboxes work) where, by default they would only show only the title cell, but when tapped or clicked on they would expand below to show the rest of the meta data and actions?

Not sure; that's definitely a way better idea, but would have to have some kind of JS added to control that. I'll play with removing columns too. I agree that the initial look should be way more compact, but if we can find a way to include an expanded view, that would be awesome.

#66 in reply to: ↑ 65 @azaozz
13 years ago

Replying to helenyhou:
Replying to chexee:

Not sure; that's definitely a way better idea, but would have to have some kind of JS added to control that.

Don't worry about the JS.

Usually the best way to control this kind of switching is by adding and removing a class on a parent element. If you get it to work that way, the JS would be one line toggle (you can test that in Firebug and friends by adding/removing the class by hand).

If you think we need something more complicated, ping me in #wordpress-dev and we will put it together fast :)

#67 follow-ups: @chexee
13 years ago

Added larger, touch-friendly input boxes and submit buttons:

http://chx.mx//kc/b3vgofhog4cc4.png

#68 follow-ups: @helenyhou
13 years ago

Here's a run of just the title with an expanded state, using azaozz's advice to just add a class on the tr. Needs some kind of indicator that you can expand/collapse. The table head/foot is kind of misleading/confusing when expanded, since it just says Title. Select all checkbox is back though, hooray!

Default: http://cl.ly/1t3b1N463b452l322N2j
Expanded: http://cl.ly/3h2J1p3I1c35011p2I3O

#69 in reply to: ↑ 67 @helenyhou
13 years ago

Replying to chexee:

Added larger, touch-friendly input boxes and submit buttons:

http://chx.mx//kc/b3vgofhog4cc4.png

Cooooool. The top accordion could probably use visible arrows to indicate expand/collapse, like the individual menu items have.

#70 in reply to: ↑ 67 ; follow-up: @sabreuse
13 years ago

Replying to chexee:

Added larger, touch-friendly input boxes and submit buttons:

http://chx.mx//kc/b3vgofhog4cc4.png

Love the big targets! I'm noticing that the labels of menu items/tabs are cut off on both the left and right - could we enforce showing the beginning of each label (and optionally cut off the end of the label) so we have something more like "Another M..., Menu 1, Sample M..." instead of "nother Menu, Menu 1, Sample Men" or wherever it happens to truncate?

#71 in reply to: ↑ 70 ; follow-up: @chexee
13 years ago

Replying to sabreuse:

Love the big targets! I'm noticing that the labels of menu items/tabs are cut off on both the left and right - could we enforce showing the beginning of each label (and optionally cut off the end of the label) so we have something more like "Another M..., Menu 1, Sample M..." instead of "nother Menu, Menu 1, Sample Men" or wherever it happens to truncate?

That could get messy if someone has a lot of menus (even 5 would make the tabs tiny) or has similar pre-fixed menus. I'm not in love with the scrolling sidebar either, though :/

Replying to helenyhou:

Cooooool. The top accordion could probably use visible arrows to indicate expand/collapse, like the individual menu items have.

They have them on hover, which is totally unhelpful for a touch device :P Whoo, I'll make them persistent. Cool!

#72 in reply to: ↑ 68 ; follow-up: @sabreuse
13 years ago

Replying to helenyhou:

Needs some kind of indicator that you can expand/collapse.

I'd suggest something like the little gray down-arrow on accordeons, but (same issue as with Chexee's menu accordeons) we'd need to make it persistent since we can't assume hover, at least on mobile.

The table head/foot is kind of misleading/confusing when expanded, since it just says Title.

Title isn't ideal for either collapsed or expanded - it's not just labeling that one field any more, but the whole page/post/media item/whatever. I'm not sure what to call it more generically, though.

#73 in reply to: ↑ 71 @sabreuse
13 years ago

Replying to chexee:

That could get messy if someone has a lot of menus (even 5 would make the tabs tiny) or has similar pre-fixed menus. I'm not in love with the scrolling sidebar either, though :/

Yeah, I don't think getting rid of the scrolling would happen with any decent number of tabs. I was thinking more of the readability of the labels themselves: forcing them to start with the beginning of the label text even if they fade off at the end feels like it should make for better comprehensibility.

#74 in reply to: ↑ 72 ; follow-up: @helenyhou
13 years ago

Replying to sabreuse:

I'd suggest something like the little gray down-arrow on accordeons

For sure. I can go digging for the image and see about applying it. I wonder if maybe clicking/tapping anywhere on the row that's not a link/checkbox should make it toggle? The arrow might be kind of a small target, but having it toggle anywhere could be really unexpected behavior.

Title isn't ideal for either collapsed or expanded - it's not just labeling that one field any more, but the whole page/post/media item/whatever. I'm not sure what to call it more generically, though.

Could probably change the text with JS to the name of the screen we're on. The tables get a class based on the screen, so it'd be easy enough to determine what the name should be. Sometimes they are sortable, though, so changing the name might still be weird. Don't want to lose sort.

#75 in reply to: ↑ 74 @sabreuse
13 years ago

Replying to helenyhou:

For sure. I can go digging for the image and see about applying it.

wp-includes/images/toggle-arrow.png, looks like

I wonder if maybe clicking/tapping anywhere on the row that's not a link/checkbox should make it toggle? The arrow might be kind of a small target, but having it toggle anywhere could be really unexpected behavior.

I wouldn't go so far as the full row. It's not a button, and it would be weird for it to act like one - but the arrow by itself is way too small by itself. IIRC the recommended target sizes for touch are generally 30-40px - so I'd vote for making the last section of each row clickable, but not the whole thing.

#76 in reply to: ↑ 68 @azaozz
13 years ago

Replying to chexee:
Replying to helenyhou:

All looking very good. Starting to think we may be able to add some phone browsers support in 3.3 and refine it in 3.4.

@helenyhou we probably can try having something similar to how the widgets are opened/closed, i.e. a large enough div that is floated right with the arrow as a centered background. The html for it would look something like

<div class="toggle-whatever"><br /></div>

(the filler <br /> gives it shape in all browsers).

The JS for the above example would be:

jQuery('.toggle-whatever').click( function(){
  jQuery(this).parents('tr').toggleCalss('my-toggle');
});

You can paste that in the (Firebug) console and run it while testing too.

Last edited 13 years ago by azaozz (previous) (diff)

#77 @helenyhou
13 years ago

It works! http://cl.ly/3F1L0N3z1M0F0Z3t0X3W

I did this one with the toggle under the checkbox, just because it was the simplest for proof of concept. It's kind of a small target right there (30px by 20px), but it really could be moved anywhere, maybe the end of each line with some padding added to prevent collision with titles. Not sure what the right way of adding this in is, though. I ended up adding it to the class method for testing.

By the way, if you resize a Webkit browser after page load, it does terrible things to the table elements that switch to display:block. Since this is really targeting mobile, I don't see it as a huge issue, but you might experience it on your full-size machines :)

#78 @DrewAPicture
13 years ago

This may be a candidate for another ticket another time, but how will the (new flyouts) menu be treated when the dashboard is resized with this new responsive admin? Will the hover still exist but just be moot in terms of touch screens? Will the menus expand down automatically at a certain screen width? Or maybe a tap to open animation without a page refresh? My motivation for asking is this: If the purpose of the flyouts was to make any menu accessible via one-click access, how will you match that for devices that don't innately support hover operations?

Something to think about. I've posted the same on koop's ticket (#18382).

Version 0, edited 13 years ago by DrewAPicture (next)

#79 @saracannon
13 years ago

We're moving all small-screen discussion and patches to #18655 - as it will be for future-release. :]

#80 @helenyhou
13 years ago

18198.list-tables-max-width.diff adds max-width to #posts-filter, .widefat and .tablenav to keep it from getting too wide to read on large screens. Number is kind of arbitrary, open to other suggestions.

Last edited 13 years ago by helenyhou (previous) (diff)

@helenyhou
13 years ago

Limit max width of widefat list tables, semi-arbitrarily to 2000px

#81 follow-up: @azaozz
13 years ago

In [18667]:

Auto-column switching for the dashboard (js based), see #18198

@saracannon
13 years ago

responsive category pages

#82 @saracannon
13 years ago

initial pass: responsive category pages.. converts to one col after 768px

still needs testing on ipad/tablets.

http://cl.ly/0a2T0k192N3c3x2F3k1s

http://cl.ly/0m0e0C3z2V2a0o2c2730

Last edited 13 years ago by saracannon (previous) (diff)

#83 @azaozz
13 years ago

In [18670]:

Limit max width of .widefat list tables, props helenyhou, see #18198

#84 @azaozz
13 years ago

Typo in the commit message, meant to reference this ticket.

Changeset [18669] by azaozz
Responsive tag and category pages, props saracannon, see #18198

@helenyhou
13 years ago

CSS for theme screens, also limits plugin cloud tag width

@helenyhou
13 years ago

Modifications to the two list-table classes for theme screens

@helenyhou
13 years ago

JS to make each row of div's equal height on load/resize, from http://stephenakins.blogspot.com/2011/01/uniform-div-heights-for-liquid-css-p.html

#85 @helenyhou
13 years ago

First pass at theme screens (available and install). Feedback on width (they are fixed) and the whole border/whitespace/grid thing welcome.

18198.themes-css.diff has the CSS for the theme screens and also limits the width of the plugin tag cloud to wrap that up. I think it also takes out the .widefat max-width @saracannon had put in the responsive stuff because it was breaking things for me.

18198.class-wp-theme-install-list-table.diff makes the two theme list tables... not tables. Both are also now 24 per page, just as a number that's more likely to come out even.

18198.theme-row-height.js is a piece of JS that makes each row of divs adjust to the height of the tallest one on load and resize. Not a big JS person, this could use some review.

#86 @azaozz
13 years ago

In [18671]:

Remove max-width for .widefat, see #18198

#87 @nacin
13 years ago

Bumping up to 36 rather than down to 24 should result in the same opportunities. But it's also been a long time since I took fifth grade math.

#88 @helenyhou
13 years ago

Sure, I'm always for more information per-screen. 24 was definitely an arbitrary pick - you core people are welcome to change it whatever you think is best :)

Edit: I just realized you meant for the search screens. I forgot it was 30 before - installed themes screen was at 15, which is where I was going from.

Last edited 13 years ago by helenyhou (previous) (diff)

#89 in reply to: ↑ 81 @ptahdunbar
13 years ago

Replying to azaozz:

In [18667]:

Auto-column switching for the dashboard (js based), see #18198

FYI: This changeset introduced new bug #18665 (Admin Dashbord Widgets columns are 'stuck').

#90 @helenyhou
13 years ago

Tried it out without borders to eliminate the need for the JS piece: http://cl.ly/2w1P1m1Y0G0B0E3C2p2x. Need some feedback on whether or not it's legible/scannable/etc.

@helenyhou
13 years ago

No borders, no JS

#91 @azaozz
13 years ago

In [18673]:

Responsive themes screen, props helenyhou, see #18198

#92 @andrewryno
13 years ago

Uploaded screenshot with 2 of the issues I'm seeing. Flyouts don't look right and then the sub-menu of the active item doesn't hide itself.

#93 follow-up: @helenyhou
13 years ago

I'm seeing the same thing, and also having hover problems with the flyouts. Should this go on #18382?

#94 @andrewryno
13 years ago

True, forgot about that ticket. I put it in here only because I noticed it once the responsive admin stuff went it. Looks fine on my old trunk install from before all the responsive stuff.

#95 in reply to: ↑ 93 @azaozz
13 years ago

Replying to helenyhou:

...Should this go on #18382?

Yes, actually reported that couple of weeks ago. Thinking it needs a css fix, no point in running js on page load to fix the css there.

Last edited 13 years ago by azaozz (previous) (diff)

@helenyhou
13 years ago

Fix for theme information (install thickbox)

#96 @helenyhou
13 years ago

Attached a patch to fix the theme information display in the install thickbox, as pointed out by Ipstenu. Body still has a min-width from elsewhere, which is messing with all thickboxes, so it still scrolls horizontally.

#97 @Ipstenu
13 years ago

  • Cc ipstenu@… added

#98 follow-up: @Viper007Bond
13 years ago

I assume the max-width on the lists is a result of this ticket? It's rather lame having whitespace to the right of my list of comments, posts, etc.

Screenshot below.

#99 in reply to: ↑ 98 ; follow-up: @azaozz
13 years ago

Replying to Viper007Bond:

I'm not sure what's worse: having white space on the right or having super long (2000px+) rows that make you turn your head to see the right side.

As far as I've seen nobody uses the browser maximized on a 27"/32"/46" screens, so this may be a secondary consideration.

#100 in reply to: ↑ 99 @Viper007Bond
13 years ago

Replying to azaozz:

As far as I've seen nobody uses the browser maximized on a 27"/32"/46" screens, so this may be a secondary consideration.

I do. :( For at least 5 years, I used WordPress at 1920x1200 (24") and have been using WordPress at 2560x1600 (30") since early this year. I've never had a single problem. Heck, I still run WordPress maximized at 1920x1080 on my 13" laptop.

I don't understand how (or why) people don't use things like browsers in anything but maximized mode. Perhaps it's a Mac thing. I can't remember the last time I had an application that wasn't maximized.

Last edited 13 years ago by Viper007Bond (previous) (diff)

#101 @Viper007Bond
13 years ago

According to Twitter, I am weird for running things in fullscreen. Then again, responses were from Mac users. Hmm.

#102 @ryan
13 years ago

I too run fullscreen/maximized. Xtra-wide is how I ride. That said, I don't really have a max width preference for the list table pages.

#103 @wpmuguru
13 years ago

I run one of my browsers fullscreen because I'm using firebug, etc. I use multiple desktops/sessions and one desktop has just that browser. I don't object to a bit of whitespace on the right.

#104 @azaozz
13 years ago

The (not that many) people I've seen that work on large 2000px+ screens usually have the screen split in two "zones" left/right and do stuff in more than one app at the same time. Only seen designers/artists that have Photoshop or similar in full screen mode (and even a second screen for all the palettes).

#105 follow-ups: @nacin
13 years ago

Replying to azaozz:

Replying to Viper007Bond:

I'm not sure what's worse: having white space on the right or having super long (2000px+) rows that make you turn your head to see the right side.

As far as I've seen nobody uses the browser maximized on a 27"/32"/46" screens, so this may be a secondary consideration.

I don't get it. If no one uses it this way, then why the max width? Now you *can't* use it this way.

Say someone manages a CPT all day long. 27" screen, long titles, full descriptions, a dozen columns. Designed exactly for a big screen.

We shouldn't be putting a max width on anything. We should make some screens (like widgets) take full advantage of it. And leave the rest alone.

#106 in reply to: ↑ 105 @helenyhou
13 years ago

Replying to nacin:

Say someone manages a CPT all day long. 27" screen, long titles, full descriptions, a dozen columns. Designed exactly for a big screen.

That's a good point, and so's Viper007Bond's on Twitter that a user could control it if it really bothers them. I'll work on an alternative that just deals with how awful the import screen is at full width in a bit.

#107 in reply to: ↑ 105 @azaozz
13 years ago

Replying to nacin:

... We shouldn't be putting a max width on anything.

That's not going to work on most screens. Reading very long lines is hard and tiring. And is ergonomically wrong.

On the other hand I agree we shouldn't needlessly constrain width if it can be made useful. Perhaps we should try to look at individual "reading areas", for example the Comment column on the comments screen and make sure they don't exceed 800-900px. Also all these lengths should be in em IMHO.

As an experiment: open Firebug (or friends) right now, find div#content and remove the width: 58em from it. Now try reading/responding :)

Last edited 13 years ago by azaozz (previous) (diff)

#108 @azaozz
13 years ago

In [18693]:

Add missing var in postbox.js, see #18198

#109 @azaozz
13 years ago

In [18694]:

The rest of add missing var in postbox.js, see #18198

#110 @SergeyBiryukov
13 years ago

Dashboard has whitespace on the right in 1440x900 (see the screenshot).

#111 @helenyhou
13 years ago

Attaching a patch to make the import screen not exceed necessary width on wide screens, as it does not change too often. Screenshot: http://cl.ly/0I3a372Y1j3P3Z0t1u3s

@helenyhou
13 years ago

Import screen list table

#112 @dd32
13 years ago

See also #18670 - Add new Link screen defaults to 1 column, however only shows the first columns widgets (2nd column, containing the publish widget, remaing hidden until the 1/2/auto options are selected)

#113 @azaozz
13 years ago

In [18704]:

Importers and Install themes thickbox fixes, props helenyhou, see #18198

#114 @azaozz
13 years ago

In [18736]:

Responsive admin improvements for the dashboard, new/write screens and links screens, see #18198

@sabreuse
13 years ago

Fix for tab and category sidebars in post-new

#115 follow-up: @sabreuse
13 years ago

On the post-new screen, expanding the "most used tags" or "add a new category" options causes ugly overflow. Screenshot here: http://cl.ly/2X0G403q3A3A280f1F30

The attached patch fixes this, while still respecting responsiveness when shrinking to 1 column layout.

Last edited 13 years ago by sabreuse (previous) (diff)

#116 in reply to: ↑ 115 @azaozz
13 years ago

Replying to sabreuse:

On the post-new screen, expanding the tab or category options causes ugly overflow. Screenshot here: http://cl.ly/2X0G403q3A3A280f1F30

This looks like a bug. These screens (Add / Edit Post, Add /Edit Link) have three states:

  • narrow (right postboxes are under the editor)
  • normal (right postboxes on the right, width: 280px)
  • wide (right postboxes on the right, width: auto, min and max width so they are a little "elastic" and fill some of the white space).

From the screenshot it seems some css or js has not loaded properly. Perhaps try resetting the browser.

#117 @Ipstenu
13 years ago

I had this problem too, and that was my first action after I saw it (even did the Chrome hard-flush of all cached files, and unrelated, rebooted the computer because XP sucks). I can repro it on a clean site/theme too.

#118 @azaozz
13 years ago

In [18743]:

Fix inconsistent css handling of .wide-screen, see #18198

#119 @azaozz
13 years ago

Yes, it was a bug in the css, [18743] should fix it.

@sabreuse
13 years ago

Per ui meetup discussion, remove max-width on tables (updated)

#120 @sabreuse
13 years ago

Missed a max-width in the first patch I uploaded, replaced with edited version

#121 @azaozz
13 years ago

In [18801]:

Remove max-width from list tables. Better to limit the width on individual fields or areas where readability is impacted, see #18198

Props sabreuse. Sry, forgot to include in the commit message.

Last edited 13 years ago by azaozz (previous) (diff)

#122 @azaozz
12 years ago

  • Resolution set to fixed
  • Status changed from new to closed

Fixed for now, more responsive in 3.4.

#123 @WraithKenny
12 years ago

semi-related #17959

#124 @azaozz
12 years ago

In [20942]:

Remove leftover JS global, see #18198

Note: See TracTickets for help on using tickets.