For all these subscriptions options we have, and the ones that other modules may implement we need to have three different kinds of UI
- Links/forms for the user to subscribe to nodes/comments/blogs/terms, etc... Currently handled by the subscriptions_ui module. This is the simpler case because the options are tied to the object in the UI, mostly works for now (It wont scale that good for tags when we have too many...)
- Account settings for the user to manage its own subscriptions. Depending on how many subscription types we have this may need some streamlining and simplification.
- Administration UI for admins to handle all users subscriptions and be able to subscribe/unsubscribe users at will.

About the different subscription types we have some simpler ones:
- Thread subscriptions
- Subscriptions to content type
- Subscriptions to tags
- Subscriptions to user posts
Some more complex ones, mixing the types above
- tag and content type
- user and content type
- tag and user

When having lots of tags and users and content types it is not a trivial task to have all this handled with a simple and comprehensive interface, like the one the user needs to administer its own subscription. The current model we are using of having a tab per subscription type (thread, tag...), a checkbox and a time interval may not work for these more complex subscription types.

The administrator, on the other side, should be able to handle some more complex interface like it could be having a plain list of subscriptions and some filter box, more like the node admin interface.
User[ ] Content Type [ ] Tag(s)[ ]
List: User, Type, Author,.... (link to user account pages..)

So about the user account settings for subscriptions, we really need some better solution that can accommodate all these complex subscription types easily, some ideas for this:
- Some tree-like structure that I.e. for each subscribed tag may spawn to the different contexts used for subscribing for that tag (Simple, content type, user....)

Example:
  - Subscription to Tag1 [ ] 
      - Users [...........]
      - Content types [........]
  - Subscription to Content Type A (On a different tab) [ ]
      - Users [..........]
      - Tags [...........]

- Handling the send interval in a different tab for each event type (1) instead of per-subscription, maybe also selecting for which specific events to receive notification (2)

Example 1:
  - Nodes: Send interval
  - Comments: Send interval
  - Voting: Send interval
Example 2:
  - Nodes: Create, Update, Comment...
  - Tags (terms): Create, Update, Post (Or tagging an existing post)

One last option, just in case we don't find anything better for this may be to use some subscription list with filters like the one outlined above for administrators, or maybe one of these in addition to some simpler tabs.

Comments

salvis’s picture

salvis
he/his
commented

Thanks for laying this out. Just some quick comments for now:

The checkboxes are redundant and unnecessary: setting the Send Interval to Never is as good as unchecking the checkbox.

I believe we should have a separate checkbox for each subscription (except thread subscriptions) to indicate whether it includes comments or not. You might say the same thing for updates, I guess...

(Just so we don't forget: unpublished nodes/comments need to be sent when they're being published.)

salvis’s picture

salvis
he/his
commented
Version: 6.x-1.x-dev »

Many interesting ideas, thank you — we'll have to see...

salvis’s picture

salvis
he/his
commented
moshe weitzman’s picture

moshe weitzman commented

Subscribe ... This UI seems like a nearly unsolvable problem. FYI, I'm considering add adding a plugin for organic groups so one can subscribe to 'jobs in the san francisco' group, for example.

gustav’s picture

gustav commented

Designing a perfect user interface for this will indeed be a challenge. However here are some things which I think can be improved easily:

1) When I want to subscribe to a thread on the node page I am presented with three tickboxes for that purpose. Two of them are clearly labeled: "On updates" and "On comment". But there is a third one in front that is not labelled and I have no idea what it is for. For an existing thread, what could I possibly be subscribing for beyond updates and comments? I suspect the checkbox is there only because it is also there for subscribing to content types and similar where it makes sense to subscribe to creation of new posts. Perhaps it should be shown only in those cases and should then be labelled "On creation".

2) When I subscribe to a thread I have no way of setting the interval without going to my account, then to the subscriptions tab, then to the threads tab. I think it would be better if clicking on "Subscription" on the node page (or below a teaser) would not just expand to show a limited interface on the page but would open a pop-up window with the full interface where I can also set the interval. Not having the interface on the page also makes styling of nodes and teasers much easier. So I think there should at least be an option to get rid of the current "Subsribe" block and instead add a "Subscribe" link to the node links which opens a popup.

3) Currently, when subscribing using the "Subscribe" block below a teaser on a page with many teasers the page reloads and I am back at the top of the page. This can be solved in three ways (in order of preference): a) my suggestion 2) above of using a popup window for the interface, b) setting the subscription via AJAX without page reload, c) reloading with an anchor so that one gets back to the original place after reload.

4) Currently by default the subscriptions are set to "As soon as possible". I think it would be better if the user could choose a different default. In fact I think most users will want to make the same choice for all their subscriptions anyway. They will just be annoyed by having to make that choice individually for every subscription.

5) I had expected to be able to set all my subscription options on the "Subscriptions" tab on my account page. But it turns out I have to set some of them on the "Edit" tab. I find that confusing and unnecessarily complicated. I thing the options that are currently on the edit tab should be moved to "Overview" sbutab of the subscription tab. There is plenty of space on that page.

