Forum OpenACS Development: General Alerts

Collapse
Posted by Malte Sussdorff on
Out of curiosity. Is anyone porting general alerts in a way that
allows ALL kind of alerts to be managed through one interface?

This means not only one page where you can turn on/off your
news/calendar/bboard alerts but as well manage spam mails. Add to this
templating functionality (In the 3.x package there is support for
this), so you could decide what format the alerts should have (useful
for .LRN if e.g. Students want to know from which community they are
spammed, they could choose a format in which to recieve the mail and
then sort mails automatically with their favourite email client).
Furthermore this would allow multiple destination types for the alerts
(Jabber, SMS {for those lucky Europeans}, VoiceXML).

Collapse
2: Response to General Alerts (response to 1)
Posted by Don Baccus on
Coincidence is a wonderful thing - one of the OpenMSG programmers e-mailed me today talking about the desire to integrate SMS into OpenACS 4.

No one is working on a general alerts package of the sort you describe.  We really need something like this, and we need an architecture that allows for multiple destination types as you mention.  The agents that do actual delivery (via e-mail, Jabber, SMS etc) should be built using the service contract model, right?

And packages that do alerting should also do so using the service contract model.  The general alerts package, and its UI, then can be thought of as sitting in the middle, providing a way for users to connect alerts from various packages to message delivery agents of their choice.

Am I on the right track?  The most challenging aspect of this might be the UI - flooding the user with choices is a good way to confuse them.

dotLRN will only provide a simple e-mail service much like OpenACS today, AFAIK, because that's the way it works now in ACES.  There is that nice central alerts page you talk about, though.

Collapse
3: Response to General Alerts (response to 1)
Posted by Michael Feldstein on
Regarding the UI, if somebody can sketch out usage cases for
me, I'd gladly take the first crack at a wireframe.
Collapse
4: Response to General Alerts (response to 1)
Posted by Don Baccus on
The OpenMSG folk are going to jump in soon, either here or in a new thread ...

Hmmm...Malte, do you have a box running ACES up?  If so, Michael could look at its general alerts page to get a sense of how things exist now.  The basic change is that you will in the future need to be able to set the kind of alert you want to receive (e-mail, SMS) as well as frequency and all that.

Collapse
5: Response to General Alerts (response to 1)
Posted by Michael Feldstein on
If it hasn't changed from the version that was on Sloanspace
circa April, then I'm already familiar with it. It was pretty bad, but I
have some definite ideas about how to improve it.

I take it, then, that we are only talking about the end-user UI, and
not the admin UI (at least for now).

Collapse
6: Response to General Alerts (response to 1)
Posted by Don Baccus on
Yes, end-user UI for controlling their personal alerts.
Collapse
7: Response to General Alerts (response to 1)
Posted by Malte Sussdorff on
At least we made some improvements and use the general alert system instead of the homegrown solutions. Check it out at www.aiesec.net, you should get access within a day or two. Or send me a mail when you registered.
Collapse
8: Response to General Alerts (response to 1)
Posted by Michael Feldstein on
<p>OK, I'm working with Malte to see the latest ACES
interface.</p>

<p>In the meantime, it will help to nail down the functionality
goals in more detail. In particular, I need to know not only what's
likely to get built into the first iteration, but also what is likely to
get built into the second and third iterations, so I can design the
interface to accomodate future needs. So here are some
random questions/thoughts on functionality:</p>
<ul>
<li>Using bboard as our archtype, there are at least two levels of
alerts. First, there are alerts for a package instance (e.g., one
bboard.) Second, there are alerts for particular items (e.g., one
discussion thread in bboard or one ticket in ticket-tracker.) As I
recall, the ACES implementation only allows you to toggle the
first kind (i.e., at the package instance level). Would we want this
package to enable both levels of control?</li>

<li>If the answer to the previous question is "yes," then how do
we handle interactions between the instance-level settings and
the item-level settings? For example, I could imagine somebody
wanting a daily digest of a bboard but instant alerts for one
thread. What options do we want to offer? What kinds of default
behaviors make the most sense?</li>

<li>I can imagine somebody wanting to set alerts on a third level,
in which they want to know about content items of a certain type
across all package instances. For example, somebody might
say, "Alert me to all content items submitted by Al Essa," or "Alert
me to all content items that are categorized under XML," or even,
"Alert me to all content items that contain the words 'cell,' 'phone,'
and 'AT&T' in them." Do we want to plan for this sort of
functionality in the foreseeable future? (If so, then I suspect that
the UI design should overlap with the search UI.)</li>

<li>I understand that we want an interface that makes it possible
to plug in new alert channels (e.g., email, Jabber, SMS, etc.) as
they are developed. At what level of granularity do we want/need
to allow users to control their channel output? At the item-level?
At the instance-level? Both? And am I correct in assuming that
we want users to be able to select output to, for example, both
their pager and their email?</li>

<li>Which of the features listed here are likely to make it into the
first iteration? Which into the second or third? And which should I
just cross off the list entirely?</li>
</ul>

