[META] [UX] The Configuration page (/admin/config) needs some love.

[klonos]

This can evolve to be a meta issue if it turns that there's a lot of tasks and we need to keep them separate. So far I see these issues that need to be addressed:

• [ ] #978 The page could use an instant search filter (like on the modules page)
• [ ] #979 Add a "Hide/Show descriptions" link like in D7/D8:
• [ ] TBD The categories and their containing entries should be in parity with whatever grouping we decide for #494. If we want to "automate" this, we should look at implementing something like #508.
• [x] #1178 Add icons to the config sections for better scanability
• [x] #2828 The categories seem to be in random order. They should be in alphabetical order (unless somebody has another suggestion). and ...
• [x] #2828 (see #2828)| The items under each category seem to be randomly placed as well. They should be listed alphabetically (unless somebody has another suggestion).
• [x] #2828 We use a two-column layout that is not responsive and by default makes the page unnecessarily long on wide screens. Perhaps we should consider using a responsive grid or an accordion or some other solution that wraps the categories under each other in small screens.

[klonos]

...makes the page unnecessarily long on wide screens.

This is what I mean:

[klonos]

A quick and dirty solution for 1.0.0 could be to go with the alphabetical ordering for both the categories themselves as well as the items within each one of them. Is this page generated statically?

I don't know how easy it'll be to implement the search filter. I guess we could reuse the code from the modules list, but if we cannot make it happen in 1.0.0 we'll have a chance at some 1.0.x ...but it would be a win to see it in 1.0.0. It's those tiny details that'll make people like Backdrop over Drupal.

The responsive part can wait for a 1.x I guess, but again, the soonest we can demonstrate responsiveness in the admin UI, the better.

Anyways, my point is lets improve as we go.

[klonos]

...and here's how ugly the page looks in narrow screens:

...and as the screen gets narrower, the page becomes uglier:

...and uglier (text starts bleeding outside its containers):

[docwilmot]

Single column alphabetical is a quick fix:

But two column alphabetical responsive would take some work, and maybe javascript - you'd have to ensure its alphabetical down the left column then down the right so it makes sense when the breakpoint happens, then you'd need to calculate the combined heights of the boxes in each column. Or maybe just count the number of links in total and divide by two, but it would never be evenly divided left and right.

The 'admin/structure' page is similar design but single column, so that may not be altogether unacceptable.

[klonos]

Single column alphabetical is a quick fix: ... But two column alphabetical responsive would take some work

As I said, lets move one step at a time. This is better than what we (as well as D7/D8) currently have in place. So I say lets get it in and improve later.

[klonos]

...github does not have issue summary versioning, so letting you know I've added another task:

• [ ] Add a "remove descriptions" link like in D8.

[quicksketch]

We use a two-column layout that is not responsive and by default makes the page unnecessarily long on wide screens. Perhaps we should consider using a responsive grid or an accordion or some other solution that wraps the categories under each other in small screens.

I'd like to see this converted to be a responsive layout, that keeps its two-column appearance until two columns become two narrow, then convert to one. The PR at https://github.com/backdrop/backdrop/issues/610 just converts it to a single column listing for all layouts, which I don't think is a complete solution.

Add a "remove descriptions" link like in D8.

