Move update notification settings

Patch that moves admin/reports/updates/settings to admin/settings/updates. Gets rid of admin/reports/updates/list, since it is not needed with no other tabs available. Plus, change in the update settings title to a more applicable name.

applies cleanly and works for me.

I added a description to the admin/settings/updates, since its no longer a tab: "Change frequency of checks for available updates to your installed modules and themes, and how you would like to be notified."

The /admin/build/menu page has the same Settings tab, and you can find more examples..

Can we make a general solution please, and not just move things around when someone does not find something.. menu_local_tasks are not visible enough in garland theme, that's a fact. But before removing all of them can we write a general regulation where things should be..

similar UI issue: #209237: Unify the UI for delete functionality

Yeah, this needs a more general solution. Some people think having the settings "live" right next to the things they control is better UX. Other people think putting all the settings in 1 place, even if they touch wildly different parts of your site is better UX. Seems like core does some of both. Perhaps local items aren't visible enough with garland. Perhaps we need a solution where you can have multiple ways to find the same settings. For example, maybe the problem is that admin/by-module didn't find this settings tab (I've never looked closely at how admin/by-module actually works, but perhaps that's where we need the effort)...

In fact results on #546956: [meta-issue] Overhaul of Information Architecture seems to call for rolling this change back. The general thinking there seems to be that we'd have standalone settings pages for items which belong under a category with other items and if this is not true, we'd try to put the config page under the item which is being configured. This stands for menu and update status at least.

Here is a quick rollback patch.

Tested this and it passed. I support this change.

Tagging IA.

I don't really want to roll back a patch asked for by the boss. ;)

Also agree with this - this page is 1-1 with update status - we don't have any other pages about update stuff, so belongs in context with it.

Reopening this issue.

Getting used to the new D7 C&M page, i expected this to be under the system or the development category.

Patch attatched to put this in the system category.

also, this keeps it similar to all the other reports, (which are also a single page,) where the setting pages can be found in the C&M hierarchy

Argh. ;)

I still maintain it would be better for the settings page to live both next to the report that the settings impact (how I wrote it originally, and supported by various usability tests since), and next to all the other settings pages (where Dries and others apparently expect to find it). Why not just have two doors into the same room? I guess the only downside is that the breadcrumbs are going to be tricky if you can reach the same page from two different paths. But, I predict this page is going to move around over and over while the two opposing camps try to convince the other than their way is the One True Way(tm) that people will find these settings. That just seems crazy.

about the UX: context sensitive settings (where no content (menu, theme, blocks) == nothing to set) should be located as sub-items of the pages itself, while general (global) settings should be in the C&M hierarchy

the best example of this is content types: if there are no content types, there is nothing to set.

There is a "show tabs on overview pages" I strongly recommend not committing this until that's in.

@chx:
you mean: #550718: admin/people needs to have a default tab (was: Tabs on admin pages are not accessible from overviews and menus) (which should be committed soon, as it is pretty important from the usability standpoint of this and other issues)

when viewing admin/reports I expect an overview of the reports from my site, not a overview of al the reports, and also all availble settings for those reports. (settings is not a report! also where did we move the settings for logging to?)

I regulary work with #550718: admin/people needs to have a default tab (was: Tabs on admin pages are not accessible from overviews and menus) and #516150: Add fallback for main content block rendering applied, and unpatch those two right before creting a diff.

This patch makes even more sense when #550718: admin/people needs to have a default tab (was: Tabs on admin pages are not accessible from overviews and menus) is applied.

#550718: admin/people needs to have a default tab (was: Tabs on admin pages are not accessible from overviews and menus) is committed.

Sorry, this is a won't fix. We made a conscious decision to put this under Available updates, as it lives in that context. I understand that you might not be able to find, it but that doesn't necessarily means it should be exposed in /admin/config - we should prioritize "Overall use of the IA" higher then just this task. Where our current IA will break down if we start adding configuration links of certain top-level items to admin/config - simply because there will be to many links, we should reduce the ammount of links Drupal core exposes not increase it.

There are many tasks of finding functionality that are far more critical, then this one. If we add this one in the top level, we basically say - screw prioritization, lets fill this page with configuration links. Are we going to add menu configuration, to the structure category then too? (please don't make a patch for that).

Eitherway this is part of a larger strategy to expose the right items to /admin/config and to lower the cognitive load of that page by reducing the number of links. One way to do this is to increase the amount of context driven links, where the configuration or other kind lives inside the parent it belongs to. If you learn this pattern, which you have not yet - it should be all right.

Yes, 1-1 configuration screens should live 1-1 next to the other admin pages they affect.

@Bojhan: Thanks! That's exactly what I was hoping you'd say. Yay. :)