Створюємо дружній інтерфейс

Автор: Сергій Дуплік, Королівство Delphi


Чому одні програми подобаються користувачам, а інші ні? Чому з одними їм зручно працювати, а на інші вони лаються? Факторів тут безліч. Один з цих факторів – зручний і дружній інтерфейс. Пропоную розглянути ряд прийомів, які допомагають поліпшити зовнішній вигляд програми, а значить підвищити зручність роботи з нею.


Стаття написана за результатами розборів програм, написаних молодими розробниками нашої групи.


1. Правильно розставляємо послідовність перемикання компонентів


Багато користувачів, особливо ті, хто раніше працював у ДЗГ, мають звичку перемикатися між полями введення не мишкою, а за допомогою клавіатури клавішею 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 передає фокус введення наступного в послідовності перемикання компоненту.


2. Кнопки за замовчуванням


Все ті ж користувачі досить швидко звикають, що в діалогових вікнах додатків, як правило, клавішею Enter можна підтвердити свій вибір, а клавішею Esc – скасувати. Давайте не будемо їх розчаровувати в наших програмах, тим більше що зробити це дуже просто. Для кнопки, що реагує на Enter, встановлюємо властивість Default у true. Для кнопки, що реагує на Esc, встановлюємо властивість Cancel в true. І все.


3. Так чи ні


Всі діалогові вікна, що запитують дії користувача, повинні мати, принаймні, дві кнопки: підтвердження дії та відмови від дії (Так / Ні, Зберегти / Скасувати тощо). Відмова від дії може здійснюватися закриттям вікна кнопкою [X] в заголовку вікна. Неприпустимо, якщо є тільки одна кнопка для підтвердження дії, а для відмови передбачається закривати вікно кнопкою [X] в заголовку, або можливість відмови взагалі відсутня. Це плутає користувача, викликаючи логічне запитання: а як відмовитися?


Також не забуваємо про те, що було сказано вище, у пункті Кнопки за замовчуванням ".


4. Всі діалогові вікна повинні відкриватися по центру екрану


По центру, а не там, де вони були створені в режимі проектування. По-перше, це наочніше, а по-друге, автоматично усуває проблему різного дозволу екрану в різних користувачів.


Виключення робиться в тому випадку, якщо діалогове вікно не модально, і за результатами роботи користувача в цьому вікні відразу відбуваються зміни в основному вікні (наприклад, фільтрація набору даних, перемальовування графіків і т.п.).


5. Розміри вікон не повинні перевищувати розмірів екрану


Ні в якому разі. Це неподобство, коли частина вікна вилазить за екран. Дана вимога не залежить від дозволу екрану у користувача, тобто відмовки типу "Хай поставлять більшу роздільну здатність" не проходять.


6. Коректна зміна розмірів віконних елементів


Віконні елементи повинні коректно змінювати свої розміри або переміщатися при зміні розмірів вікна, при максимізації вікна і при відновленні вікна після максимізації.


7. Всі завжди видно


Зменшення розмірів вікна не повинно приводити до зникнення віконних елементів і бажано не повинно призводити до появи смуг прокрутки (scroller-ів) самого вікна. Можна обмежувати мінімальні розміри вікна таким чином, щоб всі елементи були видно і доступно. Якщо немає можливості розмістити компоненти таким чином, щоб всі були видні у вікні, можна використовувати закладки (типу PageControl) для розбиття компонентів на групи. Відмовки з приводу дозволу екрана теж не пропускаємо.


8. Хинт скрізь, хінт завжди


Для кнопок, особливо на панелях інструментів (типу ToolBar) повинні бути задані підказки (hint), щоб завжди було зрозуміло, навіщо потрібна та чи інша кнопка.


9. Колірна гамма


Не варто розфарбовувати компоненти на формі у всі кольори веселки. Це стомлює очі і розсіює увагу користувача. Це не виглядає "круто". Виділення кольором використовується в тому випадку, коли треба залучити увагу користувача до якогось певного елемента або певної частини вікна. Наприклад, розфарбувати світло-червоним кольором записи, в яких присутні помилки або, навпаки, світло-зеленим кольором запису, перевірка яких пройшла успішно.


Висновок


Є дуже хороший метод, який дозволяє знайти недоліки програми взагалі і інтерфейсу зокрема. Він простий: уявіть себе на місці користувача і протягом півгодини спробуйте працювати так, як працює він. Ще краще, якщо ваш користувач в межах досяжності (наприклад, працює в тій же організації). У такому випадку сядьте поруч з ним, а краще замість нього, і спробуйте зробити його роботу. Вносити дані, змінювати їх, виводити звіти і т.д. Якщо ви не знаєте, як зробити правильно, запитайте у свого користувача. Зробіть не одну-дві однотипні операції, як в отладочном режимі, а 20-30, а то й більше різних операцій, в різному порядку. Забудьте що-небудь ввести або введіть неправильно і подивіться, як програма на це відреагує. Ви досить швидко побачите слабкі місця вашої програми.


Автор статті автоматизував роботу приймальної комісії у ВНЗ, і в перший рік впровадження програми по 3-4 години на день проводив у приймальній комісії, реєструючи абітурієнтів, заповнюючи їх персональні дані і видаючи їм звіти про здачу іспитів. А у решту робочий час виправляв помилки і недоліки. Повірте, на наступний рік проблем практично не залишилося. Аналогічно було і при впровадженні кадрового модуля.


Таким чином, пам'ятайте про зручність роботи для користувачів. Хай їм буде легко і приємно працювати з вашими програмами.

Схожі статті:


Сподобалася стаття? Ви можете залишити відгук або підписатися на RSS , щоб автоматично отримувати інформацію про нові статтях.

Коментарів поки що немає.

Ваш отзыв

Поділ на параграфи відбувається автоматично, адреса електронної пошти ніколи не буде опублікований, допустимий HTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

*

*