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

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

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

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


Стандартні елементи інтерфейсу

Постарайтеся не використовувати в своїй програмі нестандартні елементи інтерфейсу – наприклад, командні кнопки не тільки з текстом, але і з малюнком, або комбіновані списки зі складною рамкою, які в достатку можна знайти в oilline-колекціях VCL і ActiveX-компонентів. Хоча б тому, що саме так чинять професійні розробники інтерфейсів. “Чим стандартнішими компоненти, тим краще і професійніше вид “- не раз доводилося чути від досвідчених авторів. Посудіть самі: ви коли-небудь бачили в програмі від Microsoft, Corel та Adobe елемент управління, зроблений початківцям програмістом, викладений в Інтернеті і супроводжувалися припискою у файлі readme.txt: “Це мій перший досвід у створенні компонента, тому не штовхайте занадто сильно!”

Зауваження

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

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


Невелика палітра інструментів

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


Однакову відстань між елементами управління

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


TabOrder. “Правильний” порядок

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

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


Вибір шрифтів

Тут все просто – автор не повинен вибирати ніяких шрифтів. Залиште їх такими, якими вони визначені за замовчуванням, а краще – вкажіть у властивості Шрифт (Font) відповідні глобальні змінні Windows: WindowText, MenuText і т. д. У цьому випадку зміна користувачем стандартних шрифтів Windows по своєму смаку за допомогою Панелі управління відіб’ється і на зовнішньому вигляді вашої програми. Таким чином, користувач, запустивши ваш продукт, виявиться в знайомому йому оточенні.

Ще одне питання – переважне накреслення шрифтів. Сучасні системи програмування допускають вказівка ​​для властивості Шрифт, крім звичайного (normal) накреслення ще й напівжирне (bold), курсивне (Italic) і підкреслене (underlined), а також їх поєднання. Багато авторів, зрадівши наданими можливостями, охоче ними користуються, застосовуючи різні комбінації шрифтових накресленні. На самому ж в інтерфейсах Windows-програм прийнято використовувати лише два накреслення: нормальне і напівжирне (останнє – для виділення якої-небудь важливої ​​інформації, заголовків і т. п.). Застосування курсиву або підкреслення, яке, до того ж, користувач помилково може прийняти за гіперпосилання – це поганий тон.


Масштабування шрифтів

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


Вибір квітів

Тут ситуація в точності така ж, як і зі шрифтами: ніякого вибору. При проектуванні інтерфейсу потрібно взагалі забути про властивість Колір (Color) елементів управління. Залиште кольору стандартними, і нехай ваша програма виглядає так, як цього хоче її користувач, а не автор (хороша ідея – передбачити в програмі можливість зміни колірної гами різних частин інтерфейсу: багато користувачів люблять налаштовувати кольору “під себе”, причому так, що іншій людині таке “поєднання” кольорів може здатися зовсім неоковирним). І в цьому, потрібно сказати, авторам програм пощастило: вони позбавлені однією з найголовніших турбот дизайнерів і художників, які ж кольору вибрати для свого нового творіння.

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


Альтернативне управління

Ваша програма повинна однаково добре управлятися як за допомогою миші, так і клавіатури. Не повинно бути функцій, які можна виконати тільки мишею (за винятком традиційно “мишачих” операцій – наприклад, малювання в графічних редакторах). Найбільш популярні функції слід забезпечити “гарячими клавішами” для швидкого доступу. При виборі комбінацій клавіш не забувайте про звички і навичках користувачів: зупиніться на тих комбінаціях, які зазвичай використовуються в програмах такого роду. Наприклад, якщо ви розробляєте файловий менеджер в стилі Провідника Windows, то краще створювати комбінації, традиційні для Windows-програм (табл. 1), якщо ж ви орієнтуєтеся на Norton Commander, то, наприклад, для функції оновлення списку файлів привласнити “гарячу клавішу” + , а не Windows. Але, напевно, в такій ситуації ідеальний, але, природно, не найлегший варіант – передбачити для функцій програми дві “схеми” гарячих клавіш, щоб задовольнити потреби прихильників обох стилів роботи з файлами.


