search

ushahidi / platform

Ushahidi Platform API version 3+
http://ushahidi.com
Other
682 stars 506 forks source link

Notifications #519

Closed ushbot closed 9 years ago

ushbot commented 9 years ago

Management and pushing of alert messages:

Need to

Created by shadowhand on 2014-11-03 10:43:40.

Imported from https://phabricator.ushahidi.com/T1076

ushbot commented 9 years ago

Comment by anarghya on 2014-11-03 14:35:38:

Can you @ tag me on the ones you need a spec on? Thanks! So on this you need a spec from me, correct?

ushbot commented 9 years ago

Comment by shadowhand on 2014-11-13 05:15:54:

@anarghya need spec for how alert screens should interface with users. also need spec to describe the content used for SMS and email alerts. also need a spec for the admin management of alerts.

ushbot commented 9 years ago

Comment by @rjmackay on 2014-11-14 10:42:20:

.. can we have a 'needs spec' tag or column on the workboard? that'd be useful for knowing where to engage in product spec'ing :)

ushbot commented 9 years ago

Comment by @rjmackay on 2015-01-15 16:30:33:

Moving this to Feb.. but can we get design / spec work underway for this before Feb? @brandonrosage?

ushbot commented 9 years ago

Comment by anarghya on 2015-01-16 13:28:05:

@rjmackay wasn't camelcase working on alerts? What happened to that? It was a different task if I recall correctly ...

ushbot commented 9 years ago

Comment by @rjmackay on 2015-01-16 13:37:20:

No idea TBH. However the design framework doesn't really discuss alerts, and the design thinking about this needs to happen before we blindly build something.

ushbot commented 9 years ago

Comment by shadowhand on 2015-01-16 13:59:27:

CamelCase never worked on alerts.

ushbot commented 9 years ago

Comment by @middle8media on 2015-01-17 04:45:49:

Agree that we need to think in terms of Design Framework first. @brandonrosage, @sophshep and will discuss and work into DF.

ushbot commented 9 years ago

Comment by @brandonrosage on 2015-02-25 09:11:09:

