Standardized 'Feed'

[kylegracey]

Hey guys, I REALLY think we need to start making a major push for a standardized feed of every action on Imua. I think the expectations history @neelbhat88 is a great example of how useful a history feed can be. I know it's a daunting task, and i'm sure it will take a while to get it right. But I feel like the longer we wait, and the more features we add, the harder it's going to get to pull everything together.

I obviously don't know everything that's involved from the back-end, but here's how I kind of envision the process of creating this thing:

Start by building a firehose of EVERYTHING happens related to whatever user is logged in. We could give it it's own page (#/feed/{{user.id}}?) and just have a list of every action that happens from the big 3 (tasks, progress, expectations) related to that user. This view wouldn't be exposed to them.

Once we have the simple firehose, we can start giving different weights to different actions. Categorizing them, etc.

Once we have a standardized firehose... it seems like it should be easy to filter down what it shows. So if we then wanted to add a 'history' feed on an individual tasks page, we could say 'Show the history of all actions related to {{task.id}} by/on {{user.id}}', then everything's populated automatically.

There are so many ideas and features that could be built off the structure of this feed.

[ttapers]

All part of the master back-end-refactoring plan. We pretty much follow this firehose filtering model for the progress and org dashboard pages. Just keep on flowing with the vision - we'll make it happen :)

We should have a meeting, though, to sync up and identify the technical difficulties, so we can have an idea for what's possible by when.

On Sep 19, 2014, at 12:54 PM, Kyle Gracey notifications@github.com wrote:

Hey guys, I REALLY think we need to start making a major push for a standardized feed of every action on Imua. I think the expectations history @neelbhat88 is a great example of how useful a history feed can be. I know it's a daunting task, and i'm sure it will take a while to get it right. But I feel like the longer we wait, and the more features we add, the harder it's going to get to pull everything together.

I obviously don't know everything that's involved from the back-end, but here's how I kind of envision the process of creating this thing:

Start by building a firehose of EVERYTHING happens related to whatever user is logged in. We could give it it's own page (#/feed/{{user.id}}?) and just have a list of every action that happens from the big 3 (tasks, progress, expectations) related to that user. This view wouldn't be exposed to them.

Once we have the simple firehose, we can start giving different weights to different actions. Categorizing them, etc.

Once we have a standardized firehose... it seems like it should be easy to filter down what it shows. So if we then wanted to add a 'history' feed on an individual tasks page, we could say 'Show the history of all actions related to {{task.id}} by/on {{user.id}}', then everything's populated automatically.

There are so many ideas and features that could be built off the structure of this feed.

— Reply to this email directly or view it on GitHub.

[kylegracey]

You're the shit. Definitely down to meet up. Are you guys at 1871 today? Or if you want to meet up this weekend let me know.

[mcassid3]

Neel and I are at 1871. Pat/Jake working up north.

On Fri, Sep 19, 2014 at 3:53 PM, Kyle Gracey notifications@github.com wrote:

You're the shit. Definitely down to meet up. Are you guys at 1871 today? Or if you want to meet up this weekend let me know.

— Reply to this email directly or view it on GitHub https://github.com/neelbhat88/imuadev/issues/427#issuecomment-56234035.

Mark B. Cassidy Westside Children's Therapy http://westsidechildrenstherapy.com/ (815)-545-7182 | mcassid3@gmail.com

[ttapers]

Jake and I are actually on our way up to visit our buddy in MI for the weekend - will be back early Sunday.

On Sep 19, 2014, at 4:53 PM, Kyle Gracey notifications@github.com wrote:

You're the shit. Definitely down to meet up. Are you guys at 1871 today? Or if you want to meet up this weekend let me know.

— Reply to this email directly or view it on GitHub.

[ttapers]

For this feed, I presume it's pretty much based on the last time things were updated? And not just updated, but knowing exactly what happened: created, deleted, what fields were updated, when, by who, etc., correct? We're going to need some sort of constraints, or a starting point, because we can't store the entire history of every database table interaction in full detail. Can you give an example of the types of feed items that would pop up on someone's dashboard, and how they would interact with them? (The more extreme the better)

[neelbhat88]

I was thinking about notifications a little today and came across this: http://blog.meldium.com/home/2013/4/22/dont-spam-your-users-batch-notifications-in-rails

That article talks about using Mailboxer which allows our Models to send and receive messages. So when certain actions happen you can send a message to User (the instance of that user) and then later you can get all unread messages for a User which will include all the messages that were sent to User. I see this as more of an event-like architecture, where as the public activity is more of a subscriber-esqe architecture. With this, we essentially fire an event when something "notifiable" happens, and then our Notification engine just says "show me the latest events". With the activity, everything logs its own activity always, and then when we want to get notifications, the Notification engine goes out to all models keeping track of activity (anything it's "subscribed" to) and gets latest activity and then needs to figure out what to notify the user about.

Just something to think about as we approach doing the notifications. I think both would work for notifications, its just approaching it from two different sides.