[buddypress-trac] [BuddyPress Trac] #6712: Screen notifications settings page
buddypress-trac
noreply at wordpress.org
Wed Apr 20 23:59:05 UTC 2016
#6712: Screen notifications settings page
---------------------------------------+------------------
Reporter: r-a-y | Owner:
Type: enhancement | Status: new
Priority: normal | Milestone: 2.6
Component: Component - Notifications | Version: 1.9
Severity: normal | Resolution:
Keywords: has-patch early |
---------------------------------------+------------------
Comment (by DJPaul):
I've been doing thinking about this recently. I remembered some
discussions Boone, John, Rocío, and I, had at the last WCSF:
https://bpdevel.wordpress.com/2014/11/12/at-wcsf-some-attendees-of/.
Please read the "Activity component" section. It broadly covers a concept
designed to overhaul how any kind of notification is done internally, and
the flexibility that it would provide to the core BuddyPress experience,
and for developers. I still believe this is a worthy goal.
The general idea that any kind of action on a site triggers an event which
handles sending notifications to affected user. "Email" or "toolbar" would
just become one type of notification (not dissimilar from how WordPress
supports post types -- it's still a content type, just handled
differently).
I'm not intending to de-rail this ticket by saying "we shouldn't build
this until we have that other thing done", but just that consideration is
given to this future goal so we can make the best decisions for today
without stitching ourselves up in the future.
'''1) The existing "[user] > Settings > Emails" screen should encompass
both Emails and Toolbar notifications.'''
There should not be a separate screen for each *type* of notification. For
example, if we ever wanted to add SMS Text Message support to BuddyPress
core (an unlikely example), having to introduce a third notification
screen for text messages -- with virtually the same layout as toolbar and
emails -- is a very poor user experience.
In terms of what this means for this feature, rather than "yes" and "no"
as options, we could have something like a radio button for each
notification type for "only email", "only toolbar", "both".
We don't need to build UI support for any kind of custom notification type
API at the moment (apart from basic hooks and filters) because the
underlying notifications PHP architecture will require a substantial
overhaul.
'''2) The underlying implementation for updating/fetching email or toolbar
notification preferences doesn't need to be unified yet.'''
We can use the new functions you've proposed for toolbar notifications,
and the existing functions for email notifications, etc. These can be
unified in the future if/when the subscription changes occur.
:)
--
Ticket URL: <https://buddypress.trac.wordpress.org/ticket/6712#comment:15>
BuddyPress Trac <http://buddypress.org/>
BuddyPress Trac
More information about the buddypress-trac
mailing list