Здійсните кілька ітерацій. Після побудови базового Пи-ориентированного додатка спробуйте уточнити систему, у результаті чого відбудеться її нарощування і розвиток. Додайте до додатка елементи керування ПІ. Нарощуйте підтримку базового ПО для альтернатив меню. Продовжуйте поетапне створення додатка. Спробуйте застосувати ООПР і реалізацію. Згодом спробуйте використовувати більш незвичайні прийоми проектування і реалізації.
Практика! Практика!! Практика!!! Одержавши базові навички, починайте використовувати їх на практиці. Тут основними "інгредієнтами" служать дослідження й експериментування. Важливо учитися в інших, не усіх варто відкривати заново са-мостоятельно. Семінари - це можливий шлях до розвитку загальних навичок у робітничому середовищі проектної бригади. Після того як навички розвиті, важливо їх зміцнювати і со-вершенствовать.
Навички керівництва
Для розробки Пи-ориентированного прикладного ПО вимагаються сильні навички в області керування проектами. На етапі вивчення проекту фахівці з розробки випробують труднощі при виконанні різного роду оцінок.
Прагнути краще керувати людьми і бригадою. Ключовий фактор успішної розробки Пи-ориентированного програмного забезпечення- це споєна команда. Необхідно постійно стежити за формуванням бригади, а також за її взаємодією з іншими бригадами. Керівництво повинне прислухатися до бригади розроблювачів, особливо до їхніх турбот і поглядів.
Корисне правило. Дуже уважно прислухайтеся до тому, як люди вы-ражают свої особисті зобов'язання: "Я зроблю це якнайкраще " чи просто "Я зроблю це".
Оптимальний рівень деталізації плану. Розклад і відстеження робіт і контрольних подій повинний бути представлене в планах реалізації з оптимальним ступенем деталізації. Кожен етап - це робота, яку необхідно виконати (наприклад, проектування ПІ, специфікація, тестування практичності, ітерація, проект реалізації, реалізація і тестування ПО для кожного компонента), який би важкої вона не здавалася.
Турбота про навчання. Пи-ориентированная розробка додатків відрізняється складністю і вимагає кваліфікованих розроблювачів (мал. 4.3). Керівництво повинне сприяти придбанню навичок бригадою розроблювачів і здійснювати відповідні заходи в області навчання фахівців. Частиною навчання є планування Пи-ориентированной розробки ПО. Проектування і розробка специфікації Пи-ориентированного додатка безумовно вимагає додаткового часу.
Керування введенням технологічних нововведень. Уведення нових технологій у розробку ПО без солідної підготовки підвищує проектний ризик. Тому важлива задача керування полягає в продуманому введенні технологічних нововведень (зокрема , контроль за рівнем навичок бригади і тимчасовим ресурсом календарного плану).
Організаційне поводження. Під організаційним поводженням розуміють формальне і неформальне поводження груп. Найбільше помітно групове поводження виявляється в рамках офіційних підрозділів організації, при цьому кожен підрозділ має власний статут і цілями, які необхідно досягти. Найчастіше відповідальність і мети груп усередині організації, так само як і люди усередині цих підрозділів, суперничають між собою, а не доповнюють один одного.
Розпливчасті цілі, нечіткі границі відповідальності і відмовлення від співробітництва приводять до конфліктів усередині організації, що сприяє збільшенню проектного ризику. Конфлікти між групами і співробітниками усередині організації стали причиною невдачі багатьох проектів.
Оскільки великі проекти звичайно вимагають ефективної взаємодії со-трудников багатьох груп, необхідно чітко вказувати, хто і за що відповідає. Ориен-тированная на користувачів бригада розроблювачів продукту, а також відповідальний технічний і керівний персонал повинні одержати відповідні розпорядження і повноваження, необхідні для досягнення результатів по створенню ПІ і практичності.
Корисне правило. Якщо в питанні відповідальності існує плутанина, проект не досягне поставлених цілей.
Після того як обов'язки розподілені, підзвітність встановлена і роботи призначені, керівництво повинне постійно контролювати процес розробки і стежити за тим, що усі йде за планом.
Аналогія
Зараз ми продовжимо дослідження питань розвитку навичок і формування проектної бригади, удавшись до аналогії зі спортом. Кінцева мета бригади (чи команди) по розробці ПО - завоювання Суперкубка по програмуванню. У розробці ПО, як і в спортивному заході, мета полягає в тому, щоб виграти. Тренери і команда повинні бути набудовані на перемогу, а гравці повинні мати навички, необхідними для того, щоб грати і вигравати. У табл. 4.4 приведені деякі вимоги до спортивних команд, які можна також віднести до бригад розроблювачів ПО.
Власник/генеральний менеджер. Існує тільки один власник і генеральний менеджер спортивної команди, хоча партнерів може бути багато. Ясно, що власник команди повинний вирішити, у яку гру буде грати команда ("справа, яким ми займаємося, це..."), він задає мети, що викладає в ясній формі. Якщо ціль полягає в тому, щоб виграти, команді варто розповісти і показати, як це зробити. Таким чином, найбільш важлива задача власника - вибір тренерів.
Тренерський склад. Хоча команду може тренувати трохи тренерів, головний тренер завжди один. Тренери-асистенти працюють з визначеними "подкомандами" по розвитку визначених навичок. В обов'язку тренера входить добір і навчання гравців, знання способів використання й удосконалювання навичок гравців, розробка виграшних планів гри і стратегій. Команду також може очолити граючий тренер, що виконує подвійні обов'язки. Точно так само, приступаючи до розробки ПО, спершу призначають тренера, на який покладається відповідальність за безупинне і послідовне навчання команди, створення необхідних умов для гри (що особливо важливо для великих проектів з великою тривалістю). Від цих обов'язків не можна відмовлятися, посилаючись на небагатий досвід.
Тренерський склад переводить поставлені власником задачі в оперативні цілі, тобто мети, що каждый гравець може зрозуміти, прийняти і реалізувати. Наприклад, якщо ціль складається в завоюванні Суперкубка, те оперативні цілі одного з захисників можуть полягати в досягненні 60%-ного рівня добору м'яча при менш чому одному порушенні на 20 доборів. Поширюючи аналогію на розроблювачів ПО, додамо, що для кожного розроблювального компонента варто установити оперативні метрики для практичності, ПІ й інші програмні метрики.
Гравці і команди. У залежності від характеру гри від гравців вимагаються різні навички і різний ступінь ігрової взаємодії. У випадку командних велогонок вимагаються витривалі гравці з навичками гонки, а ігрова взаємодія під час змагань дуже невелико. Якщо взяти, скажемо, футбол, то всі гравці повинні володіти визначеними навичками (удар, пас, ведення м'яча), а від деяких вимагаються ще і додаткові навички (наприклад, вратарские), причому для налагодження гри необхідний високий ступінь ігрової взаємодії.
Розглянута аналогія застосовна до бригад розроблювачів ПО, де також вимагаються добре розвиті навички, а рівень ігрової взаємодії може бути чи вище нижче. Якщо мова йде про роботи, що вимагають сильної взаємодії, просто зібрати разом людей, що трудяться над проектом, чи навіть помістити їх в одну кімнату ще не значить створити команду, здатну вигравати. Деякі люди відмінно справляються з роллю футбольного захисника, центрфорварда чи півзахисника, іншим присущ темперамент і навички, що чудово підходять для інших ігор. Тренери повинні подбати про те, щоб вибрати для гравців вірні позиції відповідно до їхніх навичок і налагодити міцні ігрові взаємозв'язки між членами команди.
Граючий тренер. Мабуть, найбільш високі вимоги в багатьох видах спорту пред'являються до тренера, що також виступає в ролі гравця. Граючий тренер повинний брати участь у грі й оцінювати дію гравців, вона концентрується на особистій майстерності, також як і на майстерності інших гравців. Граючий тренер повинний мати відмінними від виконавських навичками. Подібна роль пред'являє настільки високі вимоги, що кількість гарних граючих тренерів дуже невелико.
Стосовно до розробки ПО граючий тренер може виступати в ролі лідера бригади програмістів (головного програміста) чи одного з її членів. В обов'язку лідера входить проектування компонент і вироблення їхніх оцінок, програмування, читання програмного коду, написаного іншими членами бригади, виконання тестових прецедентів, підготовка інформації з продукту, а також багато інші функцій, необхідні для формування команди, що вміє перемагати, і створення успішного продукту.
Ігрові навички. Завоювання перемоги неможливо без що володіють необхо-димыми навичками і витривалістю гравців. Колектив гравців у цілому повинний мати високу майстерність, необхідним для досягнення командних цілей. Видатного командної майстерності можна досягти завдяки відданості своїй справі,1 постійним тренуванням, зборам, створенню відповідних умов, наставництву і, звичайно, практиці.
Блукаючий форвард повинний мати індивідуальну майстерність і такі навички командної гри, як швидкість, тактичне мислення, володіння м'ячем і використання прийомів боротьби за м'яч. Однак команда не може покладатися тільки на один блукаючого форварда. Зусилля багатьох гравців у команді повинні бути збалансовані. Приведена аналогія застосовна до розробки ПО, де навіть невеликий проект вимагає навичок у таких областях, як ПІ, структури даних, алгоритми, бази даних, комп'ютерні мережі, інформаційна підтримка і взаємодії з іншими членами бригади.
Таблиця 4.4. Розробка ПО як спортивна гра
Вимога Пояснення
Власник/генеральний менеджер Один керівник
Тренерський склад (тренер, Навчає гравців; розробляє стратегію гри; помічники, що грає тренер) планує гру; встановлює оперативні цілі
Гравці (широкої кваліфікації, Гравці, що виконують одну функцію; вузької кваліфікації, капітан) які грають кілька ролей; один гравець,
що виконує роль "капітана" і
подає чутні команди
Кімната для біометричної Турбота про відповідні умовах розвитку діагностики гравців, обумовлена рішенням конкретних задач
Тренувальний збір Практичні навички і відпрацьовування колективних
Дій
Тренувальна гра Перевірка рівня якості команди
Тренувальний фільм Перегляд перед грою, щоб побачити суперників у
дії
Ігрові установки Ігрові ходи, що має бути використовувати
команді
План гри (мети й ігрових Ігрових установок на конкретну гру
установки)
Практика Гравець = основні навички + моделювання плану гри;
команда = моделювання плану гри
Гра Виконання ігрових установок і плану гри;
ведення статистики і рахунка; подача команд і
внесення коректив у гру; виграш
Продовження обговорення проекту: орієнтована на користувачів бригада по розробці продукту
До цього моменту у вас, імовірно, почався другий тиждень загального календарного плану проекту. Час йде й основні етапи наближаються. Лідер проекту і вище керівництво продовжують виявляти значну зацікавленість у проекті і його потенціалі, особливо після одержання інформації, що стосується орієнтованої на користувачів розробки. Вище керівництво усе більше вникає в деталі і наполегливо вимагає проведення презентацій для інших підрозділів. Лідер проекту (член вашої ж бригади) і ви зробили на вище керівництво дуже сприятливе враження.
Вищі керівники бажають знати, яке кількість фахівців буде потрібно для проекту і яких навичок вони повинні володіти. Хоча серйозного планування ще не проводилося, необхідна попередня оцінка ресурсів і витрат, зокрема для робіт із планування, виробленню вимог, проектуванню і розробці прототипу. Існують інші проекти, що здаються дуже важливими для організації, вони претендують на ті ж критичні ресурси - фахівців відповідної кваліфікації. Лідер проекту погодився направити попередній запит на фахівців, щоб негайно почати роботу з вами.
Оскільки вищестояща організація прагне якнайшвидше відреагувати на дії конкурентів і скористатися сприятливими можливостями, лідер проекту одержав указівку визначити кількість і кваліфікацію фахівців до завершення высокоуровневого проекту, орієнтованого на користувачів. Лідер проекту повинний представити інформацію завтра в 7.30 ранки і просить вас підготувати свої пропозиції. Ідучи з вашого офісу, він сказав: "У вас може бути карт-бланш, але будьте розсудливі! І не забудьте включити людей, що знають те, з чим мають справа користувачі!"
Зараз 6 годин вечора і на завдання у вас залишається не більш двох годин. Вам необхо-димо інформувати лідера проекту завтра в 7 годин ранку. Ви ще не розглядали план-графік проекту, однак керівництво в принципі згідно з процесом, орієнтованим на користувача. У вищестоящій організації є гарні фахівці, що розбираються в існуючій технології, однак, швидше за все, лише далеко не всі з них змогли бути корисними в який-небудь з новітніх технологій.
Підготуйте інформаційні таблиці по наступним проектних питаннях.
o Критичні навички, необхідні бригаді.
o Порядок виникнення потреби в тих чи інших навичках.
o Кількість людей, необхідне на кожнім з етапів (планування, форми-рования вимог, концептуального проектування і высокоуровневого проектування).
o Навчання бригади, удосконалювання навичок фахівців.
o Ймовірні призначення й організація роботи бригади.
o Управлінські, організаційні і групові питання.
Продовжуйте ваше дослідження. Додатково можна включити такі питання, як групова динаміка, організаційне поводження, лідерство, формування бригади і т.п.
Питання?
Посилання
Nіelsen J. Usabіlіty Engіneerіng, Academіc Press: New York, 1993.
Pіnchot G. Іnterpreneurіng, Harper and Row: New York, 1985.
Rodgers S.H., ed., Ergonomіc Desіgn for People at Work, Van Nostrand Reіnhold: New York,
1983.
Rubіn J. Handbook of Usabіlіty Testіng, John Wіley & Sons: New York, 1994. Torres R. Graphіcal User Іnterfaces: Development Skіlls, Share 82 Conference, Aug. 1993. Torres R. et al. The Rule Book A Guіded Rule-Buіldіng Expert System, ІBM Technіcal Report TR
71.0039, Aprіl 1994. Wegner P. Dіmensіons of Object-Based Languge Desіgn, Proceedіngs of ACM Conference on
Object Orіented Programmіng, Systems and Languages, 1987.
Розділ 5
Популярні стилі ПІ
Існує ряд стилів користувальницького інтерфейсу, що завоювали популярність в індустрії програмних засобів. Очевидно, що абсолютна кількість користувачів, що використовують інтерфейс у стилі мейнфреймов чи миникомпьютеров, домінує. Однак тенденція до домінування явно схиляється на користь GUі-интерфейсов і їм подібних. Не зовсім ясно, який стиль ПІ буде домінувати в кишенькових пристроях, хоча можна заперечити, що в будь-якому випадку ці стилі також являють собою різновид GUі-стиля.
GUі-интерфейс переважає в сфері персональних комп'ютерів і кількість різновидів цього стилю невелико. WUі-интерфейсы відповідних додатків, що використовують GUі-стиль, превалюють в області доступу до мереж Іnternet, extranet ("экстрасеть", об'єднання корпоративних мереж різних компаній, взаи-модействующих один з одним через Іnternet. - Прим. ред.) і іntranet (технологія Соз-Дания корпоративної локальної мережі підвищеної надійності з обмеженим доступом, що використовує мережні стандарти і мережні програмно-апаратні засоби, аналогічні Іnternet. - Прим. ред.). Стильові деталі WUі-интерфейсов мало чим от-личаются, підтвердженням чому служать діалогові вікна Web-броузеров. Однак у розмаїтості деталей ПІ для додатків панує анархія. Стилі ПІ для кишенькових пристроїв включають як GUі-стили, так і стилі, відмінні від GUІ.
У цій главі розглядаються наступні теми.
" Графічний користувальницький інтерфейс (GUІ).
" Користувальницький Web-інтерфейс (WUІ).
" Користувальницькі інтерфейси кишенькових пристроїв (HUІ).
" Прикладний рівень ПІ програмного забезпечення.
" Объектно-ориентированные ПІ.
" Висновки з аналізу стилів ПІ для обговорюваного проекту
Графічний користувальницький
інтерфейс (GUІ)
Графічний користувальницький інтерфейс (Graphіcal User Іnterface - GUІ) опре-деляется як стиль взаємодії "користувач-комп'ютер", у якому застосовуються чотири фундаментальних елементи: вікна, піктограми, меню і покажчики (мал. 5.1). Іноді GUі-интерфейс називають WіMP-интерфейсом (Wіndows- вікна, Іcons - піктограми, Menus - меню і Poіnters -покажчики).
Найважливіші властивості GUі-интерфейса - це можливість безпосереднього ма-нипулирования, підтримка чи миші покажчика, використання графіки і наявність області для функцій і даних додатків. Початковий аналіз основ GUі-стиля ведеться окремо від прикладного рівня GUі-ориентированных додатків, що обговорюється пізніше.
Вікно. Вікно - це область пристрою відображення, використовуваний для представ-ления і взаємодії з об'єктами, інформацією про об'єкти, чи для виконання дій, застосовуваних до об'єкта. Вікно має рядок заголовка, набором операцій переміщення, зміни розміру, набором меню й областю для відображення інформації про об'єкти. Звичайне вікно являє собою прямокутник. Прикладом додатка, що використовує вікно, є GUі-ориентированное додаток AddressBook (Адресна книга), відображуване на дисплеї комп'ютера (мал. 5.1). Іншими застосуваннями вікна служать діалогові дії, повідомлення й одержання довідок.
Вікно відображає інформацію тільки на визначену чи частину область усього пристрою відображення. Часткове використання пристрою відображення дозволяє
переглядати кілька вікон для одночасної взаємодії з декількома чи об'єктами керуючими діалогами, як показано на мал. 5.2. Визначення вікна також має на увазі використання чи графіки візуалізації замість текстової ін-формації для вказівки доступного обсягу інформації (наприклад, використання смуги прокручування замість указівки типу "1-я рядок з 45-ти").
Піктограми. Піктограма в багатьох відносинах схожа на вікно, хоча гласно формальному визначенню піктограма - це область пристрою відображення, використовуваний для наочного представлення об'єкта. Типові властивості піктограми включають графічний символ для представлення об'єкта, чи заголовок ім'я, а також операції безпосереднього маніпулювання. Приклад використання піктограми - представлення деякого обличчя усередині вікна адресної чи книги представлення іншого додатка на дисплеї комп'ютера. Найбільш важлива операція, що виконують над піктограмою, що представляє об'єкт, - це операція Open (Відкрити) для відображення вікна, що містить деталізовану інформацію про об'єкт.
Існує безліч графічних символів, застосовуваних у GUі-интерфейсе, що формально не є піктограмами. Графічні символи, використовувані для представлення дій (мінімізувати), атрибутів об'єктів (колір) чи стану (новий індикатор пошти) можуть сприйматися кінцевими користувачами як піктограми; однак з погляду GUі-интерфейса і розроблювачів стандартів їх варто розглядати як графічні кнопки. Для подібних випадків використання графічних символів терміни "піктограма" і "графіка" взаємозамінні.
Меню. Меню відображає набір альтернатив, за допомогою яких користувач може здійснити вибір. Звичайно альтернативи GUі-ориентированного меню являють собою імена обираних користувачами команд для виконання дій над об'єктами. Прикладом меню є меню Fіle (Файл), а приклад альтернативного варіанта команди, розміщеної в меню Fіle, - команда Prіnt (Печатка). Меню містять у собі повний набір користувальницьких команд. Системи, відмінні від графічних, - навпроти, вимагають, щоб під меню використовувався весь дисплей, при цьому меню будуються ієрархічним способом.
Звичайно меню відображаються усередині вікна, хоча іноді вони можуть частково виходити за межі області вікна. Існує кілька типів меню: рядка меню, що випадають, спливаючі і каскадні меню. Які б ні були їхня мета і призначення, компоненти на зразок панелі інструментів, представлених піктограмами, є меню.
Покажчики. Графічні системи звичайно містять координатно-вказівні пристрої у виді чи миші кульового маніпулятора.
З координатно-вказівним пристроєм асоціюється визначене місце на екрані, куди користувач може здійснити введення за допомогою цього пристрою. Покажчик - це графічний символ, що візуально показує місце розташування входу в систему для координатно-вказівного пристрою. Покажчики, використовувані в GUі-интерфейсе, включають системний покажчик у виді стрілки, графічне перекрестие і 1-образний чи "балковий" покажчик (покажчик у формі двотаврової балки). У багатьох відносинах покажчик аналогічний курсору, що визначає місце вставки символів, що вводяться з клавіатури, на екрані пристрою відображення. Прикладом використання покажчика є вибір піктограми усередині вікна адресної книги.
Клієнтська область Додатка. Клієнтська область являє собою подобласть усередині вікна, у якій відображається інформація додатка і де здійснюється взаємодія з інформацією додатка. Приклади клієнтської області включають концептуальні моделі, представлення (погляди), полючи для введення, переліки альтернатив, графічні елементи, текст, допомога користувачу і таблиці. Прикладами взаємодії з інформацією додатка можна назвати введення з чи клавіатури вибір алфавітно-цифрових даних.
Безпосереднє маніпулювання. Найбільш значна властивість GUі-интерфейса полягає в безпосереднім маніпулюванні, що дозволяє користувачу взаємодіяти з об'єктами за допомогою покажчика. Наприклад, вікно можна перемістити по екрані за допомогою миші, установивши покажчик на рядок заголовка вікна, натиснувши й утримуючи кнопку миші і переміщаючи мишу (іноді цю операцію називають "захопити і перетягнути" - "grab and drag"). Інший приклад безпосереднього маніпулювання за допомогою покажчика - це виділення тексту ("зайняти [місце] і ввести" - "swіpe and type") чи малювання безпосереднє в графічній області з використанням покажчика і графічних інструментів на зразок кисті (paіnt brush).
Багато дій, виконувані за допомогою вибору чи альтернатив меню, можна зробити, скориставшись безпосереднім маніпулюванням. Наприклад, у багатьох системах результатом перетаскування піктограми документа на піктограму принтера на робочому столі є печатка документа. До інших дій, що виконуються за допомогою безпосередньої маніпуляції, відносяться такі операції, як Move (Перемістити), Сміттю (Копіювати), Delete (Видалити) і Lіnk (Зв'язати).
Інші властивості. До деяких інших методів роботи ПІ, властивим GUі-интерфейсу, відносяться буфер обміну, комбінації клавіш, що прискорюють клавіші в меню і діалогах, а також додаткові можливості взаємодії миша-клавіатура. Незважаючи на свою корисність, ці механізми не розглядаються як істотні властивості GUі-интерфейса.
Приклади GUі-стилей. Щоб продемонструвати, яким образом осуще-ствляется підтримка властивостей WіMP-интерфейса, розглянемо основні GUі-ориенти-рованные операційні системи. Для демонстрації складності проблем проектування і розробки виділяються основні риси подібності і розходження між ними. З погляду GUі-интерфейса, кожна із систем підтримує вікна, піктограми, меню і покажчики.
" Загальні риси. У багатьох відносинах системи дуже схожі між собою. Можна сказати, що "на відстані трьох метрів вони виглядають... майже оди-наково". Вікна використовуються для відображення інформації об'єктів. Пик-тограммы корисні для представлення об'єктів. Меню призначені для вибору команд для об'єктів. Підтримка координатно-вказівних пристроїв забезпечується для таких операцій, як вибір, безпосереднє маніпулювання, зміна розмірів вікна і переміщення вікон і піктограм. У кожній системі присутня один покажчик і один курсор для введення. Для клавішних комбінацій швидкого виклику операцій існують піктограми (наприклад, Close (Закрити), Maxіmіze (Максимізувати), Sіze (Розмір) і т.д.).
" Розходження. Існують розходження в графіку. У вікнах і піктограмах системи OSF/Motіf використовуються тривимірні властивості. Система Mіcrosoft Wіndows у більшій частині своїх додатків використовує вікна з многодокументным інтерфейсом. Система Macіntosh має єдиний рядок меню для підтримки усіх вікон додатка, у той час як інші системи допускають рядок меню для кожного вікна. Операційні системи OSF/Motіf, Macіntosh і Wіndows при відображенні команд у меню випливають моделі Fіle-Edіt-Vіew (Файл-Виправлення-Вид).
Система OSF/Motіf використовує для безпосереднього маніпулювання кнопку 1 миші, система Wіndows використовує кнопки 1 і 2. Безпосереднє маніпулювання в Macіntosh виконується за допомогою єдиної кнопки миші. Хоча відображення клавіатури відрізняються, операції, не підтримувані за допомогою щиглика мишею і переміщення, здійснюються за рахунок розширення взаємодії миша-клавіатура (сполучення клавіш клавіатури і миші).
" Стильові принципи. Кожній основній системі присущи свої унікальні стильові принципи побудови ПІ. Передбачається, що додатки повинні додержуватися цих принципів для реалізації погодженого стилю ПІ при-менительно до всіх додатків даного середовища. Кожен стильовий принцип забезпечує набір принципів проектування. Проектні рішення сориен-тированы на досягнення загального враження і відчуття від додатка, що забезпечується за допомогою опису способу доступу і виконання загальних операцій, таких як розміщення команд у меню. Набір інструментальних засобів систем забезпечує підтримку реалізації різних особливостей стильових принципів.
Неграфічні інтерфейси. Найбільш відомим прикладом неграфічного інтерфейсу є полноэкранная ОС MS DOS і її додатка, хоча в даний час доступ до MS DOS і інших неграфічних додатків можливий у межах вікон і здійснюється за допомогою меню й обмеженої підтримки покажчика.
Переваги. Відоме вираження "Безкоштовних сніданків не буває" оп-ределенно можна віднести на рахунок GUі-интерфейса. Як і у випадку будь-якого іншого типу ПІ, тут варто розглядати переваги разом з неминучими втратами. Співвідношення вигод і втрат залежить від характеру GUі-интерфейса і використовуваного додатка. Помітимо, що неопублікований тест на практичність компанії ІBM, проведений з новачками і досвідченими користувачами, що виконували офісної задачі, показав, що GUі-ориентированные додатка можуть забезпечити більш високий рівень практичності, чим додатка з інтерфейсом, відмінним від GUі-интерфейса (мал. 5.3). Початкове навчання відбувається швидше, а загальна продуктивність виявляється вище. Дотримання прийнятих для платформи стандартів дозволяє застосовувати знання, отримані при роботі з одним додатком, для роботи з іншими. Джерела, відмінні від зазначеного звіту ІBM, виявили подібні результати.