Findings from the usability study at the University of Minnesota 2011

During the study it was found that the most participants were awfully confused with the enabled/disabled themes when they were on "Appearance". They did not understand what was going on.

What is required is a cleaner and clear interface to segregate themes into different sections. One of the approach that could be tried is a tab structure with the tabs as "Enabled", "Disabled" and "Browse New". That being said, we probably also need a better label instead of "Enabled" and "Disabled".

Also consider to develop means of recommending a theme as admin and/or front end.

During the study, it was also found that it was not immediately clear to some participants that "Settings" is the place to go to edit the color for their theme.

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

catch’s picture

Version: 7.x-dev » 8.x-dev
Priority: Critical » Major

I'm moving this to 8.x, it probably can't be fixed in 7.x at all.

Also I'm downgrading this to 'major', while enabled/disabled/default themes is definitely confusing, being confused about it doesn't prevent you from using your Drupal site - at worst you get stuck with the theme you already have or have some themes enabled that shouldn't be. See http://drupal.org/node/45111.

Bojhan’s picture

Title: Confusion with enabled/disabled/default theme » Not clear which themes are enabled and disabled

Ok let me clear this up, this issue is only about the confusion figuring out which theme is "currently" showing on their website.

Default theme is part of this issue, but in a way isolated. Because this is a issue of the appearance page its layout and contents, rather than just labeling.

What I found most striking is that, "Seven" which has no real importance to the beginning user is big in there face. Can we remove this (e.g have admin themes down on the page)?

Jeff Burnz’s picture

I like webchicks idea of using tabs on the modules page, do you think that's feasible for this page?

xmacinfo’s picture

What I found most striking is that, "Seven" which has no real importance to the beginning user is big in there face. Can we remove this (e.g have admin themes down on the page)?

The are no admin themes in Drupal 7, even if Seven is branded as an admin theme:

name = Seven
description = A simple one-column, tableless, fluid width administration theme.
package = Core
core = 7.x

for 8.x (and maybe a backport to 7.x) we need more meta information for admin themes. For example:

name = Seven
description = A simple one-column, tableless, fluid width administration theme.
package = Core

; new to 8.x?
type = Admin
core = 8.x

I digress, since this is probably an issue for 8.x somewhere. :-)

xmacinfo’s picture

Found #550102: Allow a theme to set itself as an admin or frontend theme exclusively, which is a start. We need a way to mark a theme as 'admin'. After that, it would be easy to hide there themes behind a tab.

dcmistry’s picture

Jeff: Spot on! In fact, when we are discussing this issue I too suggested the tab layout for this page. It could have three tabs based on what is enabled, disabled and what could be browsed.

eigentor’s picture

+1 for using tabs.
This could be an elegant way of hiding things that the new user does not need to know or see.
But it needs testing if they will click the tab some time later.

dcmistry’s picture

I am all for testing :)

Jeff Burnz’s picture

Heres a comp of what I might assume we are talking about, rough to show the concept.

Bojhan’s picture

I am not really sold on this direction, sure it might work on this one page. But where would this be reusable? I feel the main issue, can be solved by reoderding the importance of items and removing admin themes from the initial display.

eigentor’s picture

Jeff's Screenshot:

eigentor’s picture

I am with Bojhan: Tabs don't help if they just hide the mess.
Thinking needs to go what we show and why, and maybe a clearer hierarchy already helps.
This is not mutually exclusive with tabs.

Jeff Burnz’s picture

We know the problems, lets work towards solutions, anything else is pretty much noise.

Some ideas:

- place all the disabled themes below a line or in a darker shaded area
- when the theme in enabled it moves into an area above
- the Default theme is always on the far left, with a colored background
- dont use the large screenshots, these hog screen real-estate and don't add anything
- use AJAX when enabling or setting a theme as default, highlight the "Settings" link when its first enabled

- have a third Primary tab (next to "List" which would need to change it name maybe) where the Admin themes live. Having it down the bottom is weird and hides it also (you have to scroll to even know its there).

