Основні принципи розробки графічного інтерфейсу користувача

[ виправити ] текст може містити помилки, будь ласка перевіряйте перш ніж використовувати.

скачати


Зміст

Введення

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

Правило 1: дати контроль користувачеві

Правило 2: зменшити навантаження на користувача

Правило 3: зробити інтерфейс сумісним

Керівні принципи

Програма "Tidy Start Menu"

Висновок

Література

Введення

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

Трейсі Леонард

Чому треба дотримуватися принципів побудови користувальницького інтерфейсу?

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

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

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

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

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

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

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

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

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

Хансен представив перший список принципів проектування [2]. Принципи такі:

1) знати користувача;

2) скоротити запам'ятовування;

3) оптимізувати операції;

4) усунути помилки.

Багато великих виробників операційних систем, випусти на ринок свої нові продукти, публікують відповідні інструкції та вказівки. У цих виданнях розкриваються принципи підходу до проектування інтерфейсу. Керівництва випускали Apple Computer, Inc. (1992), IBM Corporation (1992), Microsoft Corporation (1995) та UNIX OSF / Motif (1993).

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

Важливість дотримання принципів

"Несумісність інтерфейсу може коштувати великої компанії мільйонів доларів збитку через втрату продуктивності і збільшення вартості технічної підтримки." - Джессі Бріст.

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

Дані принципи витримали перевірку часом і появою нових комп'ютерних технологій. Якоб Нільсен зауважив: "Принципи залишаться основними навіть якщо програма буде мати футуристичний тривимірний дизайн з печаткою" DataGlove ", що служить для введення, будуть розпізнаватися руху та" живі "відеозображення. Вони будуть актуальні, оскільки виражають основну ідею діалогу з машиною за допомогою команд" [8].

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

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

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

"Роби це простіше, але не примітивніше."

Альберт Ейнштейн

Правило 1: дати контроль користувачеві

Досвідчені проектувальники дозволяють користувачам вирішувати деякі завдання на власний розсуд. Архітектори по завершенні будівництва складного комплексу будівель повинні прокласти між ними доріжки для пішоходів. Поки вони не знають, в якому саме місці люди будуть перетинати майданчика. Тому доріжки ніколи не прокладають одночасно із зведенням будівель. На майданчиках між будинками поміщаються таблички з написом: "Будь ласка ходіть по траві". Через деякий час будівельники повертаються і тільки тепер, згідно з "волевиявлення" населення, заливають протоптані доріжки асфальтом.

Принципи, які дають користувачеві контроль над системою:

1) використовувати режими розсудливо;

2) надати користувачеві можливість вибирати: працювати або мишею, або клавіатурою, або їх комбінацією;

3) дозволити користувачеві сфокусувати увагу;

4) демонструвати повідомлення, які допоможуть йому в роботі;

5) створити умови для негайних і оборотних дій, а також зворотного зв'язку;

6) забезпечити відповідні шляхи і виходи;

7) пристосовуєте систему до користувачів з різним рівнем підготовки;

8) зробити користувальницький інтерфейс більш зрозумілим;

9) дати користувачеві можливість налаштовувати інтерфейс за своїм смаком;

10) дозволити користувачеві безпосередньо маніпулювати об'єктами інтерфейсу;

Використовувати режими розсудливо

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

Дозволити людині використовувати мишу і клавіатуру

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

Дозволити користувачеві переключити увагу

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

Показувати пояснюють повідомлення і тексти

У всьому інтерфейсі використовувати зрозумілі для користувача терміни. Вони не зобов'язані знати про бітах і байтах!

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

Забезпечити негайні і оборотні дії і зворотний зв'язок

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

Надавати зрозумілі шляхи і виходи

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

Пристосовуватися до користувачів з різними рівнями навичок

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

Зробити користувальницький інтерфейс "прозорим"

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

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

Дати користувачу можливість налаштувати інтерфейс на свій смак

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

