4.4.2. Рекомендації з проектування користувальницького інтерфейсу

Перш ніж приступати до реалізації форми (чи звіту), важливо ретельно спроектувати її (чи його) макет. Можна дати деякі корисні рекомендації зі створення макетів будь-яких форм і звітів. Зокрема, подібний макет повинний включати:

• змістовну назву;

• ясні і зрозумілі інструкції;

• логічно обґрунтовані угруповання і послідовності полів;

• візуально привабливий вид вікна форми чи звіту;

• легко пізнавані назви полів;

• погоджену термінологію і скорочення;

• погоджене використання квітів;

• візуальне виділення простору і границь полів уведення даних;

• зручні засоби переміщення курсору;

• засобу виправлення окремих помилкових символів і цілих полів;

• засобу висновку повідомлень про помилки при введенні неприпустимих значень;

• особливе виділення необов'язкових для введення полів;

• засобу висновку пояснювальних повідомлень з описом полів;

• засобу висновку повідомлення про закінчення заповнення форми.

Змістовна назва

Інформація в назві повинна ясно і недвозначно ідентифікувати призначення звіту чи форми.

Ясні і зрозумілі інструкції

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

Логічно обґрунтовані угруповання і послідовності полів

Логічно зв'язані поля в звіті чи формі варто розташовувати разом, причому їхня послідовність повинна бути логічно обґрунтованою і погодженою.

Візуально привабливий вид вікна форми чи поля звіту

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

Легко пізнавані назви полів

Назви полів повинні бути знайомі користувачу. Наприклад, якщо типова назва поля Sex (Стать) замінити його менш зрозумілим синонімом Gender (Рід), то це може заплутати деяких користувачів.

Погоджена термінологія і скорочення

Повсюдно повинні використовуватися тільки знайомі і зрозумілі терміни чи скорочення, обирані з заздалегідь погодженого списку.

Погоджене використання кольорів

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

Візуальне виділення простору і границь полів уведення даних

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

Зручні засоби переміщення курсору

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

Засоби виправлення окремих помилкових символів і цілих полів

Користувач повинний легко визначати, які саме операції доступні йому для виправлення помилки, допущеної при введенні даних. Для цієї мети звичайно використовуються найпростіші механізми, подібні до натискання клавіші <Backspace> чи повторному введенню поверх помилкових символів.

Засоби висновку повідомлень про помилки при введенні неприпустимих значень

При введенні в поле неправильних даних програма повинна виводити повідомлення про помилку. Це повідомлення повинне інформувати користувача про допущеній помилки і вказати діапазон припустимих значень.

Особливе виділення необов'язкових для введення полів

Необов'язкові для введення поля повинні бути явно відзначені за допомогою відповідного напису чи виділення особливим кольором. Подібні поля варто розташовувати після обов'язкових для введення полів.

Засоби висновку пояснювальних повідомлень з описом полів

Коли користувач поміщає курсор миші в чергове поле, то в деякім стандартному місці (наприклад, у рядку стану даного вікна) варто вивести інформацію про це поле.

Засобу висновку повідомлення про закінчення заповнення форми

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

4.5. Використання CASE-інструментів

Перший етап життєвого циклу програми бази даних - тобто планування бази даних, може також передбачати вибір найбільш придатних інструментів автоматизованого проектування і створення програм, що прийнято називати CASE-інструментами (Computer-Aided Software Engineering). У самому широкому змісті Термін "CASE-інструмент" застосуємо до будь-яких засобів автоматизованого проектування і створення програм. Подібні інструменти просто необхідні AД й АБД для досягнення максимальної ефективності їх дій по розробці бази даних. CASE-інструменти можуть включати наступні компоненти:

• словник даних, призначений для збереження інформації про дані, використовуваних у створюваному додатку;

• інструменти проектування, що забезпечують проведення аналізу даних;

• інструменти розробки корпоративної моделі даних, а також концептуальних і логічних моделей даних;

• інструменти, що дозволяють створювати прототипи програм.

Я к показано на мал. 4.5, усі CASE-інструменти можна розбити на три категорії:

• CASE-інструменти високого рівня,

• CASE-інструменти низького рівня,

• інтегровані CASE-інструменти.

CASE-інструменти високого рівня застосовуються на початкових стадіях життєвого циклу розробки баз даних, a CASE-інструменти низького рівня — на більш пізніх, починаючи зі стадії реалізації, у ході тестування і протягом усього процесу супроводу функціонуючої системи. Інтегровані CASE-інструменти застосовуються на всіх стадіях життєвого циклу системи, а тому вони повинні підтримувати усі функції CASE-інструментів як високого, так і низького рівнів.