1.5. Розробка інтерфейсу як частина загального циклу розробки

Застосовувані сьогодні методи розробки проектів найчастіше не вважаються з необхідністю розробки інтерфейсу. Цей недогляд може бути наслідком того, що фахівці з розробки інтерфейсів залучаються до проекту занадто пізно, коли можливості поліпшення якості взаємодії між користувачем і продуктом здебільшого вже загублені. Інтерфейсом зручніше за все займатися саме на початкових стадіях розробки. І якщо фахівці з інтерфейсів залучаються вже після того, як програмне забезпечення спроектоване і визначені його чи інструменти коли розробка програми вже майже довершена, те їхньої рекомендації можуть зажадати переробки усієї виконаної роботи, що, природно, є неприйнятним. Коли бюджет проекту уже вичерпаний і робітник план майже довершений, перспектива відмовлення від більшої чи частини навіть усього дизайну і готового коду, звичайно, не може викликати ентузіазму в менеджерів проекту. Так що навіть у такій сучасній книзі по керуванню проектами, як "UML Toolkіt" (Erіksson and Magnus, 1998), не говориться про необхідність розглядати інтерфейс уже на стадії аналізу вимог до проекту, що автори позначають як першу фазу його розробки. Однак у дійсності розробка інтерфейсу не повинна відкладатися до стадії технічної реалізації, що у плані Эриксона і Магнуса є третьою фазою. Визначивши задачу, для якої продукт призначений, спочатку спроектуйте інтерфейс, після чого приступайте до його реалізації. Це повторюваний процес. Визначення задачі буде мінятися під час розробки інтерфейсу. Тому весь процес розробки продукту буде проходити відповідно до змін у задачі продукту і його інтерфейсі. Тут необхідно прагнути до максимальної гнучкості. На першому етапі розробки варто визначити, що саме повинено зробити користувач для одержання того чи іншого результату і як система повинна відповідати на кожну його дію.

Користувачі не задумуються над тим, як улаштована машина, поки вона справляється зі своїми задачами. При цьому не має значення, який саме процесор використовується і чи є мова програмування объектно-ориентированным, многопоточным чи, бути може, називається якимись іншими розумними словами. Для користувачів важливіше всього зручність і результати. Але усе, що вони бачать, - це інтерфейс. Іншими словами, з погляду споживача саме інтерфейс є кінцевим продуктом.

________________________________________

Ваш час безцінний, ваша робота священна

Я привчився часто зберігати пророблену роботу, щоб навіть у випадку системного збою не утратити велику частину своєї праці. Наприкінці кожного чи абзацу навіть після декількох пропозицій я за допомогою сполучення клавіш викликаю команду збереження. Ця команда створює копію тексту на диску, де він може залишатися відносно захищеним від втрати у випадку збою. Приблизно щогодини я створюю резервну копію своєї роботи за допомогою енергонезалежного запам'ятовуючого пристрою, що може бути фізично витягнуте з комп'ютера й у такий спосіб захищено від будь-яких несподіванок у його роботі. Крім того, щотижня я зберігаю резервну копію всієї системи на зовнішньому диску. Це не виходить, що я параноїк, - я усього лише вважаю, що такий підхід практичний. Однак необхідності у всіх цих складних процедурах не повинне виникати. Система повинна розглядати всі дані, що вводяться користувачем, як безцінні. І якщо перефразувати Перший закон робототехніки Азимова: "Робот не може заподіяти шкоду чи людині своєю бездіяльністю допустити, щоб людині була заподіяна шкода", те перший закон проектування інтерфейсів повинний звучати приблизно так: "Комп'ютер не може заподіяти шкоду даним чи користувача своєю бездіяльністю допустити, щоб даним була заподіяна шкода".

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

Найкращим формулюванням другого закону інтерфейсу може бути наступне твердження: "Комп'ютер не повинний витрачати впустую ваш чи час змушувати вас виконувати дії понад необхідний". У розділі 4.3 буде розглядатися вимір обсягу роботи, необхідного для виконання тієї чи іншої задачі.

________________________________________