implement the top level Appearance / Choose Theme admin page

Hi all,

just wanted to tell that the project is not abandonned by me. I am working it right now and over the next week.

A first vision has been published on http://www.d7ux.org/appearance/ (comment 6).
I am working on screenshots right now, so stay tuned.

Ok, first Screenshot. Landing page v1.

Obviously everything is not in place :

* It actually lacks a feature i would like to add which is "Have a draft status" for theme that are not ready for production.
* Copy of a theme create a sub-theme.

some more detailed screenshot to explain the behavior and some food for thought:

Scan already installed themes

When the admin clicks on the "Appearance" Link, he arrives on the "theme-list" page.
Here you can see that the admin can either click on a theme, search for a new theme, upload a theme (TBD) or create a theme from scratch (TBD).

By clicking on a theme, he is sent to the "preview-normal.png" page.
On this screen, the user can preview how the website will look like and test all the existing themes sequencialy (via the left and right arrows next to the drop-down menu) or by selecting the theme he wants to try on the drop-down menu.

Customize a theme

If he clicks the "Customize" button, the Admin Header extends to "preview-customizing.png".
Here he customize the theme both globaly by the header parameters(TBD), and localy via overlays over the zones (TBD: cf "preview-overlay.png")
It is possible to save the customized theme as a new theme (a sub-theme).

Search for new themes

If the admin clicks on search for new themes, on the themes list, he is sent to the "search-and-download.png". By default, no filters are applied and the most recent themes compatible for the current version are displayed.
The user can filter the list using lists of parameters.
Typical parameters would be type of site (blog,ecommerce,), number of columns, position of the sidebar, css vs table-based. fixed-sized vs. fluid-sized vs. elastic-sized.
Idealy an icon would exist for each attribute. In the list of theme, all the attributes are displayed as an icon.

Install new themes

For each theme in the new themes list, a button is present.
The available states for the buttons are "Install", "installed" (if the theme is already installed but not updated), or "Update" (if it is already installed, but updated since then).

When the admin click on install or update, the buttons turn into an "installing..." and disables. The file starts downloading (visible on the sidebar), allowing the user to keep navigating the list for other themes.

After some themes are downloaded, the user can preview the themes (It actually sends to the "preview-normal.png").

Gilles, Mark Boulton will look at this in a bit - so in the mean while I hope to give you some feedback. First of all I like the track you are upon. Could you explore what type of customization would happen in that area you proposed, since the current options within Drupal are more then could exist in such a small interaction area (but you do want to do that).

Theme overview
I am not sure how this handles multiple themes, I see drafts but that doesn't really make it clear I would go for something as active, not active, default.

The version number is not really important, only if it doesn't apply to your drupal version as a whole (so 6.x theme on 5.x). What does x do?

Thanks all for your feedback. I'll hopefully post some updates later tonight.

To answer Leisa comment about defining "what is a theme", I started a google doc with the different attributes on
http://spreadsheets.google.com/ccc?key=rKN0QAE49yjD_EHloEf23lQ

Here's an idea for Appearance. General idea...

1. 80% of users only have 1 theme, so hide the notion of other enabled themes.
2. D6 thumbnails are worthless, so make the thumbnails bigger
3. I've added in a way to get to theme settings vs global settings, but I honestly think these settings belong under modules and config. Yes, I know they're theme related, and some of the files are stored in the theme directory, but let's hide those details from the user. I mean come on, who expects to configure how their search settings appear via a theme?
4. I neglected to add two things which probably belong A) credit to the designer B) version number. I expect both of those would fall under the description but before the enable / preview

http://blip.tv/file/2290150

Take aways...
1. When designing modules and config, find a way to incorporate theme settings

Interesting, I think Noyz is on the right track. However the sub-theme tab seems doesn't seem to give much information from how the themes are layout themselves on what a sub-theme is or where it belongs to.

Onto 4. I am not sure you are totally right on this, yes sure - there are quite some settings that don't belong there. But certain settings do make more sense to below under theme settings, say for example the color picker.

Small detail: http://janaksingh.com/portfolio has some cool visual effect which could be mimicked on Appearance?

+1 for adding a grid layout to the theme selection page and placing the active theme above the de-activated themes in #8.

Thank you all for your feedback (that i just discover, shame on me i should have checked it before)

Noyz: Thanks for the amazing video. I aggree with most of your point:
#1 : Yep definitely, 80% of the user base would probably go with 1 theme. Yet we have to be sure it allows multiple theme. I really think that most of the user base (80% of the remaining 20%) goes with 1 theme, many sub-themes with different colorsets. Yet we have to keep track of the remaining solutions "Make the most frequent tasks easy and less frequent tasks achievable."

#2 : i picked this idea already in the current revision of my work on Appearance.

#3 : i'm not sure on this
From what i've seen in the global settings, you define :
* What should be visible
* The color theme,
=> I think those two depends on the theme only.

* Module per module caracteristics
"who expects to configure how their search settings appear via a theme?"
=> I am not sure what you refer to ? What search settings are settable via a theme ? If those are search settings, they definitely needs to be defined on the "search tab".

#4 As already discussed, how does the revision number can help ?
+> The way i am going to is : Bigger thumbnails, Name of the theme, owner, Rating,

I'm also not sure the way you relate subthemes to their relative main theme. There is no single view to see what themes are accessibles (whether subthemes or main theme).

@Dries: Like this effect, not sure how revelant it is in this case. Shall we display thumbnails only and display info on mouse onhover ?

Tell me, WDYT ?

I think, show us.

Regarding #3. Agree there will probably always be some settings. But at present, I'd NEVER think to go to Theme > Settings to enable/disable/configure such features - like search settings. My point was to start thinking about these features as we think about other related areas like Config

subscribing

+1 to killing the theme settings pages. :-p There's no reason you still couldn't have theme-specific options but just placed under the config pages.

subscribe

subscribe

I've rev'd the appearance wireframes to be more specific on theme settings, and arrive at a better approach (IMO) in regards to multiple themes:

http://blip.tv/file/2397857/

Many will contest the notion of global theme settings, but here's the rationale:
1. Many theme settings, although Drupal theme settings, don't feel like themes settings (enabling breadcrumbs, setting the author/date format, setting the search result format, etc." As such, users will not go to the themes/config to adjust such settings.

