Вставлю свою копеечку...
Нет, такой диалог не нужен! Зачем? Если пользователь нажал Del он на автомате нажмет Ok и все равно расстроиться из-за потерянной информации. Лишний клик мышкой не защитит, а только увеличит раздражение. Надо бережно относиться к информации пользователя - за функции "удалить безвозвратно" надо удалять программистов.
Вы же понимаете что всё это в "идеале". В реальности если постоянно делать скажем бекапинг базы и прочих данных, то вскоре винт пользователя переполниться и... ничего хорошего из этого не выйдет..
Паковать, делать инкрементальные бекапы, разрабытывать новые алгоритмы.
Бекапы... Инкриментные бекапы... Это на каких базах? Базе студентов ВУЗа? Больше примеров адекватных не придумал.
Вы как себе представляете, например, восстановление накладной, на товар, который неделю назад отправлен в экспедицию?
Или восстановить отсчеты датчиков, мммм... Давления, какой то установки, недельной давности. По данным которых уже построены отчеты и приняты управляющие и инженерные меры.
Считаю, удаление очень удачно реализовано в 1С Предприятии(не реклама). Но не всегда подходит. Например, в складских учетных системах, когда товар захвачен помеченной на удаление записью, получается подвисшим, где-то между ментальным полем Земли и записью в БД....
У многих банков целые направления кредитования закрываются из-за убыточности.
Это показывает уровень образованности и развитости наших банкиров. Что такое скоринг и скоринг системы, они явно не знают. Жаль... Жаль, что такие банки еще где-то работают.
А теперь к сути темы.
1. Нужно отталкиваться от того какие функции выполняет приложение, в какой среде работает и т.д. Универсального совета нет.
Что необходимо для одного, возможно не совместимо с другим.
2. По поводу ошибок и вывода оных в модальных формах. Ошибки нужно прежде всего разделить. Есть ошибки кода в программе, есть логические ошибки(например, оператор работает с не актуализированными данными), есть ошибки оператора(которых тоже довольно много)...
К каждому классу ошибок нужно подходить по-своему. Тоже нет универсального рецепта.
Да, ошибки программиста, мало интересны пользователю, так же как и наоборот. Стратегию обработок этих ошибок тоже нужно выбирать под конкретную задачу.
Если вы работаете в конторе под которую и пишите, то и трафик внутрисетевой можно погонять. Если софт распространяется не управляемо, то извините, но не нужно смотреть на сектантов мак-фака из "свободной" пиндосии. Еще очень много людей которые каждый мегабайт считают.(яркий пример, такого убожества - хром, который втихую утаскивает(устаскивал?) невероятное количество трафика).
Если говорить только о локальной обработке ошибок. Я предпочитаю, сообщать модальным окном кратенько, и отдельно вести 2 лога.
1 лог(файловый) - ошибки программиста. Есть для этого и инструменты и возможности. Лог удаляется опционально. Обычно они именуются датами, и при следующем падении если лог старше месяца, удаляем. Если за месяц не обратились вряд ли вообще обратятся.
2 лог(файловый или временные таблицы БД, уровня сессии) - ошибки оператора. Естественно храниться в течении "сессии" работы с приложением. Отображение в удобной и приемлемой для пользователя форме.
3. Отображение данных. В этом отношении, считаю, что каждому студенту, обязательно, нужно вдалбливать архитектуру "документ/вид". Но у нас, к сожалению, в большинстве случаев этого не делается. Или делается на уровне - "я слышал, такое есть. Если интересно, почитайте в интернете". Вот в этом плане MFC(к примеру), намного порядков, вперед, делала VCL(к примеру). А жаль.
В идеале предоставлять пользователю на выбор(не исключающий) несколько вариантов представления данных. И не боятся экспериментировать. Не загонять себя в рамки того, что если данные табличные, то и отображать их нужно таблично. Бред, причем абсолютный.
Особенно это касается вывода каких то агрегированных(если хотите агрегированных данных). К вашим услугам Dashboard'ы, GIS-данные и т.д. Не упирайтесь в естественное представление данных.
4. Очень важный момент - первый запуск приложения. Tip's считаю бредом который мало кто читает, а раздражает невероятно. Но упорно их двигают. Так же раздражает когда при первом запуске выкидывают первым делом окно настроек. Да пользователь даже не понимает о чем идет речь, как он может это настраивать?! Обязательно необходимо, делать какую-то "типовую" первоначальную настройку программы.
5. Сохраняйте настройки пользователя НЕ явно для него, по крайней мере те которые касаются визуальной части программы и которые не приводят к краху приложения(иначе оно не запустится). Естественно, чтобы потом пользователю не пришлось, снова двигать, тыкать и прочее. Ему ТАК удобнее. Он сделал свой выбор. Например, передвинул пользователь столбец в гриде, сохраните. Выбрал сортировку по фамилии, сохраните. Передвинул панельку сверху - вниз, сохраните.
Если действия пользователя привели к краху приложения, и приложение не может подняться, откатывайте настройки на "типовые"(опять же речь идет о программах массового пользователя. Когда пользователь не находится в минуте набора телефонного номера, текста icq и т.д.)
Идеальный случай, сбросить настройки. Показать пользователю, что были такие настройки, и изменение таких то настроек привело к краху. Обычно пользовательских настроек не так много, пользователь подправит и разберется. Но естественно, тут нужно действовать обдуманно. Это не панацея.
6. Справочная система. Основная справка и контекстная справка... Если Вы собираетесь ее писать на отъе@ись, то лучше совсем не пишите. Разочарование пользователя будет куда больше, если он полезет в справку и не найдет искомого, чем когда справки совсем нет. Сейчас интернет все больше приходит в нашу жизнь, если лень писать справку, заводите пользователя на сайт и форум. Может там уже есть и обсуждалось. Если не обсуждалось, то он сможет хотя бы спросить, причем не на форуме - "Умелые домохозяйки", а у разработчиков.
7. Контекстное меню. Не забывайте о нем. Не нужно делать полную копию toolbar'a, но и делать 1 кнопку тоже не стоит. Да есть маньяки клавиатуры которые любят горячие клавиши - флаг в руки. Но сейчас приходят новые поколения пользователей, которые без мышки не мыслят себя. Так вот не обижайте не тех - не других.
Сейчас, возможно скажите, модно, но процветает идеология, что все жизненно важные функции объекта приложения должны быть консолидированы около него. Зайдите на одноклассники, посмотрите как реализованы всплывающие окна. Запустите "Кризис", новый "Wolfenstein", посмотрите как реализованы функции выбора режимов игры(амуниции?). Это действительно УДОБНО. Пользователю, если он работает с самой нижней записью в гриде, не нужно ползти мышкой вверх окна, чтобы посмотреть, например сумму по этому счету. Он нажав правую кнопку тут же получает доступ к ЭТОЙ ЖЕ кнопке...
8. И последнее. Самого главное. Все что написано выше, не нужно использовать, это от лукавого, чтобы запутать Вас)))))))))
Уф... Вот такие краткие соображения на этот счет)))))
PS^ Писал, как и просилось в заголовке из личного опыта. Книгу рекомендуемую в теме, полистал, но соглашусь с теми, кто говорит, что в книге мало интересного. По крайней мере, я для себя ничего не нашел...
С Уважением.
А LCL Linux,Windows, MacOs .
