Moving URL Aliases out of Site configuration

This works for me, with pathauto, I almost never go to this page, and when I do, it's to change pathauto settings (which adds itself as a tab).

RTBC once the test bot goes green.

I'm not a pathauto user, but it still make sense to me, as I control the URLs from within the node creation form.

Hm. I committed this. A couple of things:

1. This change shifts the paradigm from "everything under configuration is stuff you do once at most and basically never touch again" to "pages that you will probably not be able to configure once, but rather will need to revisit from time to time." More things than just nodes get paths, and editing a path is not that uncommon of an occurrence - probably once a month or so.
2. The screen this goes to is a content listing. It's not content listing that end-users or "editors" will ever be exposed to, to be sure, but you edit it, add it, delete it same as you do taxonomy terms, aggregator feeds, etc.
3. URLs are the very fundamental essence of "Structure," which is what we ultimately want to rename "Site building."

This might be something we want to revisit prior to shipping D7 once more of the underlying IA is in place.

Yeah I'm not convinced on this. For instance I list the path_redirect listing under admin/build/url-redirects since that's something that users occasionally check. It's not a one-time configuration. It feels right to have it listed with URL aliases there. It wouldn't feel right to have URL redirects listed under admin/settings.

FWIW, Pathauto used to be at admin/settings/pathauto and was moved to admin/build/path/pathauto after outcry from users and a "usability review" + patch by Gabor/Acquia.

The pathauto page is a mix of settings (patterns) and "building" (deleting and bulk generating). I agreed to put it there because that put all the path stuff in one place and was consistent with the way that settings are grouped, like how some node "settings" are in content simply because nodes are content.

There have been many complaints about moving pathauto from admin/settings/pathauto to admin/build/path/pathauto but I think that is mostly because 1) people hate change 2) menu local tasks don't show up at admin/by-module so it wasn't listed there 3) people hate change.

In my opinion, the path page as we have it is a build item. I believe this is validated by the card-sorting that Civicspace did when we first split up the admin menu that put them there.

Yes, we want to give a chance for the work Mark and Leisa and the UX team did to come together as a whole before we start mercilessly picking it apart again. I'm not necessarily opposed to moving it back to where it was, but I'd rather not do so before we have the entire picture in front of us. Moving where menu items go is definitely an "OK post-code-freeze" task, but adding the admin header is not. And without an underlying IA restructure, we can't really gauge the effectiveness of the admin header unless all the underlying bits are in place.

Oh yes I agree, let's just make sure to re-evaluate once there is a more complete UX and IA picture in place.

Yes, we want to give a chance for the work Mark and Leisa and the UX team did to come together as a whole before we start mercilessly picking it apart again.

So, this change was based on their work?

If there was some research behind this move then sure, let's do it. The original post and subsequent comments just state opinions rather than providing justification - hence my questioning of the logic and attempt to cite the original motivation for putting it where it is.

It would be nice to get pointers to research/justification as these issues are created/committed.

@greggles: Here's a video that helps explain the rationale/justification for the IA changes, and helps give an idea where we're tryng to head: http://www.yoroy.com/2009/reorganize-drupal-admin-items-within-d7ux-fram...

While this doesn't show users banging their faces against the keyboard in confusion with the current nav, it does present a sound justification for heading in the current direction.

Hopefully this'll end up on D7UX.org shortly, since I'm not sure how many people subscribe to the planet, and I know a lot of people are kind of in the dark atm about what happened at the sprint this weekend.

Thank you for not fixing any of the paths in path.admin.inc. :P

@Bojhan: Just giving you a hard time. :) Care to mark as RTBC so HEAD isn't broken? :)

That's all the references to admin/build/path that grep could find ;)

OK, let's give this a try (and re-evaluate as necessary). Committed.

You don't build modules or themes in admin/build either. It's the site what you are building. I still see path management more related to site building that configuration.

This debate does on and on while we categorize IA items. There are two "paths" (pun intended):

(1) move back URL aliases to structure (on the grounds that it is used more often then other settings under Configuration and modules)
(2) move URL aliases to "Search and metadata" where pathauto is supposed to be placed and other path related items like Clean URLs are placed and most probably path redirect will be placed; this categorization covers SEO related modules

We need to move URL aliases since "Site configuration" is a ghost container which is being emptied in favor of actual places in the D7UX IA.

The attached patch implements (2).

This is how it stacks up with mates in the same category:

BTW the parent issue for meta-discussions was/is #546956: [meta-issue] Overhaul of Information Architecture.

Subscribe. Solution in #26 makes sense to me.

Committed to HEAD. We'll want to make sure when we revisit the weighting of some of this stuff that it shows up at the top of the list.

Docs, please!

Pathauto belongs into a deeply hidden page below admin/config, yes.

Pathauto provides one-time settings, yes.

URL aliases don't.

URL aliases belong into the group of things I would call "Maintain" (to maintain your site). Stuff you need to re-visit, and/or, administer from time to time. Stuff you should look into, or, needs to be administered infrequently.

Contrary to that, settings are one-time configuration settings. Stuff you don't need to look into from time to time.

I therefore am almost 100% in line with webchick's initial impression. URL aliases belong into 'Structure' (because we lack a better location).

But at the end of the day...

The pathauto page is a mix of settings (patterns) and "building" (deleting and bulk generating). I agreed to put it there because that put all the path stuff in one place and was consistent with the way that settings are grouped, like how some node "settings" are in content simply because nodes are content.

...I'm no longer sure whether the decision to move settings into settings and other stuff relating to those settings elsewhere ("Structure", potentially more) was a right decision. And I supported the initial movement of settings pages that were not yet located below admin/settings. So I'm to blame, too.

The example of URL aliases and Pathauto is actually the situation that many contributed modules will face. Instead of providing things "in-context", any related stuff will be placed anywhere -- and every single module can decide on its own. The "context" would be unique, but an IA/UX pattern merely depends on the personal opinion of someone. A "developer", which makes things most often a bit more complicated, when trying to explain UX issues.

The overall situation reminds me of "package" information in .info files, resp. the categories on admin/build/modules.

For starters: #227687: Properly capitalize "User interface" package name -- That issue actually is totally non-sense with regard to the developer time that was wasted - but in terms of UX, it's a major WTF, because you have two categories "User interface" and "User Interface" in your module list, some modules here, some modules there!

Literally the same I am going to expect in the new administrative categories. -- In addition to the no longer existing distinction between "one-time configuration" and other functionality, which adds a fair amount of confusion on its own.

Luckily. Administration menu users won't be affected by this issue. They are easily able to search, learn, and get used to strangely placed links without a noticeable impact.

However, I am very worried about the "other" users.

@sun: as you nicely explained, there is no clear choice. If there would be, this would not be left for so far at the end of the development cycle. We should definitely test this and other changes and apply our test results to the placement of these items. That would not help contrib, so we should document why did we put items as we did so they can follow.

I'm not 100% sure about placig it under "Search and metadata". I do not think this is the first place users will go a looking for it, BUT at the moment it is the best place to have. It might make more sense moving it to its own group in "Configuration and modules" ?

#653068: Update documentation is incomplete.

Is this too late to re-visit now?

Added docs to http://drupal.org/node/727352

EDIT: But yes, my comment in #31 (and others elsewhere) still remains, and we will regret this categorization. But anyway, either people are not trying to understand and work with D7, or I'm just the only one who sees this as a major usability problem that we introduced for no good reason.

See also: #759824: "Configuration" IA category has some stuff in it that has nothing to do with configuration