2. Related... Modules and Config will be a primary location for all users, and a place to adjust sitewide settings. Features like breadcrumbs, mission statements, pictures in posts are all "config" and therefor should be found there, and will be better received and used more if these settings are pushed there.
.
3. The list of themes settings should be standardized (vs. set based on the primary theme).

4. If a theme excludes features not set in the standardized feature, then those features don't show. For example, if one of the standardized items is to turn on/off breadcrumbs, and one enable theme excluded breadcrumbs in it's .tpl file, than that theme just won't show breadcrumbs even though it's turned on. Yes, this could be frustrating for some users, but hopefully this is a short term problem. Doing it this way enforces a standard, and ultimately themers should build themes that map to the standard.

what do you think?

one more thing, color module would also live under the theme. So logo, favicon, and color

So one concern with me is that, by making it a checkbox you actually give more attention to multiple themes then you would, by automatically turning it on. Why not design, so that multiple themes can just fit in? I can see several solutions to just designing them in, as its not a high use case - we don't have to optimize that experience (one is setting defaults - we can just put that in the theme specific setting).

I am quite concerned with your IA proposal, I don't see why these type of activities require such radical change of the module / config page behaviour (bubbeling up) nor why they require (looking like) several links. I feel you are trying to push this towards the structure, because that makes sense - but we should find a fitting label for these type of settings. Instead of making a new pattren.

Again, I don't see why these settings couldn't exist on a theme by theme basis - I understand you don't expect them there, but eliminating the ability seems rather rigorous especially for multi site setups? Since its an edge case anyway, one can do a bit of learning to find out that those abilities are listed under the theme settings now that you have several themes enabled?

I would go as far as saying that, there could be two places for these settings to live. In one case - if there is only 1 theme enabled for it to be in Display (or whatever label) under Module & Config, but when there are several themes enabled that it could also live on the settings page.

Also I love the Related links, idea - I have been trying to push that forward for like a year - but I think within this design we actually have a space to put them nicely.

This is a quick idea, for the themes page if there are several themes enabled.

These settings already exist on a theme by theme basis, and they're getting lost. All I'm doing is pushing config settings to a config area. You said it yourself that you didnt know these settings existed - why then are you prosposing keeping them in an area that isn't getting found?

By making secondary themes enabled by default (without the checkbox), your solving for the 20%. Users in the 80% that want a new theme, will click Enable, and get two themes - not the expected behaviour. Then, they have to figure how how to make one the primary (drag and drop or weights for non js users). I don't think the checkbox will draw too much attention, so long as it's a clear checkbox.

Oke. Regarding the unexpected behavior, that is indeed not right - in my example a theme would be pushed as default if enabling. But it could be a functionality disabled by default.

I think the real discussion is in the disagreement over the prominence of the chechbox. I believe that a checkbox like this, will really draw attention - getting people to try it out (after all its the only form element on the page).. and on its own it really confuse people (since, multiple themes sounds useful)- is it something, we can place somewhere else?

So I understand your opinion on moving stuff to the configuration area, which makes sense - but I don't feel it should change the behavior of the module & config page to such an extend. Its just not worth the effort, for something so small. Since we are grouping all the settings on one page, lets just link off to that page.

I don't see why we want to to disallow theme per theme specific settings (it shouldn't in the new setup impend the design). It's a minor design effort to put some kind of per-theme grouping on that theme configuration page in modules & settings.

I think we might be trying to kill to many kittens, just redesigning the theme page and moving some settings to another place. Is diffrent to overhauling the complete display system, really worth the effort? If it's only a 20% use case, of it being seen at all.

I think a solution to the "checkbox problem" is placing it in between the "Active theme" and the "Available theme" part. That gives a more natural workflow for end-users:
1. I come to the page, see the Active Theme. I see that the screenshot somewhat resembles my site, so I now kind of get what a theme is (if I haven't before).
2. I look below and see that there are other available themes and that I can have multiple active themes. Since the checkbox is now more in the area of active themes, if I am a very new user I will be afraid of ruining everything (which is quite possible, so the fear is good) so I just leave it as is.

Concerning the theme settings thing: I have to agree with Bojhan that this belongs on a single page in Modules & Config. Especially since the new trend is to move all "settings-related" things there (or under "Site configuration" for now) such as User settings, etc. it isn't much of a change in trend to move this site from a tab in admin/build/themes to admin/build/settings or then admin/configuration/theme-settings.
About the problem that things can be enabled that the theme doesn't support. Themes can define their features in their info files, so it should be possible to look up all the theme features / settings for the active theme(s) and only show those options. Definitely a different issue, though.

One thing is missing from the video: A radio for "Default" when multiple themes are enabled.

What do we need the active themes setting for at all? As far as I know, these are only used if you give your users the choice of a personal theme when they visit the website.

I'd say this is used on far less than 20% of drupal sites.
So opting for pushing the setting if a theme is active or not somewhere deep into a config page.
On the primary appearance page you just choose your theme, done.

What would be great would be more feedback, at best committer feedback, whether this is something that can be removed from core.
I really think it should be, especially as this is a feature that is not very well documented and very unobvious. I remember from one of my first Drupal sites, that I only noticed about half a year after I put the site online, when a user sent me a screenshot because of a bug, that he had pushbutton enabled...
I don't know any use-case in which this could make sense. Something that is found in other software (phpBB, IIRC has it) is choosing colors, but that is something that should be done, with a better color module or skinr or whatever.
That would make these mock-ups much easier.

While I'd support removing supporting multiple themes on the site (in core), this should be a feature available in contrib, since sites use this to have theme switching based on sections. Also, sites might want to support multiple themes for users. So while we don't need to support it in core, we need to have a UI, which can support this.

My problem with Jeff's design is that he does not map items from themes like Acquia Marina, which he mentions. Core cannot predict theme settings for any future theme by its nature, so we need to let themes put in their settings and possibly alter out other ones (where a theme has a different setting). Standardizing on one set of settings would kill efforts like the TNT base theme under Acquia Marina or the Adaptive themes base theme which has even more options to configure your site (including dynamic selection of layout).

Also, given that the plan is to ship core with two themes enabled by default (one front end and one backend theme), setting theme options will already affect two themes. You might easily want breadcrumbs on the live UI but not on the admin one or vice versa. By mandating most theme settings under General settings, we make it quite much harder to build sites which don't have the same layout and looks all around.

I am entirely against removing multiple themes support in core #292253: Remove the per-user themes selection from core. This is a regression.

I've always used this powerful feature, especially in the pharmaceutical sector.

Please make sure that in this project we keep the multiple themes support intact.

BTW #502002: Wireframes for d7ux appearance was previously marked as duplicate of this. (To cross-link Jeff's previous mockups.)

Ok, here is an "approximation" of what Jeff is proposing. There are a few issues with his proposal as said above, mainly that Drupal 7 already comes with two themes enabled out of the box. His UI lacks any way to configure the admin theme (although he talks about it in the video). So there are several classes of themes:

- those not enabled are the easiest group, but Drupal 7 supports a disabled admin theme too
- those enabled from where they can either also be the default and/or the admin theme

So theoretically one theme can be admin even if not enabled, or can be enabled, admin and default all three the same time. Now how can this be visualized is tricky in itself. What I've choosen is that if a theme is default additionaly to being enabled, it is not shown in the enabled list. However, if it is admin and enabled, that means a user theme selector would show it to users, so it should also be shown among enabled themes. (In Drupal 6 enabled == those users with appropriate perms can select it; in D7, what enabled means is still undecided, since user theme selection was removed, and enabling a theme does not mean anything beyond that (except that you can configure its settings and blocks when enabled, except when you configure the admin theme)). Huh.

So the attached patch tries to approximate the appearance screen with this in mind, but does not yet implement actual actions for the action links.

Updated to include the gray bottom border on the groups. This is how it looks.

Enabled or admin theme gets: Configure | Disable
If enabled or admin but not default, it also gets: Set default
If disabled: Enable | Set default | Set admin theme

I realize Jeff suggests a drag and drop style ordering UI for specifying what the default theme will be, but the order of the themes beyond that has no meaning whatsoever and IMHO on his video, that the first enabled theme becomes the default is not communicated.

Anyway, this is a disruption enough that we can start to refine from here I hope.

Also, the patch changes all theme screenshots temporarily to this one (also attached).

Enabled themes

How about putting the enabled theme state into some advanced options for now? To please xmacinfo and others that use it, it could remain in core :). But on the primary selection page? This needs user testing once more...

