Вопрос UX: лучше иметь "серьезное удаление" или иметь "мусор",

Я разрабатываю приложение, которое позволяет пользователю управлять отдельными точками данных. Одна из вещей, которую мои пользователи захотят сделать, это "удалить", но что это значит?

Для веб-приложения лучше представить пользователю возможность иметь серьезное удаление или использовать систему "trash"?

В разделе "серьезное удаление" (хотелось бы знать, есть ли лучшее имя для этого...), вы нажимаете "delete", а затем пользователь предупреждается "это окончательное и трагическое действие. После этого вы будете не сможет получить имя -интересное имя точки данных здесь, даже если вы плачете..." Затем, если они нажмут кнопку delete... ну, это действительно исчезнет навсегда.

В рамках модели "мусор" вы никогда не верите, что пользователь действительно хочет удалить... вместо этого вы удаляете точку данных с "основного дисплея" и помещаете в ведро под названием "мусор". Это получает его от пользователей, что они обычно хотят, но они могут вернуть его, если они совершают ошибку. Очевидно, именно так ушло большинство операционных систем.

Преимущества "серьезного удаления":

Легко реализовать
Легко объяснить пользователям

К недостаткам "серьезного удаления" относятся:

Это может быть трагически окончательно
иногда, кошки ходят по клавишам

Преимущества системы "мусор":

пользователь в безопасности от себя.
массовые методы, такие как "удалить связку сразу", имеют больше смысла
сохраняет головные боли поддержки

Недостатками системы "мусор" являются:

Для конфиденциальных данных вы создаете иллюзию уничтожения. Пользователи считают, что что-то ушло, но это не так.
Множество тонких различий усложняет реализацию.
Вы "в конечном итоге" удалите содержимое корзины?

Мой вопрос в том, какой из них является правильным шаблоном проектирования для современных веб-приложений? Как работает функция "архив"? Вот как работает gmail. Дайте достаточно обсуждения, чтобы оправдать ваш ответ... Было бы интересно указать на некоторые соответствующие исследования.

-Ft

Ответ 1

Я думаю, вы довольно хорошо обобщили плюсы и минусы модели мусора:

Pro: В целом, лучше для пользователя.
Con: В целом, проще для разработчика.

Для специалиста по юзабилити, такого как я, это не проблема. Что касается Im, то разработчики должны работать над тем, чтобы сделать жизнь проще для пользователей. Честно говоря, пока у веб-приложений нет возможностей Undo, таких как мусор, я не думаю, что мы можем считать их пригодными для использования. Время, которое веб-приложения догоняют до 1984 года.

Несколько других деталей:

Другим преимуществом модели мусора является способность устранить необходимость в сообщении подтверждения в большинстве случаев. Подавляющее большинство времени, пользователь удаляет что-то намеренно, поэтому добавление дополнительного сообщения с подтверждением обычно добавляет к ним работу. Хуже того, у них появляется привычка быстро удалять ОК, что обобщает другие подтверждения, которые они действительно лучше читают. См. http://alistapart.com/articles/neveruseawarning.
Часть красоты метафоры мусора заключается в том, что она предлагает пользователю, что удаление не является постоянным. Подобно физической корзине, объекты могут быть восстановлены. Если вы показываете мусор, очевидно, достаточно на вашей странице (чтобы пользователи поняли, что могут открыть его), и включите изображение мусора в виде значка рядом с пунктом меню "Удалить", которого должно быть достаточно, чтобы указать, что удаление не уничтожает, а скорее перемещает вещи в корзину.
Вероятно, он допустим, чтобы уничтожить самые старые удаления в корзине, если есть соображения производительности. Это опять-таки согласуется с метафорой метафора: пользователи могут предвидеть, что рано или поздно "кто-то" собирается очистить корзину. Я не думаю, что пользователи позаботятся, если мусор никогда не опустеет. Если им нужно по-настоящему уничтожить что-то чувствительное, вы можете предоставить ему явную процедуру (например, удалить что-то уже в корзине).

Ответ 2

Вот вам подходящая статья. Он больше ориентирован на бизнес-сценарии, но он может применяться где угодно.

Не удалять, просто не.

Ответ 3

В моем личном идиосинкразическом представлении каждое необратимое действие является серьезной ошибкой дизайна. Эти "Вы ДЕЙСТВИТЕЛЬНО, АБСОЛЮТНО, ПОЗИТИВНО уверены?" ящики сообщений являются чистым дерьмом, потому что пользователь очень быстро подготовлен, чтобы просто нажать "ОК" и сделать с ним. Фактически, я потерял важные данные, несмотря на такие диалоги несколько раз.

Другими словами: эти диалоговые окна не добавляют рабочий отказоустойчивый барьер, а просто барьер юзабилити.

Даже у систем мусора есть эта проблема (они просто откладывают момент); лучшее решение с точки зрения удобства использования - бесконечная история. Разумеется, реализация этого может привести к снижению затрат (например, с точки зрения использования памяти).

Постоянное удаление конфиденциальных данных может (и должно!) всеми средствами быть реализовано как гораздо более сложное действие: оно редко требуется. Единственная проблема заключается в том, чтобы дать пользователю понять, что данные обычно не теряются. Использование истории вместо мусора может помочь здесь: мусор может быть неправильно понят как постоянное удаление, а (видимая) история действий не дает этой иллюзии безопасности.

Ответ 4

Мое мнение таково, что на самом деле нет причин для жесткого удаления всего, что может быть важно для кого-то. По моему опыту, боль от необходимости делать резервное копирование на магнитной ленте, потому что пользователь понял, что они удалили что-то на прошлой неделе, что им нужно, легко разрешается с помощью флага "IsActive" или "IsDeleted" в записях, которые пользователь мог бы мягко удалить.

Ответ 5

Полностью зависит от контекста.

Если это легко обратимое действие, просто удалите его, вам может даже не понадобиться подтверждение
Если вы можете потерять много данных, возможно, будет храниться "хранилище временных удаленных элементов".

Ответ 6

Я не вижу, что презентация приложения (веб-приложение или нет) является основным драйвером для этого решения. Меня больше интересует ценность данных, его простота отдыха и затраты на содержание и ведение домашнего хозяйства.

Я чувствую, что, когда ваше приложение действует как хранилище ценных данных, предпочтительнее использовать delete-through-trash.