• Project Info / Latest activity page

last modified November 30, 2007 by rpenate

Project Latest Activity

Attachments

20071017 Summary Mockup

20071130 Account News Feed

20071129 Account News Feed with Invitations  

Open Questions

  • What information do we want displayed for each "latest update"?
  • Do we want to preserve "latest update" history forever or does it expire?
  • Should we display latest updates to content with non-standard read permissions?
  • What types of updates, and to what sorts of things, should we have initially? In the long term?

Updates

None to speak of.

Summary

Provide a summary of most recent contentful changes to a project for users to see at-a-glance what's been updated recently.

Mission-driven objectives

  • Encourage more user activity by highlighting updated content
  • Give users reasons to keep coming back by letting them quickly see what's new

User stories

  • Luke sees that a project has recently been updated and is curious about it. He navigates to the project to see its new updates, but since he hasn't memorized every detail of all of that project's content, he has no easy way of figuring out where the update was, what the update was, and whether he cares. Luke gets frustrated and doesn't pay attention to the project any more. But he'd really prefer to navigate to the project and easily see a list of the most recent updates to the project.
  • Lindsey is managing a project on OpenPlans. She thinks her wiki page is kind of boring, and would rather have her Project Info / Latest Updates page be the front page of her project. She sets this to be so. Now she has a more dynamic homepage. -ng
    • Wait, really? This seems entirely outside the scope of both this iteration and this project. -egj
    • Motherfucking Kupu lost my comments. So my short, annoyed recreation of those comments: yes, this is a transcluder feature, and that feature should fall out fairly effortlessly from a normal implementation.

Technical & functional objectives (more like questions)

  • Where are these updates published? On a separate full document at /myproject/recent? In an HTML chunk which can be included into other documents? In an Atom feed that can be subscribed to? (How much overlap is there between this and the notifier?) How is this information actually going to be accessed?
    • I think it should be /myproject/recent, and it should be a full app/HTML/etc. We can transclude it from there if we want. We can't put the trancluder statements in existing projects, so we need this full interface; and anyway, that's not much different than making transcludable content, since it's just simple HTML either way. It might be valuable to make it more Ajaxy than you might be initially inclined, as that would be useful for transclusion. -- ianb
  • Most project content (wiki pages, file attachments, mailing lists) is uniformly read-protected across a project: if you can view some content in a project, you can view all of it, and vice versa. But tasklists don't obey this rule -- you can have a tasklist that's invisible to some users even if they can view the project and its other content. So there will have to be some way of checking security per-item as well as per-user so that we're not publishing information about updates to content that a user shouldn't be able to see at all. Ideally, this shouldn't be prohibitively inefficient; ideally, this won't be duplicating the existing security built into the apps that have content -- it would be a big pain to keep the permissions up to date, and I really hate security and have no interest in designing a security system.
    • Alternatively we could get rid of all privacy settings for reading content, but I don't think that's actually a very good idea. Oh, but it would make a heck of a lot of things a heck of a lot easier.
    • Maybe it would be slightly easier if you just maintain the stats twice, once for public and once for private data. Or maybe just annoying. And... I don't feel like this has to be that hard. -- ianb
      • Actually, it's worth asking UI whether we even want to be maintaining stats about non-public data. I know there's been a trend towards only displaying public data in summaries, at least until/unless we can come up with some good way to explicitly but unobtrusively mark private data as such so people don't freak out.
  • Do we store updates forever, or do we delete them after they've "expired"?
    • This isn't a damn RCS, it's just a news feed, so why keep them around?
    • Does it matter?
    • If we let things expire, it also lets us be lazy about stuff like lost updates, initial sync, etc. If everything will eventually expire, then none of the pieces seem quite so essential. -- ianb


Long-range summary

  • Add "updated" events to other applications -- wordpress, tasktracker, etc. Short-term, make sure nothing is designed to make tasktracker integration impossible. Longer-term, do it.


Online resources / who to talk to / current features this is related to

Cabochon, CabochonServer, CabochonClient -- to send and receive events between applications about updates to a project (David)
Statistician -- this may be the thing that receives those update events and publishes them, or it might not; I'm not really sure (David)

How we plan to do this

Phase I: setup, caution, proof of concept
Phase II: think about security, figure out what behavior and UI we actually want
Phase III: attempt at implementation

Security

Each "update" item has an attribute associated with it: "this is where you go to see if you can view this item." This is either the "canonical" URI of the actual content that the update is referring to, or the URI of some other thing that is guaranteed to have identical security as the update. So a tasklist update will have this attribute point to the tasklist itself; a wikipage update will have this attribute point to the project that it belongs to, since project viewability is identical to viewability of the wikipage. Items can then be grouped according to this attribute and security can then be checked for a whole batch simultaneously (I suppose by sending a HEAD request to the URI in that attribute and seeing if it comes back 200 or 302/401/403)

