#3941 NORM Never A: "Keep" buton should be renamed to "Keep now" and have a secondary option "Keep a copy"

[Zarro Boogs per Child]

#3941: "Keep" buton should be renamed to "Keep now" and have a secondary option
"Keep a copy"
-------------------------------+--------------------------------------------
  Reporter:  HoboPrimate       |       Owner:  Eben          
      Type:  defect            |      Status:  new           
  Priority:  normal            |   Milestone:  Never Assigned
 Component:  interface-design  |     Version:                
Resolution:                    |    Keywords:                
  Verified:  0                 |  
-------------------------------+--------------------------------------------

Comment(by Eben):

 Both of these have interesting implications in collaborative activities,
 but I agree with both.

 Replying to [ticket:3941 HoboPrimate]:
 > After a discussion on IRC:
 >
 >  1. It's a good idea to rename the Keep button on activities as "Keep
 now". This makes its function more clear, that it is an explicit save of
 the current state, and hints to the user that otherwise the activity takes
 care of keeping by itself.

 I think this is a good clarification.  When pressing "keep now", I'd
 expect that only the person who does so gets a version in the Journal.  Of
 course, if that person later resumes the activity it would still have it's
 associated collaboration scope, and others could join that version and
 obtain it themselves, implicitly.  I think this comes naturally, as our
 collaboration model is based on the idea that the version histories of
 individuals may be out of sync, but their choice to synchronously
 collaborate on any one of those at any time is always possible.

 >  2. It would also have a secondary palette with "Keep a copy", which
 would save an independent copy of the current state of the activity on the
 Journal. My sugestion, it would be named as "<the current name of the
 activity> copy #1". If an activity of that name already exists in the
 Journal.

 This one is less straightforward in the collaborative space.  I think it's
 clear that the idea of a "copy" on our system means an activity having the
 same internal state but a different activity ID (Probably a different
 title, too, but the activity ID is the deciding identifier).  As such,
 "Keep a copy" should create a new entry in the Journal, likely with a name
 as specified above, and having a new activity ID.  What's less clear is
 the scope that entry should have.  Unlike the "keep now" case, it actually
 seems that a private copy is the way to go, since clicking the "keep a
 copy" is a personal gesture.  The scope could always be broadened later.

 So, in the end, the idea is that the action which retains the same
 activity ID also retains its associated collaboration and scope.  The
 action that results in a new activity ID creates a private copy.  Does
 this logic make sense?

-- 
Ticket URL: <https://dev.laptop.org/ticket/3941#comment:2>
One Laptop Per Child <https://dev.laptop.org>
OLPC bug tracking system