Представлення функцій в OS / 2 і діалогові вікна для зміни функціональних властивостей у Windows 95 дозволяють налаштовувати багато системні переваги та об'єкти. Розробники Windows 95 навіть створили додаткову утиліту - Tweak UI. Програмні продукти повинні використовувати властивості операційної системи згідно з іншими додатками. Проте всі інші атрибути програмного інтерфейсу, включаючи меню і кнопки, повинні мати функцію індивідуальної настройки.

Дозволити користувачеві пряме маніпулювання об'єктами інтерфейсу

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

Дозволити користувачеві думати, що він контролює ситуацію

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

Правило 2: зменшити навантаження на користувача

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

Принципи, що дозволяють знизити навантаження на пам'ять користувача:

1) не завантажувати короткочасну пам'ять;

2) покладатися на розпізнавання, а не на повторення;

3) представити візуальні заставки;

4) передбачити установки за замовчуванням, команди Undo і Rendo;

5) передбачити "швидкі" шляху;

6) активувати синтаксис дій з об'єктами;

7) використовувати метафори з реального світу;

8) застосовувати розкриття і пояснення понять і дій;

9) збільшити візуальну ясність.

Не навантажувати короткочасну пам'ять

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

Покладатися на розпізнавання, а не на повторення

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

Забезпечити візуальні підказки

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

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

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

Забезпечити ярлики для інтерфейсу

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

Активізувати синтаксис дій з об'єктами

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

Використовувати метафори реального світу

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

Пояснювати поняття і дії

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

Збільшити візуальну ясність

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

Правило 3: зробити інтерфейс сумісним

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

Принципи створення сумісності інтерфейсу:

1) проектування послідовного інтерфейсу;

2) загальна сумісність всіх програм;

3) збереження результатів взаємодії;

4) естетична привабливість і цілісність;

5) заохочення вивчення;

Проектування послідовного інтерфейсу

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

Загальна сумісність всіх програм

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

Поліпшення інтерфейсу і послідовності

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

Збереження результатів взаємодії

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

Естетична привабливість і цілісність

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

Заохочення вивчення

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

Керівні принципи

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

Джон Гулд

Для чого потрібні керівні принципи

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

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

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

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

Нормативи

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

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

Розвиток існуючих керівних принципів проектування інтерфейсу

Багато програмні продукти створені для роботи на різних платформах. З тих пір, як ці платформи мають різні операційні системи, інструменти та стилі інтерфейсу, дуже складно розробляти інтерфейс, що задовольняє всі платформи або що працює на кожній з платформ. Доповнення - добірка індустріальних посібників з проектування - було розроблено Беллкором [12]. Воно містить опис і керівні принципи для основних компаній і операційних систем, як IBM CUA, OSF, Microsoft Windows і ін

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

Застосування керівних принципів

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

Керівні принципи по розробці інтерфейсу на макро-і мікрорівні

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

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

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

Програма "Tidy Start Menu "

З часом у вас накопичилося багато програм в меню "Пуск", і кожного разу для запуску потрібної програми вам потрібно витрачати час на пошуки? Програма "Tidy Start Menu" допоможе вам навести порядок в меню і зробити роботу комфортною!

Для цього програма пропонує розбити всі програми з меню на категорії. Так, наприклад, програми, які використовуються для роботи в Інтернет, можна об'єднати в групу "Інтернет", а всі ігри помістити в категорію "Ігри".

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

Нижче наведено вихідні коди програми і знімки його інтерфейсу.

program Man;

uses

Forms, Dialogs, Controls,

Viewing in 'Viewing.pas' {look},

Setuping in 'Setuping.pas' {setup},

Editing in 'Editing.pas' {Edit},

ADOTableofset in 'ADOTableofset.pas' {TabSheetset};

{$ R *. res}

begin

try

Application.Initialize;

Application.Title: = 'Programs';

Application.CreateForm (Tlook, look);

Application.CreateForm (Tsetup, setup);

Application.CreateForm (TEdit, Edit);

Application.CreateForm (TTabSheetset, TabSheetset);

Application.Run;

except

