Отображение системных сообщений -- важная задача, которой часто не уделяют должного внимания.
Мне известно 4 способа отображения сообщений:
1. Диалоговое окно. Ввел что-то не так -- бац, возникает окошко, где написано что ты дурак и окнопка "ОК". Пока не согласишься, прога не даст ничего сделать.
2. Встроенное в интерфейс сообщение, к примеру красный восклицательный знак возле текстового поля.
3. Всплывающее окошко (которое либо исчезает само, либо ждет пока его закроет пользователь, но при этом не блокирует ввод данных).
4. Панель/таблица со списком сообщений.
Итак. В модных софтинах диалоговых окон для сообщений стараются избегать. Типа пример плохого тона.
Остается 3 варианта.
При этом вариант 2 (встроенное в интерфейс) актуален только для форм ввода данных. И для форм ввода данных этот вариант предпочтителен. Иногда для форм ввода данных используют и всплывающее окошко, но это не очень удобно (типа ввел некорректный email, а вверху всплыло окошко "email введен с ошибкой", не так удобно как сообщение возле TextBox).
А вариант 3 и 4 по сути очень похожи -- эти варианты ипсользуют для оповещения о "фоновых проблемах", когда демоны чего-то не смогли сделать (к примеру, не удалось установить обновления).
Причем вариант 4, имхо, более продвинутый.
А какой вариант для системных сообщений предпочитаете вы? Нравятся ли вам всплывающие окошки для сообщений или лучше панель/таблица?
Здравствуйте, Shmj, Вы писали: S>А какой вариант для системных сообщений предпочитаете вы? Нравятся ли вам всплывающие окошки для сообщений или лучше панель/таблица?
В dungeon keeper был симпатишный
MessageTab
MessageTab для оперативного уведомления о последних важных событиях с привлечением внимания и журнал для просмотра и поиска сообщений.
Для этого должно быть выделено специальное место, а не popup или темболее диалог который выскакивает как черт из табакерки (а диалог еще и всё блокирует)
И конечно же tail -f /var/log/syslog
Здравствуйте, Shmj, Вы писали:
S>Отображение системных сообщений -- важная задача, которой часто не уделяют должного внимания.
Смотря что за сообщение.
К примеру, если сообщение информативного характера, то можно тот же MsgBox блокирующий, но с задержкой и автозакрытием. Тот же MessageBoxTimeout (по ссылке старая статья, и API вроде как недокументиваннный, но вот судя по МСДНъ эта функция давно документирована, и часть оф. API).
А вообще всё будет зависеть от Use Case сообщения. Должен ли пользователь принять какое-то решение (ОК, Отмена или что-то в этом роде)? Должен ли он продолжить ввод? Те же формы с данными. Сообщение показывается в результате каких-либо действий пользователя (клики, кнопки, меню) или это фоновое извещение в стиле "йопта, есть обновления"?
Всё будет определяться только сценарием. Единого решения нет!
Здравствуйте, Shmj, Вы писали:
S>А какой вариант для системных сообщений предпочитаете вы? Нравятся ли вам всплывающие окошки для сообщений или лучше панель/таблица?
Только не модальные окна. Они бесят всех и вся. Можешь сделать всплывающий popup, написать что ввёл с ошибкой и подсветить поля, но только никаких модалов блокирующих область ввода данных.
Здравствуйте, Shmj, Вы писали:
S>А какой вариант для системных сообщений предпочитаете вы? Нравятся ли вам всплывающие окошки для сообщений или лучше панель/таблица?
Я читал умную книжку, в которой было написано, что если программа выдает пользователю какое-то сообщение, то это затем, чтобы пользователь принял какое-то решение, которое программа не может принять за него. Соответственно, если во вплывающем окошке есть только одна кнопка, как узнать, какое решение принял пользователь (кроме очевидного решения нажать на эту кнопку)?
На мой взгляд, если пользователь не знает, что делать с этими системными сообщениями, то они будут его только раздражать. Большинство пользователей закрывают эти окошки, не читая. Так стоит ли программе их открывать>
Здравствуйте, Carc, Вы писали:
C>К примеру, если сообщение информативного характера, то можно тот же MsgBox блокирующий, но с задержкой и автозакрытием.
Зачем же блокирующий
Кроме того, если с автозакрытием -- есть риск что пользователь даже не увидит его. Отвлекся, пошел за чаем и...
Здравствуйте, Shmj, Вы писали:
S>А какой вариант для системных сообщений предпочитаете вы? Нравятся ли вам всплывающие окошки для сообщений или лучше панель/таблица?
Я один не понял что такое "системные сообщения" ?
Это сообщения которые нужны системе, а не пользователю? Тогда не надо их выводить.
Если сообщения нужны пользователю, то как их выводить зависит от степени важности и того, что делает пользователь. Тут общего ответа нет, надо сценарии использования смотреть. И это не в философию, а в юзабилити и проектирование интерфейсов.
ЗЫ. Удивлен как программисты пытаются придумать универсальные рецепты для сложных проблем, при этом уделяют много времени не-проблемам.
Здравствуйте, Pzz, Вы писали:
Pzz>Здравствуйте, Shmj, Вы писали: Pzz>Соответственно, если во вплывающем окошке есть только одна кнопка, как узнать, какое решение принял пользователь (кроме очевидного решения нажать на эту кнопку)?
Если в сообщении одна кнопка, то там нечего узнавать, т.к. нет никакого решения пользователя. Оно одно и только одно. В этом случае это сообщение информативного характера. И все равно всё будет упираться в use-case, в сценарий использования.
а) Должна ли быть эта информация из такого окошка доступна и после? Тогда может быть это лог, таблица, список сообщений, который потом можно посмотреть (не суть важно где: в лог-файле, в UI или еще как).
б) Должен ли быть прерван поток выполнения? Т.е. решение пользователю предоставляется одно и только одно, то бишь выбора нет. Но поток выполнения должен быть прерван, и прерван явно, что бы пока пользователь не нажмет ОК, дальше ничего не происходило.
Простой пример: common dialog открытия файлов в винде, есть там настройки (флаги в API), которые задают некоторые ограничения, мол открывать только существующие файлы OFN_FILEMUSTEXIST и иже с ними. Если файла не существует, диалог не даст пользователю нажать ОК. И что делает диалог, если ввести имя несуществующего файла? Говорит чего-то там "Файл не найден" и одна кнопка ОК. И не даст пользователю баловать дале, пока не нажмет ОК.
Что имеем? Вроде как решения пользователю не дают, но такое сообщение нужно. Ибо нужно четко дать понять пользователю в чем проблема, и прямо здесь и сейчас дать понять в чем дело, и чтобы он все-таки увидел и прочитал. Это как раз тот самый случай, что поток выполнения должен быть прерван, хотя никакого выбора для пользователя нет.
в) Ну такое же сообщение, с единственной кнопкой, но информативного характера. Нечто вроде "Все распрекрасно, кэп, всё получилось". Когда нет никакой надобности прерывать поток выполнения.
Простой пример из одной моей софтины. Если в 2-ух словах, то плагин стучится в хост-аппликуху, забирает данные, пакует в ZIP, и толкает их в Dropbox. Дык вот если все ОК, то в конце он показывает MsgBox с единственной кнопкой ОК + минимум инфы: что, куда, в каком объеме.
А зачем? А чтоб отчитаться что всё зер гут, но поскольку нет никакой надобности прерывать поток выполнения, то через три-пять сек, он автоматически закрывает этот MsgBox.
И наоборот: вот когда случается ошибка с такой отправкой данных, то тот же MsgBox, с алертами и матюгами, но без автозакрытия. Ибо это важно. Потому как пользователю точно нужно знать, что данные в дропбокс не ушли.
Повторюсь, всё упирается в сценарий использования. И только. Серебряной пули нет. Вернее есть, но их несколько. Но какую выбрать определяет сценарий использования.
PS: кстати не обязательно или-или. В том же случае "в)" (плагин для дропбоксу), сообщения сообщениями, а вот критическая инфа точно также может писаться в лог.
Здравствуйте, Shmj, Вы писали:
S>Здравствуйте, Carc, Вы писали:
C>>К примеру, если сообщение информативного характера, то можно тот же MsgBox блокирующий, но с задержкой и автозакрытием. S>Зачем же блокирующий
Блокирующие, но на маленькое время. Если пользователю важно — он успеет прочесть. Это всё равно информативного характера. S>Кроме того, если с автозакрытием -- есть риск что пользователь даже не увидит его. Отвлекся, пошел за чаем и...
А это похир, ибо "Это всё равно информативного характера.". Раз всё зер гут, то и нечего дергать пользователя, когда оно ему не надо.
Командир (пользователь) дал команду (нажал меню типа), подчиненный (программа) выполнил команду. Всё отлично! Чего теребить пользователя? Интересно — успеет увидеть, нет — дык и не надо.
