Здравствуйте.
А в чем сейчас принято хранить и разрабатывать пользовательскую документацию?
Документация для большого программного комплекса.
Нужно чтобы можно было выставлять документацию на WEB, генерить разные PDF документы по списку разделов.
Чтобы был легкий доступ к редактированию.
Открытый внутренний формат исходников.
Сейчас юзаем Help & Manual старую однопользовательскую версию.
Разработка на винде.
Здравствуйте, swame, Вы писали:
S>Здравствуйте. S>А в чем сейчас принято хранить и разрабатывать пользовательскую документацию? S>Документация для большого программного комплекса. S>Нужно чтобы можно было выставлять документацию на WEB, генерить разные PDF документы по списку разделов. S>Чтобы был легкий доступ к редактированию. S>Открытый внутренний формат исходников. S>Сейчас юзаем Help & Manual старую однопользовательскую версию. S>Разработка на винде.
Если документация для поставляемого продукта: MkDocs (material, with-pdf). Собирается как часть продукта.
Чем хорошо: markdown, простой как палка. написание документации можно легко делегировать ИИ. Он может посмотреть как работает код и напишет доки.
Скриншоты или видосики пока не знаю как его научить делать, эту часть приходится делать вручную.
Если продукт для компании, использовал DevOps (Wiki) как правило. Из плюсов что можно редактировать вживую и добавлять комментарии.
Его так же можно зачекаутить как GIT репозиторий, и делегировать написание документации ИИ.
Но вообще зависит что у заказчика есть. Confluence например туда же.
Здравствуйте, swame, Вы писали:
S>А в чем сейчас принято хранить и разрабатывать пользовательскую документацию?
Стоит почитать про DocOps. Там сейчас появились свои, современные, форматы. А с внедрением это просто пушка-бомба, когда с одного конца засовываешь в конвейер исходники и вопросы, а с другого выпадают ответы как этот код работает.
Здравствуйте, swame, Вы писали:
S>Здравствуйте. S>А в чем сейчас принято хранить и разрабатывать пользовательскую документацию?
В MS Office в режиме ревью работаешь над докой "по госту", потом в PDF перегоняешь, но надо следить чтобы все ссылки кликались и работали. Для интерактива можно сделать своего ИИ-агента и обучить.
Почему вордовый документ? Там есть замечательный режим ревью и редактирование когда можно писать комментарии прямо в исходной доке во время ревью того, что напишет техпис. S>Нужно чтобы можно было выставлять документацию на WEB, генерить разные PDF документы по списку разделов.
Не нужно. PDF качается на ПК и с него и смотрится. S>Чтобы был легкий доступ к редактированию.
Да, MS Office и грамотное версионирование продукта и доков. S>Открытый внутренний формат исходников.
Доки для пользака идут из сторей и фичей, а не из исходников. S>Разработка на винде.
Тогда вордовый док самое лучшее. Хранить можно на шаре чтобы был совместный доступ для ревью, например.
Здравствуйте, Kernan, Вы писали:
K>Здравствуйте, swame, Вы писали:
S>>Здравствуйте. S>>А в чем сейчас принято хранить и разрабатывать пользовательскую документацию? K>В MS Office в режиме ревью работаешь над докой "по госту", потом в PDF перегоняешь, но надо следить чтобы все ссылки кликались и работали. Для интерактива можно сделать своего ИИ-агента и обучить.
Все это выглядит как шаг назад к бардаку даже по сравнению Help & Manual.
K>Почему вордовый документ? Там есть замечательный режим ревью и редактирование когда можно писать комментарии прямо в исходной доке во время ревью того, что напишет техпис.
Не особо актуально.
S>>Нужно чтобы можно было выставлять документацию на WEB, генерить разные PDF документы по списку разделов. K>Не нужно. PDF качается на ПК и с него и смотрится.
Имелось в виду что один и тот же раздел из базы может переиспользоваться в разных томах документации в актуальном виде без ручного копирования.
S>>Чтобы был легкий доступ к редактированию. K>Да, MS Office и грамотное версионирование продукта и доков. S>>Открытый внутренний формат исходников. K>Доки для пользака идут из сторей и фичей, а не из исходников.
Имелись в виду исходники документации, из которых собираются PDF и онлайн а не код программы.
S>>Разработка на винде. K>Тогда вордовый док самое лучшее. Хранить можно на шаре чтобы был совместный доступ для ревью, например.
Помню писал диссер страниц всего на 500 в ворде в одиночку, даже это было довольно адово.
Здравствуйте, bnk, Вы писали:
bnk>Здравствуйте, swame, Вы писали:
S>>Здравствуйте. S>>А в чем сейчас принято хранить и разрабатывать пользовательскую документацию? S>>Документация для большого программного комплекса. S>>Нужно чтобы можно было выставлять документацию на WEB, генерить разные PDF документы по списку разделов. S>>Чтобы был легкий доступ к редактированию. S>>Открытый внутренний формат исходников. S>>Сейчас юзаем Help & Manual старую однопользовательскую версию. S>>Разработка на винде.
bnk>Если документация для поставляемого продукта: MkDocs (material, with-pdf). Собирается как часть продукта. bnk>Чем хорошо: markdown, простой как палка. написание документации можно легко делегировать ИИ. Он может посмотреть как работает код и напишет доки. bnk>Скриншоты или видосики пока не знаю как его научить делать, эту часть приходится делать вручную.
Да спасибо смотрю на это.
Но вот with-pdf как я понял из описания собирает всю базу в один документ, а надо как-то выборочно.
bnk>Пример MkDocs (Microsoft) bnk>https://pnp.github.io/pnpjs/ bnk>https://pnp.github.io/sp-dev-fx-controls-react/
bnk>Если продукт для компании, использовал DevOps (Wiki) как правило. Из плюсов что можно редактировать вживую и добавлять комментарии. bnk>Его так же можно зачекаутить как GIT репозиторий, и делегировать написание документации ИИ. bnk>Но вообще зависит что у заказчика есть. Confluence например туда же.
