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

[Gary C Martin]

On 4 Jul 2009, at 03:18, 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 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).

This would solve one of my pet dislikes with the current solution.  
Once you've set up a Journal query, it's a pain to reset back to  
default. And the more filter options we provide the worse it would  
get. Ideally there would be a reset button – if selecting visual UI  
filter options added query text into the search field, the little (x)  
clear search field could be used to reset all options back to default  
in one click :-)

This would require the reverse to be true, so as you typed in the  
search field, any visual UI would need to update to match the query  
state. Cool, but quite a tough chunk of dev work.

Hmmm, actually that's not necessarily true. If you remove all visual  
UI feedback from the other toolbar controls, the search query string  
could be the feedback. Clicking, say the favourite star, would just  
inject favorite:yes into the query string, that would be your  
feedback... No other toolbar/button UI state would need to to be kept  
in sync (they all just inject query text).

Regards,
--Gary