[Sugar-devel] Nobody understands "Keep"

[Eben Eliason]

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
>>>
>>>
>>
>