techwriter (Все сообщения пользователя)

[QUOTE]H&M User пишет:
[QUOTE] techwriter пишет:
Но факт остается фактом, необходимость ввода сложных формул в некоторой документации присутствует. Также это очень актуально при разработке содержательной конструкторской документации, где помимо текстового обоснования присутствуют математические расчеты. При этом ее основной формат - печатный. Для последнего варианта очень целесообразно использовать Latex, а не Docbook или DITA.
И повторю вопрос: ты для картинки где будешь формулу брать?
[/QUOTE]А чем Вас H&M не устраивает? Вставка OLE-объектов Microsoft Equation 3.x или MathType (в CHM и HTML получаются gif-картинки).
[/QUOTE]Я ничего против H&M не имею. Просто речь идёт о Docbook и Latex.

[QUOTE]Виктор Фигурнов пишет:
[QUOTE] techwriter пишет:
Метод описывает поведение сущности. Я считаю, некорректно называть метод атрибутом сущности.
[/QUOTE]С глубоким прискорбием сообщаю, что при посылке вашего сообщения вы использовали метод POST, являющийся атрибутом HTML-формы. :D
[/QUOTE]post является значением атрибута "method". Атрибут может также принимать значение "get". Атрибут "method", в свою очередь, относится к тегу "form".

[QUOTE]Виктор Фигурнов пишет:
[QUOTE] techwriter пишет:
[QUOTE] Т.е у сущности есть атрибуты, у которых в свою очередь могут быть параметры?
[/QUOTE]
Нет.
[/QUOTE]Да. Атрибутом сущности может быть метод (процедура, функция). У этого метода (процедуры, функции) могут быть параметры.
[/QUOTE]Метод описывает поведение сущности. Я считаю, некорректно называть метод атрибутом сущности. Один метод может описывать поведение нескольких сущностей.

[QUOTE]eoi пишет:

спасибо! Т.е у сущности есть атрибуты, у которых в свою очередь могут быть параметры?
[/QUOTE]
Нет. Например, у вас есть сущность "столы". Столы могут иметь следующие атрибуты: ширина, длина, высота, цвет, вес, количество ножек и пр. Параметры же влияют на что-либо. Например, столы шириной 2 метра вы продаете за 100 рублей, а столы шириной 1 метр вы продаете за 50 рублей. В этом случае атрибут с конкретным значением становится входным параметром для расчета цены.

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

С пятницей!

Да, вот где поле для фантазий :

[QUOTE]ADVANCED пишет:
[QUOTE] techwriter пишет:
Например, у меня был фрилансерский проект по разработке онлайн-справки по работе с математическим онлайн-редактором. У этого редактора была куча функционала, который позволял писать и редактировать научные и технические статьи. Он был предназначен для преподавателей технических вузов.
[/QUOTE]У меня был проект по разработке телематической платформы, где нужно было описать API модуля "расчетов", к которому должны обращаться сервисы сторонних разработчиков. И документация предназначалась именно для сторонних девелоперов, которым нужно понимать к чему обращаться, откуда ждать результаты расчетов и как все считается. Всего около тысячи операций, соответственно по несколько формул в каждой операции расчета.
Ни одной формулы не использовал, т.к. не математик и не факт, что читающий эти формулы поймет. Нарисовав формулу, совсем не очевидно, что она будет правильно осознана. А когда словами пишется, что на что умножается/делится/прибавляется/отнимается, какие коэффициенты применяются и откуда они берутся - вопросов не возникает.
[/QUOTE]Причем тут осознание формулы? Тебе надо написать примеры ввода формул в математическом редакторе, в котором используется свой язык.Ты можешь сколько угодно упираться в своем предположении, что все можно описать словами. Но факт остается фактом, необходимость ввода сложных формул в некоторой документации присутствует. Также это очень актуально при разработке содержательной конструкторской документации, где помимо текстового обоснования присутствуют математические расчеты. При этом ее основной формат - печатный. Для последнего варианта очень целесообразно использовать Latex, а не Docbook или DITA.
И повторю вопрос: ты для картинки где будешь формулу брать?

[QUOTE]ADVANCED пишет:
Написать толмут в 1500 страниц, который никто никогда не откроет и не распечатает, а если откроет, то не найдет там то что нужно - это косяк технического писателя.
[/QUOTE]"Хорошо подавать материал" тоже это включает. Если от противного, то недостаточно разработать онлайн-справку с удобным поиском и закругленными кнопками. Если она не будет содержать полезного контента, цена ему тоже равна нулю.
Поэтому тем, кто хочет развиваться, и идет лично от меня посыл: сначала надо научиться организовывать и управлять контентом. Если будет понимание самой концепции того, каким образом это оптимально сделать, сразу возникнет необходимость применения тех или иных технологий. Не технология первична, а концепция организации и управления информацией. На концепцию накладывается технология, а не концепция на технологию.

