[Sugar-devel] Nobody understands "Keep"

[Eduardo H. Silva]

2009/7/10 Eben Eliason <eben at laptop.org>:
> On Fri, Jul 10, 2009 at 10:29 AM, Tomeu Vizoso<tomeu at sugarlabs.org> wrote:
>> On Fri, Jul 10, 2009 at 16:25, Eben Eliason<eben at laptop.org> wrote:
>>> On Fri, Jul 10, 2009 at 10:05 AM, Martin
>>> Dengler<martin at martindengler.com> 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<tomeu at sugarlabs.org> 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
> Sugar-devel at lists.sugarlabs.org
> 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