Етапи проектування інтерфейсу user needs. Страх чистого аркуша при проектуванні інтерфейсів. Так що ж робити, щоб почати проектувати

Принципи проектування користувальницького інтерфейсу.

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

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

Можна виділити 3 принципу розробки призначеного для користувача інтерфейсу:

Контроль користувачем інтерфейсу;

Зменшення завантаження пам'яті користувача;

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

Правила:

Необхідно дати контроль користувачу. Досвідчені проектувальники дозволяють користувачам вирішувати деякі завдання по-своєму власному рішенню. але : Необхідна наявність у користувачів необхідних навичок. Якщо завдання вирішується не користувачем, то він повинен мати можливість контролювати процес. Принципи, які дають користувачеві контроль над системою: 1) необхідно розсудливо використовувати режим. 2) надати можливість користувачу вибрати: працювати з мишею або клавіатурою, або з тим і іншим разом. 3) необхідно дозволити користувачеві сфокусувати увагу (прериваемость). 4) корисність: демонструвати користувачеві пояснюють поради та тексти. 5) негайна зворотний зв'язок і зворотні дії. 6) необхідно дати можливість користувачеві вільно орієнтуватися в інтерфейсі. 7) інтерфейс повинен пристосовуватися до користувачів з різними рівнями навичок. 8) призначений для користувача інтерфейс повинен бути зрозумілим (прозорим), тобто при хорошому інтерфейсі користувач його не сприймає, а відчуває себе як би усередині комп'ютера і може вільно маніпулювати об'єктами.

Зменшити навантаження на пам'ять користувача. Принципи: 1) не слід короткочасну пам'ять. Не слід змушувати користувачів запам'ятовувати і виконувати те, що може зробити і комп'ютер. 2) необхідно покладатися на розпізнавання, а не на повторення. Необхідно передбачати списки і меню, що містять об'єкти або документи, які можна вибрати. Чи не змушувати користувачів вводити інформацію вручну без підтримки системи. 3) необхідно забезпечити візуальні підказки. Користувачі повинні знати, де вони знаходяться, що роблять, і що вони можуть зробити в подальшому. Коли користувачі перебувають в якомусь режимі, вони повинні бути поінформовані про це посредствам відповідних індикаторів. 4) необхідно передбачити функцію скасування останньої дії, його повтору і функції установки за замовчуванням. Потрібно використовувати здатність комп'ютера зберігати і відшукувати інформацію про вибір користувача і властивості системи. Необхідно передбачити багаторівневі системи відміни і затримки команд. 5) необхідно реалізовувати прямий доступ до елементів інтерфейсу за допомогою клавіатури. Як тільки користувач добре освоїть програмний продукт, він починає відчувати потреби в прискорювачах. Однак, при їх реалізації потрібно слідувати стандартам. 6) необхідно використовувати синтаксис дій з об'єктами: об'єктно-орієнтована синтаксис дозволяє користувачеві зрозуміти взаємозв'язок між об'єктами і діями в програмному продукті. Об'єктно-орієнтована синтаксис був описаний розробниками Palo Alta Research Center (PARC). Xerex. 7) слід використовувати метафори реального міра.Метафори дозволяють переносити свої знання користувачам з реального світу в світ комп'ютерів. Якщо виявиться, що метафора не відповідає своєму призначенню в усьому інтерфейсі, необхідно вибрати нову метафору. Якщо ж метафора обрана, то слід неухильно виконувати її у всьому інтерфейсі. 8) Чи потрібно пояснювати поняття і дії. Користувачі не повинні сумніватися з приводу програмного переходу. Не потрібно показувати всі функції, а тільки ті, в яких є потреба. Необхідно забезпечити легкий доступ до найбільш часто використовуваних функцій і дій. Рідко використовувані функції слід приховати і дозволити користувачеві викликати їх у міру необхідності. Для непідготовлених користувачів необхідно використовувати режим «Майстер». 9) необхідно збільшити візуальну ясність. необхідно використовувати принципи візуального проектування для полегшення сприйняття інформації.

Послідовність призначеного для користувача інтерфейсу.Користувачі можуть переносити свої знання і навички з однієї програми в іншу програму - це переваги. Принципи створення сумісного інтерфейсу: 1) проектування послідовного інтерфейсу. користувач повинен мати опорні точки при переміщенні в інтерфейсі. Це заголовки вікон, навігаційні карти, деревоподібна структура. Крім того, користувач повинен мати можливість завершити поставлене завдання без зміни середовища роботи або перемикання між стилями введення даних. 2) загальна сумісність усіх програм. Сумісність реалізується на трьох рівнях: подача інформації; поведінку програми; техніка взаємодії. Сумісність у подачі інформації - користувач може сприймати інформацію схожу в логічному, візуальному, фізичному вигляді у всій програмі. Сумісність у поведінці - одні й ті ж об'єкти мають одне і теж поведінку. сумісність в техніці взаємодії - способи роботи з мишею і клавіатурою повинні бути однакові у всіх програмах. 3) збереження результатів взаємодії - при виконанні одних і тих же дій повинні отримувати одні і ті ж результати. 4) естетична привабливість і цілісність. 5) заохочення вивчення.

Інтерфейси.

Типи інтерфейсів:

Графічний користувальницький інтерфейс: Graphical User Interface (GUI);

Web User Interface (WUI).

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

Існує 2 підходи до побудови GUI:

Об'єктно-орієнтовані інтерфейси;

Інтерфейс, орієнтований на додаток (функціонально-орієнтований інтерфейс).

WUI: взаємодія з програмою здійснюється через інтернет по протоколу HTTP, тобто ПО генерує Web-сторінку, яку користувач переглядає і яку генерує Web-браузер.

Інші типи інтерфейсів:

Інтерфейси командного рядка: введення користувач здійснює за допомогою клавіатури, але система висновок здійснює на екрані комп'ютера (друкує текст).

Тактильні інтерфейси: реалізуються через тактильну зворотний зв'язок. Широко застосовуються в комп'ютерних симуляторах.

сенсорні інтерфейси: Це графічні інтерфейси користувача, в яких використовується сенсорний екран одночасно як пристрій введення і виведення.

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

Аттектівние ПІ: Характеризуються тим, що керують увагою користувача, визначаючи коли перервати користувача, за допомогою якого повідомлення і який рівень детальності інформації йому надати.

Інтерфейс жестів: це GUI, введення в якому здійснюється у формі жестів руками або ж за допомогою миші.

