Разработка инструкции пользователя программы

Содержание
  1. Разработка руководства пользователя по ГОСТ 34 и ГОСТ 19 в программе Dr.Explain
  2. Когда и у кого возникает необходимость оформления документации по ГОСТ
  3. Какие ГОСТы используются для подготовки пользовательской документации
  4. Руководство пользователя — основной документ для конечного пользователя
  5. Сложности написания руководства пользователя по ГОСТ
  6. Dr.Explain упрощает создание руководства пользователя по ГОСТ
  7. Создание нового руководства пользователя по ГОСТ
  8. Приведение существующей пользовательской документации в соответствие с требованиями ГОСТ
  9. Как написать руководство пользователя: подробная инструкция
  10. Жми на заголовки 🙂
  11. Исследуйте тему
  12. Разработайте план и напишите текст
  13. Cоздание справочной системы или руководства пользователя в Dr.Explain
  14. Руководство пользователя для пользователя
  15. Екатерина Филатова, 12.06.2006
  16. Структура руководства
  17. Краткость и стиль
  18. Выводы

Разработка руководства пользователя по ГОСТ 34 и ГОСТ 19 в программе Dr.Explain

@ Журавлев Денис

Когда и у кого возникает необходимость оформления документации по ГОСТ

Многие IT-компании, которые занимаются разработкой и сопровождением программного обеспечения и автоматизированных комплексов, сталкиваются с задачей создания пользовательской документации для своих продуктов в соответствии с требованиями ГОСТ.

Как правило, необходимость в наличии документации по ГОСТ возникает при сотрудничестве с государственными организациями, крупными производствами и компаниями, при заказной разработке программного обеспечения по тендерам и госзаказам или при необходимости добавить программный продукт в «Единый реестр российских программ для электронных вычислительных машин и баз данных (реестр отечественного ПО)».

Какие ГОСТы используются для подготовки пользовательской документации

Существует две серии (набора) стандартов, которые регламентируют набор создаваемых документов и правила их оформления при разработке автоматизированных систем, комплексов и программного обеспечения:

  • ГОСТ 34 — Автоматизированные системы
  • ГОСТ 19 — Единая система программной документации (ЕСПД)

С одной стороны, эти два стандарта конкурируют между собой, предлагаю различные варианты комплектности документации на проект. С другой стороны, они фокусируются на разных аспектах, и поэтому хорошо дополняют друг друга.
ГОСТ 34 главным образом определяет комплектность, виды, структуру и содержание создаваемых документов.
ГОСТ 19 в большей степени определяет правила оформления документов.
Поэтому, на практике часто используются сразу оба этих ГОСТа.

Руководство пользователя — основной документ для конечного пользователя

Если говорить именно о документации для конечного пользователя системы, то из перечня описываемых в ГОСТ 34 документов нас интересует «Руководство пользователя». В ГОСТ 19 аналогичный по смыслу документ называется «Руководство оператора», но для программного обеспечения чаще используется именно первый вариант.

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

Сложности написания руководства пользователя по ГОСТ

Для начинающего технического писателя или простого специалиста, которому неожиданно поручили подготовить руководство пользователя по ГОСТ, эта задача является серьезной проблемой.

Мало того, что необходимо изучить большое число нормативных документов, изобилующих перекрестными ссылками и написанных сложным, излишне канцелярским, почти юридическим языком, так еще необходимо выбрать оттуда требования, относящиеся именно к создаваемому виду документа. Затем, на протяжении всей работы, нужно постоянно контролировать соблюдение этих требований в рабочем документе, постоянно сверяясь со стандартами.

Обычно проблема усугубляется еще и нехваткой времени, так как писать пользовательскую документацию, к сожалению, часто принято в самом конце проекта, перед самым дедлайном — датой сдачи или запуска системы.

У опытного технического писателя документирование по ГОСТ, возможно, не вызовет серьезных затруднений. Однако, даже у него подготовка шаблонов новых документов, приведение к требованиями стандартов существующей документации или проверка финального документа на соответствие этим требованиям может занять существенное время.

