Reconsider whether "Appearance" should be a top-level item in the IA

I can only say, yes, that's indeed as intended.

Some context: it's true that this is not really a 'heavy usage' page in administration. But it IS a very important feature new evaluators look for to get an idea of the possibilities and ease of changing a site's look and feel. For that, it *does* deserve this top level place in the IA.

UX-wise rtbc.

No brainer... Code looks simple and solid..
Things work as expected...

RTBC

Alrighty! Committed to CVS HEAD. Thanks.

If we don't ship more than:

Garland (on by default)
Stark (which is never supposed to be used)
Seven (an admin theme, also on by default)

with Drupal 7, I think we should revert this. I disagree with this one in general because even on a brand new site you visit it once or twice then forget about it, and it's not exactly hard to find in /config, but with only one viable front-end theme in core it's going to be embarassing. If anything, replace with a link to plugin manager so people can download new themes once they install.

So tagging with 'revisit before release'. Obviously I'd love to see us get more front-facing themes into core before 7.0, but no sign of those anywhere at the moment and time is short.

Re-opening this, see discussion from http://drupal.org/node/699848#comment-2806812 downwards. We should move 'Appearance' to a section on admin/config

It is a bit late to do this honestly - wish you would have shared the importance of this concern earlier, apart from you not agreeing with the ideological choice is there a real usability issue occurring?

I shared it August 1st 2009, which was some time ago. I also said the same thing in a tonne of other places at the time, but no-one listened. See Jacine's post on the other thread for why it's a usability issue - can't find Skinr module.

