Size: a a a

technicalwriters

2020 November 11

NV

Nick Volynkin in technicalwriters
Я даже добавлю, что писателю не надо с разработчиками разговаривать. Пишешь — и пиши, не трать время на болтовню. И с читателями не надо, их дело читать, а наше — писать.
источник

MC

Milkhail Che in technicalwriters
что-то вы совсем перегибаете
источник

MC

Milkhail Che in technicalwriters
пасив агрешн
источник

NV

Nick Volynkin in technicalwriters
:)
источник

MC

Milkhail Che in technicalwriters
если в HaT я могу парой кликов добавить условия и переменные, то в DaC нужно открывать файлы и править их.
Тупо экономичнее
источник

НО

Наталья Орлова... in technicalwriters
Nick Volynkin
Я даже добавлю, что писателю не надо с разработчиками разговаривать. Пишешь — и пиши, не трать время на болтовню. И с читателями не надо, их дело читать, а наше — писать.
Чукча не читатель, чукча писатель!
источник

MS

Maria Shabanova in technicalwriters
Nick Volynkin
Я даже добавлю, что писателю не надо с разработчиками разговаривать. Пишешь — и пиши, не трать время на болтовню. И с читателями не надо, их дело читать, а наше — писать.
Долой болтовню!
источник

FM

Fox Mulder in technicalwriters
You are technical/like working in scripting languages/etc. or have a dedicated technical resource - Кто сказал, что быть умным плохо. Еще 20 лет назад компьютеры были уделом малого круга людей. Сейчас, на смену ворда идут другие системы. Мозг нужен всегда.
=
You’re comfortable with using Git/GitHub - прекрасная система отслеживания изменений. Плюс автоматизация.
=
Your company/product is developer-centric (APIs, etc.) DAC полезен и в продуктовых командах. Вопрос только в команде, будут ли они исповедовать новые парадигмы.
=
Developers will be providing or directly editing the documentation - Вся команда должна писать документацию. Взваливание процесса документирования всех аспектов продукта на техписа не приводит ни к чему хорошему.
==
You want more control over consistency/presentation - Дело в том, что это не так. Для DAC разработаны плагины, которые позволяют батчем креейтить теже презентации pptx.
==
You are not very technical or do not have time/resources to do the technical work - Не согласен как человек, который работал с HAT. Уровень технического вхождения крайне высок, я бы даже написал, что выше чем в DAC. Тем более, что и DAC, и HAT из коробки позволяют делать документацию сходного уровня. Всё что сверх требует очень глубоких познаний. Пример, xslt.
==
You need to use an existing CMS - Все эти CMS крайне дОроги. А если вы еще выпускаете pdf, то рано или поздно вы придётё к осознанию. что apache-fop вам не подходит и надо покупать очень дорогие процессоры.
==
You need to publish to several different formats/sites or integrate with an existing system like Zendesk or Confluence - В Confluence можно лить и DAC, на сегодняшний день это не является чем то сложным. Что же касается sites or integrate, то современные версии HAT тоже могут.
==
Your Engineering is outsourced/contracted/unable to contribute - Тут да, подключить к HAT внешних контрибьюторов тяжело.
===
Use a HAT (or other approaches) if you expect to do all the writing, if you’re not comfortable using Git/GitHub - Современные HAT также взаимодействуют с git, так что разбираться придется, только в HAT это реализовано сложнее чем в DAC.
===
Help Authoring Tools (HATs) and larger documentation tool suites are better able to enforce templates and standards (DITA/DocBook) and style guide considerations (cross reference format, layout, etc.) - Дело в том, что ни в DITA, ни тем более в DocBook не вкладываются какие-либо значимые ресурсы сообщества, форматы не развиваются и на сегодняшний день выглядят устаревшими, проприетарными и очень дорогими.
источник

MC

Milkhail Che in technicalwriters
с некоторыми пунктами поспорил бы, но не буду ленту засорять)
Ввести бы тут комменты.
источник

FM

Fox Mulder in technicalwriters
Milkhail Che
с некоторыми пунктами поспорил бы, но не буду ленту засорять)
Ввести бы тут комменты.
А можно узнать с какими?
источник

ET

Eduard Tibet in technicalwriters
Milkhail Che
если в HaT я могу парой кликов добавить условия и переменные, то в DaC нужно открывать файлы и править их.
Тупо экономичнее
ХАТ, если вы про оффлайн, а не клауд, не является кросс-платформенным. Во всяком случае, Флер только под виндой, эксплейн - тоже. Наверное, единицы есть под мак. А под линукс - совсем ничего.
источник

MC

Milkhail Che in technicalwriters
"Вся команда должна писать документацию" — это как говнокод чужой переделывать, проще заново написать, а лучше допросить и самому написать.

"Уровень технического вхождения крайне высок, я бы даже написал, что выше чем в DAC" — сколько надо собак скушать, чтоб поставтиь ДАК, настроить стили и шаблоны, в том же HelpandManual интерфейс почти как в ворде.