This could also simplify your patches and worries with all those confusing states of themes.

@eigentor: Drupal 7 core already has two themes enabled by default, so it is not much advanced, it is how it is set up out of the box.

Even if the themes are enabled - do we need to show it to the user here?
He sets a theme as default or as Admin theme, and that is all (or eve more than) especially a new beginner should be bugged with IMHO.

@eigentor: Please note that this is the admin user here, so he needs to see all enabled themes. Also, Drupal 7 comes with two enabled-themes at installation time, Garland and Seven. So it's not only me that needs multiple-enable themes, Drupal 7 now needs it at install time.

@Gábor: I like your suggestions in #32. However I think we need to highlight the default theme to make it stand out from the crowd. Can we change make the theme name bigger and bold for the Default one? I would also move up the admin theme just below the default theme. Enable themes should be displayed after the admin one and, I think, we should display the two enabled themes in your example (we would list Garland and Seven).

I have not reviewed the code or installed the patch, though. :-)

@xmacinfo: this is a misunderstanding. There are two seperate things:

a) having themes enabled
b) where do we show that setting

All I am bitchin' about is b)

Admin user is the only user in a beginners site. So a beginner is exposed to it.

I see this a multistep-process
1) rename "enabled" to "user can choose this theme" (or similar)
2) putting it on an advanced settings page for the theme (could be just behind the "configure" Link Gabor has put in.
3) finding a good place for these settings - this could be what is mentioned in 2)
4) Totally reworking the themes settings page like Jeff points out in his Video.

Just today I did some user testing with a not-so-technical person. http://vimeo.com/5994325 Doing this reminds you of the total information overkill a user is confronted with visiting the admin area for the first time. Still choosing a theme is something a person like this might well be able to.

Anything he cannot understand or use I would be glad to put to a place he might expect it to be. The infamous "Options" or "Settings" link is on every windows or Mac application and only the brave click it - and know they do on their own risk.

@eigentor: well, we don't know what enabled means. Whether it is "an organic group can choose this theme" or "this theme might show up on certain sections of the site" or "a user can choose this theme".

One thing I was thinking about is that we might just list the enabled and disabled themes in two lists, and highlight the default and the admin theme via a thick border around the screenshot and/or a bigger title, or something like that.

Should mention that the inclusion of the version number in the title of the theme got some criticism from Bojhan, but we somehow should display the theme version number. It is important for support reasons. What asked a question in the forum about a module/theme, the version number is often important to answer. Users need to be able to tell the version numbers easily.

Here is an updated patch which changes how themes are listed. The default and the admin theme are listed first in this order in the enabled listing. I've added two markers on them: (A) they get notes in parenthesis (B) they get a subtle border around their screenshot. If a theme is both default and admin theme, it gets "default theme, administration theme" as it notes in parenthesis.

Note that due to how this UI is designed, to make an admin theme or default theme enabled but not special, you need to disable and enable it again. You cannot toggle the admin or default flag on the theme itself. That would be another link additionally to the already numerous links we have.

Still uses the image for all themes from above. For the screenshot, I've copied stark in two other copies and added them fake names, so you can see what happens when you have more themes enabled and more disabled.

So after looking at this page for quite a while, I think we should differentiate the administration theme from the actual themes. It only tends to confuse the bunch, and one wouldn't change administration theme often if at all.

So I tried to reuse the collapsed state, that we initially had on the theme page to expose its prominence. Be aware this is not the final implementation of fieldsets or anything at all, its merely a visual exploration.

This is the collapsed state, as shown I tried to avoid using any form elements and rather follow the consistency of page it's interaction.

This is the collapsed state, as shown I tried to avoid using any form elements and rather follow the consistency of page it's interaction.

Gabor, I like where you're going with this. I have but one nit. The admin theme and the site theme are not equal. In fact, if the admin theme is done correctly, nobody will ever want to change it. So everyone should be focused on the primary theme. Perhaps the admin theme should be a tab.

@Gábor: I like very much your idea. The only thing I would do is make the name of the default theme larger and bolder. The rest is fine.

@Bojhan: There is no way to differentiate a theme from ad admin theme. Any Drupal theme can be set as an admin theme.

