I see this as a spectrum between sharing things almost-synchronously (nothing is 100% synchronous) and sharing them highly asynchronously (posting things you expect others halfway around the world to get in a few weeks). Another point on the spectrum is an Activity such as Meshboard, which centers around asynchronous collaboration and the persistance of a specialized 'bulletin board' view of postings that anyone has made that have not yet expired.
Right now the mesh view supports pretty synchronous activities - either you are actively doing something with someone, or you very recently were. Eben discusses sharing objects as "a snapshot, and not in any way permanently linking/publishing the file (It should be a momentary button)"... Also worth considering are meshboard sharing of objects with expiration date and more permanent sharing of objects. SJ On 9/14/07, Walter Bender <[EMAIL PROTECTED]> wrote: > 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 > _______________________________________________ Devel mailing list [email protected] http://lists.laptop.org/listinfo/devel
