It seems like the general consensus is that there *are* use cases for
Duplicating items both across Collections and within the same
Collection (mostly for Templating).
However, adding references to items across collections and creating
custom recurrence in the calendar seem to be more basic.
However, there is still the open issue of: What does "Copy and Paste
within the same Collection mean for non-Calendar items?". For now I'm
going to recommend that we disallow this functionality for non-event
items.
In the future, we may come up with a use for this feature (ie. Create
a series of dependent tasks, Create a discussion thread, etc)
Therefore, unless there are any objections, I'm going to amend http://
bugzilla.osafoundation.org/show_bug.cgi?id=5461 with the following
recommendations by the End of Today:
Cmd/Ctrl - C/V: Copy and Paste across collections = Add a reference
to the item in the destination collection.
Cmd/Ctrl - C/V: Copy and Paste an Event within a collection = Create
a custom recurrence.
Cmd/Ctrl - D: Duplicate the item
Mimi
On Mar 22, 2006, at 3:22 PM, Katie Capps Parlante wrote:
Mimi Yin wrote:
Reference: https://bugzilla.osafoundation.org/show_bug.cgi?id=5461
Copying items between Collections is essentially the same as
DnDing (Drag and Drop) items between Collections. It adds "the
same item" to the destination Collection.
*Q.* Can anyone think of any use cases for treating Copy and Paste
between Collections as "Add Duplicates of the Copied items to the
destination Collection"?
You are starting up 4 similar projects. You want to create a very
similar task that lives in each project, but you actually want 4
different tasks (they will have different statuses as they get
completed, for example). You want to create one and then
'duplicate' the task in the other 3 collections.
We also want to support Copying and Pasting items within the same
Collection. However, if we extend the model we've established for
Copying and Pasting between Collections, C&P within a Collection
is essentially meaningless. So, after chatting with Alec and
Jeffrey briefly, we came up with the following proposal:
Create a new Edit menu item called Duplicate (Cmd/Ctrl - D) which
creates a 2nd item that is essentially identical in every way with
the original item except that the 2nd item has a different UUID
(and different "date created", "created by" values as well).
And Copy and Paste is either:
1. Disabled when C&Ping within the same Collection; OR
2. If you Copy and Paste an event on the same calendar, it create
a recurring event with custom recurrence dates (e.g. Esther's
scenario). C&P within the same Collection would be disabled for
non-event items.
If you don't want to create a custom recurrence, you can always
use the Duplicate menu item (Cmd/Ctrl - D) first and then Cut and
Paste the Duplicate.
The biggest downside of this approach is that Cmd/Ctrl - C is a
lot more common than Cmd/Ctrl - D, so users might accidentally
create a custom recurrence, when they really mean to Duplicate.
I like the proposal overall, and agree that the downside above is a
bit of a risk.
*Q. *What are use cases for using C&P to create a custom recurrence?
+ I'm a traveling salesperson. For the next 3 weeks, I'm going to
visit the same client and I take the same flight out on Monday
morning and the same flight back on Friday evening.
+ Esther's scenario: Scheduling an irregularly re-occurring board
meeting 18 times a year.
*Q. *What are use cases for Duplicate?
+ I am having a meeting with the same people in the same location
about a different topic tomorrow. I want to Duplicate today's
meeting item and re-title it for tomorrow's meeting.
Do other people have use cases? Which scenario is more common in
calendaring? Custom recurrence or Duplicate?
I think the duplicate case is going to look something like: I have
a meeting that is a little bit similar to some other meeting (some
of the same people), but not really related in any way. I copy/
paste and then delete some names, add some others. The copy/paste
is just a way of saving some typing, not implying any relationship
at all between the meetings.
Cheers,
Katie
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Design" mailing list
http://lists.osafoundation.org/mailman/listinfo/design
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Design" mailing list
http://lists.osafoundation.org/mailman/listinfo/design