if MessageDlg ('The software is not installed! You wish to instal it?',

mtInformation, [mbYes, mbCancel], 0) = mryes then

begin

Application.Initialize;

Application.CreateForm (Tsetup, setup);

Application.Run;

end; end;

end.

unit Viewing;

interface

uses

Windows, Messages, SysUtils, Variants, Classes, Graphics, Controls, Forms,

Dialogs, Menus, ComCtrls, ShellCtrls, ToolWin, ImgList;

const

WM_MYICONNOTIFY = WM_USER + 123;

type

Tlook = class (TForm)

PageControl1: TPageControl;

TabSheet1: TTabSheet;

TabSheet2: TTabSheet;

TabSheet3: TTabSheet;

TabSheet4: TTabSheet;

TabSheet5: TTabSheet;

ShellListView1: TShellListView;

ShellListView2: TShellListView;

ShellListView3: TShellListView;

ShellListView4: TShellListView;

ShellListView5: TShellListView;

PopupMenu1: TPopupMenu;

N1: TMenuItem;

N2: TMenuItem;

N3: TMenuItem;

N4: TMenuItem;

MainMenu1: TMainMenu;

Services1: TMenuItem;

oreinstall1: TMenuItem;

Edit1: TMenuItem;

Exit1: TMenuItem;

ToolBar1: TToolBar;

ImageList1: TImageList;

ToolButton1: TToolButton;

ToolButton2: TToolButton;

ToolButton3: TToolButton;

ToolButton4: TToolButton;

ToolButton5: TToolButton;

procedure FormCreate (Sender: TObject);

procedure FormDestroy (Sender: TObject);

procedure N1Click (Sender: TObject);

procedure N2Click (Sender: TObject);

procedure N4Click (Sender: TObject);

procedure FormActivate (Sender: TObject);

procedure oreinstall1Click (Sender: TObject);

procedure Exit1Click (Sender: TObject);

procedure Edit1Click (Sender: TObject);

private

ShownOnce: Boolean;

public

procedure WMICON (var msg: TMessage); message WM_MYICONNOTIFY;

procedure WMSYSCOMMAND (var msg: TMessage); message WM_SYSCOMMAND;

procedure CreateTrayIcon (n: Integer);

procedure DeleteTrayIcon (n: Integer);

procedure RestoreMainForm;

procedure HideMainForm;

end;

var

look: Tlook;

implementation

{$ R *. dfm}

uses

ComObj, activex, ShellApi,

registry, StdCtrls, ADOTableofset, Setuping;

procedure Tlook.CreateTrayIcon (n: Integer);

var

nidata: TNotifyIconData;

begin

with nidata do

begin

cbSize: = SizeOf (TNotifyIconData);

Wnd: = Self.Handle;

uID: = 1;

uFlags: = NIF_ICON or NIF_MESSAGE or NIF_TIP;

uCallBackMessage: = WM_MYICONNOTIFY;

hIcon: = Application.Icon.Handle;

StrPCopy (szTip, Application.Title);

end;

Shell_NotifyIcon (NIM_ADD, @ nidata);

end;

procedure Tlook.DeleteTrayIcon (n: Integer);

var nidata: TNotifyIconData;

begin

with nidata do

begin

cbSize: = SizeOf (TNotifyIconData);

Wnd: = Self.Handle;

uID: = 1;

end;

Shell_NotifyIcon (NIM_DELETE, @ nidata);

end;

procedure Tlook.FormCreate (Sender: TObject);

begin

ShownOnce: = False;

CreateTrayIcon (1);

end;

procedure Tlook.FormDestroy (Sender: TObject);

begin

DeleteTrayIcon (1);

end;

procedure Tlook.HideMainForm;

begin

Application.ShowMainForm: = False;

ShowWindow (Application.Handle, SW_HIDE);

ShowWindow (Application.MainForm.Handle, SW_HIDE);

end;

procedure Tlook.N1Click (Sender: TObject);

begin

RestoreMainForm;

DeleteTrayIcon (1);

N1.Enabled: = False;

N2.Enabled: = True;

end;