Dr.Explain упрощает создание руководства пользователя по ГОСТ

Начиная с версии 5.5.1100 программа для создания пользовательской документации Dr.Explain предлагает функцию автоматизированной поддержки ГОСТ в проектах. Эта функция призвана значительно облегчить жизнь пользователям, перед которыми стоит задача создания руководства пользователя в соответствии с требованиями государственных стандартов.

В частности программа Dr.Explain контролирует и автоматизирует поддержку следующих требований стандартов:

  • Наличие обязательных разделов документа “Руководство пользователя” [ГОСТ 34 РД 50-34.698-90]. Все разделы снабжаются пояснениями по их содержанию.
  • Оформление титульных листов, аннотации и содержания [ГОСТ 19.105-78, 19.104-78].
  • Параметры печатных страниц документа и расположение основных элементов на них [ГОСТ 19.106-78].
  • Структуру и оформление колонтитулов [ГОСТ 19.106-78].
  • Оформление текстовой части документа: стили шрифтов, абзацные отступы, межстрочные интервалы [ГОСТ 19.106-78].
  • Формирование и оформление заголовков, разделов, перечислений (списков) [ГОСТ 19.106-78].

Управление функцией поддержки ГОСТ для проекта доступно в Настройках проекта в разделе Общие.

При включенном режиме поддержки ГОСТ для проекта соответствующие пользовательские настройки для печатаемых форматов RTF\DOC и PDF автоматически перекрываются программой, что гарантирует полное соответствие параметров выходных документов требованиям стандартов.

Для выходных форматов HTML и CHM будут использоваться пользовательские настройки вне зависимости от активности режима поддержки ГОСТ. Это снимает ограничение на свободную стилизацию этих форматов и позволяет, например, оформить онлайн-справку полностью в корпоративном или тематическом стиле.

Важно: Перед включением режима поддержки ГОСТ для уже существующих в формате Dr.Explain проектов необходимо сделать резервную копию gui-файла проекта.

Важно: Функция поддержки ГОСТ доступна в Dr.Explain только в русскоязычной версии интерфейса. Язык интерфейса программы выбирается в меню Настройки\Выбор языка программы (Options\Application language).

Создание нового руководства пользователя по ГОСТ

Для создания нового руководства пользователя по требованиям ГОСТ 34 в программе Dr.Explain можно использовать команды меню Файл \ Создать локальный проект — Руководство пользователя по ГОСТ 34 или Файл \ Создать общий проект на tiwri.com — Руководство пользователя по ГОСТ 34

или аналогичные кнопки на стартовом экране приложения.

Программа создаст новый проект, в котором уже присутствуют шаблон титульного листа, аннотация, оглавление и обязательные разделы, оформленные по ГОСТ.

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

Настройки оформления для печатных форматов RTF/DOC и PDF будут выставлены в соответствии с требованиям ГОСТ 19.

Приведение существующей пользовательской документации в соответствие с требованиями ГОСТ

Также программа Dr.Explain позволяет привести существующую пользовательскую документацию в соответствии с требованиями ГОСТ.

Важно: Перед включением режима поддержки ГОСТ для уже существующих в формате Dr.Explain проектов необходимо сделать резервную копию gui-файла проекта.

Если исходная документация еще не ведется в Dr.Explain, а хранится в других форматах, первым шагом необходимо выполнить импорт существующих документов в программу. Dr.Explain поддерживает импорт документов из ряда популярных форматов. Команды импорта доступны как на стартовом окне программы, так и в меню Файл.

Затем необходимо включить режим поддержки ГОСТ в свойствах проекта описанным ранее способом. Программа проверит структуру документа на наличие обязательных разделов и, если они отсутствуют, создаст их. Остальные существующие разделы, наличие которых не регламентировано ГОСТами, будут перенесены в скрытый от экспорта раздел “Старое дерево разделов”.

Читайте также:  Amica eco 40 инструкция