Операція

Таблиця 5.1. Стандартні комбінації клавіш в Windows Комбінація клавіш

Нове (вікно, лист, файл і т. п.) +

Відкрити +

Зберегти +

Друк + <Р>

Скасувати +

Повторити +

Вирізати + , +

Копіювати + , +

Вставити (з буфера обміну) + , +

Вставити (новий об’єкт)

Видалити

Виділити всі +

Знайти +

Знайти далі

Замінити +

Оновити

Довідка


Цеглинки інтерфейсу

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

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

· Відповідності елемента управління виконуваної ним задачі;

· Від послідовності правил, за якими функціонує елемент управління.

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


Заголовок вікна (форми)

Хоча в палітрах доступних програмісту компонентів сучасних систем створення додатків відсутній такий елемент управління, як заголовок вікна, він визначається властивістю Заголовок (Caption) об’єкта Форма (Form), йому потрібно приділяти не меншу увагу, ніж кнопкам, списками і тому подібним елементам.

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

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



  • якщо назва документа поміщається в заголовку вікна першим, то воно завжди видимо на кнопці, що представляє відповідну програму на панелі завдань Windows, і дізнатися, який в даний момент відкрито документ, не представляє ніяких труднощів. А от якщо в заголовку вікна спочатку йде назва програми, то, отже, воно і видно на панелі задач, і для того, щоб з’ясувати, з яким саме документом працює дане вікно, потрібно переключитися в нього (або навести курсор на кнопку панелі задач і почекати секунду, поки не з’явиться спливаюча підказка);

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

У нових версіях програмних продуктів поступово відбувається відмова від традиційної схеми побудови заголовків окоп. Наприклад, Microsoft вже перевела на новий формат заголовка вікна свої продукти – від простого “Блокнота” зі складу Windows до програм пакета Office 2000.


Командні кнопки

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

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

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

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

Особисто мені доводилося не раз стикатися з описаною вище проблемою. Одного разу я навіть не зміг зареєструвати законно придбану копію shareware-програми; кнопка Зареєструвати весь час залишалася відключеною, незважаючи на введення в текстове вікно реєстраційного коду. І інформацію про те, що саме я роблю неправильно, я зміг отримати, тільки написавши листа автору програми … Тому при проектуванні інтерфейсу власної програми, Actual Startup, я вирішив не піддаватися спокусі зробити діалогові вікна занадто “розумними”. Кнопка ОК у вікні створення нового “сервісу” стає доступною навіть при введенні неправильних даних, зате після її натискання з’являється вікно з повідомленням про помилку і інформацією про те, як її виправити.


Текстові підпису

Здавалося б, які “підводні камені” можуть бути при використанні одного з найпростіших елементів управління – Label? По-перше, не забудьте про масштабування шрифтів: щоб текстова підпис автоматично підлаштовувати свої розміри згідно міститься в ній тексту, перевірте, що властивість AutoSize має значення True. По-друге, також надайте значення True властивості Transparent (якщо ваша середу розробки підтримує його) – це призведе до того, що фон підпису стане прозорим, і гарантовано вбереже вас від виникнення проблеми.

Ось такий він непростий, елемент Label: “обрізаний” текст і фон, який не відповідає фону основної форми, можуть сильно зіпсувати ставлення користувача до всієї програми.


Меню

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

У самих перших програмах, призначених для роботи на персональних комп’ютерах, меню являло собою список операцій, і для вибору будь-якої з них було потрібно натиснути на клавіатурі клавішу з цифрою, позначає порядковий номер відповідної команди в меню. У програмних продуктах для IBM PC середини 80-х років, більшість з яких працювало в текстовому режимі екрана (той же Norton Commander), меню вже мало складну структуру: команди були розбиті на групи, назви яких виводилися в рядку вгорі екрану; по спадаючим списками команд можна було переміщатися натисканням клавіш зі стрілками, а вибір робити за допомогою клавіші . У багатьох програмах до управління підключилася миша.

