Пользовательский интерфейс. Обмен опытом.

[скалогрыз]

ещё практический пример о дизайне диалогов: http://bugs.freepascal.org/view.php?id=15564

[Brainenjii]

По поводу сообщений об ошибках... Не совсем к интерфейсу относится, но всё-таки... Как вы их отлавливаете? В смысле - вот случается, что программка моя выбрасывает Access Violation и зависает... Причём случается это крайне редко и никогда у меня, что особенно напрягает ^_^ Вот как её отследить? Отладчик - сразу отметается, да и отключён - только глюки от него при сборке. Запихнуть проблемное место в одно большое Try...Except? Смысла особого не вижу - информации ведь это мне никакой не даст, да и где это проблемное место - могу только подозревать... Пока решил логированием каждого входа во все подозреваемые методы и выходы из них, теперь жду, когда она (ошибка) повторится... Но ведь не дело... Как "принято" поступать в подобных ситуациях? ^_^

[Sergei I. Gorelkin]

Запихнуть проблемное место в одно большое Try...Except? Смысла особого не вижу - информации ведь это мне никакой не даст

Почему не даст? В блоке except доступна ф-ция ExceptAddress, которая возвращает адрес возникшего исключения. Если повезло и она вернула адрес в пределах модуля, получить место в исходнике - дело техники. Хуже, если, к примеру, вызвали виртуальный метод уничтоженного объекта и управление передано черт-те куда.
Можно прогнать программу через valgrind+memcheck, оно неплохо отлавливает левые обращения к памяти. Можно скомпилировать с проверками и затиранием переменных (-Criot -gttt), будет работать медленнее, но вероятность отлова глюков возрастет.

[Brainenjii]

Хм... Valgrind + memcheck - хорошо, когда знаешь, как ошибку повторить... Я пытался - ни в какую ^_^ А чем может помочь (-Criot -gttt)? // на работе IE6, с ним гуглить - одно мучение >_<

[FedeX]

Запихнуть проблемное место в одно большое Try...Except?

Кстати, есть такая штука как Application.OnException называеться, если не ошибаюсь..

[Sergei I. Gorelkin]

Хм... Valgrind + memcheck - хорошо, когда знаешь, как ошибку повторить... Я пытался - ни в какую ^_^ А чем может помочь (-Criot -gttt)?

И то, и другое помогает найти не столько ошибку непосредственно, сколько условия, приводящие к ее появлению. Или спровоцировать ее постоянное или более частое появление.
-Cr, -Ci, -Co и -Сt вставляют проверки на переполнения и выходы за пределы диапазонов (-Ci - проверки ввода/вывода, возможно излишни).
-gttt затирает все локальные переменные, так что, например, если некий указатель не всегда инициализируется программой, но по стечению обстоятельств оказывается равным nil в 99.9% случаев, то с -gttt он больше не будет равен nil и программа рухнет гораздо раньше

[Vadim]

Я думаю, что те, кто говорит "Все диалоги - пацтол!", так же как и я сталкивались с неправильным оформлением и выводом этих самых диалогов. Оттого и нелюбовь. Ведь что получается, диалог, при неправильном выводе информации, не помогает решить проблему, а только усложняет её решение.
Для наглядности приведу недавний пример. Скачал свежие исходники Lazarus. Пытаюсь собрать с помощью make. Сборка идёт успешно, но в самом конце (а у меня комп старенький и конец появляется только через 15..20 минут ) вижу сообщение:
Не могу сполнить /usr/bin/fpcres
И что мне делать? Первое, что приходит в голову, проверить права доступа и возможность запуска. Проверяю - с правами всё ок, запуск этой утилиты из командной строки проходит успешно. Что дальше делать? Тупичок, господа программеры...
Вот на это бы надо обратить внимание в первую очередь - чтобы все диалоги помогали, а не запутывали пользователя. А вы - "все диалоги и модалы - фтопку! Прога должна умереть без единого звука!".

[Brainenjii]

// надо закомментировать строчку {$R x.rc} в файле проекта. Оставить только {$R x.res}

[Vadim]

Brainenjii
Эффекта никакого, та же ошибка. Какие ещё могут быть причины?

[Climber]

Прога должна умереть без единого звука!".

Я такого не говорил
Прога должна уметь доказать,что без модального диалога никак не обойтись. Я уже привел пример с экселем, как можно было обойтись без модального окна. Иногда они могут понадобиться, но я все равно предпочитаю немодальные. Если говорить о многочисленных окнах настройки - то лучше немодальное + отображение поверх всех окон. Имхо, это лучше.
Сообщений вида "Не могу исполнить /usr/bin/fpcres" тоже быть не должно. Мне по барабану, что прога может, а что нет. Меня интересует конечный результат. Поэтому вместо "Не могу" она должна сразу говорить, что именно она не может и почему. То есть: "Для выполнения вам не хватает файла xyz.abc", "Вы не имеете права выполнять эту операцию" и т. д. Нет, конечно, можно и так оставить, только вот на звание "user-friendly" не пусть не претендует

[Vadim]

Я такого не говорил

Кто говорил - в общем то уже и не важно. Потому что следующеей предложение:

Прога должна уметь доказать,что без модального диалога никак не обойтись.