Інтерфейс на основі мовних агентів: Зроблено спробу персоніфікувати дії комп'ютера за допомогою анімованого персонажа, який реалізує взаємодію в мовній формі.

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

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

Текстові ПІ. Відрізняються від інтерфейсів командного рядка тим, що вводять текст, але застосовують інші форми введення.

Інтерфейси на базі природних мов.Введення здійснюється природною мовою (пошукові системи).

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

Масштабуються ПІ: Це GUI, в якому інформаційні об'єкти представлені з різними рівнями масштабу і деталей, причому користувач може змінювати масштаб переглядається області для відображення більшої кількості деталей.

Історія інтерфейсів: Першими з'явилися пакетні інтерфейси (1945-1968 рр.), Потім - інтерфейси командного рядка (1969-1980 рр.). в 1981 р З'явився GUI, відчутні і сенсорні інтерфейси.

стандартизація інтерфейсів: В 2007 році був опублікований стандарт ISO / IEC 24752. Цей стандарт розглядає вимоги до систем на основі інформаційних технологій. Common User Access (CUA) компанії IBM - це найбільш повне керівництво, що визначає стандарт для об'єктно-орієнтованого призначеного для користувача інтерфейсу.

Графічний користувальницький інтерфейсGUI.

Розроблено в 1981 р Складається з графічних інтерфейсів: вікна, меню, піктограми і як пристрої введення використовувалася миша в доповненні до клавіатури. Виведення інформації здійснюється на двовимірний графічний екран. Користувач використовує пристрій введення для управління положенням курсору. Інформація на екрані організована за допомогою вікон і представлена \u200b\u200bпіктограмами. Доступні команди зібрані в меню вказівного пристрою. Присутній віконний менеджер, що забезпечує взаємодію між вікнами, програмами і ОС. У ПК це все моделюється за допомогою метафор робочого столу.

взаємозв'язокGUI з об'єктно-орієнтованим ПІ.

У ООПІ користувач безпосередньо взаємодіє з об'єктами, що представляють суті в конкретній предметній області. Основні відмінності: користувач сприймає і впливає на об'єкти; користувач може класифікувати об'єкти на основі їх поведінки. У ООПІ спочатку вибирається об'єкт, а потім дії над цим об'єктів.

Технологія Naked Objects (чисті об'єкти) - це шаблон побудови інтерфейсу користувача.

У цю технологію закладені три ідеї:

Вся бізнес-логіка инкапсулируется в об'єктах предметної області;

ПІ повинен бути прямим поданням об'єктів предметної області, причому всі дії користувача повинні зводитися до створення або отримання об'єктів і викликом методів цих об'єктів.

ПІ на 100% створюється автоматично, виходячи з визначення об'єктів предметної області.

переваги: скорочення циклу розробки; можна легко вносити зміни, отже, виникає гнучкість; простий аналіз вимог користувача.

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

технологія Model-View-Controller (MVC). Одночасно це і шаблон для проектування ПІ і шаблон для побудови всієї архітектури додатку. Даний шаблон ізолює бізнес-логіку від ПІ, даючи можливість змінювати одне, не зачіпаючи інше.

Описується співвідношення між моделлю, поданням і 50 онтролером. Суцільні лінії - прямий зв'язок. Пунктирна лінія - непрямий зв'язок.

Модель - являє собою інформацію (дані), якими оперує додаток і бізнес-прищепила, використовувані для маніпуляції даними.

Вид (подання) -елементи ПІ (візуальні елементи оформлення).

контролер - реалізує передачу моделі дій користувача (натискання клавіші, руху мишею і т.д.)

опис шаблону

Шаблон для побудови програми. Зазвичай додаток розбивається на окремі рівні, що працюють на різних комп'ютерах.

Рівень представлення;

Рівень бізнес-логіки;

Рівень доступу до даних.

У MVC рівень представлення розбивається на View і Controller. Web-додаток, де вид - це html-сторінка, а контролер - це код, який обробляє динамічні дані і генерує вміст html-сторінки, модель представлена \u200b\u200bфактичними даними, збереженими в базі даних, xml-файлах і т.д. бізнес-правило - правило, яке перетворює фактичні дані у відповідь на дії користувача.

Сценарій роботи програми:

Користувач взаємодіє з ПІ (натискає кнопку);

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

Контролер інформує модель про дії користувача, приводячи до зміни стану моделі.

Вид використовує модель неявно, щоб згенерувати відповідний ПІ. Вид отримує необхідні дані з моделі, але модель не має прямого зв'язку з видом.

ПІ чекає подальших дій користувача.

Шаблон для проектування.

Модель - це предметно-орієнтоване уявлення інформації, якою оперує додаток.

Бізнес-логіка наділяє сенсом сирі, необроблені дані. У багатьох додатках використовується механізм збереження стану в базі даних. Часто для збереження стану моделі в базі даних може використовуватися бібліотеки об'єктно-реляційного відображення.

Вид відображає модель у формі придатній для взаємодій. Зазвичай - у вигляді елементів призначеного для користувача інтерфейсу. Причому для однієї і тієї ж моделі можуть використовуватися різні уявлення для різних цілей.

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

Етапи розробки призначеного для користувача інтерфейсу (процес проектування призначеного для користувача інтерфейсу)

Проектування ПІ складається з наступних етапів:

Визначення необхідної функціональності системи (аналіз вимог). Цей етап дуже важливий по своїй суті. Традиційно визначення функціональності системи виходить з відділу продажів. Для відділу продажів існує два джерела інформації (скарги наявних клієнтів і система конкурентів). Обидва ці джерела є ненадійними. Також існує два методи аналізу: 1) аналіз цілей користувача: Людям не потрібні інструменти самі по собі, а їм потрібні результати їх роботи. Основне завдання - уникнути непотрібної конкретики, тобто описом, яка повинна бути майбутня функціональність. 2) аналіз дій користувача: Цей метод полягає в спостереженні за людьми, які виконують своє завдання, користуючись уже наявними інструментами (це може бути система конкурентів і предмети реального світу). Крім того, крім дій необхідно аналізувати і результати роботи. Потрібно прагнути до мінімізації кількості функцій. Існує два підходи до виділення функцій: 1) розглядається система в цілому. виділяється максимальна кількість функцій, при цьому результати багатьох з функцій є сумою результатів інших функцій. 2) всі складові функції з системи вилучаються.

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

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