З розквітом Windows і зростанням популярності графічного інтерфейсу меню зайняло основне місце серед засобів керування комп’ютерними програмами. Законодавець мод в області інтерфейсів Windows-додатків – Корпорація Microsoft – постійно покращувала зовнішній вигляд і ергономіку меню. У Windows 95 в меню були додані графічні піктограми і можливість переміщення курсора мишею, а не тільки клавіатурою, як в Windows 3.1; в Windows 2000 з’явилися “розумні” меню, в яких першими показувалися найбільш часто викликаються користувачем команди.

Але, тим не менш, усіх цих заслуг меню в справі побудови інтерфейсів не виробляють на деяких авторів програм ніякого враження, і вони – о жах! – Починають вважати, що без меню в програмі цілком можна обійтися. Я якось запитав одного з shareware-авторів, в головному вікні програми якого була присутня тільки кнопкова панель інструментів, а меню не було. “Та ну його … Я не знаю, чого туди поміщати” – Почув я у відповідь.

Питання “Що поміщати в меню?” я розгляну трохи пізніше, а поки хотів би звернути увагу на обов’язковість присутності меню в головному вікні програми. Це, якщо завгодно, таке ж правило хорошого тону, як і будь-яке з евристик Якоба Нільсена, про які розповідалося вище. Відмовляючись від включення меню в проект своєї програми, автор ігнорує досвід і навички користувачів, змушує їх відмовлятися від стилю роботи, до якого вони звикли. Особливо мене тішить, коли автори не роблять в програмі меню, але створюють кнопкову панель інструментів: остання з’явилася в інтерфейсі програм для персональних комп’ютерів відносно недавно і, звичайно, не може бути повноцінною заміною меню. Хоча б тому, що меню – це не просто список команд, це ще і багатофункціональна “шпаргалка” по роботі з програмою, “шпаргалка”, яка завжди під рукою (як відомо, читати довідкові файли користувачі не дуже люблять). Досить провести мишею по рядку меню вгорі екрана, і можна з’ясувати набір функцій програми, комбінації “Гарячих клавіш” і навіть – пояснення призначення кнопок на панелі інструментів.

Зауваження

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

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

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

І, звичайно ж, не варто забувати про контекстних меню – меню, що з’являються при клацанні правою кнопкою миші на якому-небудь об’єкті і містять команди для роботи з цим об’єктом. Розробка таких меню – справа, хоча технічно дуже просте, але при цьому досить копітка. Тим не менш, витрати часу і сил обов’язково окупляться. Операційна система Windows 95 і її подальші версії привчили користувачів до думки, що при натисканні правою кнопкою миші з’являється контекстне меню. Клацання правою кнопкою миші став вже настільки природнім дією, що програма, не “розуміє” його, нагадує людину, яка не чує, що йому говорять. Контекстне меню – одна з найсильніших звичок користувачів і навик, який мають навіть малодосвідчені новачки. Потрібно обов’язково враховувати це при розробці інтерфейсів власних програм.

Деякі автори програм забувають про значення терміна “контекстне меню”. Таке меню повинно містити тільки ті команди, які відносяться до об’єкта, якому належить меню. Викликати по клацанню правою кнопкою миші меню з пари десятків пунктів і вже тим більше дублікат головного меню програми не має сенсу: практична цінність такого “контекстного” меню дорівнює нулю.

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


Списки

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

Щоб уникнути виникнення подібних проблем потрібно ретельно протестувати роботу програми, щоб з’ясувати, чи можлива ситуація, що в список будуть виведені занадто довгі рядки, щоб уміститися в ньому повністю. Якщо це не виключається, то можна передбачити засоби, що дозволяють все-таки повністю переглянути “обрізану” рядок, наприклад, при подвійному натисканні мишею на що цікавить користувача рядку виводити на екран невелике віконце, де необхідний текст відображається повністю. Ще один хороший шлях вирішення цієї проблеми – замінити елемент Список (ListBox) більш функціональним, скажімо, ListView (В ньому, наприклад. Провідник Windows виводить список файлів). Задавши певним чином деякі властивості ListView, можна домогтися його повного зовнішньої схожості з традиційним списком, проте на відміну від останнього у вікні ListView буде присутній горизонтальна лінійка прокрутки.


Прапорці та перемикачі

