[Dev] Engineering feedback on item deletion and removal
chao at osafoundation.org
Mon Nov 1 15:05:21 PST 2004
Thanks for your well thought out proposal. The simplified model was
close to what I had proposed initially too (but I still had In and Out
as library collections). I think we added the ability the move items to
the trash, even when you're not in the "All" collection because:
1) that's the right behavior for "junk". You always want to allow items
to be marked as spam, regardless of what collection you're in, and for
the item to be removed from all collections when "junked"
2) Toggling the menu item (be it from the menu bar or the context menu)
from "move to trash" (if you're in a Library Collection ) and "remove"
(User defined collections) was thought to be more confusing than just
having two different menu items for the two different tasks.
3) Why not allow users to choose where reasonable between delete vs.
remove? They may want to either operation on different occasions. It's
only when there's only one specific affordance (e.g. delete key) that
we need to choose between whether remove vs. trash is the "natural"
operation for the user
Mimi, Sheila or Mitch, anything to add/modify?
On Nov 1, 2004, at 9:19 AM, Donn Denman wrote:
> I'd like to propose a simplified model for item deletion and removal,
> that only has one operation: Remove. I was inspired by iPhoto, which
> supports non-silo collections which are a simplified form of our User
> Defined collections. I think having a single operation makes both the
> UI and the implementation simpler.
> Here's how it works. In general, removing an item just removes it
> from that collection. The item can still exist in other collections.
> It doesn't matter if the item was explicitly added to the collection,
> or implicitly through a query rule. There is one exception: the All
> collection. Since "All" contains every item, removal from All removes
> from all collections, and puts the item in the Trash.
> The Details, using the terms from the ItemRemovalAndDeletion Wiki:
> * The "Remove" operation is available on any collection.
> * The "All" collection is the only Library collection.
> * Removing an item from a Removal collection (Trash or Junk)
> removes it from the Repository
> * Removing an item from a Library collection (All) puts the item in
> a Removal collection (the Trash)
> * Removing an item from any other collection simply removes it from
> that collection
> * All other affordances map onto Remove: Cut, Clear, the delete
> key, dragging out of a collection, etc
> The down side to this proposal is that it's harder to delete an item,
> because you have to remove it from the "All" collection. I think this
> is OK, given that we have a system based on a robust capable
> repository for our data. The user may want to periodically go to
> "All" and grab a bunch of older items to remove. The Archive
> collection (post Kibble) can help with this cleanup - items that are
> neglected end up in the Archive, and they are easy to get rid of.
> The up side is that it's very easy to remove things from any
> collection - there's only one choice. There's never any confusion
> about what the different affordances do.
> I think we should start with this simple model, and if we decide we
> need a shortcut to actually Trash/Delete an item then we can add that,
> and we get back to the model proposed in the ItemRemovalAndDeletion
> - Donn
> On Oct 13, 2004, at 11:09 AM, Donn Denman wrote:
>> This looks like a very well thought out design for disposing of items.
>> Overall, I think it looks really good. But my initial reaction was
>> that it's too complicated - why do we need both deletion and removal
>> operations? Reading further, I see that our Item Collections need a
>> "remove" operation that's independent of deletion. For User Defined
>> collections, removing the item from the collection is very different
>> from deleting the item altogether. You are just excluding it from
>> that group of items. But "Library" collections are more automatic -
>> they don't really have an exclusions list so removing the item must
>> be done with deletion. This all makes sense to me, and it looks like
>> the model of the Trash is good and consistent.
>> Detailed Notes
>> Chandler has a "Delete" menu item in the Edit menu. I assume that it
>> does the same thing that the delete key does, since the delete key is
>> the keyboard accelerator for the delete menu item.
>> I'm wondering how we'll be implementing the Removal collections.
>> Since the items are still in the repository, all our queries will
>> find them. So we'll need to update our queries to not include them
>> somehow. Maybe there's a better way to do this than simply adding an
>> extra rule to each query. Ideally when we move items to a removal
>> collection, we'd actually move them to another section of the
>> repository which we can exclude from our normal queries. But these
>> are implementation details that don't really have anything to do with
>> the UI design, and should probably be moved to a different discussion
>> - Donn Denman
>> On Oct 12, 2004, at 2:13 PM, Chih-Chao Lam wrote:
>>> I've updated the page based on review comments from Mitch.
>>> Hopefully, this will make it more easily understood by everyone.
>>> On Oct 12, 2004, at 9:18 AM, Katie Capps Parlante wrote:
>>>> The design team has been working on a spec for item deletion and
>>>> removal (from item collections). It would be great to get the cpia
>>>> folks to take a look at the spec and give feedback (and anyone else
>>>> who is interested).
>>>> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
>>>> Open Source Applications Foundation "Dev" mailing list
>>> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
>>> Open Source Applications Foundation "Dev" mailing list
>> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
>> Open Source Applications Foundation "Dev" mailing list
More information about the Dev