In fact, if the admin theme is done correctly, nobody will ever want to change it.

Not quite true. Like any other themes, there will be modifications to Seven which will span in a new admin theme category in the download pages of DO. Furthermore, for many client branding will be incorporated in their admin theme.

Added an issue that could impact this UI, #550102: Allow a theme to set itself as an admin or frontend theme exclusively

If we have by all means to keep the "enabled" state on the main theme config page, let's at least work on the wording. The wording I propose in this screenshot is only a placeholder - "exposed" and "unexposed" is hardly better than "enabled". The trouble with any of this words is: they are misleading. Coming to this page, clicking on "enable" I would expect this to make the theme my default theme. It has to be very clear what the words mean. I always hesitated on the old UI, and thought: Mmm, do I have to enable, or default, does it have to be enabled in order it can be default? Why two settings? And the user gives up and does not choose a theme at all.

Further concepts in this screenshot: making the default theme way bigger than the others and highlighting it with yellow should help to make clear this is your default theme. IMHO even the word "default" was not needed here anymore.

To make this more intuitive, clicking on a thumbnail or make default should pop the chosen theme up to the top and magnified position, so there is an istant feedback, which implies this theme is special and gives a good chance the user succeeds in finding out this changes the default theme of the site. All this sure need a save button and the regular message your changes are not saved unless you click the submit button.

The magnified screenshot should also help with the "preview" Bojhan proposes. Still the preview would be nice feature. Just checked Wordpress: they do the preview in an overlay, which renders the front page in the previewed theme. But I doubt a bit we will see this for D7.

I think active/inactive is way less confusing than exposed/unexposed, especially for non-native English speakers

also the active/available feels like it only adds to the confusion, for an active theme isn't considered available and there are more available themes then the ones shown on this page, as it only shows installed themes that work with current version

@eigentor: Our core problem here is that we (== Drupal core) don't know what "active" means. It might mean a user can select it, it might mean you can pick it for some paths in a theme chooser (see themekey module), it might mean that you are running a multiuser blog and a module lets blog owners set that up for their theme (see blogtheme module). All we know is that core associates some things with an active module: it can be set the default; it can have blocks configured, it can have other settings configured. We don't know what active means on a given installation beyond that. As it stands Drupal 7 does not do anything with multiple active themes, given that user theme selection was removed. So there is no core feature whatsoever to accommodate, but there is a flourishing contrib space around this which makes it mandatory for us to support multiple themes.

Drupal core already support multiple themes, no need to load a contrib.

Just use Garland as the enabled default theme and enable Seven and make it the admin theme.

The result, two enable themes used in Drupal 7. :-)

No doubt about keeping up the support for it. I think I will provie a screenshot where I think this setting should go. It is just a question where to show it, no question that we keep it.

@xmacinfo: enable Stark and Minnelli and then what?

So the screenshot illustrates it: since this is a perfect feature for the 20% , this should be the place for it:

Hiding it somewhere innocuous like that seems like a very good idea to me.

+1 for the proposed solution in #53...removes a confusing checkbox from the Themes selection page, and better illustrates what it means for a theme to be "enabled"

@Gábor - I don't understand your question in #52. To give a quick answer, if I enable those two extra theme, in additino to Garland and Seven, well, the admin theme can be selected between the 4 enabled themes. The end results, 4 enabled themes, one for the default view, one the the admin pages and 2 extra themes that do not show up in other pages.

So we still need to enable a minimum of two themes to have a site theme and an admin theme.

@eigentor - In order to display a theme in the sub local task (menu under a tab) like displayed on your mockup, the theme must be already enabled. If it is not enabled, you will not reach this setting page! In your example Garland and Chrono are the only two themes enabled. All other themes are not enabled, including Seven.

What if we just removed that janky "configure links for themes don't show up unless you first enable/activate them" behaviour? I'm trying to think of why that's in there, and I'm curious if whatever it was is still an issue now that themes are identified by .info files, not page.tpl.php files, and that D7 no longer allows the phptemplate_ prefix for theme function overrides, thus far reducing the chances of function name collisions.

webchick's solution in #57 is what I assumed eigenator meant with #53, so +1 on that obviously.

@webchick: it is pretty important to enable a theme first before you can run any code inside them. Two examples:

- Themes might have dependencies which need to be fulfilled before the configure screen can be shown. They might call out to modules to build certain theme variables, etc.
- Theme translations are imported when the theme is enabled (otherwise it would be a waste of db to keep them imported all the time), so you would not get a localized configuration page as you'd expect.

Sorry, what I'm saying in #57 is on a slightly different tangent. But yes, +1 to #53 as well.

Better explanation: Since we removed the per-user themes feature from D7, the "enabled" checkbox on the themes page has only one function: it turns on/off the tabs you see in #53 for which themes are configurable. You'll notice only "Chrono" and "Garland" are visible, not also Stark, Seven, etc. etc. This is because Stark and Seven are not marked "Enabled" so their settings are not exposed as tabs.

So what #56 is saying is that the screenshot in #53 is impossible to do, because it's a chicken/egg situation: You can't see the settings page to check this box unless you've first checked this box. :P

So in #57, I am suggesting NOT tying the visibility of those settings pages to the enabled checkbox in the first place, and just letting all themes be configurable (we'll probably want to move away from tabbed navigation if we go that route but I assume that'll be part of the proposed revamp).

Hope that makes sense. :)

#59: Well, damn it. :) Back to the drawing board!

@Gábor: is there any reason we can't just not load up any of the theme's settings or anything aside from the translation of the "enable" form item (which should be the same for every theme anyway) and .info stuff like dependencies so we can disallow enabling the theme?
so then if the theme is enabled, the form is submitted, the same page reloads and the options are now available, causing users to be forced to look at the page

but that would still leave the problem we would have if we just slapped every installed theme on a tab, pretty sure this would render the ui unusable on sites with lots of themes, but I think that's an issue on its own

#59: Well, Themes calling out to modules has a point. So to untangle this, the only way I see is to force themes being enabled once they are uploaded. But we can divide this into cases.

1. Core themes.
There should not be a problem activating all core themes by default. This would mean activating color.module by default for Garland - but actually this is not mandatory, people might not want to recolor Garland. Still find it a good idea: if we have a recolorable theme in core and give beginners a chance to find this cool feature, enable color module.

