#1870944: [Meta] Mobile friendly admin pages

Problem/Motivation

The Appearance page doesn't display properly on small screens. The enabled themes section of the page has text that wraps very weirdly on mobile-sized screens making it difficult to read and presenting severe usability problems.

The main source of this problem is that the text is fixed to the right of a 300 pixel wide image, so screens smaller then 600 pixels start to squeeze the text into smaller and smaller space until it starts wrapping beneath the 300 pixel image.

Proposed resolution

The Appearance page uses 2 different grids. The enabled themes section has a fixed 300 pixel wide image, with a fixed 20 pixel gutter and a fluid "description" column. The disabled themes section uses a fixed 300 pixel-wide column with 20 pixel gutter, but images are scaled down to 200 pixels wide to show a submissive status with regards to enabled themes.

  1. We should use a single responsive, fluid grid for the entire page.
  2. For larger screens, use media queries to have 3, 4, or 5 columns. The enabled themes section should be limited to the first 2 columns; image in 1st column, text in 2nd column. The disabled themes section should be similar to now with images above text, but we should no longer limit the image size to 200 pixels wide.
  3. For smaller screens, use media queries to have 1 or 2 columns. On 2 column-sized screens, the enabled themes section will use the same layout as above. For 1 column-sized screens, an enabled theme's text will be below its image.
  4. Making the disabled themes use larger images (see point #2 above) means they will compete with the enabled themes for dominance. So I think we should add a light grey background to the disabled themes section. (This idea was proposed too late in the original Appearance issue.)

Remaining tasks

All of them.

CommentFileSizeAuthor
#62 Appearance.png118.83 KByoroy
#60 responsive-appearance-page-1861702-60.patch6.65 KBrteijeiro
#57 responsive-appearance-page-1861702-57.patch6.61 KBechoz
#55 responsive-appearance-page-1861702-54.patch6.46 KBrteijeiro
#53 responsive-appearance-page-1861702-53.patch6.96 KBrteijeiro
#52 responsive-appearance-page-1861702-52.patch4.88 KBechoz
#48 Screenshot_21_05_2013_10_32.png213.51 KBalexpott
#42 responsive-appearance-page-1861702-42.patch3.46 KBechoz
#42 720px.png136.95 KBechoz
#42 719px.png137.27 KBechoz
#40 Screen Shot 2013-04-23 at 09.38.14.png112.18 KBLewisNyman
#37 appearance-wide.png154.18 KBechoz
#37 appearance-narrow.png151.27 KBechoz
#36 responsive-appearance-page-1861702-36.patch3.46 KBechoz
#34 1861702-responsive-appearance-page-34.patch3.45 KBrteijeiro
#32 drupal8-appearance.png205.46 KBrteijeiro
#32 drupal8-appearance-d7.png193.14 KBrteijeiro
#31 responsive-appearance-page-1861702-31.patch3.45 KBLewisNyman
#29 Screen Shot 2013-04-12 at 8.58.07 AM.png130.73 KBwebchick
#29 Screen Shot 2013-04-12 at 8.59.21 AM.png101.78 KBwebchick
#27 drupal8-disabled-themes.png365.02 KBrteijeiro
#23 drupal8-appearance.jpg653.48 KBrteijeiro
#21 responsive-appearance-page-1861702-21.patch2.87 KBLewisNyman
#21 desktop.png150.1 KBLewisNyman
#21 mobile.png115.86 KBLewisNyman
#18 appearance-wide.png255.69 KBrteijeiro
#18 appearance-vmenu.png273.17 KBrteijeiro
#18 appearance-hmenu.png696 KBrteijeiro
#16 appearance-full.png213.02 KBrteijeiro
#11 responsive-appearance-page-1861702-11.patch2.03 KBLewisNyman
#9 Photo 23-01-13 20 19 18.png90.23 KBrteijeiro
#4 IE 9 Screenshot196.23 KBmcjim
#4 Firefox Screenshot159.98 KBmcjim
#4 responsive-appearance-page-1861702-4.patch2.01 KBmcjim
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

Bojhan’s picture

Issue tags: +Usability

Sounds good :)

webchick’s picture

Category: bug » task

Moving to a task, rather than a bug report.

JohnAlbin’s picture

Issue tags: -#d8mux +d8mux

Issue tags aren't Twitter hashtags. doh!

mcjim’s picture

Status: Active » Needs review
FileSize
2.01 KB
159.98 KB
196.23 KB

Patch to kick things off.
I think it works in a functional sense. Not sure about aesthetically.
Anyway, it's a start.