Пользователь должен будет перенести содержимое этих разделов или разделы целиком методом drag-n-drop в основное дерево проекта и отредактировать их по необходимости.

Как и в первом случае настройки оформления для печатных форматов RTF/DOC и PDF будут выставлены в соответствии с требованиям ГОСТ 19.

Источник

Как написать руководство пользователя: подробная инструкция

Руководство пишется для того, чтобы помочь людям использовать технику, мебель, транспорт и т. д. Пишется максимально простым и доступным языком, чтобы было понятно человеку с любым уровнем интеллекта. Как хорошо писать классическое руководство я поэтапно расскажу в статье.

Топовую подборку профессиональных курсов от ведущих школ: обучение копирайтингу с нуля

Жми на заголовки 🙂

Исследуйте тему

Чтобы автору написать понятное руководство ему нужно самому хорошо разбираться в теме. Неважно — являетесь вы экспертом в области или нет, нужно обязательно прочитать информацию из разных источников. Или ещё раз освежить материал в памяти.

Чтобы инструкция получилась полезной копирайтеру нужно разбираться в отрасли на 100%, но описывать её с позиции новичка. То есть ставить себя на место читателя. Прочитайте аналогичные статьи на похожие товары. Это поможет вам лучше разобраться в структуре и стиле такого контента.

Разработайте план и напишите текст

После тщательного изучения материала можно приступать к планированию. Продумайте, с чего лучше начать и чем продолжить. На примере инструкции к пылесосу «Xiaomi mi robot vacuum cleaner» я расскажу о принципах написания такого текста.

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

Опишите сначала азы (описание программы, техники), затем усложняйте текст (как исправить ошибки при работе с продуктом).

Не пишите специальные термины, понятные только узкому кругу читателей. Текст должен быть понятен любому. Если без этого никак — распишите каждый термин понятным языком.

Не используйте в работе личное мнение или собственный опыт пользования товаром. Инструкция — это документ, в котором структурно и чётко описаны шаги и действия.

Добавляйте в статью скриншоты. Наглядно понять работу программы или техники намного проще.

Пишите даже те моменты, которые кажутся очевидными и понятными без описания. Они понятны вам. Но не факт что и всем остальным тоже.

Пишите текст короткими предложениями с глаголами повелительного наклонения: «Включите компьютер», «Нажмите на кнопку…», «Включите в розетку…».

Придерживайтесь логики и будьте последовательны. Например, при описании программного обеспечения для ПК: «Включите компьютер. Вставьте диск в дисковод…». Будет нелогично писать: «Начните работу с диском, затем включите ПК». Завершайте инструкцию ответами на частые вопросы и/или описанием неисправностей и как их устранить.

После того как статья будет готова — дайте её прочитать другу или знакомому, и спросите, насколько она понятна. Так вы сможете исправить недочёты и испытать ваш текст в действии.

Источник

Cоздание справочной системы или руководства пользователя в Dr.Explain

image

Всем привет. Наверное, любой разработчик на вопрос, что вам больше всего не нравится в процессе разработки, ответит: «написание документации» или упомянет об этом в самом начале списка проблем. В документировании действительно ничего интересного нет, но, тем не менее, руководство пользователя, как я уже писал в своем первом посте на Хабре, является важным компонентом любого профессионального продукта. Плохо составленная документация будет не только препятствием на пути привлечения новых покупателей, но и является большим минусом к имиджу продукта и разработчика.

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

Сам иногда занимаюсь help-файлами и не понаслышке знаю, что создание справочной системы занимает время и является кропотливой и нудной работой, особенно документирование интерфейса. Однако пару месяцев назад открыл для себя инструмент, который значительно ускоряет этот процесс. Речь идет о программе Dr.Explain от самарской компании Индиго Байт Системз. Она мне понравилась продуманным интерфейсом и возможностью документировать интерфейс ПО в полуавтоматическом режиме.

Dr.Explain vs. Help and Manual