"Современные HAT также взаимодействуют с git, так что разбираться придется, только в HAT это реализовано сложнее чем в DAC." — Не понял, в чём сложность: и там и тут исходники, делаешь чекаут, диф, сабмиты.

"Дело в том, что ни в DITA, ни тем более в DocBook не вкладываются какие-либо значимые ресурсы сообщества" — так дита этож вроде самый что ни на есть ДАК, нет?
источник

ET

Eduard Tibet in technicalwriters
Fox Mulder
You are technical/like working in scripting languages/etc. or have a dedicated technical resource - Кто сказал, что быть умным плохо. Еще 20 лет назад компьютеры были уделом малого круга людей. Сейчас, на смену ворда идут другие системы. Мозг нужен всегда.
=
You’re comfortable with using Git/GitHub - прекрасная система отслеживания изменений. Плюс автоматизация.
=
Your company/product is developer-centric (APIs, etc.) DAC полезен и в продуктовых командах. Вопрос только в команде, будут ли они исповедовать новые парадигмы.
=
Developers will be providing or directly editing the documentation - Вся команда должна писать документацию. Взваливание процесса документирования всех аспектов продукта на техписа не приводит ни к чему хорошему.
==
You want more control over consistency/presentation - Дело в том, что это не так. Для DAC разработаны плагины, которые позволяют батчем креейтить теже презентации pptx.
==
You are not very technical or do not have time/resources to do the technical work - Не согласен как человек, который работал с HAT. Уровень технического вхождения крайне высок, я бы даже написал, что выше чем в DAC. Тем более, что и DAC, и HAT из коробки позволяют делать документацию сходного уровня. Всё что сверх требует очень глубоких познаний. Пример, xslt.
==
You need to use an existing CMS - Все эти CMS крайне дОроги. А если вы еще выпускаете pdf, то рано или поздно вы придётё к осознанию. что apache-fop вам не подходит и надо покупать очень дорогие процессоры.
==
You need to publish to several different formats/sites or integrate with an existing system like Zendesk or Confluence - В Confluence можно лить и DAC, на сегодняшний день это не является чем то сложным. Что же касается sites or integrate, то современные версии HAT тоже могут.
==
Your Engineering is outsourced/contracted/unable to contribute - Тут да, подключить к HAT внешних контрибьюторов тяжело.
===
Use a HAT (or other approaches) if you expect to do all the writing, if you’re not comfortable using Git/GitHub - Современные HAT также взаимодействуют с git, так что разбираться придется, только в HAT это реализовано сложнее чем в DAC.
===
Help Authoring Tools (HATs) and larger documentation tool suites are better able to enforce templates and standards (DITA/DocBook) and style guide considerations (cross reference format, layout, etc.) - Дело в том, что ни в DITA, ни тем более в DocBook не вкладываются какие-либо значимые ресурсы сообщества, форматы не развиваются и на сегодняшний день выглядят устаревшими, проприетарными и очень дорогими.
Про "проприетарные" форматы не совсем согласен. Ибо это даже не форматы, а стандарты (да, да, со всеми атрибутами стандартов). И не может быть проприетарным то, что является открытым стандартом. А то, что не развиваются - это смотря в какой области. Допустим, дита сейчас идет в область Industry 4.0 - там docs-as-code ни к чему, а вот profiling и самантический контекст, автоматические каталоги - т.п.  в самый раз. И не забываем, что SaaS Paligo - достаточно известная и популярная - сделана именно на основе DocBook (5.0/5.1).
источник

FM

Fox Mulder in technicalwriters
Milkhail Che
"Вся команда должна писать документацию" — это как говнокод чужой переделывать, проще заново написать, а лучше допросить и самому написать.

"Уровень технического вхождения крайне высок, я бы даже написал, что выше чем в DAC" — сколько надо собак скушать, чтоб поставтиь ДАК, настроить стили и шаблоны, в том же HelpandManual интерфейс почти как в ворде.

"Современные HAT также взаимодействуют с git, так что разбираться придется, только в HAT это реализовано сложнее чем в DAC." — Не понял, в чём сложность: и там и тут исходники, делаешь чекаут, диф, сабмиты.

"Дело в том, что ни в DITA, ни тем более в DocBook не вкладываются какие-либо значимые ресурсы сообщества" — так дита этож вроде самый что ни на есть ДАК, нет?
"Дело в том, что ни в DITA, ни тем более в DocBook не вкладываются какие-либо значимые ресурсы сообщества" — так дита этож вроде самый что ни на есть ДАК, нет? - По моим знаниям - нет. DIta выросла из DocBook и является апологетом стандарта Dita-OT. DAC исповедует другие принципы.
=
"Уровень технического вхождения крайне высок, я бы даже написал, что выше чем в DAC" — сколько надо собак скушать, чтоб поставтиь ДАК, настроить стили и шаблоны, в том же HelpandManual интерфейс почти как в ворде. - А если надо на выходе получить pdf или html не в дефолтном формате? Значит надо лезть внутрь и делать стили. Как человек, который это делал, напишу - это не так и просто.
=
"Вся команда должна писать документацию" — это как говнокод чужой переделывать, проще заново написать, а лучше допросить и самому написать. - Думал. Вот сейчас у нас девопс описывает стенд. Я могу поднять тестовую площадку, но это займет у меня гораздо больше времени, чем у него. Попутно девопс пишет процесс. Скорее мне БЫСТРЕЕ взять уже готовый материал и поправить. Но тут каждому своё, не настаиваю.
источник