@sophshep and I worked through this today, [[ https://docs.google.com/a/ushahidi.com/document/d/1JnfDERRFBV6suR0lglf76Fu9uVnfhs0PjwiGrtWrHDU/edit#heading=h.u4i0by55ks9m | adding some visual design work ]] to the Design Framework. Below is a detailed description for how we intend for "Alerts" to work.

Alerts are communication tasks defined at the deployment level, within Tools, requiring a title, a logical statement that defines the activity that triggers the task ("If..."), and a logical statement for what the task is ("Then...").

The title field is intended to be a short text description of what the alert does (e.g. "Notify editors about new unstructured posts").

The "If..." field is intended to be an interactive sequence of select controls that form a logical statement about what conditions within the deployment will trigger the alert's task -- its "Then..." statement. It does so by first asking what type of content will trigger the alert: Post or Comment. Then, it asks what the content must do: Created, Modified, or Added to a Set.

For Created and Modified values, the field will then ask about the metadata to focus on: Category, Stage, Published status. The selected metadata will provide a second select control populated dynamically with the deployment's relevant values, for the user to select (e.g. Category > Safe Location).

For the "Added to a Set" value, the field will then ask you to define which Set, using a dynamically-populated select control.

The "Then..." field is intended to be an interactive sequence of select controls and, conditionally, text inputs that form a logical statement about what the alert's task is, once triggered. It first asks what type of communication should be sent: Email or SMS.

If "Email" is selected, a second select control is appended, asking whether the intended recipient is a user group within the deployment or specified address(es). If "User group" is selected, a third select control is appended, dynamically populated with the deployment's available user groups. If "Email address(es)" is selected, a text input is appended for the user to specify the recipient(s), comma separated.

This spec is intentionally simple and small in scope. We want to avoid Alerts becoming a feature that sneaks into every corner of the app's functionality, in the way "Bookmark" and "Add to Set" already do. It's designed to be an advanced feature, used by administrators with very intentional, specific direction.

Thanks for your feedback, @rjmackay.

ushbot commented 9 years ago

Comment by @middle8media on 2015-02-25 09:56:53:

Great work!!!

ushbot commented 9 years ago

Comment by @rjmackay on 2015-02-25 09:57:33:

So I think what you're describing would work well for Admins.. but Alerts in V2 is focus much more on public / basic members. In V3 we hoped to hit both those user groups. There are probably 2 different use cases

Comments on what you've suggested

I don't think Alerts needs to be an advanced feature with a full If..Then type builder. I think it could be as simple as 'Subscribe to this set'..

Also worth noting that in the 3 use cases I mentioned, its useful to be able to view the full set of matching posts in the web UI.. not so creating a set for that alert could be a bonus.

ushbot commented 9 years ago

Comment by @brianherbert on 2015-02-25 10:04:27:

+1 on "subscribe to this set" as a simple alerting mechanism.

ushbot commented 9 years ago

Comment by kinnla on 2015-02-27 11:38:08:

Hi, my name is Till, from the Nepal Monitor Project and Daniels advisor at Free University of Berlin. The Nepal Monitor uses alerts a lot, especially SMS alerts, so I am interested in how the feature will implemented. If a user subscribes to an alert, can she manage the alert herself? For example, if her phone number changes. Or will the "Alert management" be an admin only feature? Best regards, Till

ushbot commented 9 years ago

Comment by @rjmackay on 2015-02-27 13:05:58:

@kinnla I know @brandonrosage and @sophshep are doing some more thinking on this. But I think if a user can sign themselves up for an alert they have to be able to manage their alerts somewhere too.

ushbot commented 9 years ago

Comment by Nhorning on 2015-02-27 23:55:52:

Hi @rjmackay and All,

At the NepalMonitor.org Project, were currently using a version of Ushahid 2.7 customized by a local developer, Himalayan Techies.

At this point we found it would likely be more efficient to try and incorporate our feature requests into the upcoming release of Ushahidi 3.0 than to submit them to our local developer. I have to admit I'm not really up on how to log issues on Phabricator, so I'm going to put them in here, and if there is a more specific way I can enter them into the system please let me know.

| Feature| Discription | Comment | |Daily Alert Digest| A daily digest function for email alerts | @nhorning: This should be the highest priority. It's one of our biggest pain points. | | |Have a separate entry field for the sms alert and not continue with the beginning of the report in the sms | @nhorning: Needs to have a configure check-box. Many users may want to retain automatic functionality | | | Have a function where we can send messages to all subscribers of a certain area without uploading a report. | @Kinnla: do you mean an "invisible" report (uploaded to the dateabase but not displayed on the website)? FH: More like using as a mailing list, independent of reports on the database| |Ushahidi mobile app| My dream: Let subscribers sign up with Ushahidi app and get there alerts by push function on the mobile| | |Alert management menu | Alert subscribers can manage their subscriptions (delete, edit, update phone number, update email address) | FH: I like this idea. @nhorning: This of course needs to also be able to modified from the backend without going into the database. If possible, there should be a backend map of alert subscriptions, as well as an easy way to categorize alerts and view a list of which alerts have been sent to which subscription | |Multi language support for reports | Several language versions of a report can be submitted. Alert subscribes can select their preferences for one or several languages | |

ushbot commented 9 years ago

Comment by @brandonrosage on 2015-02-28 12:25:10:

@rjmackay I made a series of revisions to the Design Framework today that redefine how "Alerts" work, based on your fantastic feedback.

First, they aren't called "Alerts." They're called "Notifications," and they can be turned on for any piece of content within the deployment that you can "Bookmark." That includes Sets and individual Posts.

As you can see in [[ https://docs.google.com/a/ushahidi.com/document/d/1JnfDERRFBV6suR0lglf76Fu9uVnfhs0PjwiGrtWrHDU/edit#heading=h.ll54n3tqk33w | the Sets section of the Design Framework ]], upon selecting "Bookmark," the trigger's label changes to "Bookmarked" and becomes a dropdown control that allows you additionally "Get Notifications" or "Unbookmark."

So, in effect, Notifications are a user-specific option for any content they choose to Bookmark. It's an enhancement to Bookmarking, rather than an entirely independent feature. I think by packaging it within "Bookmark," we avoid the pitfalls of tacking yet another action onto every Post and Set, while also pairing it with the action it's most closely related to.

Also, part of [[ https://docs.google.com/a/ushahidi.com/document/d/1JnfDERRFBV6suR0lglf76Fu9uVnfhs0PjwiGrtWrHDU/edit#heading=h.ucawq0ytwecm | each user's "Account Settings" ]] is the user's info, like email address and (optionally) phone number. Account Settings also includes a "Notifications" view, where they can choose which of those channels they'd like to use to receive notifications, and see a summary of the content (e.g. Posts, Sets) they've already opted to "Get Notifications" for.

The only use case this doesn't yet address is @nhorning's "daily digest." I think the first question to answer before solving that is: What do you need that daily digest to tell you? What sort of content or numbers would be communicated in that notification?

Thank you, @nhorning, for your insight on this.

ushbot commented 9 years ago

Comment by Nhorning on 2015-02-28 14:04:02:

Hi @brandonrosage,

Our project is based in large-part on democratizing access to Human Rights and Security information. We Do a lot of media monitoring, as well as aggregation of reports from Human Rights organizations and Sit-Reps from international organizations.

Use Case: Someone signs up to receive Alert e-mails from our deployment. They want to receive nation wide reports, from all our categories, but that's 50 - 80 e-mails a week. Or, they want to sign up for national reports of VAW - That's about 30 e-mails a week.

They click a box to turn the e-mails into a digest, so their contents are aggregated, and sent periodically instead of at the time we map the report. They are able to set how frequently the receive the digest (Daily, Weekly, Monthly, hour intervals if possible)

Now they they receive one email a day with 7 or so reports rather than 7 e-mails a day. They read these e-mail's as part of their daily routine to improve their situational awareness.

ushbot commented 9 years ago

Comment by Nhorning on 2015-02-28 14:11:05:

Also @brandonrosage,

Based on the Design Framework you have, it would be good to create settings such that someone can aggregate multiple sets into a periodic e-mail, But then still have other sets that send them Alerts immediately.

It would also be very good to have some default settings that can be configured by the deployment admins, In order to make it easy for non-technical people to easily sign up for an advertised service (Ie, Daily Digests of Security incidents, VAW incidents etc.)

ushbot commented 9 years ago

Comment by @rjmackay on 2015-03-02 09:44:50:

| Feature| Discription | Comment | |Daily Alert Digest| A daily digest function for email alerts | @nhorning: This should be the highest priority. It's one of our biggest pain points. |

This will probably happen later as a follow up to this task.

| |Have a separate entry field for the sms alert and not continue with the beginning of the report in the sms | @nhorning: Needs to have a configure check-box. Many users may want to retain automatic functionality |

not sure I really understand this one?

| | Have a function where we can send messages to all subscribers of a certain area without uploading a report. | @Kinnla: do you mean an "invisible" report (uploaded to the dateabase but not displayed on the website)? FH: More like using as a mailing list, independent of reports on the database|

I think this is covered by T655

|Ushahidi mobile app| My dream: Let subscribers sign up with Ushahidi app and get there alerts by push function on the mobile| |

I think this is a little way of being doable for us. But something @eyedol could keep in mind once alerts exists in the core.

|Alert management menu | Alert subscribers can manage their subscriptions (delete, edit, update phone number, update email address) | FH: I like this idea. @nhorning: This of course needs to also be able to modified from the backend without going into the database. If possible, there should be a backend map of alert subscriptions, as well as an easy way to categorize alerts and view a list of which alerts have been sent to which subscription |

I definitely think the basic version of this should be part of this ticket. |Multi language support for reports | Several language versions of a report can be submitted. Alert subscribes can select their preferences for one or several languages | |

Probably T1112

If you want to drop any lists like this in Phab again.. you can try creating a task here: https://phabricator.ushahidi.com/maniphest/task/create/ If you can't get the projects etc right just make sure you assign to me and I'll triage it :)

ushbot commented 9 years ago

Comment by @rjmackay on 2015-03-02 09:55:08:

@brandonrosage Notifications looks great.. and makes much more sense than 'Alerts' :)

! In T1076#22206, @brandonrosage wrote: As you can see in [[ https://docs.google.com/a/ushahidi.com/document/d/1JnfDERRFBV6suR0lglf76Fu9uVnfhs0PjwiGrtWrHDU/edit#heading=h.ll54n3tqk33w | the Sets section of the Design Framework ]], upon selecting "Bookmark," the trigger's label changes to "Bookmarked" and becomes a dropdown control that allows you additionally "Get Notifications" or "Unbookmark."

So, in effect, Notifications are a user-specific option for any content they choose to Bookmark. It's an enhancement to Bookmarking, rather than an entirely independent feature. I think by packaging it within "Bookmark," we avoid the pitfalls of tacking yet another action onto every Post and Set, while also pairing it with the action it's most closely related to.

My only concern with putting notifications under bookmarks is that it looses its discover-ability. Particularly if I want notifications for my own set .. why would I bookmark my own set? (its already under My Sets) right? Whats the flow look like for getting notifications on an arbitrary search? ie.

  1. Go to Views
  2. filter by category/time/location/etc
  3. Select 'Create a smart set with these filter'
  4. Bookmark the set and choose notifications .. or can I bookmark the search directly?

That said, once you know Notifications exists (and is under bookmarks) it looks perfect.

For an MVP of notifications I'd like to just tackle notifications of Sets.. adding notifications on individual posts, etc later. That way we replicate what could be done in 2.x before tackling further notifications. Does that sound sane? or likely to just complicate the UI in the interrim?

ushbot commented 9 years ago

Comment by Nhorning on 2015-03-02 14:26:11:

@rjmackey

That's an important point. We already have quite a few people who subscribe themselves to alerts on our deployment, after they just stumble across the website. However, when they subscribe themselves, they usually miss 2 of the steps and end up subscribing to the wrong area.

A frontend "get alerts" interface like 2.7, but different in that it walks you through the process of picking the type of information you want and the area you want it for would be ideal.

ushbot commented 9 years ago

Comment by @brandonrosage on 2015-03-03 05:23:03:

@nhorning What specific content would be included in the digest? For example, if the user wanted a digest of the activity on three different Sets at the end of each week:

I'd like to make sure we know exactly what we mean when we say "digest."

ushbot commented 9 years ago

Comment by @rjmackay on 2015-03-03 10:02:27:

@brandonrosage my view of it is that it should similar to when you have a digest from a mailing list: it collects everything you would have received in multiple emails, but sends just 1.

In our case:

For your specific example:

@nhorning does that cover your needs? are there other things you would include? things I've suggested that you don't need?

ushbot commented 9 years ago

Comment by Nhorning on 2015-03-03 15:24:08:

@rjmackay,

I think you hit the nail on the head. We just want everything someone would have received as an alert aggregated into one e-mail. If they could be grouped by the subscribed category in the e-mail, all the better.

Also, I noticed you didn't understand one of our feature requests...

Currently, our sms alerts are composed of the 1st 140 or so characters of the reports we approve. That means that in order the alerts we send to make sense, we have to write a separate 140 characters in transliterated Nepali at the top of the report.

If it is to long, the whole sentence doesn't get sent, and the sms subscribers think they missed something. If it's too short, the first few words of English from the rest of the report get pulled in and the subscribers also think they've missed something. So, our mapping coordinator would like a way to enter the sms alert into a separate field so he can determine exactly what gets sent out.

ushbot commented 9 years ago

Comment by Nhorning on 2015-03-11 19:33:29:

Hi there. Just a quick question. Does the "sets" and therefore notifications/alerts feature include the ability to specifically exclude a category? This could be particularly useful for some of our large institutional subscribers who only want to receive say... gender based violence reports that are NOT from their own organization.

ushbot commented 9 years ago

Comment by @rjmackay on 2015-03-12 09:14:37:

@nhorning. at the moment I think it'll probably allow whatever filters we have on the posts list / map pages. That doesn't allow excluding categories yet. Right now if you select multiple categories it loads all posts with any of those categories.

Nhorning commented 9 years ago

Hi All,

In Quakemap.org we created a "notification" system separate from the alert system, which would notify commenters on a report to subsequent comments via e-mail or SMS, and also notify the number listed as the contact on the ground for the report. It looks like this notification system might be configurable to fulfill that criteria, but I wanted to check to be sure.

rjmackay commented 9 years ago

@sophshep I'm not sure exactly how we should translate this: https://docs.google.com/document/d/1JnfDERRFBV6suR0lglf76Fu9uVnfhs0PjwiGrtWrHDU/edit#heading=h.roqpx5jsjbhx into the client.. Jason's done some good work so far.

jasonmule commented 9 years ago

So, I am currently reusing the settings-list pattern with drop downs for adding and editing contacts in the meantime. notifications

Nhorning commented 9 years ago

Robbie Closed this. Does that mean it was done?

Neil Horning Nepal Digital Humanitarian Coordinator Project Committee | NepalMonitor.org http://www.nepalmonitor.org/ Coordination Team | Quakemap.org http://quakemap.org/ Mobile: +977 984-959-0609 Skype: nhorning

The Digital Humanitarian Coordinator role is an initiative of the digital humanitarian community, supported by UNHCR. Partners include DHN, Kathmandu Living Labs, Humanity Road, Standby Task Force, ACAPS, The World Bank, and OCHA.

On 09/30/2015 04:37 PM, Robbie Mackay wrote:

Closed #519 https://github.com/ushahidi/platform/issues/519.

— Reply to this email directly or view it on GitHub https://github.com/ushahidi/platform/issues/519#event-422926998.Web Bug from https://github.com/notifications/beacon/AByRNQHoGiH0UAkKlZD4AWPYk5Jls73Wks5o27ZzgaJpZM4Fwe5b.gif

rjmackay commented 9 years ago

Actually I just realised this only work for collections right now. I'll reopen and get Jason to detail whats still needs to be done. Maybe split this out into a collection of smaller issues? @jasonmule

jasonmule commented 9 years ago

It's mainly getting this to work the same way for saved searches for now.

rjmackay commented 9 years ago

@jasonmule can you give this task a size?

rjmackay commented 9 years ago

@jasonmule is this finished now or is there UI work for saved searches?

jasonmule commented 9 years ago

It's done. UI work was merged as well.