[Sugar-devel] Journal --- Sugar-Developers meeting REMINDER (2 July, 2009 - 14.00 (UTC)) --- irc.freenode.net, #sugar-meeting

[Eben Eliason]

On Fri, Jul 3, 2009 at 11:19 PM, Gary C Martin<gary at garycmartin.com> wrote:
>
> On 4 Jul 2009, at 03:13, Eben Eliason wrote:
>>
>> On Fri, Jul 3, 2009 at 7:25 PM, Gary C Martin<gary at garycmartin.com> wrote:
>>>>
>>>> Devils advocate here, so just because someone was late to the realtime
>>>> party, they don't get to download an otherwise openly published piece
>>>> of work that could be re-published at any time by any of the
>>>> temporally lucky contributors? Downloading a Journal entry would not
>>
>> I think you misunderstand me, as I think I'm arguing exactly the
>> opposite. I wouldn't want to deprive people the ability to download
>> finished works because the sharer doesn't want to open the document up
>> for public collaboration. The distinction is important, so that it's
>> possible to share things with others without having to make my own
>> documents open to collaboration.
>
> OK, yes thanks, I see this issue now: I might want folks to be able to
> download an entry, but I might well want to work on it privately, by myself.

You said it so much more succinctly that I did!

>>>> allow you in anyway to edit the remote users copy, you'd just get a
>>>> snapshot downloaded to your Journal as if they had performed an
>>>> equivalent "Send to" function.
>>
>> Exactly. If you conflate public vs. private states for documents with
>> the collaboration sharing scope, every public document would also be
>> open for public collaboration, which might not be desired, and might
>> discourage people from sharing their output.
>
> Yep.
>
>>> Replying to myself, always a bad sign ;-)
>>>
>>> Use case: "Darn, I missed the weekly project chat meeting, AGAIN... Oooh,
>>> Bob is still online, let me see if I can download the meeting activity
>>> entry."
>>
>> This might not be the best example, since by definition the chat
>> meeting is an open collaboration, with a "neighborhood" (for example)
>> sharing scope.
>
> FWIW: I was assuming all chat participants has stopped the Activity (so not
> available in the neighbourhood), but that Bob (and his buddy icon) were
> still online.

Yup, gotcha. My point was that, if the activity were collaboratively
public already anyway, it doesn't hit the snag I was trying to bring
up above.

>>> Misc supporting argument: If you default to Journal sharing OFF and make
>>> it
>>> a new separate manual public sharing UI tick box/setting (required for
>>
>> I'm not necessarily stating that it should be off by default
>> (everything private). I'm simply arguing that it should be independent
>> of the collaboration scope. What may make sense (maybe this is what
>> you meant?) is to default all documents which become shared with the
>> neighborhood to public, while all others would default to private.
>
> Yes that's what I was trying to say :-) default all documents which become
> shared with the neighborhood to public :-) Though I'd missed your point that
> we would need some other UI in addition to this default, to allow someone to
> share an entry without collaboration.
>
> Using the current Activity "Share with:" UI would indeed likely conflate
> collaboration with sharing, though it could still be worth investigating.

We can explore it, though I think putting a hard separation between
them might be the best way to indicate their distinctness, since the
distinction might not be obvious with a label, or an icon, in the UI
(assuming the controls were side by side).

My thought process here was that the activity UI is the place where
active collaboration happens, so that's a great place to allow one to
change the collaboration sharing settings. The Journal is the place
where the output goes, and the place that I "show people" when they
choose to view my Journal. This seems like a logical place to decide
which entries are public and which are private. It's possible that the
separation of these will be the clearest way to indicate, without need
for much teaching, the difference.

On a visual note, perhaps we can come up with some unique icon for
"shared Journal object", and then stamp that icon on the front cover
of the Journal activity icon that we show when viewing someone else's
Journal. This would help reinforce the idea that the activity only
shows Journal entries which have that icon toggled on.

> Something along the lines of 3 modes "Private", "Collaborate with
> Neighbourhood", "Public Journal entry" (where "Collaborate with
> Neighbourhood" was collaborative and a public Journal entry).

I think combining them in one popup menu is asking for confusion...

>> PS. I think we need to come up with some better terminology to
>> distinguish between collaboration sharing and journal sharing. That
>> would make this much easier to talk about.
>
> You're not kidding there :-)

should we call both "sharing", but differentiate it with a modifier,
like "collaboration" vs. "document", or maybe "activity" vs. "object".
This latter might be the best I've thought of so far. "activity
sharing" is real-time collaboration; "object-sharing" is public
Journal entries, the output. Thoughts? Better suggestions?

Eben


> Regards,
> --Gary
>
>