*Update* - 6/1/2009 - this feature is fully sponsored and under development

Esitmate for CrowdSourcing consideration. If you would like to be a Project Sponsor please reply to this thread and let us know your requirements for this feature.

• Name: UserProfile StoryFeed Type Filtering
• Description:  Currently a feed shows all types by RelatedID. This feature will allow an Admin to set a feed to only show Status Updates on a tab or it can allow the user to filter their own profile feed view
• Proposed Deliverables: A new setting to allow filtering on one or more types. There would also be a setting to allow the user to change the type to make it more flexible.
• References: Facebook Status Updates filter, Filter on profile stories. Bebo story filtering
• Consider: Should the user filter pref be persisted across sessions? Much easier without perm. persisiting (no database table). Could use the core profile preference table to store it (like Survey Module) or possible just a cookie.

Estimate based on above functionality: 6 hours

Cost: $50 * 6 hours  = $300

Individual Project Sponsor Amount: 3 people at $100 or 2 people at $150 each.

 

	Crowd	Amount
Sponsored	2	$300
Still Needed	0	$0

 

If you would like to sponsor this project please reply to this thead and discuss your requirements. Does the above solution meet your needs? Do you have any unique use-cases that need to be considered?

Steve J. wrote I'm in for this - I will pay for half. Yes, I think persisting should be included - it will make for a better user experience! If you can have some way to use different "looks" for each it would be a plus. i.e - if you're only listing the statuses, you might want the picture to appear or be larger, along with the type.  I haven't really thought about how to accomplish that, but it would be plus since you could give different twists with each tab.

Ok, I will use the core personalisation tables to store their preference.

I see what you saying regarding different templates for each filter, but this would significantly increase development time - you'd need DB tables to store each template against each type or filter. There may be a simpler hack in the Storyfeed module where you can output the StoryFeed type in the CSS of an action - e.g. Appent the type onto the StoryFeed CSS (for example - storyfeedGroupAdd) and then you could put different CSS for each type of action. I have not looked into this but it may be possible currently).

Ok, here is the spec in more detail:

1. All possible types will have to be identified in a table as they will need to be listed and referenced (There won’t be a UI for this in this version and that would require new screens to edit the data).
2. There will be a new setting for setting the Filter Type (multiple choice, with an ALL (default).
3. There will be another new setting for the admin to chose if the user can change the filter on this instance of the storyfeed. So for example, if you made a tab called “Status Updates” you would probably set this to false so it can’t be change, whereas the view on the home page would be changeable by the user).
4. I’ll persist the User Choice in a cookie as this solves the problem for anonymous and logged on users (the cookie can last indefinitely). I think this is the easiest (and therefore cheapest) solution and will satisfy 90% of the cases.

Paging would be good but this would add on another 2 hours to the original quote (that's bog-standard paging with no user preferences for page size etc). I guess I could use the same approach as the Private Profile and have a "StoryFeed PageSize" in the user preferences but it would be the same value for all StoryFeed displays.