Итак, Dr.Explain позволяет создавать help-файлы в формате CHM для поставки вместе с приложением, справочные системы в HTML для размещения на сайте продукта, а также руководства пользователя в RTF и в PDF с оглавлениями и ссылками. Справочная система генерируется в разных форматах из единого источника, что позволяет быстро обновлять документацию при выходе новых версий ПО. В этом плане Dr.Explain ничем не отличается от Help and Manual, которой я давно пользуюсь.

Интерфейс состоит из двух областей. Первая – это панель навигации с древовидной структурой содержания проекта. А вторая – редактор страниц.

image

В дереве задается вся структура help-файла, включая заголовки папок и страниц. Редактор страниц состоит из стандартных инструментов для написания и форматирования текста, а также имеются инструменты для вставки гиперссылок, картинок, таблиц и переменных. Все это есть и в Help and Manual, но панель инструментов в Dr.Explain скомпонована, на мой взгляд, более продуманно.

image

Рисунок 1. Панель инструментов Dr.Explain

image

Рисунок 2. Панель инструментов Help and Manual

Главная фишка Dr.Explain – это автоматизация самого трудоемкого процесса документирования – создание аннотаций пользовательского интерфейса. Да, вы правильно меня поняли. Больше не нужно делать снимки экрана самому, рисовать выноски и стрелки, вставлять все это хозяйство в проект вручную – программа сама сделает снимок любой части интерфейса по вашему выбору, проанализирует и найдет (сама!) все значимые элементы (кнопки, элементы управления, списки), вставит снимок в проект справки и автоматически расставит стрелки и пояснительные выноски к изображениям. Пользователю остается всего лишь ввести краткое пояснение к каждой выноске и все.

Кроме того, к выноскам можно добавить и более подробные пояснения. Для всех выносок программа автоматически сгенерирует симпатичную на вид табличку, которая будет размещаться ниже скриншота с выносками и может включать в себя все эти подробные пояснения.

Такое полуавтоматическое документирование интерфейса значительно ускоряет и облегчает создание справочной системы, т.к. разработчику остается всего лишь добавить свои описания в выноски. В Help and Manual я все это тоже могу сделать – правда, придется делать это вручную. Обычно я делаю снимки окон в Snagit, обрабатываю края снимка, добавляю тень, рисую стрелки. А для документирования элементов окна вручную создаю табличку, нарезаю снимки кнопок и контролов, обрабатываю их края и вставляю в проект, а затем пишу описания каждой выноски. На это тратится уйма времени и усилий.

Читайте также:  Мирамистин инструкция детям со скольки лет
Кое-что еще…

В Dr.Explain есть и другие полезные возможности, которых, к сожалению, нет в Help and Manual. Например, есть удобный режим просмотра проекта – одним кликом по соответствующей кнопке можно быстро посмотреть, как будет выглядеть справка в формате CHM или HTML после компиляции. Превью открывается прямо в окне редактора. Поверьте, это очень удобно. Однако нет PDF-превью – это минус. В Help and Manual чтобы посмотреть, как выглядит справка, нужно постоянно компилировать проект.

image

Также в программе есть возможность интегрировать контекстно-зависимую справку прямо в приложение (F1), управление деревом навигации, набор шаблонов оформления, поддержка CSS, возможность быстрого обновления документации при выходе новой версии программы путем замены иллюстраций, но с сохранением выносок, аннотаций, описаний; функция поиска и индексации в онлайн-справке без программирования (PHP, ASP) или баз данных на стороне сервера.

Источник

Руководство пользователя для пользователя

Екатерина Филатова, 12.06.2006

Vlad Golovach

Известно, что пользователи часто даже не заглядывают в инструкции, прилагаемые к программным продуктам, предпочитая постигать все премудрости работы программы на практике. Получается, что руководство, призванное помочь пользователю, никак не облегчает его жизнь, а многие полезные функции программного продукта так и остаются недопонятыми и невостребованными. Почему так происходит?