Логічний зв'язок;

Зв'язок за поданням користувачів;

Процесуальна зв'язок.

логічний зв'язок визначає взаємодію між блоками з точки зору розробника.

Зв'язок за поданням користувачів - зв'язок між блоками, що виникає в ході вирішення конкретного завдання. Зв'язок, здатна визначати зв'язку з поданням користувачів, є класифікацією за методом сортування карток. Всі поняття записуються на картку, далі групі користувачів необхідно їх розсортувати або розділити на групи. недоліки: необхідність пошуку уявлень цільової аудиторії. Необхідно як мінімум 4-5 чоловік.

процесуальні зв'язку: єдиний спосіб отримати інформацію - це спостереження за користувачами. В результаті цього спостереження ми отримуємо структуру системи, яку потрібно представити графічно.

Проектування окремих блоків. На кожному етапі проектуються окремі екрани інтерфейсу користувачів.

GOMS (Goals, Operators, Method and Selection rules - цілі, оператори, методи і правила їх вибору).

цілі - це просто цілі користувача.

Оператори - це ті дії, які програмне забезпечення дозволяє користувачеві виконувати (наприклад, дії мишею).

методи - це послідовність знайомих користувачеві дій, які дозволяють виконувати завдання.

Правила вибору - то, чим керується користувач.