I hope I am not appearing to be nagging. I am not. I am really appreciative of this rewritten module and am just thinking of constructive ways of suggesting improvements.

And a side-note to Moshe: I am very interested in the organic groups plugin, as will all other organic groups users. Is there an issue for this already?

salvis’s picture

salvis
he/his
commented
Assigned: jose reyero » salvis

Thank you very much for your thoughtful feedback (as well as the quick heads-up about the install issue).

1) The checkboxes in the left column are the "master checkboxes" that actually turn the subscription on or off. Once we have everything in place, we'll be looking for a JavaScript guru to show the Send Interval, On update, and On comment items only when the master checkbox is active. This ought to make it clear what's happening, no?

2) Right, the Send Interval column is missing from the node page. It should be added IMO.

2.1) Is it necessary to be able to subscribe from teasers?

2.2) We've been debating about where the node subscriptions interface should go. Of course it doesn't need to be expanded by default, but even then I'm not really happy with where it is. Having just a link that opens a pop-up is a great idea!

3) Where do you see a "block below a teaser on a page with many teasers"? I don't think we add the fieldset to teaser views but only to full-node views. Either way, a pop-up would avoid the page reload, one more in favor of a pop-up!

4) We intend to have site-wide as well as user-specific defaults for the Send Interval, On Update, and On Comments values.

5) The Subscriptions settings on the My account | Edit page are a left-over from the old design. You're right, it makes sense to move them to the Overview page.

Keep it coming!

gustav’s picture

gustav commented
Version: » 5.x-2.0-beta2

Thanks for your positive reply. I would be very happy with all your suggestions.

1) Yes, with that bit of javascript in place everything will be intuitive.

3) There is an option "Show subscribe link with teaser" and I had that selected. I have switched that option off now. But a simple link to a "Subscribe" popup would make sense even on teaser pages.

introfini’s picture

introfini commented

Hi,

I think that the fieldset attribute #collapsed should default to TRUE, or else we get a big ugly form in the end of the node.

Regards,
introfini

Daryljames’s picture

Daryljames commented

Hello,

After 3 months of building my site. This is my first comment. That said. I am in desperate need of my users being able to recieve notifications on a bit deeper level. I've been following the developement of 5.2x, and have seen some speculation of an incorporation with views.

To be exact I need my users to be able to subscribe to a taxonomy, and recieve updates filtered by proximity i.e. posts within 250 miles in Automotive Category.

Is this something that may be being incorporated, or do you have any suggestions on how to implement such a feature by any combinations of modules?

I really appreciate in advance your replys.

Daryl

Daryljames’s picture

Daryljames commented

Hello Again

The other thing I was wondering. Will it mess anything up if I change the term Taxonomy back to Categories. I'm pretty sure my users are not going to be able to figure out what a taxonomy is without a little research, do I need to change the term in anything but the subscriptions.ui?

Daryl

Daryljames’s picture

Daryljames commented

I've been running around this module for a little while, and found a couple things that aren't working correctly.

1. the subscribe to content box is appearing on pages for users whos permission is set to not be able to subscribe to content, only to taxonomy.

2. In the overview link content types appears with a value of 0 even when the user is not allowed to subscribe to content types.

3. Also when viewing a full page view of a node you are given the same opportunity.

It seems as though subscriptions is not respecting the permissions set for the user.

Daryl

salvis’s picture

salvis
he/his
commented

PLEASE USE THIS THREAD ONLY FOR UI DESIGN DISCUSSIONS!

@introfini: Yes, I agree, the fieldset will be collapsed by default. I assume, chx set it to expanded so that testers will notice it, but I'm sure it won't stay that way.

@Daryljames:
#10: You should be fine changing the title in
'title' => t('Taxonomy'),
in subscriptions_taxonomy.module.

Please do not post off-topic replies. Post new issues for #9 (support request) and #11 (bug report), and if you find additional bugs, then open more new issues, otherwise this becomes unmanageable.

introfini’s picture

introfini commented

Hi Salvis,

I also think it would be great to have the option to show the subscribe form as integrated in the node or as link to a separated page (better for themes).

Thanks,
introfini

mr.andrey’s picture

mr.andrey commented

I second introfini's suggestion about being able to have "subscribe to post" be in the links that takes the user to a separate page.

I have a voting module at the bottom of my posts and it looks extremely busy with this extra fieldset.

Thanks for all the great work!

Best,
Andrey.

salvis’s picture

salvis
he/his
commented

"subscribe to post" links

Unfortunately, chx hates pop-ups, so the debate goes on. Another idea was to put the node UI into a block of its own, which could be displayed in the footer region.

mr.andrey’s picture

mr.andrey commented

It would be really neat if "subscribe to post" link was in links and upon clicking it, the links would move down and the fieldset unfold on the top sort of like js/ajax tabs.

Subscribing to an article is not something that everyone would want to do all the time, so personally I wouldn't mind going to a separate page to subscribe. To include the form at the bottom of each node is a bit overkill IMO. Some kind of alternative would be very welcome.

Thanks,
Andrey.

salvis’s picture

salvis
he/his
commented

There needs to be a usable fallback for those who don't have JavaScript enabled.