webchick’s picture

Priority: Major » Normal

Since #1870944: [Meta] Mobile friendly admin pages is a major task, downgrading this one so we don't overload thresholds with this one particular sub-initiative.

Shyamala’s picture

+dmux8-admin tag

Shyamala’s picture

Issue tags: -mobile

edited tag

Shyamala’s picture

Issue tags: +mobile, +d8mux-admin

edited tag

rteijeiro’s picture

Status: Needs review » Needs work
FileSize
90.23 KB

Hi all.

Applied #4 patch and looks well except for a small blank space on the right side. I can see it in Opera, Firefox and iPhone.

Take a look at the attached iPhone screenshot.

Hope it helps.

LewisNyman’s picture

Issue tags: +mobile-novice, +CSS novice

Novice tags

LewisNyman’s picture

Status: Needs work » Needs review
FileSize
2.03 KB

Good stuff guys, nice to see this page getting some love!

The fix was minor, a margin-right needed to be removed.

rteijeiro’s picture

Status: Needs review » Reviewed & tested by the community

Nice, tested the #11 patch with Chrome, Firefox, Opera, Safari and also with iPhone and it seems to solve the issue with Seven as administration theme.

Maybe it should be considered as RTBC.

Great work :)

Bojhan’s picture

Status: Reviewed & tested by the community » Needs review

Hmm, does this change anything visual on the desktop?

rteijeiro’s picture

Status: Needs review » Reviewed & tested by the community

Reviewed with desktop screen sizes in Chrome, Safari, Opera and Firefox and everything seems ok.

Should I review something else?

Bojhan’s picture

Status: Reviewed & tested by the community » Active

@rteijeiro Its common to provide a screenshot so that others can review the visual change. Atleast the last screenshot I see, has quite some visual changes .

I dont think its RTBC, untill we can give it a good review.

rteijeiro’s picture

FileSize
213.02 KB

Hi @Bojhan, I have attached a full page screenshot. Thank you for your comments :)

Bojhan’s picture

@rteijeiro Would it be much trouble to also attach the full width desktop version?

rteijeiro’s picture

Of course not, @Bojhan.

I have attached screenshots for the full width desktop version without expanded menu and with both vertical and horizontal menu expanded ;)

LewisNyman’s picture

Looks good to me

+1 RTBC

Bojhan’s picture

How could this be RTBC? The disabled section doesn't look at all like D7? I don't think the design decision to use a gray background is a useful one, we had the right design before using positioning and size - there doesn't seem to be any reason why we cant make that responsive.

LewisNyman’s picture

Status: Active » Needs review
Issue tags: -Usability
FileSize
115.86 KB
150.1 KB
2.87 KB

Ok, so I rewrote this patch from scratch, for me it was easier to do that then to take what we already had and undo the design changes. Rough screens attached for the curious.

Points of interest:

  1. I've kept the enabled theme images at a fixed width on desktop, there's not a lot of joy in making them smaller and making it harder to see the details
  2. I've completely removed the “No screenshot” boxes on mobile. They are only there to align everything properly on desktop and it makes no sense to have a big box taking up half your screen.
  3. Yes, I'm using CSS calc() for the disabled "no screenshot" boxes, because they are now fluid. There's no support drama here because they are used inside of a media query, so IE8 would even see them.
rteijeiro’s picture

Status: Needs review » Needs work

Tested the #21 patch and found some issues:

- The theme screenshots should be centered in mobile size.
- When you are resizing the browser, the disabled section also resizes (see screenshot)

rteijeiro’s picture

FileSize
653.48 KB

Problems with the screenshot :(

Now attached.

LewisNyman’s picture

#22:

- When you are resizing the browser, the disabled section also resizes (see screenshot)

I'm not sure I understand this point? It should resize, it's fluid.

rteijeiro’s picture

Yes, I agree with you but it resizes differently than the enabled section. If you look at the screenshot you will notice that the theme screenshot in the disabled section is smaller than in the enabled section.

LewisNyman’s picture

That's actually by intent. The enabled screenshot doesn't need to resize, there's no benefit to that. The disabled screenshot does have to resize because it's set in three columns

rteijeiro’s picture

Status: Needs work » Reviewed & tested by the community
FileSize
365.02 KB

Ok, now it makes sense. I tried with more disabled themes and looks nice (see screenshot).

It's a RTBC for me.

echoz’s picture

#22, I don't think the theme screenshots should be centered when stacked, it looks good lined up with the text.

I see in the beginning of the "Appearance page" section of system.admin.css is "table.screenshot" which must be an artifact from the past, as there is no table there (or Lewis would have nuked it!). The class .screenshot is covered lower in the stylesheet. I realize this is more of a general cleanup point and is debatable whether it's part of this patch, otherwise looks good to me, nice work Lewis.

webchick’s picture

Status: Reviewed & tested by the community » Needs work
FileSize
101.78 KB
130.73 KB

I think this is what Bojhan is saying (screenshots would be helpful in future comments :))