2. Someone uploads a theme, and may have succeeded to upload some modules it depends on. drupal_set_message: "You have uploaded a new theme. Enable it in order to use it. We must find out if your regular user follows this message if it is clear enough (Experience from the formal usability testing?)

4. If we don't like this messaging and redirecting, there might at least be a way to make the "setting active" more intuitive.

You click a thumbnail of the "disabled" themes: it comes up into the white area. No need for a label "Enabled here" because the full color hints at that. Your get a message "To enable this theme, click save". Once the user saves, all dependent modules are auto-installed. There is no link to disable a theme here on purpose, since you hardly ever want to do this (as a beginner).

The advanced user goes to settings and finds a way to disable themes. If we are really keen we can do drag and drop on this screen one day, this way themes could be disabled and enabled. All this expects that the enabled setting e.g. for organic groups (or the non-longer-existing user theme selection) gets a different setting, that has nothing to do with the "enabled state" you need to be able to configure a theme. Hopefully the greyed out and transparent state gives a hint that these themes are only "half there". I hope a user is courious and clicks it to see it more clearly and hop, up it goes into the light.

Your click it once more: it goes up to the top magnified position. Thus you have to pull it up in a two-step-process that I hope to be intuitive.

But I must admit this is trickier than expected. Drupal multiple tangled dependencies come at a price :(
Actually many of the most popular themes have module dependencies like Acquia Marina.

Still if we could sort it out for Core themes would be a clean start, and given Drupal 7 will have more than Stark, Seven and Garland (ouch) will well serve 50-60% of the people.

I'm not sure we're getting a big boost in usability here. The vast majority of users starting out will think of Drupal as a web tool which has ONE look-and-feel that end users see, accompanied by an admin interface. Yes, Drupal uses a theme to render the admin interface, but the admin theme is not equal to the end-user theme. Most will think this is Drupal and why would i change this. I think at present people change it as an artifact of the current usability issue where users are not clear where administration stops and usage begins. A problem that will go away with D7. That said, IMHO, the two do not belong on the same UI. Said differently, would the admin theme "seven" ever be enabled as an end-user theme? I'm pretty certain the answer is no, and if that's the case, why are we burdening users with this decision?

Additionally, why burden users with idea of multiple themes unless they specifically request such a feature. That said, it seems to me that enabling a disabled theme should always replace the default - unless the user decides otherwise. If users want multiple themes, they should go to config and turn on a setting for multiple themes.

My two cents

@webchick, @seutje: another issue with making disabled themes look like enabled ones is that update status only checks for updates for enabled themes. I've specifically opened #542828: Do not special case disabled admin theme to not even let the administration theme picked from disabled themes. One thing we could do is to auto-enable themes when found (when visiting the theme admin page). That would still require a disable feature to let people remove themes if they want. If there is no disable operation, we just keep cruft in the database (translations, theme settings, etc). Not that we currently remove any of these, since there is no "uninstall" operation for themes, only "disable". So we might not care that much actually.

+1 for auto-enabling themes when going to themes admin page. Not having to do the seperation between enabled and disabled in the display makes it 1 step easier.

A disable option could easily be added like shown in #53

How are module dependencies get handled at the moment - I guess you have to install any theme-specific modules manually? So one could think about making this automatic, but if it is not there now, we don't make things worse if it is not in D7.

-1. That will not work.

1. Enable all theme automatically.
2. Disable one or more theme.
3. Now, how do we expect to re enable a disabled theme?

We still need, after all a enable/disable switch!

@xmacinfo: this can work quite well, since we can easily provide an "enable" switch. Just the workflow is different.

1. core default: all themes enabled
2. someone uploads one or several new themes and goes to themes admin page: all themes enabled automatically
3. someone disables a theme manually: the mockups from #63 or #47 or whatever apply.

But the main problem would be solved: the 80% user would only see cases 1 and 2 and never be confronted with a confusing "disabled" state. Only a more knowledgable user that knows what disabled means gets to see that, since he manually disabled a theme.

Mission accomplished.

@noyz: no problem with not exposing seven as a normal theme. Themes could get an "administration theme" flag in the .info file so they only show up in the admin theme collapsible area.

@eigentor: Agreed! Screens #63 or #47 would let the admin user enable a theme previously disable. Disabling a theme could then be make like #53. However, in #53, disabling a theme should return the user to screens #63 or #47. So I guess we have something here.

Also, I am against the creation of a category of administration theme. In my opinion, and the opinion of others I saw in the D7 issue queue, the Admin user can use any theme and mark it as admin, whereas any theme, including Seven, can be used as a regular theme. Seven can create a satisfactory default theme, even if it's using only a few regions. Anyway, this should be another issue.

subscribing

@Dries cheers for the shoutout mate :-) http://janaksingh.com/portfolio is my portfolio site

I really like #63 and am also in favour of getting rid of the column of "enabled" checkboxes. I like the suggestion to have themes enabled by default with the option to disable the theme for "power users."

If possible I think it would be nice to see two additional tags added to the enabled themes:
1. Admin theme (with a link to change the admin theme using the current UI)
2. Content editing theme (with a link to change the admin theme settings using the current UI).
This might be more appropriate under a new issue though.

@eigentor's mockups did not cover setting the admin theme, so I took Bojhan's advice and put it on a collapsed fieldet looking area (yeah, an actual collapsed fieldset) under the main themes page. It can also be made a tab as Noyz suggested. Also, some parts of the patch were in need of a reroll.

Still did not implement actual working links, but moving out the admin theme settings cleaned up the way, so we have less links per theme :)

This screenshot also highlights that variable width descriptions are not nice but we cannot do much against them.

Ah, the styling could be done by us css guys.

We could leave out the "enabled themes" because it is self-explaining that the ones at the top are enabled. (so we can banish this term completely from novices eyes)

Ok, can we get a test up on #73. If it fails, we can fix it - and get this in. I see this as a huge improvement, and we do not need to fix administration theme interaction in this patch. Its not very critical at all.

Is anyone working on this?

We have removed the text above the theme settings page. I think it's in strong need of a corresponding help page.

Changes like the ones suggested above could make this a different task.

Is this going forward, or has it been killed by time?

wow. we really could use this in D7. I'll try to take a look at fixing the patch in the next couple days.

Here's a straight re-roll of Gábor’s patch in #73. It no longer applied because of the theme function changes (hook_theme and single $variables param issues).

