...

3 Dec 2010 - 1:37pm
3 years ago
13 replies
1515 reads
Maurice
2009

...

Comments

3 Dec 2010 - 2:06pm
Eduardo F. Ortiz
2008

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

3 Dec 2010 - 2:39pm
smitty777
2010

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

 

3 Dec 2010 - 3:05pm
dmitryn
2004

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

3 Dec 2010 - 3:05pm
blissfulguru
2010

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.

3 Dec 2010 - 3:05pm
Rhonda Ranney
2010

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

3 Dec 2010 - 3:05pm
Nils-Erik Gustafsson
2009

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. 
 

11 Jan 2011 - 9:11am
Maurice
2009

...

3 Dec 2010 - 7:10pm
Chuy Hernandez
2009

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!

3 Dec 2010 - 10:05pm
Rhonda Ranney
2010

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

7 Dec 2010 - 12:06am
cfmdesigns
2004

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.

8 Dec 2010 - 10:05am
Bailey
2009

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


3 Dec 2010 - 11:23pm
pabini
2004

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:

  1. When they're solving a design problem that hasn't been solved before.
  2. When a disruptive innovation would make a product much, much better.

4 Dec 2010 - 10:32pm
Jennifer Quigley
2008

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.

Syndicate content Get the feed