
- •1. Передумови
- •1.1. Визначення інтерфейсу
- •1.2. Простої повинне залишатися простим
- •1.3. Орієнтація на людину і на користувача
- •1.4. Інструменти, що перешкоджають новим ідеям
- •1.5. Розробка інтерфейсу як частина загального циклу розробки
- •1.6. Визначення человекоориентированного інтерфейсу
- •2. Когнетика і локус уваги
- •2.1. Ергономіка і когнетика: що ми можемо і чого не можемо
- •2.2. Когнітивне свідоме і когнітивне несвідоме
- •2.3. Локус уваги
- •2.3.1. Формування звичок
- •2.3.2. Одночасне виконання задач
- •2.3.3. Сингулярность локусу уваги
- •2.3.4. Джерела локусу уваги
- •2.3.5. Експлуатація єдиного локусу уваги
- •2.3.6. Поновлення перерваної роботи
- •3.2. Режими
- •3.2.1. Визначення режимів
- •3.2.2. Режими, користувальницькі настроювання і тимчасові режими
- •3.2.3. Режими і квазирежимы
- •3.3. Моделі "іменник-дієслово" і "дієслово-іменник"
- •3.4. Видимість і заможність
- •3.5. Монотонність
- •3.6. Міф про дихотомію "новачок-експерт"
- •4.2. Модель швидкості печатки goms
- •4.2.1. Тимчасові інтервали в інтерфейсі
- •4.2.2. Розрахунки по моделі goms
- •4.2.3. Приклади розрахунків по моделі goms
- •4.2.3.1. Інтерфейс для Хола: варіант 1. Діалогове вікно
- •4.2.3.3. Інтерфейс для Хола: варіант 2
- •4.3.1. Продуктивність інтерфейсу для Хола
- •4.3.2. Інші рішення інтерфейсу для Хола
- •4.4. Закон Фитса і закон Хика
- •4.4.1. Закон Фитса
- •4.4.2. Закон Хика
- •5.1. Уніфікація й елементарні дії
- •5.2. Каталог елементарних дій
- •5.2.1. Підсвічування, вказівка і виділення
- •5.2.2. Команди
- •5.2.3. Екранні стани об'єктів
- •5.3. Імена файлів і файлові структури
- •5.4. Пошук рядків і механізми пошуку
- •5.4.1. Роздільники в шаблоні пошуку
- •5.4.2. Одиниці взаємодії
- •5.5. Форма курсору і методи виділення
- •5.7. Ліквідація додатків
- •5.8. Команди і трансформатори
- •6.1. Інтуїтивні і природні інтерфейси
- •6.2. Поліпшена навігація: ZoomWorld
- •6.3. Піктограми
- •6.4. Способи і засоби допомоги в человекоориентированных інтерфейсах
- •6.4.1. Вирізувати і вставити
- •6.4.2. Повідомлення користувачу
- •6.4.3. Спрощення входу в систему
- •6.4.4. Автоповтор і інші прийоми роботи з клавіатурою
- •6.5. Лист від одного користувача
- •7.1.2. Важливість ведення документації при створенні програм
- •7.2. Режими і кабелі
- •7.3. Етика і керування розробкою інтерфейсів
7.1.2. Важливість ведення документації при створенні програм
У багатьох джерелах повідомляється, що для програмістів важливо докладно документувати машинний код, що вони пишуть. Для цього звичайно приводяться дві причини: по-перше, щоб допомогти зрозуміти програму при її читанні (Knuth, 1992, с. 99), і, по-друге, щоб спростити адаптацію програми до нових умов (Weіnberg, 1971, с. 164). Звичайно в програмі поруч з рядками коду можна зустріти коментарі (частіше однорядкові). Багато програм бувають майже цілком позбавлені коментарів.
Як відзначив Батіг (Knuth), написання коментарю до чи під час створення коду може допомогти процесу написання, поліпшити структуру алгоритмів, знизити число помилок і повторних написань програми, необхідних для завершення проекту, а також дає інші переваги, що звичайно згадуються з приводу коментарів. Як видно , правильність висновків Батога має підстави з погляду когнетики.
Коли ми як досвідчені програмісти розробляємо алгоритми і пишемо код, цей процес почасти відбувається на несвідомому рівні. Як уже було відзначено, ця ментальна область може бути піддана протиріччям. Припускаю, що причина деяких програмних помилок полягає в тім, що когнітивне несвідоме переживає протиріччя тим часом, що ми хочемо зробити, і тим, що повинено зробити комп'ютер відповідно до нашого коду.
Однак для того, щоб ясно виразити свої наміри природною мовою, нам варто зробити процес мислення свідомим, і саме в когнітивному свідомому ці протиріччя швидко стають очевидними. Навіть якщо ця гіпотеза неправильна, написання коментарів змушує нас ретельніше обмірковувати розв'язувану задачу для різних умов і з різних точок зору.
На жаль, середовища програмування були розроблені таким чином, що вносити коментарі в створювані програми не просто. Наприклад, коментарі в багатьох мовах програмування обмежуються одним рядком, а якщо многострочные коментарі припустимі, то в них часто не використовується перенос чи тексту інші можливості, що повинні бути в найпростіших текстових редакторах (виключення складають UCSD Pascal і Oberon). Щоб у мові Vіsual Basіc, що появились у 90-х роках, написати коментар розміром з абзац, вам приходиться вручну робити перенос тексту. По легендах, програмісти не особливо грамотно вміють писати, тому перевірка орфографії повинна бути включена в щосереди програмування, однак у програмних середовищах ця служба майже ніколи не зустрічається. В існуючій версії Mathematіca, що є в загальному чудовою програмою для роботи з математичними вираженнями, коментарі були прибрані з програм і поміщені в спеціальне вікно, що є зовсім неправильним кроком. Тільки деякі системи (як, наприклад, створена Батогом програма WEB (1992)) були розроблені таким чином, щоб сприяти веденню документації. Іншої, менш складний, але досить ефективний метод, був використаний автором цієї книги (Lammers, 1986, с. 226).
Для збереження працездатності програми будь-яким внесеної в неї змінам повинні передувати зміни в супровідних її коментарях. Аналогічно тому, як немає необхідності розділяти різні форми використання комп'ютера у виді додатків, програмування не повинне якось особливо відрізнятися від інших видів роботи, що користувач виконує за допомогою комп'ютера. Досвід показує, що більшість користувачів комп'ютерів з небажанням відносяться навіть до спроб програмування. Напевно, деякі переваги програмування були б більш зрозумілі, якби процес програмування був настільки інтегрований із середовищем, що окремі програмні структури могли б використовуватися без необхідності учити всю чи мову середовище програмування. Було б також корисно мати можливість комбінувати функції з різних мов, однак це не повиннео бути сумішшю, подібної PL/І, але, скоріше, повинний використовуватися метод злиття, запропонований у цій книзі для додатків. Імовірно, дуже коштовним був би варіант, у якому комбінувалися б структури LІSP для обробки списків, структури APL (чи різновиду цієї мови J) для обробки масивів, могутні методи обробки рядків з мови SNOBOL, механізми спадкування й об'єкти з Smalltalk і т.д.
Розроблювачі мов програмування й експерти по інтерфейсах занадто рідко працюють разом, і хоча когнетика дозволяє удосконалити комп'ютерні інтерфейси, випливає в максимальному ступені використовувати також сполучення сучасних методів розробки мов програмування з нашими знаннями про людський фактоpax. Це питання, що дотепер зберігає свою актуальність, був розглянутий в одній із самих ранніх книг Вейнберга в області розробки інтерфейсів людина-машина "Психологія комп'ютерного програмування" (Weіnberg, "Psychology of Computer Programmіng", опублікована в 1971 р.), що набагато випередила свій час і дотепер залишається для нас одкровенням.