Re: [sugar] adding versions to journal/datastore
Christopher Sawtell, in responded to my post in this thread, suggested that versioning would support Undo. Now _that's_ a worthwhile goal to think about -- giving kids a simple-to-use datastore undo/redo capability. mikus ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] adding versions to journal/datastore
On Wed, Oct 8, 2008 at 9:04 PM, Christopher Sawtell [EMAIL PROTECTED] wrote: I am new around here did not realise that the list server doesn't munge the addresses, my apologies. Anyway, I responded to Mikus thus:- I agree the 'effort' is theoretically trivial, what versioning provides is a new version number without the need to _remember_ that one has to create a new file name for the new version, and that, for many people, is far from trivial. Remember that in times of yore - pre 1981 - versioning was a standard feature offered by many O/Ss. These days the need for versioning has become somewhat nebulous because the various source code control systems allow one to check in and out, and to see the differences very simply. Whether or not children should have to deal with that level of complexity in order to be able to 'undo' the latest, erroneous, changes to their current 'magnum opus' is, I suppose, open to debate. We certainly don't plan on exposing them to that, unless they absolutely want it. Instead, the model will simply be along the lines of I messed up this picture, but it looked good yesterday before I scribbled on it. Let me scroll back in time through the Journal to yesterday's entry, when it still looked OK, and resume that. Previews and dates should assist the process of rediscovering old versions. Another potential option is to build versioning support into the undo/redo buttons of an activity, such that it's possible to skip back through old entries by undoing. This idea, of course, has its share of intricacies to figure out, but it could be a powerful system. - Eben -- Sincerely etc. Christopher Sawtell ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] adding versions to journal/datastore
On Wed, Oct 1, 2008 at 9:44 PM, Eben Eliason [EMAIL PROTECTED] wrote: On Mon, Sep 29, 2008 at 3:54 PM, Tomeu Vizoso [EMAIL PROTECTED] wrote: Hi Eben and other sugarites, I'm trying to find a simple way to add some version support to the journal, but for that I need to know what's the sweetest spot (no pun intended) between value and complexity. I'm thinking about making the next notable changes to the UI: - the journal list shows one line per interesting entry. Interesting entries are tips of branches and a branch is created every time the user clicks the Keep button or resumes an entry. Activities can also choose to make a branch in behalf of the user at any moment, for example just before the user selects Erase all in Paint, I'm want to become a bit clearer with your terminology, because I'm not sure that branches line up in my mind. I used the term branch just to put the idea in known terms, but the important part is in which occasions an entry is marked as interesting. I think I didn't do a good job at explaining myself, so will try again: In the current Journal, we always overwrite older information except when the user clicks the 'Keep' button. I think we agree this is not the most desirable situation, as being able to inspect the intermediate states is important for reflecting about the creation process. If we stop overwriting and keep updating entries as often as we do now, we'll have lots of more entries in the journal list. And most of them won't be relevant to the user. We can improve this situation by showing just a subset of all the stored entries in the list view and let the user only access all the entries in the detailed view of an entry. How do we determine which are the entries in this subset of interesting entries? - we let the user tell us with the Keep button, - consider the last entry written in a session as interesting, - mark (or rather, don't unmark/overwrite) an entry as interesting when it is resumed. Regards, Tomeu ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] adding versions to journal/datastore
On Thu, Oct 2, 2008 at 3:55 PM, Greg Smith [EMAIL PROTECTED] wrote: Hi Guys, This is a great discussion and very helpful design interaction! Just sampling a few items on this thread I have two high level comments: 1 - The primary requirement for the Journal is to never lose data. I think there are some known issues with the datastore but I'm not sure where they are tracked. The most important case is to not lose data when the users exits the activity or keeps. The secondary case is to do interim saves so that if the XO or activity crashes or the XO is shut down we still save something recent. Please don't try to extend the Journal paradigm until we nail, provably and completely. Well, precisely the proposed addition is for stopping losing so much data ;) We are currently overwriting lots of potentially useful work, the proposed scheme tries to minimize the lost data without taking up too much space or making the journal more cumbersome to use. 2 - In terms of better organization of Journal data. It hasn't come up as a problem from the field in my experience. Erik and Elana have said that they have heard of severe difficulties to find stuff in the journal, to the point of saying that data is effectively lost because of this. We haven't managed to get concrete issues from that feedback yet, perhaps you could take up that task and give something more actionable to developers? That said, versions have little to do with this issue. It can still be improved and making it easier to optimize the available storage seems like a high priority based on NAND full issues. We should still consider better data organization and access, especially if we can make something that really resonates with kids. We especially need to address saving and accessing in the collaborative creation process. Agreed, but this doesn't have much to do with versions, does it? The concern I have with the discussion so far is that its way too complicated. I don't think any K - 6 grade kid will have a good conception of a tree or hierarchy. It will be incomprehensible and work like black magic to them. No tree or hierarchy will be exposed in the UI. We just leave around more intermediate entries and make accessible in a popup a list of older versions of an entry. Even the idea that the newest is at the top is not universal (see: http://lists.laptop.org/pipermail/localization/2008-September/001583.html). I can agree with that, but we need to put them somewhere ;) The notion of size or quantity is not the same for a kid as an adult either. One Piaget experiment I read about showed that most kids below a certain age would assume that 5 items spread far apart were more than 6 items placed close together. Throw in many items of the same screen space each with a different size in MBs and they will completely miss that one quantity is more than the other. How can we change the UI to better acknowledge this fact? I don't mean to make this impossible to design. I suggest that we make sure we nail the reliability piece first. Then come up with some experiments which cover use cases and include mock-ups. Then test them with kids. If we design this based on our own understanding of what works for us, we can make something useful and interesting but it may not be optimized for kids. Optimizing for the ways kid's minds work is something we can do better than anyone else, if we can get good at it. I don't think that we have current plans to change the Journal UI substantially in the next release. But if we had well-focused feedback, we may be able to suggest UI changes that improve the user experience. My 2 cents. I apologize for being such a skeptic. Lately I feel like I'm swimming up stream. If the river is flowing towards consensus and we can make something short term which we can learn from, don't let me slow you down. I don't think it's time to be nor skeptic nor the opposite. We should instead work now on finding clear links between issues on the user side and work to do during the next release. That's how we'll be able to most effectively use the existing resources. And just for the record, I'm ok with not doing versions for 0.84, but I do think we should move forward on the discussions now. Regards, Tomeu ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] adding versions to journal/datastore
On Fri, Oct 3, 2008 at 12:08 AM, Marco Pesenti Gritti [EMAIL PROTECTED] wrote: I suggest that we proceed as following: 1 Next week we are planning to land Tomeu datastore rewrite. It's a drop in replacement with no API changes, which should allow us to have a solid, simple datastore in 0.84 and to start working on all the the small, but fundamental UI improvements which we delayed in the last year waiting for perfect DS to show up. (better automatic tagging by activities, encourage to title entries, fine scrolling view, open the last document by default when launching activities, performance improvements and a bunch of other cool stuff). 2 Scott, Erik, Tomeu, Michael, Chris (am I missing anyone? :P) are all racing to design a more powerful datastore which would provide versions, advanced tagging and better compatibility with POSIX. I'm particularly excited about the possibility to collaborate with GNOME on it, it would be a great sinergy: looking forward for the result of the summit! These efforts are more invasive, still being researched, and will likely require API changes. We should encourage them, give them enough time to mature and to reach consensus inside the community. The winner should land when it's ready and compatibly with the project schedule. In particular, the deadline for new modules proposal is at the end of the week. I'm ok with this, but would like to say that I don't feel like racing at all. As I have said before, I feel overwhelmed by all the work left to do and the exiguous resources available, so you can imagine that I don't have energy to waste in a race. Is only that though I think that OLPC should have hired someone to properly work on the DataStore that hasn't happened to date (at least that I know of), so I decided to take action so we don't ship the same outdated DS as we have been doing until date. I'm more than ok if OLPC decided to start dedicating new resources to the DS and Journal and will (very!) happily move to do other stuff if required. I'm pretty much finished with my DS replacement for this release, so I'm ok with keeping it in the drawer just in case we don't have anything better at time for 0.84. Regards, Tomeu ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] adding versions to journal/datastore
I'm not comfortable with the value of supporting multiple versions within the datastore. Why should the run-of-the-mill user need to refer to obsolete versions of the information in the datastore ? being able to inspect the intermediate states is important for reflecting about the creation process. Here is the first cogent argument I've seen in favor of multiple versions. But how is this inspection to take place? The principal tool available on the XO is 'diff' -- and even that was being omitted from builds for a while. I expect many of the systems running Sugar to have small screens. Those would not be enough for a side-by-side presentation of before and after. The question is - how often would reflecting on the creation process be used. If infrequently, the user himself could perform the necessary versioning - at the first stopping point, enter 'Poem about clouds, v.1' in the Title field in Write, and press 'keep'. At the next stopping point, replace the '1' in the Title with '2' and press 'keep' again, etc. The result is a set of versions, each stored with a different name. The point I am making is that by providing versioning in the datastore, what is saved is additional effort by the user. Is that savings big enough to justify the implementing of versioning ? mikus ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] adding versions to journal/datastore
Hi Guys, This is a great discussion and very helpful design interaction! Just sampling a few items on this thread I have two high level comments: 1 - The primary requirement for the Journal is to never lose data. I think there are some known issues with the datastore but I'm not sure where they are tracked. The most important case is to not lose data when the users exits the activity or keeps. The secondary case is to do interim saves so that if the XO or activity crashes or the XO is shut down we still save something recent. Please don't try to extend the Journal paradigm until we nail, provably and completely. 2 - In terms of better organization of Journal data. It hasn't come up as a problem from the field in my experience. It can still be improved and making it easier to optimize the available storage seems like a high priority based on NAND full issues. We should still consider better data organization and access, especially if we can make something that really resonates with kids. We especially need to address saving and accessing in the collaborative creation process. The concern I have with the discussion so far is that its way too complicated. I don't think any K - 6 grade kid will have a good conception of a tree or hierarchy. It will be incomprehensible and work like black magic to them. Even the idea that the newest is at the top is not universal (see: http://lists.laptop.org/pipermail/localization/2008-September/001583.html). The notion of size or quantity is not the same for a kid as an adult either. One Piaget experiment I read about showed that most kids below a certain age would assume that 5 items spread far apart were more than 6 items placed close together. Throw in many items of the same screen space each with a different size in MBs and they will completely miss that one quantity is more than the other. I don't mean to make this impossible to design. I suggest that we make sure we nail the reliability piece first. Then come up with some experiments which cover use cases and include mock-ups. Then test them with kids. If we design this based on our own understanding of what works for us, we can make something useful and interesting but it may not be optimized for kids. Optimizing for the ways kid's minds work is something we can do better than anyone else, if we can get good at it. My 2 cents. I apologize for being such a skeptic. Lately I feel like I'm swimming up stream. If the river is flowing towards consensus and we can make something short term which we can learn from, don't let me slow you down. Thanks, Greg S ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] adding versions to journal/datastore
On Thu, Oct 2, 2008 at 3:55 PM, Greg Smith [EMAIL PROTECTED] wrote: Hi Guys, This is a great discussion and very helpful design interaction! Just sampling a few items on this thread I have two high level comments: 1 - The primary requirement for the Journal is to never lose data. I think there are some known issues with the datastore but I'm not sure where they are tracked. The most important case is to not lose data when the users exits the activity or keeps. The secondary case is to do interim saves so that if the XO or activity crashes or the XO is shut down we still save something recent. Please don't try to extend the Journal paradigm until we nail, provably and completely. 2 - In terms of better organization of Journal data. It hasn't come up as a problem from the field in my experience. It can still be improved and making it easier to optimize the available storage seems like a high priority based on NAND full issues. We should still consider better data organization and access, especially if we can make something that really resonates with kids. We especially need to address saving and accessing in the collaborative creation process. The concern I have with the discussion so far is that its way too complicated. I don't think any K - 6 grade kid will have a good conception of a tree or hierarchy. It will be incomprehensible and work like black magic to them. Even the idea that the newest is at the top is not universal (see: http://lists.laptop.org/pipermail/localization/2008-September/001583.html). The notion of size or quantity is not the same for a kid as an adult either. One Piaget experiment I read about showed that most kids below a certain age would assume that 5 items spread far apart were more than 6 items placed close together. Throw in many items of the same screen space each with a different size in MBs and they will completely miss that one quantity is more than the other. I don't mean to make this impossible to design. I suggest that we make sure we nail the reliability piece first. Then come up with some experiments which cover use cases and include mock-ups. Then test them with kids. If we design this based on our own understanding of what works for us, we can make something useful and interesting but it may not be optimized for kids. Optimizing for the ways kid's minds work is something we can do better than anyone else, if we can get good at it. My 2 cents. I apologize for being such a skeptic. Lately I feel like I'm swimming up stream. If the river is flowing towards consensus and we can make something short term which we can learn from, don't let me slow you down. A huge +1 by me on this, Greg. Despite being the one that incouraged Tomeu to explore versions... Marco ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] adding versions to journal/datastore
1 - The primary requirement for the Journal is to never lose data. I Say what? Maybe one could argue that this is the primary requirement for the datastore, but the Journal is there primarily as a place of reflection. The fact that the datastore has been problematic and that the Journal is so underdeveloped relative to our goals may account for the fact that feedback from the field has been so narrow. -walter -- Walter Bender Sugar Labs http://www.sugarlabs.org ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] adding versions to journal/datastore
On Thu, Oct 2, 2008 at 12:57 PM, Walter Bender [EMAIL PROTECTED] wrote: 1 - The primary requirement for the Journal is to never lose data. I Say what? Maybe one could argue that this is the primary requirement for the datastore, but the Journal is there primarily as a place of reflection. The fact that the datastore has been problematic and that the Journal is so underdeveloped relative to our goals may account for the fact that feedback from the field has been so narrow. ++ -walter -- Walter Bender Sugar Labs http://www.sugarlabs.org ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] adding versions to journal/datastore
On Mon, Sep 29, 2008 at 3:54 PM, Tomeu Vizoso [EMAIL PROTECTED] wrote: Hi Eben and other sugarites, I'm trying to find a simple way to add some version support to the journal, but for that I need to know what's the sweetest spot (no pun intended) between value and complexity. I'm thinking about making the next notable changes to the UI: - the journal list shows one line per interesting entry. Interesting entries are tips of branches and a branch is created every time the user clicks the Keep button or resumes an entry. Activities can also choose to make a branch in behalf of the user at any moment, for example just before the user selects Erase all in Paint, I'm want to become a bit clearer with your terminology, because I'm not sure that branches line up in my mind. I agree that we could/should have a number of incremental saves which are created within a given activity session. The latest of these would be promoted to a new interesting entry should the activity crash, or the machine restart, etc. I agree that upon closing an activity session, or pressing the keep button, a new interesting entry is created, also. I'm unsure, however, that each of these entries represents the tip of a branch, or that only the tip should be shown. Should a branch only be created when the user duplicates an entry or keeps a copy? A branch would certainly be created when resuming an old entry (not the tip/top entry), but would you branch when the top entry itself is resumed? Also, to clarify, in your vision would resuming a given activity instance (always from the tip, let's assume) several times result in a new interesting entry for each, or would you collapse it into a single entry unless a branch is made? While this results in fewer entries in the Journal, it defeats the idea of the Journal as a historical record of versions, instead making it a flat folder sorted by modification date. - in the detailed view of an entry, all its ancestors are displayed in a list, including non-interesting entries, The latest designs actually include a popup menu in place of the date, which allows one to select versions of the document by date without exposing the whole list permanently in the view. Ideally, this list would include icons which indicate those which have been starred, so that digging through a potentially long history is easier to manage. Walter, could you elaborate on your comment? - Eben - and that's it ;) Eben: is that too simple? If it's enough, I'll propose an API for it. Thanks, Tomeu ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] adding versions to journal/datastore
Walter, could you elaborate on your comment? My comment was in regard to the anticipated additional complexity we may run into if/when we have versioning between multiple users, as would be dictated by most of the bulletin board schemes. Not sure if Tomeu's model will work, but it doesn't seem a bad first step. -walter -- Walter Bender Sugar Labs http://www.sugarlabs.org ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] adding versions to journal/datastore
On Wed, Oct 1, 2008 at 3:49 PM, Walter Bender [EMAIL PROTECTED] wrote: Walter, could you elaborate on your comment? My comment was in regard to the anticipated additional complexity we may run into if/when we have versioning between multiple users, as would be dictated by most of the bulletin board schemes. Not sure if Tomeu's model will work, but it doesn't seem a bad first step. I see. I think we partially circumvent the complexities by restricting the notion of versions to, in the end, a flattened tree. That is, the user isn't concerned with the details of branching structure. Instead, the most recent version (from any branch) I've resumed is the one that sits at the top of my Journal. This is consistent with the Journal as a time-based structure, because the tip of that new branch I created was created last in the timeline. When you have several kids, potentially with different versions of the same activity, they can all get back together, do manual merges, and then continue work in whichever instance they choose. When they all stop working on that implicitly agreed upon true version, that then becomes the tip, and the latest entry for all of them in the Journal. This model does, of course, eliminate (at least with the current UI proposal) potential advantages of a truly hierarchical versioning scheme, but I think it simplifies specifically to the point you raised earlier, which is that the last thing I did will be the most important thing to me. - Eben PS. The one place this causes problems is when you go back to an old version, rename it with the intent to use it as a base for a completely different project, and then work from there. In this case, you really want to have a new root node, instead of a new version. We should discuss the implications here, and if we might want to create a copy (a new root node that contains the contents of the copied node) on rename. -walter -- Walter Bender Sugar Labs http://www.sugarlabs.org ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] adding versions to journal/datastore
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I very much like Tomeu's version model, but I am also unsure whether I have interpreted it correctly. My feeling is that each object in the Journal is associated with a tree of versions. The tree has one node with no ancestors: the root node, which represents the initial version. The tree also has at one or more nodes with no children: these are the leaf or tip nodes, which represent the most recent versions. Resuming any version and editing it produces a new node whose ancestor is the node of the version that was resumed. An editing session that contains many incremental saves may produce a long chain of such nodes. ~From a user interface perspective, I think the idea is extremely simple. Each object is actually a leaf from the version tree, and the detail page of an object shows its predecessors. This does not conflict with the Actions view of the Journal or the Objects view. The history of an object is only visible in its detail page. Under normal circumstances, editing an object causes that object to move up toward the top of the Objects view, but does not cause any duplication. Keep also does not induce a duplication; it just ensures that a new leaf node is made for the current state. The only way to duplicate an Object is to explicitly resume an old version from the version history in the details view. When that resumed instance is saved, either automatically or through the Keep button, a new leaf node is created, and so a new entry appears in the Objects view. Adopting this idea would make the current Journal behave like the future-designs Objects view, with each object appearing only once, rather than once for every time it has been edited. We may then add a separate Action view to complete the future-Journal. - --Ben -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkjj2qIACgkQUJT6e6HFtqRRIACdF+5ZOi/+qe6mPXCfS7OE3RYz 4GYAoJA3mpl+3HbKMi2fiUHRED1BWfEj =NZQm -END PGP SIGNATURE- ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
[sugar] adding versions to journal/datastore
Hi Eben and other sugarites, I'm trying to find a simple way to add some version support to the journal, but for that I need to know what's the sweetest spot (no pun intended) between value and complexity. I'm thinking about making the next notable changes to the UI: - the journal list shows one line per interesting entry. Interesting entries are tips of branches and a branch is created every time the user clicks the Keep button or resumes an entry. Activities can also choose to make a branch in behalf of the user at any moment, for example just before the user selects Erase all in Paint, - in the detailed view of an entry, all its ancestors are displayed in a list, including non-interesting entries, - and that's it ;) Eben: is that too simple? If it's enough, I'll propose an API for it. Thanks, Tomeu ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] adding versions to journal/datastore
From the perspective of a single user, I don't think it is too simple. I cannot imagine a scenario where the most recent is not the preferred default. -walter On Mon, Sep 29, 2008 at 3:54 PM, Tomeu Vizoso [EMAIL PROTECTED] wrote: Hi Eben and other sugarites, I'm trying to find a simple way to add some version support to the journal, but for that I need to know what's the sweetest spot (no pun intended) between value and complexity. I'm thinking about making the next notable changes to the UI: - the journal list shows one line per interesting entry. Interesting entries are tips of branches and a branch is created every time the user clicks the Keep button or resumes an entry. Activities can also choose to make a branch in behalf of the user at any moment, for example just before the user selects Erase all in Paint, - in the detailed view of an entry, all its ancestors are displayed in a list, including non-interesting entries, - and that's it ;) Eben: is that too simple? If it's enough, I'll propose an API for it. Thanks, Tomeu ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar -- Walter Bender Sugar Labs http://www.sugarlabs.org ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
