Если учесть, что дорожные знаки более-менее стандартизированны, и, что не менее важно, каждый водитель обязан знать их значение, то это будет не лучшая аналогия. Зачастую бывает невозможно объяснить разницу между хорошим интерфейсом и выученным.
Здесь можно выделить как минимум два важных момента:
негативный опыт «тупых окошек»
часто повторяющиеся действия
«Тупые окошки» — это прерогатива не до конца продуманных интерфейсов. Продумывать системное взаимодействие работа весьма рутинная и не всегда явно доступная. Поэтому зачастую результат работы системных сообщений ложится на логику программистов, либо на логику приложения, в котором по-умолчанию заложена логика программистов. А так как по роду занятий программисты не обязаны проектировать взаимодействие с пользователем, следовательно и результат получается соответствующий.
Тупость окошек заключается в отсутствии классификации (сообщение, диалог, ошибка) и проработке (e.g. информационное сообщение — зеленое, ошибка — красное, etc.). Печальный опыт работы, скажем, с осью MS, формирует негативный опыт взаимодействия юзера. «Произошла какая-то херня! ОК.» как исток зарождения бездумного тыканья на кнопки.
Даже если нам повезло и мы работаем с качественным приложением, мы сталкиваемся с повторяемостью действий. И совершенно логично, что при любом раскладе выдавать сообщение на подтверждение удаления будет правильным, потому как на кону потеря данных. И получается, что после того, как мы удалили что-то не нужное, обвинять приложение в отсутствии заботы о нас, мы не можем, потому что это как бы явно не так. Тем не менее «уже поздно» и приложению мы не доверяем :)
В данном случае, на мой взгляд, проблема связана в не до конца акцентном привлечении внимания. Бȯльшая часть окошек PMA идентична, а следовательно пользователя ничего не колышет в случае когда действительно важно прочитать. Удачной проработкой окошек здесь я бы назвал выделение красным ахтунгом всего окошка, чтобы юзер, находясь даже в самом неосознанном состоянии имел возможность взбодриться и все-таки заставить себя прочитать содержание заботливого текста системы. Ну и классика — если написать на кнопке не «да», а «удалить» — это также может быть очень хорошим стимулом включить мозг :)
Хорошая агитация в сторону верстки «настоящей резины». То есть той, где резиновыми являются основные содержательные элементы — шрифт в относительных величинах, сетка в процентах.
Однако, помимо того, что этот тип верстки является не самым простым, важно еще понимать, что чем сложнее дизайн и чем дубовее макеты, тем вероятность создания качественной резины резко падает, даже если квалификации верстальщика для этого достаточно. А следовательно страдает и все что связано с зумом и прочим.
Если отказаться от обильного использования графики, задача резко упрощается с точки зрения гибкости ресайза, и вики — яркий тому пример.
Вообще, с массовым приходом широкоформатников, ситуации с «распространенным» разрешением скорее всего скоро не станет. И для качественной кросс-форматной реализации нужны новые подходы к верстке макета.
Чем-то идеологически переплетается с идеями Раскина про будущие системы, в которых приоритетность «потока» определяет новый уровень взаимодействия, все больше воплощая тем самым идею машины для человека, а не наоборот.
Из критичного, на вскидку, ввиду единственной возможности закрытия тултипа только по крестику, эффективность использования данного приема заметно снижается в случаях, когда тултип уходит за видимую часть окна браузера (например, у элемента расположенного в правом краю). Возможно стоит допилить проверку для корректного позиционирования в таких случаях.
«Тупые окошки» — это прерогатива не до конца продуманных интерфейсов. Продумывать системное взаимодействие работа весьма рутинная и не всегда явно доступная. Поэтому зачастую результат работы системных сообщений ложится на логику программистов, либо на логику приложения, в котором по-умолчанию заложена логика программистов. А так как по роду занятий программисты не обязаны проектировать взаимодействие с пользователем, следовательно и результат получается соответствующий.
Тупость окошек заключается в отсутствии классификации (сообщение, диалог, ошибка) и проработке (e.g. информационное сообщение — зеленое, ошибка — красное, etc.). Печальный опыт работы, скажем, с осью MS, формирует негативный опыт взаимодействия юзера. «Произошла какая-то херня! ОК.» как исток зарождения бездумного тыканья на кнопки.
Даже если нам повезло и мы работаем с качественным приложением, мы сталкиваемся с повторяемостью действий. И совершенно логично, что при любом раскладе выдавать сообщение на подтверждение удаления будет правильным, потому как на кону потеря данных. И получается, что после того, как мы удалили что-то не нужное, обвинять приложение в отсутствии заботы о нас, мы не можем, потому что это как бы явно не так. Тем не менее «уже поздно» и приложению мы не доверяем :)
В данном случае, на мой взгляд, проблема связана в не до конца акцентном привлечении внимания. Бȯльшая часть окошек PMA идентична, а следовательно пользователя ничего не колышет в случае когда действительно важно прочитать. Удачной проработкой окошек здесь я бы назвал выделение красным ахтунгом всего окошка, чтобы юзер, находясь даже в самом неосознанном состоянии имел возможность взбодриться и все-таки заставить себя прочитать содержание заботливого текста системы. Ну и классика — если написать на кнопке не «да», а «удалить» — это также может быть очень хорошим стимулом включить мозг :)
Однако, помимо того, что этот тип верстки является не самым простым, важно еще понимать, что чем сложнее дизайн и чем дубовее макеты, тем вероятность создания качественной резины резко падает, даже если квалификации верстальщика для этого достаточно. А следовательно страдает и все что связано с зумом и прочим.
Если отказаться от обильного использования графики, задача резко упрощается с точки зрения гибкости ресайза, и вики — яркий тому пример.
Вообще, с массовым приходом широкоформатников, ситуации с «распространенным» разрешением скорее всего скоро не станет. И для качественной кросс-форматной реализации нужны новые подходы к верстке макета.
Из критичного, на вскидку, ввиду единственной возможности закрытия тултипа только по крестику, эффективность использования данного приема заметно снижается в случаях, когда тултип уходит за видимую часть окна браузера (например, у элемента расположенного в правом краю). Возможно стоит допилить проверку для корректного позиционирования в таких случаях.