Источник
Программист думает как программист и основное, что занимает программиста - это программный код. Чтобы создавать интерфейсы, необходимо отказаться от тех принципов, которые используются в кодировании.
Проблемы, связанные со структурами данных.
Программист думает как программист и основное, что занимает программиста - это программный код. Чтобы создавать интерфейсы, необходимо отказаться от тех принципов, которые используются в кодировании.
Проблемы, связанные со структурами данных.
- Использование имен переменных или технических терминов для текстовых меток. Такие имена мало значимы для пользователей. Например, подумайте, сколько человек знает, что такое полный дуплекс?
- Злоупотребление текстовыми полями. Простое текстовое поле предоставляет слишком много вариантов пользователю. Если поле типа String это не значит, что необходимо всегда использовать TextBox.
- Ограничения по хранению значения в коде переносятся в формы. Например, телефон должен всегда храниться в определенном формате. Но это не значит, что необходимо запрещать пользователю вводить телефон в другом общеупотребимом формате. Пусть программа автоматически преобразует текст в нужный формат.
- Избыток сообщений об ошибках. Часто выводят сообщения об ошибках при малейших проблемах вне зависимости от сложности проблемы и понимания ее пользователем. Необходимо выводить сообщения об ошибках, которые пользователь сам может легко исправить.
- Выдача специальных значений переменных. Часто используют спец. значения для переменных для обозначения отсутствия значения. Например "-1" для натуральных чисел. Необходимо выдавать понятный текст, а не спец. значение и позволять вводить это спец. значение с помощью кнопки, либо еще как-нибудь.
- Не включение в форму элементов ввода наиболее вероятных значений. С точки зрения кода значения, вводимые в форме равновероятны, хотя для пользователя это не так. Например при выборе шрифта наиболее вероятно, что пользователь выберет последний выбранный шрифт или шрифт, выбранный в прошлом.
- Чрезмерное обобщение. Программисты шутят, что есть только три числа: 0, 1 и бесконечность. Для выполнения функции 2 и более раз пишется цикл. Такое обобщение часто приводит к избыточной сложности.
- То, что требуется согласно коду не всегда знает пользователь. Например, в программе требуется код аэропорта, а пользователь знает только название города. Необходимо спрашивать пользователя то, что он знает.
- Слишком долгая обработка форм. Вы когда-нибудь видели большие формы, которые состоят полностью из пустых полей и вы не знаете, что заполнять? Обнулять все значения можно коде для структур данных, но не для пользователя. Можно заполнять значениями по умолчанию, либо разбивать форму на несколько форм.
- Отображение сразу всех полей. Структуры данных в коде не должны полностью отображаться в интерфейсе. Необходимо учитывать зависимости между полями, определять важное от неважное, обязательные и опциональные поля, скрывать редко используемые поля.
- Заполни все или ничего. Еще одна проблема отображения структуры данных в интерфейс. Нельзя заставлять пользователя обязательно вводить все данные, которые есть в структуре. Пусть он введет только самое необходимое на текущем этапе, а остальное он заполнит потом.
- Барьер приватности. Если структуры данных требуют какой-то персональной информации, которую сложно получить (иметь логин, найти забытый пароль), то пользователь может не захотеть давать личные данные, особенно если эти данные не требуются для выполнения задачи (по крайней мере начала).
- Частый ввод одних и тех же данных. Человек не компьютер, он не любит выполнять одну и ту же работу по нескольку раз. Реализуйте заполнение полей значениями по умолчанию.
- Слишком много полей на экране. Сложные формы вызывают панику и неприязнь. Уменьшайте количество полей на формах!
- Избыточные ограничения на ввод данных. Если пользователь верит, что он ввел верные данные, то скорее всего это так. Позвольте вводить информацию в разных форматах. На эту тему см. статью We cannot accept that behavior.
Комментарии
Отправить комментарий