Глава 12
Принципи, інструкції
і посібники зі стилю
Принципи, стандарти, інструкції і посібники, що стосуються практичності і ПІ, звичайно не розглядаються в документації по процесах створення ПО і не враховуються при плануванні розробки більшості продуктів. Розробка посібника зі стилю звичайно зв'язана зі спізнілими міркуваннями, що приводять до роботи, що у підсумку лягає на плечі бригади розроблювачів продукту і повинна виконуватися за рахунок її наявних ресурсів у рамках існуючого плану-графіка. Однак посібник зі стилю ПІ у виді документа або в програмній формі являє собою ключовий компонент постачання - результат виконання однієї з задач концептуального проектування.
Багато компаній витрачають значні зусилля, розробляючи внутрішні посібники зі стилю ПІ, щоб компенсувати недоліки загальних посібників, хоча велика частина з цих зусиль не приносить бажаних результатів у відношенні практичності, інтеграції і погодженості стосовно до продуктів, розроблювальним незалежними бригадами. Наслідком даної проблеми є ріст витрат на навчання, зниження продуктивності і почуття глибокого розчарування в користувачів, проектувальників, розроблювачів і менеджерів.
У розділах даної глави розглядаються наступні питання.
" Гідні уваги принципи, стандарти, інструкції і посібники зі стилю.
" Деякі визначення.
" посібники, Що Наказують, по стилі.
" рішення, Що Наказують, для загальних проблем.
" Розробка посібників, що наказують, по стилі.
" Точка зору керівництва.
" Корисні методи.
" Принципи й інструкції для проекту.
У даній главі розглядається питання про те, що необхідно знати проектній бригаді про вибір і використання проектних принципів і інструкцій. Далі вказуються розходження в поняттях принципів, інструкцій і стандартів. Потім будуть приведене визначення посібника зі стилю ПІ, характеристики ефективних посібників зі стилю і методів їхньої розробки стосовно до ПІ продукту, інформаційних і візуальних об'єктів, а також інших артефактів. Застосування орієнтованих на користувачів методів розробки рекомендується при розробці посібників зі стилю тільки в тих випадках, коли користувачі входять у проектну бригаду.
У главі докладно описуються посібники, що наказують, по стилі. Пропоновані методи їхньої розробки розглядаються з технічної й управлінської точки зору. Приводяться дуже специфічні приклади стилю, що наказує, для використання елементів GUІ-, WUІ- і HUі-интерфейса, функціональних можливостей, погодженості й інтеграції. Аналізуються процеси розробки керівництва, що наказує, по стилі, а
також процеси його використання розроблювачами і керівниками (мал. 12.1).
Гідні уваги принципи,
стандарти, інструкції і посібники
зі стилю
Існує ряд посібників зі стилю ПІ, створених постачальниками платформ ОС і/чи броузеров. Ці посібники зі стилю для платформ носять загальний характер у тім змісті, що не містять указівок по досягненню специфічних і погоджених результатів високого рівня для якого-небудь чи додатка пакета додатків, або для різнорідної сукупності додатків, що функціонують на даній платформі. Це твердження можна проілюструвати наступними прикладами.
" Існує тенденція надавати розроблювачам посібника з забезпечення погодженості для низкоуровневых структур елементів керування і меню.
" Існують обмежені посібники з забезпеченню погодженості стосовно до концептуальних і топологічних моделей, интерфейсным і функціональним можливостям додатків, а також до методів інтеграції різних додатків.
" Використання подібних посібників зі стилю приводить до значної непогодженості між додатками.
Компанії витрачають значні зусилля, розробляючи внутрішні посібники зі стилю ПІ, щоб компенсувати недоліки загальних посібників. Багато хто з цих зусиль не приносять бажаних результатів у відношенні практичності, інтеграції і погодженості стосовно до продуктів, розроблювальним незалежними бригадами. Наслідком даної проблеми є ріст витрат на навчання, зниження продуктивності і почуття глибокого розчарування в користувачів, проектувальників, розроблювачів і менеджерів.
Корисне правило. Виходячи з кращих намірів, ми залишаємося непослідовними (навіть стосовно себе). Ціль посібника зі стилю складається саме в тім, щоб допомогти нам бути послідовними.
Деякі визначення
Перш ніж поглибитися в деталі, пропонуємо кілька визначень для того, щоб досягти загального розуміння.
Принципи. Принципи- це загальні вказівки по проектуванню, що носять якісний характер і відносяться до категорії тверджень, яких полез-но дотримувати. Приклад часто проголошуваного принципу проектування - прагнення до простоти. Досягнення простоти завжди в центрі уваги користувачів, розроблювачів, експертів по оцінці й інших фахівцях, так чи інакше зв'язаних із програмним забезпеченням. Оцінки фактичної відповідності цьому принципу важко піддаються безпосередньому виміру, суб'єктивні і є питанням міри, з яким до них потрібно підходити. Можна без праці скласти довгий перелік принципів, що дуже важко використовувати на практиці.
Корисне правило. Виберіть не більш 10 важливих принципів, а потім виробіть інструкції, що містять вимірні оцінки для цих принципів, так щоб вони стали діючими і практичними.
Крім принципу простоти, раніше згадувалися такі принципи, як эстетич-ность, продуктивність і пристосовність.
Інструкції. Інструкція (чи провідна вказівка) - це правило проектування, що корисно при реалізації і легко піддається виміру в термінах відповідності. От приклад подібної інструкції: "Використовуйте червоний (RGB 255,0,0) колір для тексту попереджуючого повідомлення, відображуваного на білому тлі." (Колірна модель RGB (сокр. від Red-Green-Blue - "червоний", "зелений", "синій") - це основна палітра, використовувана в програмуванні і комп'ютерній графіці. - Прим. ред.)
Виконання інструкцій легко піддається безпосередньому виміру, вони об'єктивні і конкретні. У багатьох посібниках зі стилю інструкції приводяться як правила, а інші вказівки як рекомендації.
Корисне правило. Розробляйте тільки такі інструкції, що дійсно необхідні для проектування і реалізації.
Стандарти. Стандарти - це провідні вказівки, що відбиваються безпосередньо в ПІ операційної чи системи яким дотримує велика кількість ведучих організацій галузі при розробці додатків. Стандарти найвищого рівня розробляються організаціями на зразок Міжнародної організації по стандартизації (Іnternatіonal Standardіzatіon Organіzatіon- ІSO). Приклад стандарту ПІ, орієнтованого на визначену платформу, - використання терміна Edіt (Виправлення) для найменування меню, що містить команди роботи з буфером обміну.
Корисне правило. Завжди випливайте галузевим стандартам, якщо тільки у вас немає твердої, заснованої на думці користувачів впевненості в доцільності відхилень.
Посібник зі стилю. Посібник зі стилю ПІ - це концептуальна і дуже высокоуровневая специфікація, що описує загальний зовнішній вигляд, поводження і користувальницьку взаємодію, а унікальні подробиці, що стосуються ПІ додатка, опускаються.
Корисне правило. Посібник зі стилю варто розробляти виходячи з І нестатків проекту, але при цьому прагнути уникнути невдоволення спонсорів, користувачів проекту і користувачів продукту.
Посібник зі стилю можна уявити собі як высокоуровневый чи огляд керівництво користувача, що описує спосіб використання чи продукту пакета додатків. Посібник зі стилю ПІ містить принципи, інструкції і стандар , застосовувані при проектуванні продукту.
Корисне правило. Наявність принципів, стандартів, інструкцій і посібників зі стилю необхідне, але недостатня умова постачання високоякісного програмного забезпечення ПІ. У загальному випадку, кращий підхід полягає в тім, щоб підтвердити обґрунтованість використання яких-небудь посібників стосовно до конкретного продукту, спираючи на думку проектної бригади і кінцевих користувачів.
Деякі приклади загальних елементів стилю ПІ включають використання кольору, термінів, шрифтів, графіки, звуку, загальних концептуальних моделей, топологічних моделей, загальних функцій, проектних стереотипів і загальних форматів для конкретних типів даних. На противагу цьому приклади конкретної інформації про додаток включають довжину і діапазон значень полів, джерела даних, конкретний порядок табуляції й унікальних функцій.
Проблема. Традиційні посібники зі стилю ПІ носять описовий ха-рактер (тобто дається загальна вказівка без конкретизації директиви, що підказується,). Інструкції описового типу рекомендують розроблювачу ПІ використовувати вікна в різних цілях, наприклад, для відображення чи об'єктів дій. Однак керівництво описового типу слабко конкретизує чи інструкції директиви у відношенні того, як саме відображати чи об'єкт дія усередині чи вікна бажане поводження при взаємодії.
Розроблювач повинний виділити конкретні деталі, цілком прочитавши посібник зі стилю, сформувати бажаний стиль, а потім визначити конкретні деталі додатка, що виходять за рамки базисних властивостей ПІ. Типова складність стилю для ПІ, що проектна бригада повинна будувати, виходячи з наступних складових, показана на мал. 12.2.
" Базові компоненти ПІ (стандартні елементи керування).
" Користувальницькі елементи чи керування методи для конкретних нестатків додатка (візерунки з "хлібних крихт"). ("Хлібні крихти" - оператори, що вбудовуються спеціально в програму отладочные, що служать дороговказною ниткою для пошуку причин аномального поводження програми при налагодженні - як хлібні крихти в казці братів Гримм, де герої блукали по лісі - Прим. ред.)
" Інтеграція конкретних елементів ПІ (розташування списків на сторінках).
Сучасні стилі ПІ. Навіть незважаючи на те, що GUІ-, WUІ- і HUі-стили добре відомо в індустрії програмних засобів, деякі підприємства як і раніше продовжують переносити централізовані додатки в ці стилі. Крім того, багато нових додатків створюються розроблювачами з невеликим досвідом у цих технологіях і проектуванні ПІ. Сучасних посібників зі стилю недостатньо для того, щоб допомогти недосвідченим розроблювачам уникнути розповсюджених пасток, що ведуть до непрактичних додатків і інтерфейсів. Крім цього, традиційні посібники зі стилю не допомагають новим розроблювачам у використанні можливостей, властивим сучасним стилям.
На що звертати увагу. Розроблювачі додатків звертають особливу увагу на використання компонентів ПІ для одержання належного ефекту і гарантію того, що прикладний рівень ПІ відрізняється практичністю і внутрішньою погодженістю. Розроблювачі GUІ-, WUІ- і HUі-ориентированных додатків не зосереджуються на розробці компонентів ПІ для представлення зовнішнього вигляду і поводження, якщо тільки це не є зовсім необхідним.
Розроблювачі Пи-ориентированных додатків концентрують свою увагу на наступних питаннях.
" Належне використання стилів ПІ (елементи керування, списки, меню, полючи і т.д.).
" Прикладний ПІ (передбачувана користувальницька модель, установка, поводження робочого столу, використовувані особливості ПІ і предметної області, об'єктні моделі, моделі представлення, моделі підтримки користувачів, командні моделі, моделі потоку задач, ефективне використання апаратного забезпечення і т.д.).
" Практичність (запобігання розповсюджених проблем, наприклад, занадто великої кількості екранів/кроків роботи).
" Погодженість (спільність між додатками, що виходить за рамки базових властивостей ПІ).
" Інтеграція (використання безпосереднього маніпулювання, буфера обміну і т.д.).
Труднощі. Основні труднощі для проектної бригади полягають у тому, щоб вийти загальна мова з користувачами і розроблювачами. Інші труднощі полягають у тім, щоб передбачати й уникнути розповсюджених проблем, що стосуються ПІ - орієнтованих додатків.
З огляду на величезну кількість деталей, зв'язаних із прикладним рівнем ПІ і способом використання елементів керування ПІ, не дивно, що різні розроблювачі, що працюють в одній і тій же предметній області, використовують ту саму описову інформацію для досягнення досконала різних результатів. Тут никоим образом не розглядаються цілком осі простору компонент користувальницького інтерфейсу (мал. 12.3). Як видно з малюнка, стиль ПІ і прикладний стиль ПІ впливають на досягнутий рівень практичності і погодженості.
Очевидно, що одне з рішень проблеми практичності, інтеграції і погодженості стосовно до декількох додатків полягає в створенні єдиного проекту системного рівня для набору додатків. Однак цей підхід важко втілити на практиці для великих організацій, що експлуатують велику кількість існуючих додатків, що використовуються загальним колективом користувачів. У деяких випадках немає необхідності в єдиному проекті системного рівня для досягнення організаційних цілей у відношенні термінів, вартості, ПІ і продуктивності роботи користувачів, а також рівня їхньої задоволеності. У подібних випадках необхідною і достатньою відповіддю на проблему служать посібники, що наказують, по стилі.
Керівництво, що наказує, по стилі дає точні і засновані на досвіді проектні інструкції, спрямовані на конкретні чи проблеми досягнення конкретних результатів. Керівництво, що наказує, по стилі звертається до обох осей простору компонент ПІ (мал. 12.4) і пропонує рішення багатьох проблем, властивих посібникам зі стилю і розробк, що представляють собою як, постачальників ОС, так і внутріфірмові розробки. Використання провідних указівок приводить до створення практичних, інтегрованих і погоджених продуктів. Інструкції виступають у формі правил використання елементів керування ПІ, проектних рішень і застосування прикладних елементів чи ПІ методів, що сприяють створенню погоджених і інтегрованих додатків.
Посібники, що наказують, по стилі забезпечують правила і директиви, призначені для досягнення конкретних результатів стосовно до чи додатка сукупності додатків.
Рамки посібників, що наказують, по стилі досить широкі, щоб давати результати по використанню ПІ, характеристикам предметної області, ПІ, погодженості й інтеграції. Використовуване до розробки керівництво, що наказує, по стилі допомагає проектувальникам досягти конкретних результатів. Подібний підхід застосовується після спроби забезпечити коректні інструкції для додатка, що не задовольняє передбачуваним цілям чи випробує проблеми з практичністю. Критичний фактор успіху керівництва, що наказує, по стилі складається в об'єктивній і перевірці відповідності, що піддається, вимогам.
Корисне правило. Уключите всі основні проектні стереотипи ПІ для поводження, зовнішнього вигляду і користувальницької взаємодії в керівництво, що наказує, по стилі.
Приклад для списків і таблиць. Розглянемо приклад моделі, що наказує, для простого списку об'єктів, відображуваних у вікні Web - броузера, де простота визначається обсягом набору дій, виконання яких можливо над чи списком його елементами (див. мал. 12.4).
Нижче приводиться підмножина можливих інструкцій, що наказують.
" Використовуйте таблицю для відображення списку об'єктів і даних по табуляції.
o Для ясності помістите заголовок так, щоб він був вирівняний по лівому краї над таблицею.
o Поля, що керують умістом таблиці, відображаються над таблицею і підзаголовком.
" Таблиця вирівнюється по центрі сторінки й оточена вільним місцем.
o Заголовок першого стовпця вирівняний по лівому краї.
o Заголовки інших стовпців вирівняні по центрі стовпця.
o Текстова інформація усередині стовпця вирівняна по лівому краї.
o o Числова інформація усередині стовпця вирівняна по правому краї.
" Використання кольору.
o У рядку заголовка текст відображається білим кольором на темно-синім тлі (#336699).
o За винятком посилань текст у першому рядку відображається чорним кольором на білому тлі.
o Інші рядки відображаються як чорний текст на ясно-синім тлі (#9999FF0).
o Між стовпцями відображається біла розділова лінія.
" Команди доступу.
o Команда Open (Відкрити) використовується за замовчуванням для елементів списку за допомогою натискання клавіші <Enter> (одиночного щиглика мишею).
o Для об'єкта Lіst (Список) і об'єктів-елементів списку передбачене спливаюче меню.
o При використанні кнопок для набору команд роботи зі списком вони групуються під списком і затінюються, якщо їхнє використання заборонене.
Інструкції, що наказують, точно вказують, яким образом додаток використовує компоненти ПІ. Кількість інструкцій, що наказують, може бути досить велико, однак для кожного проекту варто визначити, що потрібно для досягнення поставлених цілей.
Корисне правило. Уявляйте собі інструкції, що наказують, як кращі "інгредієнти" "рецепта" ПІ.
Приклад ДЛЯ об'єкта. Для багатьох об'єктів предметної області також не-обходжене керівництво, що наказує. Як приклад розглянемо Web-орієнтований додаток, для об'єкта якого використовується метафора реальної записної книжки на противагу додаткам типу записної книжки з традиційним ПІ.
o Для представлення об'єкта використовуйте метафору записної книжки, у якій природним образом за допомогою індексних вкладок організований невеликий, зв'язаний набір даних чи інших об'єктів.
o Індексні вкладки відображаються уздовж верхнього краю записної книжки.
o У записній книжці використовується невелика кількість вкладок, що неперекриваються, для яких не потрібно горизонтальної чи сторінки прокручування вкладок на сторінці встановленого за замовчуванням розміру.
o Які-небудь молодші (не основні) вкладки не використовуються.
o Яке-небудь візуальне зв'язування в нижній частині записної книжки не використовується.
o Записна книжка вирівняна по центрі сторінки й оточена вільним місцем.
o Щоб вкладки були однакового розміру, для їхнього позначення використовуйте короткі терміни, чи абревіатури піктограми (розташовані в порядку переваги).
o На одній вкладці розміщається одна сторінка інформації.
Крім розпоряджень по використанню стандартних елементів ПІ, можна запропонувати розпорядження по способі використання метафори записної книжки. Візуальне представлення зображує топологічну модель для записної книжки, що відображається наочно в оточенні вільного простору навколо графічної області. Дані розташовані в тілі кожної записної книжки.
Рішення, що наказують, для загальних проблем
Для кожної проблеми, будь те загальна проблема для Пи-ориентированных чи додатків унікальна проблема для конкретного додатка, визначаються інструкції, що наказують. Нижче приведені приклади загальних проблем і рішень, що наказують, для них.
Розмір екрана. Багато розроблювачів схильні без необхідності проектувати дуже великі екрани, що являють собою навряд чи не цілком заповнені чи вікна сторінки броузера. У многостраничных чи многооконных додатках це приводить до значного росту обсягу операцій керування і навігації по вікнах.
Розпорядження. Початковий розмір екрана для клієнтської області еквівалентнийі області 12,7x17,8 див чи 10,2x15,2 див для монітора з діагоналлю 17 дюймів.
Кількість екранів/кроків роботи. Для багатьох додатків наблю-дается тенденція до реалізації традиційної ієрархії меню з використанням чи вікон сторінок броузеров. Це приводить до великої кількості робочих кроків по відкриттю, закриттю і маніпулюванню з чи вікнами сторінками броузеров.
Розпорядження. Максимальна кількість вікон/сторінок для об'єктів, між якими можливий перехід при роботі з часто використовуваною задачею, дорівнює трьом: для списку, об'єкта і подобъекта.
Об'єктна модель. Додатки розробляються разом з явними чи неявними передбачуваними користувальницькими моделями, структурами об'єктів і топологічних моделей. Представляється, що по більшій частині додатка в рамках організації розробляються разом з набором моделей, що змінюються в широких межах. Як наслідок, у кінцевих користувачів виникають труднощ при вивченні цих моделей і в роботі з неузгодженими стереотипами представлення, використання і підтримки.
Розпорядження. Використовуйте фізичні моделі об'єктів з візуальними представленнями, еквівалентними їхнім реальним аналогам.
Модель доступу до команд. Багато додатків мають загальні функції, у той же час багато додатків, що повинні мати цими об-щими функції, не володіють ними. Прикладом подібної загальної функції може служити сортування списку в зростаючому й убутному порядку. Навіть коли загальна функція доступна, у розпорядженні користувача не завжди мається загальний метод доступу до опції стосовно до всіх додатків, з якими він працює. Доступ до функції може здійснюватися з використанням рядка меню і выпадающего меню, панелей інструментів, що спливають меню, клавіш швидкого вибору команд і щиглика мишею на заголовках стовпців списку. Як наслідок, кінцевим користувачам сутужніше навчатися і виробляти звичні прийоми роботи.
Розпорядження. Доступ до кожної операції здійснюється за допомогою рядка меню, що випадає і спливає меню. Доступ до найбільше часто використовуваних функцій також здійснюється за допомогою клавіш швидкого вибору команд і кнопок панелі інструментів. Жодна з операцій не доступна тільки за допомогою взаємодії з покажчиком миші.
Зразкова схема посібника зі стилю. На мал. 12.5 показана схема керівництва, що наказує, по стилі. Уміст схеми надзвичайно широко і вичерпно. Можливі різні підходи до створення схеми (наприклад, схеми, більш близькі до того, що називається специфікацією ПІ, чи процессно - орієнтований погляд на проектування і розробку ПІ). Найважливіший момент полягає в наданні необхідної інформації таким чином, щоб її легко могла використовувати проектна бригада.
Зразкова схема інструкції. При написанні інструкцій, що наказують, використовується постійна схема. По можливості сутність інструкції зображується в графічній формі при безумовній погодженості з іншими стосовними до справи інструкціями. На мал. 12.6 показана підмножина відповідних інструкцій для використання символів клавіш, що прискорюють, GUі-ориентированного додатка.
У загальному випадку схема інструкції, що наказує, включає наступні елементи.
" Визначення терміна, чи поняття властивості.
" Візуальне чи графічне зображення розглянутого предмета.
" Приклад(-ы).
" Вимірні і необхідні правила використання.
" Визначені чи зарезервовані елементи, що базуються на чи системі пакеті додатків.
" Підказки і методи використання.
" Обґрунтування.
" Посилання, шаблони і приклади програмного коду.
Розробка
керівництва, що наказує, по стилі
Розробка посібника зі стилю ПІ для додатка вимагає істотних витрат незалежно від використовуваного підходу. Як правило, до розробки залучається кілька людей на тривалий період часу, протягом якого звичайно ведуться переговори і дебати в спробах дійти згоди у відношенні питань стилю. Найчастіше для того, щоб домогтися практичності, інтеграції й узгодженості, необхідні компроміси, що зм'якшують інструкції.
Нижче приводяться основні особливості, властивій розробці керівництва, що наказує, по стилі.
Цілеспрямованість. Керівництво, що наказує, по стилі спрямовано на досягнення ясно сформульованих конкретних результатів. При цьому визначаються бажані, конкретні і вимірні результати. Якщо мети не поставлені, проектна бригада не може чи почати продовжувати розробку посібника зі стилю.
Підтримка керівництва. Оскільки розробка і застосування предписы-вающего посібника зі стилю до новим чи існуючим продуктам зв'язані зі значними витратами, вони вимагають підтримки з боку керівництва. Ця підтримка може знадобитися в таких аспектах, як внесення змін, суперечки з розроблювачами, що не бажають вносити зміни, план-графік робіт, якому варто витримувати, необхідні ресурси і потенційні доробки. Керівники повинні виявляти твердість у підтримці цілей і проведенні необхідних перетворень. У противному випадку не варто братися за розробку керівництва, що наказує, по стилі.
Ранній початок і безупинне продовження. Розробка руково-дства по стилі починається на етапі концептуального проектування і продовжується протягом усієї розробки. Спочатку виявляються очевидні елементи стилю, а більш тонкі і неочевидні потенційні елементи виявляються і додаються з часом .
Ефективність. Природно, що наказує посібник зі стилю повинний відповідати поставлена цілям, а його розробка повинна бути ефективної по витратах і витримана по заданих термінах.
Орієнтація на користувачів. Бажані результати у відношенні продукту виражаються в користувальницьких термінах.
Орієнтація на розроблювачів. Бажані результати у відношенні користувачів формулюються в термінах, зрозумілих бригаді реалізації. Це досягається за рахунок використання дуже конкретних інструкцій. Дуже ефективне звертання до точно визначених елементів керування й елементам стилю, що повинні використовувати розроблювачі.
Спрощення реалізації. Найбільш ефективний метод формування посібника зі стилю - це використання прикладів програм (фрагментів коду, алгоритмів, структури чи даних шаблонів сторінок, що служать як чи стереотипи прикладів) для повторного використання розроблювачами. Подібний підхід полегшує тягар реалізації і тестування.
Реализуемость. Керівництво, що наказує, по стилі завжди описує методи, реалізовані в рамках обмежень на терміни, ресурси і кваліфікацію персоналу. Методи, що вимагають великих витрат і применшують значення продукту і користувачів, не використовуються.
Тісто - придатність. Розпорядження не має змісту складати, якщо їхній не можна протестувати об'єктивним образом за допомогою незалежної бригади тестировщиков. Тестові прецеденти для розпоряджень складаються з використанням керівництва, що наказує, по стилі як высокоуровневой специфікації поводження, зовнішнього вигляду і користувальницької взаємодії. Спосіб складання й інтерпретації розпоряджень позбавлений суб'єктивності. Тут немає простору для думок - рішення або вірне, або невірно. У цьому змісті інструкція піддається зміні і легко перевіряється. Якщо додаток не відповідає керівництву, що наказує, по стилі, складається план усунення дефектів.
Конкретність. Кожне розпорядження повинне бути конкретним. Варто уникати невизначеності.
Доцільність. Розпорядження має сенс складати тільки в тому випадку, якщо вони безпосередньо корисні з погляду цілей у відношенні ПІ, практичності, чи погодженості інтеграції. У противному випадку розпорядження чи не складається відкладається на більш пізніше час.
Доречність. Розпорядження вирішує конкретну або не складається.
Гнучкість. Керівництво, що наказує, по стилі відрізняється гнучкістю і допускає багатозначні варіанти в об'єктів, команд і моделей взаємодії. Розмаїтість іноді має сенс стосовно до різних об'єктів кінцевих користувачів.
Повнота. Сферу розгляду керівництва, що наказує, по стилі складає цілісний досвід кінцевих користувачів. Власне кажучи інсталяція, поводження робочого столу, зовнішній вигляд, документація, ефективність і інші види сприйманого користувачем поводження і користувальницької взаємодії складають дійсний зміст посібника зі стилю в тій мері, у який це потрібно для проекту.
Обсяг. Обсяг посібників, що наказують, по стилі визначається необходимо-стью задоволення проектних цілей. Однак існують межі, до яких проектувальники і фахівці з реалізації можуть осмислювати, засвоювати і застосовувати вихідні матеріали для посібників зі стилю в рамках календарних планів, що мають зміст, по навчанню і розробці.
" Наслідок 1. Не складайте розпорядження заради розпоряджень.
" Наслідок 2. П'ятдесят видрукуваних сторінок - непогана верхня межа для початкового документа.
Корисне правило. Той факт, що посібник зі стилю розробляється в електронному виді, не означає, що обсяг розпоряджень може рости экспоненциально.
Практичність. Керівництво, що наказує, по стилі дає логічні інструкції для всіх елементів. Окремі розпорядження важливі, якщо їх розглядати изолированно, однак загальний підсумок повинний задовольняти вимогам.
Наочність. Оскільки керівництво, що наказує, по стилі концентрується на ПІ, у процесі їхньої розробки корисно вільне використання графічних прикладів. Ефективні також інтерактивні посібники зі стилю.
Відображення на продукт. Кожне розпорядження відображається на один чи кілька екранів і/чи типів взаємодій продукту. Результуюче відображення використовується при складанні план - графіків, що показують, коли буде досягнута відповідність продукту керівництву, що наказує, по стилі.
Відповідальність/підзвітність. На один фахівця покладаєте" відповідальність за технічні питання розробки керівництва, що наказує; по стилі і досягнення бажаних результатів, а іншої відповідає за питання, що стосуються управлінських аспектів розробки. Ці два фахівці звітують за постачання посібника зі стилю і бажані результати у відношенні продукту. Команда менеджерів і технічна бригада ставляться в популярність щодо відповідальності цих двох облич і ступеня прихильності керівництва організації досягненню результатів.
Корисні методи
Розробка сімейства продуктів з високими цілями у відношенні ПІ, практичності, інтеграції і погодженості являє собою дуже ризиковане підприємство. Існують деякі методи, що дозволяють знизити ризик у процесі розробки керівництва, що наказує, по стилі.
Орієнтоване на користувачів проектування. Аналогічно іншим компонентам постачання, посібник зі стилю - важлива потенційна сфера додатка методів проектування з орієнтацією на користувачів. Користувачами посібника зі стилю є члени проектної бригади. Доцільно але якомога раніше розробити прототип і оцінити компонент посібника зі стилю. Важливо також здійснити необхідна кількість ітерацій доти , поки будуть задоволені запити користувачів і вимоги.
"Портрет" сімейства продуктів "До". Необхідно одержати копії екранів задіяних продуктів (це екранні зображення продукту, що показують, у чому складаються проблеми). Потім конструюється колаж, що демонструє, як виглядає окремий продукт на робочому столі користувача разом з послідовністю кроків для загальних задач стосовно до сукупності продуктів. При можливості варто поцікавитися в користувачів, що вони думають з цього приводу.
Непогодженості. Складіть перелік відмінностей між продуктами. Класифікуйте найбільш істотні відмінності і привласніть їм пріоритети з крапки ренію кінцевих користувачів. Подбайте про те, щоб ідентифікувати відмінності у функціях і ПІ стосовно до всього сімейства продуктів. І знову, попросите користувачів допомогти у встановленні пріоритетів.
"Портрет" сімейства продуктів "Після". Ґрунтуючись на сущест-вующих стандартах, переробіть екранні зображення так, щоб одержати бажані ефекти (це екранні зображення, що усувають проблеми). Для Досягнення результату використовуйте багаторівневий підхід - розглянете рівень, пакета, об'єктний рівень, діалоговий рівень і рівень елемента керування. Побудуйте колаж, що демонструє, як виглядають обновлені продукти на робочому столі користувача разом з послідовностями кроків їхніх загальних задач. Поцікавтеся, що користувачі думають із приводу пропонованого рішення.
Чого це коштує. Складіть перелік змін, що приводять до желае-мому результату. Переконаєтеся в реализуемости рішення і його прийнятності з погляду вартості зусиль, необхідних для досягнення бажаного результату, попрацювавши для цього з бригадами розроблювачів. Заохочуйте персонал в узятих їм на себе зобов'язаннях.
Покази і розповіді. Ґрунтуючись на відгуках користувачів, звернетеся до керівництва з питанням, чи задовільні з його погляду отримані результати. Якщо немає - назад до креслярської дошки. Якщо необхідні витрати виявилися занадто великі, проведіть переговори з приводу виділення додаткових ресурсів, залучення фахівців, що володіють необхідною кваліфікацією, зміни план - графіка чи робіт зниження результативності. Цей процес продовжується доти , поки керівні і технічні кола не прийдуть з угоді про те, що може і що повиннео бути зроблено.
Розпорядження. Після того як угода досягнута, можна починати розробку керівництва, що наказує, по стилі. Керувати внесенням змін у продукт випливає за допомогою вимірних план - графіків і планів розробки. Для оцінки відповідності продукту посібнику зі стилю переконаєтеся в тім, що тестові прецеденти складені і розподілені між тестировщиками. Продовжуйте супровід екранних зображень продукту "До" і "Послу", выверяйте керівництво, що наказує, по стилі, проводите покази і розповідайте про зміни поки продукт розробляється.
Періодичні оцінки/звіти. Продовжуйте оцінювати результати і надавати звіти керівництву до завершення розробки продукту. По получе-нии відгуків користувачів уведіть необхідні зміни і постійно інформуйте про їх керівництво і розроблювачів.
Точка зору керівництва
Керівництво, що наказує, по стилі дає унікальну можливість менеджерам бригад розроблювачів створити практичні, погоджені й інтегровані продукти. Унаслідок вимірного характеру керівництва, що наказує, по стилі кожен продукт випробується на індивідуальну сумісність. Сукупність продуктів, що представляють інтерес, оцінюється з погляду загальної сумісності і досягнення бажаного результату.
Очевидно, що якщо сукупний бажаний результат не досить задовільний, додаткові розпорядження розробляються і реалізуються доти , поки цей результат не буде досягнутий. Якщо загальний бажаний ефект досягнуть, але окремий продукт відхиляється від результату, до продукту і/чи бригаді його розроблювачів застосовуються коригувальні дії.
Перед командою менеджерів коштують наступні основні проблеми.
1. Чітко сформулювати мети у відношенні ПІ, практичності, інтеграції і погодженості.
2. Зажадати від розроблювачів керівництва, що наказує, по стилі продемонструвати шляху досягнення поставлених цілей.
3. Призначити технічний і управлінський персонал, відповідальний за розробку керівництва, що наказує, по стилі, і відслідковувати реалізацію продукту.
4. Зажадати від розроблювачів продуктів показати сумісність, навіть якщо план-графік і ресурси випробують напруга в порівнянні зі звичайною розробкою продукту.
Продовження обговорення проекту:
принципи й інструкції
Унаслідок важливості проекту вище керівництво виявляє турботу про забезпечення проекту необхідним персоналом. У проект була введена ще одна бригада розроблювачів. Ви не знаєте нікого з цих фахівців особисто, однак бригада заслужила загальну репутацію сперечальників і самовпевнених людей. Маючи визначений досвід у швидкому постачанні декількох продуктів, додаткова бригада, здається, має мінімальні навички в орієнтованому на користувачів проектуванні і забезпеченні практичності, а також посередніми навичками в проектуванні і розробці ПІ. Цю думку розділяють багато фахівців, включаючи лідера проекту.
Однак друга бригада розроблювачів дуже пишається своєю роботою і почуває, що в неї досить навичок в області ПІ і практичності. Ця бригада вірить, що причина всіх дефектів її продуктів криється в позиції вищого керівництва й у невірному підході до маркетингу. Лідер проекту згадав, що, можливо, фахівці з другої бригади зможуть допомогти в таких областях, як керування печаткою, загальні діалоги, загальні елементи керування і загальні функції. Ви помітили, що вони можуть дуже швидко "видати" проект вікон і сторінок за допомогою деяких цікавих задумів, однак це не знімає істотних проблем із загальним проектуванням. Крім того, їхні продукти не дуже добре поводяться в експлуатації, а відгуки користувачів про їхню роботу суперечливі.
Окремі бригади в лабораторії працюють над іншими додатками, що могли б розширити довідник додатків в аспектах функціональних можливостей і конкурентноздатності (наприклад, експертні системи й агенти, електронна пошта, телефонія, відео, факсимільний зв'язок і інше допоміжне ПО). Ви бачили ці додатки і знаєте, що вони мають коштовні можливості, однак дуже відрізняються по враженню і відчуттю. Деякі з цих бригад можна було б переключити на реалізацію компонентів проекту.
Хоча ці додатки не задіяні безпосередньо в задачах планування конференцій, вище керівництво виразило бажання, щоб уся сукупність розроблених силами лабораторії програмних засобів сприймався як пакет додатків, що у відношенні ПІ, практичності, погодженості й інтеграції міг би суперничати з лідируючими в галузі програмними пакетами. Лідер проекту згадав, що ви повинні відзвітуватися за те, як справитися з цією ситуацією.
Вищі керівники попросили лідера проекту провести інформаційну нараду по питанню про те, як цієї мети можна досягти силами проектної бригади. Один з вищих керівників виразив поінформованість у відношенні труднощів, що коштують на шляху досягнення сумісності декількох додатків на рівні пакета. У свій час він був менеджером проекту, зв'язаним з розробкою документа по стандартизації ПІ, що так і не досяг поставленому цілей, як наприклад, у відношенні ПІ і практичності. На останній нараді з вищим керівництвом він помітив, що бажав би впритул займатися цим аспектом проекту. Ви чули, як він хотів довідатися, чи є твердження "бачити те ж, що бачать клієнти" проектним принципом, чи інструкцією властивістю проекту.
Лідер проекту зобов'язався провести нараду завтра в 7 ч 30 хв ранки. У вашому розпорядженні біля двох годин для підготовки брифінгу по проекті. Вам належить розглянути такі питання.
" Принципи, стандарти, інструкції і посібники зі стилю.
" Яким образом задовольнити вимоги по ПІ і погодженості на рівні пакета.
" Яким образом домогтися злагодженої роботи різних бригад.
" Графік^-графік-план-графік дозволу проблем, зв'язаних з посібником зі стилю іншими складностями.
Лідер проекту порадив вам показати вищому керівництву, що необхідно для досягнення успіху, використовувавши для цього три наочних приклади елементів посібника зі стилю. Зокрема , ви повинні продемонструвати рівень погодженості, досягнутий у рамках підтримуваних платформ, а саме GUІ-, WUІ- ,HUі-стили. Приклади повинні бути достатніми для демонстрації результатів "Д и "Після" переробки додатків з використанням існуючих продуктів.
Для брифінгу не потрібно повний набір принципів, стандартів і інструкцій. Однак яке - що виразно необхідно зробити в межах двох тижнів для бригад розроблювачів, що беруть участь у проекті. Будь-якого розробленого посібника зі стилю повинне бути досить для підтримки інших бригад, що беруть участь у цьому й іншому чи проектах входять до складу інших бригад, що працюють поза основним офісом компанії.
Подбайте про те, щоб продовжити ваше дослідження через Іnternet. Переконаєтеся, що у вас є доступ до основних загальнодоступних стандартів і стандартів ІSQ. Використовуйте інші виявлені вами директивні документи як чи посилання для доповнення переліку задач, розв'язуваних проектною бригадою.
Питання?
Посилання
Grudіn J. The Case Agaіnst User Іnterface Consіstency, Communіcatіons of the ACM, Oct.
1989.
Human Іnterface Guіdelіnes: The Apple Desktop Іnterface, Apple Computer, Іnc. Addіson-Wesley:Cupertіno, CA, 1995.
Java Look and Feel Desіgn Guіdelіnes, Sun Mіcrosystems. Addіson-Wesley: New York, 1999. ASF/Motіf Style Guіde, Revіsіon 1.0, Open Software Foundatіon. Prentіce-Hall: Englewood
Clіffs, NJ, 1990.
Torres RJ. A User-Centered Desіgn Based Approach to Style Guіdes, Eds. J. Vanderdonckt and
C. Farenc, Tools for Workіng wіth Guіdelіnes, Sprіnger-Verlag, 2000.
Torres RJ. et al. Proofreadіng GUІ-Based Applіcatіons, Common Ground, Ed.JoAnn Hackos,
UPA Newsletter, V8.3, July 1998.
Vanderdonckt J. Development Mіlestones Towards a Tool for Workіng wіth Guіdelіnes,
Іnteractіng wіth Computers, V12.2, Sep. 1999.
The Wіndows Іnterface Guіdelіnes for Software Desіgn: An Applіcatіon Desіgn Guіde,
MіcrosoftCorp. Mіcrosoft Press: Redmond, WA, 1995.