Just to reiterate from Kim's original posting: We are not proposing this as a new feature for Trial-3, just " some analysis of what is needed."
I am not married to the exact details* of the scenerio as described; simply I want to suggest that to have mechanisms for sharing activities and "objects" is the goal. From the user perspective, it is a clear, simple, and powerful concept. How it gets implemented under the hood and how it gets exposed in the UI is of course something that needs careful thought. -walter * for one, it isn't clear that in "object" sharing, the same activity that created an object need be the one that is used to open it when it is shared. It might be sufficient to place the object in the journal as the default action (or as a hover option) and use the Journal's existing resume mechanism as the arbitor. On 9/13/07, Zarro Boogs per Child <[EMAIL PROTECTED]> wrote: > #3431: Need to be able to share objects in the mesh, not just activities > -----------------------+---------------------------------------------------- > Reporter: kimquirk | Owner: marco > Type: defect | Status: new > Priority: high | Milestone: Trial-3 > Component: sugar | Version: > Resolution: | Keywords: > Verified: 0 | > -----------------------+---------------------------------------------------- > > Comment(by Eben): > > Replying to [comment:2 kimquirk]: > > * Design team. I talked with Eben and I think we need a way to > > differentiate activities and objects. Either using visual styling inside > > the mesh view or doing some sort of overlay (which I think would be > > cleaner but we would have to evaluate implementation if we go that way). > > Whatever method we choose, I think we need to indicate the distinction > between collaborations (activities) and objects (their result). I'm not > confident that anything we do in the current mesh view will be distinct > enough, since the implication for objects in that view is that XOs can > cluster around them eg. they are activities. Still, in order to get a > rough implementation of this working sooner than later, I would be content > to skip the overlay if we can come up with another way of making the > distinction. > > > Also Eben was thinking to a slightly different way to trigger share from > > the journal. Anyway we need a solid/agreed design before starting with > > the implementation. > > I think that we need to make this an action upon the object, rather than a > change to its state. To clarify, I mean that we shouldn't be "setting a > sharing scope" for the Journal entry, since that implies a more persistent > change. Instead, what we're really doing is posting a copy of the current > state of the object itself, much like tacking it to a bboard. However we > reveal this in the Journal, we should make it clear that it is tacking up > a snapshot, and not in any way permanently linking/publishing the file (It > should be a momentary button). > > -- > Ticket URL: <https://dev.laptop.org/ticket/3431#comment:3> > One Laptop Per Child <https://dev.laptop.org> > OLPC bug tracking system > -- Walter Bender One Laptop per Child http://laptop.org _______________________________________________ Devel mailing list [email protected] http://lists.laptop.org/listinfo/devel
