Drumbeat/Batucada/Future: Difference between revisions
Jump to navigation
Jump to search
No edit summary |
|||
| Line 1: | Line 1: | ||
= January 2011 = | |||
== Design / Content == | |||
* How-to screencasts explaining how to use features of the site. | |||
== Project Pages == | |||
* Project donation pages for featured projects | |||
* Basic searching / filtering for projects (by tags, name, etc) | |||
== User Dashboard == | |||
* Recommendations engine (suggested projects, etc) | |||
= Q1 2011 = | |||
== Design / Content == | |||
* General improvements on UX / Stories | |||
== User Profiles == | |||
* Experiment with idea of badges for certain accomplishments. | |||
== Activity Streams / Dashboard / Project Pages == | |||
* Allow users to comment on or reply to activities, replies will be threaded. | |||
* Allow easier "sharing" of content. Preview content when syndicating blog posts, videos, etc. | |||
= Q2 2011 = | |||
== Federated Social Web == | |||
* Drumbeat user accounts should be valid WebFinger identifiers (i.e. paul@drumbeat.org) and should resolve to an XRD with information about services used by the user. | |||
* Drumbeat should implement [http://ostatus.org OStatus] in order to support cross site follows / messaging. | |||
* We should aim to pass [http://federatedsocialweb.net/wiki/SWAT0 SWAT0]. The first "Social web acid test". | |||
== Integration with CRM == | == Integration with CRM == | ||
| Line 15: | Line 47: | ||
In order to make requests to the CRM API in a way that does not affect the performance of the site (and hence the user experience), the integration will need to be asynchronous. We could use Django post_save signals on the models to send messages to a message queue. Another application could then consume tasks from the message queue and do the necessary work on the CRM side. | In order to make requests to the CRM API in a way that does not affect the performance of the site (and hence the user experience), the integration will need to be asynchronous. We could use Django post_save signals on the models to send messages to a message queue. Another application could then consume tasks from the message queue and do the necessary work on the CRM side. | ||
Latest revision as of 21:14, 28 October 2010
January 2011
Design / Content
- How-to screencasts explaining how to use features of the site.
Project Pages
- Project donation pages for featured projects
- Basic searching / filtering for projects (by tags, name, etc)
User Dashboard
- Recommendations engine (suggested projects, etc)
Q1 2011
Design / Content
- General improvements on UX / Stories
User Profiles
- Experiment with idea of badges for certain accomplishments.
Activity Streams / Dashboard / Project Pages
- Allow users to comment on or reply to activities, replies will be threaded.
- Allow easier "sharing" of content. Preview content when syndicating blog posts, videos, etc.
Q2 2011
Federated Social Web
- Drumbeat user accounts should be valid WebFinger identifiers (i.e. paul@drumbeat.org) and should resolve to an XRD with information about services used by the user.
- Drumbeat should implement OStatus in order to support cross site follows / messaging.
- We should aim to pass SWAT0. The first "Social web acid test".
Integration with CRM
Notes
- Whatever CRM we go with must have a Web API.
- Events tracked in CRM:
- User creation, deletion
- Event creation, deletion
- Project creation, deletion
- Updates to major fields in these models ("major is tbd")
- User joins a Project
- User RSVPs to an Event
Possible Architecture
In order to make requests to the CRM API in a way that does not affect the performance of the site (and hence the user experience), the integration will need to be asynchronous. We could use Django post_save signals on the models to send messages to a message queue. Another application could then consume tasks from the message queue and do the necessary work on the CRM side.