Re: [Sugar-devel] Journal --- Sugar-Developers meeting REMINDER (2 July, 2009 - 14.00 (UTC)) --- irc.freenode.net, #sugar-meeting
On Mon, Jul 6, 2009 at 11:21 AM, Eben Eliason wrote: > I like these terms, but I don't think they define the split I'm > referring to. object-push and object-pull describe, "sending an object > to a friend" and "taking something from my friend's Journal" > respectively. Both of these types of sharing are "object-sharing" (the > recipient gets the resulting object, with a new tree_id). > > The more I think about it, I kind of like the "object-sharing" and > "activity-sharing" distinction, since in all of our high-level > outlines of Sugar we break the UI down into 3 core components: people, > activities, and objects. In this paradigm, we have: > > object-sharing: the transfer of objects from people to people, via > push (send to) or pull (view published journal) > activity-sharing: collaboration among two or more people within an > activity, acting on a shared object or objects > > Can someone phrase this more clearly? > > Eben > Collaboration is the term we have used in Sugar for co-editing. Google Documents use the term 'Collaborators'. Isn't the verb 'Collaborate'? --Fred ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Journal --- Sugar-Developers meeting REMINDER (2 July, 2009 - 14.00 (UTC)) --- irc.freenode.net, #sugar-meeting
I like these terms, but I don't think they define the split I'm referring to. object-push and object-pull describe, "sending an object to a friend" and "taking something from my friend's Journal" respectively. Both of these types of sharing are "object-sharing" (the recipient gets the resulting object, with a new tree_id). The more I think about it, I kind of like the "object-sharing" and "activity-sharing" distinction, since in all of our high-level outlines of Sugar we break the UI down into 3 core components: people, activities, and objects. In this paradigm, we have: object-sharing: the transfer of objects from people to people, via push (send to) or pull (view published journal) activity-sharing: collaboration among two or more people within an activity, acting on a shared object or objects Can someone phrase this more clearly? Eben On Mon, Jul 6, 2009 at 10:56 AM, Benjamin M. Schwartz wrote: > Eben Eliason wrote: >> 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. > > I've been using the terms "object push" and "object pull". > > --Ben > > ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Journal --- Sugar-Developers meeting REMINDER (2 July, 2009 - 14.00 (UTC)) --- irc.freenode.net, #sugar-meeting
Eben Eliason wrote: > 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. I've been using the terms "object push" and "object pull". --Ben signature.asc Description: OpenPGP digital signature ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Journal --- Sugar-Developers meeting REMINDER (2 July, 2009 - 14.00 (UTC)) --- irc.freenode.net, #sugar-meeting
On Sat, Jul 4, 2009 at 2:00 AM, Andrés Ambrois wrote: > On Saturday 04 July 2009 12:31:48 am Eben Eliason wrote: >> On Fri, Jul 3, 2009 at 11:19 PM, Gary C Martin wrote: >> > On 4 Jul 2009, at 03:13, Eben Eliason wrote: > > > >> >> 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? > > How about "publishing"? It seems to me the most concise way to express the > action of making content available to a wider audience. That's a pretty good suggestion. The only aspect of the problem this doesn't seem to cover nicely is the direct object transfer from child A to child B. This form of transfer is of the "object-sharing" kind, but I'm not sure publishing is the right term to cover it. I would be quite happy to describe all aspects of the Journal interface for making things public as publishing, though. Eben >> Eben >> >> > Regards, >> > --Gary >> >> ___ >> Sugar-devel mailing list >> Sugar-devel@lists.sugarlabs.org >> http://lists.sugarlabs.org/listinfo/sugar-devel > > -- > -Andrés > ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Journal --- Sugar-Developers meeting REMINDER (2 July, 2009 - 14.00 (UTC)) --- irc.freenode.net, #sugar-meeting
On Saturday 04 July 2009 12:31:48 am Eben Eliason wrote: > On Fri, Jul 3, 2009 at 11:19 PM, Gary C Martin wrote: > > On 4 Jul 2009, at 03:13, Eben Eliason wrote: > >> 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? How about "publishing"? It seems to me the most concise way to express the action of making content available to a wider audience. > Eben > > > Regards, > > --Gary > > ___ > Sugar-devel mailing list > Sugar-devel@lists.sugarlabs.org > http://lists.sugarlabs.org/listinfo/sugar-devel -- -Andrés ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Journal --- Sugar-Developers meeting REMINDER (2 July, 2009 - 14.00 (UTC)) --- irc.freenode.net, #sugar-meeting
I'm expecting you all to invent Linux groups any minute now. ^_^ On Fri, Jul 3, 2009 at 6:52 PM, Andrés Ambrois 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 wrote: >> > On 2 Jul 2009, at 14:47, Eben Eliason wrote: >> >> On Wed, Jul 1, 2009 at 1:42 PM, Aleksey Lim > 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 '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 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. > > >> Eben >> ___ >> Sugar-devel mailing list >> Sugar-devel@lists.sugarlabs.org >> http://lists.sugarlabs.org/listinfo/sugar-devel > > -- > -Andrés > ___ > Sugar-devel mailing list > Sugar-devel@lists.sugarlabs.org > http://lists.sugarlabs.org/listinfo/sugar-devel > -- Silent Thunder (默雷/धर्ममेघशब्दगर्ज/دھرممیگھشبدگر ج) is my name And Children are my nation. The Cosmos is my dwelling place, The Truth my destination. http://earthtreasury.org/worknet (Edward Mokurai Cherlin) ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Journal --- Sugar-Developers meeting REMINDER (2 July, 2009 - 14.00 (UTC)) --- irc.freenode.net, #sugar-meeting
On Fri, Jul 3, 2009 at 11:19 PM, Gary C Martin wrote: > > On 4 Jul 2009, at 03:13, Eben Eliason wrote: >> >> On Fri, Jul 3, 2009 at 7:25 PM, Gary C Martin 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
Re: [Sugar-devel] Journal --- Sugar-Developers meeting REMINDER (2 July, 2009 - 14.00 (UTC)) --- irc.freenode.net, #sugar-meeting
On 4 Jul 2009, at 03:18, Eben Eliason wrote: > On Fri, Jul 3, 2009 at 9:52 PM, Andrés > Ambrois 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 wrote: On 2 Jul 2009, at 14:47, Eben Eliason wrote: > On Wed, Jul 1, 2009 at 1:42 PM, Aleksey > Lim >> 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 '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 ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs
Re: [Sugar-devel] Journal --- Sugar-Developers meeting REMINDER (2 July, 2009 - 14.00 (UTC)) --- irc.freenode.net, #sugar-meeting
On 4 Jul 2009, at 03:13, Eben Eliason wrote: > On Fri, Jul 3, 2009 at 7:25 PM, Gary C Martin > 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. >>> 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. >> 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. 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). > 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 :-) Regards, --Gary ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Journal --- Sugar-Developers meeting REMINDER (2 July, 2009 - 14.00 (UTC)) --- irc.freenode.net, #sugar-meeting
On Friday 03 July 2009 11:18:24 pm Eben Eliason wrote: > On Fri, Jul 3, 2009 at 9:52 PM, Andrés Ambrois 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 wrote: > >> > On 2 Jul 2009, at 14:47, Eben Eliason wrote: > >> >> On Wed, Jul 1, 2009 at 1:42 PM, Aleksey Lim > > > > 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 '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@lists.sugarlabs.org > >> http://lists.sugarlabs.org/listinfo/sugar-devel > > > > -- > > -Andrés -- -Andrés ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Journal --- Sugar-Developers meeting REMINDER (2 July, 2009 - 14.00 (UTC)) --- irc.freenode.net, #sugar-meeting
On Fri, Jul 3, 2009 at 2:05 PM, Aleksey Lim wrote: > On Fri, Jul 03, 2009 at 01:29:56PM -0400, Eben Eliason wrote: >> On Fri, Jul 3, 2009 at 10:42 AM, Gary C Martin wrote: >> > On 2 Jul 2009, at 14:47, Eben Eliason wrote: >> >> >> >> On Wed, Jul 1, 2009 at 1:42 PM, Aleksey Lim 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 '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. > > so, you think that my idea of Pins looks ugly :) > http://lists.sugarlabs.org/archive/sugar-devel/2009-July/016025.html Something like that could work. Pins, icons, iconic tags: any of these variants on the idea could work. Perhaps we can find a way to integrate these into the line of tags, at the beginning before the custom tags, instead of eating up extra space to the left of each entry. However, I do think we'll probably want to make these basic toggles permanent so that they are visually on or off and can't ever disappear completely for an entry, so that it's obvious that they exist and they are easy to toggle. Eben > -- > Aleksey > ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Journal --- Sugar-Developers meeting REMINDER (2 July, 2009 - 14.00 (UTC)) --- irc.freenode.net, #sugar-meeting
On Fri, Jul 3, 2009 at 9:52 PM, Andrés Ambrois 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 wrote: >> > On 2 Jul 2009, at 14:47, Eben Eliason wrote: >> >> On Wed, Jul 1, 2009 at 1:42 PM, Aleksey Lim > 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 '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). Eben > >> Eben >> ___ >> Sugar-devel mailing list >> Sugar-devel@lists.sugarlabs.org >> http://lists.sugarlabs.org/listinfo/sugar-devel > > -- > -Andrés > ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Journal --- Sugar-Developers meeting REMINDER (2 July, 2009 - 14.00 (UTC)) --- irc.freenode.net, #sugar-meeting
On Fri, Jul 3, 2009 at 7:25 PM, Gary C Martin wrote: > On 3 Jul 2009, at 23:50, Gary C Martin wrote: > >> On 3 Jul 2009, at 18:29, Eben Eliason wrote: >> >>> On Fri, Jul 3, 2009 at 10:42 AM, Gary C Martin >>> wrote: On 2 Jul 2009, at 14:47, Eben Eliason wrote: > > On Wed, Jul 1, 2009 at 1:42 PM, Aleksey > Lim 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. >> >> 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. >> 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. > 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. > 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. Eben 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. > privacy), folks will rarely set it, there will be little to share from > someone else's Journal so you'll rarely bother looking for something > remotely. Changing the Activity sharing language from "Share with: > Neighbourhood" to "Share with: Anyone", means both synchronous and > asynchronous sharing could happen, suddenly allows deployments to > automatically** cross pollinate content and activities as folks move from > otherwise isolated network islands. > > **by automatically, I mean that the sharer has not needed to be asked to > provide specific access to some entry, if it already was public, then it is > shared. Though this does suggest to me that we should finally be allowed to > "un-publicly sh
Re: [Sugar-devel] Journal --- Sugar-Developers meeting REMINDER (2 July, 2009 - 14.00 (UTC)) --- irc.freenode.net, #sugar-meeting
On Friday 03 July 2009 02:29:56 pm Eben Eliason wrote: > On Fri, Jul 3, 2009 at 10:42 AM, Gary C Martin wrote: > > On 2 Jul 2009, at 14:47, Eben Eliason wrote: > >> On Wed, Jul 1, 2009 at 1:42 PM, Aleksey Lim 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 '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 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. > Eben > ___ > Sugar-devel mailing list > Sugar-devel@lists.sugarlabs.org > http://lists.sugarlabs.org/listinfo/sugar-devel -- -Andrés ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Journal --- Sugar-Developers meeting REMINDER (2 July, 2009 - 14.00 (UTC)) --- irc.freenode.net, #sugar-meeting
On 3 Jul 2009, at 23:50, Gary C Martin wrote: > On 3 Jul 2009, at 18:29, Eben Eliason wrote: > >> On Fri, Jul 3, 2009 at 10:42 AM, Gary C Martin >> wrote: >>> On 2 Jul 2009, at 14:47, Eben Eliason wrote: On Wed, Jul 1, 2009 at 1:42 PM, Aleksey Lim 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. > > 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 > 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. 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." 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 privacy), folks will rarely set it, there will be little to share from someone else's Journal so you'll rarely bother looking for something remotely. Changing the Activity sharing language from "Share with: Neighbourhood" to "Share with: Anyone", means both synchronous and asynchronous sharing could happen, suddenly allows deployments to automatically** cross pollinate content and activities as folks move from otherwise isolated network islands. **by automatically, I mean that the sharer has not needed to be asked to provide specific access to some entry, if it already was public, then it is shared. Though this does suggest to me that we should finally be allowed to "un-publicly share" an entry if desired (a manual choice); and perhaps a global manual setting for deployments/ users to switch of all Journal sharing. Regards, --Gary ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Journal --- Sugar-Developers meeting REMINDER (2 July, 2009 - 14.00 (UTC)) --- irc.freenode.net, #sugar-meeting
On 3 Jul 2009, at 18:29, Eben Eliason wrote: > On Fri, Jul 3, 2009 at 10:42 AM, Gary C Martin > wrote: >> On 2 Jul 2009, at 14:47, Eben Eliason wrote: >>> >>> On Wed, Jul 1, 2009 at 1:42 PM, Aleksey >>> Lim 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. 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 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. >> 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 '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. My main reasons against the check-boxes are that they seem to eat quite a chunk of the UI, and make it seem a deal more visually complicated. I could imagine changing entry sharing status in the Journal details view, but that is out the way and not so scary for regular Journal use. Regarding RSS feeds (which I do otherwise like for heterogeneous reasons), the main issue with that solution would be the problems when collaborators were using a remote Jabber server. Machines are likely behind firewalls et al, and accessing standard RSS feeds off such machines would fail in most cases requiring non standard network tweaks or alternative protocol support. Regards, --Gary ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Journal --- Sugar-Developers meeting REMINDER (2 July, 2009 - 14.00 (UTC)) --- irc.freenode.net, #sugar-meeting
On Fri, Jul 03, 2009 at 01:29:56PM -0400, Eben Eliason wrote: > On Fri, Jul 3, 2009 at 10:42 AM, Gary C Martin wrote: > > On 2 Jul 2009, at 14:47, Eben Eliason wrote: > >> > >> On Wed, Jul 1, 2009 at 1:42 PM, Aleksey Lim 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 '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. so, you think that my idea of Pins looks ugly :) http://lists.sugarlabs.org/archive/sugar-devel/2009-July/016025.html -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Journal --- Sugar-Developers meeting REMINDER (2 July, 2009 - 14.00 (UTC)) --- irc.freenode.net, #sugar-meeting
On Fri, Jul 3, 2009 at 10:42 AM, Gary C Martin wrote: > On 2 Jul 2009, at 14:47, Eben Eliason wrote: >> >> On Wed, Jul 1, 2009 at 1:42 PM, Aleksey Lim 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 '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. Eben ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Journal --- Sugar-Developers meeting REMINDER (2 July, 2009 - 14.00 (UTC)) --- irc.freenode.net, #sugar-meeting
On 2 Jul 2009, at 14:47, Eben Eliason wrote: > On Wed, Jul 1, 2009 at 1:42 PM, Aleksey Lim > 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 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 ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Journal --- Sugar-Developers meeting REMINDER (2 July, 2009 - 14.00 (UTC)) --- irc.freenode.net, #sugar-meeting
On Thu, Jul 2, 2009 at 06:08, Sascha Silbe wrote: > On Tue, Jun 30, 2009 at 09:43:38PM +0200, Simon Schampijer wrote: > >> in this week we want to talk about the Journal and datastore [1] >> improvements planned for 0.86. > > I really hope to make it (my GSoC work depends on it - there's a lot of > stuff to talk about and some decisions to make) but am not sure I can > (especially given how flakey internet access is ATM). Would be great to at > least be able to read the meeting logs afterwards (as usual). > > [1] contains my thoughts on a VCS based datastore rewrite - a bit fleshed > out now, but still not finished. The most important part for now is that I'd > like to change the find() API call to take two parameters instead of one. > Right now, the single parameter is a mixture of a query (giving key-value > pairs that entries must match to be returned) and of output options (sorting > order etc.). As we need to change API for version support anyway I'd like to > seize that opportunity to fix this mess (no offense intended). > > While the document currently mentions the index backend quite often I might > actually skip it at first and use only the database backend instead. Xapian > (an Information Retrieval system used by the current datastore to provide > simple metadata search) is very interesting and could be quite useful for a > future FindMyData activity - but IMO with a new API focussing on > probabilistic information retrieval, including spell checking and partial > queries (Xapian "term"s seem to correlate quite well with Sugar "tags", > BTW). The basic attribute search stuff currently used is IMO best done using > a database, not an IR system. > > The document is largely a braindump, not a design document yet. So please > overlook the rough edges and the fact that I'm proposing a full rewrite - I > might end up recycling a large part of the current code base, but thinking > of it as a "new" thing helps me see things more clearly. > > > [1] > http://git.sugarlabs.org/projects/versionsupport-project/repos/mainline/blobs/master/datastore-redesign.html There's lots of interesting stuff in there, will ask some questions today in a separate thread. Regards, Tomeu > CU Sascha > > -- > http://sascha.silbe.org/ > http://www.infra-silbe.de/ > -BEGIN PGP SIGNATURE- > Version: GnuPG v1.4.9 (GNU/Linux) > > iQEcBAEBAgAGBQJKTDKsAAoJELpz82VMF3Da9j4IAKPAS8n/UAOn2Anqoq+RqtHF > Ez1g5CUG+3q4yS5bwpwBGRWu1pEvT+GIrr+lXLsloSGtidApfopIhVIOmNR3wGHn > F3cPLPjcsdoosqWAMdEC+TWpXAwNlLS5mSk4T8o/podUTqnaBnRT7W09DUaPF2L9 > 2oAfme73dyHpFplf9qARIZeWqFGEiDDN3H9tN6yQxY0laozLnTTwDn8OCqIzHcqR > VitMO8s979xO7MYsJzLC+4dXwcADKlPQQOqObcJyxfR7zb29ShkSl/W7Tv+AuAiD > S23qscIoT6/BAcxRdAlrczvxJtc500VwikzRDy1tuFVKHjpJxdOYROuFOqhRg8Q= > =sRau > -END PGP SIGNATURE- > > ___ > Sugar-devel mailing list > Sugar-devel@lists.sugarlabs.org > http://lists.sugarlabs.org/listinfo/sugar-devel > > ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Journal --- Sugar-Developers meeting REMINDER (2 July, 2009 - 14.00 (UTC)) --- irc.freenode.net, #sugar-meeting
On Wed, Jul 1, 2009 at 1:42 PM, Aleksey Lim wrote: > On Wed, Jul 01, 2009 at 09:48:23AM -0400, Eben Eliason wrote: >> On Tue, Jun 30, 2009 at 6:22 PM, Aleksey Lim wrote: >> > On Tue, Jun 30, 2009 at 09:43:38PM +0200, Simon Schampijer wrote: >> >> Hi, >> >> >> >> in this week we want to talk about the Journal and datastore [1] >> >> improvements planned for 0.86. The Library activity [2] has shown some >> >> interesting concepts as well. What are the common goals, how to move >> >> forward, where to invest? >> > >> > Just some thoughts before meeting. >> > >> > For new Journal we have: >> > * action-centric view >> > * object-centric view >> > >> > In my mind they are quite different, >> > action-centric view relates to timelines when object-centric is more >> > like a browsing of objects(sort, tag them etc). >> > >> > So, what about using Library's code base for object-centric view? >> >> I think Library and Scott's "Journal 2" are both good sources to pull >> from. From a UI perspective, however, I think keeping to something >> very much like the existing mockups is the best course, both because >> this is a familiar ground for users (the initial vision for object >> view is nearly identical to the current Journal UI) and because it's >> important to keep it simple while finding intuitive ways to extend >> functionality. I think exposing tags, adding tag autocompletion, and >> improving the selection filters in the toolbar are good places to >> start. > > I'm a bit concerned by having(many?) filter combo-boxes in toolbar[1], > maybe having sidebar(like in Library[2]) could make more sense(btw user can > hide sidebar to browse objects in "full window" mode), moreover we could > use several views for entries in sidebar: list(tree) view, tag cloud[3]. I think a solution something like Scott's Journal2 mockups proposed could work nicely here, without the need to add a sidebar. Collapsing the text popup menus to simple icons (eg. an activity icon for the "what" filter, an XO for the "who" filter, etc.) would be a great improvement, both making the UI more visual, less cluttered, and also providing us with palettes instead of popup menus for adjusting the filters. These palettes could, as you suggest/show, even have grid or list views; the "when" palette could have a calendar or a timeline; we could have search fields in the palette for narrowing down long lists of tags, people or activities, etc. This is really just a rearrangement of what you're proposing, without eating up all the extra screen real estate for a persistent sidebar, because I think that space really is needed for looking at the contents of the Journal itself. >> Adding the grid view to expose object previews would also be a >> great addition! >> >> I also like that Library has started to support sharing. I think there >> have been a number of interesting proposals for how this might work in >> the Journal, and I'd love to see the feature added. Perhaps by >> selecting "View Journal" in the palette for a buddy it would be >> possible to see anyone's shared content. > > The original idea of Library in case of sharing was shared(common) collections > of sugar objects i.e.: > * user #1 creates collection(Library object), creation means choosing > filter for local objects(user tags, properties like mime-type, another > DS fields) > * user #1 shares his collection(Library object) > * user #2 can join #1's session and see(download) objects from his collection > * user #2 can add his local objects to this shared collection(by setting > filter for his local objects) > so, all joined users can view all(from all users) shared objects in > one place I see. Cool. > Having "View Journal" option in buddy menu makes sense as well I agree. > 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! Eben > And Library's method doesn't fit well for this(since it uses filter and > adding one particular object to collection(shared list) is a problem). > > I thought about this issue in context of Library.. and what about: > Extend conception of Favorites to Pins. The idea is: > > - having implicit list of Library-collections/shared-collections means > problem to support these lists(if user deletes some object, sugar > should update all these collection lists implicitly) > - contrariwise, having in object implicit list
Re: [Sugar-devel] Journal --- Sugar-Developers meeting REMINDER (2 July, 2009 - 14.00 (UTC)) --- irc.freenode.net, #sugar-meeting
On Thu, Jul 2, 2009 at 9:29 AM, Simon Schampijer wrote: > I guess you mean this one with object preview? > http://wiki.sugarlabs.org/go/Design_Team/Designs/Journal#10 > For audio objects we might even be able to add a simple playback > functionality here. I like the preview idea - as when skimming for pictures > (when not associated with an activity and therefore having a thumbnail) is > quite hard - you have to open it in Imageviewer first. I think adding support for basic audio and video previews would be a fantastic addition! Eben ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Journal --- Sugar-Developers meeting REMINDER (2 July, 2009 - 14.00 (UTC)) --- irc.freenode.net, #sugar-meeting
On 07/01/2009 03:48 PM, Eben Eliason wrote: > On Tue, Jun 30, 2009 at 6:22 PM, Aleksey Lim wrote: >> On Tue, Jun 30, 2009 at 09:43:38PM +0200, Simon Schampijer wrote: >>> Hi, >>> >>> in this week we want to talk about the Journal and datastore [1] >>> improvements planned for 0.86. The Library activity [2] has shown some >>> interesting concepts as well. What are the common goals, how to move >>> forward, where to invest? >> Just some thoughts before meeting. >> >> For new Journal we have: >> * action-centric view >> * object-centric view >> >> In my mind they are quite different, >> action-centric view relates to timelines when object-centric is more >> like a browsing of objects(sort, tag them etc). >> >> So, what about using Library's code base for object-centric view? > > I think Library and Scott's "Journal 2" are both good sources to pull > from. From a UI perspective, however, I think keeping to something > very much like the existing mockups is the best course, both because > this is a familiar ground for users (the initial vision for object > view is nearly identical to the current Journal UI) and because it's > important to keep it simple while finding intuitive ways to extend > functionality. I think exposing tags, adding tag autocompletion, and > improving the selection filters in the toolbar are good places to > start. Adding the grid view to expose object previews would also be a > great addition! I guess you mean this one with object preview? http://wiki.sugarlabs.org/go/Design_Team/Designs/Journal#10 For audio objects we might even be able to add a simple playback functionality here. I like the preview idea - as when skimming for pictures (when not associated with an activity and therefore having a thumbnail) is quite hard - you have to open it in Imageviewer first. Another mid hanging fruit would be the selecting of several objects and applying actions to them. http://wiki.sugarlabs.org/go/Design_Team/Designs/Journal#6 In general - I like the little improvements steps that has a lot of impact. Regards, Simon ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Journal --- Sugar-Developers meeting REMINDER (2 July, 2009 - 14.00 (UTC)) --- irc.freenode.net, #sugar-meeting
On 02.07.2009, at 06:08, Sascha Silbe wrote: > [1] contains my thoughts on a VCS based datastore rewrite - a bit > fleshed out now, but still not finished. The most important part for > now is that I'd like to change the find() API call to take two > parameters instead of one. I'm slightly surprised you find this minor change the most important part. > [1] > http://git.sugarlabs.org/projects/versionsupport-project/repos/mainline/blobs/master/datastore-redesign.html How do you intend transfer of file ownership to be handled? Have you though about interaction with Rainbow? The only way to access meta data for a given object seems to be find()? Is there metadata associated with the object in general or just in each version? How to access/distinguish those? In update() I assume you submit the old version_id and get back the new version_id? And since you do not care about compatibility you should change the spelling to follow the D-Bus naming conventions: http://dbus.freedesktop.org/doc/dbus-specification.html#naming-conventions - Bert - ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Journal --- Sugar-Developers meeting REMINDER (2 July, 2009 - 14.00 (UTC)) --- irc.freenode.net, #sugar-meeting
On Tue, Jun 30, 2009 at 09:43:38PM +0200, Simon Schampijer wrote: in this week we want to talk about the Journal and datastore [1] improvements planned for 0.86. I really hope to make it (my GSoC work depends on it - there's a lot of stuff to talk about and some decisions to make) but am not sure I can (especially given how flakey internet access is ATM). Would be great to at least be able to read the meeting logs afterwards (as usual). [1] contains my thoughts on a VCS based datastore rewrite - a bit fleshed out now, but still not finished. The most important part for now is that I'd like to change the find() API call to take two parameters instead of one. Right now, the single parameter is a mixture of a query (giving key-value pairs that entries must match to be returned) and of output options (sorting order etc.). As we need to change API for version support anyway I'd like to seize that opportunity to fix this mess (no offense intended). While the document currently mentions the index backend quite often I might actually skip it at first and use only the database backend instead. Xapian (an Information Retrieval system used by the current datastore to provide simple metadata search) is very interesting and could be quite useful for a future FindMyData activity - but IMO with a new API focussing on probabilistic information retrieval, including spell checking and partial queries (Xapian "term"s seem to correlate quite well with Sugar "tags", BTW). The basic attribute search stuff currently used is IMO best done using a database, not an IR system. The document is largely a braindump, not a design document yet. So please overlook the rough edges and the fact that I'm proposing a full rewrite - I might end up recycling a large part of the current code base, but thinking of it as a "new" thing helps me see things more clearly. [1] http://git.sugarlabs.org/projects/versionsupport-project/repos/mainline/blobs/master/datastore-redesign.html CU Sascha -- http://sascha.silbe.org/ http://www.infra-silbe.de/ signature.asc Description: Digital signature ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Journal --- Sugar-Developers meeting REMINDER (2 July, 2009 - 14.00 (UTC)) --- irc.freenode.net, #sugar-meeting
On Wed, Jul 01, 2009 at 05:42:14PM +, Aleksey Lim wrote: > On Wed, Jul 01, 2009 at 09:48:23AM -0400, Eben Eliason wrote: > > On Tue, Jun 30, 2009 at 6:22 PM, Aleksey Lim wrote: > > > On Tue, Jun 30, 2009 at 09:43:38PM +0200, Simon Schampijer wrote: > > >> Hi, > > >> > > >> in this week we want to talk about the Journal and datastore [1] > > >> improvements planned for 0.86. The Library activity [2] has shown some > > >> interesting concepts as well. What are the common goals, how to move > > >> forward, where to invest? > > > > > > Just some thoughts before meeting. > > > > > > For new Journal we have: > > > * action-centric view > > > * object-centric view > > > > > > In my mind they are quite different, > > > action-centric view relates to timelines when object-centric is more > > > like a browsing of objects(sort, tag them etc). > > > > > > So, what about using Library's code base for object-centric view? > > > > I think Library and Scott's "Journal 2" are both good sources to pull > > from. From a UI perspective, however, I think keeping to something > > very much like the existing mockups is the best course, both because > > this is a familiar ground for users (the initial vision for object > > view is nearly identical to the current Journal UI) and because it's > > important to keep it simple while finding intuitive ways to extend > > functionality. I think exposing tags, adding tag autocompletion, and > > improving the selection filters in the toolbar are good places to > > start. > > I'm a bit concerned by having(many?) filter combo-boxes in toolbar[1], > maybe having sidebar(like in Library[2]) could make more sense(btw user can > hide sidebar to browse objects in "full window" mode), moreover we could > use several views for entries in sidebar: list(tree) view, tag cloud[3]. > > > Adding the grid view to expose object previews would also be a > > great addition! > > > > I also like that Library has started to support sharing. I think there > > have been a number of interesting proposals for how this might work in > > the Journal, and I'd love to see the feature added. Perhaps by > > selecting "View Journal" in the palette for a buddy it would be > > possible to see anyone's shared content. > > The original idea of Library in case of sharing was shared(common) collections > of sugar objects i.e.: > * user #1 creates collection(Library object), creation means choosing > filter for local objects(user tags, properties like mime-type, another > DS fields) > * user #1 shares his collection(Library object) > * user #2 can join #1's session and see(download) objects from his collection > * user #2 can add his local objects to this shared collection(by setting > filter for his local objects) > so, all joined users can view all(from all users) shared objects in > one place > > Having "View Journal" option in buddy menu makes sense as well > 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). > And Library's method doesn't fit well for this(since it uses filter and > adding one particular object to collection(shared list) is a problem). > > I thought about this issue in context of Library.. and what about: > Extend conception of Favorites to Pins. The idea is: > > - having implicit list of Library-collections/shared-collections means > problem to support these lists(if user deletes some object, sugar > should update all these collection lists implicitly) > - contrariwise, having in object implicit list of all collection links that > this object participates in, means also some odd implicit job to > support these links > + so, what about delegation this job to users and make this process explicit > + sugar does not do odd job of implicit supporting lists of links > + users can understand what objects go to what collections(like > collection of objects to share, collection of starred objects, users > collections) > * old Favorites mark would be a "pre-installed" pin > so, we could have several standard pins: > * pins for objects to share > * Favorites could be transformed to pins to show objects in home view > so any object(not only activities) could appear in home view > * ... > * each pin could have unique color(and name) > * like Favorites pins could be attached to objects from list view(there > is no needs to open details dialog) > * each objects can have several pins attached at the same time > * we can render all these attached pins in one cell(not in per-pin cells > like for participants) i.e. pins will overlap each over > > [1] http://wiki.sugarlabs.org/go/Design_Team/Designs/Journal#3 > [2] http://wiki.sugarlabs.org/go/File:-1.png > [3] http://wiki.sugarlabs.org/go/File:-2.png sorry, forgot to mention - its all about object-centric view -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.or
Re: [Sugar-devel] Journal --- Sugar-Developers meeting REMINDER (2 July, 2009 - 14.00 (UTC)) --- irc.freenode.net, #sugar-meeting
On Wed, Jul 01, 2009 at 09:48:23AM -0400, Eben Eliason wrote: > On Tue, Jun 30, 2009 at 6:22 PM, Aleksey Lim wrote: > > On Tue, Jun 30, 2009 at 09:43:38PM +0200, Simon Schampijer wrote: > >> Hi, > >> > >> in this week we want to talk about the Journal and datastore [1] > >> improvements planned for 0.86. The Library activity [2] has shown some > >> interesting concepts as well. What are the common goals, how to move > >> forward, where to invest? > > > > Just some thoughts before meeting. > > > > For new Journal we have: > > * action-centric view > > * object-centric view > > > > In my mind they are quite different, > > action-centric view relates to timelines when object-centric is more > > like a browsing of objects(sort, tag them etc). > > > > So, what about using Library's code base for object-centric view? > > I think Library and Scott's "Journal 2" are both good sources to pull > from. From a UI perspective, however, I think keeping to something > very much like the existing mockups is the best course, both because > this is a familiar ground for users (the initial vision for object > view is nearly identical to the current Journal UI) and because it's > important to keep it simple while finding intuitive ways to extend > functionality. I think exposing tags, adding tag autocompletion, and > improving the selection filters in the toolbar are good places to > start. I'm a bit concerned by having(many?) filter combo-boxes in toolbar[1], maybe having sidebar(like in Library[2]) could make more sense(btw user can hide sidebar to browse objects in "full window" mode), moreover we could use several views for entries in sidebar: list(tree) view, tag cloud[3]. > Adding the grid view to expose object previews would also be a > great addition! > > I also like that Library has started to support sharing. I think there > have been a number of interesting proposals for how this might work in > the Journal, and I'd love to see the feature added. Perhaps by > selecting "View Journal" in the palette for a buddy it would be > possible to see anyone's shared content. The original idea of Library in case of sharing was shared(common) collections of sugar objects i.e.: * user #1 creates collection(Library object), creation means choosing filter for local objects(user tags, properties like mime-type, another DS fields) * user #1 shares his collection(Library object) * user #2 can join #1's session and see(download) objects from his collection * user #2 can add his local objects to this shared collection(by setting filter for his local objects) so, all joined users can view all(from all users) shared objects in one place Having "View Journal" option in buddy menu makes sense as well 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). And Library's method doesn't fit well for this(since it uses filter and adding one particular object to collection(shared list) is a problem). I thought about this issue in context of Library.. and what about: Extend conception of Favorites to Pins. The idea is: - having implicit list of Library-collections/shared-collections means problem to support these lists(if user deletes some object, sugar should update all these collection lists implicitly) - contrariwise, having in object implicit list of all collection links that this object participates in, means also some odd implicit job to support these links + so, what about delegation this job to users and make this process explicit + sugar does not do odd job of implicit supporting lists of links + users can understand what objects go to what collections(like collection of objects to share, collection of starred objects, users collections) * old Favorites mark would be a "pre-installed" pin so, we could have several standard pins: * pins for objects to share * Favorites could be transformed to pins to show objects in home view so any object(not only activities) could appear in home view * ... * each pin could have unique color(and name) * like Favorites pins could be attached to objects from list view(there is no needs to open details dialog) * each objects can have several pins attached at the same time * we can render all these attached pins in one cell(not in per-pin cells like for participants) i.e. pins will overlap each over [1] http://wiki.sugarlabs.org/go/Design_Team/Designs/Journal#3 [2] http://wiki.sugarlabs.org/go/File:-1.png [3] http://wiki.sugarlabs.org/go/File:-2.png -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Journal --- Sugar-Developers meeting REMINDER (2 July, 2009 - 14.00 (UTC)) --- irc.freenode.net, #sugar-meeting
Eben wrote: > On Tue, Jun 30, 2009 at 3:43 PM, Simon Schampijer wrote: >> All the people involved - please attend, would be awesome if UI >> designers would attend too. > > I'd love to join, though I'm not sure how much attention I can give > the meeting while at work. I'll try to peek in. As with Eben, I'm interested but regularly unavailable during those hours for real-time conversation due to other commitments. Apologies, Michael ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Journal --- Sugar-Developers meeting REMINDER (2 July, 2009 - 14.00 (UTC)) --- irc.freenode.net, #sugar-meeting
On Wed, Jul 1, 2009 at 9:46 AM, Tomeu Vizoso wrote: > On Wed, Jul 1, 2009 at 15:43, Eben Eliason wrote: >> On Tue, Jun 30, 2009 at 3:43 PM, Simon Schampijer wrote: >>> Hi, >>> >>> in this week we want to talk about the Journal and datastore [1] >>> improvements planned for 0.86. The Library activity [2] has shown some >>> interesting concepts as well. What are the common goals, how to move >>> forward, where to invest? >>> >>> All the people involved - please attend, would be awesome if UI >>> designers would attend too. >> >> I'd love to join, though I'm not sure how much attention I can give >> the meeting while at work. I'll try to peek in. > > During this weekend would work fine for me, as well. > > Alternatively, if we take good minutes we can have a productive thread > on the mailing list afterwards. That sounds fine. Don't reschedule on account of me. I'll try to keep one eye in that direction, and just ping me specifically as needed if I'm not paying close enough attention. ;) Eben > Regards, > > Tomeu > >> Eben >> >>> Regards, >>> Simon >>> >>> [1] http://wiki.sugarlabs.org/go/Version_support_for_datastore/Proposal >>> [2] http://wiki.sugarlabs.org/go/Activities/Library >>> ___ >>> Sugar-devel mailing list >>> Sugar-devel@lists.sugarlabs.org >>> http://lists.sugarlabs.org/listinfo/sugar-devel >>> >> ___ >> Sugar-devel mailing list >> Sugar-devel@lists.sugarlabs.org >> http://lists.sugarlabs.org/listinfo/sugar-devel >> > ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Journal --- Sugar-Developers meeting REMINDER (2 July, 2009 - 14.00 (UTC)) --- irc.freenode.net, #sugar-meeting
On Tue, Jun 30, 2009 at 6:22 PM, Aleksey Lim wrote: > On Tue, Jun 30, 2009 at 09:43:38PM +0200, Simon Schampijer wrote: >> Hi, >> >> in this week we want to talk about the Journal and datastore [1] >> improvements planned for 0.86. The Library activity [2] has shown some >> interesting concepts as well. What are the common goals, how to move >> forward, where to invest? > > Just some thoughts before meeting. > > For new Journal we have: > * action-centric view > * object-centric view > > In my mind they are quite different, > action-centric view relates to timelines when object-centric is more > like a browsing of objects(sort, tag them etc). > > So, what about using Library's code base for object-centric view? I think Library and Scott's "Journal 2" are both good sources to pull from. From a UI perspective, however, I think keeping to something very much like the existing mockups is the best course, both because this is a familiar ground for users (the initial vision for object view is nearly identical to the current Journal UI) and because it's important to keep it simple while finding intuitive ways to extend functionality. I think exposing tags, adding tag autocompletion, and improving the selection filters in the toolbar are good places to start. Adding the grid view to expose object previews would also be a great addition! I also like that Library has started to support sharing. I think there have been a number of interesting proposals for how this might work in the Journal, and I'd love to see the feature added. Perhaps by selecting "View Journal" in the palette for a buddy it would be possible to see anyone's shared content. Eben > -- > Aleksey > ___ > Sugar-devel mailing list > Sugar-devel@lists.sugarlabs.org > http://lists.sugarlabs.org/listinfo/sugar-devel > ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Journal --- Sugar-Developers meeting REMINDER (2 July, 2009 - 14.00 (UTC)) --- irc.freenode.net, #sugar-meeting
On Wed, Jul 1, 2009 at 15:43, Eben Eliason wrote: > On Tue, Jun 30, 2009 at 3:43 PM, Simon Schampijer wrote: >> Hi, >> >> in this week we want to talk about the Journal and datastore [1] >> improvements planned for 0.86. The Library activity [2] has shown some >> interesting concepts as well. What are the common goals, how to move >> forward, where to invest? >> >> All the people involved - please attend, would be awesome if UI >> designers would attend too. > > I'd love to join, though I'm not sure how much attention I can give > the meeting while at work. I'll try to peek in. During this weekend would work fine for me, as well. Alternatively, if we take good minutes we can have a productive thread on the mailing list afterwards. Regards, Tomeu > Eben > >> Regards, >> Simon >> >> [1] http://wiki.sugarlabs.org/go/Version_support_for_datastore/Proposal >> [2] http://wiki.sugarlabs.org/go/Activities/Library >> ___ >> Sugar-devel mailing list >> Sugar-devel@lists.sugarlabs.org >> http://lists.sugarlabs.org/listinfo/sugar-devel >> > ___ > Sugar-devel mailing list > Sugar-devel@lists.sugarlabs.org > http://lists.sugarlabs.org/listinfo/sugar-devel > ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Journal --- Sugar-Developers meeting REMINDER (2 July, 2009 - 14.00 (UTC)) --- irc.freenode.net, #sugar-meeting
On Tue, Jun 30, 2009 at 3:43 PM, Simon Schampijer wrote: > Hi, > > in this week we want to talk about the Journal and datastore [1] > improvements planned for 0.86. The Library activity [2] has shown some > interesting concepts as well. What are the common goals, how to move > forward, where to invest? > > All the people involved - please attend, would be awesome if UI > designers would attend too. I'd love to join, though I'm not sure how much attention I can give the meeting while at work. I'll try to peek in. Eben > Regards, > Simon > > [1] http://wiki.sugarlabs.org/go/Version_support_for_datastore/Proposal > [2] http://wiki.sugarlabs.org/go/Activities/Library > ___ > Sugar-devel mailing list > Sugar-devel@lists.sugarlabs.org > http://lists.sugarlabs.org/listinfo/sugar-devel > ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Journal --- Sugar-Developers meeting REMINDER (2 July, 2009 - 14.00 (UTC)) --- irc.freenode.net, #sugar-meeting
On Wed, Jul 1, 2009 at 00:22, Aleksey Lim wrote: > On Tue, Jun 30, 2009 at 09:43:38PM +0200, Simon Schampijer wrote: >> Hi, >> >> in this week we want to talk about the Journal and datastore [1] >> improvements planned for 0.86. The Library activity [2] has shown some >> interesting concepts as well. What are the common goals, how to move >> forward, where to invest? > > Just some thoughts before meeting. > > For new Journal we have: > * action-centric view > * object-centric view > > In my mind they are quite different, > action-centric view relates to timelines when object-centric is more > like a browsing of objects(sort, tag them etc). > > So, what about using Library's code base for object-centric view? Have no objection to that, though we first need to see on which UI changes we agree for 0.86 and then we'll integrate the code as with any other contribution. Looking forward to discuss this further, Tomeu > -- > Aleksey > ___ > Sugar-devel mailing list > Sugar-devel@lists.sugarlabs.org > http://lists.sugarlabs.org/listinfo/sugar-devel > ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Journal --- Sugar-Developers meeting REMINDER (2 July, 2009 - 14.00 (UTC)) --- irc.freenode.net, #sugar-meeting
On Tue, Jun 30, 2009 at 09:43:38PM +0200, Simon Schampijer wrote: > Hi, > > in this week we want to talk about the Journal and datastore [1] > improvements planned for 0.86. The Library activity [2] has shown some > interesting concepts as well. What are the common goals, how to move > forward, where to invest? Just some thoughts before meeting. For new Journal we have: * action-centric view * object-centric view In my mind they are quite different, action-centric view relates to timelines when object-centric is more like a browsing of objects(sort, tag them etc). So, what about using Library's code base for object-centric view? -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] Journal --- Sugar-Developers meeting REMINDER (2 July, 2009 - 14.00 (UTC)) --- irc.freenode.net, #sugar-meeting
Hi, in this week we want to talk about the Journal and datastore [1] improvements planned for 0.86. The Library activity [2] has shown some interesting concepts as well. What are the common goals, how to move forward, where to invest? All the people involved - please attend, would be awesome if UI designers would attend too. Regards, Simon [1] http://wiki.sugarlabs.org/go/Version_support_for_datastore/Proposal [2] http://wiki.sugarlabs.org/go/Activities/Library ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
