simplify user interface for notifcations management

Haven't reviewed the patch but after watching the video, a huge +1 for this. The current UI is not something I want to expose to site users and this is a big improvement.

Seems like a very helpful cleanup improvement to me. I personally do like the single, filterable list (everything on one page) versus having several tabs.

I just have one question. What is the purpose of this one change?

-function notifications_ui_access_user_add($account, $type = NULL) {
-  // Main tab, visible only if any subscription type enabled
-  $check_types = $type ? array($type) : array_keys(notifications_ui_subscription_types());
+function notifications_ui_access_user_add($account) {
+  // Main tab, visible only if any subscription type enabled.
+  $check_types = array_keys(notifications_ui_subscription_types());

Thanks Greg!

subscribing

@greggles: That makes perfect sense. I see where the argument is dropped from the callback, so it's definitely best to not expect it in the called function.

I successfully applied the patch, and it all looks good except for one thing: When I go to /user/1/notifications/subscriptions, see the following in a warning box:

warning: call_user_func_array() [function.call-user-func-array]: First argument is expected to be a valid callback, 'theme_notifications_subscriptions_filter_form' was given in /[foo]/includes/theme.inc on line 617.

Do you think theme_notifications_subscriptions_filter_form() needs to stay? Or do you want to remove $form['#theme'] (line 26 of the patch)?

Looks good greggles. Patch applied. Works. No errors. Maybe the theme function really belongs in a separate patch, but your update seems sensible to me. Marking RTBC! :-)

Subscribing...

subscribing

Hey greggles, this looks nice. But it seems to me that UI work has been too focused on one specific site, gdo, while these modules contemplate a much wider range of use cases and site set ups. Actually sometimes I wonder whether UX people have ever thought about what UX means for a single module that will be run on many different sites vs improving a specific site, which is so much easier. (When you see latest D7 it seems they don't)

So I think the best option here would be to support your user story, as we all want to improve gdo, while still letting other options open.

About the specific issues here:

- The subscriptions management page with filters is cool when you have many subscription types and users can handle filters (drupal.org users can be considered experienced web users or at least above average in the context of all internet users). For a small site with only 'content type' subscriptions it would be much easier just to have the 'content type' tab alone.

- About the 'context' issues you point out, completely agree, that's something to fix and I'll start by applying that part of the patch.

- I still like the overview page because jumping straight into the filters may be too much for many users. Basically, it provides some information about what's this about and also links to some 'hidden' options like default send method and interval which are under user account edit. So IMHO instead of dropping this one, it would be some place to add some more information and help text. Whether this needs to be the default tab is an open question though, because we could also default to the 'subscriptions management' page and let this one as a 'Help' tab.

- The option to get ride of that tabs is already built into the module under Notifications UI settings, User account pages (Tab), see screenshot. Isn't this working for you?

However I think we are pretty close to your wanted UI here, maybe just some options missing. For now I'll see which part of the patch I can apply without breaking other implementations, let me know what you think about the overview page, as changing default tabs is a bit of a mess with the menus.

Committed the part to show the 'edit subscription' page under account subscriptions context, with some changes (it includes also the remove subscription)

> greggles #13
> I don't find your reaction to external feedback particularly constructive, but that's your call.

Yeah, you're right, sorry. I'll work on that.

Thanks so much for presenting the issue so nicely. I've forgotten for a while that too often generic module improvements come from these very specific user stories, we are on the same side after all...

So the feedback is really appreciated, sorry about the 'hostile' reply.