It still has the broken links as Gábor pointed out, so you can't enable/disable/configure themes with this patch applied. I just fixed the obvious broken bits of the patch and fixed up some CSS to match Gábor's screenshot.

Here's a screenshot.

Since new screenshots are such a PITA to set up, here's 5:3 ratio snapshots of all our core themes at 960px by 576px. I'm thinking 300x180 should be our new screenshot size, but haven't committed to a specific size yet.

Still working on an updated patch. I've fixed the broken admin theme form so far and am implementing the page callbacks for the enable/disable links along with new hook_themes_enabled() and hook_themes_disabled() which would be required to replace the hook_system_themes_form_alter() functionality we had prior to this patch.

Crappy, half-done patch. But shows the direction I'm headed. I'll keep at it.

I did clean up the CSS so that the form looks reasonable in Stark. Some of the previous CSS was moved to Seven's style.css.

Does it work

New patch which adds the form handling behind the enable/disable/default operation links. The links are now GET-style form submissions. Unfortunately, clicking the link displays the form and doesn't submit the form. :-\

Made operations links easier to alter and now only appear when theme is core-compatible. Fixed simpletests.

bot?

lol. Ok, testbot says its all green. yay! But the admin/appearance page doesn't have any working enable/disable/set default links. :-p

admin/appearance/enable?theme=stark displays the form specified at that path, but doesn't register that the form has been submitted.

In IRC, greggles pointed out that the "Add to default shortcuts" links are a similar idea. I'll have to sleep on that and try again tomorrow. (unless, someone else wants to jump on it.) :-D

BTW, the patch is about 80% done, I think. 10% work on the links. And needs 10% CSS love too. So if you guys want to start reviewing that now, that'd be awesome. Right now the images are overflowing the grid I had roughly setup for the page, because I added a border and padding around the images but the image widths by themselves take up the full grid width.

Lets bump this in the appropriate category for such a top-level change.

@JohnAlbin: Can you post a screen capture? :-)

Here's a screenshot.

(click above to zoom)

yoroy asked in IRC what it would look like if the disabled themes used a screenshot that was 50% of the enabled themes.

I whipped up a quick mock-up using CSS to resize the images.

(click above to zoom)

Here's a patch where the links actually work. Yay! In IRC, greggles pointed out that we are using a similar link-does-a-GET-submission for the "add to shortcuts" links.

Also here's a tarball of the new screenshots. They are 294px wide by 174px tall. The thinking behind the size is that a typical browser width is 960px wide (also used by several grid systems as the default width). We can create a grid to display the appearance page using 300px wide columns with 20px gutters and that will fit evenly into a 960 wide page. I was originally using a 300px x 180px screenshot (a 5:3 ratio), but some of the screenshots (seven notably) had indistinct edges so I put a 3px grey and white border around the screenshots and had to shave 6 pixels off the width and height so they would continue to fit in the grid. Thus, a 294x174 image with a 3px border becomes a 300px x 180px box that is easy to align in many possible admin themes.

One idea (not implemented) is to make themes give large-ish screenshots. Say 960px wide by 576px tall. And then we could use imagestyles to re-size them to the proper shape. That would allow alternative admin themes to use any image size they wanted.

Since the screen capture in #94 looks so much better then then one in #93, IMO, I used CSS to resize the disabled themes' screenshots to 50% of enabled theme screenshots.

-    $screenshot = $screenshot ? theme('image', array('path' => $screenshot, 'alt' => t('Screenshot for !theme theme', array('!theme' => $theme->info['name'])), 'title' => '', 'attributes' => array('class' => array('screenshot')), 'getsize' => FALSE)) : t('no screenshot');

...

+      $screenshot = $theme->screenshot ? theme('image', array('path' => $theme->screenshot, 'alt' => t('Screenshot for !theme theme', array('!theme' => $theme->info['name'])), 'title' => '', 'attributes' => array('class' => array('screenshot')), 'getsize' => FALSE)) : t('no screenshot');

this produces

<img src="http://example.com/themes/garland/minnelli/screenshot.png" alt="Screenshot for Minnelli theme" title="" class="screenshot" />

aren't empty title attributes only for decorative images?

Good catch, seutje! But it looks like that's a bug in theme_image(); there's no way to generate an img tag without a title attribute and using a title that is identical to the alt text isn't proper, imo.

#94 looks awesome. I really like the "integrate with imagestyles" idea to do this the correct way instead of css scaling.
It would also allow for funky carroussels to be developed in contrib I'd imagine, etc.

#94 is perfect.

I would propose to cmomit this as soon as we get a proper RTBC.

In follow up issues we could then:

- Integrate image styles for the thumbnails.
- Display the "Set default" link only for enabled themes.

Two concerns:

A) Shouldn't be Seven be rather not shown in the enabled themes section? It is an admin theme and not meant to be set as default. Couldn't you not show up there a theme that has been set as admin theme?

B) I guess we will not get in anymore the auto-enabling of all themes that get installed to get rid of the enigmatic "enable" link that misguides Users that I outlined in #68
Ah, fear this will be D8 stuff...

A) Will be D8 stuff.

B) D8 too.

Display the "Set default" link only for enabled themes - sounds like something we can do before RTBC

I haven't inspected this patch at all, but how I would expect it to work is it uses image styles for the two thumbnail sizes so that a themer only needs to put a single screenshot.png in their theme at whatever size and it will automatically get scaled and cropped to the proper dimensions. Is that indeed the case?

webchick: that's the idea yes, but not yet implemented as such in the latest patch.

A) Shouldn't be Seven be rather not shown in the enabled themes section? It is an admin theme and not meant to be set as default. Couldn't you not show up there a theme that has been set as admin theme?

