Створення прототипів інтерфейсів, Комерція, Різне, статті

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

Будь прототип несе на собі наслідки безлічі компромісів. Наприклад, абсолютно резонно хочеться, щоб прототип максимально відповідав реальному продукту – це полегшує тестування і збільшує ймовірність виявлення структурних помилок. З іншого боку, створення прототипу, це, все-таки, підпорядкована операція, самостійної цінності не має, а значить, створювати прототип потрібно в максимально стислі терміни. Більш того, якщо розглядати прототип як засіб тестування (що, власне кажучи, і потрібно робити), виявляється, що прототип повинен легко модифікуватися. У самому справі – при тестуванні знайшли проблеми, тепер прототип потрібно переробляти і тестувати знову. От і виявляється, що якщо робити прототип детальним, красивим і функціональним, він вийде дорогим (перш за все щодо витраченого на нього часу) і при цьому слабко підходящим для модифікування.

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

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


Перший тип – примітивний

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

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

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

Якщо вам хочеться йти в ногу з прогресом, ви можете скористатися системою DENIM. Ця програма «емулює» листок паперу і ручку з гумкою, при цьому дозволяє постачати вийшов псевдо-паперовий прототип зародковій інтерактивністю. Так, наприклад, ви можете без праці зробити так, щоб кнопка, яку ви намалюєте, автоматично відкривала інший екран. На жаль, DENIM володіє певними недоліками. По-перше, він дуже функціонально бідний (як-не-проект некомерційний). По-друге, DENIM сам є полігоном інтерфейсних рішень (в результаті звичайної панеллю інструментів виявляється дуже незручно користуватися). Втім, це має і свої переваги – де ще, наприклад, можна побачити в дії круглі меню?


Другий тип – напівреальний

Найпоширенішим інструментом для створення прототипів другого типу є MS Visio. Деяку конкуренцію йому можуть скласти MS PowerPoint і Macromedia FreeHand (і взагалі будь-ілюстративний пакет, володіє можливістю працювати з кількома сторінками) але можливості PowerPoint для такої роботи дуже малі, а можливості FreeHand, навпаки, занадто великі. Ні те ні інше швидкість роботи не збільшує.

При роботі з Visio можна вибрати одну з двох можливостей: можна або малювати все екрани на одному аркуші, з’єднуючи взаємопов’язані елементи управління та екрани лініями, або малювати кожен екран на окремому аркуші, пов’язуючи екрани посиланнями. Перший варіант хороший для вас, оскільки дозволяє оцінити інтерфейс в цілому, другий – для замовника і суб’єктів тестування, оскільки його легше зрозуміти. Як правило, перетворити другий варіант в перший виявляється набагато легше.

Серед численних наборів заготовок в Visio є і набір з елементами інтерфейсу Windows, проте ці заготовки виконані досить незграбно, з величезною кількістю зайвих деталей. Користуватися можна тільки заготовками для радіокнопок і чекбоксів (які реалізовані непогано), а також заготівлею для смужки прокрутки. Оскільки створення власних інтерактивних заготовок непроблематично, я рекомендую створити свій набір і користуватися ним. Сам я, втім, так не роблю, а просто малюю потрібні мені елементи на ходу. Виходить трошки повільніше, ніж користуватися готовими, але зате виглядає прототип краще (часу ж для створення власного набору в мене немає).

Великою перевагою Visio є можливість записувати результат в HTML-файл, що дозволяє без проблем тестувати інтерфейс на території суб’єктів (витягнути суб’єкта тестування до себе досить проблематично). Раніше це міг тільки PowerPoint, ніж, багато в чому, і пояснювалася його популярність як інструмент для створення прототипів. Зараз це вміє і Visio (зверніть увагу, що збереження в HTML початок нормально працювати тільки в Visio 2001, з іншого боку, більш ранні версії краще працюють з російською мовою).

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


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

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

Ваш отзыв

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

*

*