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.

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.

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.

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.

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.

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.

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.

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.

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?

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.

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.

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 :)

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!

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?

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 :/

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.

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.

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.

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

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 :)

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 inherently support hover events?

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

​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.

​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.

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.

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.

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).

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.

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 :)

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)

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.