Pro:
  • This is really easy
  • The recent-updates app doesn't need to know anything about security
    • (egj doesn't need to know anything about security)
  • This should work very well for batches of content which are grouped according to security permissions, like the majority of recent updates to a project
Con:
  • This will not work very well for batches of content which aren't grouped according to security permissions
    • A bunch of tasklists
      • On the other hand, screw tasklists?
    • A random slice of content from the site (sitewide recent updates, recent updates to things I happen to be interested in, recent updates by Chris [unless I'm Chris.. hmm], etc)
      • On the other hand, YAGNI?
    • It would be staggeringly inefficient and the very idea scares me! If events can group their security containers (e.g., 10 tasks all have the same container, and that container is checked just once and cached) then maybe it would be reasonable. But it still scares me that by hitting the stats you could be generating dozens of sub-HTTP requests. -- ianb
      • Er... yes, of course events would group their security containers, that's the whole point of having the containers. Also, the use case I'm addressing here is "recent updates to a project", which (approximately) means that ALL events can be grouped into a single container, so we're generating one subrequest. If this becomes unmanageable or if the uses for this app expand to some of the other things that are being discussed on this page, then it can be rewritten midstream, but I can't really think of any reason not to start here. -- egj
Okay, I've skimmed over the code a bit. This is, indeed, really easy: the events that are emitted contain an extra parameter like "security_container_uri". The event subscriber (Statistician) takes this and puts it in the newly-created row of the Event table. It might be worth storing them as foreign keys into a separate SecurityContainer table (if the HEAD request to the SecurityContainer URI fails permanently, like a 301 or 404, we probably want to update or delete all associated Events immediately) or it might not.

What if content is deleted?

  • Does this show up in the updates? If so, what URI can we point to in order to determine whether the "deletion update" is viewable?
    • This is a fairly fundamental problem: the Events really want to assume that they're referring to things that are, well, referable.
    • I think events really have to refer to other things too. E.g., if there's an update, it would be nice if the event gave context about what things were like before the update. But the "before" might not be addressable. (Though it could be.) Giving the title of the deleted page in the event seems only reasonable. -- ianb
    • I think there is a case around the idea of "open plans" to have events archived. Not sure we have a use for it yet however so we could start by only making the latest month of activity available to users. --ma
  • What happens to existing Events when their referenced content is deleted? Do those Events get deleted now that they no longer refer to something referable?
    • Seems to me that the simplest way to handle it would be to not store deletions in the list of Events (so we don't have to worry about keeping a URI around for security checking of deleted content) and to delete updates stored about deleted content (so when we do the security check, a 404 response tells us to delete this update as well as not publishing it (oh, wait, that's not necessarily true, because the security check isn't necessarily going to be checking on the object itself, drat -- so a 404 on the security check is sufficient, but not necessary, for deletion (so do we send a DeletionEvent to Statistician which is interpreted as "delete all Events associated with this content, and don't publish this Event"?))) --egj
    • The event should stay with some info that the content for it has been deleted --ma
But these are implementation-driven conclusions (and entirely naive ones at that) so I need to discuss it with UI.

Maybe like Vacuum there could be a way of purging events? Otherwise expiration mitigates the risk of exposing an embarrassing page. -- ianb / yes! --ma

Initial tasks // approximate iteration schedule

Phase I (through Monday or Tuesday)
  • install cabochon
  • install statistician
  • install cabochon event emitter into opencore (*)
  • emit some sort of "updated" event in opencore on content changes for statistician to subscribe to (*)
  • figure out what events actually look like (*)

Phase II (through Wednesday or Friday)

  • figure out if statistician is, in fact, the thing that produces "recent updates"
  • figure out how and where we want recent updates to be published
  • determine an initial set of things that will trigger an "updated" event (i think this should be small at first; it can be expanded later)
  • uh, security

Phase III (through end of iteration, at least)

  • publish events in statistician
  • make sure security works
  • integration
    • deliverance rule for wrapping page and/or add to existing page via transcluder
    • topnav menu link?

Mouna attempts to propose something and will answer the questions next


4 types of latest activity
  1. On the project
  2. On the user's section
  3. On my projects
  4. Home page of Openplans.org

We will focus on #1 for now.

Project Latest Activity

Updates, changes and deletes on the following content should be printed:
  • Wiki pages
    • Changes in content of an existing page (as tracked in the History of a page)
    • incl. Changes with attachements
    • incl. Changes with notes
    • Deleting of a page
    • Creation of a new page
  • Project preferences
    • Changes in any of the field including mission statement, long name, security and featurlets
  • Team
    • Addition of a new member --invitations should not be tracked i think at this stage
    • Removal of a member
    • Change of role of a member
  • Task tracker (at the task list level)
    • New list created
    • Some activity on an existing list
      • Some focus on the completion of a task and the addition of new task
      • The rest of the data can be combined into "general activity" on a task
    • Deleting of a list
  • Mailing lists (at the thread level)
    • New mailing list created
    • Existing mailing list deleted
    • Preferences of an existing mailing list changed
    • Some activity at the thread level (new messages, new threads, new replies)

FEATURES
  • Ability to filter the latest activity by date:
    • View latest for past hour / today / past 2 days / past week / past month.
  • Content would be bundled according to the view selected, showing each item only once with a summary of all activity on this thread: one wiki page, one task list, one mailing list thread
  • Ability for project admins to delete a specific feed entry from the latest updates --this might require a special view for project admins where they would see the full feed of each item in order and they can delete them individually. This could be a special view called "view latest: all details"
Interface layouts to follow -- as soon as we have an approved final list of features.