Хороші посилання на приклади документації кінцевого користувача та поради [закрито]

10

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

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

Це схоже на це питання, однак я шукаю документацію для кінцевих користувачів для використання нетехнічними користувачами.

design documentation users

— Джон
джерело

1

"де я можу знайти хороші приклади документації для кінцевого користувача програмного забезпечення". Крок 1. Купіть деяке програмне забезпечення. Крок 2. Прочитайте документацію. Що заважає вам забрати документацію з існуючого програмного забезпечення, яке ви вже використовуєте? Я вважаю, що більшість пакунків для кінцевих користувачів мають повну документацію в режимі он-лайн. Що вас заважає читати документацію Microsoft для їх Office Suite?

— С.Лотт

Я вважаю, що більшість прочитаних нами документів написана таким чином, що не є привабливим для читання, і більшість моїх книг, як правило, стосуються програм, спрямованих на технічну аудиторію. Просто побачите, коли хто востаннє читав посібник Microsoft? Тому я шукав кілька натхненних прикладів.

— Джон

Хм, цікаво q.

— Грак

@John: "більшість документації". Добре. Отже, після відмови від "більшості", що залишилося? Ми не знаємо, чому ви відкидаєте частину найбільш використовуваної документації на планеті як "не привабливу для читання". Ви можете розширити свій список скарг і додати свій особистий короткий список прикладів програмної документації, що не виключається вашим тестом "не звертається до читання". Ми вас не дуже добре знаємо, тому не можемо здогадатися, чому ви маєте на увазі під "не зверненням до читання".

— S.Lott

2

Будьмо уважні, що нам не потрібні запитання з такими конкретними критеріями, що таке "добре", що це стає локалізованим і не застосовується для більшості людей. Мене не цікавлять кольорові схеми.

— JeffO

1

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

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

Деякі теми можуть охоплювати:

Цільова аудиторія
Технічні вимоги
Як встановити (якщо застосовується)
Процес (тобто яку функцію бізнесу виконує програмне забезпечення?)
Набір функцій (які функції має програмне забезпечення?)
- Ви можете мати підхід, орієнтований на завдання, до цього, наприклад, Додати користувача або Додати документ
- Ви можете мати об'єктно-орієнтований підхід, наприклад, Користувачі, Ролі
- Ви можете мати підхід на основі меню, наприклад, меню Файл, Меню перегляду
Нарешті, можливо, розділ "Майбутні функції" та "Найпоширеніші запитання" можуть виступати в ролі сховища знань вашого продукту.

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

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

Сподіваюсь, це допомагає

— funkymushroom
джерело

2

Я прочитав кілька "посібників для кінцевих користувачів" і написав їх, і думаю, що є багато елементів, які покращують їх ефективність:

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

Сподіваюся, це може бути корисним для вас.

— Ніколас
джерело

1

Ви згадуєте, що він буде використовуватися для тренувань.

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

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

Якщо ви тренувальний документ був на 1/2 таким крутим, як навчальний посібник Джоела з меркурієм, я б прочитав його. Але вам потрібен хтось із а) пристрастю до написання та б) неймовірною глибиною знань, щоб витягнути це, навіть якщо ви могли скопіювати 3 пункти вище. Сподіваюся, це спрацює.

— MikeRand
джерело

0

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

Я також просто натрапив на ReadTheDocs, який робить багато того самого, але є прийнятим рішенням.

— Пайпер Мерріам
джерело

0

Ознайомтесь з Товариством технічної комунікації (STC) . Багато їх лауреатів нагород написали загальнодоступні твори. Вони також можуть мати зразки. Ставши членом, це також забезпечить доступ до більшого обсягу інформації.

— Джим Раш
джерело