procedure Tlook.N2Click (Sender: TObject);

begin

HideMainForm;

CreateTrayIcon (1);

n2.Enabled: = False;

n1.Enabled: = True;

end;

procedure Tlook.N4Click (Sender: TObject);

begin

close;

end;

procedure Tlook.RestoreMainForm;

var i, j: Integer;

begin

Application.ShowMainForm: = True;

ShowWindow (Application.Handle, SW_RESTORE);

ShowWindow (Application.MainForm.Handle, SW_RESTORE);

if not ShownOnce then

begin

for I: = 0 to Application.MainForm.ComponentCount -1 do

if Application.MainForm.Components [I] is TWinControl then

with Application.MainForm.Components [I] as TWinControl do

if Visible then

begin

ShowWindow (Handle, SW_SHOWDEFAULT);

for J: = 0 to ComponentCount -1 do

if Components [J] is TWinControl then

ShowWindow ((Components [J] as TWinControl). Handle, SW_SHOWDEFAULT);

end;

ShownOnce: = True;

end; end;

procedure Tlook.WMICON (var msg: TMessage);

var P: TPoint;

begin

case msg.LParam of

WM_LBUTTONDOWN:

begin

GetCursorPos (p);

SetForegroundWindow (Application.MainForm.Handle);

PopupMenu1.Popup (PX, PY);

end;

WM_LBUTTONDBLCLK: n1Click (Self);

end;

end;

procedure Tlook.WMSYSCOMMAND (var msg: TMessage);

begin

inherited;

if (Msg.wParam = SC_MINIMIZE) then n2Click (Self);

end;

procedure Tlook.FormActivate (Sender: TObject);

begin

n2.Click;

end;

procedure Tlook.oreinstall1Click (Sender: TObject);

begin

setup.Show;

end;

procedure Tlook.Exit1Click (Sender: TObject);

begin

close;

end;

procedure Tlook.Edit1Click (Sender: TObject);

begin

hide;

TabSheetset.Show;

end;

end.

Модуль Setup:

unit setuping;

interface

uses

Windows, Messages, SysUtils, Variants, Classes, Graphics, Controls, Forms,

Dialogs, ComCtrls, StdCtrls, ShlObj, ComObj, ActiveX, DB, ADODB;

type

Tsetup = class (TForm)

ProgressBar1: TProgressBar;

Button1: TButton;

ListBox1: TListBox;

Label1: TLabel;

Button2: TButton;

DataSource1: TDataSource;

ADOConnection1: TADOConnection;

ADOTable1: TADOTable;

ADOTable2: TADOTable;

ADOTable3: TADOTable;

ADOTable4: TADOTable;

ADOTable5: TADOTable;

ADOTable1N: TAutoIncField;

ADOTable1Run: TWideStringField;

ADOTable1Program: TWideStringField;

ADOTable2N: TAutoIncField;

ADOTable2Run: TWideStringField;

ADOTable2Program: TWideStringField;

ADOTable3N: TAutoIncField;

ADOTable3Run: TWideStringField;

ADOTable3Program: TWideStringField;

ADOTable4N: TAutoIncField;

ADOTable4Run: TWideStringField;

ADOTable4Program: TWideStringField;

ADOTable5N: TAutoIncField;

ADOTable5Run: TWideStringField;

ADOTable5Program: TWideStringField;

procedure Button1Click (Sender: TObject);

procedure Button2Click (Sender: TObject);

procedure FormClose (Sender: TObject; var Action: TCloseAction);

end;

var

setup: Tsetup;

f: Text;

implementation

{$ R *. dfm}

procedure Tsetup.Button1Click (Sender: TObject);

var

i: integer;

s1, s2: string;

procedure LookDir (StartDir, Mask: String; List: TStrings);

var

SearchRec: TSearchRec;

s, k: string;

begin

if StartDir [Length (StartDir)] <> '\' then StartDir: = StartDir + '\';

if FindFirst (StartDir +'*.*', faAnyFile, SearchRec) = 0 then

begin

repeat