In D7 the page looks like this:
Enabled themes are about 2x as wide/high as disabled themes

The disabled themes are diminished in importance relative to the enabled themes in desktop width.

In D8, the page (at least for me) looks like this:

Both themes' screenshots are the same size

So we lose that strong distinction between enabled/disabled, and instead have to pick out a tiny header in amongst BIG SCREENSHOTS THAT ATTRACT EYEBALLS to tell the difference.

We should fix this I think.

Otherwise, looks great!

rteijeiro’s picture

Yes, I have tried also with one only disabled theme to see if the theme preview screenshot resizes and it seems that the theme preview screenshot size is always: 200px X 150px

LewisNyman’s picture

Status: Needs work » Needs review
FileSize
3.45 KB

Ok, I realised that I removed a set width on the disabled images and replaced it with max-width 100%. I've replaced this with max-width 75% to make the screenshot smaller.

I've also added one div to the no-screenshot container to make the CSS a lot simpler. Yay!

rteijeiro’s picture

Status: Needs review » Needs work
FileSize
193.14 KB
205.46 KB

Now it seems smaller but I think the right size is max-width: 60% to look the same as in Drupal 7.

This screenshot is with max-width: 75%

This screenshot is with max-width: 60%

Do you agree with me?

rteijeiro’s picture

Status: Needs work » Needs review
rteijeiro’s picture

I have done the change I commented in comment #32 but with a width of 55% (hope that Lewis Nyman doesn't care and agree with me).

Now the disabled theme screenshots are the same size than in Drupal 7 version.

echoz’s picture

Status: Needs review » Needs work

It doesn't work to have the disabled screenshot a percentage of its container when that container itself is a percentage, because as the width of the viewport changes, the screenshot needs to range from 100% of it's narrowest container (1/3 of viewport = ~55% of enabled screenshot), to 55% of it's widest container (viewport wide enough so 1/3 = enabled screenshot).

I don't have a solution. Changing disabled screenshot to max-width 100% when parent is 1/3 partly fixes it, but makes it equal to enabled screenshot at wider viewport. The way it is now, the disabled screenshot gets way tiny, but can also be same width as enabled screenshot.

Enter a local test of the patch at http://responsinator.com/ to see how all viewport widths are not ok.

echoz’s picture

Status: Needs work » Needs review
FileSize
3.46 KB

I do have a solution. I realized the disabled screenshot needs a consistant width (as the problem in #35 describes). This patch gives max-width: 194px; to the disabled screenshot. That is the only change since Lewis's #31 patch, where it was previously max-width: 75%;

echoz’s picture

FileSize
151.27 KB
154.18 KB

Screenshots showing consistent width for disabled screenshot:

wide

narrow

webchick’s picture

Oh, that looks much better! :)

rteijeiro’s picture

Status: Needs review » Reviewed & tested by the community

Great!! Thans echoz, it seems that all the problems are solved.

Tested with Chrome, Safari, Opera and Firefox with awesome results ;)

Thats a RTBC for me.

LewisNyman’s picture

Status: Reviewed & tested by the community » Needs work
FileSize
112.18 KB

I'm not sure how setting the image to a fixed width helps the page be responsive? We need these screenshots to be fluid, otherwise they start to overlap:

Screen Shot 2013-04-23 at 09.38.14.png

echoz’s picture

Thanks Lewis, I was hoping for your input and also hoping someone could test an extra disabled theme, I couldn't get a copy of Stark to show up (prob Safari caching issue), and had assumed it would never need to be narrower at the 1/3 stage. So I'm back to not having a solution for #35.

echoz’s picture

Status: Needs work » Needs review
FileSize
137.27 KB
136.95 KB
3.46 KB

This patch addresses the issue shown in #40 by changing the breakpoint from min-width: 40em to min-width: 45em so there is never any overlap.
#35 explains why having the disabled screenshot be a percentage of a percentage container does not work.

Screenshots on both sides of the 45em breakpoint (720px):

720px viewport width, the closest the disabled screenshots can get:

720px.png

719px viewport width:

719px.png