Прапорці (CheckBoxes) і перемикачі (Option Buttons) використовуються для однієї мети: для вибору з групи запропонованих варіантів. Різниця між ними, як вам, напевно, відомо, полягає в тому, що прапорці використовуються для вибору одночасно кількох варіантів з групи, а перемикачі дозволяють зробити вибір на користь тільки одного варіанту.

На жаль, навіть деякі досить авторитетні фахівці не надають великого значення цьому відмінності між прапорцями і перемикачами. У черговому номері Visual Basic Programmer “s Journal 101 Tech Tips for VB Developers, що вийшов у серпні 1999 року, було опубліковано невеликий шматок коду, який модифікував функціональність групи прапорців, дозволяючи їм працювати, як перемикачі: з їхньою допомогою можна було вибрати тільки один варіант із запропонованих. “Така зміна може бути корисно, якщо ви хочете використовувати прапорці замість перемикачів”, – йшлося в публікації. Редактор сайту iarchitect.com з іронією запропонував замінити другу частину цієї фрази на наступне: “… якщо ви хочете запитати ваших користувачів”. Адже сама поява на екрані групи прапорців відразу говорить користувачеві про те, що зараз йому можна буде зробити вибір декількох варіантів, а не одного-єдиного. Тому ні в якому разі не застосовуйте прапорці для організації вибору одного варіанта з групи.


Конфіденційність

Кнопкові панелі інструментів (Toolbars) – улюблений компонент багатьох розробників. З ним вікно програми відразу набуває більш привабливий, солідний і професійний вигляд. Любов програмістів до панелей інструментів настільки велика, що вони, як я вже розповідав трохи вище, навіть відмовляються на користь них від святая святих користувальницького інтерфейсу – меню! Звичайно, популярність компонента призводить до того, що багато початківці розробники при включенні панелей інструментів у свій проект стикаються з деякими “підводними каменями”.

Панель інструментів – досить складний і, так би мовити, примхливий компонент. Для його підтримки в Windows включена спеціальна бібліотека – comctl32.dll. За історію розвитку операційних систем сімейства Windows 9.x ця бібліотека пережила кілька оновлень, що призвело до того, що в програмах, створених на більш пізніх версіях системи, з “новими” версіями comctl32.dll, панель інструментів не може працювати, якщо програма запущена під однією з попередніх версій Windows. Досвідчені розробники обов’язково включають в довідкові файли своїх програм інформацію про цю проблему. Вони викладають на своїх Web-сайтах нову версію comctl32, dll, щоб користувачі не самих останніх версій Windows могли нормально працювати з програмою. А от якщо програміст забуває про це, то незабаром йому починають приходити листи від користувачів з повідомленнями про дивну помилку, в результаті якої на кнопках панелі інструментів не видно піктограми.

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

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