if (SearchRec.Attr and faDirectory) <> faDirectory then

begin

if ExtractFileExt (StartDir + SearchRec.Name) = Mask then

begin

List.Add (StartDir + SearchRec.Name);

s: = StartDir + SearchRec.Name;

k: = SearchRec.Name;

writeln (f, s);

writeln (f, k); i: = i +1;

ProgressBar1.Position: = i;

end; end

else

if (SearchRec.Name <>'..') and (SearchRec.Name <> '.') then

begin

LookDir (StartDir + SearchRec.Name +'', Mask, list);

end;

until FindNext (SearchRec) <> 0;

FindClose (SearchRec);

end; end;

procedure jarlik (const PathObj, PathLink, Desc, Param: string);

var

IObject: IUnknown;

SLink: IShellLink;

PFile: IPersistFile;

begin

IObject: = CreateComObject (CLSID_ShellLink);

SLink: = IObject as IShellLink;

PFile: = IObject as IPersistFile;

with SLink do

begin

SetArguments (PChar (Param));

SetDescription (PChar (Desc));

SetPath (PChar (PathObj));

end;

PFile.Save (PWChar (WideString (PathLink)), FALSE);

end;

procedure setap;

begin

while not eof (f) do

begin i: = i +1;

ProgressBar1.Position: = i;

readln (f, s1); readln (f, s2);

ADOTable1.First;

ADOTable2.First; ADOTable3.First;

ADOTable4.First; ADOTable5.First;

while not ADOTable1.Eof do

begin

if s2 = ADOTable1Run.AsString then

