|
Почему одни программы нравятся пользователям, а другие нет? Почему с одними им удобно работать, а на другие они ругаются? Факторов здесь множество. Один из этих факторов - удобный и дружественный интерфейс. Предлагаю рассмотреть ряд приемов, которые помогают улучшить внешний вид программы, а значит повысить удобство работы с ней.
Статья написана по результатам разборов программ, написанных молодыми разработчиками нашей группы. Правильно расставляем последовательность переключения компонентов Многие пользователи, особенно те, кто ранее работал в ДОС, имеют привычку переключаться между полями ввода не мышкой, а с помощью клавиатуры клавишей Tab. К тому же, это гораздо быстрее, чем выделять каждое поле мышью. Поэтому порядок переключения компонентов должен быть выставлен правильно. Это касается как компонентов внутри всех компонентов-контейнеров (панелей, GroupBox-ов и им подобных), так и самих компонентов-контейнеров, если их на форме несколько. Порядок переключения компонентов внутри контейнера задается свойством TabOrder. Первым становится активным компонент, у которого TabOrder равен 0, вторым с 1 и т.д., пока не будут перебраны все компоненты. Кроме этого, у компонента есть свойство TabStop, которое показывает, будет ли компонент получать фокус при переключении клавишей Tab. Если нужно запретить переключение на какой-либо компонент, поставьте у него TabStop = false. В этом случае переключиться на данный компонент можно будет только с помощью мыши. Бывают случаи, когда пользователи, привыкшие переключаться определенной клавишей в одной программе, по привычке продолжают пользоваться ей и в остальных. Часто это происходит с пользователями 1С, где для перехода по полям ввода может использоваться клавиша Enter. Что ж, дадим им такую возможность в наших программах, если они об этом просят. Устанавливаем у формы свойство KeyPreview в true и пишем обработчик события OnKeyPress: procedure TForm1.FormKeyPress(Sender: TObject; var Key: Char);
begin
if ord(key)=vk_Return then
Form1.SelectNext(PriemForm.ActiveControl, true, true);
end; Такой обработчик обеспечивает переход по элементам формы при нажатии клавиши Enter. Следует заметить, что подобный метод не будет работать с кнопками, т.к. нажатие Enter на кнопке приводит к ее нажатию, тогда как нажатие Tab передает фокус ввода следующему в последовательности переключения компоненту. Кнопки по умолчанию Все те же пользователи довольно быстро привыкают, что в диалоговых окнах приложений, как правило, клавишей Enter можно подтвердить свой выбор, а клавишей Esc - отменить. Давайте не будем их разочаровывать в наших программах, тем более что сделать это очень просто. Для кнопки, реагирующей на Enter, устанавливаем свойство Default в true. Для кнопки, реагирующей на Esc, устанавливаем свойство Cancel в true. И все. Да или нет Все диалоговые окна, запрашивающие действия пользователя, должны иметь, по крайней мере, две кнопки: подтверждения действия и отказа от действия (Да/Нет, Сохранить/Отменить и т.п.). Отказ от действия может осуществляться закрытием окна кнопкой [X] в заголовке окна. Недопустимо, если имеется только одна кнопка для подтверждения действия, а для отказа предполагается закрывать окно кнопкой [X] в заголовке, либо возможность отказа вообще отсутствует. Это путает пользователя, вызывая логичный вопрос: а как отказаться? Также не забываем о том, что было сказано выше в пункте "Кнопки по умолчанию". Все диалоговые окна должны открываться по центру экрана По центру, а не там, где они были созданы в режиме проектирования. Во-первых, это нагляднее, а во-вторых, автоматически устраняет проблему разного разрешения экрана у разных пользователей. Исключение делается в том случае, если диалоговое окно не модально, и по результатам работы пользователя в этом окне сразу происходят изменения в основном окне (например, фильтрация набора данных, перерисовка графиков и т.п.). Размеры окон не должны превышать размеров экрана Ни в коем случае. Это безобразие, когда часть окна вылезает за экран. Данное требование не зависит от разрешения экрана у пользователя, т.е. отговорки типа "Пусть поставят большее разрешение" не проходят. Корректное изменение размеров оконных элементов Оконные элементы должны корректно изменять свои размеры или перемещаться при изменении размеров окна, при максимизации окна и при восстановлении окна после максимизации. Все всегда видно Уменьшение размеров окна не должно приводить к исчезновению оконных элементов и желательно не должно приводить к появлению полос прокрутки (scroller-ов) самого окна. Можно ограничивать минимальные размеры окна таким образом, чтобы все элементы были видны и доступны. Если нет возможности разместить компоненты таким образом, чтобы все были видны в окне, можно использовать закладки (типа PageControl) для разбиения компонентов на группы. Отговорки по поводу разрешения экрана тоже не пропускаем. Хинты везде, хинты всегда Для кнопок, особенно на панелях инструментов (типа ToolBar) должны быть заданы подсказки (hint), чтобы всегда было понятно, зачем нужна та или иная кнопка. Цветовая гамма Не стоит раскрашивать компоненты на форме во все цвета радуги. Это утомляет глаза и рассеивает внимание пользователя. Это не выглядит "круто". Выделение цветом используется в том случае, когда надо привлечь внимание пользователя к какому-то определенному элементу или определенной части окна. Например, раскрасить светло-красным цветом записи, в которых присутствуют ошибки или, наоборот, светло-зеленым цветом записи, проверка которых прошла успешно. Заключение Есть очень хороший метод, который позволяет найти недостатки программы вообще и интерфейса в частности. Он прост: представьте себя на месте пользователя и в течение получаса попытайтесь работать так, как работает он. Еще лучше, если ваш пользователь в пределах досягаемости (например, работает в той же организации). В таком случае сядьте рядом с ним, а лучше вместо него, и попробуйте сделать его работу. Вносить данные, изменять их, выводить отчеты и т.д. Если вы не знаете, как сделать правильно, спросите у своего пользователя. Сделайте не одну-две однотипные операции, как в отладочном режиме, а 20-30, а то и более различных операций, в разном порядке. Забудьте что-нибудь ввести или введите неправильно и посмотрите, как программа на это отреагирует. Вы достаточно быстро увидите слабые места вашей программы. Автор статьи автоматизировал работу приемной комиссии в ВУЗе, и в первый год внедрения программы по 3-4 часа в день проводил в приемной комиссии, регистрируя абитуриентов, заполняя их персональные данные и выдавая им отчеты о сдаче экзаменов. А в оставшееся рабочее время исправлял ошибки и недочеты. Поверьте, на следующий год проблем практически не осталось. Аналогично было и при внедрении кадрового модуля. Таким образом, помните об удобстве работы для пользователей. Пусть им будет легко и приятно работать с вашими программами. Автор: Сергей Дуплик
|