Seven is enabled by the default profile (that's why it is displayed there in the screencaps.) If a theme is the admin theme and not enabled, it will appear in the "disabled themes" section with a "configure" link. That is consistent with how D6 works. :-\

Talked with JohnAlbin about what size the big original screenshot should be then. We'd strongly suggest aiming for a 960px width, because:

- It still fits the 1024 viewport (though we wouldn't use the original in this implementation)
- It's a common widht that lets itself chop up / resize well into smaller sizes. (see the many grid themes based on this width)
- It allows for 1:1 screenshots, removes 1 generation of image fuzzyness introduced by scaling
- I can think of all kinds of interesting uses for the big size image in the new d.o. themes section :)

As for aspect ratio, 16:9 is nicely panoramic, but 4:3 or thereabouts gives more height to actually show of the design elements/

Patch appears to apply fine, but then...

@eigentor, you need to go to "Configuration and modules" -> "Performance" and then clear all the caches. The patch changes several menu item/router definitions.

not exactly micro.

Can the images be converted to use Imagestyles? Then this is RTBC, be aware - it would be preferred these didn't show up in the imagestyle interface.

Worked a bit on the CSS:

The default theme should be the only big one, and highlighted a lot more. This gives some optical feedback to the user he has set his site's theme. Also the link to set a theme default (which is the only important one to a novice user) must be bigger than the enable / configure links.
It is not really possible to style the Set Default link directly, so styling the last link is a bit dirty, this needs a seperate class.

Did all this, rerolled patch. Image resizing only CSS since I don't know how to do the imagestyles.

Ok, so I think the design exploration that eigentor did in #111 is bad - it visually now sets 3 different styles and puts way to much emphasis on the default one, the mere indicator of (default theme) should be enough to prone the user. Also, setting one link to be bigger then another to me outlines a misunderstanding of prominence, making it bigger/bolder does not necessarily increase its prominence and if it does only by inconsistency.

@eigentor Honestly I am also getting a bit tired of this, we spoke about this and we discussed this numerous times already - we took a design direction and all we needed to implement that. You keep bringing in design explorations, even though we are past that phase already. I am sorry, but these improvements are simply not good - and with so few days left I want to avoid derailing this issue.

So lets continue with the patch in #96.

eigentor, this layout is taking it too far.

Consider seeing this within overlay context, the active theme is life-size visible in the background already. Maybe a background color for the active theme works, but I'd rather use the different sized thumbnails to differentiate between enabled and disabled then between the active one and the rest. Lets stop designing for now and instead focus on implementing #94 as the desired outcome.

it makes no sense to present a preview of the active theme larger than themes that aren't active

why would the user prefer a preview of something he can see in-action over something he hasn't seen in-action?

[edit] and this is what happens when u open a tab and forget about it for a couple of hours before posting anything [/edit]

OK, ok. wasn't aware you were iterating over the design.

My main concern is, that one thing still does not get clear intuitively for the user: which is my default theme. They might recognize it because it is at the top, and they might recognize it because they have seen it on their site.

Still what I would click intuitively was not "set default" but "enable". By making the default one bigger (even if it is not necessarily as big as I made it) it gets instantly clear if you clicked the wrong button.

But whatever, I don't wanna hold this up.

What we need is commit #96 without using image styles.

And later do two follow ups, in their own issues:

1. Integrate image styles for the thumbnails.
2. Display the "Set default" link only for enabled themes.

I will not RTBC #96 since I did not get time enough to review the code. Anyone up to the task?

I would agree with what xmacinfo proposes.

I just applied the #96 patch, and got errors. Basically the same experience reported in #107, only with a few differences in the details of the error message.

Plus, no themes show up at all.

ERRORS: (or see attached screenshot)

Notice: Undefined variable: output in theme() (line 909 of includes/theme.inc).
Notice: Undefined index: system_themes_form in drupal_retrieve_form() (line 510 of includes/form.inc).
Warning: call_user_func_array(): First argument is expected to be a valid callback, 'system_themes_form' was given in drupal_retrieve_form() (line 545 of includes/form.inc).

I didn't, btw, upload the package of images (since I'm not sure where they go), but from the errors listed, I don't think that makes a difference.

I should have read #108 and cleared my cache before posting my last #118 comment.

But clearing the cache didn't help. It actually took down the whole site.

On the page returned right after clearing the cache, I got this error message:

Notice: Undefined variable: output in theme() (line 909 of includes/theme.inc).
PDOException: SQLSTATE[HY000]: General error: 5 Out of memory (Needed 110784 bytes): SELECT data, created, headers, expire, serialized FROM {cache} WHERE cid = :cid; Array ( [:cid] => schema ) in cache_get() (line 46 of includes/cache.inc).

Then when I refreshed the theme page (which had been in a different tab) or go to the site home page (or presumably any other page), I got this error:

PDOException: SQLSTATE[HY000]: General error: 5 Out of memory (Needed 110784 bytes): SELECT data, created, headers, expire, serialized FROM {cache} WHERE cid = :cid; Array ( [:cid] => schema ) in cache_get() (line 46 of includes/cache.inc).