Очевидны две базовые проблемы. Авторы руководств:

  • традиционно придерживаются принципа, что пользователи не читают инструкций.
  • исходят из принципа «мы описываем программный продукт», не учитывая того, что пользователь и его задачи гораздо важнее.

Выход прост, но используется лишь частично: создаваемое руководство пользователя должно соответствовать своему названию — объяснять и помогать, а не просто описывать функциональность программы. То есть автору руководства следует хорошо представлять себе:

  • как человек будет использовать программный продукт,
  • какие трудности заставят его обратиться к тексту инструкции.

И с учетом этих представлений создавать текст руководства.

Главными составляющими качества руководства пользователя, безусловно, являются его структура и собственно текст. И от того, насколько эти составляющие отвечают нуждам пользователя, зависит качество всего руководства.

Структура руководства

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

Заглянув в такое руководство и потратив впустую некоторое время, пользователь вряд ли воспользуется им вновь. Поэтому очевидно, что:

  1. Руководство должно в первую очередь иметь простую и четкую структуру, построенную в зависимости от назначения и применения программного продукта. То есть отвечать на вопросы: что это за продукт, кому и когда он нужен, как с ним работать: установка и настройка, перечень решаемых задач и оптимальные способы их реализации, способы решения возможных проблем.
  2. При создании структуры руководства следует исходить из нужд и потребностей пользователя программного продукта, так, чтобы, открыв содержание, пользователь мог без труда найти ответ на искомый вопрос. А обнаружив нужное, получил исчерпывающую информацию, как решить свою задачу, когда и зачем использовать ту или иную функциональность программы.
  3. Поскольку пользователь вряд ли будет полностью читать руководство, а будет лишь просматривать нужные разделы, то каждый раздел должен быть автономен и давать всю информацию по данному вопросу.

Попробуем применить эти принципы к конкретному руководству. Проанализируем структуру руководства пользователя для работы с Автоматизированной информационно-аналитической системой «Библиотека». Его содержание:

  • Введение
  • Программа «Библиотека» позволяет Технические требования Установка программы Особенности работы с модулем «Рабочее место библиотекаря»
  • Описание программы
  • Введение Общая концепция данных в АИАС «Библиотека» С чего начать? Составление списка сотрудников и читателей Источники поступления Оформление поступления Акт поступления Распределение документов по подразделениям и формам индивидуального учета Книга суммарного учета Книга индивидуального учета Поиск и редактирование документов
  • Поиск Редактирование Замена Выбытие Выдача
  • Реестр актов Акт проверки фонда Акт замены Акт выбытия Тетрадь замены документов Словарь Справочник
  • Общие положения Поиск и редактирования Добавление нового описания Указание списка авторов Копирование записи Импорт данных Утилиты по работе с базой
  • План работы Абонемент Классы
  • Создание класса Работа с классами Выдача классам Выдача ученикам Выдача через таблицу Формирование таблицы
  • Статистика Печать Справка

