2009/7/10 Eben Eliason <[email protected]>: > On Fri, Jul 10, 2009 at 10:29 AM, Tomeu Vizoso<[email protected]> wrote: >> On Fri, Jul 10, 2009 at 16:25, Eben Eliason<[email protected]> wrote: >>> On Fri, Jul 10, 2009 at 10:05 AM, Martin >>> Dengler<[email protected]> wrote: >>>> On Fri, Jul 10, 2009 at 10:01:19AM -0400, Eben Eliason wrote: >>>>> On Fri, Jul 10, 2009 at 5:28 AM, Tomeu Vizoso<[email protected]> wrote: >>>>> > But are you meaning that we should name the current one "Keep a copy" >>>>> > and when we have versions add "Keep"? >>>>> >>>>> No, no. I'm urging that we name it "Keep new version" now if we rename >>>>> it, so that it's meaning doesn't change down the road when versions >>>>> are introduced. >>>> >>>> "Keep new version" seems a lot closer to a description of the >>>> implementation than of the user-desired result. Unless this "new >>>> version" becomes the active one (i.e., the one upon which the user >>>> continues to work, assuming they don't close the application), isn't >>>> the result of the button press better called "Keep[ing of a] backup >>>> version"? >>> >>> I'm happy to entertain other terminology. All I'm really trying to get >>> across is that, technically, this action is strictly not what I >>> interpreted as "keep a copy" in the presence of versions, and I don't >>> want to confuse the terminology later by mixing up the terms. >>> >>> I'd be equally satisfied, I think, by finding a better term for what >>> I'm presently describing as "keep a copy", wherein a brand new tree_id >>> is assigned to the copy, detaching it from the history (and >>> collaboration scope) of the original. The fundamental issue is whether >>> or not version/collaboration history is retained with the action, so >>> let's ensure that we name both of these types of copy operations at >>> the same time, even if we only have one of them for now, so that it >>> can be extended later. >>> >>> Ben's suggestion of "checkpoint" could work. Perhaps "Keep checkpoint" >>> would be better to retain the action. You're right that it's more like >>> "keep backup version"....that is, the keep operation which retains the >>> tree_id basically writes the current state of the activity as a >>> version (the "just-now-previous" one), and allows you to continue >>> working in the "most current" one. No branching, in the traditional >>> sense, happens here. >> >> Should we discuss this in sugar-devel? Why not asking any of the >> teachers in IAEP what is more natural for them? > > Makes sense to me, as long as we can convey to them first the > distinction between the two. The problem at hand is that "keep a copy" > makes perfect sense, until you toss in this alternate action to > confuse things. > > As another note, I have another reason why I interpreted "keep a copy" > to mean "new tree_id", and not just new version. Looking at the design > mockups for the action/object views of the Journal, we designed the > object view to show only the most recent version of any object. That > is, each object is represented just once in that list. Here, it seems > like "keep a copy" should mean "give me a new object in this list"; > Keeping a version is just an action which snapshots a previous state > of the current object, without making a true "copy" of it. > > Maybe we could always refer to "versions" as "history" in Sugar (seems > logical, given the Journal metaphor!). Then, we could call what the > new tree_id case "keep a copy" as I initially suggested, and the new > version_id case "keep in history", to indicate that pressing it will > add a new listing in the history of the current object. > > Eben > >> Regards, >> >> Tomeu >> >>> Eben >>> >>>>> > Regards, >>>>> > >>>>> > Tomeu >>>>> >>>>> Eben >>>> >>>> >>> >> > _______________________________________________ > Sugar-devel mailing list > [email protected] > http://lists.sugarlabs.org/listinfo/sugar-devel > You're right eben, sorry for not thinking it through (and the current translation in pt_PT of keep is just keep in all releases).
I'd like to suggest that when an auto-save is done, to have the keep button either become unsensitive or visually change into a closed folder with the secondary palette saying "Kept X minutes ago". This is inspired by how Gmail works. Eduardo _______________________________________________ Sugar-devel mailing list [email protected] http://lists.sugarlabs.org/listinfo/sugar-devel