:(

always apply a patch before installing, as if you would of downloaded the package with the patch included

Compared to #96, this patch makes screenshots and operations links more alterable because they aren't rendered until the theme function.

Also, I had forgotten to style the "no screenshot" text properly. I changed "Configure" to "Settings" to match the text used by Jeff Noyes and Bojhan earlier in the issue.

Oh, and the patch in #121 also removes the "Set default" link from disabled themes, since xmacinfo suggested it and yoroy agreed. So you now have to enable a theme first, then set it to default.

Ok. So the docs for theme_image_style specifically say:

This function does not work with images outside the files directory nor with remotely hosted images.

So it doesn't work with screenshot.png files in themes directories. boo!

So, right now theme_image_style won't work on images outside the files/ directory. And any imagestyle that the system module creates (like 'screenshot_enabled' or 'screenshot_disabled') is going to be visible to site admins since there is no support for hidden, system-only imagestyles. *sigh*

Bah! Even worse. I just realized image.module is not a required module. So we can't require the Appearance page to use it. :-p

Okay, what about this backup plan:

1. Make all themes include a 294x219 screenshot.png. This is the size used by enabled themes.
2. For disabled themes, we can simply use some CSS to resize the "enabled screenshot" down to 194x144 (66% of the actual size).
3. Make all themes include a 960x720 screenshot-large.png and add a "Preview" link to all the non-default themes that will link directly to that image.
4. Optionally, for the preview link use JQuery UI to do a modal of the large screenshot. Like this: http://jqueryui.com/demos/dialog/#modal

Thoughts? Right now the patch in #121 already does 1 and 2 of that plan. I think I need to provide some updated images though.

+1 for preview image, this is neat.
Hopefully themers will implement that on drupal.org, too...

I like this a lot, but it still feels like the 'Administration theme' feature is bolted on. I like to believe if the administrator theme stuff can be better integrated. Thoughts from the UX camp?

If with bolted on you mean not integrated with the rest of theme selection, then yes. Remember that in D6 there's a seperate page for setting an admin theme, found in another top level section even (admin/build/themes vs. admin/settings/admin-theme), so at the very least it's bolted on in the right place now.

And this is by design. The idea is to not actively promote the 'admin theme' setting too much. We have Seven in core now as a dedicated admin theme, which fixes one of the main conceptual issues (front- vs. back-end confusion). We want to downplay the option to change it. It's possible, sure, but not necessarily recommended. That's why it's in it's own seperate fieldset at the bottom of the page. (There's still enough confusion to be had with 'enabled' / 'default' choices for regular themes. Integrating admin theme settings into that mix would complicate this even more, we explored these options in the original issue: #135976: Make picking administration theme more user-friendly )

Extremely minor re-roll of #121. Removed the unused style_name that was in the pre-rendered operations links. Also, fixed the empty title by duplicating the alt attribute (which is the best I can do, seutje). And moved theme group titles from theme_system_themes_page() to system_themes_page(), so that modules could add additional theme groups if they need to.

And here are the updated images needed. They are 294px wide by 219px tall. The thinking behind the size is that a typical browser width is 960px wide (also used by several grid systems as the default width). We can create a grid to display the appearance page using 300px wide columns with 20px gutters and that will fit evenly into a 960 wide page. I was originally using a 300px x 225px screenshot (a 4:3 ratio), but some of the screenshots (seven notably) had indistinct edges so I put a 3px grey and white border around the screenshots and had to shave 6 pixels off the width and height so they would continue to fit in the grid. Thus, a 294x219 image with a 3px border becomes a 300px x 225px box that is easy to align in many possible admin themes.

Here's an updated screen capture as well. Click the image to zoom.

So, using image styles here is basically impossilbe since image.module is optional. Adding a on:hover preview of the larger thumbnail for the disabled themes is only a nice to have and not feasible anymore given the timeframe. The approach for how we designed the admin theme function has been explained. A great looking page is the result.

RTBC

Agreed, lets get this sucker in - its such an important visual change to this screen. And takes away the checkbox vs radio mania that it is haunting now.

@yoroy right, downsizing via CSS is dirty but not soooo dirty, as the images are rather small

Newest generation of browsers do display downsized images quite correctly. Any new solution will need to wait for Drupal 8.

This new theme page is very nice and professional, specially with the grid layout. Congratulations!!!!!

Please let’s it make it in D7 before it’s too late! :-)

Committed to CVS HEAD. Yay! Great job all.

We need some documentation in the Drupal 7 theme guide (http://drupal.org/node/550722).

Specially the new size of “They are 294px wide by 219px tall.” theme thumbnails.

I'm leaving this fixed, though.

Docs for screenshot methodology are done: http://drupal.org/node/647754

The D6->D7 theme upgrade docs still need updating.

The new theme hooks hook_themes_enabled() and hook_themes_disabled also need to be documented in a *.api.php file somewhere, probably system.api.php. See #675046: Make sure all hooks in D7 have documentation.

I am working on these hook docs, which will go into modules/system/theme.api.php

Here's a patch for the missing hook docs.

Note that the theme update guide still needs to be updated (see #135), so if this is committed, please set status back to Needs Work.

No style issues.
Text looks good.

Committed to CVS HEAD. Thanks.

See comment #135 - I believe the theme guide still needs an addition.

changing tagging scheme for update guide

The main problem pointed out at #292253: Remove the per-user themes selection from core for the D6 theme admin page was, that it is not obvious what is the difference between "enabled" and "default", or what is the consequence of having a theme "enabled".

The new layout is nice, but I don't see how it solves this problem.
Maybe there have been user studies which prove that it does, but I don't see how.

I also miss an indication on the "default" theme that it is in fact chosen as the default. I see there is no "set default" and no "disable" link, but that might be misunderstood as "Garland cannot be disabled".
Again, I could be wrong.

What is the meaning of "enabling" a theme? one might ask.
- In D6, it meant that users can choose this theme in their user settings (with the respective permission). This was axed in D7, and will hopefully come back via contrib.
- Technically, D6 or D7 alike, it means that you can: edit theme settings, move blocks into theme regions, be notified about updates, etc. While, for all the disabled themes, this is not the case.
- A lot of modules might give the "enabled" setting additional meaning, by making it available for one or another thing to do with it.

Any chance we can make these things more obvious?

In the other issue it was argued that explanation text will not be read.
I have the idea this is caused by the tendency of usability books to boil everything down to a simplified statement.
The real question is, if someone is looking for information, where does this person look first?

I imagine some well-designed on-hover text here and there could do the trick, or be part of the solution. Not necessarily html title attribute (too slow, and no decent formatting options), rather some css magic.
At least I do read the on-hover text on unit build buttons in RTS games, that tell me "can shoot air. long range. can jump cliffs. cost 100 oil."

Any thoughts?

Another problem with the new design is that now you need one page request for each theme to enable and disable. And these requests are not the fastest.
I am yet undecided if this is really a problem. Probably not that much for sites with only few themes installed.

I also miss an indication on the "default" theme that it is in fact chosen as the default.

Um… you mean like ensuring the default theme is always the first theme listed in enabled themes and putting the theme name in bold and having bold text that says “default theme” right next to the name of the default theme? See the screenshot in comment #128.

Would it help if it blinked? ;-)

In core, the only reason we have enabled/disabled themes is explained in comment #59 above. If we used that explanation on the Appearance page, well… 97% of people wouldn't find that useful text. However, if contrib modules alter what "enabled" means, they are free to add text to the Appearance page that helps explain it.

OK, reviewing for update guides... It looks like from skimming the issue above, the only thing that needed to be documented in the Theme 6/7 update guide was the new size for the Appearance thumbnail.

Let's see...

1) http://drupal.org/node/647754 (creating a screen shot for appearance page)
already has the correct dimensions in it. I also made sure the d6 page for that linked to the d7 page (it didn't before). It looks like that's the main page on d.o docs about making screen shots for themes (the page with the theme file overview http://drupal.org/node/171194 links there), so I think we're OK as far as the theming guide goes.

2) The 6/7 update guide... I added this as
http://drupal.org/update/themes/6/7#thumbnail

I think this issue is now fixed.