Collapse
9: Response to General Alerts (response to 1)
Posted by Don Baccus on
Those are certainly really good questions, Michael, and I don't have any solid answers.  These are design choices that we need to think about.  There's a risk of providing so much choice that it would become unusably complex.

Maybe Malte's thought about this.  He should - he raised the issue, after all! (you're stuck, Malte!)

BTW ACES allows you to get alerts for postings by a particular person, I think.  More arbitrary criteria - i.e. search strings - could get awfully expensive in terms of server effort.  Selecting alerts according to categorization criteria would be less expensive.  But this requires good categorization.

As far as what to expect in a first release, I think we need to hammer out a basic design for the package and those plug-ins that fulfill its contract requirements.  This is crucial.  Plain e-mail alerts and a few basic packages hooked to it is probably all that's likely to get done at first unless OpenMSG, Malte, or others with a serious need are able to devote considerable effort to it.

Collapse
Posted by Peter Harper on
Hi folks,

Appologies for not dipping into this conversation until now, I've been pretty busy.  As Don's already mentioned, us at OpenMSG  are very keen to see some progress in this area.  We've been building AolServer SMS support for while now, and would like to see the OpenACS adopt a notifcation/message/alert scheme that would allow (relatively) easy integration of this stuff, as well as the jabber development being done by Tom.

I'd literally only just started thinking about this yesterday, so I haven't got any clear thoughts in my own head yet about overall requirements.  I'll try and formalise them over the next few days.

The issue raised by Michael regarding a user wanting alerts "from user x, or containing text y" is interesting, and by total coincidence is another issue I've been discussing with my colleagues here at OpenMSG over the last couple of days.  This is highlights common functionality (in my opinion) that might be used across various different packages in the system, i.e. a filtering mechanism.  Is there a requirement here for an acs-filter service package?  This could allow a user in the system to apply filters to their alerts.  (granted Don's concern about server CPU cycles....).  Ideally, this package could be integrated with the content repository, so providing a content item "filtering" mechanism.

I need to bring myself fully up to speed with the current alerts system within the ACS, which I shall do over the next couple of days.

Cheers,
Pete.

Collapse
Posted by Don Baccus on
It would be great, Peter, if you guys could take the lead on formulating requirements and could float design ideas for this stuff.  It really needs some focused thought.

As far as my comment regarding computational expense, I didn't mean to imply that we shouldn't consider ideas like Michael's.  For lower-volume  sites computational expense is less an issue than functionality.  We just want to make sure we provide optional functionality that we know will scale well, too, and that we don't introduce computationally expensive features on a non-optional basis.

And acs-filters package?  That's an interesting idea ...

Collapse
Posted by Michael Feldstein on
A filtering system would be cool. In addition to supporting alerts,
it might be useful for doing the equivalent of saving a search
query. (In fact, might there be some overlap in functionality
here?) It would be nice to be able to have non-programming
users define criteria for selecting content and have that content
either pop up in an alert or act as a data source for a portlet or
adp page. Is that feasible?

Along the same lines, if we develop this kind of capability we
should make sure that the UI is shared by the search package.

Collapse
Posted by Malte Sussdorff on
My $0.02:
  • Types of alert sources we deal with:
    BBoard, News, Calendar, File-Storage, Content Repository and many more
  • Types of destination:
    EMail, Instant Messaging, VoiceXML, SMS, Pager and many more to come
  • Types of filtering alerts:
    Category, Subject, Keywords, Author, Community probably even here many more
  • Other interesting information: Frequency, Subscription Status (on, off, vacation)
For the UI we could look at a hierachical presentation:
  1. Alert Source
  2. Alert Filter (e.g. Group or other)
  3. Alert "Title" with destination, frequency and status.
This list could get very long though. But maybe if we use something like the ticket tracker dimensional sliders, we could bring this into a more useful UI.

On the other hand, how do we solve this technically? Now would be a perfect moment for having a wicky. Hmmpfff.... My suggestion is that we first phase out possible stages of evolution using wimpy point in collaboration. Then we could add to this possible UI designs (scanned hand drawings should be fine for a start). Furthermore, the more technical guys could start on looking at implementation possibilities. And once we have this, I'd try to get cheap labour (e.g. students or developers from armenia, russia, india) to actually implement our design. Because I'm at least convinced this can be sold later on as part of implementation work for a client 😉.

P.S.: On a personal note, I'm off til probably 1st of November, so dont expect immediate responses from me til then.

Collapse
Posted by kapil thangavelu on
some more change (+0.02USD)

it sounds like there are two issues being discussed here, functionality and ui of alerts. i'm more interested in functional reuse of the system. functionally, the system being described here could be better described as an event channel supporting a subscribe/publish model with push and pull distribution of events and listener filter registrations. i think such a system would be of great utility and i think designing it in a general way will facilitate functional reuse. as far as implementation i think an approach based on acs-service-contract with a model much like neophtyos did for search would be useful (a little more fleshed out to support some of the additional features and ui). my relational skills are so weak that i hesistate to suggest in front of such an august crowd, but what about a single events table, one for listener registrations, and another for listener filters, and another for event channels, and perhaps one for publisher registrations (on a given channel).