Розроблено в 1983р. Всі дії користувача можна розкласти на складові. Обмежуючи номенклатуру цих складових можна заміряти час їх виконання на масі користувачів і отримати статистично вірні оцінки їх тривалості. Для визначення швидкості рішення будь-якого завдання, знаючи тривалість кожної складової, можна визначити тривалість всього процесу. Кращим процесом буде той, у якого час виконання буде мінімальним. Приклади методів: натискання кнопки миші - 0,1 сек; переміщення курсору миші (модель Фіттса визначає час позиціонування курсора миші в залежності від відстані до об'єкта і його розміру) - в середньому 1,1 сек; взяття або кидання миші - 0,4 сек; вибір дії - 1,2 сек; час реакції системи - від 0 до ∞.

Укладання глосарію.

Збір і початкова перевірка повної схеми системи.

Сучасні тенденції побудови призначених для користувача інтерфейсів.

Призначені для користувача інтерфейси розвивалися в напрямку підвищення інтелектуалізації. Основними такими заходами є:

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

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

ТЕОРІЯ АГЕНТІВ

Теорія агентів (формализуема для опису агентів і вирази бажаних властивостей цих агентів).

Методи кооперації агентів (для вивчення способів кооперативного поведінки агентів при спільному вирішенні задач).

Архітектура агентів і багатоагентних систем.

Мови програмування агентів.

Методи, мови і засоби комунікації агентів.

Методи і засоби підтримки мобільності агентів.

Властивості агентів і термінологія

Агент - це сутність, яка знаходиться в деякому середовищі, від якої вона отримує дані, і яка відображає події, що відбуваються в середовищі, інтерпретує їх і виконує команди, які впливають на середу.

При реалізації агента можна утримувати і апаратні, і програмні компоненти.

Інтелектуальний агент - розуміють програмну або апаратну систему, яка має такі властивості:

Самоконтроль (здатність контролювати свої дії);

Автономність (здатність працювати без людини)

Суспільну поведінку (здатність функціонувати з іншим агентом)

Реактивність (здатність сприймати навколишнє середовище і реагувати на її зміни)

Здатність агента брати на себе ініціативу, тобто генерувати цілі і радикально діяти для з досягнення.

Додатково від агента вимагають наявності деякого підмножини ментальних властивостей: знань (постійна частина знань агентів про себе і про навколишнє середовище, інших агентів)

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

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

Наміри - це те, що агент повинен зробити за зобов'язаннями до інших агентам, або те, що випливає з його бажань (відповідно до бажань).

Цілі - це безліч кінцевих і проміжних станів, які агент прийняв в якості стратегії поведінки.

Зобов'язання - завдання, які агент бере на себе, за дорученням інших агентів в рамках оперативного поведінки, для досягнення загальних цілей.

Теорія агентів вивчає різні способи формування опису агентів.

Для опису агентів використовується наступний засіб:

числення предикатів (можуть бути встановлені обмеження і повністю описати властивості агента неможливо)

використання метамовою

використання розширень відомих модальних логік, що містять спеціальні оператори, які мають не истинностное значення.

При виборі формальної моделі агент, зокрема може бути уявлення ментальних понять, вирішує два класи проблем:

Синтаксична проблема

семантична проблема

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

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

Для використання модальних логік при описі агентів припускають розробку засобів для опису часових аспектів «поведінки» агентів. Для цього і розробляються розширення існуючих модальних логік.

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

Моделі колективної поведінки агентів

У разі взаємодії агентів:

Агент не може вирішувати поставлену задачу самостійно і звертається до інших агентам за допомогою;

Одна велика складна задача вирішується колективом агентів.

Для того щоб агент міг взаємодіяти повинні бути вирішені наступні проблеми:

Формування спільних планів дії

Врахування інтересів компаньйонів агента

Синхронізація спільних дій

Організація переговорів про спільні дії

Розпізнавання необхідності кооперацій

Вибір підходящого партнера

Навчання поведінки в колективі

Розподіл обов'язків і декомпозиція задач

Вирішення конфліктних ситуацій та ін.

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

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

Так що ж робити, щоб почати проектувати?

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

Без досвіду і відповіді на питання «З чого почати?» виникає страх. Щось нове робити боязно, але і нескінченно сидіти склавши руки сенсу немає. Перший млинець все одно буде грудкою. Не бійтеся говорити про свій перший досвід. Будь-інтерфейс, який ви зробили, - будь він навіть жахливий - все одно можна використовувати.

створюємо історії

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

Щоб зрозуміти, що ми маємо на увазі під терміном «історія», давайте уявимо: Максим стає клієнтом автосалону «Зірка Неви» - він купив собі новий автомобіль. При укладанні договору в офісі компанії співробітники автосалону повідомляють йому про існування онлайн-системи для клієнтів, де він може бачити свої платежі, оплати по кредиту, нагадування про технічний огляд і страховку, а також новини автосалону.

З такого заходу ми починаємо «розкручувати» історію. Найбільш важливо в процесі придумування історії опрацювати всі можливі варіанти розвитку подій.

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

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

Без історії немає ні продукту, ні проекту, ні інтерфейсу. А зв'язний розповідь дозволить пояснити поведінку користувача і зрозуміти, чого йому не вистачає.

Взаємодіючи з комп'ютером, людина намагається не перетворитися в машину, а навпаки - олюднити систему. Який функціонал ні навішувати, без емоцій людині не буде цікаво. Люди очікують від комп'ютера нових вражень і реакції на свої дії. Хороші історії викликають емоційний відгук: подобається - не подобається, швидко - повільно, хочу - не хочу.

паліть дієсловом

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

Відволікання в стилі «тут було б непогано зробити кнопочки» треба обривати, бо вони відводять думка в сторону від послідовної історії. При роботі над інтерфейсом кожен повинен знати сюжет взаємодії користувача з сервісом і прокручувати його в голові. Без зв'язковий історії не виходить зв'язкових інтерфейсів.

Дайте пограти!

Популярні граблі, на які можна наступити, - це сказати «до біса теорію, дайте пограти!». Звичайно, це теж спосіб навчитися проектувати: освоюємо інструмент і по ходу справи отримуємо навик. Але проблема в тому, що інструмент не дозволить вирішити задачу правильно, в цьому зазвичай допомагають знання і досвід. І, щоб ви не витрачали час на перебір програм, коротко розповімо про них.

Я хотів би дати вам простий, але парадоксальний рада: не вірте всьому, що говорять про проектування.

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

Таких «прописних» істин багато, і вони разом народжують страшний і жахливий набір міфів про проектування - про найголовніші з них я б і хотів сьогодні поговорити.

Міф № 1. Проектування - це додаткова послуга

Проектувальник, зайнятий важливим суспільно-корисною справою

Багато хто вважає, що етап проектування - це додаткова послуга, якою можна знехтувати. Це не так.

Заради чого ми створюємо IT-продукти? Якщо ми знаходимося в своєму розумі і добрій пам'яті, ми створюємо їх задля вирішення бізнес-завдань (своїх власних чи своїх клієнтів - не так важливо); рішення цих бізнес-задач, в свою чергу, спирається на виконання створюваним продуктом завдань користувачів з урахуванням умов ринку, технологічних обмежень і всього іншого.

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

Далі на основі зібраної інформації потрібно придумати продукт, причому придумати його так, щоб він не суперечив умовам завдання, а, навпаки, сприяв би їх виконання - і такий продукт являє собою складний організм, де всі частини взаємопов'язані один з одним. Придуманий продукт, знову-таки, потрібно правильним чином зафіксувати, щоб і замовник, і розробник розуміли, що вони отримають в результаті (і в майбутньому могли б цей продукт допрацьовувати).

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

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

Міф № 2. Проектування коштує дорого

Менеджер проекту вибиває бюджет з замовника

Існує думка, що етап проектування тільки здорожує продукт.

У зв'язку з цим я обожнюю цитувати Карла Вігерса - патріарха системного проектування, автора чудової книги «Розробка вимог до програмного забезпечення» і просто розумної людини.

Карл Вігерс якось провів дослідження американського ринку IT-розробки і підрахував, що в середньому 40% бюджетів розробки марнується, Причому ці гроші втрачаються не з вини криворуких розробників або поганих замовників, а всього лише тому, що дві сторони - замовник і розробник - просто не змогли домовитися між собою.

Сорок відсотків - і це для Америки, де панують зовсім інші відносини між замовником і розробником! Для Росії, мені здається, ця цифра ще вище - рази так в півтора.

При цьому правильне системне проектування, за підрахунками того ж Вігерса, забирає 15-20% бюджетів на розробку (і ця цифра повністю підтверджується нашим досвідом).

Виходить цікавий ефект: ми витрачаємо фіксовані 15-20% на проектування, але при цьому зводимо до мінімуму «порожні» витрати (ті самі 40% бюджету), які потенційно можуть поховати проект і, до того ж, надзвичайно затягують терміни отримання працездатного продукту.

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

Міф № 3. Проектування - це написання ТЗ

Слон, зроблений по ТЗ

Часто доводиться чути, що проектування - це процес написання ТЗ, який можна прикласти до договору. Це не так.

Як ми з'ясували в ході розбору попереднього міфу, проектування мінімізує ризики розробки. Ви будете сміятися, але це і є єдиним і головним його призначенням - все інше гармонійно виникає з цього факту:

• проектування дозволяє врахувати інтереси користувачів (і тим самим мінімізувати ризики розробки);
• проектування дозволяє врахувати інтереси замовника (і тим самим мінімізувати ризики розробки);
• проектування дозволяє врахувати всі значимі зовнішні чинники (і тим самим мінімізувати ризики розробки);
• проектування дозволяє сторонам отримати єдине бачення продукту (і тим самим мінімізувати ризики розробки);
• проектування дозволяє точно спрогнозувати терміни і вартість розробки (і тим самим ... ну, ви зрозуміли).

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

Міф № 4. Проектування - це про інтерфейси

Продукт з продуманим дружнім інтерфейсом

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

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

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

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

Міф № 5. Проектувати може і менеджер

Менеджер, зайнятий профільної активністю

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

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

У великих проектах і, зокрема, в замовний розробці це грає з менеджерами дуже злий жарт: якщо менеджер встає перед дилемою вирішити проблему, пов'язану з проектом в цілому (наприклад, витягнути дизайнера із запою - абсолютно реальна історія, до речі), або вирішити проблему , пов'язану з проектуванням (більш детально прописати протокол даних в ТЗ), то будь-який менеджер вибере рішення, яке погасив пожежі, які вирують тут і зараз. Справді - недоработанное ТЗ позначиться десь на далекій перспективі, а ось вчасно не погашений проектний пожежа призведе до втрати проекту прямо в поточний момент. Та й, врешті-решт, як можна спокійно писати ТЗ, коли тебе постійно відволікають клієнти по дрібницях?

І так буде на всьому протязі розробки. Якщо до цього ціннісному аспекту додати аспект професійний (все-таки проектувальник повинен вміти багато чого з того, що не зобов'язаний знати менеджер), то легко зрозуміти, чому проектуванням повинен займатися окремий, спеціально навчена людина зі своєю системою цінностей.

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

Міф № 6. Проектуванням повинні займатися психологи

Технічне утримання продукту за версією психолога

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

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

Міф № 7. Проектування повинні займатися інженери

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

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

Хто ж такий проектувальник?

Ким же повинні бути проектувальники? Це дуже складне питання, на який я коротко можу відповісти так.

• Варто змиритися, що на «правильних» системних проектувальників ніде поки не вчать.
• Найчастіше правильний проектувальник народжується на стику між умовними гуманітарними і технічними науками.
• Найчастіше хороший проектувальник не знає, що він - хороший проектувальник, і працює по лівій спеціальності, яка його не радує.
• У такого «Неактивована» хорошого проектувальника шизофренічний послужний список, околотехніческое освіту, широкий кругозір і склад розуму доброго класичного інженера.
• Проектувальник повинен розуміти дизайнерів, розробників, замовників і користувачів.
• Проектувальник повинен вміти спілкуватися з людьми.

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

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

Єдиного підходу до проектування не існує

Проектувальник не витримує напруження пристрастей на проекті

Підходів до проектування багато, і недосвідчений читач може просто збожеволіти від великої кількості прийомів, підходів і абревіатур, щедро присмачених термінологічним бардаком (всіма цими UX, UI, CX, HCD та іншими IDDQD з кривими російськомовними аналогами).

Деякі, втім, намагаються вивести універсальні моделі проектування, але в підсумку виходить так, що в спробі об'єднати існуючі 20 (умовно) підходів до проектування ми отримуємо в підсумку 21 підхід - і методології, як здається, починають плодити самих себе.

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

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

замість висновку

Отже, що ми з вами сьогодні з'ясували?

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

І останнє прохання: не вірте на слово навіть мені - я буду тільки радий, якщо ви не будете не погоджуватися зі мною і відстоювати свою точку зору: це буде приводом для корисного і великої розмови, в ході якого може з'явитися чергова істина - і це чи не чудово?

2.2. ЕТАПИ ПРОЕКТУВАННЯ користувацького ІНТЕРФЕЙСУ

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

по-перше, учасники діалогу повинні розуміти мову один одного;

по-друге, вони не повинні говорити одночасно;

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

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

До цього слід також додати, що застосування додаткових засобів вираження сприяє кращому взаєморозумінню. Іноді одна вдала ілюстрація замінює десятки слів. Наприклад, на питання "Як пройти в бібліотеку?" найкраще відповідати, маючи під рукою карту міста.

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

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

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

Таким чином, при проектуванні користувальницького інтерфейсу необхідно визначити:

Структуру діалогу;

Можливий сценарій розвитку діалогу;

Візуальні атрибути, що відображається (синтаксис повідомлень).

2.2.1. ВИБІР СТРУКТУРИ ДІАЛОГУ

Вибір структури діалогу - це перший з етапів, який повинен бути виконаний при розробці інтерфейсу.

Розглянуті нижче чотири варіанти структури діалогу є різновидами структури типу «питання - відповідь», проте кожна з них має свої особливості і найбільш зручна для певного класу задач.

ДІАЛОГ ТИПУ «ПИТАННЯ - ВІДПОВІДЬ»

Структура діалогу типу «питання-відповідь» (Q & A) заснована на аналогії зі звичайним інтерв'ю. Система бере на себе роль інтерв'юера і отримує інформацію від користувача у вигляді відповідей на питання. Це найбільш відома структура діалогу; всі діалоги, керовані комп'ютером, в тій чи іншій мірі складаються з питань, на які користувач відповідає. Однак в структурі Q & A цей процес виражений явно. У кожній точці діалогу система виводить як підказку одне питання, на який користувач дає одну відповідь. Залежно від отриманої відповіді система може вирішити, який наступне питання задавати. Структура Q & A надає природний механізм введення як керуючих повідомлень (команд), так і даних. Ніяких обмежень на діапазон або тип вхідних даних, які можуть оброблятися, що не накладається. Існують системи, відповіді в яких даються на природній мові, але частіше використовуються пропозиції з одного слова з обмеженою граматикою.

Діалог у вигляді питань і відповідей в достатній мірі забезпечує підтримку користувача, так як навіть короткий пряме запитання при розумному побудові може бути самопоясняющім. Структура Q & A не гарантує мінімального обсягу введення, що оцінюється за кількістю натискань клавіш, однак при відповідному підборі скорочень можна зменшити будь-яку надмірність. Разом з тим, структура Q & A має один суттєвий недолік. Навіть якщо введення відбувається досить швидко, для людини, яка вже знає, які питання задає система і які відповіді потрібно на них давати, відповідати на всю серію питань досить утомливо.

З появою графічного інтерфейсу структура Q & A дещо застаріла, проте у неї є певні переваги. Ця структура може задовольнити вимоги різних користувачів і типів даних. Зокрема, така структура особливо доречна при реалізації діалогу з безліччю «відгалужень», тобто в тих випадках, коли на кожне питання передбачається велике число відповідей, кожен з яких впливає на те, яке питання буде поставлено наступним. З цієї причини структура Q & A часто використовується в експертних системах.

ДІАЛОГ НА ОСНОВІ МЕНЮ

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

Існує кілька основних форматів представлення Меню не екрані:

Список об'єктів, які обирають прямою вказівкою, або указаніемномера (або мнемонічного коду);

Меню у вигляді блоку даних;

Меню у вигляді рядка даних;

Меню у вигляді піктограм.

Меню у вигляді рядка даних може з'являтися вгорі або внизу екрану і часто залишається в цій позиції протягом усього діалогу. Таким чином, за допомогою меню зручно відображати можливі варіанти даних для введення, доступних в будь-який час роботи з системою. Якщо в системі є досить велика різноманітність варіантів дій, організовується ієрархічна структура з відповідних меню. Додаткові меню у вигляді блоків даних «спливають» на екрані в позиції, яка визначається поточним становищем покажчика, або «випадають» безпосередньо з рядка меню верхнього рівня. Ці меню зникають після вибору варіанта.

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

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

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

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

Меню - це найбільш зручна структура діалогу для непідготовлених користувачів; жорстка черговість відкриття і ієрархічна вкладеність меню може викликати роздратування професіонала, уповільнювати його роботу. Традиційна структура меню недостатньо гнучка і не в повній мірі узгоджується з методами адаптації діалогу, такими, наприклад, як випереджаюче введення, за допомогою якого можна прискорити темп роботи підготовленого користувача. Більш детально питання організації та візуального представленіяменю розглянуті в розділі «Проектування елементів управління».

ДІАЛОГ НА ОСНОВІ ЕКРАННИХ ФОРМ

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

Якщо зустрілася якась помилка, додаток не повинно заново виводити порожню форму; виводиться форма з попередніми відповідями і допущеними помилками. Новий «бланк» видається лише в разі відповідного запиту користувача.

Таким чином, цю структуру доречно застосовувати там, де джерелом даних служить існуюча вхідні ( «паперова») форма документа.

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

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

Структура діалогу на основі екранної форми забезпечує високий рівень підтримки користувача: для кожного питання форми можуть бути передбачені повідомлення про помилки і довідкова інформація. Користувачеві можна також надати допомогу, включивши деякі елементи формату відповіді в питання або в поле відповіді. Ця структура дозволяє підвищити швидкість введення даних в порівнянні зі структурою типу «питання - відповідь» і маніпулювати ширшим діапазоном вхідних даних, ніж меню; крім того, з нею можуть працювати користувачі будь-якої кваліфікації. Оскільки ця структура має послідовну, а не деревоподібну організацію, вона в меншій мірі підходить для роботи в режимі вибору варіантів. Ще однією сферою застосування екранних форм є завдання параметрів запитів в базах даних. Цей механізм іноді називають запитом за зразком ( Query by Example).

Одним з типів заповнення форм є також різноманітні меню. У таких меню користувачеві надається список варіантів і він не обмежений можливістю єдиного вибору; можна вказати кілька варіантів.

ДІАЛОГ НА ОСНОВІ КОМАНДНОГО МОВИ

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

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

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

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

Оскільки дана структура передбачає великий обсяг матеріалу, що запам'ятовується, імена команд слід вибирати так, щоб вони несли смислове навантаження і легко запам'ятовувалися. Розробник повинен прагнути уникати зайвої Функціональності, що походить від бажання створити власну команду для кожної функції, виконуваної системою, тобто не варто створювати безліч різноманітних команд з часто перекриваються функціями. Такі «благі» наміри нерідко призводять до появи великої кількості ключових слів для позначення команд і синтаксичних правил, багато з яких рідко використовуються і лише ускладнюють роботу.

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

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

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

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

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

Викладене можна представити у формі так званої «таблиці вибору» (рис. 2.1).

критерії	вибір користувача	Тип діалогу
		меню	питання - відповідь	мова команд	заповнення екранних форм
мета: запит обчислення Складний вибір Ввід данних Ввід данних (великий обсяг)		+ + +	+ + + + +	+ + + + + +	+ + +
Тип користувача: програміст непрограмістів Має досвід роботи Немає досвіду роботи		+ +	+ +	+ + *	+ + *
Час навчання: дуже мале Менше 1 дня Більше 1 дня		+ +	+ +	** +	** +
результат оцінки

* - використання цього типу діалогу даною категорією користувачів вимагає наявності системи допомоги;

** - використання коштів системи можливо тільки в обмеженому обсязі.

Мал. 2.1. Варіант таблиці вибору

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

Вибір найбільш підходящої структури діалогу на основі таблиці виконується наступним чином.

1. Закрити графи «Тип діалогу».

2. У графі «Вибір користувача» позначити критерії, що відносяться до даного застосування.

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

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

2.2.2. РОЗРОБКА СЦЕНАРІЮ ДІАЛОГУ

Розвиток діалогу в часі можна розглядати як послідовність переходів системи з одного стану в інший. Очевидно, що жодна з цих станів не повинно бути «тупиковим», тобто користувач повинен мати можливість перейти з будь-якого поточного стану діалогу в потрібне (за один або кілька кроків). Для цього в ході розробки інтерфейсу необхідно визначити всі можливі стану діалогу і шляхи переходу з одного стану в інший. Іншими словами, необхідно розробити сценарій діалогу.

Цілями розробки сценарію діалогу є:

Виявлення та усунення можливих тупикових сітуаційв ході розвитку діалогу;

Вибір раціональних шляхів переходу з одного стану діалогу в інше (з поточного в потрібне);

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

Складність розробки сценарію визначається в основному двома чинниками:

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

У свою чергу, ступінь невизначеності дій користувача залежить від обраної структури діалогу. Найбільшою детерминированностью володіє діалог на основі меню, найменшою - діалог типу «питання-відповідь», керований користувачем.

Зі сказаного випливає, що сценарій діалогу можна спростити, знизивши ступінь невизначеності дій користувача. Можливими способами вирішення цього завдання є:

використання змішаної структури діалогу (застосування меню з метою «обмеження свободи» користувача там, де це можливо);

застосування вхідного контролю введеної інформації (команд і даних).

Додаткові можливості по зниженню невизначеності дій користувача надає об'єктно-орієнтований підхід до розробки інтерфейсу, при якому для кожного об'єкта заздалегідь встановлюється перелік властивостей і допустимих операцій. Найбільш ефективний такий підхід при створенні графічного інтерфейсу; більш детально ці питання обговорюються в розділі «Особливості графічного інтерфейсу».

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

Спосіб опису сценарію діалогу залежить від ступеня його складності. Існуючі методи опису сценаріїв можна розділити на дві великі групи:

неформальні і формальні методи.

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

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

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

Мал. 2.2. крок діалогу

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

ТЕМП ВЕДЕННЯ ДІАЛОГУ

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

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

Темп ведення діалогу залежить від характеристик апаратних і програмних засобів ЕОМ, а такжеот специфіки вирішуваних завдань. Вимога відповідності темпу ведення діалогу психологічним особливостям людини висуває обмеження на значення цих характеристик не тільки «зверху», а й «знизу». Пояснимо це твердження.

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

Важливість обліку темпу ведення діалогу була усвідомлена ще в 60-х роках, коли з'явилися перші інтерактивні системи. Повільний відповідь системи не відповідає психологічним потребам користувача, що призводить до зниження ефективності його діяльності. Занадто швидкий відповідь також може створити несприятливий уявлення про систему.

Вимоги до часу відповіді залежать від того, що очікує користувач від роботи системи, і від того, як взаємодія з системою впливає на виконання його завдань. Дослідження показали [З], що якщо час відповіді менше очікуваного, точність вибору операції з меню збільшується зі збільшенням часу відповіді системи. Це пов'язано з тим, що надмірно швидкий відповідь системи як би «підганяє» користувача, змушує його метушитися в прагненні «не відставати» від більш розторопного партнера по спілкуванню. Помічено, що досвідчений користувач боїться працювати з системою, якщо, витративши кілька хвилин на введення, він моментально отримує від неї відповідь з повідомленням про помилку.

Час відповіді повинно відповідати природному ритму роботи користувачів. У звичайній розмові люди очікують відповіді близько 2 секунд і чекають того ж при роботі з комп'ютером. Час очікування залежить від їх стану і намірів. На уявлення користувача впливає також його попередній досвід роботи з системою.

Зазвичай человекможет одночасно запам'ятати відомості про п'ять-дев'яти предметах. Вважається також, що зберігання даних в короткочасної пам'яті обмежена за часом: близько 2 секунд для мовної інформації і 30 секунд для сенсорної. Тому люди мають схильність розбивати свою діяльність на етапи, відповідні порцій інформації, які вони можуть зберігати одночасно в пам'яті. Завершення чергового етапу називається клаузен. Затримки, що перешкоджають настанню клауз, дуже шкідливі і неприємні, так як вміст короткочасної пам'яті вимагає постійного оновлення і легко стирається під впливом зовнішніх факторів. Зате після клауз подібні затримки цілком прийнятні і навіть необхідні. Завершення завдання, що веде до відпочинку, називають закриттям. У цей момент зникає необхідність подальшого зберігання інформації і людина отримує істотне психологічне полегшення. Так як користувачі інтуїтивно прагнуть до закриття в своїй роботі, слід ділити діалоги на фрагменти, щоб користувач міг «вчасно» забувати проміжні результати.

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

Наявні результати досліджень дозволили виробити такі рекомендації по допустимому часу відповіді інтерактивної системи:

0,1 ... 0,2 с - для підтвердження фізичних дій (натискання клавіші, робота зі світловим пером, «мишею»);

0,5 ... 1,0 с - для відповіді на прості команди (наприклад, від моменту введення команди, вибору альтернативи з меню до появи нового зображення на екрані);

1 ... 2 с - при веденні зв'язкового діалогу (коли користувач сприймає серію взаємопов'язаних питань як одну порцію інформації для формування одного або декількох відповідей, затримка між наступними один за одним питаннями не повинна перевищувати зазначену тривалість);

2 ... 4 с - для відповіді на складний запит, що складається в заповненні деякої форми. Якщо затримка не впливає на іншу роботу користувача, пов'язану з першою, можуть бути прийнятні затримки до 10 с;

більше 10 с - при роботі в мультизадачності режимі, коли користувач сприймає це завдання як фоновий процес. Прийнято вважати, що якщо користувач не отримує відповідь протягом 20 с, то це не інтерактивна система. У такому випадку користувач може «забути» про завдання, зайнятися вирішенням іншого завдання і повертатися до нього тоді, коли йому буде зручно. При цьому програма повинна повідомляти користувачу, що затримка відповіді не є наслідком виходу системи з ладу (наприклад, шляхом регулярного поновлення рядка стану системи або ведення протоколу виконання завдання користувача).

МЕТОДИ розробці гнучких ІНТЕРФЕЙСУ

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

Існують три види адаптації: фіксована, повна і косметична.

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

докладний (для початківця користувача);

короткий (для підготовленого користувача).

Правило двох рівнів може бути розширено до правила N рівнів діалогу. Однак такий підхід має кілька недоліків:

1) не враховується той факт, що навички накопичуються поступово;