It doesn't need to be pretty, but it must work reasonably well.

Daryljames’s picture

Daryljames commented

Hello Again,

I personally think that the way it is is great, as long as it's collapsed by default.

samuelet’s picture

samuelet commented

Me too.
And may i suggest to set also the description field? Noob users don't know what subscription mean.

Crimson’s picture

Crimson commented

Okay, this form UI way of doing it is really not jiving well with my themes and the way I've setup forum topics. Is it possible to give the option of only having a link that goes to such a thing? Or even better, when you click on the link, a drop down menu appears that gives you the subscription options (like in the other forum software).

moshe weitzman’s picture

moshe weitzman commented

I am thinking that we need an admin page analogous to the 'display fields' tab that CCK offers where an admin can say which of the available subscriptions should actually appear. there might be more prefs there like fieldset versus node links.

andrabr’s picture

andrabr commented

A couple of suggestions toward UI simplification (I will be submitting formal feature requests for tracking purposes):

1) "Send Interval", while a wonderful feature, is often too much for the users. I believe it needs a permission, manageable both via the standard "Accesss Control" UI and the subscription administration interface at admin/settings/subscriptions

2) Subscriptions by author probably need to be handled as a dimension of its own - I know users who would not care what kind of content they are subscribing to, but will very much care who wrote it. (Does this deserve a separation to a submodule? - Oops! off-topic)

3) The most natural place for a user to subscribe to a post is the post's page - this is the way it works already. The most natural place for a user to subscribe to a taxonomyy term, a content type or an author is while visiting the tag page, content type page, or author's profile. I would say that these are badly needed, and in fact one should be able to switch off all the fancy in-post subscription options (like we do for teasers today) in favor of subscribing in the term/tag/author pages, right next to RSS subscription.

An excellent use case for (3) is opening subscription to a free tagging vocabulary. Just imagine the form it will generate once the users add a few hundred tags! Which brings me to the last suggestion:

4) Management of free tagging vocabulary subscriptions definitely requires special handling in user profiles. I would suggest showing only the tags already subscribed to. (3) will handle new subscriptions just fine.

I am just beginning to learn Drupal (it's AWESOME), but at least I can give back a bit by thinking this through :-)

salvis’s picture

salvis
he/his
commented
Assigned: salvis » Unassigned

Lots of great ideas here — I don't want to stand in the way of anyone putting some of them into patches...

If you're interested in doing this, please start a new specific issue and let's discuss it there.

Daryljames’s picture

Daryljames commented

Hi all,
I just wanted to make a small suggestion. I like the new interface in the account section. The one thing that doesn't make a whole lot of sense for my website is having the check box for comments, because we don't use the comment module. I see that there is a way to set the interval, but will there be a way to shut off these options all together?

salvis’s picture

salvis
he/his
commented

I agree that displaying the On comments column is pretty dumb if you don't have comments -- will work on it...

You want to hide the other columns, too?

Daryljames’s picture

Daryljames commented

The other columns are fine, I just wasn't sure what the author area was for, nothing is displayed there.

intent’s picture

intent commented

First off, I just want to say how impressed I am with the subscriptions module (and Drupal in general for that matter - I'm new to the cms).

I agree with those who posted above that the current UI is probably overly complicated for most users. I would recommend giving admins an option to hide any or all of the columns (Interval, On Update, On Comments).

Secondly, I would like to be able to define the content types to which a user is allowed to subscribe by role. I like the functionality in the "User defaults" admin and would essentially like to see that expanded so that I could select a role and select which content types will display on the subscriptions sign up page when members with that role view it.

For example:

Let's say I have two roles; man and woman. My content types might be "Sports," "Automotive Repair," "Home Decor," and "Makeup" (sexist, I know, but please hang in there with me :p )

If a user is assigned a role of man, I only want him to see "Sports" and "Automotive Repair" as content type subscription options.

If there is already a way to do this and I have simply missed it, I apologize.

Again, thanks for the great module.

mr.andrey’s picture

mr.andrey commented

Here's an alternative that makes "Subscribe to post" a node link that goes to a separate page.

http://drupal.org/node/208631

salvis’s picture

salvis
he/his
commented
Version: 5.x-2.0-beta2 » 5.x-2.0-beta8

I barely dare to touch this thick thread, but we've come a long way and much of what has been discussed here is implemented now.

Please open new separate issues for any additional UI discussions, unless you have a specific and good reason to tag on here...

gustav’s picture

gustav commented
Version: 5.x-2.0-beta8 » 5.x-2.0-beta9
Status: Active » Closed (fixed)

I have just read through this long thread and was very impressed that virtually everything that has been suggested here has been implemented by salvis and chx.

I feel it is a bit of a waste of time to make others read this long thread, given that almost everything that is written about has been solved. So I am taking the liberty to mark this as closed. Anything that is not yet resolved needs to go into a new thread, otherwise noone will find it anyway.

salvis’s picture

salvis
he/his
commented

Thanks, delius.

I believe there was one missing piece, namely a better place to put the node form. I hope http://drupal.org/node/208631#comment-702471 is (or will lead to) the answer to that remaining issue.