CV

Cro Vin in technicalwriters
Fox Mulder
You are technical/like working in scripting languages/etc. or have a dedicated technical resource - Кто сказал, что быть умным плохо. Еще 20 лет назад компьютеры были уделом малого круга людей. Сейчас, на смену ворда идут другие системы. Мозг нужен всегда.
=
You’re comfortable with using Git/GitHub - прекрасная система отслеживания изменений. Плюс автоматизация.
=
Your company/product is developer-centric (APIs, etc.) DAC полезен и в продуктовых командах. Вопрос только в команде, будут ли они исповедовать новые парадигмы.
=
Developers will be providing or directly editing the documentation - Вся команда должна писать документацию. Взваливание процесса документирования всех аспектов продукта на техписа не приводит ни к чему хорошему.
==
You want more control over consistency/presentation - Дело в том, что это не так. Для DAC разработаны плагины, которые позволяют батчем креейтить теже презентации pptx.
==
You are not very technical or do not have time/resources to do the technical work - Не согласен как человек, который работал с HAT. Уровень технического вхождения крайне высок, я бы даже написал, что выше чем в DAC. Тем более, что и DAC, и HAT из коробки позволяют делать документацию сходного уровня. Всё что сверх требует очень глубоких познаний. Пример, xslt.
==
You need to use an existing CMS - Все эти CMS крайне дОроги. А если вы еще выпускаете pdf, то рано или поздно вы придётё к осознанию. что apache-fop вам не подходит и надо покупать очень дорогие процессоры.
==
You need to publish to several different formats/sites or integrate with an existing system like Zendesk or Confluence - В Confluence можно лить и DAC, на сегодняшний день это не является чем то сложным. Что же касается sites or integrate, то современные версии HAT тоже могут.
==
Your Engineering is outsourced/contracted/unable to contribute - Тут да, подключить к HAT внешних контрибьюторов тяжело.
===
Use a HAT (or other approaches) if you expect to do all the writing, if you’re not comfortable using Git/GitHub - Современные HAT также взаимодействуют с git, так что разбираться придется, только в HAT это реализовано сложнее чем в DAC.
===
Help Authoring Tools (HATs) and larger documentation tool suites are better able to enforce templates and standards (DITA/DocBook) and style guide considerations (cross reference format, layout, etc.) - Дело в том, что ни в DITA, ни тем более в DocBook не вкладываются какие-либо значимые ресурсы сообщества, форматы не развиваются и на сегодняшний день выглядят устаревшими, проприетарными и очень дорогими.
В какой продукт (формат) по Вашему мнению  вкладываются "значимые ресурсы сообщества"?
источник

FM

Fox Mulder in technicalwriters
Если подходить комплексно:
Visual studio + markdown + github
источник

BF

Bobba Fett in technicalwriters
Milkhail Che
если в HaT я могу парой кликов добавить условия и переменные, то в DaC нужно открывать файлы и править их.
Тупо экономичнее
Вопрос тулинга и денег. Возможно, вместо покупки HAT можно было на эти деньги нанять того, кто напишет скрипт/плагин для вашего редактора, который будет так же быстро и наглядно всё делать, а под капотом “открывать файлы и править их”. Ну или кто-то в компании сделает или вы сами. Ключевое слово “возможно” - для некоторых компаний подобное недопустимо и лучше просто быстро вкинуть денег в готовый тул.

И да, это отнимает время и внимание от самого контента)
источник

MC

Milkhail Che in technicalwriters
HTML шаблоны и в ДАК и в ХАТ одинакого править.
А вот шаблоны для pdf в HelpandManual — визуальный редактор, все отступы и т.д. настраивается без знаний — рекомендую))
источник

BF

Bobba Fett in technicalwriters
Milkhail Che
HTML шаблоны и в ДАК и в ХАТ одинакого править.
А вот шаблоны для pdf в HelpandManual — визуальный редактор, все отступы и т.д. настраивается без знаний — рекомендую))
Спасибо за рекомендацию, я хелп энд мануал в двух компаниях вводил, чтобы хотя бы от ворда отойти, я просто к тому, что возня vs купить готовое это всегда палка о двух концах, бывает что возня оправдана
источник

BF

Bobba Fett in technicalwriters
Я сейчас как-то неправильно использовал фразу “палка о двух концах”)
источник