Page 1 of 1

Centralized notification handling

Posted: Fri Aug 18, 2017 11:00 pm
by brentwilliams2
First of all, I apologize that I am going to break part of the rule for this category, but I'm not a developer and don't know how to help. That said, I hope you find value in this idea. What I have found that Joomla needs is the ability to centrally manage notification settings across several extensions. Currently, unless I'm mistaken, each component handles their notification settings independently, which means users have to hunt down all the places where they can turn on/off email/text/on-page/etc notifications. I believe that this framework should be handled centrally.

Re: Centralized notification handling

Posted: Sat Aug 19, 2017 10:26 am
by ranwilli
No, No, NO!

Re: Centralized notification handling

Posted: Sat Aug 19, 2017 3:48 pm
by brentwilliams2
Can you share an alternate solution? Because having it reside only within the individual components is a really bad user experience.

Re: Centralized notification handling

Posted: Sat Aug 19, 2017 7:27 pm
by sozzled
It's not really possible to have several extensions, created by different developers, to all work co-operatively together to use a "centralised notification" mechanism. Different Joomla extensions use different systems: some of them use email (which is about as "centralised" as one can imagine; other systems rely on messaging features built into those components and the messages are "delivered" when the visitors to the sites login.

I don't understand the "bad user experience" that you assert. Perhaps you might like to clarify those comments.

Furthermore, not every website manager installs all the different kinds of extensions—there are thousands of them—that are available in Joomla. Each extension has its own "notification" mechanisms. It's a matter of learning how those extensions work and then to utilise those features to the best of your own needs.

I'm sorry that you feel it's difficult for you (or your users) to "hunt down all the places where they can turn on/off email/text/on-page etc. notifications" but that's the way that all software products have worked ever since the first computer programs were written for decades of years. If you want to help your users then, I suggest, you teach them about the facilities offered by your site and how they can use those features themselves.

For these reason, I agree with @ranwilli. Furthermore, I am asking the forum moderators to move this topic to a more appropriate forum category (viz. "The Lounge").

Re: Centralized notification handling

Posted: Sat Aug 19, 2017 9:23 pm
by brentwilliams2
I don't mean the delivery of notifications, but rather the selection of what types of notifications that a user wants to receive. Let's say that you have a forum, job board, blog, etc all installed. The user has to select their notification preferences (i.e, do I want to get email notifications for different types of activities) for each component in their own component area. That is absolutely not consistent with other websites, where users can define their notification preferences all in one spot. This is the type of functionality I'm talking about: https://www.facebook.com/settings?tab=notifications.

Re: Centralized notification handling

Posted: Sat Aug 19, 2017 9:43 pm
by sozzled
Facebook is just one, single (and proprietary) application. It's a not a website and, therefore, one can't compare applications like Facebook with "other websites". The ability to manage Facebook user preferences from a central place has evolved over time and, even today, some preferences are still not centralised and may, in fact, be described as clumsy. I'm not buying into any arguments about Facebook, by the way. We're just comparing apples and oranges.

Re: Centralized notification handling

Posted: Sun Aug 20, 2017 4:16 am
by brentwilliams2
I don't know why you are talking about "arguments" anyway. I'm just trying to share an idea that would help with usability and user satisfaction. I don't know why both yourself and ranwilli are responding like this - it surely doesn't foster a healthy, positive environment.

Re: Centralized notification handling

Posted: Thu Oct 26, 2017 2:20 am
by mmx
It would be nice if framework and extension notifications could be queued to a todo list for further action on a time-availability basis. Large numbers of notifications make it difficult to work with some extensions. If introduced as an api, extension developers could write code to support it for their own packages.

Some extension developers, overuse notifications. Not meaning to point out any specific developer, I will call out Minitek's FAQ Book Pro component as an example. It generates a notification each time a new faq section is created to suggest creating a menu entry for the newly created section. You cannot remove these notifications without creating a menu item. When creating a large FAQ consisting of many sections, a lot a notification messages appear. As a result, one has to constantly adjust scrollbars or roll the mouse wheel to reach the form for adding new sections. In many circumstances, it's not necessary to create a menu item at all. This could be handled with a url link but you are forced to create a menu item.

Notifications are a great feature but also a nemesis of sorts when ergonomic principles are not considered.