Status: Needs review » Needs work
Issue tags: -mobile, -Responsive Design, -d8mux, -mobile-novice, -CSS novice, -d8mux-admin

The last submitted patch, responsive-appearance-page-1861702-42.patch, failed testing.

echoz’s picture

Status: Needs work » Needs review
Issue tags: +mobile, +Responsive Design, +d8mux, +mobile-novice, +CSS novice, +d8mux-admin
rteijeiro’s picture

Status: Needs review » Reviewed & tested by the community

Reviewed and it seems right, like shown in #42 screenshots. Maybe RTBC, finally? :)

echoz’s picture

Thanks rteijeiro, I hope so.
@LewisNyman, does the problem (#35) and solution needing fixed max-width make sense for you?

LewisNyman’s picture

Yep this looks good to me from the screenshots.

alexpott’s picture

Status: Reviewed & tested by the community » Needs work
FileSize
213.51 KB

Manually tested and I still get overlap...
Screenshot_21_05_2013_10_32.png

rteijeiro’s picture

Ok, alexpott you are right. That's because the expanded vertical menu. I tested that with the horizontal menu only :(

EDIT: Nice catch, BTW!

echoz’s picture

There is a .vertical class on the toolbar, so we could make another breakpoint. 52em seems to be just where the vertical menu change happens, but is too wide to stack the screenshots when there is no menu used.

LewisNyman’s picture

So myself, echoz, and Jesse spoke on this issue at length. The vertical toolbar has potential to mess with media queries in every theme. We agreed that it probably won't produce major errors for front facing themes, and that if it did, it's pretty easy to override the toolbar CSS to stop the vertical toolbar shifting the page around. Let's not assume this is a huge problem until we find that it is.

We do have a responsibility to make sure the admin UX works in these situations. So we should write another media query that takes into account the offset of the toolbar.

echoz’s picture

Status: Needs work » Needs review
Issue tags: -mobile-novice, -CSS novice
FileSize
4.88 KB

This patch adds an another breakpoint for the viewport with the vertical toolbar displayed. A solution to keep the display w/toolbar to not also recognize the narrower breakpoint was to use the :not pseudo-class (thanks LewisNyman), which syntax requires the preceeding selector like so (doesn't work without "body"):

body:not(.toolbar-vertical)

Alternatively, we can achieve less specificity if we add a .no-toolbar class. If someone wants to implement that, have at it!

:not works with IE9+ (tested).
I also reduced some instances of class .theme-selector, and finally got rid of table.screenshot!

rteijeiro’s picture

Updated the changes in system.admin-rtl.css file too.

Status: Needs review » Needs work

The last submitted patch, responsive-appearance-page-1861702-53.patch, failed testing.

rteijeiro’s picture

Status: Needs work » Needs review
FileSize
6.46 KB

Sorry, patch above is not valid. It contains the .htaccess file.

Status: Needs review » Needs work

The last submitted patch, responsive-appearance-page-1861702-54.patch, failed testing.

echoz’s picture

Status: Needs work » Needs review
FileSize
6.61 KB

Thanks @rteijeiro, re-rolled with some declaration order changes in rtl.

rteijeiro’s picture

Status: Needs review » Reviewed & tested by the community

Great @echoz. Tested again and checked with an RTL language. Everything seems ok.

Also tested with overlay and disabled theme thumbnails overlaps a bit. Not sure if it should work with overlay or not so I consider it as RTBC.

Please, feel free to open this issue or a new one if you consider to fix overlay.

alexpott’s picture

Status: Reviewed & tested by the community » Needs work

Needs a reroll

curl https://drupal.org/files/responsive-appearance-page-1861702-57.patch | git a
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100  6773  100  6773    0     0   6027      0  0:00:01  0:00:01 --:--:--  7394
error: core/modules/system/system.admin-rtl.css: does not exist in index
error: core/modules/system/system.admin.css: does not exist in index
rteijeiro’s picture

Status: Needs work » Needs review
FileSize
6.65 KB

Re-rolled with the latests changes in 8.x branch. Now applies well.

echoz’s picture

Status: Needs review » Reviewed & tested by the community
yoroy’s picture

FileSize
118.83 KB

I applied the latest patch and tested in Chrome, Safari, Firefox on OS X with and without overlay. Looking great, RTBC indeed.

alexpott’s picture

Status: Reviewed & tested by the community » Fixed

Committed 84d0ea9 and pushed to 8.x. Thanks!

Automatically closed -- issue fixed for 2 weeks with no activity.

Anonymous’s picture

Issue summary: View changes

Added link to meta issue