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
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. Schwartzbmsch...@fas.harvard.edu 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
On Saturday 04 July 2009 12:31:48 am Eben Eliason wrote: On Fri, Jul 3, 2009 at 11:19 PM, Gary C Marting...@garycmartin.com wrote: On 4 Jul 2009, at 03:13, Eben Eliason wrote: snip 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
On Sat, Jul 4, 2009 at 2:00 AM, Andrés Ambroisandresambr...@gmail.com wrote: On Saturday 04 July 2009 12:31:48 am Eben Eliason wrote: On Fri, Jul 3, 2009 at 11:19 PM, Gary C Marting...@garycmartin.com wrote: On 4 Jul 2009, at 03:13, Eben Eliason wrote: snip 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 Thu, Jul 2, 2009 at 06:08, Sascha Silbesascha-ml-ui-sugar-de...@silbe.org 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 terms 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 2 Jul 2009, at 14:47, Eben Eliason wrote: On Wed, Jul 1, 2009 at 1:42 PM, Aleksey Limalsr...@member.fsf.org wrote: But in that case we should provide possibility to mark objects that can be shared(I guess sharing all local objects by default is not a nice idea). Right. This would be essential. There's definitely some thought that needs to be done here. Scott had an interesting proposal which basically exposed the Journal (or some subset of it) as an RSS feed. This was really neat, because it meant we could build a UI for someone else's Journal in Sugar, populating it with that data, but also that these feeds could be shared globally, for anyone with an RSS reader to benefit from. That's a really powerful approach in my mind, and there is some starter code lying around as a proof of concept already! +1 to rss feed concept, makes life a lot easier in a heterogeneous environment. I'm still catching up on email so apologies if this has been mentioned already. But the UI for marking of entries as sharable does not necessarily need to be another Journal user-interface addition** In the simplest approach you could just extend the Activity Share with: my Neighbourhood control to mark a Journal entry as part of the RRS feed. Would need some 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 Fri, Jul 3, 2009 at 10:42 AM, Gary C Marting...@garycmartin.com wrote: On 2 Jul 2009, at 14:47, Eben Eliason wrote: On Wed, Jul 1, 2009 at 1:42 PM, Aleksey Limalsr...@member.fsf.org wrote: But in that case we should provide possibility to mark objects that can be shared(I guess sharing all local objects by default is not a nice idea). Right. This would be essential. There's definitely some thought that needs to be done here. Scott had an interesting proposal which basically exposed the Journal (or some subset of it) as an RSS feed. This was really neat, because it meant we could build a UI for someone else's Journal in Sugar, populating it with that data, but also that these feeds could be shared globally, for anyone with an RSS reader to benefit from. That's a really powerful approach in my mind, and there is some starter code lying around as a proof of concept already! +1 to rss feed concept, makes life a lot easier in a heterogeneous environment. I'm still catching up on email so apologies if this has been mentioned already. But the UI for marking of entries as sharable does not necessarily need to be another Journal user-interface addition** In the simplest approach you could just extend the Activity Share with: my Neighbourhood control to mark a Journal entry as part of the RRS feed. Would need some The problem I see with this is that we're talking about two different kinds of sharing. Just because I want to make a picture I drew available for anyone to look at, or even make a photocopy of to scribble on, doesn't mean that I want to let them into a shared painting session so they can scribble on the original with me. This is the difference between sharing an activity with someone collaboratively, and sending them (a copy of) the resulting object. thought on wording, do you add more levels of sharing? Or do you just simplify the Share with: language language to Private, Share with: Anyone. **though I would like entries to visually show their sharing state, the buddy column hints at this but should be made explicit I do actually think that the Journal is the best place to expose this, especially since the way we plan to expose the feature in the UI is something like view my friend's Journal. I'm not sure exactly how or where that happens. Perhaps if we can abandon the checkbox for the multi-selection we can use that space for a public/private toggle of some kind. 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 Fri, Jul 03, 2009 at 01:29:56PM -0400, Eben Eliason wrote: On Fri, Jul 3, 2009 at 10:42 AM, Gary C Marting...@garycmartin.com wrote: On 2 Jul 2009, at 14:47, Eben Eliason wrote: On Wed, Jul 1, 2009 at 1:42 PM, Aleksey Limalsr...@member.fsf.org wrote: But in that case we should provide possibility to mark objects that can be shared(I guess sharing all local objects by default is not a nice idea). Right. This would be essential. There's definitely some thought that needs to be done here. Scott had an interesting proposal which basically exposed the Journal (or some subset of it) as an RSS feed. This was really neat, because it meant we could build a UI for someone else's Journal in Sugar, populating it with that data, but also that these feeds could be shared globally, for anyone with an RSS reader to benefit from. That's a really powerful approach in my mind, and there is some starter code lying around as a proof of concept already! +1 to rss feed concept, makes life a lot easier in a heterogeneous environment. I'm still catching up on email so apologies if this has been mentioned already. But the UI for marking of entries as sharable does not necessarily need to be another Journal user-interface addition** In the simplest approach you could just extend the Activity Share with: my Neighbourhood control to mark a Journal entry as part of the RRS feed. Would need some The problem I see with this is that we're talking about two different kinds of sharing. Just because I want to make a picture I drew available for anyone to look at, or even make a photocopy of to scribble on, doesn't mean that I want to let them into a shared painting session so they can scribble on the original with me. This is the difference between sharing an activity with someone collaboratively, and sending them (a copy of) the resulting object. thought on wording, do you add more levels of sharing? Or do you just simplify the Share with: language language to Private, Share with: Anyone. **though I would like entries to visually show their sharing state, the buddy column hints at this but should be made explicit I do actually think that the Journal is the best place to expose this, especially since the way we plan to expose the feature in the UI is something like view my friend's Journal. I'm not sure exactly how or where that happens. Perhaps if we can abandon the checkbox for the multi-selection we can use that space for a public/private toggle of some kind. 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 3 Jul 2009, at 18:29, Eben Eliason wrote: On Fri, Jul 3, 2009 at 10:42 AM, Gary C Marting...@garycmartin.com wrote: On 2 Jul 2009, at 14:47, Eben Eliason wrote: On Wed, Jul 1, 2009 at 1:42 PM, Aleksey Limalsr...@member.fsf.org wrote: But in that case we should provide possibility to mark objects that can be shared(I guess sharing all local objects by default is not a nice idea). Right. This would be essential. There's definitely some thought that needs to be done here. Scott had an interesting proposal which basically exposed the Journal (or some subset of it) as an RSS feed. This was really neat, because it meant we could build a UI for someone else's Journal in Sugar, populating it with that data, but also that these feeds could be shared globally, for anyone with an RSS reader to benefit from. That's a really powerful approach in my mind, and there is some starter code lying around as a proof of concept already! +1 to rss feed concept, makes life a lot easier in a heterogeneous environment. I'm still catching up on email so apologies if this has been mentioned already. But the UI for marking of entries as sharable does not necessarily need to be another Journal user-interface addition** In the simplest approach you could just extend the Activity Share with: my Neighbourhood control to mark a Journal entry as part of the RRS feed. Would need some The problem I see with this is that we're talking about two different kinds of sharing. Just because I want to make a picture I drew available for anyone to look at, or even make a photocopy of to scribble on, doesn't mean that I want to let them into a shared painting session so they can scribble on the original with me. This is the difference between sharing an activity with someone collaboratively, and sending them (a copy of) the resulting object. 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 my friend's Journal. I'm not sure exactly how or where that happens. Perhaps if we can abandon the checkbox for the multi-selection we can use that space for a public/private toggle of some kind. 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 Friday 03 July 2009 02:29:56 pm Eben Eliason wrote: On Fri, Jul 3, 2009 at 10:42 AM, Gary C Marting...@garycmartin.com wrote: On 2 Jul 2009, at 14:47, Eben Eliason wrote: On Wed, Jul 1, 2009 at 1:42 PM, Aleksey Limalsr...@member.fsf.org wrote: But in that case we should provide possibility to mark objects that can be shared(I guess sharing all local objects by default is not a nice idea). Right. This would be essential. There's definitely some thought that needs to be done here. Scott had an interesting proposal which basically exposed the Journal (or some subset of it) as an RSS feed. This was really neat, because it meant we could build a UI for someone else's Journal in Sugar, populating it with that data, but also that these feeds could be shared globally, for anyone with an RSS reader to benefit from. That's a really powerful approach in my mind, and there is some starter code lying around as a proof of concept already! +1 to rss feed concept, makes life a lot easier in a heterogeneous environment. I'm still catching up on email so apologies if this has been mentioned already. But the UI for marking of entries as sharable does not necessarily need to be another Journal user-interface addition** In the simplest approach you could just extend the Activity Share with: my Neighbourhood control to mark a Journal entry as part of the RRS feed. Would need some The problem I see with this is that we're talking about two different kinds of sharing. Just because I want to make a picture I drew available for anyone to look at, or even make a photocopy of to scribble on, doesn't mean that I want to let them into a shared painting session so they can scribble on the original with me. This is the difference between sharing an activity with someone collaboratively, and sending them (a copy of) the resulting object. thought on wording, do you add more levels of sharing? Or do you just simplify the Share with: language language to Private, Share with: Anyone. **though I would like entries to visually show their sharing state, the buddy column hints at this but should be made explicit I do actually think that the Journal is the best place to expose this, especially since the way we plan to expose the feature in the UI is something like view my friend's Journal. I'm not sure exactly how or where that happens. Perhaps if we can abandon the checkbox for the multi-selection we can use that space for a public/private toggle of some kind. How about using special tags? A Publish tag seems reasonable for this, and consistent with the fact that it could live in a publish directory an HTTP server would serve. I 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 Fri, Jul 3, 2009 at 7:25 PM, Gary C Marting...@garycmartin.com 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 Marting...@garycmartin.com wrote: On 2 Jul 2009, at 14:47, Eben Eliason wrote: On Wed, Jul 1, 2009 at 1:42 PM, Aleksey Limalsr...@member.fsf.org wrote: But in that case we should provide possibility to mark objects that can be shared(I guess sharing all local objects by default is not a nice idea). Right. This would be essential. There's definitely some thought that needs to be done here. Scott had an interesting proposal which basically exposed the Journal (or some subset of it) as an RSS feed. This was really neat, because it meant we could build a UI for someone else's Journal in Sugar, populating it with that data, but also that these feeds could be shared globally, for anyone with an RSS reader to benefit from. That's a really powerful approach in my mind, and there is some starter code lying around as a proof of concept already! +1 to rss feed concept, makes life a lot easier in a heterogeneous environment. I'm still catching up on email so apologies if this has been mentioned already. But the UI for marking of entries as sharable does not necessarily need to be another Journal user-interface addition** In the simplest approach you could just extend the Activity Share with: my Neighbourhood control to mark a Journal entry as part of the RRS feed. Would need some The problem I see with this is that we're talking about two different kinds of sharing. Just because I want to make a picture I drew available for anyone to look at, or even make a photocopy of to scribble on, doesn't mean that I want to let them into a shared painting session so they can scribble on the original with me. This is the difference between sharing an activity with someone collaboratively, and sending them (a copy of) the resulting object. 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 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 ___
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 Ambroisandresambr...@gmail.com wrote: On Friday 03 July 2009 02:29:56 pm Eben Eliason wrote: On Fri, Jul 3, 2009 at 10:42 AM, Gary C Marting...@garycmartin.com wrote: On 2 Jul 2009, at 14:47, Eben Eliason wrote: On Wed, Jul 1, 2009 at 1:42 PM, Aleksey Limalsr...@member.fsf.org wrote: But in that case we should provide possibility to mark objects that can be shared(I guess sharing all local objects by default is not a nice idea). Right. This would be essential. There's definitely some thought that needs to be done here. Scott had an interesting proposal which basically exposed the Journal (or some subset of it) as an RSS feed. This was really neat, because it meant we could build a UI for someone else's Journal in Sugar, populating it with that data, but also that these feeds could be shared globally, for anyone with an RSS reader to benefit from. That's a really powerful approach in my mind, and there is some starter code lying around as a proof of concept already! +1 to rss feed concept, makes life a lot easier in a heterogeneous environment. I'm still catching up on email so apologies if this has been mentioned already. But the UI for marking of entries as sharable does not necessarily need to be another Journal user-interface addition** In the simplest approach you could just extend the Activity Share with: my Neighbourhood control to mark a Journal entry as part of the RRS feed. Would need some The problem I see with this is that we're talking about two different kinds of sharing. Just because I want to make a picture I drew available for anyone to look at, or even make a photocopy of to scribble on, doesn't mean that I want to let them into a shared painting session so they can scribble on the original with me. This is the difference between sharing an activity with someone collaboratively, and sending them (a copy of) the resulting object. thought on wording, do you add more levels of sharing? Or do you just simplify the Share with: language language to Private, Share with: Anyone. **though I would like entries to visually show their sharing state, the buddy column hints at this but should be made explicit I do actually think that the Journal is the best place to expose this, especially since the way we plan to expose the feature in the UI is something like view my friend's Journal. I'm not sure exactly how or where that happens. Perhaps if we can abandon the checkbox for the multi-selection we can use that space for a public/private toggle of some kind. How about using special tags? A Publish tag seems reasonable for this, and consistent with the fact that it could live in a publish directory an HTTP server would serve. I think it's a good idea to store these states as metadata, but I also think that we need to expose the feature visually to highlight the capability and make it easier to manage. I wouldn't want kids to have to type publish into the correct field in order to share their work. I can also imagine a tags used for starred entries and other metadata (in a general sense) used by sugar. This would make them searchable as well. Yup. I don't think this works yet, but the intent has always been to allow advanced search queries by specifying key:value pairs (as in gmail). In fact, all of the filters we support should have text equvalents, eg. cat kind:image with:alice favorite:yes (or similar). 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 2:05 PM, Aleksey Limalsr...@member.fsf.org 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 Marting...@garycmartin.com wrote: On 2 Jul 2009, at 14:47, Eben Eliason wrote: On Wed, Jul 1, 2009 at 1:42 PM, Aleksey Limalsr...@member.fsf.org wrote: But in that case we should provide possibility to mark objects that can be shared(I guess sharing all local objects by default is not a nice idea). Right. This would be essential. There's definitely some thought that needs to be done here. Scott had an interesting proposal which basically exposed the Journal (or some subset of it) as an RSS feed. This was really neat, because it meant we could build a UI for someone else's Journal in Sugar, populating it with that data, but also that these feeds could be shared globally, for anyone with an RSS reader to benefit from. That's a really powerful approach in my mind, and there is some starter code lying around as a proof of concept already! +1 to rss feed concept, makes life a lot easier in a heterogeneous environment. I'm still catching up on email so apologies if this has been mentioned already. But the UI for marking of entries as sharable does not necessarily need to be another Journal user-interface addition** In the simplest approach you could just extend the Activity Share with: my Neighbourhood control to mark a Journal entry as part of the RRS feed. Would need some The problem I see with this is that we're talking about two different kinds of sharing. Just because I want to make a picture I drew available for anyone to look at, or even make a photocopy of to scribble on, doesn't mean that I want to let them into a shared painting session so they can scribble on the original with me. This is the difference between sharing an activity with someone collaboratively, and sending them (a copy of) the resulting object. thought on wording, do you add more levels of sharing? Or do you just simplify the Share with: language language to Private, Share with: Anyone. **though I would like entries to visually show their sharing state, the buddy column hints at this but should be made explicit I do actually think that the Journal is the best place to expose this, especially since the way we plan to expose the feature in the UI is something like view my friend's Journal. I'm not sure exactly how or where that happens. Perhaps if we can abandon the checkbox for the multi-selection we can use that space for a public/private toggle of some kind. 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 Friday 03 July 2009 11:18:24 pm Eben Eliason wrote: On Fri, Jul 3, 2009 at 9:52 PM, Andrés Ambroisandresambr...@gmail.com wrote: On Friday 03 July 2009 02:29:56 pm Eben Eliason wrote: On Fri, Jul 3, 2009 at 10:42 AM, Gary C Marting...@garycmartin.com wrote: On 2 Jul 2009, at 14:47, Eben Eliason wrote: On Wed, Jul 1, 2009 at 1:42 PM, Aleksey Limalsr...@member.fsf.org wrote: But in that case we should provide possibility to mark objects that can be shared(I guess sharing all local objects by default is not a nice idea). Right. This would be essential. There's definitely some thought that needs to be done here. Scott had an interesting proposal which basically exposed the Journal (or some subset of it) as an RSS feed. This was really neat, because it meant we could build a UI for someone else's Journal in Sugar, populating it with that data, but also that these feeds could be shared globally, for anyone with an RSS reader to benefit from. That's a really powerful approach in my mind, and there is some starter code lying around as a proof of concept already! +1 to rss feed concept, makes life a lot easier in a heterogeneous environment. I'm still catching up on email so apologies if this has been mentioned already. But the UI for marking of entries as sharable does not necessarily need to be another Journal user-interface addition** In the simplest approach you could just extend the Activity Share with: my Neighbourhood control to mark a Journal entry as part of the RRS feed. Would need some The problem I see with this is that we're talking about two different kinds of sharing. Just because I want to make a picture I drew available for anyone to look at, or even make a photocopy of to scribble on, doesn't mean that I want to let them into a shared painting session so they can scribble on the original with me. This is the difference between sharing an activity with someone collaboratively, and sending them (a copy of) the resulting object. thought on wording, do you add more levels of sharing? Or do you just simplify the Share with: language language to Private, Share with: Anyone. **though I would like entries to visually show their sharing state, the buddy column hints at this but should be made explicit I do actually think that the Journal is the best place to expose this, especially since the way we plan to expose the feature in the UI is something like view my friend's Journal. I'm not sure exactly how or where that happens. Perhaps if we can abandon the checkbox for the multi-selection we can use that space for a public/private toggle of some kind. How about using special tags? A Publish tag seems reasonable for this, and consistent with the fact that it could live in a publish directory an HTTP server would serve. I think it's a good idea to store these states as metadata, but I also think that we need to expose the feature visually to highlight the capability and make it easier to manage. I wouldn't want kids to have to type publish into the correct field in order to share their work. I wasn't suggesting that either. Scott's concepts [0] have a list of used tags for exploration, these special tags would be highlighted/prioritized somehow in this list. [0]http://wiki.laptop.org/go/Image:Journal2-working.png I can also imagine a tags used for starred entries and other metadata (in a general sense) used by sugar. This would make them searchable as well. Yup. I don't think this works yet, but the intent has always been to allow advanced search queries by specifying key:value pairs (as in gmail). In fact, all of the filters we support should have text equvalents, eg. cat kind:image with:alice favorite:yes (or similar). Eben Eben ___ Sugar-devel mailing list Sugar-devel@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 4 Jul 2009, at 03:13, Eben Eliason wrote: On Fri, Jul 3, 2009 at 7:25 PM, Gary C Marting...@garycmartin.com wrote: Devils advocate here, so just because someone was late to the realtime party, they don't get to download an otherwise openly published piece of work that could be re-published at any time by any of the temporally lucky contributors? Downloading a Journal entry would not I think you misunderstand me, as I think I'm arguing exactly the opposite. I wouldn't want to deprive people the ability to download finished works because the sharer doesn't want to open the document up for public collaboration. The distinction is important, so that it's possible to share things with others without having to make my own documents open to collaboration. OK, yes thanks, I see this issue now: I might want folks to be able to download an entry, but I might well want to work on it privately, by myself. 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 4 Jul 2009, at 03:18, Eben Eliason wrote: On Fri, Jul 3, 2009 at 9:52 PM, Andrés Ambroisandresambr...@gmail.com wrote: On Friday 03 July 2009 02:29:56 pm Eben Eliason wrote: On Fri, Jul 3, 2009 at 10:42 AM, Gary C Marting...@garycmartin.com wrote: On 2 Jul 2009, at 14:47, Eben Eliason wrote: On Wed, Jul 1, 2009 at 1:42 PM, Aleksey Limalsr...@member.fsf.org wrote: But in that case we should provide possibility to mark objects that can be shared(I guess sharing all local objects by default is not a nice idea). Right. This would be essential. There's definitely some thought that needs to be done here. Scott had an interesting proposal which basically exposed the Journal (or some subset of it) as an RSS feed. This was really neat, because it meant we could build a UI for someone else's Journal in Sugar, populating it with that data, but also that these feeds could be shared globally, for anyone with an RSS reader to benefit from. That's a really powerful approach in my mind, and there is some starter code lying around as a proof of concept already! +1 to rss feed concept, makes life a lot easier in a heterogeneous environment. I'm still catching up on email so apologies if this has been mentioned already. But the UI for marking of entries as sharable does not necessarily need to be another Journal user-interface addition** In the simplest approach you could just extend the Activity Share with: my Neighbourhood control to mark a Journal entry as part of the RRS feed. Would need some The problem I see with this is that we're talking about two different kinds of sharing. Just because I want to make a picture I drew available for anyone to look at, or even make a photocopy of to scribble on, doesn't mean that I want to let them into a shared painting session so they can scribble on the original with me. This is the difference between sharing an activity with someone collaboratively, and sending them (a copy of) the resulting object. thought on wording, do you add more levels of sharing? Or do you just simplify the Share with: language language to Private, Share with: Anyone. **though I would like entries to visually show their sharing state, the buddy column hints at this but should be made explicit I do actually think that the Journal is the best place to expose this, especially since the way we plan to expose the feature in the UI is something like view my friend's Journal. I'm not sure exactly how or where that happens. Perhaps if we can abandon the checkbox for the multi-selection we can use that space for a public/private toggle of some kind. How about using special tags? A Publish tag seems reasonable for this, and consistent with the fact that it could live in a publish directory an HTTP server would serve. I think it's a good idea to store these states as metadata, but I also think that we need to expose the feature visually to highlight the capability and make it easier to manage. I wouldn't want kids to have to type publish into the correct field in order to share their work. I can also imagine a tags used for starred entries and other metadata (in a general sense) used by sugar. This would make them searchable as well. Yup. I don't think this works yet, but the intent has always been to allow advanced search queries by specifying key:value pairs (as in gmail). In fact, all of the filters we support should have text equvalents, eg. cat kind:image with:alice favorite:yes (or similar). This would solve one of my pet dislikes with the current solution. Once you've set up a Journal query, it's a pain to reset back to default. And the more filter options we provide the worse it would get. Ideally there would be a reset button – if selecting visual UI filter options added query text into the search field, the little (x) clear search field could be used to reset all options back to default in one click :-) This would require the reverse to be true, so as you typed in the search field, any visual UI would need to update to match the query state. Cool, but quite a tough chunk of dev work. Hmmm, actually that's not necessarily true. If you remove all visual UI feedback from the other toolbar controls, the search query string could be the feedback. Clicking, say the favourite star, would just inject favorite:yes into the query string, that would be your feedback... No other toolbar/button UI state would need to to be kept in sync (they all just inject query text). Regards, --Gary ___ 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 Marting...@garycmartin.com wrote: On 4 Jul 2009, at 03:13, Eben Eliason wrote: On Fri, Jul 3, 2009 at 7:25 PM, Gary C Marting...@garycmartin.com wrote: Devils advocate here, so just because someone was late to the realtime party, they don't get to download an otherwise openly published piece of work that could be re-published at any time by any of the temporally lucky contributors? Downloading a Journal entry would not I think you misunderstand me, as I think I'm arguing exactly the opposite. I wouldn't want to deprive people the ability to download finished works because the sharer doesn't want to open the document up for public collaboration. The distinction is important, so that it's possible to share things with others without having to make my own documents open to collaboration. OK, yes thanks, I see this issue now: I might want folks to be able to download an entry, but I might well want to work on it privately, by myself. You said it so much more succinctly that I did! allow you in anyway to edit the remote users copy, you'd just get a snapshot downloaded to your Journal as if they had performed an equivalent Send to function. Exactly. If you conflate public vs. private states for documents with the collaboration sharing scope, every public document would also be open for public collaboration, which might not be desired, and might discourage people from sharing their output. Yep. Replying to myself, always a bad sign ;-) Use case: Darn, I missed the weekly project chat meeting, AGAIN... Oooh, Bob is still online, let me see if I can download the meeting activity entry. This might not be the best example, since by definition the chat meeting is an open collaboration, with a neighborhood (for example) sharing scope. FWIW: I was assuming all chat participants has stopped the Activity (so not available in the neighbourhood), but that Bob (and his buddy icon) were still online. Yup, gotcha. My point was that, if the activity were collaboratively public already anyway, it doesn't hit the snag I was trying to bring up above. Misc supporting argument: If you default to Journal sharing OFF and make it a new separate manual public sharing UI tick box/setting (required for I'm not necessarily stating that it should be off by default (everything private). I'm simply arguing that it should be independent of the collaboration scope. What may make sense (maybe this is what you meant?) is to default all documents which become shared with the neighborhood to public, while all others would default to private. Yes that's what I was trying to say :-) default all documents which become shared with the neighborhood to public :-) Though I'd missed your point that we would need some other UI in addition to this default, to allow someone to share an entry without collaboration. Using the current Activity Share with: UI would indeed likely conflate collaboration with sharing, though it could still be worth investigating. We can explore it, though I think putting a hard separation between them might be the best way to indicate their distinctness, since the distinction might not be obvious with a label, or an icon, in the UI (assuming the controls were side by side). My thought process here was that the activity UI is the place where active collaboration happens, so that's a great place to allow one to change the collaboration sharing settings. The Journal is the place where the output goes, and the place that I show people when they choose to view my Journal. This seems like a logical place to decide which entries are public and which are private. It's possible that the separation of these will be the clearest way to indicate, without need for much teaching, the difference. On a visual note, perhaps we can come up with some unique icon for shared Journal object, and then stamp that icon on the front cover of the Journal activity icon that we show when viewing someone else's Journal. This would help reinforce the idea that the activity only shows Journal entries which have that icon toggled on. Something along the lines of 3 modes Private, Collaborate with Neighbourhood, Public Journal entry (where Collaborate with Neighbourhood was collaborative and a public Journal entry). I think combining them in one popup menu is asking for confusion... PS. I think we need to come up with some better terminology to distinguish between collaboration sharing and journal sharing. That would make this much easier to talk about. You're not kidding there :-) should we call both sharing, but differentiate it with a modifier, like collaboration vs. document, or maybe activity vs. object. This latter might be the best I've thought of so far. activity sharing is real-time collaboration; object-sharing is public Journal entries, the output. Thoughts? Better suggestions? Eben Regards, --Gary
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 Ambroisandresambr...@gmail.com wrote: On Friday 03 July 2009 02:29:56 pm Eben Eliason wrote: On Fri, Jul 3, 2009 at 10:42 AM, Gary C Marting...@garycmartin.com wrote: On 2 Jul 2009, at 14:47, Eben Eliason wrote: On Wed, Jul 1, 2009 at 1:42 PM, Aleksey Limalsr...@member.fsf.org wrote: But in that case we should provide possibility to mark objects that can be shared(I guess sharing all local objects by default is not a nice idea). Right. This would be essential. There's definitely some thought that needs to be done here. Scott had an interesting proposal which basically exposed the Journal (or some subset of it) as an RSS feed. This was really neat, because it meant we could build a UI for someone else's Journal in Sugar, populating it with that data, but also that these feeds could be shared globally, for anyone with an RSS reader to benefit from. That's a really powerful approach in my mind, and there is some starter code lying around as a proof of concept already! +1 to rss feed concept, makes life a lot easier in a heterogeneous environment. I'm still catching up on email so apologies if this has been mentioned already. But the UI for marking of entries as sharable does not necessarily need to be another Journal user-interface addition** In the simplest approach you could just extend the Activity Share with: my Neighbourhood control to mark a Journal entry as part of the RRS feed. Would need some The problem I see with this is that we're talking about two different kinds of sharing. Just because I want to make a picture I drew available for anyone to look at, or even make a photocopy of to scribble on, doesn't mean that I want to let them into a shared painting session so they can scribble on the original with me. This is the difference between sharing an activity with someone collaboratively, and sending them (a copy of) the resulting object. thought on wording, do you add more levels of sharing? Or do you just simplify the Share with: language language to Private, Share with: Anyone. **though I would like entries to visually show their sharing state, the buddy column hints at this but should be made explicit I do actually think that the Journal is the best place to expose this, especially since the way we plan to expose the feature in the UI is something like view my friend's Journal. I'm not sure exactly how or where that happens. Perhaps if we can abandon the checkbox for the multi-selection we can use that space for a public/private toggle of some kind. How about using special tags? A Publish tag seems reasonable for this, and consistent with the fact that it could live in a publish directory an HTTP server would serve. I 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 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 07/01/2009 03:48 PM, Eben Eliason wrote: On Tue, Jun 30, 2009 at 6:22 PM, Aleksey Limalsr...@member.fsf.org 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 Thu, Jul 2, 2009 at 9:29 AM, Simon Schampijersi...@schampijer.de 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 Wed, Jul 1, 2009 at 1:42 PM, Aleksey Limalsr...@member.fsf.org wrote: On Wed, Jul 01, 2009 at 09:48:23AM -0400, Eben Eliason wrote: On Tue, Jun 30, 2009 at 6:22 PM, Aleksey Limalsr...@member.fsf.org 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 of all collection links that this object participates in, means also some odd implicit job to
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 Eliasone...@laptop.org wrote: On Tue, Jun 30, 2009 at 3:43 PM, Simon Schampijersi...@schampijer.de 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 6:22 PM, Aleksey Limalsr...@member.fsf.org 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 9:46 AM, Tomeu Vizosoto...@sugarlabs.org wrote: On Wed, Jul 1, 2009 at 15:43, Eben Eliasone...@laptop.org wrote: On Tue, Jun 30, 2009 at 3:43 PM, Simon Schampijersi...@schampijer.de 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
Eben wrote: On Tue, Jun 30, 2009 at 3:43 PM, Simon Schampijersi...@schampijer.de 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 01, 2009 at 09:48:23AM -0400, Eben Eliason wrote: On Tue, Jun 30, 2009 at 6:22 PM, Aleksey Limalsr...@member.fsf.org 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
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 Limalsr...@member.fsf.org 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.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 terms 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
[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