Как видно, структура этого руководства довольно большая и нечеткая, формулировки расплывчаты, разделы дублируют друг друга. Рассмотрим наиболее характерные ошибки и способы их решения:

  1. Целых три раздела: Программа «Библиотека» позволяет, Введение и Общая концепция данных в АИАС «Библиотека» по-разному описывают одно и то же — задачи и возможности программы Библиотека. Зачем дробить и удлинять структуру? Будет проще и логичнее объединить их один раздел.
  2. В разделе Особенности работы с модулем «Рабочее место библиотекаря» можно отметить целых две проблемы. Во-первых, из содержания непонятно, что это за модуль и откуда он взялся. Во-вторых, в разделе описывается не особенность работы с этим модулем, а процесс его установки. Получается, что автор сознательно запутывает пользователя и даже обманывает, заставляя самостоятельно разбираться в проблеме. Эту информацию следует перенести в раздел, описывающий процесс установки.
  3. Раздел Установка программы рассказывает, что данный программный продукт состоит из четырех отдельно устанавливаемых модулей. Как устанавливать эти модули неясно, и лишь информация об установке одного модуля выносится в отдельную главу. Логичнее рассказать пользователю о модулях в разделе, посвященном описанию самой программы, а в разделе Установка рассказать об особенностях установки.
  4. Заголовок Описание программы не совсем уместен, поскольку описание программы есть в начале руководства, далее необходимо рассказать пользователю о том, как собственно работать с этой программой. Получается, что заголовок дезинформирует пользователя. Это явная ошибка.
  5. Все три раздела С чего начать?, Составление списка сотрудников и читателей, Источники поступления повествуют о необходимых настройках программы перед началом работы, а именно: регистрации учреждения, формировании подразделений, форм учета и списка читателей, сотрудников и источников поступления. Эти действия необходимо совершить один раз и затем лишь вносить изменения. Поэтому совершенно непонятно, зачем автор руководства делит эту информацию на разные разделы.
  6. После завершения всех настроек пользователь может начинать работать. Соответственно в руководстве пользователя далее помещается информация, как работать с документами, абонементом и классами, а также вести учет.
  7. Раздел Справочник. Неверное название вводит пользователя в заблуждение. Из содержания неясно, что это и есть База шаблонов библиографических описаний, которая поставляется вместе с программным продуктом, о чем говорится в описании к программе. Пользователь должен знать, что ему не требуется вносить описания вручную, а только пользоваться шаблонами.
  8. Все Акты и Реестр Актов относятся к специальной базе данных учетных форм, списков, реестров, предусмотренной программным продуктом. Об этом также говорится в описании к программе, и логичнее объединить соответствующие главы в один раздел, посвященный работе по учету информации.
  9. Разделы Словарь и Справка вполне можно объединить в раздел Справочная информация или хотя бы перенести Словарь в конец руководства.
  10. И, наконец, не во всех разделах присутствует информация о том, чем этот раздел полезен пользователю, для чего, когда и как лучше его использовать. Это обстоятельство, вкупе с нечеткой структурой и расплывчатыми формулировками, сильно затруднит освоение программного продукта пользователем.
Читайте также:  Инструкция применения кофемашины крупс

С учетом обозначенных замечаний получаем более простую и логичную структуру руководства:

  • Задачи и возможности программы «Библиотека»
  • Технические требования
  • Установка программы
  • Настройка программы
  • Работа с программой
  • Работа с документами
  • Оформление поступлений Поиск Редактирование Замена Выбытие Выдача Распределение документов по подразделениям и формам индивидуального учета
  • Учет документов
  • Реестр актов Акт поступления Акт проверки фонда Акт замены Акт выбытия Книга суммарного учета Книга индивидуального учета
  • База шаблонов библиографических описаний
  • Поиск и редактирования Добавление нового описания Указание списка авторов Копирование записи Импорт данных Утилиты по работе с базой
  • Планирование работы Абонемент Классы Статистика Печать
  • Справочная информация

Приведенное в качестве примера руководство вполне обычно. Инструкций подобного качества, к сожалению, множество. Собственно именно это и заставляет многих авторов и пользователей считать, что руководство пишется ради самого руководства («чтобы было»), и никто его не читает. Но эту ситуацию вполне можно изменить.

Безусловно, помимо правильной разбивки текста существуют и другие важные условия, необходимые для создания практичного руководства, например:

  • Обязательные правила и моменты, требующие особого внимания пользователя, следует выделять в тексте.
  • Текст желательно снабдить перекрестными ссылками так, чтобы при необходимости пользователь не мучился в поисках упомянутого термина.
  • Верстка руководства должна быть удобной для пользователя.
  • При необходимости текст следует сопровождать соответствующими тексту иллюстрациями.

Игнорирование любой из этих деталей способно испортить руководство и затруднить восприятие текста пользователем. Однако здесь нужно не перестараться и не перегрузить текст лишними деталями. Пестрящий подчеркиваниями, предупреждениями и ссылками текст рассеивает внимание читателя. Обо всех особенностях текста и верстки необходимо рассказать пользователю в начале руководства.

