I've come across this often in our internal apps, where we have items on a list that can be taken off (removed) or eradicated from the database (deleted). So I would agree with your initial assessment. Be careful, though, as your users might not understand such a fine distinction (don't under any circumstances have a button where the label changes from Remove to Delete, for example).
Delete is the opposite of Create. It applies to objects, e.g.
"create/delete a document".
Remove is the opposite of Add. It applies to object attributes that
need a parent object in order to exist, e.g. "add a comment to/remove
a comment from a document".
The distinction between Delete and Remove should not have to do with
whether the action can be undone. When you put a document in
Trash/Recycle Bin, you are deleting it, even though the action can be
undone.
To simplify, what is the button going to do? Delete or remove? And in what context?
On Dec 3, 2010 1:50 PM, "Maurice Carty" <mo_vibes@hotmail.com> wrote: > Hi all, > > What are your thoughts on using the term "Delete" vs. "Remove"?
> > Delete = destructive? permanent? > Remove = non-destructive? Is it still there, somewhere? permanent? > > Differing people seem to have their own views or interpretations. > Your thoughts/comments are appreciated.
> > Thanks. > >
Delete = really delete an object (but it could be restored by Undo).
Remove = remove from a list or other view, but keeping the object.
Best regards,
Nils-Erik
Nils-Erik Gustafsson
GUI@cmpmail.com
-----Original Message-----
From: Maurice Carty <mo_vibes@hotmail.com>
To: gui@cmpmail.com
Sent: Fri, Dec 3, 2010 7:39 pm
Subject: [IxDA] Delete vs. Remove
Hi all,
What are your thoughts on using the term "Delete" vs. "Remove"?
Delete = destructive? permanent?
Remove = non-destructive? Is it still there, somewhere? permanent?
Differing people seem to have their own views or interpretations.
i think you can use the same word for both cases , but you need to take special care of some points like
- Consistency in all the app
- add extra text to the labels : Delete (or Remove) Table , Delete (or Remove) Row
According to what you`re saying, remove (or delete) in both cases gets the same result : Eliminates the object with no rollback , la main difference is you warn the user in the table case
Instead of divide the actions per table/Row, maybe you can replace the table wording by "remove all rows" or the table has another additional properties/values ?
After reading all the feedback and your explanation of what you are trying to accomplish...I would go with "deleting" the table and "removing" the row.... though there is no undo feature, both actions are indeed different and performed for different reasons. Therefore it makes sense to distinguish between deleting the entire table vs. removing a single row.
You could explain that any deletion or removal can not be retrieved...etc...
Either way consistancy is key.
Rhonda :)
On Dec 3, 2010 7:42 PM, "Jesus Adrian Hernandez Lozano" <jhernandez@idztech.net> wrote: > i think you can use the same word for both cases , but you need to take
> special care of some points like > > > > - Consistency in all the app > > - add extra text to the labels : Delete (or Remove) Table , Delete (or > Remove) Row >
> > > According to what you`re saying, remove (or delete) in both cases gets > the same result : Eliminates the object with no rollback , la main difference > is you warn the user in the table case
> > Instead of divide the actions per table/Row, maybe you can replace the > table wording by "remove all rows" or the table has another additional > properties/values ? > > Regards!
> > (((Plea
I agree, consistency is important, which is why I disagree with you, Rhonda. "Getting rid of" the table is the same thing as "getting rid of" all the rows in the table, so the terms should be the same; it's only a matter of degree or number where they differ.
Ultimately, I think you can stress way to much over what is often a choice that makes no real difference. If there are other "getting rid of" actions in the project, use parallel terminology. If there are other apps in the same niche, either match what they use or explicitly don't match. If there's nothing else worth paralleling or differentiating from, ask the simple question: "Will even 1% of projected users care/be confused/etc.?" If the answer is "probably not", then go with your gut. This thread has probably already expended more energy than the question was worth.
There's some good and bad advice among the foregoing comments. Context is key, as always. In this case, users are editing a table. This is something people commonly do in desktop apps that have existed for many years. In such a case, designers shouldn't invent, they should copy—that is, follow standard practice. Look at MS Word and Dreamweaver—and Google Docs, too—where you'll see that they all use Delete in both cases. But your labels should be specific: Delete Table and Delete Row. In a document-editing situation, no confirmation dialog box appears when a user deletes something—even a table. However, if this table is something users don't create themselves, it would be important to allow users to undo a delete or revert to a default state. Best not to display a confirmation message box, which would be obstructive to users' carrying on with their work. It would be much better to support undo.
These days, there are just two cases when designers should invent new ways of doing things:
When they're solving a design problem that hasn't been solved before.
When a disruptive innovation would make a product much, much better.
Specific to meaning … I use delete if somethng is thrown away, removed from a database, gone. It requires greater action to locate & restore something deleted. Remove when something is no longer catagorized or related to something else (as a list or collection perhaps.) It is still within fair reach, and you can access it again to restore its connection or relationship.Though you "remove" it still exists within a database.
Get the feed
Comments
Hi,
I think it comes down to what the action to be taken is;
a) Online shopping. A customer removes a product from their cart.
b) Communications. A user deletes a message.
In essence, it all comes down to the context in which these CTAs will live.
Hope this helps,
Eduardo
Hi Maurice,
I've come across this often in our internal apps, where we have items on a list that can be taken off (removed) or eradicated from the database (deleted). So I would agree with your initial assessment. Be careful, though, as your users might not understand such a fine distinction (don't under any circumstances have a button where the label changes from Remove to Delete, for example).
Delete is the opposite of Create. It applies to objects, e.g. "create/delete a document".
Remove is the opposite of Add. It applies to object attributes that need a parent object in order to exist, e.g. "add a comment to/remove a comment from a document".
The distinction between Delete and Remove should not have to do with whether the action can be undone. When you put a document in Trash/Recycle Bin, you are deleting it, even though the action can be undone.
Dmitry
What are you trying to do? Are you trying to delete a file or unpublish it?
Debbie
-----Original Message----- From: Maurice Carty Sent: Friday, December 03, 2010 11:00 AM To: dj@danceofthebee.com Subject: [IxDA] Delete vs. Remove
Hi all,
What are your thoughts on using the term "Delete" vs. "Remove"?
Delete = destructive? permanent? Remove = non-destructive? Is it still there, somewhere? permanent?
Differing people seem to have their own views or interpretations. Your thoughts/comments are appreciated.
Thanks.
To simplify, what is the button going to do? Delete or remove? And in what context?
On Dec 3, 2010 1:50 PM, "Maurice Carty" <mo_vibes@hotmail.com> wrote:
> Hi all,
>
> What are your thoughts on using the term "Delete" vs. "Remove"?
>
> Delete = destructive? permanent?
> Remove = non-destructive? Is it still there, somewhere? permanent?
>
> Differing people seem to have their own views or interpretations.
> Your thoughts/comments are appreciated.
>
> Thanks.
>
>
Delete = really delete an object (but it could be restored by Undo).
Remove = remove from a list or other view, but keeping the object.
Best regards,
Nils-Erik
Nils-Erik Gustafsson
GUI@cmpmail.com
-----Original Message-----
From: Maurice Carty <mo_vibes@hotmail.com>
To: gui@cmpmail.com
Sent: Fri, Dec 3, 2010 7:39 pm
Subject: [IxDA] Delete vs. Remove
Hi all,
What are your thoughts on using the term "Delete" vs. "Remove"?
Delete = destructive? permanent?
Remove = non-destructive? Is it still there, somewhere? permanent?
Differing people seem to have their own views or interpretations.
Your thoughts/comments are appreciated.
Thanks.
...
i think you can use the same word for both cases , but you need to take special care of some points like
- Consistency in all the app
- add extra text to the labels : Delete (or Remove) Table , Delete (or Remove) Row
According to what you`re saying, remove (or delete) in both cases gets the same result : Eliminates the object with no rollback , la main difference is you warn the user in the table case
Instead of divide the actions per table/Row, maybe you can replace the table wording by "remove all rows" or the table has another additional properties/values ?
Regards!
Hi Maurice,
After reading all the feedback and your explanation of what you are trying to accomplish...I would go with "deleting" the table and "removing" the row.... though there is no undo feature, both actions are indeed different and performed for different reasons. Therefore it makes sense to distinguish between deleting the entire table vs. removing a single row.
You could explain that any deletion or removal can not be retrieved...etc...
Either way consistancy is key.
Rhonda :)
On Dec 3, 2010 7:42 PM, "Jesus Adrian Hernandez Lozano" <jhernandez@idztech.net> wrote:
> i think you can use the same word for both cases , but you need to take
> special care of some points like
>
>
>
> - Consistency in all the app
>
> - add extra text to the labels : Delete (or Remove) Table , Delete (or
> Remove) Row
>
>
>
> According to what you`re saying, remove (or delete) in both cases gets
> the same result : Eliminates the object with no rollback , la main difference
> is you warn the user in the table case
>
> Instead of divide the actions per table/Row, maybe you can replace the
> table wording by "remove all rows" or the table has another additional
> properties/values ?
>
> Regards!
>
> (((Plea
I agree, consistency is important, which is why I disagree with you, Rhonda. "Getting rid of" the table is the same thing as "getting rid of" all the rows in the table, so the terms should be the same; it's only a matter of degree or number where they differ.
Ultimately, I think you can stress way to much over what is often a choice that makes no real difference. If there are other "getting rid of" actions in the project, use parallel terminology. If there are other apps in the same niche, either match what they use or explicitly don't match. If there's nothing else worth paralleling or differentiating from, ask the simple question: "Will even 1% of projected users care/be confused/etc.?" If the answer is "probably not", then go with your gut. This thread has probably already expended more energy than the question was worth.
Jim,
A side point:
"Getting rid of" a table is NOT NECESSARILY the same thing as "getting rid of" all the rows in a table. A table can still exist with zero rows.
When you have a container of objects, and all of the objects are gone, the container doesn't vanish.
--
Bailey Steinfadt
runnerbee17@gmail.com
There's some good and bad advice among the foregoing comments. Context is key, as always. In this case, users are editing a table. This is something people commonly do in desktop apps that have existed for many years. In such a case, designers shouldn't invent, they should copy—that is, follow standard practice. Look at MS Word and Dreamweaver—and Google Docs, too—where you'll see that they all use Delete in both cases. But your labels should be specific: Delete Table and Delete Row. In a document-editing situation, no confirmation dialog box appears when a user deletes something—even a table. However, if this table is something users don't create themselves, it would be important to allow users to undo a delete or revert to a default state. Best not to display a confirmation message box, which would be obstructive to users' carrying on with their work. It would be much better to support undo.
These days, there are just two cases when designers should invent new ways of doing things:
Specific to meaning … I use delete if somethng is thrown away, removed from a database, gone. It requires greater action to locate & restore something deleted. Remove when something is no longer catagorized or related to something else (as a list or collection perhaps.) It is still within fair reach, and you can access it again to restore its connection or relationship.Though you "remove" it still exists within a database.