говорит о том, что у Вас получается прога отдельно, а программист отдельно. Это не прога должна доказывать, а программист должен проектировать. Если нужно модальное окно, значить нужно его вставить и не мучаться угрызениями совести по ночам, что это некашерно и в Гондурасе так не делают. Если не нужно, значит окно будет немодальным.

Сообщений вида "Не могу исполнить /usr/bin/fpcres" тоже быть не должно. Мне по барабану, что прога может, а что нет. Меня интересует конечный результат. Поэтому вместо "Не могу" она должна сразу говорить, что именно она не может и почему. То есть: "Для выполнения вам не хватает файла xyz.abc", "Вы не имеете права выполнять эту операцию" и т. д. Нет, конечно, можно и так оставить, только вот на звание "user-friendly" не пусть не претендует

Вот и я про то же... В первую очередь нужно обратить внимание на выдаваемую прогой информацию - помогает она пользователю или нет. А уж в модальном это окне или немодальном - дело десятое.

[AbakAngelSoft]

Прога должна умереть без единого звука!

Это я писал

Добавлено спустя 1 минуту 26 секунд:

В первую очередь нужно обратить внимание на выдаваемую прогой информацию - помогает она пользователю или нет.

В первую очередь надо обратить внимание нужна-ли она пользователю вообще!!!

[Climber]

у Вас получается прога отдельно, а программист отдельно

А так оно и есть. Люди склонны персонифицировать любой объект, обладающий сложным поведением с некоторой степенью непредсказуемости. Погоду, компьютеры, программы... Пользователь, сидя за компом, общается не с программистом, а с программой. Поэтому именно программа должна уметь доказывать (путем вывода нужной информации), а программист должен ее научить.

В первую очередь нужно обратить внимание на выдаваемую прогой информацию - помогает она пользователю или нет. А уж в модальном это окне или немодальном - дело десятое.

Я не говорил этого явно, теперь скажу: сообщения об ошибках - это отдельный большой вопрос, его надо рассматривать отдельно от проблемы модальности. Кстати, выводить можно вообще без окон - в статусбар. В клиенте Lotus Notes, кстати, это хорошо реализовано: в статусбаре в комбобоксе выводится последнее сообщение, а по щелчку на треугольнике вываливается полный список сообщений. Рекомендую взять на заметку, очень удобно.

P. S. Что касается информации об ошибках: очень мало видел адекватных сообщений об ошибках. В случае критических сбоев программы либо спешат поделиться интимной информацией ("память по адресу 0х2A35F6DC не может быть read"), от которой мне ни тепло, ни холодно, - при этом забывая уточнить, что сбой, вообще-то, настолько критический и что дальше работать программа не будет, либо говорят что-то совсем непонятное. Но ни одна не говорит, а что мне делать дальше.

[Vadim]

AbakAngelSoft

В первую очередь надо обратить внимание нужна-ли она пользователю вообще!!!

Если Вы прочитаете мой первый пост с примером, то у Вас такого восклицания в принципе возникнуть не должно. Нужна, категорически нужна! Но не в том виде, в каком мне это в данном случае преподносится.

Добавлено спустя 12 минут 54 секунды:

А так оно и есть. Люди склонны персонифицировать любой объект, обладающий сложным поведением с некоторой степенью непредсказуемости. Погоду, компьютеры, программы... Пользователь, сидя за компом, общается не с программистом, а с программой. Поэтому именно программа должна уметь доказывать (путем вывода нужной информации), а программист должен ее научить.

Пока что мы ни на йоту не приблизились к искусственному интеллекту. А судя по нынешним студентам, всё дальше и дальше удаляемся от естественного. Программист - первый пользователь программы. Он и должен решать, где что поставить. Далее испытываем программу на кошках - близлежащих работниках, но уже не программистах. И опять же программист решает, где что поставить или не поставить.
Что может программа? У неё есть некий очень узкий список ситуаций со строгой логикой действий. И во многих случаях эта логика, на первом этапе испытания программы, приводит к сообщению "Скажите разработчикам, что я в обмороке". Не знаю как Вы, а я пока ещё не научился писать программы совсем без ошибок. И поэтому в первую очередь забочусь о максимальной информативности ситуации и эту информативность закладываю в программу, чтобы пользователь как раз и не оставался один на один со своей бедой (программой). Как ни хочется наделить программу разумом, но всё равно в конце концов получается, что программа (а далее, по цепочке, программист ) дура дурой и ничего решить не может.

[AbakAngelSoft]

Если Вы прочитаете мой первый пост с примером

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

Код: Выделить всё

  try
    F := TFileStream.Create...
  except
    ShowMessage('не могу открыть файл');
  end;

иногда добавляют имя и путь к файлу, а вообще продвинутые E.Message!!!
Вместо анализа и исправления ошибки разработчик перекладывает ответственность на пользователя - пусть разбирается.
Если мы можем продолжить без этого файла - никаких сообщений! Только вывод в лог, где подробно описываем, например "не хватает прав доступа, что бы исправить эту проблему, сделайте то-то и то-то" или "папка такая-то отсутствует это могло произойти всвязи с тем-то и тем-то, сделайте то-то и то-то" и ссылка на справочную информацию обязательно!
Видел продукт к которому прилагалась утилита автоматическогй проверки и восстановления! Вроде бы хорошо, но в случае сбоев ее предлагалось запустить вручную! Если она автоматическая почему бы и ее запуск не сделать автоматическим?