2) користувач може добре знати одну частину системи і зовсім не знати іншу;

3) користувач сам визначає рівень своєї підготовки, що знижує об'єктивність оцінки.

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

В даний час повна (автоматична) адаптація практично ні водної діалогової системі не реалізована.

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

Така адаптація може бути досягнута за рахунок застосування таких методів:

Використання замовчувань;

Використання скорочень;

Випереджаюче введення відповідей;

Багаторівнева допомогу;

Багатомовність.

Використання замовчувань. Сутність умовчання полягає в тому, що система використовує деякий спочатку задане значення будь-якого параметра, поки користувач не змінить його. В цьому випадку мають місце два аспекти адаптації системи:

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

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

Для зручності користувачів, що починають значення, використовувані за замовчуванням, можуть виводитися на екран разом з відповідним питанням системи, наприклад: «Дата реєстрації документа? [Поточна] ».

Найпоширеніший спосіб прийняття значень за замовчуванням - це нульовий введення, тобто просте натискання клавіші «Введення» як відповідь на питання системи. Якщо використовується командний мову, то користувач просто пропускає параметр, який використовується за умовчанням.

Використання скорочень передбачає, що користувач замість повного імені команди може вводити її будь-яке припустиме скорочена назва. На перший погляд може здатися, що скорочений введення більш зручний для користувача-початківця. Але це не зовсім так. Щоб користувач міг, не замислюючись, замінити команду коректним скороченням, він повинен досить добре представляти наявний набір команд, засвоїти «лексику» системи. Наприклад, якщо в системі є командиCopy і Compare, то починаючому простіше набрати повне ім'я, ніж вибрати коректний варіант скорочення.

