The next logical step after enabling a theme is to manage / administer the blocks for that theme. This patch adds a "Manage blocks" link right next to the theme settings. This is an effort to make Drupal more usable.

Finding modules, creating and placing blocks, and creating content types were difficult tasks for participants to understand...

See : http://drupal.org/node/1175694

Comments

shadcn’s picture

StatusFileSize
new863 bytes

Patch attached.

Screenshot : http://screencast.com/t/OlFAmFwnr

shadcn’s picture

Status: Active » Needs review
dcrocks’s picture

The patch tested fine on 7.x dev dated 6/9. It makes sense and should be back ported to drupal ver 7. It also eliminates the occasional confusion when the structure/blocks page doesn't open up to the theme the user expects. The term 'manage blocks' might better be 'review/manage block settings', but that is just my take.

webchick’s picture

This actually seems like a great idea to me. The patch as-is would have problems being committed to D7 because it would change strings, though.

Tagging for usability team review.

dcrocks’s picture

Here is a screen shot.

yoroy’s picture

This is that screenshot:

It inserts a 'Manage blocks' link in the list of links that are shown for an enabled theme, so:
Settings, Disable, Set default
becomes:
Settings, Manage blocks, Disable, Set default

This is one of the examples where we have to make it easier to discover related admin pages. Something we should definately work on, so I think the idea is good but not sure on the execution yet. Is this the best place to put it? Seems like a bit of a mixed bag to put something that takes you to another admin page in between other links that keep you within the Appearance section.

Jeff Burnz’s picture

StatusFileSize
new103.98 KB

Seems like the wrong place for this link - I like the idea of making things more discoverable but having this link right there on the appearance page seems out of place - maybe it would be better to have it on the actual Settings page for the theme, perhaps as part of a group of "suggested links".

Anyone using Windows? Ha, thought not, however when you fire up the Control Panel you get "See also" hints everywhere you go, examine this screenshot:

win7-hints.png

What if we were to do something like this, I know we have help system that includes links, but something more ubiquitous, that is perhaps part of the help system (so you can turn it off), maybe its called "Hints" and you can disable hinting.

shadcn’s picture

We can think of these links as the ones on the modules page. Modules have config and permissions. We have "configure" and "permissions" link for each module. Themes have "settings" and works with blocks (regions). We have settings link but we need a way to link to the block "settings" for the theme.

This connects "closely" related administration pages.

dcrocks’s picture

The nice thing about the current patch is that when you get to the blocks page the theme you selected for is the active theme, rather than the default theme, which is the normal result when choosing blocks. One click instead of 2. If you had a generic 'action' menu, it would have to take you to the default theme. What else would you put on this 'action' list: 'add content', 'menus'?
You would have to make sure the 'action' list was always viewable, not something scrolled off page. A tab might work but I don't think it would be very intuitive. Of course you could have an 'action' selector associated with each theme on the page(a drop down?).
Right now the 'disable' and 'make default' choices return to the same page after being clicked. 'settings' does not but allows you to return via either a breadcrumb trail or tabs. 'manage blocks' doesn't, which I think is the only real UI issue with this patch. But it would be helpful to indicate some way that 'settings' and 'manage blocks' are links while 'disable' and 'make default' are switches.

Jeff Burnz’s picture

I think you are not seeing what is fundamentally wrong with this - look more closely at the UI this creates, now remove everything you know about Drupal and look again - and tell me what you think blocks are.

The patch makes the massive assumption that The next logical step after enabling a theme is to manage / administer the blocks for that theme. No actually, I would think the next "logical step" after enabling a theme is to configure the themes settings. Placing this "Blocks" link will force the user to think about what blocks are and if they should click this or not. It will make them have to think - the first violation of usability.

The link may afford discovery, but it may just as well confuse the hell out users also.

dcrocks’s picture

You're right, the term 'blocks', as has been pointed out many places recently, isn't very intuitive. But that only means there is a problem with terminology, not the concept of implementing a workflow link on this page. I actually expect the user to be thinking when they are engaged in this workflow and I would expect to be reminded that configuring/setting up a drupal site has multiple steps. This is not a page for site visitors.
Perhaps the usability problems with drupal is because of too much compartmentalization and no obvious visual workflow. Site builders create the visual flow for site visitors but drupal should be creating the visual flow for site builders.

ps. If we don't want any thinking to occur then it should be 'theme settings' instead of a generic 'settings' link, no matter that it is redundant, just to make it clear.

Jeff Burnz’s picture

Its not about the terminology, is about proximity and constraint. I don't think anyone is disagreeing that things like this could be useful, rather the implementation and placement is at issue.