jarlik (s1, 'C: \ setup \ Entertainments \' + ADOTable1Program.AsString + '. lnk','','')

ADOTable1.Next;

end;

while not ADOTable2.Eof do

begin

if s2 = ADOTable2Run.AsString then

jarlik (s1, 'C: \ setup \ Games \' + ADOTable2Program.AsString + '. lnk','','');

ADOTable2.Next;

end;

while not ADOTable3.Eof do

begin

if s2 = ADOTable3Run.AsString then

jarlik (s1, 'C: \ setup \ Internet \' + ADOTable3Program.AsString + '. lnk','','');

ADOTable3.Next;

end;

while not ADOTable4.Eof do

begin

if s2 = ADOTable4Run.AsString then

jarlik (s1, 'C: \ setup \ Office \' + ADOTable4Program.AsString + '. lnk','','');

ADOTable4.Next;

end;

while not ADOTable5.Eof do

begin

if s2 = ADOTable5Run.AsString then

jarlik (s1, 'C: \ setup \ Utilites \' + ADOTable5Program.AsString + '. lnk','','');

ADOTable5.Next;

end; end; end;

begin

ProgressBar1.Max: = 5000; i: = 0;

CreateDir ('C: \ setup');

CreateDir ('C: \ setup \ Internet');

CreateDir ('C: \ setup \ Entertainments');

CreateDir ('C: \ setup \ Games');

CreateDir ('C: \ setup \ Office');

CreateDir ('C: \ setup \ Utilites');

assignfile (f, 'REZ.txt');

rewrite (f);

LookDir ('C: \ Program Files', '. Exe', ListBox1.Items);

reset (f); setap;

closefile (f);

ProgressBar1.Position: = ProgressBar1.Max;

Label1.Caption: = 'Installation is finished';

Button1.Visible: = False;

Button2.Visible: = true;

end;

procedure Tsetup.Button2Click (Sender: TObject);

begin

Close;

end;

procedure Tsetup.FormClose (Sender: TObject; var Action: TCloseAction);

begin

ADOTable1.Close; ADOTable2.Close;

ADOTable3.Close; ADOTable4.Close;

ADOTable5.Close;

end;

end.

unit ADOTableofset;

interface

uses

Windows, Messages, SysUtils, Variants, Classes, Graphics, Controls, Forms,

Dialogs, StdCtrls, ExtCtrls, DB, ADODB;

type

TTabSheetset = class (TForm)

RadioGroup1: TRadioGroup;

Button1: TButton;

DataSource1: TDataSource;

ADOTable1: TADOTable;

procedure Button1Click (Sender: TObject);

procedure FormClose (Sender: TObject; var Action: TCloseAction);

end;

var

TabSheetset: TTabSheetset;

implementation

{$ R *. dfm}

uses Editing, Viewing, Setuping;

procedure TTabSheetset.Button1Click (Sender: TObject);

begin

edit.Show;

case TabSheetset.RadioGroup1.ItemIndex of

0: ADOTable1.TableName: = 'Entertainments';

1: ADOTable1.TableName: = 'Games';

2: ADOTable1.TableName: = 'Internet';

3: ADOTable1.TableName: = 'Office';

4: ADOTable1.TableName: = 'Utilites';

end;

ADOTable1.Open;

hide;

end;

procedure TTabSheetset.FormClose (Sender: TObject;

var Action: TCloseAction);

begin

ADOTable1.Close;

look.Show;

end;

end.

unit Editing;

interface

uses

Windows, Messages, SysUtils, Variants, Classes, Graphics, Controls, Forms,

Dialogs, Grids, DBGrids, DB, ADODB, Menus, ComCtrls, ToolWin, ExtCtrls,

DBCtrls;

type

TEdit = class (TForm)

DBGrid1: TDBGrid;

MainMenu1: TMainMenu;

abSheet1: TMenuItem;

choose1: TMenuItem;

N1: TMenuItem;

Close1: TMenuItem;

ToolBar1: TToolBar;

ToolButton1: TToolButton;

ToolButton2: TToolButton;

ToolButton5: TToolButton;

DBNavigator1: TDBNavigator;

procedure FormClose (Sender: TObject; var Action: TCloseAction);

procedure Close1Click (Sender: TObject);

procedure ToolButton1Click (Sender: TObject);

procedure choose1Click (Sender: TObject);

end;

var

Edit: TEdit;

implementation

uses Viewing, ADOTableofset;

{$ R *. dfm}

procedure TEdit.FormClose (Sender: TObject; var Action: TCloseAction);

begin

TabSheetset.ADOTable1.Close;

look.Show;

end;

procedure TEdit.Close1Click (Sender: TObject);

begin

close;

end;

procedure TEdit.ToolButton1Click (Sender: TObject);

begin

TabSheetset.Show; close;

end;

procedure TEdit.choose1Click (Sender: TObject);

begin

TabSheetset.Show; close;

end;

end.

Висновок

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

Джонатан Грудина

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

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

Дослідники займалися вивченням того, як розробники використовують керівні принципи. Одне дослідження було проведено в рамках підготовки компанією IBM (1992) керівництва по призначеному для користувача інтерфейсу і довідником. Тецлав і Шварц запропонували розробникам побудувати відповідні інтерфейси на базі керівних принципів по загальному для користувача інтерфейсу. Вони з'ясували, що були упущені кілька важливих ідей і деталей. Розробники віддавали перевагу графічним ілюстрацій і прикладів, а не тексту, що розповідає про концепції розробки. Крім того, вони хотіли мати можливість дослідити пропоновані приклади інтерактивним способом. Отримані розробки у великій мірі були визнані сумісними, однак мали місце і розбіжності в інтерпретації керівних принципів [15]. Розробка інтерфейсу багато в чому схожа на наше життя - на конкретне питання не завжди мають однозначну відповідь.

Інше дослідження Товтрап і Нільсен принесло аналогічні результати [16]. Тільки 71% розробок відповідав стандартам. Велика частина відмінностей була обумовлена ​​впливам досвіду розробників зі створення нестандартних проектів. Представлений для оцінки інтерфейс мав у середньому від 4 до 12 відхилень. Це було особливо дивно, оскільки в учасників тесту інтерес до зручності застосування інтерфейсу був вище середнього. Розробка інтерфейсу - більше мистецтво, ніж наука. Конкретні приклади надзвичайно корисні, оскільки демонструють, як треба слідувати керівним принципам з розробки. Щоб навчити розробників використанню принципів, потрібні тривалі тренінги. Алан Зейчік вдало підвів підсумок по цій темі: "Мораль така: при розробці програмних інструментів і споживчих продуктів варто дотримуватися існуючих керівним принципам по призначеному для користувача інтерфейсу. Дотримуйтесь їм, навіть якщо вам здається, що вони мають дефекти. Можливо, ваш проект більш високої якості, але запитайте себе: чи допоможе ця найвищої якості схема, що відображає функціональні клавіші, або вдосконалену метафора меню мою додатком стати невід'ємною частиною робочого середовища користувача? Або це стане постійним джерелом роздратування, через якого мій досконалий продукт у підсумку буде припадати пилом на полиці? " .

Література

  1. Apple Computer, Inc. 1992. Macintosh Human Interface Guidelines. Reading. MA: Addison-Wesley.

  2. Hansen, W. 1971. User engineering principles for interactive systems. AFIPS Conference Proceedings 39. AFIPS Press, pp. 523-532.

  3. Heckel, Paul. 1984. The Elements of Friendly Software Design. New York: Warner Books.

  4. IBM Corporation. 1992. Object-Oriented Interface Design: IBM Common User Access Cuidelines. New York: QUE.

  5. Johnson, Jeff, Teresa Roberts, William Verplank, David Smith, Charles Irby, Marian Beard, and Kevin Mackey. 1989. The Xerox Star: A Retrospective. IEEE Computer 22 (9): pp. 11-29.

  6. Mayhew, Deborah. 1992. Principles and Guidelines in Software User Interface Design. Englewood Cliffs, NJ: Prentice-Hall.

  7. Microsoft Corporation. 1995. The Windows Interface Cuidelines for Software Design. Redmond, WA: Microsoft Press.

  8. Nielsen, Jakob. 1990. Traditional dialogue design applied to modern user interfaces. Communication of the ACM 33 (10), pp. 109-118.

  9. Open Software Foundation. 1993. OSF / Motif Style Guide, Revision 1.2. Englewood Cliffs, Prentice-Hall.

  10. Rubenstein, R. and H. Hersch. 1984. The Human Factor: Designing Computer System for People, Newton, MA: Digital Press.

  11. Shneiderman, Ben. 1992. Designing the User Interface: Strategies for Effective Human-Computer Interaction. Reading. MA: Addison-Wesley.

  12. Bellcore. 1996. Design Guide for Multiplatform Graphical User Interfaces. LP-R13, Piscataway, NJ: Bellcore (http://www.bellcore.com).

  13. Gould, Jonh D. 1988. How to design usable systems. In Helander, M. (Ed.), Handbook of Human-Computer Interaction. Amsterdam, Holland: Elsevier Science Publishers.

  14. Grudin, Jonathan. 1989. The case against user interface consistency. Communications of the ACM 32 (10).

  15. Tetzlaff, Linda and David R. Schwartz. 1991. The use of guidelines in interface design. Proceeding of ACM CHI'91, New Orleans, LA.

  16. Smith, Sidney and Jane Mosier. 1986. Guidelines for Designing User Interface Software. Report ESD-TR-86-278 MTR-10090. Bedford, MA: MITRE Corporation.


Додати в блог або на сайт

Цей текст може містити помилки.

Програмування, комп'ютери, інформатика і кібернетика | Курсова
126.3кб. | скачати


Схожі роботи:
Організація інтерфейсу користувача
Тестування для користувача інтерфейсу
Проектування інтерфейсу як частина розробки ТЗ
Основні принципи та етапи розробки плану PR кампанії з використанням рекламних засобів і прийомів
Використання графіки Викорисьання графічного режиму в Pascal -основні оператори
Принципи розробки та оцінки державної політики України
Графічний редактор Paint Опис графічного редактора Paint - стандартоного графічного редактора
Принципи розробки алгоритмів і програм для вирішення прикладних завдань
Принципи розробки плану використання засобів масової інформації для реклами
© Усі права захищені
написати до нас