Однією з модифікацій цього підходу є випереджаюче введення символів, при якому система, «дізнавшись» по перших символах команду, «дописує» її сама. Прикладом може служити інтерфейс системиGPSS / PC , В якій при введенні початкових символів команди на екран виводиться її повне ім'я, а курсор автоматично переміщається в потрібну позицію для введення параметрів цієї команди. Зрозуміло, користувач, особливо початківець, відчуває почуття «глибокої вдячності» такій системі за «посильну допомогу».

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

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

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

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

2.2.3. ВІЗУАЛЬНІ АТРИБУТИ відображається інформація

До візуальних атрибутів, що відображається відносяться:

Взаємне розташування і розмір відображуваних об'єктів;

Колірна палітра;

Засоби залучення уваги користувача. Проектування розміщення даних на екрані передбачає виконання таких дій:

1) Визначення складу інформації, яка повинна з'являтися на екрані;

2) Вибір формату представлення цієї інформації;

3) Визначення взаємного розташування даних (або об'єктів) на екрані;

4) Вибір засобів привернення уваги користувача;

5) Розробка макета розміщення даннихна екрані;

6) Оцінка ефективності розміщення інформації.

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

Загальні принципи розташування інформації на екрані повинні забезпечувати для користувача:

можливість перегляду екрану в логічній послідовності;