- make this all dependent on #550102: Allow a theme to set itself as an admin or frontend theme exclusively

xmacinfo’s picture

@Jeff Burnz: I like your tabs in #11, #13, however, we should only have two tabs:

| Display Themes | Admin Themes |

So all admin themes (specifically marked as admin in the .info file) would be hidden. :-)

As for the main theme page, all your ideas in #15 are good.

aspilicious’s picture

Sub, I predicted this to be an issue. I couldn't find the admin theme myself when trying drupal7 the first time. Sadly it was to late to change the UI. So lets fix this mess in D8 :D.

aspilicious’s picture

Btw: whats wrong with secondary tabs? Not visible enough?

Jeff Burnz’s picture

Here's a design concept for #15. Essentially I have flipped the D7 idea of have having rows for enabled themes and a grid for disabled themes - now I have the active/enabled themes in a fixed grid and the inactive/disabled themes in rows. In my experience you tend to have more disabled themes than active themes (especially early on - new users like to upload lots of themes and try them out).

I've tried to clean up the UI and make it very simple, using solid blocks of color, no borders and plenty of white space. I'm not sure about the AJAX suggestion in #15 - I have added notes below to describe how this might work if we did.

Active Themes

  1. Active themes are positioned at the top, displayed in a grid (fixed height grid containers to avoid float clearing issues).
  2. The Current Default Theme is high-lighted with a label/heading (if this is h2 it makes semantic sense).
  3. The default theme has one link - "Configure". The other active themes have three links - "Configure", "Set as Default Theme" and "Deactivate". This language is not so important as the design, the current Enable and Disable would work as well.
  4. If we use AJAX when a user clicks "Set as Default Theme" it would "move" to the top left corner of the grid and be styled as the "Current Default theme", the old default theme would move one to the right. If the user clicks "Deactivate" it is removed from the grid and falls back into the inactive themes list.
  5. Notably the description is not display here - instead we show this on the Configuration page. Often descriptions have links to help or the issue queue - you are most likely to need this when on the configuration page, not on the Appearance overview page. This also helps declutter the UI for active themes.

