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

[Andrés Ambrois]

On Friday 03 July 2009 11:18:24 pm Eben Eliason wrote:
> On Fri, Jul 3, 2009 at 9:52 PM, Andrés Ambrois<andresambrois at gmail.com> 
wrote:
> > On Friday 03 July 2009 02:29:56 pm Eben Eliason wrote:
> >> On Fri, Jul 3, 2009 at 10:42 AM, Gary C Martin<gary at garycmartin.com> 
wrote:
> >> > On 2 Jul 2009, at 14:47, Eben Eliason wrote:
> >> >> On Wed, Jul 1, 2009 at 1:42 PM, Aleksey Lim<alsroot at member.fsf.org>
> >
> > wrote:
> >> >>> But in that case we should provide possibility to mark objects that
> >> >>> can be shared(I guess sharing all local objects by default is not a
> >> >>> nice idea).
> >> >>
> >> >> Right. This would be essential. There's definitely some thought that
> >> >> needs to be done here.
> >> >>
> >> >> Scott had an interesting proposal which basically exposed the Journal
> >> >> (or some subset of it) as an RSS feed. This was really neat, because
> >> >> it meant we could build a UI for someone else's Journal in Sugar,
> >> >> populating it with that data, but also that these feeds could be
> >> >> shared globally, for anyone with an RSS reader to benefit from.
> >> >> That's a really powerful approach in my mind, and there is some
> >> >> starter code lying around as a proof of concept already!
> >> >
> >> > +1 to rss feed concept, makes life a lot easier in a heterogeneous
> >> > environment.
> >> >
> >> > I'm still catching up on email so apologies if this has been mentioned
> >> > already. But the UI for marking of entries as sharable does not
> >> > necessarily need to be another Journal user-interface addition** In
> >> > the simplest approach you could just extend the Activity "Share with:
> >> > my Neighbourhood" control to mark a Journal entry as part of the RRS
> >> > feed. Would need some
> >>
> >> The problem I see with this is that we're talking about two different
> >> kinds of sharing. Just because I want to make a picture I drew
> >> available for anyone to look at, or even make a "photocopy" of to
> >> scribble on, doesn't mean that I want to let them into a shared
> >> painting session so they can scribble on the original with me.
> >>
> >> This is the difference between sharing an activity with someone
> >> collaboratively, and sending them (a copy of) the resulting object.
> >>
> >> > thought on wording, do you add more levels of sharing? Or do you just
> >> > simplify the "Share with:" language language to "Private", "Share
> >> > with: Anyone".
> >> >
> >> > **though I would like entries to visually show their sharing state,
> >> > the buddy column hints at this but should be made explicit
> >>
> >> I do actually think that the Journal is the best place to expose this,
> >> especially since the way we plan to expose the feature in the UI is
> >> something like "view <my friend>'s Journal." I'm not sure exactly how
> >> or where that happens. Perhaps if we can abandon the checkbox for the
> >> multi-selection we can use that space for a public/private toggle of
> >> some kind.
> >
> > How about using special tags? A "Publish" tag seems reasonable for this,
> > and consistent with the fact that it could live in a publish directory an
> > HTTP server would serve.
>
> I think it's a good idea to store these states as metadata, but I also
> think that we need to expose the feature visually to highlight the
> capability and make it easier to manage. I wouldn't want kids to have
> to type "publish" into the correct field in order to share their work.

I wasn't suggesting that either. Scott's concepts [0] have a list of used tags 
for exploration, these special tags would be highlighted/prioritized somehow 
in this list. 

[0]http://wiki.laptop.org/go/Image:Journal2-working.png

>
> > I can also imagine a tags used for starred entries and other metadata (in
> > a general sense) used by sugar. This would make them searchable as well.
>
> Yup. I don't think this works yet, but the intent has always been to
> allow advanced search queries by specifying key:value pairs (as in
> gmail). In fact, all of the filters we support should have text
> equvalents, eg. "cat kind:image with:alice favorite:yes" (or similar).
>
> Eben
>
> >> Eben
> >> _______________________________________________
> >> Sugar-devel mailing list
> >> Sugar-devel at lists.sugarlabs.org
> >> http://lists.sugarlabs.org/listinfo/sugar-devel
> >
> > --
> >  -Andrés

-- 
  -Andrés