We already know that users think blocks are content, by creating a proximal relation between "theme" and "blocks" you conjure a different mental model of what blocks are, how they fit into the overall users schema - making them part of the theme configuration runs against the grain of that mental model.

The appearance page already has issues of its own, and when you really break down the appearance page there is a lot going on there - there are many decisions that need to be made. In fact there is really too much going on (admin theme settings should be moved elsewhere) and the page simplified - adding a single link to blocks increases the complexity of the page - in other words we loose a logical constraint (deal with themes, and themes only).

In my redesign of the Appearance page I changed "Settings" to "Configure", which makes more sense: http://drupal.org/node/1167444#comment-4558278

shadcn’s picture

I too agree with the terminology behind "blocks" and the wording "Manage blocks". I mean we can find better ways to put that.

But, I think that there are two ways of looking at this. One is that "blocks" are tightly related to themes, Two, they are not. IMHO, they are.

When you install a new theme, you want to configure settings, yes AND you want to configure your blocks for the theme. A new theme needs configuration, so you have a way to get to that from the themes page. But a new theme introduces new regions that break your whole layout, and you want to be able to go to the block page and set the blocks for the theme. This one link solves the problems of finding where blocks admin are and make sure you're on the right theme.

It works the same way permissions does for modules. Permissions have their own administration page. But because they are closely linked to modules, Drupal 7 has the "permissions" link on the module page (Note that there's no way to get back to the modules page from the permissions page). It adds some thinking yes (what are permissions?) but does make the whole workflow better.

My two cents. :)

Jeff Burnz’s picture

It would be very nice if one of you could actually counter or reply to my arguments. I am being polite enough to entertain yours. Please do the same and not just attempt to re-frame the issue around some arbitrary notions of what relates to what.

As stated above, twice already I believe, NO ONE is arguing the point that configuring blocks relates to setting up the theme - what is being discussed as a concern is the implementation.

I would also say that your argument above only rings true for experienced users, those that know what blocks are, that a theme might add new regions and that they might break the block configuration. Power users know this stuff - they also know how to navigate to the block configuration, and probably how to set a shortcut if they need a quick link.

I think what you guys are not doing is walking in the shoes of the absolute newbie - this person has no idea what a block is, or what a region is, or that the layout might break therefore they should rush off to the blocks page as soon as they enable a theme - this patch adds a "manage blocks" link for themes that are not even the default theme, which don't even show on the front end. Remember, no theme key stuff going on just yet - we're talking about newbies here.

What I alluded to above makes a lot more sense, to gently "suggest things" provides affordance and discovery, but does not enforce decision making - which is what this patch does.

dcrocks’s picture

I thought this issue was about improving the usability of this particular administrative page by adding what seems, to some, a natural link. That should be able to be done alongside the other issues proposing changes to the appearance page. This change does not preclude other proposed changes. I personally like the changes proposed in http://drupal.org/node/1167444#comment-4558278. But I still think this change will help many, even if it needs improvement, and it shouldn't create too many problems for the completely ignorant, who, I would hope, would be following some script that led them exactly and only to just the steps they needed to follow.
So, to a core issue, I personally would have liked something here when I began with drupal(and no, I had no specific CMS experience) to help on the path to completing an install, even if it meant fumbling around with new terms whose purpose I didn't immediately recognize. I would rather have been led down an unexpected path than no path at all. That I consider part of learning; even after all these years, I tend to RTFM last.
If drupal is being aimed at the gadzillion Wordpress users, then it is much more in need of a crazy good help system than a super simple admin system. (And so is Wordpress).

yoroy’s picture

Issue tags: -Needs usability review

Good example of connecting the dots between related screens. We're looking for a general pattern for showing these 'related topics' links. In that regard, Jeff's screenshot in #7 looks more like the direction we want to pursue.

Other possible examples:

- link to 'content types' on the content creation listing screen (node/add)
- link to 'manage blocks' on the menus listing page

Would be good to see some simple sketches here. What if we had a right sidebar on admin pages for example :)

shadcn’s picture

Just logging some links that might be useful later

http://drupal.org/node/1340452

thedavidmeister’s picture

Status: Needs review » Needs work

Two things.

1. Patch no longer applies.

error: modules/system/system.admin.inc: No such file or directory

2. @Jeff Burnz has pointed out a few reasons this patch, while possibly going generally in the right direction, does need to be thought out more thoroughly in terms of link placement.

lauriii’s picture

Issue summary: View changes
Issue tags: +Needs usability review

It would nice to get some feedback from the UX people if this is still relevant

Bojhan’s picture

Status: Needs work » Closed (won't fix)

Not really, for sure not this fix.