Inactive/Disabled Themes

  1. The current D7 grid is a mess - it has float clearing issues and is difficult to scan when there are more than 10 - 15 themes (not unusual at all, I've seen sites with 40+ themes). Therefor I have shown these in rows, which facilitates easy scanning (users only need to scan down).
  2. Each row has a screen-shot, theme name and version, description and two links - "Activate" and "Activate and set as Default Theme".
  3. This list should be alphabetical.
  4. This list does NOT show Admin themes, instead we display them somewhere else.
  5. This list does NOT show themes with the flag hidden = TRUE.
  6. If we use AJAX when a user clicked "Activate" it would "move" to the active themes grid and append to the list (be the last item in the grid display). If the user clicks "Activate and Set as Default Theme" it moves to the top left of the grid and get the Current Default Theme styles. Naturally it is removed from the disabled themes list.

You'll have to imagine the design concept is embedded it the rest of the Appearance page:

redesign the appearance page for drupal 8

xmacinfo’s picture

@Jeff Burnz: I like very much your mockup. The way you separate the enables themes versus the disabled (available) ones is efficient. Also, like you said, we do not need anymore a larger version of the theme capture, although a nice lightbox effect would be awesome here.

However, where do we hide the admin themes, or better yet, where do we show them? Do we create:

• a new Admin settings page?
• a tab to show admin themes?
• a collapsible region to show the admin themes?

aspilicious’s picture

This still gives some problems.

Users don't know what the difference is between:

- active and default
- active
- deactivated

Don't know if we can fix that...

Grayside’s picture

The difference between enabled and disabled has always seemed really obscure to me.

I've always though of enabled themes as "Available" to be activated for use. Another way to describe it might be Installed.

Jeff Burnz’s picture

Later today I'll break this design down into smaller screen-shots and detail the thinking for each part of it, much is designed around the concept of visual hierarchies.

@20 - not sure as yet, maybe use a secondary tab?

@21 - this is where we should really be linking to a help page with the docs to explain this. We could add a more verbose message when the theme is enabled - such as "this theme is now enabled and is available for use in your site".

aspilicious’s picture

If its avalaible in my site I suspect it to be *the* theme I would see on the frontpage. It needs a little more explanation.
"this theme is now enabled and is available for use in your site. Set it as a default theme to make it your current front end theme."
I'm not good english so it needs to be rewritten but you'll get the idea.

Why do we have multiple active themes? Is this for contrib? If it's for contrib can't we make core in such a way that there is *one* active theme?

Jeff Burnz’s picture

You are able to have multiple enabled themes because users can select their own default theme if they have the right permissions, also you can invoke a theme for a particular site section, page etc (you don't need a contrib module to do this).

aspilicious’s picture

Hmm this makes it harder to create a clear UI. We should add part of your explanation in #25 to the help page.

Jeff Burnz’s picture

The way I see it the goals of the user are to:

- find and enable the theme they just uploaded
- change their front end theme
- know which theme is the default, so they can easily configure it
- find the link to configure the theme
- disable themes
- learn something about the theme before they enable it (via the description)

That's really a lot already, trying to teach users about Drupals theme switching capability is beyond this pages capability imo and would needlessly over complicate things for most users who don't use this feature.

aspilicious’s picture

I'm ok with that.

droplet’s picture

(main page)
- Site Themes
-- a short description tells users can choose their own theme.

This page includes all ENABLED theme and highlighted the Default theme

(another page, a link or a tab redirect to this page)
- Install or active a new theme
--Enable a new theme
--Install a new themes
--- Install form URL
--- Install form File
--- Get more themes online

I think most of Participants and exist Drupal users don't know THEIR USERS CAN SET A OWN THEME ON PROFILE PAGE. So they confused with enable/disable concept.

Jeff Burnz’s picture

@29 - the problem with this is you're not saying why we should have these things or how they solve the design problem. Bojhan voiced concerns about introducing a new design pattern and asked for a solution that keeps these things on one page - the only thing I have left out right now is Admin themes and how to deal with those. Couple of those things you included are not in the scope of this issue (uploading themes etc).

xmacinfo’s picture

You are able to have multiple enabled themes because users can select their own default theme if they have the right permissions[…]

@Jeff Burnz: Setting themes from the user profile page have been removed from Drupal 7. We'd need a contrib module to do this in D7.

@aspilicious: Like modules, themes can be enabled and disabled. However, only the selected (default) theme is displayed on the home page (in D7 users need to close the overlay to see the result). From all enabled themes, only one is displayed at a time.

In advanced sites configuration, there are numerous ways to display another [enabled] theme by context, variable, path, etc. This is how some Drupal sites will use one theme for the home page and another theme for a section of a site.

catch’s picture

We should seriously consider removing the checkboxes for multiple enabled themes (apart from default + admin), and allow modules to provide their own UI for it. We'll need to keep the settings/blocks UI for multiple themes if they exist - for admin as much as anything else, but that doesn't require the main page to have this option.

There's a fair bit of discussion of this at #292253: Remove the per-user themes selection from core - haven't re-read that issue but it's good background.

droplet’s picture

@Jeff Burnz
Themes on (- Site Themes) page are Enabled. We give a SHORT & CLEAR MESSAGE THERE to tell them this is ACTIVED!

2nd,
D7 has a link to "Install new theme".
We enable a disabled theme is similar to install a new theme from URL/FILE
It's on same page will let users know "Oh. It's the way to add more theme to my site"

Upload theme (= install theme) should be included in this thread.

--------------------

"@Jeff Burnz: Setting themes from the user profile page have been removed from Drupal 7. We'd need a contrib module to do this in D7."

Oh. I missed this. So now, we can force to enable ONE theme only and that will be the Default theme.

Jeff Burnz’s picture

Lets go back to the OP and see how this design works to try and solve the problems:

>During the study it was found that the most participants were awfully confused with the enabled/disabled themes when they were on "Appearance". They did not understand what was going on.

> What is required is a cleaner and clear interface to segregate themes into different sections.

Active Themes

appearance_redesign_1167444_03_activethemes.png

  1. Here we use a "titled section" concept with heavy shaded background on the title and white text to make it pop. Positioning this in the top left corner is consistent with the notion of being first in a list, the top position (in LTR languages, in RTL this needs to be flipped).
  2. The theme names are horizontally aligned - this creates a gap above the the non-default theme names - this void makes them feel lower (in the order), but they eye picks up that the theme names are all on the same plane so its not visually disturbing.
  3. The screen shots are the same size throughout the UI, using a bigger screen-shot is not a strong indicator of important in this context (to vague). To save screen space we just use the same size image.
  4. The links - you will almost immediately see there are more links on the non-default themes than the default theme, these draw the eye (being collectively heavier than the single link on the default theme), this forces you to notice there are more options. Again everything it perfectly aligned so the integrity of the layout is not compromised.

Inactive Themes

appearance_redesign_1167444_04_inactivethemes.png

  1. We use a shaded section to separate these away from the active themes - note in the original screen-shot there is a lot of white space to help make the distinction that these are somehow different, the label simply makes this obvious.
  2. Each theme is a separate row, with screen-shots arranged vertically this is very easy to scan down - the user only needs to scroll and look in one position on the screen, as opposed to the current usage of a grid where the user needs to scan left to right and down - the reality here is that you end up scanning randomly because the layout is often broken due to float clearing issues.
  3. The theme names are given plenty of white space to make them easy to pick out, in case the theme is not evident from the screen-shot.
  4. Links align vertically with each other which makes them easy to locate - again we use sufficient white space to make them easy to pick out.

I think it should be pretty easy to get a patch for this ready, even a rough one for testing out the UI.

I like the idea of adding a more verbose message when a theme is first enabled, and I have not as yet dealt with Admin themes (which I would really like to see separated away under a secondary tab).

Jeff Burnz’s picture

@33 "+ Install new theme" is an Action Link that sits above this design. This issue is about giving the users a very clear UI for managing themes on the Appearance page. There is a separate issue for action link visibility (sorry I cant recall the thread, but its part of the UMN findings).

xmacinfo’s picture

@Jeff Burnz: I am speachless. This is exactly what we need.

Current Default Theme should display with a (?) button linking to the help page, which would explain the lingo. I think we could use the same (?) buttons as in the module page.

Admin theme selection should be hidden in a dark corner (or a completely different admin page). I fear that a tab called “Admin Theme” would be interpreted as “Administer theme”. So I am glad it does not show up in you comps.

xmacinfo’s picture

Also, larger thumbnails should not be discarded. We could display them in a Lightbox (if the theme have a large thumbnail).

But that would make for a new issue, if your new layout is committed.

stBorchert’s picture

Status: Active » Needs work
FileSize
17.23 KB

Here's a patch based on the mockup of Jeff in comment #34. Its not a complete solution and is only a first draft to test how the new layout works.

aspilicious’s picture

FileSize
104.89 KB
91.91 KB
101.23 KB

Here is a screenshot of the current test implementation
theme_current_mockup.png

I think the horizontal line should go. I made a mini mockup of the design without the line
theme_mockup1.png

I'm also not sure if the difference between active and not active themes is visible enough. So I tried to make a mockup of something I had in mind. Sadly I'm not a designer so I didn't get it like I want.
theme_mockup2.png

Jeff Burnz’s picture

I'd hadn't planned to change the URL from settings to configure - I'm not sure that is really in scope or a hard requirement to make this work - my thinking had been that you configure your settings. I'm more in the mind to leave this as "settings" rather than make this change.

Issue: theres a problem with the local task tabs - we have a new tab "configure" which links to the Global settings page, and the old Global Settings tab which is now linking to admin/appearance (the list), I think we should remove the new "configure" tab and just keep the original "Global Settings" tab.

I've given the patch a few tweaks, mostly CSS and markup structure, nothing too major - this better matches Seven's color scheme (the design I did was a bit rushed and I was best guessing). The key things I worked on are font sizes, colors, removing the border between the two lists and white-space. I also used min-height instead of height on some things so text zoom won't smash it up.

@aspilicious - the styles were not complete, I think a little white space can achieve basically the same thing without introducing such heavy elements into the design.

This is only the 2nd patch I have rolled with git so... here we go...

Jeff Burnz’s picture

Wrong patch, bah. This is the one with the right grays, using the same light gray as even table rows.

Also attached live screen-shot (this is inside the overlay) - more white space and in particular the inactive title is inside the shaded area (just used a different selector to apply the shading to the entire area).

appearance_live_1167444_05.png

aspilicious’s picture

FileSize
6.35 KB

Thnx for the patch. Yeah I know my design was to heavy thas why I'm not a designer ;).

Actually we should do a new mini usabilty test when the design is done, so we can confirm the issue has been fixed.

One note:
I disabled seven theme and suddenly my tabs were broken.

xmacinfo’s picture

@aspilicious: Please edit your post and remove the space in your attachment filename. I am not able to look at it :-)

Jeff Burnz’s picture

@aspilicious re 42, yeah, thats the tabs issues I identified in #40, I wasn't sure if this was some problem with the implementation or some problem when I first applied stBorchert's patch from #38, I saw some mismatch hunks but applied it anyway, the main thing about my patch is the style.

aspilicious’s picture

FileSize
6.35 KB

Lets try this than

stBorchert’s picture

Status: Needs work » Needs review
FileSize
17.83 KB

Sorry, my fault. I forgot to change some paths.
Now the tabs look like this: https://img.skitch.com/20110605-g2p8atpnbbuqpu1bin97348w8i.png

Patch based on #41.

Status: Needs review » Needs work

The last submitted patch, theme_section_redesign-1167444-46.patch, failed testing.

stBorchert’s picture

Status: Needs work » Needs review

Now with updated tests.

stBorchert’s picture

Uh, forgot to attach the patch :/

aspilicious’s picture

Something is going wrong in your testing environment. The last file always get applied badly.

stBorchert’s picture

@aspilicious: Latest patch passed PIFR tests without any problems.
I've created it from a clean checkout of Drupal 8.x (git clone --branch 8.x http://git.drupal.org/project/drupal.git).

aspilicious’s picture

It passes but when I apply the patch I get some parts that don't apply cleanly. I don't know why. I don't have these issues with all the other patches.

Jeff also noticed this:

"#38, I saw some mismatch hunks but applied it anyway, the main thing about my patch is the style."

stBorchert’s picture

Could you please post the message or a screenshot of the error.
Do you apply the patch to the 8.x-branch?

aspilicious’s picture

FileSize
81.85 KB

apply_warning.png

stBorchert’s picture

Unfortunately the left side (original file) isn't shown ...
Are there no messages and details regarding this error?

aspilicious’s picture

FileSize
85.84 KB

Here is the match that didn't work. I can't see a problem... Strange.
Nop no other errors in my gui.
unmatched.png

And it is always the last hunk of the last file that doesn't work.

Jeff Burnz’s picture

Status: Needs review » Postponed

Postponing this redesign until we have some idea of where #474684: Allow themes to declare dependencies on modules, that said we can continue to prototype changes, possibly work on the UI for the changes proposed in #474684.

Jeff Burnz’s picture

Also this issue needs to be taken into consideration: #550102: Allow a theme to set itself as an admin or frontend theme exclusively, which may well be a harder one to solve from the UI perspective.

jibran’s picture

sun’s picture

Erm — isn't this entire issue obsolete?

The Appearance page outputs enabled and disabled themes separately since D7 already...?

xmacinfo’s picture

I agree with sun. All this issue is obsolete.

Bojhan’s picture

Status: Postponed » Closed (fixed)

Yup its already fixed. It hasn't come up since