[QUOTE]Elanor пишет:
А вот всякие круглые кнопочки, высоты и всевозможное макетирование в веб-справке - это больше к веб-дизайнеру задание. И нет в этом, в общем-то, ничего зазорного. Всегда имеет смысл судить конечный результат - когда и текст не требует редакторской правки, и выглядит пристойно (и вот это "выглядит" отнюдь не всегда заслуга тех.писа - есть много "специально обученных людей", которые могут внести свою лепту в книги).
[/QUOTE]В идеале, в отделе документирования, на мой взгляд, должно быть разделение по ролям: технические писатели, редакторы и дизайнеры. Тогда и текст не будет требовать редакторской правки и выглядеть все будет достойно.

[QUOTE]Elanor пишет:
Мне кажется, основная работа техписа - написать понятную пользователю книгу/справку/нужное дописать, которая была бы подспорьем в освоении программы. Сделать это согласно установленным стандартам, и чтобы конечный текст отображал истинное положение вещей.
[/QUOTE]Полностью согласна. Основная задача технического писателя - писать. Умение хорошо подавать материал тоже большое искусство :)

[QUOTE]ADVANCED пишет:
techwriter, и правда, это же с молоком матери передается ))[/QUOTE]Не стоит преувеличивать сложность реализации. Закругление углов у кнопок не самое сложное, что есть в CSS.

[QUOTE]ADVANCED пишет:
[QUOTE] techwriter пишет:
[QUOTE] ADVANCED пишет:
А почему не сделать формулы картинкой ?
[/QUOTE]Угу. Очень "удобно".
[/QUOTE]в кавычках - сарказм?
А что не удобного то? Я вот ни разу не встречал формулы в документации и ни разу не писал их. В учебниках видел только. В картинке формула будет или нет, не важно.
Не думаю что формулу нужно часто редактировать. Что неудобного? Скриншоты ведь делаются в виде картинок, а не в виде куска html с кнопочками и надписми
[/QUOTE]Потому что ты писал только документацию к бизнес-приложениям и никаким другим.
Например, у меня был фрилансерский проект по разработке онлайн-справки по работе с математическим онлайн-редактором. У этого редактора была куча функционала, который позволял писать и редактировать научные и технические статьи. Он был предназначен для преподавателей технических вузов. Возникает вопрос, совсем нетрудоемко, на твой взгляд, в этом случае отдельно писать формулы, их скриншотить и потом вставлять в текст? И, кстати, в чем ты их планируешь составлять? В "неудобном" ворде?

[QUOTE]Виктор Фигурнов пишет:
Заказчик говорит, что онлайн-документация ему в принципе нравится, но эта кнопочка должна быть с закругленными углами, этот ярлычок вкладки другой высоты, промежуток между панелями должен быть узкий, должны быть такие-то кнопки, которые то-то делают, и т. д. Будете отвечать, что ничего этого делать не умеете?
[/QUOTE]Виктор, а что сложного в закруглении углов, изменении высоты и проставлении промежутков между панелями?

[QUOTE]Виктор Фигурнов пишет:
Ну попробуйте за месяц выучить HTML5 и CSS3, сдать экзамен и получить майкрософтовский сертификат "Programming in HTML5 with CSS3".

Тогда и будете говорить, что это несложно.
[/QUOTE]А что конкретно для вас сложно в этой связке?

[QUOTE]ADVANCED пишет:
И направление развития я бы выбрал не в сторону госстандартов и бюрократии, а передовых технологий ПО и хелпа для этого ПО, в частности онлайн-справки, а также HTML5, CSS3, JS, верстка. Инструментарий для разработки документации независимо от платформы и устройств, переносимые источники, без привязки к какому-либо формату или системам хранения.
[/QUOTE]Думаю, очевидно: недостаточно владеть инструментарием. Да и овладеть им не так сложно. HTML5 и CSS3 не те вещи, которыми имеет смысл хвалиться, т.к. в них чего-то мегасложного нет. Любой может научиться за месяц.

[QUOTE]Ден пишет:
У нас на работе аврал, пришла новая "метла". Сейчас ставит план по объему выдаваемой техническими писателями количества листов готовой документации в день. Итак, у кого какой темп написания документации? Есть ли какой план по разработке док-ов в неделю?.
[/QUOTE]У меня - нет. Но я могу писать очень быстро :)))

[QUOTE]ADVANCED пишет:
Седня кровь сдавал, там студентов очень много было.За кровь около 2000 получают + 600 руб компенсация или коробка с продуктами (сырокопченая колбаса, сыр, ореховая смесь, шоколад, гематогенки, конфеты всякие и т.д, ). За плазму около 4500, а за эритроциты вообще около 8000 рублей.
[/QUOTE]Да не особо полезно сдавать кровь на регулярной основе.