простоту вибору потрібної інформації;

можливість ідентифікації пов'язаних груп інформації;

различимость виняткових ситуацій (повідомлень про помилки або попереджень);

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

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

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

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

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

залишати порожнім приблизно половину екрану (вікна);

залишати порожній рядок після кожної п'ятої рядки таблиці;

залишати чотири-п'ять прогалин між стовпцями таблиці. Фрагменти тексту повинні розташовуватися на екрані так, щоб погляд користувача сам переміщався в потрібному напрямку. Вміст полів повинне не «притискатися» до краю екрану, а знаходиться в межах його горизонтальних або вертикальних осей. Меню, яке містить відносно невеликий обсяг інформації, має зміщуватися в ліву верхню частину екрана. Щоб підкреслити симетрію, вміст і найменування полів, що відносяться до однієї групи, повинні вирівнюватися по вертикалі. По можливості необхідно вирівнювати все логічно пов'язані групи даних.

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

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

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

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

При використанні методу прямокутників після розбиття екрану на поля кожне з них заповнюється довільним текстом і відділяється від інших по всьому периметру, по крайней мере, одним пропуском. Через центр екрану подумки проводяться осі, що дозволяють оцінити збалансованість розміщення полів.

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

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

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

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

Запропоноване поділ не є універсальним. Кожен з етапів можна поділити на підетапи. І на підпідетапи - так процес виглядає ще складніше, а значить дорожче в очах клієнтів :-)