Краткость и стиль

Хорошее руководство пользователя отличается не только продуманной структурой, но и качеством текста. Установленных критериев здесь нет, так же как нет единого стиля. Главные принципы — текст руководства должен давать пользователю четкие и исчерпывающие ответы, не перегружать читателя лишними и не нужными ему техническими деталями, легко читаться и быть грамотным.

Как применить эти принципы на практике рассмотрим на примерах с типичными ошибками.

Список может содержать информацию ссылочного типа. Стандартным действием для просмотра этой информации является нажатие клавиши Enter для выбранной строки списка. В том случае, когда для ссылочной информации предусмотрен режим редактирования в отдельной форме, открывается эта форма. Если информация для списка находится в состоянии «Только просмотр» (не разрешено редактирование), то информация в открываемой форме тоже будет недоступна для редактирования.

Это тяжело читаемый, слишком большой и стилистически неправильный текст, отдающий канцеляризмом. В него приходится вчитываться, чтобы понять, о чем же идет речь. Пользователю придется потратить много сил, чтобы выудить из такого руководства нужную информацию. А ведь достаточно всего лишь сообщить, что пункты списка могут быть ссылками, ведущими на отдельную форму с подробной информацией, а также объяснить, в каких ситуациях и для чего он может менять эту информацию.

Пользователей в системе могут заводить администраторы или руководители подразделений. Существует еще один способ заведения пользователей в системе. Пользователь может сам подать заявку на регистрацию, которая должна быть одобрена администратором.

Расплывчатая формулировка с повторами, не объясняющая разницу в регистрации. Следует указать, что существуют именно два способа, и разъяснить когда именно применяется каждый их них.

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

Нет нужды изъясняться так длинно и витиевато, к тому же это предложение несогласованно. Достаточно написать Перед началом работы установите параметры, соответствующие вашей организации.

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

Лишние и вводные слова затрудняют восприятие текста. Кроме того, создается впечатление, что автор сам не уверен в написанном. Здесь хранится вся учетная информация: акты документы, формы и т.д.

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

Такой шаблонно-бюрократический текст не только непонятен, но и отпугивает пользователя. Руководство, написанное похожим языком, вряд ли когда-либо будут читать. Фраза Перед началом работы выполните следующие действия проще в разы.

Для возможности составления акта поступления литературы необходимо составить список источников поступления.

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

Для работы с программой необходимо, чтобы в базе данных было зарегистрировано ваше учреждение, были назначены подразделения библиотеки, было сформировано строение книг суммарного и индивидуального учета, был подготовлен список читателей.

Элементарные грамматические ошибки или обычные недочеты, как в данном случае — многократное повторение слова «было», не добавят доверия к руководству и его автору.

Выводы

Итак, если руководство пользователя создается для пользователя, а не для описания программного продукта, оно должно отвечать нескольким требованиям:

  • Главная персона в руководстве всегда пользователь и его запросы при работе с данным продуктом. Руководство не должно обманывать его ожидания. Оно должно отвечать на вопросы, а не заставлять читать описания интерфейса программы.
  • Четкость характеристик. Пользователю необходимо ясно объяснить не только как совершить то или иное действие, но и как лучше это сделать, когда лучше, для чего и к чему это приведет. В этом случае пользователь лучше сможет ориентироваться в программном продукте и использовать его по максимуму. Расплывчатые и непонятные формулировки здесь неуместны!
  • Краткость текста. Текст должен быть небольшим и легко читаться. Нужно избегать тяжеловесных форм с многочисленными причастными или деепричастными оборотами, вводными словами и т.д. И нельзя заставлять пользователя читать лишние детали. Пользователь не должен тратить время на длинные и зачастую ненужные описания.
  • Стилистически и грамматически правильный текст. Грамотный текст облегчает восприятие текста и повышает доверие пользователя к руководству.

Источник

Поделиться с друзьями
Adblock
detector