What’s the difference between Remove and Delete?
G ood UX design happens when you don’t notice it during or after the experience. The main goal of good UX design is to take the user on a specific mission as quickly as possible, with the least effort possible. In good UX design, very rarely do users notice the mastery they encounter, even in the most simple and most obvious interactions like, for example, deleting items.
“A user interface is like a joke. If you have to explain it, it’s not that good.” — Martin LeBlanc
Simple interactions in the world of UX can turn into user nightmares if enough attention is not paid. Let’s say you’re using Google sheets and you spent hours and hours creating the structure and formulas and adding information, and then by pure accident you click on the trash icon and poof, your work is gone.
All of us have felt this pain at least once in our lifetime, so we all know how hard it is to lose your precious work and how much anger and frustration this experience can cause. That’s why a simple action like “delete” deserves an article for itself.
Why do users delete?
To understand the difference between these two actions, first we need to understand why and what our users want to delete. This largely depends on the context, but again it could be applicable generally. In most cases, users delete because of a need for better organization or a lack of space, or to hide sensitive data, or simply because they don’t want something to be present in the UI.
What’s the difference between delete and remove?
This is a simple definition:
Remove and Delete are defined quite similarly, but the main difference between them is that delete means erase (i.e. rendered nonexistent or unrecoverable), while remove denotes take away and set aside (but kept in existence).
— The New York State
Let’s go through each in order to get a better understanding of both.
Deleting
So, let’s go through a typical flow of deleting an item:
In this flow, upon clicking “delete” the user is prompted to confirm whether they want to delete the item or not. Clicking confirm would then delete the item permanently.
This is the most common “out of the box” solution and it’s quite easy to develop. The problem with this flow is that the user’s file is permanently erased from the system and this could lead to user frustration.
Users tend to delete items accidentally but also on purpose only to realize later that they would like to reverse their actions. They may face this situation even after seeing a big warning message that their item is being deleted permanently.
Permanently deleting sensitive data should by all means be implemented as a much more complicated action because it is rarely needed.
- Easier to develop
- More storage space available
- Easier to get rid of sensitive data
- Permanently lost data
- User frustration
- Rarely needed
Removing
Here is a flow of removing an item:
Apart from being safer for the user, removing requires less effort as well. Upon clicking “remove” the item is automatically removed and a pop up message appears to inform the user that their item is moved to the trash, and an option to “undo” is available. Usually, items in trash have a “lifespan” after which they are automatically removed permanently. One good example is Apple’s iOS; it does the same when you delete a photo.
Despite being a much safer and easier experience, there is a downside to this flow. Most users are actually not even aware of the “Trash” segment, and usually they either think their data is removed permanently or they cannot find it because in most cases it is hidden.
- Losing valuable data is avoided
- Important data can be restored
- Users feel much safer
- Harder to develop
- Users are usually not aware of the “Trash”
- Harder to delete sensitive data
UX designers should avoid irreversible actions. The truth is if you add a big warning message like, “Are you really really, 100%, absolutely sure you want to delete this file?” a lot of users will still click “Yes” and later realize that they made an irreversible mistake and loose important data despite the dialog.
Good UX experience should feel safe and trustworthy — the user shouldn’t be afraid to do something, nor should user actions create a negative impact on other aspects of the application. Irrevocable actions should be “hidden” and hard to do.
Difference between "delete" and "remove" [closed]
I am writing a mobile application that will, as a part of its functionality, display a list of recorded thoughts. Now I am deciding the textual content of the menus and that left me thinking whether there is a logical difference between words remove and delete. Which one is more appropriate when speaking about taking an item off the list? I guess remove is, but why?
3 Answers 3
Delete and remove are defined quite similarly, but the main difference between them is that delete means erase (i.e. rendered nonexistent or nonrecoverable), while remove connotes take away and set aside (but kept in existence).
In your example, if the item is existent after the removal, just say remove, but if it ceases to exist, say delete.
As a side note: delete is sometimes used of computer files to mean move to trash/recycle bin (hence it is still recoverable), but that’s not a standard meaning outside of that context.
![]()
They are very similar, but the way I would make the distinction here is based on what the action does, and on the item being removed/deleted from the list.
If the item will continue to exist outside the list, I would recommend «remove», as it is being removed from the list, but the item itself is not deleted.
If the item will no longer exist, then «remove» and «delete» are essentially equivalent, although «delete» may be a bit clearer, since the user is deleting the item.
You can remove something from a collection (eg a file from a project, a folder from a library) without deleting it. If the item in question has no life outside your collection (eg a paragraph from a word document) then there’s no difference between remove and delete. But if it has such a life (eg an image file in an HTML page) then remove and delete could be different. Delete is stronger — not only stop including it in my collection to it, linking to it, whatever, but also delete it from wherever it lives.
-
Featured on Meta
Linked
Related
Hot Network Questions
Site design / logo © 2023 Stack Exchange Inc; user contributions licensed under CC BY-SA . rev 2023.3.11.43304
By clicking “Accept all cookies”, you agree Stack Exchange can store cookies on your device and disclose information in accordance with our Cookie Policy.
What’s the difference between remove and delete?
And I’m not sure which one should I use to delete a user profile?
What is the difference between the remove and delete methods in TypeORM?
![]()
![]()
1 Answer 1
- remove — Removes a given entity or array of entities. It removes all given entities in a single transaction (in the case of entity, manager is not transactional).
- delete — Deletes entities by entity id, ids or given conditions:
As stated in example here:
Which means you should use remove if it contains an array of Entities.
While you should use delete if you know the condition.
Именование переменных: "removeSmth" vs "deleteSmth"?
Глобальной разницы нет, оба слова означают «удалять». Но «remove» имеет альтернативный перевод «убирать», «снимать» и по сути имеет более мягкое значение, нежели «delete» — «стирать», «вычеркивать», «исключать».
Ну и remove более формальное слово.
- Вконтакте
Ну find я вижу как поиск с заранее известным положительным результатом, а search это есть сам процесс поиска, который может и не привести к результату. Что же касается remove и delete, то тут я вижу в первом случае устранение объекта при том, что этот объект можно вызвать повторно, а delete — удаление объекта без возможности повторного его вызова.
Это я с точки зрения лингвистики и опыта подхожу, кодеры могут со мной не согласиться.
- Вконтакте
Здесь, конечно, да, имеются в виду функции. «Именование переменных» — это я так подумал что логично было бы назвать общий вопрос, что ли 🙂
PS кроме того, во многих языках переменная может быть и функцией. В частности, JS, на котором я обычно пишу. Видимо, сказалась привычка 🙂
- Вконтакте
> Скорее всего вы имели ввиду имена методов.
Да, про это я написал чуть выше.
Вообще, здесь, похоже, очень размытая грань между remove и delete 🙂 (что если элемент списка — цельный объект? 😉 )
- Вконтакте
Я имел в виду вот что. Хорошее название для метода становится в некотором смысле дополнительной документацией.
Про функцию findSmth( what ) я предполагаю, что она вернёт мне найденный объект. Возможно, только первый найденный. Ещё я думаю, что в случае неудачи, она вернёт null или false.
От функции searchForSmth( criteria ) я буду ожидать массив (список) с результатом поиска. В случае если ничего не найдено, я думаю, такая функция должна будет вернуть пустой массив. Но не false.
Это первый шаг. Когда я вижу метод объекта с некоторым названием — даже не читая коммента (не говоря уже о документации) я могу очень быстро этот объект затестить. Если мои ожидания совпадают с действительностью — это значительно ускорит разработку.
В общем, идея состоит в том, чтоб именовать объект (функцию) так, чтоб разработчик мог получить полезную информацию. Наиболее полно мой вопрос, наверное, звучит как «Можно ли выбирая между remove… и delete… повлиять на количество полезной информации, сообщаемой потенциальному будущему хакеру моего кода, как это есть в случае с find и search?» 🙂
IMHO, вообще, если мы посмотрим на привязки английских слов к английским, а русских к русским, то разницу увидим. Удалять — это не уничтожать, не освобождать, не разрушать. В русском удалять — это удалять, отодвигать далеко. Remove, в принципе, немного соответствует слову удалять. Потому что есть такие термины removable media, или ещё что-то. Но тут нет оттенка: разрушаемый носитель. Он именно удаляемый, вынимаемый всё такое.
Так что, remove и удалить — это нечто вроде ‘убрать с глаз долой’. Поэтому, как бы и команда rm в UNIX — это же не стирание файла, а стирание ссылки на него из директории, типа — не хочу тебя видеть.
Delete — это другое. Это некая противоположность к let. И как раз носит смысл: разрушить, то что возникло, или стереть с доски, вычеркнуть из текста. Всё такое.
Опять же find и search они тоже не переводятся, как поиск, если искать смысловые привязки в английском. search — это нечто связанное с изучением, потому что research, или там научный поиск, или поиск решения. Это нечто такое, продолжающееся, не обязательно с нужным результатом. А find (второе значение основать) это нечто такое, связанное с получением результата, с обретением чего-то такого.
Вот. Можете поприменять это к программам. Мой опыт: не использую remove и delete. Использую такие выражения: form и drop. Первое от сформировать, что более соответсвует по смыслу созданию объекта в памяти, a drop — это выбросить, тоже вполне понятно, без всяких там тонкостей, да и смыслу более соответствует. Когда мы избавляемся от объекта в программе, то мы же не стираем его, не разрушаем память, в которой он находится, мы как бы просто забываем о нём, выбрасываем ссылку. Да и писать короче и ровнее: )
Ну. И в программах и в своих структурах данных я всегда делаю find в структурах данных, а search — это скорее как существительное, и прилагательное, когда надо назвать нечто поисковое: searchbot или там linesearch (при распознавании образов).