Re: Centralized notification handling

Posted: Thu Oct 26, 2017 4:40 am
by brentwilliams2
Hi mmx,
Maybe I'm misunderstanding your reply, but I was referring to email notifications (or site notifications like JomSocial has). So I didn't quite get what you were meaning with scrolling - it sounded like you were talking about on-page notifications?

Re: Centralized notification handling

Posted: Thu Oct 26, 2017 5:17 am
by mmx
Sorry, I hit upon your post while looking for a solutions to a few problems and experiences. Wishful thinking and some stupidity on my part.

Re: Centralized notification handling

Posted: Thu Oct 26, 2017 9:27 am
by darb
Notification is and should be part of the so called centralized rule based decision management system ie rule engine and a centralized rule modeler integrater where you can set up different rules with standard operators/models objects to different actions with triggers for different Joomla components. Facebook using rules for ads and it could also be used for notifications for triggers and actions (decisions) Drupal also have a rule engine and using rule syntax already integrated with its taxonomy/vocabularies and nodes.

I have discussed this very much since Joomla 1.0 2005 and still there is a slow motion for doing something similar like Drupal & Facebook ie but some 3pds start using rule set thinking with at least operators and use of proprietary rule based parameters only for example the new EasySocial 2.1.1 with conditional field types ie rules.

I have given up to discuss this any further and this is the last attempt to get some attention for making something similar to J 4 https://groups.google.com/forum/#!topic ... ykSwblNvoA and the Joomla core developers are not eager to learn, understand and use this kind of thinking unfortunately

Facebook ad rules https://developers.facebook.com/docs/ma ... arted/v2.9

Read more in the Joomla Google discussion Johan "For example"
In a rule engine world, a rule can be applied anywhere regardless of the actor.

https://groups.google.com/forum/#!topic ... ykSwblNvoA

For example

Assume you want to build an email notification plugin that is triggered each time a article is added. This is very easy to build using the plugin system, if however you want to use that same plugin to send email notifications for a contact, or a category, or when something is added in a third party extension that would be a whole lot harder.. You would need to build a separate custom plugin for each use case, or implement specific code for each.

In a rule engine world, a rule can be applied anywhere regardless of the actor. To be able to do that you foremost need a standardised interface. This is an old problem in Joomla and the discussions around rule engines go back more then a decade now. It's not an easy problem to fix. It's something we tried to solve with the MVC in 1.5 but never really got enough standardisation in to be able to do so.

Re: Centralized notification handling

Posted: Thu Oct 26, 2017 9:36 am
by darb
Quote and example of php built RulerZ

That's cool, but why do I need that?

First of all, you get to express business rules in a dedicated, simple language. Then, these business rules can be encapsulated in specification classes, reused and composed to form more complex rules. Specifications are now reusable and testable. And last but not least, these rules can be used both to check if a candidate satisfies it and to filter any datasource.

If you still need to be conviced, you can read the whole reasoning in this article http://blog.kevingomez.fr/2015/02/07/on ... er-things/.

https://github.com/K-Phoen/rulerz

Re: Centralized notification handling

Posted: Sat Oct 28, 2017 8:06 pm
by mmx
darb wrote:Quote and example of php built RulerZ

That's cool, but why do I need that?

First of all, you get to express business rules in a dedicated, simple language. Then, these business rules can be encapsulated in specification classes, reused and composed to form more complex rules. Specifications are now reusable and testable. And last but not least, these rules can be used both to check if a candidate satisfies it and to filter any datasource.

If you still need to be conviced, you can read the whole reasoning in this article http://blog.kevingomez.fr/2015/02/07/on ... er-things/.

https://github.com/K-Phoen/rulerz
There is no reason why a biz rules api could not be added to the framework itself by an independent party. Use what interfaces, classes and libraries you can from the framework and extend the framework by writing your own code. Maybe the framework needs added support to make that possible.

I usually write code using the Yii framework and we do have a dedicated biz rules api for RBAC. Many developers use the conventions set by the api to write their own application-specific rules for RBAC as well as their applications and implement those rules in their models.

This is one of those areas where "if you build it, they will come". Anyone can build it. Developers will use it if available.

Now that Joomla! is looking more like a non-CMF framework, more independent effort probably should be directed in this area.