We actually removed the show/hide descriptions link specifically to reduce UI elements (#129). We can reconsider, but let's weigh the advantages of having vs. excluding.

The page could use an instant search filter (like the one we have in the modules page): #503

Some other pages need instant search more than others, this one doesn't need it as much as

[klonos]

I'd like to see this converted to be a responsive layout, that keeps its two-column appearance until two columns become two narrow, then convert to one. The PR at backdrop/backdrop#610 just converts it to a single column listing for all layouts, which I don't think is a complete solution.

True, but since we are going to have 1.0.x versions shipped soon(ish), how about we consider going with an interim quick fix so that this page looks decent in small screens in 1.0.0 (It will be another UX issue that Backdrop 1.0.0 fixed compared to D8) and then work towards finding a solution for 2 columns that apparently requires more time. In the meantime we can focus our energy on the rest of the pending issues that stop 1.0.0 getting out the door.

We actually removed the show/hide descriptions link specifically to reduce UI elements (#129). We can reconsider, but let's weigh the advantages of having vs. excluding.

Sorry, I missed that issue. IMO before removing things (modules, features, UI elements etc) we should have metrics to back the decision. Just doing things and expecting people to complain about missing them is not a good practice because people might not be bothered to actually take action (file an issue or make a comment). Having a lot of such trivial complains build up might result in losing user base and we cannot afford it at the moment.

Having said all that, I think it is a good idea that descriptions should be set to be hidden by default in small screens so that this page works more like a small usable menu list rather than a very long config options index. In large screens on the other hand we have space to "waste", so we could default to showing the descriptions. Now because all these are assumptions and you could easily have people in large screens that are Drupal old-timers and already know what these links do, so they'd most likely choose to hide the descriptions in order to unclutter the page. Similarly, you could possibly get new-comers that are testing things on mobile devices and could use the guidance. With no show/hide element available, you deprive both user groups the choice and reduce UX quality. Especially in the case of people that know their way around this page, you choose to remove the element in order to unclutter the UI, but you end up leaving them with what they consider clutter and no option to get it out of their way. This totally defeats the purpose the way I see it.

As for the search filter, if we do end up implementing something like #508 in order to automate things and as people add more modules to their site, the more chances are you'd have additional contrib entries in this page. Eventually, you'll end up having the same issues in this page that lead us implementing the filter in the modules page in the first place.

[klonos]

...if we choose to adopt something generic (NIH) instead of "cooking" our own, then http://designinstruct.com/web-design/responsive-css-grid/ seems to have a pretty good collection/comparison of open source, free CSS responsive grid systems. My favorites are the Responsive Grid System and the Simple Grid

[docwilmot]

For the short term though, removing the left and right CSS from Seven (we cant add responsive CSS to Seven because the user may not use Seven as his admin theme) and adding this to system.admin.css does the trick nicely:

/**
 * Responsive columns.
 */
@media screen and (max-width:450px) {
  div.admin {
    margin: 0; /* LTR */
    padding-right: 4px;
    padding-left: 4px;
  }
  div.admin .left {
    float: left; /* LTR */
    width: 100%;
  }
  [dir="rtl"] div.admin .left {
    float: left;
  }
  div.admin .right {
    float: left; /* LTR */
    width: 100%;
  }
  [dir="rtl"] div.admin .right {
    float: left;
  }
  div.admin-panel .description {
    display: none;
  }
}
@media screen and (max-width:780px) {
  div.admin {
    padding-right: 4px;
    padding-left: 4px;
    margin: 0; /* LTR */
  }
  div.admin .left {
    float: left; /* LTR */
    width: 100%;
  }
  [dir="rtl"] div.admin .left {
    float: left;
  }
  div.admin .right {
    float: left; /* LTR */
    width: 100%;
  }
  [dir="rtl"] div.admin .right {
    float: left;
  }
}

What do you think?

[docwilmot]

Narrow screens (hide descriptions with CSS)

Medium screen size (iPad landscape for eg)

Wide screen

[klonos]

I think this is a fine interim solution that fixes the original issue I reported. Lets ship 1.0.0 with this simple solution and improve as we go.

[klonos]

...perhaps also address the random positioning and provide alphabetical order for the categories and the entries in them. Later on, we could improve this by bringing categories in parity with what ever grouping we decide for #494

[quicksketch]

Yay! Much better. The CSS needs a little work to be mobile-first. Where the current CSS should be wrapped in @media screen and (min-width:780px) {, so that instead of undoing CSS on the mobile size, you're only adding CSS on the desktop size. In general, we should use min-width to add additional CSS to larger sizes, with smaller sizes also applying their CSS to the larger sizes.

[docwilmot]

OK, got it done with your suggestions. Was about to do a PR but was wondering whether my assumption about placing the CSS changes in system.admin.css is valid since all the other admin CSS is in Seven. Putting this in system would be non-standard then. Where should this go ideally?

[quicksketch]

Was about to do a PR but was wondering whether my assumption about placing the CSS changes in system.admin.css is valid since all the other admin CSS is in Seven.

Leaving it in system.admin.css is correct, as this is essentially functionality provided by the menu system (the ability to specify left/right position). It should work in themes other than Seven, should an alternative admin theme be used.

It looks like the current arrangement is a bit of a mess, since the left/right styling seems to be in both Seven and system.admin.css. It looks like Seven's CSS is just "fixing" the CSS in system.admin.css (adjusting it's width). I think the best thing would be to try and consolidate the "layout" style to just system.admin.css (width, float, padding, margin) and delete it from Seven. Styling for color/font/etc can still live in Seven. Does that all sound sane?

[klonos]

It sounds perfectly sane to me.

[jenlampton]

Is it the groupings on this page that are valuable? Is it the descriptions of each grouping (which may be hidden on mobile?) or do we just come here because of habit?

We already have a responsive drop-down menu with all these links. If someone knows what link they need to click, why would they come to this page first on mobile (needing an extra page load) rather than popping open the menu and navigating there directly? I'm not sure I see any value in hiding the descriptions. People generally have no problem scrolling, even on mobile.

As far as I recall, the groupings on this page aren't "random" either. Specific ones were put at the top of the page because they were thought to be more important than the other ones -the organization was added after usability tests during early Drupal 7 development. I'm not sure how accurate those assumptions were (or still are), but the page was organized this way for a reason.

One last thought: the way I navigate this page currently is by knowing that the performance settings are half way down on the right hand side. Let's make sure that if we break these habits for people we have a good reason, and a better alternative order :)

[klonos]

Good points @jenlampton...

...or do we just come here because of habit?

I guess habit for most people, but as you said further down your comment:

...Let's make sure that if we break these habits for people we have a good reason,...

[wesruv]

@klonos++ As usual your screenshots and descriptions are super helpful, thanks for that... again :smile:

[klonos]

@wesruv yeah, over the years in the d.org issue queue I've figured that it's easier for people to get the point if you show things with screenies (where applicable of course) + edit them a bit to point specific elements. Same applies to Backdrop GitHub queue I guess. Visual is better.

To the issue at hand... I believe that with our choice of admin theme, something along the lines of Adminimal would suit better (simple, black and white icons instead of the more "radiant" ones used in Rubik).

[wesruv]

So I started working on this, and I'm at a stopping point, realizing now that I've addressed something that's not necessarily on point... but worth showing never the less.

I liked @klonos' (and Adminimal and other sub themes') idea of adding icons to the configuration page to help identification. If this becomes responsive it may effect the location/ordering of some of these elements, so the page would be easier to scan with graphics over just plain text.

After I did that it seemed like I should also be applying these icons to pages in these sections... so I've now taken a ticket that asked for a responsive layout on configuration and made it about iconography across Backdrop config... lol

I'll be working on the layout as well, I'll make sure to get that in a different branch. Here are some screenshots of the work, the icons are mostly from fontawesome, some are modified versions of fontawesome icons so they make more sense next to each other.

Configuration page

Performance

Permissions

Administration Bar

Let me know what you all think, if this is worth keeping around or not.

[wesruv]

Ahh, I guess this ticket is a meta about the config page, never the less... now I made it an admin theme wide change (maybe) :stuck_out_tongue:

[klonos]

Lovin' it!!! :heart: :+1:

Can I pleaz haz iconz on the admin bar menu???

[Graham-72]

:+1:

[klonos]

I think it's best that we moved to a separate, dedicated issue since this is a meta: #1178

I've copied all my lengthy comments (mainly due to screenshots attached) over to that issue and deleted them from this one. This keeps the meta as clean as possible with less scrolling for others reading through it. Can you guys please do the same and copy your comments there? Thanx.

[klonos]

...added the new issue to the list of tasks of this meta.

[jenlampton]

I must admit, I do really like the icons. Even in the admin bar. But I'm worried about what happens as contrib adds new categories. Do we have a default "settings" icon that we use for everything that's not defined? Or do we slowly add more icons into core over time as contrib proves categories to be good ones? Or do we let each category be defined along with an icon?

[wesruv]

@jenlampton https://github.com/backdrop/backdrop-issues/issues/1178#issuecomment-141276162

[wesruv]

I mocked up what it'd look like in the admin bar, it looks really busy. If we had an 'mega-menu'/'uber-nav' (http://www.smileycat.com/miaow/archives/images/megamenus/vwo.png) it'd work just fine, but with the current dropdown it doesn't work.

[wesruv]

I need to check if this ticket is basically done... I remember doing some responsive work on this page, but I can't remember if that was merged.

[klonos]

Can't wait to test this on a PR sandbox now that we have that!