Исследование автоколебаний при моделировании гармонического осциллятора с использованием комплексов моделирования
Автор: Головач В.
Источник: Мастерская Dr. dimdim
Одной из самых неприятных привычек разработчика интерфейса, от которой, к тому же, довольно трудно избавиться, является привычка походя оценивать интерфейс в терминах «плохой / хороший».
Раскрывающийся список:
Для того чтобы показать недопустимость подобного понимания проблемы, разберем простой пример. Допустим, что пользователь, заполняя форму ввода, должен выбрать месяц. Нормальным решением здесь является раскрывающийся список, выглядящий примерно так, как показано на иллюстрации.Возникает вопрос: хорошо ли это решение? Ответ: отсутствует. Ничего нельзя сказать, пока не определено, кто, как и при каких обстоятельствах пользуется этим решением.Если ничего подобного не известно, то это решение, оказывается хорошим, поскольку оно требует минимума места на экране. Но существует множество ситуаций, при которых оно будет работать плохо.Например, предположим, что этот элемент управления находится в самом центре поля ввода. До и после обращения к элементу управления пользователь вводит текст. В этом случае раскрывающийся список оказывается неэффективным: пользователю придется либо перемещать руку на мышь, либо на клавиши со стрелками стрелки (почти никто не знает, что обычном раскрывающемся списке можно перемещаться между элементами, просто набирая с клавиатуры нужное значение). В этом случае уместней раскрывающийся комбобокс. При первом или «невнимательном» взгляде этой проблемы не увидеть.Другая сторона вопроса: предположим, что нам важно не допустить ошибки при выборе месяца. В этом случае имеющийся список не адекватен, поскольку в некотором проценте заполненных форм всегда будут формы с месяцем, установленным по умолчанию (январь, например) – иногда пользователи будут по ошибке пропускать выбор месяца. Список при этом возможен, но его обязательно нужно будет снабдить пустым значением, стоящим по умолчанию. И этой проблемы не увидеть без специальной работы.Далее, предположим, что интерфейс предназначен для пожилых пользователей, или же основную часть пользователей составляют люди с ухудшенной координацией движений. И в этом случае раскрывающийся список пользы не принесет. Это же верно, если выбор месяца является единственным элементом управления в окне. В этом случае, поскольку не нужно экономить место, набор радиокнопок окажется предпочтительным.Пример с этим списком прост и, пожалуй, надуман. Однако на наш взгляд он отлично иллюстрирует тезис о том, что без знания о том кто, как и при каких обстоятельствах пользуется интерфейсом, этот интерфейс невозможно оценить и, тем более, разработать.При этом оказывается не очень важно, «какие именно элементы управления как именно используются в каких именно окнах». Если разработчик знает, для кого он проектирует интерфейс, каковы характеристики его пользователей, как этим интерфейсом будут пользоваться, и какие именно характеристики этого интерфейса важны, он почти неизбежно создаст адекватный интерфейс. Без знания этих эмпирических данных, напротив, вероятность разработки адекватного, успешного интерфейса крайне низка.Интересно, что как только разработчик начинает думать о таких вещах, он автоматически излечивается от вредной привычки походя оценивать интерфейс в терминах «плохой / хороший» (или «традиционный / революционный», или, упаси бог, «красивый / некрасивый»), безотносительно к контексту использования системы в целом.