1. Збір даних

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

• спілкується з клієнтом, Щоб зрозуміти сенс і філософію програми;
• дивиться напрацювання: Готові прототипи (нехай навіть вони існують тільки на серветці);
• аналізує програми конкурентів (І, можливо, проводить тестування юзабіліті програм конкурентів);
• проводить структуровані інтерв'ю з клієнтами або потенційними клієнтами.

2. Проектування

На цьому етапі розробки інтерфейсу програми дизайнер:

• визначає сітку, кольору, шрифти і фон;
• а також часто створює нестандартні елементи управління, такі як випадають меню.

Природно, на кожному з етапів йде обговорення і, при необхідності, безкоштовна доробка. Ваше замовлення ви отримаєте або в якості графічних файлів у форматі Photoshop, Або у вигляді HTML- або XAML-коду.

4. Імплементація

Коли з інтерфейсом все зрозуміло, справа залишається за небагатьом :) Як правило, наші клієнти тримають штатних програмістів, а нас залучають для різних робіт, пов'язаних з призначеним для користувача інтерфейсом, від проектування до створення іконок. Однак, тим клієнтам, у яких немає власних розробників, ми пропонуємо розробку та тестування веб-додатків і мобільних додатків під iOS. У нас є постійний відділ розробників і тестувальників. Ми гарантуємо: ніякого фрілансу.

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

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

5. Юзабіліті-тестування

Залучення до проекту хорошого дизайнера інтерфейсів не врятує від необхідності систематично проводити тести юзабіліті. Покладатися тільки на «геніального дизайнера інтерфейсів» шкідливо з наступних причин:

• природно потрібно намагатися залучити до роботи над проектом кращих дизайнерів інтерфейсу (наприклад, VisualPharm :) Але, на жаль, це не завжди можливо. Часом у вашому проекті беруть участь ті люди, яких ви можете до нього залучити, А не ті, про роботу з якими ви мрієте;
• дизайн не є точною наукою; навіть якщо ваш дизайнер геній, не всі його ідеї однаково хороші. Тому для зменшення ризику логічним буде піддати всі ці ідеї перевірці в реальних умовах з реальними користувачами. (Нагадуємо, нові ідеї можна перевірити за мінімальними витратами за допомогою таких технік, як паперовий прототип);
• яким чином дизайнери інтерфейсів взагалі стають хорошими дизайнерами? Дуже просто: навчаючись на досвіді того, які ідеї працюють, а які ні. але для отримання цього досвіду необхідні тести, Які і проводять фахівці з юзабіліті;
• навіть найкращі дизайнери можуть створити успішний продукт тільки в тому випадку, якщо вони вирішують правильно поставлене завдання. Чудовий інтерфейс не допоможе, якщо безграмотно збудований функціонал. А яким чиномдизайнери інтерфейсівдізнаються, що необхідно користувачам? Відповідь проста: за допомогою юзабіліті-досліджень;
• ніхто не ідеальний. Навіть дуже хороший дизайн може бути поліпшений, якщо його пропустити через процес поетапного поліпшення якості. На кожному етапі ви проводите тести з користувачами і на основі результатів, крок за кроком, покращуєте якість призначеного для користувача інтерфейсу.

• швидко: 2-7 днів на тест;
• дешево - на один-два порядки дешевше, ніж великі дослідження;
• в рамках вашої цільової аудиторії. Ми її знайдемо. Вам потрібні американці з середнього заходу 30-55 років, зацікавлені в російських наречених? Будь ласка.

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

терміни

Тривалість робіт залежить від кількості екранів. На проектування та дизайн одного екрану потрібно однакову кількість часу. Зазвичай нам потрібно два дніна створення прототипу (або дизайну) одного екрануі ще п'ять днів на оформлення всього замовлення. Таким чином, на розробку (проектування або дизайн) п'яти екранів знадобиться 15 робочих днів.

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

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

вартість

Проектування і дизайн одного екрану також коштують однаково:

• проектування / дизайн першого екрану варто 48 800 р. Перший екран коштує дорожче, оскільки є визначальним для всього програми. При його розробці ми повинні враховувати структуру всього програми;
• проектування / дизайн інших екранів – 18 350 р. за кожний.

Таким чином, розробка прототипу (або дизайну) п'яти екранів буде коштувати 48 800р. + 18 350р. х 4 \u003d 122 200р.

Орієнтовна вартість юзабіліті-тестування 52 500р. - 126 000р.

великі проекти

Опис, наведене вище, стосується невеликих проектів з розробки інтерфейсу програм. великі проекти буде корисно розбити на підзадачі, І проводити цикл для кожної з них. Наприклад, якби ми розробляли інтерфейс Skype, то могли б виділити такі модулі:

• інтерфейс голосового спілкування;
• інтерфейс спілкування з відео;
• управління списком контактів;
• і так далі.

Для кожного з перерахованих модулів доцільно пройти через всі етапи , Потім перейти до наступного модуля. Такий метод розробки називається Agile (Читається "еджайл"). Цю методологію прийнято поважати і згадувати кожен раз, коли хочеш справити враження на клієнтів і красивих дівчаток :-)