А от наприклад, якщо ви вирішите запозичити для своєї програми піктограми популярного менеджера закачувань ReGet (http://www.reget.com), то навряд чи це виявиться непоміченим. Ці піктограми були створені спеціально для ReGet в одній з найбільших студій дизайну в Росії – Студії Артемія Лебедєва (http://www.design.ro), і розробник ReGet – компанія ReGet Software, звичайно ж, зацікавлена ​​в тому, щоб ніхто, крім неї, не користувався цими унікальними піктограмами.

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

При проектуванні панелі інструментів заборонена, аби при натисканні та утриманні кнопки миші на деяких кнопках Конфіденційність викликалося підменю з додатковими командами. Якщо ви вирішили забезпечити Панель інструментів у своїй програмі такими “складними” кнопками, то подбайте про те, щоб відповідним чином виділити їх, інакше користувач може і не здогадатися, що це не звичайна кнопка. Наприклад, багато нарікань викликає інтерфейс стратегічної гри SimCity 2000: деякі (але не всі) кнопки на панелі інструментів містять підменю, що з’являються, якщо натиснути і не відпускати кнопку миші на одній з них. Але піктограми на кнопках ніяк не вказують на цю їхню особливість. В результаті у багатьох користувачів виникають проблеми при освоєнні інтерфейсу: зізнатися, свого часу я сам довго не міг зрозуміти, чому клацання мишею по кнопці з зображенням електростанції не дозволяє мені додати атомну електростанцію, хоча така можливість була в попередній версії гри. Виявилося, що відповідний тип електростанції, як і кілька інших, викликається з підміню, яке “заховано” в кнопці.

А ось розробники Adobe Photoshop були більш послідовні: в нижньому правому куті кожної “складною” кнопки в якості індикації вміщено зображення стрілки.

Тип кордону кнопок на панелях інструментів – теж не таке просте питання, як здається. Традиційно кнопки на інструментальних панелях точно так само, як і звичайні командні кнопки, мали об’ємну кордон навколо них. Сформований порядок порушив вихід версії 3.0 браузера Microsoft Internet Explorer, Кнопки на панелі інструментів цієї програми мали “плоский” вигляд: межа з’являлася на них лише після того, як користувач наводив на кнопку курсор миші. Оригінальну, хоча і не безперечну ідею охоче підхопили всі розробники, і сьогодні практично всі програми мають “плоску” панель інструментів. Особисто я поділяю думку, що “плоска” панель інструментів виглядає дуже незвично і цікаво, проте є користувачі, яким більше до душі традиційне оформлення панелі інструментів, коли кнопки виглядають саме так, як повинні виглядати кнопки. І ті розробники програм, які намагаються не випускати з уваги навіть самі незначні дрібниці, передбачають у своїх продуктах можливість зміни користувачем виду панелі “звичайний” / “плоский”, тим більше що технічно реалізувати таку функцію в програмі дуже просто – потрібно міняти значення всього одного властивості.


Вкладки

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

Так, вкладки дозволяють упорядкувати великі обсяги даних, однак це корисна властивість вкладок сходить нанівець, якщо число самих вкладок стає занадто великим. Тут явно спостерігається протиріччя з правилом гаманця Міллера (див. розд. “Інші принципи побудови інтерфейсів” даної глави), що визначає, що людина може утримувати у своїй короткочасній пам’яті сім плюс-мінус дві сутності. Тому в декількох рядах вкладок, які вже перестають уміщатися в рамках діалогового вікна, дуже легко заплутатися. Навіть той десяток вкладок, які знаходяться у вікні Параметри Microsoft Word, викликає численні нарікання з боку користувачів. Дійсно, мало кому не доводилося безладно клацати по вкладках вікна налаштувань Microsoft Word, щоб відшукати потрібну опцію.

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

Якщо подивитися, як ця проблема вирішується у відомих shareware-програми, то можна помітити, що їх автори прагнуть зменшити число вкладок в діалогових вікнах за рахунок поділу всіх вкладок в нові групи, де число вкладок відносно невелике. Наприклад, в головному меню популярного поштового клієнта The Bat! (Http://www.ritlabs.com) є окремий пункт – Властивості, а в ньому – кілька підпунктів, викликають відповідні діалогові вікна: Редактор листів. Швидкі шаблони. Підключення та адміністрування і т. п. У деяких з них взагалі відсутні вкладки, а деякі обійшлися лише двома-трьома вкладками. У не менш популярному текстовому редакторі UltraEdit аналогічним чином рознесені вікна налаштування самого редактора і допоміжних утиліт. У вже багато раз згадуваної програмі Chameleon Clock, у вікні Властивості створено три групи опцій: Настройки, Дії і Види (перемикання між ними відбувається за допомогою панелі в стилі Microsoft Outlook), в яких знаходяться по чотири-п’ять вкладок (А в опції Види їх взагалі немає).


Підказки

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

Треба пам’ятати, що спливаючі підказки – супутник зовсім не будь-якого компонента на формі додатку. Традиційно вони використовуються для “озвучування” призначення тільки кнопок на панелях інструментів, секцій на рядку стану і …, мабуть, все. Є деякі випадки використання спливаючих підказок для інших компонентів (наприклад, вертикальна лінійка прокрутки в Microsoft Word або меню Пуск в Windows 2000), але це швидше виняток, ніж правило.

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


Обережно: скіни!

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

Людина завжди прагне якось виділитися, додати собі і своїм речам індивідуальність. Багато людей намагаються так прикрасити власний будинок, автомобіль, робоче місце, щоб вони відрізнялися від інших. Те ж саме спостерігається з комп’ютерами: користувачі встановлюють в якості “шпалер” Робочого столу Windows сподобалися картинки, перенастроюють колірну і звукову схеми. Введення можливості змінити вид програми по своєму смаку – закономірний розвиток комп’ютерних інтерфейсів, ще один крок до задоволення бажання користувачів настроювати все “під себе” і індивідуалізувати себе і своє оточення.

Хрестоматійний приклад програми, що використовує скіни, – це мульти-медимнов плейер WinAmp (http://www.winamp.com). Саме після її виходу слово “скіни” стало дуже модним. Величезною популярністю стали користуватися програми, як і WinAmp, що дозволяли змінювати “шкіру”, online-колекції скінів (наприклад, сайт http://www.skinz.org). Слово “скіни” буквально заворожувало користувачів, і вони поспішали завантажити і випробувати будь-який програмний продукт, в описі якого воно зустрічалося. Природно, сам WinAmp теж не залишився без уваги, діставши величезну аудиторію користувачів зі всього світу, і його часто наводять як приклад вдалого маркетингового ходу.

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

Однак у цих компонентів є на перший погляд непомітний, але, проте, дуже значний недолік. Кожен з цих компонентів, як правило, працює тільки з власним форматом скінів. Внаслідок цього, в програмах, в яких підтримка скінів організована за допомогою таких компонентів, не можуть бути скіни з інших програм, наприклад з того ж WinAmp. Крім того, кількість “шкур”, які є в розпорядженні програміста, що використовує один із таких компонентів, зазвичай дуже невелика, не більше 10-20.

Деякі програмісти не звертають на ці доводи ніякої уваги:

“Подумаєш, несумісність форматів, ну і нехай, що скінів мало – головне, вони, скіни, Є!” Але давайте-ка трохи поміркуємо. Якщо кожна програма використовує власний формат скінів, значить, існує ймовірність, що в різних програмах скіни будуть також різні (насправді саме так і є). Крім того, раз для кожної програми існує всього лише по парі десятків “шкур”, то користувач «точно не зможе вибрати з них ту, яка влаштовує його на сто відсотків. І тепер уявіть картину: кожна програма на комп’ютері користувача має різний вигляд, та до того ж і не повністю влаштовує господаря системи, речі, навряд чи користувачі будуть самостійно малювати скіни до вашої програмі: це не таке вже просте заняття, а в ситуації, коли скіни потрібні відразу для декількох програм на комп’ютері, ця справа стає і зовсім безперспективним.

Набагато більш виграшний варіант – піти у фарватері лідера (прийом, який дієвий не тільки в області програмування взагалі і скінів зокрема). Кандидатура на цю роль тільки одна: WinAmp. Посудіть самі:

· WinAmp – найпопулярніша програма, яка підтримує скіни. Завдяки дійсно хорошим функціональним можливостям і безкоштовності, вона найчастіше використовується як плейер звукових файлів;

· До WinAmp вже намальовано величезну кількість скінів – більше сорока трьох тисяч (!) На серпень 2001 року;

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

Таким чином, зробивши свій продукт сумісним зі “шкурам” WinAmp, ви одним пострілом вбиваєте не двох, а трьох зайців, отримуючи:

· Десятки тисяч готових скінів, доступних користувачам;

· Величезну потенційну аудиторію, значна частина якої цілком може з потенційної стати реальною: багато користувачів захочуть отримати, наприклад, калькулятор чи записну книжку, які виглядають так само, як і їх улюблений WinAmp;

· Можливість ефективно рекламувати свою програму: наявність в описі програми слів “підтримка скінів WinAmp” дає непоганий відгук з боку користувачів на пошукових системах і в online-архівах програмного забезпечення.

Якщо ви захочете вбудувати в свою програму підтримку скінів, то спочатку гарненько подумайте: а чи справді “шкури” так необхідні вашому продукту?

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

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

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

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


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

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

Ваш отзыв

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

*

*