Ideas about notification

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Ideas about notification

hoelzro
Hello, MojoMojo!

I'm an ambitious young developer who's been using MojoMojo for quite some time now, and I figured that I should put my Perl and Catalyst skills to good use outside the workplace and contribute to a project as great as MojoMojo.

Now that my introduction is out of the way, onto my ideas about notification.  I was looking at the issue pertaining to notification (http://github.com/marcusramberg/mojomojo/issues#issue/49), and I like the "More Difficult" option, where anyone can subscribe to a page's changes.  I have some ideas on how to expand upon that:

- How about a recursive watch, so a user can monitor all page changes under a certain namespace?  This would allow admins to monitor the whole MM instance without much hassle.
- I think a checkbox on page creation/edit to subscribe to that page's changes would be cool.
- A user setting to automatically subscribe to pages that that user creates or edits would also be nice.
- Some sort of subscription management UI in the user's profile/preferences page would be nice.
- As far as the actual implementation of the notification system goes, I propose a generic notification mechanism that various output modules could subscribe to.  A page (or something else in the future) would publish a changed event, and any installed output modules would broadcast the contents of the message to all interested parties.  That way, we could implement output modules for e-mail, XMPP, or anything else that comes to mind in the future.  When users subscribe, they can specify how they want to receive notifications.

Granted, several of these ideas would take a lot of work, and some may be difficult to implement efficiently.  Please let me know what you think of them.

-Rob
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Ideas about notification

Marcus Ramberg
On Wed, Nov 25, 2009 at 1:33 PM, hoelzro <[hidden email]> wrote:
>
> Hello, MojoMojo!
>
> I'm an ambitious young developer who's been using MojoMojo for quite some
> time now, and I figured that I should put my Perl and Catalyst skills to
> good use outside the workplace and contribute to a project as great as
> MojoMojo.

That's excellent news for us :-)

> Now that my introduction is out of the way, onto my ideas about
> notification.  I was looking at the issue pertaining to notification
> (http://github.com/marcusramberg/mojomojo/issues#issue/49), and I like the
> "More Difficult" option, where anyone can subscribe to a page's changes.  I
> have some ideas on how to expand upon that:
>
> - How about a recursive watch, so a user can monitor all page changes under
> a certain namespace?  This would allow admins to monitor the whole MM
> instance without much hassle.
How would this differ from an RSS feed of recent page edits?
> - I think a checkbox on page creation/edit to subscribe to that page's
> changes would be cool.
I like this idea, even though I worry about clutter on the editing
interface. Not sure how we make such things scale well.

> - A user setting to automatically subscribe to pages that that user creates
> or edits would also be nice.
This might be a better approach to the problem

> - Some sort of subscription management UI in the user's profile/preferences
> page would be nice.
Agree
> - As far as the actual implementation of the notification system goes, I
> propose a generic notification mechanism that various output modules could
> subscribe to.  A page (or something else in the future) would publish a
> changed event, and any installed output modules would broadcast the contents
> of the message to all interested parties.  That way, we could implement
> output modules for e-mail, XMPP, or anything else that comes to mind in the
> future.  When users subscribe, they can specify how they want to receive
> notifications.

Might not want to overengineer this. Let's try to start reasonably
simple with a DBIC class for notifications

> Granted, several of these ideas would take a lot of work, and some may be
> difficult to implement efficiently.  Please let me know what you think of
> them.

In general I think starting simple and then seeing from experience
what more we need is a better approach than implementing something
complicated out of the box.


With regards
Marcus Ramberg

_______________________________________________
Mojomojo mailing list
[hidden email]
http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/mojomojo
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Ideas about notification

hoelzro
Am Nov 25, 2009 um 12:12 schrieb Marcus Ramberg <[hidden email]>:

> On Wed, Nov 25, 2009 at 1:33 PM, hoelzro <[hidden email]> wrote:
>>
>> Hello, MojoMojo!
>>
>> I'm an ambitious young developer who's been using MojoMojo for  
>> quite some
>> time now, and I figured that I should put my Perl and Catalyst  
>> skills to
>> good use outside the workplace and contribute to a project as great  
>> as
>> MojoMojo.
>
> That's excellent news for us :-)
>
>> Now that my introduction is out of the way, onto my ideas about
>> notification.  I was looking at the issue pertaining to notification
>> (http://github.com/marcusramberg/mojomojo/issues#issue/49), and I  
>> like the
>> "More Difficult" option, where anyone can subscribe to a page's  
>> changes.  I
>> have some ideas on how to expand upon that:
>>
>> - How about a recursive watch, so a user can monitor all page  
>> changes under
>> a certain namespace?  This would allow admins to monitor the whole MM
>> instance without much hassle.
> How would this differ from an RSS feed of recent page edits?

Well, the only real use of the feature would be for people who want to  
receive e-mail instead of using RSS, and also for only monitoring  
subtrees (ie. /development).
>> - I think a checkbox on page creation/edit to subscribe to that  
>> page's
>> changes would be cool.
> I like this idea, even though I worry about clutter on the editing
> interface. Not sure how we make such things scale well.

Since editing the template is so simple, we could always play around  
with this until we find an acceptable solution or scrap the idea  
altogether.  As far as scaling of UI elements goes, we could offer  
some sort of 'Advanced Settings' dropdown, perhaps.

>
>> - A user setting to automatically subscribe to pages that that user  
>> creates
>> or edits would also be nice.
> This might be a better approach to the problem
>
>> - Some sort of subscription management UI in the user's profile/
>> preferences
>> page would be nice.
> Agree
>> - As far as the actual implementation of the notification system  
>> goes, I
>> propose a generic notification mechanism that various output  
>> modules could
>> subscribe to.  A page (or something else in the future) would  
>> publish a
>> changed event, and any installed output modules would broadcast the  
>> contents
>> of the message to all interested parties.  That way, we could  
>> implement
>> output modules for e-mail, XMPP, or anything else that comes to  
>> mind in the
>> future.  When users subscribe, they can specify how they want to  
>> receive
>> notifications.
>
> Might not want to overengineer this. Let's try to start reasonably
> simple with a DBIC class for notifications

Alright; starting simple never hurts.

>
>> Granted, several of these ideas would take a lot of work, and some  
>> may be
>> difficult to implement efficiently.  Please let me know what you  
>> think of
>> them.
>
> In general I think starting simple and then seeing from experience
> what more we need is a better approach than implementing something
> complicated out of the box.
>
>
> With regards
> Marcus Ramberg
>
> _______________________________________________
> Mojomojo mailing list
> [hidden email]
> http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/mojomojo

-Rob

_______________________________________________
Mojomojo mailing list
[hidden email]
http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/mojomojo
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Ideas about notification

Marcus Ramberg
On Wed, Nov 25, 2009 at 9:16 PM, Rob Hoelz <[hidden email]> wrote:

> Am Nov 25, 2009 um 12:12 schrieb Marcus Ramberg <[hidden email]>:
>
>> On Wed, Nov 25, 2009 at 1:33 PM, hoelzro <[hidden email]> wrote:
>>>
>>> Hello, MojoMojo!
>>>
>>> I'm an ambitious young developer who's been using MojoMojo for quite some
>>> time now, and I figured that I should put my Perl and Catalyst skills to
>>> good use outside the workplace and contribute to a project as great as
>>> MojoMojo.
>>
>> That's excellent news for us :-)
>>
>>> Now that my introduction is out of the way, onto my ideas about
>>> notification.  I was looking at the issue pertaining to notification
>>> (http://github.com/marcusramberg/mojomojo/issues#issue/49), and I like
>>> the
>>> "More Difficult" option, where anyone can subscribe to a page's changes.
>>>  I
>>> have some ideas on how to expand upon that:
>>>
>>> - How about a recursive watch, so a user can monitor all page changes
>>> under
>>> a certain namespace?  This would allow admins to monitor the whole MM
>>> instance without much hassle.
>>
>> How would this differ from an RSS feed of recent page edits?
>
> Well, the only real use of the feature would be for people who want to
> receive e-mail instead of using RSS, and also for only monitoring subtrees
> (ie. /development).

The RSS feeds support monitoring subtrees already, so it's only useful
for people who hate RSS I guess :)

Marcus

_______________________________________________
Mojomojo mailing list
[hidden email]
http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/mojomojo
Loading...