I think it is good in some ways to promote "Appearance" since this is something that many new users will want to get to directly. But if it causes issues with the /admin/* IA, then that's a big problem.

I haven't reviewed this issue yet in detail; I just wanted to subscribe to come back to it later.

The usability issue is that modules that are appearance related (and live under /admin/appearance) can only be found if they insert themselves as tabs on /admin/appearance/x. There is no "task" listing for them on /admin/config.

Originally I thought that the links would be available on /admin/by-module, and even though that is far from ideal, at least it was something. However, they do not show up there either. The only link that ends up there is "configure permissions."

I agree that it's late, but I've been confused about which is supposed to be the correct listing here for a while #699848: admin/by-task is confusing since it lacks links to config pages and looks similar to admin/config and friends. I assumed that the appearance listing not showing up under /admin/config was a bug because it does exist under /admin/by-task at the moment, but just learned that is not the case and that this listing is about to go away.

It seems wrong to misclassify the module or make a new group to make it show up on admin/config because it is appearance related, but if this isn't addressed we wont have much of a choice.

What module are we talking about here? And why wouldn't it be able to list itself under Apperance if its considered a theme specific setting?

I agree with catch on both points, and I think I equally stated them elsewhere already:

1. In D7, "Appearance" still is a one-shot, one-time, and never-ever-again item. Unlike Modules and everything else, you do not change your theme. You configure your theme. Most often just once, similar to module settings. It therefore belongs into Configuration.
2. Finding a good home for Skinr is tough. Contrary to 1), I'd more often want to visit and revisit Skinr's pages during site building and potentially also afterwards. Therefore, rather belongs into Structure for me.

Skinr is tough yeah.

In day to day use it wants to use contextual links as much as possible, that's pretty clear.

Appearance is not as dumb as you portray it. Theming/styling/designing has always had it's own administrative hub in core. Besides Skinr, Jacine and I tried to find 'appearance' related modules that would make the case for an 'Appearance-related' category on the Configuration page.
Quick scan found us hardly one more.

My point: What's currently happening in Skinr is what you'd like to do on the next-gen Appearance page. Skinr should try and blend in and extend the Appearance hub itself. It's not bones (structure), it's skin (appearance). So to me the existence of Skinr itself doesn't show we need an 'appearance' config category, but proves that yes, we need an Appearance page and that's the stuff you will find there. Skinr is to Appearance as Panels is to Blocks etc.

If there's a general bug in config-links not finding a page to live on, then I'd like to see that explanation help #699848: admin/by-task is confusing since it lacks links to config pages and looks similar to admin/config and friends get focussed again. Deferring the Skinr discussion to #620326: A better UI for Skinr in the Skinr queue and report back when we have something.

Open this again with more examples of appearance-config contrib modules if they are out there. Untill then, it's 'by design'. :)

Thanks for checking it out and giving your feedback @yoroy! Appearance would have been a nice place for it, but the way D7 is now, it just wont work so I think Skinr is going to end up having its own group.

BTW, we should defer to #755614: Ensure Skinr's admin UI is easily accessible to users for the Skinr discussion (for anyone interested). That other issue is a different UI problem (skin selection) :P

We "solved" 2) if Jacine is happy with that conclusion.

But 1), the original change request of this issue, still needs further discussion and reconsideration. It's nice that we "want to promote" themes, but the idea to move Appearance to the top-level is contradictory to everything I've ever heard from the UX team. Yes, I'm listening to you, guys. This patch was committed a long time ago, way before we reached the conclusion that we designed for the wrong audience.

I'm not arguing here for Skinr, we'll figure that out, but for the record I agree with sun and catch on #1. Even if we had 20 awesome themes in core, I still don't think this deserves top level placement and such valuable real estate in the toolbar.

My 2 cents.

Yeah this was put in the top level IA with only three posts of discussion, I wish I could find the quote from Leisa but pretty sure it was in an irc conversation, however IMO it's only there for political reasons, not usability ones. Also if it moved to a category on admin/config it'd then create an appearance category for Skinr and others to go into.

So, I agree with @sun and @catch on the fact that from a purely usability perspective this doesn't make sense. However leisa's reason for this where I think connected with the idea of greatly enhancing the Appearance page, it might make sense to contact her to give some feedback on this issue.

Also we shouldn't just deny this concept for the sake of it - because the idealogical argument is actually there, its not a guess for that also see yoroy's explanation in #1. I will contact leisa.

Patch moves themes into User interface.

@catch: I think that this makes sense. If people really wanted themes in the toolbar, they could just create a shortcut for it.

Possibly it could even be one of the default shortcuts (but that would be a followup issue :) ).

All I have done (so far, at least) is looked at the screenshot. Have not reviewed the patch.

@catch: I think that this makes sense. If people really wanted themes in the toolbar, they could just create a shortcut for it.

Possibly it could even be one of the default shortcuts (but that would be a followup issue :) ).

Screenshot looks good, and patch looks clean in Dreditor (to me, at least - I don't know coding standards all that well yet). Have not tested.

@Evan Donovan: If we are taking "Themes" out of the toolbar only to stick in the Shortcuts, we might as well leave it where it is.

Actually, that shortcut proposal makes a lot of sense -- shortcut links are practically the ideal place for "beginner" stuff like this, since shortcuts can be changed quickly and easily, and installation profiles can (and should) prepopulate them.

I'd be fine with the shortcut iink too, and disagree it'd be the same as leaving it where it is - shortcuts are a lot more optional/configurable than the overall IA - and the shortcut can link directly to themes, while in config it can live with other interface features. It'd also cover the "promoting to new users" thing just as well as having it top-level.

I don't really buy into the logic going on here. Since I started with Drupal, I've probably clicked reports maybe a handful of times - not nearly as many times as I've clicked on appearance. I'm just not that kind of user. So should we also move reports? Many users will set up their modules once and never come back. Should we find a new location for modules too?

I also think the data we have on traffic to Appearance is old and changing rapidly. DrupalGardens is shooting to build a theme marketplace, which will drive TONS of traffic to the Appearance tab. Additionally, the workflow we're basing these decisions on is old. In the past, users selected a theme and walked away. Whereas today, users are designing their own themes and therefor coming back to this area regularly.

Dunno, I think you're looking for solutions where a problem doesn't exist.

I agree with @sun and @catch on the fact that from a purely usability perspective this doesn't make sense

Please don't confuse this with usability with consistency. There may be a usability issue finding skinnr (sounds like that's solved), but there is not a usability issue with Appearance being in the top level. Inconsistency maybe, but inconsistent doesn't equal unusable. I've done user testing on selecting themes, and not a single person had issues selecting and applying a theme. In fact, it had a 100% success rate - which suggests its location is anything but a usability problem.

Part of the reason why Appearance was put in the main navigation is because changing the theme is one of the first things people wanted to do. I believe for the same reason, 'Modules' was move from Configuration to its own tab.

@sun: Glad you like my idea. As someone who can see why it was moved to the top level, but who also doesn't like what it does to the admin dashboard IA to have it that way, I think that catch's proposal + adding a shortcut would provide the best of both worlds.

Modules I can see why that should stay at the top.

@Noyz:

I've done user testing on selecting themes, and not a single person had issues selecting and applying a theme. In fact, it had a 100% success rate - which suggests its location is anything but a usability problem.

I've done those usability tests too, on Drupal 6, and Drupal 7 before this change was made, and it was no problem there either. A better test would be to give users another task, such as changing their site name or removing a block, and seeing if they wrongly end up in Appearance then have to back out again to config or structure.

Either way, as mentioned already, the issue is whether such an infrequently visited link deserves the screen real estate, it has no usability affect on appearance findability where it shows up (between the two choices, based on prior testing), it does have an effect on what else will fit in that toolbar and where focus goes.

Also, what people do in Drupal Gardens really shouldn't have any bearing on what Drupal core ships with out of the box, those are two completely different workflows, and nothing stops Drupal Gardens putting this link wherever it likes. Perhaps when the theme builder is GPL and in core that argument might hold a bit more weight, at the moment, even if Bartik and Corolla get into core, you're still looking at a choice of at most three viable themes on that page, and no 'theme building' takes place under that tab that I know of.

So should we also move reports?

It's my impression that was going to become a tab on the dashboard, or merged with the dashboard via blocks if at all possible and then any leftovers moved to admin/config, but no-one did the work to make that doable. But yes of course the same argument applies. The difference with Reports is that it's a flexible category that contrib modules can add their stuff too, whereas the Appearance page isnt extendable unless you take it over completely or do all the work in tabs.

@Dries:
Modules was moved to a top level link because no one could find it hidden as a tab on admin/config, see #580868: D7UX: The Modules page needs to be easier to find.

First time visitor wanting to change their theme is handled by the shortcut if we add it, I don't think the entire IA should be geared to the first ten minutes of installing Drupal (even the most flummoxed usability testing attendees more or less found their way around after 30 minutes or so), I'm fine with the default shortcuts, which are equally prominent, being geared to those first ten minutes though.

Part of the reason why Appearance was put in the main navigation is because changing the theme is one of the first things people wanted to do.

That sounds like an argument for putting it in the shortcut bar, not the main navigation. The main navigation is about conceptual organization, while the shortcut bar is about convenience. (But any patch for the shortcut bar should maybe wait for Bartik/Corolla/etc, unless we are very excited about giving people the option to conveniently switch to Stark :)

Another good thing about this patch is that the main navigation is getting very crowded - especially when the bug gets fixed that currently prevents the Dashboard link from appearing there. Taking something out would definitely be nice.

At the same time, I don't think @Noyz is wrong about Reports at all. It's true that it maybe could have gone on the dashboard, but if the dashboard is disabled, it still would have had to go somewhere else - the main point is that it is in the top level now not because of how often it's clicked, but rather because it doesn't belong under Configuration or any other top-level category. (IMO this is a phenomenon that will be definitely be repeated with contrib modules - see also #759824: "Configuration" IA category has some stuff in it that has nothing to do with configuration.) Whether or not themes belong under Configuration should similarly be based on whether or not people think of changing their theme as "configuration".

It would really be great to solve this through actual usability testing - that's what the goal has always been, right? @catch, what you're saying about the Drupal 6 and early Drupal 7 tests is very encouraging, but in those cases it lived under Site building (or maybe Structure, at one point in Drupal 7). This is a bit different, since here it would move to Configuration. I think if we saw that people did not have much trouble thinking to look for it under Configuration, this patch would be a no-brainer. (And even if we didn't see that, it might still not be an argument against this patch so much as an argument that "Configuration" is misnamed.)

My 2bits are:

Everyone has a good point. @catch, absolutely right has nothing to do w/ Gardens, I think @Noyz was just giving a perspective based on our wealth of experience w/ users of D7.

I think the real problem is what David is talking about though. It's not so much that someone would not to think to click config if they want to add a theme, it's that they wouldn't be able to find a link on that page because it is really really crowded, will only get worse with contrib modules and has no icons to guide people.

I had an idea once which was really simple and spun into a bizarre scope creep and then when the patch was all good, to a won't fix... I don't remember the deets too well it was over a year ago, but anyway if anyone is interested.

#407022: Show help and configuration links when modules are enabled.

The bigtime idea is a "todo list" of sorts that modules can expose when enabled. This is a common interface pattern, something like "You haven't selected a theme yet! (do it) (don't show me this again)"... List these somewhere for admins (in a block most likely) and get them used to this pattern. Would help massively to reduce support requests for contrib modules too which need config and people can't find / don't bother to find. AND, allows you to bury things a little bit because once people have been to the page once, it's usually not as hard to get back. That being said, very unlikely (not) going to happen in D7 right now, but something to think about if we want to change this for D8.

For David's point, I don't see how that's not answered by adding a shortcut in the default profile, which was attached firmly to David's point too - it's equally prominent for new users, assuming we do get Bartik and/or Corolla in then you'll be able to do something useful there. I'm fine with making that assumption and including the shortcut link here fwiw.

On 'Configuration' in general, there are two broad meanings to configuration - one is 'settings', and one is 'configuring' - all site building tasks are 'configuring' at some level - configuring a view, configuring a content type etc. It's a bit of a stretch, but until someone comes up with a better word, the semi-mis-labeling of that section shouldn't be an argument against its actual purpose.

I'm personally not a fan of the shortcut solution. Shortcuts are basically just bookmarks - which can be created/managed just as easily through the browser (maybe even easier). And, bookmarks don't take away precious screen real-estate. Anyway, my point is not to digress into the shortcut solution, just to try to avoid it as a long term solution because I know eventually we can arrive at a better solution.

While I appreciate exploring the location of reports, what about modules? It too shares the same problem for many. I.e., once a sites functionality is established, many users will rarely return to modules (for right or wrong). To be clear, I'm just making a point here. I don't think modules should move, nor do I think appearance should move. I think there's validity to the problem where users may accidentally stumble into appearance for the wrong reasons, but moving to shortcuts feels wrong for the long term, and burying in site config feels equally wrong and fails at helping the users that change their appearance as their very first task. I'm certain a better solution exists, but we're talking about migrating the navigation bar into a "common task versus less common task" structure - which in my mind is potentially a complete overhaul. Are we really prepared for this at this stage in the game?

I did a mini usability test of this patch with my fiancée last night. She is not experienced with Drupal, but has seen it a couple times (and does have very basic knowledge of what a "theme" is).

I gave her a fresh installation of Drupal with this patch applied and said the following:

"Suppose you want to change the way this website looks - for example, the color. Show me where you would go to do that."

Interestingly (and partially off-topic for this issue) at first she didn't notice the toolbar at all, but went straight for the Management menu. Since the only choices there were "Add new content" and "Dashboard", she clicked on "Dashboard" and proceeded to get pretty lost in the dashboard configuration screen. Interesting result, although we have other (in some cases critical) issues about fixing the structure of that menu and perhaps not even displaying it all when the toolbar is enabled... However, it did make me wonder a bit if the Dashboard link had been in the toolbar, whether that would have been a distraction there as well. If testing this with someone else, I'd recommend applying one of the patches that fixes the Dashboard-in-the-toolbar issue, to get a better test.

In any case, once I directed her attention to the toolbar, she went straight for "Configuration" without any hesitation. She then scrolled down a bit and found the "Themes" link pretty quickly. She told me that she knew then she planned on clicking on it, although before actually doing so she did scroll down the rest of the Configuration page just to see what else was there. So once she found the toolbar, she had no problems at all.

It occurred to me that for someone who doesn't know what a "theme" is, that link might not be as obvious. As part of this patch, I think we should change the description of the menu item - currently it just says "Select and configure your themes" (which doesn't mean much and doesn't even have a period at the end; it appears to have been optimized for use as a tooltip rather than a regular menu description). Probably the description should find a way to get the phrase "your site's appearance" in there.

Where do I go to give general feedback on the d7 look and feel, I am new but want to share my thoughts and fears.. but its hard to find where to go to give feedback just keep landing on issue pages but don't want to hi-jack or mess with peoples flow.
thanks...

theGoose: that's a very legitimate question. Maybe try a post in http://groups.drupal.org/usability and we can take it from there.

thanks yoroy, I'll try to get involved instead of complaining about the work I'm not doing.

Related: #567418: Move blocks page into appearance

Adding tag - this could use more testing.

Removing tag, this was supposed to be revisited before the 7.0 release.

With the redesigned toolbar, the argument that Appearance is "taking up valuable top-level IA space" is less convincing since the default orientation of the toolbar is a vertical list of items.

I'd also like to chime in and say that I'm in favor of the idealogical reason for why Appearance should be a top-level IA item, as Yoroy described in comment #1.

I'm not seeing a lot of fruitful discussion here recently; setting to closed (works as designed).

The default orientation of the toolbar is actually horizontal, not vertical. (You might have a preference for vertical stored in your browser from a previous install.)

Also, doesn't the proposal to put the Appearance link in the shortcuts at least partially address the ideological concerns? (We have "Add content" in the shortcuts, and that's pretty important to Drupal too :) The shortcuts are a little hidden in D8 right now, although there's an open issue at #1852346: [discussion, no patch] Toolbar UI regression: shortcuts and menu not visible at same time to address that.

The one new problem that has come up with this issue in the interim, though, is that although we had a pretty good idea people were able to find Appearance under Configuration before, we now have a new top level menu item called "Extend". I can definitely imagine people looking for Appearance under there...

Also, I'm not sure the "taking up valuable top-level IA space" argument is really about physical space? I think it's more about "mental space". The more items up there, the more people have to think.

For example, I'm definitely curious if a lot of people wind up stumbling into Appearance when they are trying to do things like change their page layout... Apparently, even Drupal experts like @yoroy sometimes do this :)

Better title.

For example, I'm definitely curious if a lot of people wind up stumbling into Appearance when they are trying to do things like change their page layout...

Usability testing says the answer is that they do: #2513556: Add a link to the Block Layout page on the Appearance page

Actually, thats a bit misleading - people clicked all around the place. But appearance the most. If you remove it, all you can do next to fix the problem is remove the 2nd most clicked item. I would not say that the findings really support removal of this item.

Do you happen to know what the second most-clicked item was?

There are only so many choices, and one of them ("Structure") is correct. So I would hope removing the most popular wrong choice would be pretty helpful even if it's not a complete solution.

I don't really understand why this issue is still open. Or, rather, I get the argument that theme settings are something revisited rarely (though the counter-point about Reports being visited rarely is also true). However, according to various comments by @Noyz and others, this was already usability tested and didn't present any problems. The one counter-positive usability test from David about putting it under Configuration instead is from someone who already knows the keyword "Themes" to look for. The visual hierarchy on Config is utterly absent, so I would need a ton of convincing that without having a pre-existing idea of what keyword to scan for, we would have nearly as positive results with the task of enabling and configuring a theme.

Drupal 7 has also now been out for 4+ years and no one new has piped up saying "Grrr, man, that Appearance menu has got to go!" So if real world users are getting perturbed about it, they're at least not getting perturbed enough so that they're posting issues/comments about it. So IMO, we can close this.

However, to answer David's question, consulting the spreadsheet of DOOOOM (scan for task 7... we're working on extracting the videos from WebEx as we speak):

- Participant 1 started at appearance
- Participant 2 went to structure > block layout (but note this person was also very comfortable with Drupal 7)
- Participant 3 went to structure > content types
- Participant 4 went to add the block via contextual links on the front end and ended up in Views UI (OH NO GOD NO)
- Participant 5 also initially tried to add the block via contextual links on the front end, but then ended up on Structure > Block layout to "abstractly add a block"
- Participant 7 (there was no participant 6) also tried to use contextual links on front end, then goes to Structure > Block layout
- Participant 8 went to Configuration first.

Or, in other words, "it's a toss-up." :)

As far as people looking for blocks under Appearance, though, IMO that's completely logical. Block placement is exactly tied to how your site looks. I could see us solving this the other way, by putting the block placement page under Appearance, rather than Structure. Block placement is closely coupled to themes, anyway. (This would obviously need a larger discussion and would probably be 9.x, not 8.x at this point.)

Oh, and so we don't get all happy about the fact that half the participants navigated to the right spot to place blocks, bear in mind that a) there were several among the participants with previous D7 experience, and b) many of them had already taken a complete tour around the admin panel looking for something else by the time they got to this task, so they could have recalled it from earlier.

Sorry. ;(

It'd be a mistake to move this. While it may not be used much, it's one of the first things people do when they try Drupal.

Blocks in general are confusing. Arguably they're about layout, and layout is about appearance. If anything, Drupal would be better served by moving blocks under appearance, and listing theme settings under a label of 'theme settings' or 'look and feel' or 'brand and design'. I'm no necessarily suggesting you do this, but doing so would be a better move than eliminating 'appearance' as a top level item.

@webchick, I read back to my original comment in #4 from six years ago. The argument was not that the page is rarely visited (although it is), it was that presenting it as an up-front choice when we only ship with one viable front end theme and one viable admin theme in core means there is very little for a brand new Drupal user to do when they get there. While Garland has now been replaced with Bartik, the overall count has not changed - this is still a sparse choice for something with that much prominence.

Adding blocks to the page would mean there's something to do there though, so would help to resolve that original concern.