[QUOTE]ADVANCED пишет:
[QUOTE] writer пишет:
[QUOTE] Astica пишет:
ыы) у меня офф з.п. вообще 6400  :D  и в конвертике еще 9 т.
жаль что в рублях)
[/QUOTE]Давайте спасем [url=http://techwriters.ru/forum/user/15620/]Astica[/url] ! Пусть [url=http://techwriters.ru/forum/user/15620/]Astica[/url] увидит Японию!!

Такая зарплата точно очень мало! Даже если совсем ничего не делать и сидеть целый день в Интернете! А какой город?
Давайте попробуем вам работу подыскать, ну раза в 3-4 побольше чтобы зарплата была.
[/QUOTE]Да это не зарплата совсем. В Москве пособие молодым мамам в декрете 18-20 тысяч в месяц + молочные кухни всякие. Может 6400+9000= в неделю?
[/QUOTE]Пособие еще заработать надо.

[QUOTE]zukatoka пишет:
Как вы нумеруете рисунки в справке такого вида? В chm справке вообще принято нумеровать рисунки? А если не нумеровать, то потом при экспорте в word придется все номера вбивать руками?[/QUOTE]Применительно к HM не знаю. Но если в качестве исходника использовать HTML5 и css-счетчики, то автоматическая нумерация возможна. Соответственно при конвертировании в rtf нумерация сохраняется.

[QUOTE]ADVANCED пишет:
А почему не сделать формулы картинкой ?
[/QUOTE]Угу. Очень "удобно".

[QUOTE]Виктор Фигурнов пишет:
То есть, позволяет создавать и публиковать в HTML
[/QUOTE]Только не всеми браузерами поддерживается, насколько я знаю.

[QUOTE]fs444 пишет:
Появился вопрос - в чем разница применения Latex и DocBook? понимаю, что разный синтаксис и способ формирования документа. Нашел в интернете, что Latex больше для PDF, а DocBook для HTML.
[/QUOTE]
Глупости про формат.
Latex удобен, когда в документе есть необходимость ввода сложных формул и рисования диаграмм. DocBook и DITA для этих целей мало применим. Поэтому если вам, например, надо написать математический справочник и издать его, то лучше применять Latex. Для пользовательской документации вполне подойдет и, наверное, даже будет удобнее DocBook.

[QUOTE]ADVANCED пишет:
Эта деятельность входит в компетенцию аналитика.

Если этим занимается писатель, может означать, что:
а) ему не правильно назвали должность на которую он трудоустроен;
б) он достаточно продвинут в знаниях и имеет аналитический склад ума и проходит испытательный срок на должность аналитика;
в) аналитик заболел, а писатель из пункта "б" не знает чем заняться;
г) маленькая контора, где разработчик сам себя же тестирует, руководитель проекта контролирует время прихода и ухода сотрудников, техподдержка пишет инструкцию "как перезагрузить сервер" и происходит другая путаница в работе.
д) еще что-либо
[/QUOTE]А ТЗ и пишет аналитик, а не технический писатель.

[QUOTE]ADVANCED пишет:
Заказчик на встрече с аналитиком ставит требование "чтобы адрес можно было выбрать из списка". Аналитик отправляет программисту СМС "надо сделать справочник КЛАДР, подробности в письме". Пишет письмо в электричке пока не забыл, или прикладывает аудиозапись с диктофона. Когда аналитик приезжает на свое рабочее место со встречи, прикладывает переписку из почты в JIRA. Программист в это время уже заканчивает справочник и передает на тестирование. Тестировщик читает весь ход мыслей от появления идеи, до завершения разработки и тестирует, писатель документирует. Доработка сдается заказчику патчем или в следующем обновлении.
Вообще так редко бывает, если честно, но бывает. Пример из опыта работы с госзаказчиком. Срок разработки сокращен до минимума, все все выполнили, заказчик доволен. Никто не растягивает договоры, печати, ТЗ по ГОСТ и т.п.
[/QUOTE]Плохой принцип разработки требований.
От проектирования до разработки того же сайта выполняется много работы, как например, анализ существующих аналогов, изучение разработок конкурентов, изучение недостатков и достоинств существующих решений, описание бизнес-процессов "как есть - как будет", разработка концепции, описание возможностей развития в дальнейшем, проектирование самой системы как на уровне архитектуры, так и на уровне интерфейса и функционала и пр., и пр.
Приведенный пример - типичный пример разработки "на коленке". Заинтересованный заказчик к тому варианту редко склоняется. И ежу понятно, что JIRA для нормального управления требованиями недостаточно, она подходит только на этапе разработки системы.