Несколько небольших приёмчиков по повышению usability.

[Glen]

На странице http://kellylynch.livejournal.com/3839.html своего ЖЖ я собрал вместе несколько небольших приёмов по повышению usability десктопных приложений.

Сам приведённый в той статье пример – несколько ‘искусственный' (не мог же я разместить скриншоты своего защищённого NDA продукта :-) ); но приёмы эти я взял из реальных приложений...

[pu4koff]

В ЖЖ нет меня, поэтому тут прокомментю:

1. Кнопка SEARCH сейчас появляется только после того как какое-то из полей "From:” или ‘To:’ изменено пользователем:

Тут нарушается одно из часто описываемых в литературе правил юзабилити. Даже тут это может смутить пользователя, а в более сложных случаях он и вовсе не сможет понять принцип появления/исчезания кнопки. Более правильным считается менять активность элементов и как-то сообщать пользователю что мешает этому элементу быть активным. В данном случае это бесполезное усложнение.

2. Когда поле "From:" или поле "To:" изменено (считая со времени предудущей операции поиска), его фон меняется на бледно-жёлтый:

Когда я еще писал на делфи и ИС в основном писались на делфях, попалась мне какая-то программа в которой точно таким цветом выделялись поля ввода, в которые нельзя было вручную вбивать значения, а нужно было жать кнопку "..." для выбора элемента из справочника. С однйо стороны readonly, а с другой - изменяемый пользователем, но через другой элемент. Не знаю на счет общепринятости этого подхода, но я использовал. Измененные данные до их применения или сохранения чаще выделяют жирным шрифтом, а не цветом фона.

3. Если пользователь изменил одно из полей, а другое поле ещё не трогал

Почти никогда неоправдано автоматическое изменение фокуса. Есть частные случаи типа ввода серийника в группу полей ввода или что-то вроде перехода по ячейкам таблицы после нажатия на Enter. Это скорее приведёт к замешательству и поиску фокуса ввода. С фокусом можно делать только одно: правильно расставить последовательность перехода по Tab'у.

4. Если пользователь изменил одно из полей, а другое поле было (со времени предыдущего поиска) изменено ещё раньше

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

5. Восстановление выбранных строк после перезагрузки содержимого Grid-а

Круто, при условии, что все выбранные строки попадают в результаты нового поиска. Если пользователь выделил 10 строк, а из них 3 теперь нет в результатах, то возникает много вопросов. Втихую оставлять выделенными 7 элементов - это не есть хорошо, т.к. пользователь может разчитывать именно на 10 элементов и будет неприятно удивлён, когда это использовалось для бэкапа и скопировалось 7 файлов, а не 10 и в итоге 3 файла потерялись.

6. Автоматическая прокрутка Grid-а после его перезагрузки

Тоже много спорных моментов. На деле будет прокрутка к выделенному до поиска элемента, а остальные элементы могут быть совсем другими. Пожалуй, что это мало где реально нужно.

7. Обработка ситуации “Дата FROM превышает дату TO”

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