Публикации
Документация на английском языке: советы начинающим
26.03.2014
Сегодня мы подвели итоги конкурса «Конёк документатора». Победители награждены призами, а лучшие работы мы опубликуем на нашем сайте.
Представляем вашему вниманию работу, занявшую 1 место: «Документация на английском языке (советы начинающим)». Автор – Софья Новикова, технический писатель в компании «Икстенс», г. Новосибирск. Пунктуация и орфография автора сохранены.
Так получилось, что весь мой опыт работы техническим писателем приобретался в компаниях, работающих с иностранными клиентами. Поэтому писать документацию мне приходилось преимущественно на английском языке. Хотелось бы поделиться опытом с теми техническими писателями, кто только начинает писать англоязычную документацию либо переводить русскоязычную документацию на английский язык. Конечно, хорошее знание английского языка – это первое и необходимое требование для достижения успеха, но недостаточное. Умение писать техническую документацию на русском языке так же может оказаться хорошим подспорьем, однако в англоязычной документации есть свои особенности, которые следует учитывать. Я расскажу об основных особенностях, которые мне удалось узнать за время своей работы.
Читать дальше…
Что я получаю от участия в конференциях
24.03.2014
В преддверии конференции «ТехДок 2014: Софт» представляем вам размышления технического писателя Сары Мэддокс о пользе участия в подобных мероприятиях.
Я в муках творчества. Моя презентация для саммита STC 2014 уже отлично выглядит, и сейчас я работаю над тезисами. Я начала задумываться над тем, почему я так часто выступаю на конференциях. Это же куча работы! Неужели оно того стоит? Я посмотрела публикацию Нила Каплана, который не выступает на конференциях. Поэтому я решила поделиться своими мыслями в блоге.
Если бы лет пять назад мне сказали, что я буду выступать на конференции, реакция была примерно такая:
Ха-ха, нет, это какая-то другая Сара.
Публичные выступления пугали меня до смерти. (На самом деле, до сих пор пугают). Я никогда не думала, что смогу это сделать. Даже если приходилось просто стоять перед горсткой коллег, я превращалась в каплю желе на американских горках.
Обзор Doc-To-Help от ComponentOne
21.03.2014
Как показывает статистика, большинство технических коммуникаторов в России предпочитают работать в MS Word. И многим из них тяжело переходить на другие инструменты. К счастью, на рынке сегодня представлено большое количество инструментов, встраиваемых в Word, либо имеющих сходный интерфейс. Представляем вам обзор одного из таких продуктов – Doc-To-Help.
Если вам нравится Word, пользуйтесь им! Doc-To-Help предлагает лучшую в отрасли поддержку для авторов, работающих в MS Word. Вместо того чтобы заставлять авторов конвертировать документы Word в другие форматы, приложение встраивает рабочую панель в Word, объединяя все функции Doc-To-Help в знакомом интерфейсе.
О Doc-To-Help
Doc-To-Help, продукт компании ComponentOne, подразделения GrapeCity, был ведущим инструментом для создания и публикации контента на рынке контент-авторинга с 1991 года. Он позволил техническим коммуникаторам, создателям стандартов и другим писателям работать в редакторе на базе XML, Microsoft Word или HTML, а также публиковать контент в интернете, создавать справочные системы или печатные руководства всего одним кликом. В Doc-To-Help компания ComponentOne реализует уникальное сочетание возможностей редактирования, единого источника и издательских технологий, что ведёт к значительной экономии времени и самому высокому качеству. Doc-To-Help является полным инструментом создания документации, и пользователям не нужны дополнительные инструменты.
Кто сказал, что нельзя использовать Word для XML-авторинга?
19.03.2014
В наших публикациях мы часто описываем различные виды авторинга и не можем не упомянуть про XML-авторинг. В этой статье Скотт Абель, специалист по управлению контентом и основатель ресурса для технических коммуникаторов thecontentwrangler.com, рассматривает возможности использования MS Word для XML и предлагает поближе взглянуть на одно из альтернативных решений от партнера Microsoft, которое использует знакомый интерфейс приложения Word.
Хотя MS Word может генерировать XML, его не стоит рассматривать как надежный инструмент XML-разработки. Его возможности работы с XML лучше всего подходят для использования вместе с другими приложениями Microsoft Office. Однако, поскольку XML-авторинг завоевывает все большую популярность, на рынок выходят новые программные инструменты и утилиты XML-авторинга.
Факт: Microsoft Word является текстовым процессором. Еще два факта: Microsoft не позиционирует Word как редактор XML. И не планирует. Почему? Поскольку MS Word не является инструментом XML-авторинга, независимо от того, что думает ваша ИТ-команда. Хотя Word действительно может понимать и использовать некоторые элементы XML, он не использует XML так, как это нужно техническим коммуникаторам. Вместо этого он использует XML для передачи информации между продуктами MS Office. Полезно? Да. Для XML -авторинга? Абсолютно нет.
Обзор MadCap Flare 10 (часть 3)
17.03.2014
Мы заканчиваем обзор нового продукта компании MadCap – Flare 10. Мы уже рассмотрели основные преимущества продукта, теперь коснёмся более мелких, но тем не менее важных и полезных нововведений.
Дополнительные улучшения
Этот релиз включает многочисленные мелкие улучшения. Невозможно сказать, какие из них наиболее важны для разработчиков, поэтому перечисляю их в неопределённом порядке:
- Возможность задания условий размещения отдельных объектов на карте гиперсвязей документа. Задание условий размещения является основой составляющей единого источника, но неспособность располагать объекты на карте гиперсвязей означает, что либо вы не использовали карты гиперсвязей для единого источника, либо создавали несколько версий каждой карты и задавали условия для каждой, добавляя себе работы. Если вам в выводе единого источника нужны карты гиперсвязей документа, возможность задания условий размещения объектов на карте станет приятным для вас дополнением. Читать дальше…
Обзор MadCap Flare 10 (часть 2)
14.03.2014
Продолжаем публикацию обзора продукта Flare компании MadCap. Сегодня мы узнаем о том, насколько могут быть полезны слайд-шоу, зачем нужна функция Экспорт проекта, а также о том, каким образом компания вынуждает пользователей переходить с trial-версий на лицензионные.
Поддержка в Flare вывода HTML5 и адаптивного вывода
В Flare 9 была добавлена поддержка вывода HTML5, весьма удачно встроенная в интерфейс. Некоторые опции были названы по-другому и располагались не там, где их эквиваленты для WebHelp, но все равно оказались под рукой. В Flare 10 добавили новый, более лёгкий в использовании, редактор оболочек HTML5 и адаптивный вывод в виде набора новых вариантов в редакторе оболочек HTML5 и редакторе целевых файлов. Вы включаете адаптивный вывод на дополнительной вкладке редактора целевых файлов, устанавливаете контрольные точки на вкладке настройки редактора оболочек HTML5 и устанавливаете различные другие параметры отображения в редакторе оболочек HTML5.
ABBYY FineReader 12 — новое слово в OCR-технологиях
Компания ABBYY достаточно давно заняла лидирующие позиции на мировой арене разработок в области распознавания текстов и лингвистики. В настоящей публикации мы представляем новую версию одного из флагманских продуктов этой компании — ABBYY FineReader 12. Новая версия этого продукта вышла в свет совсем недавно, 12 февраля 2014 г., и обладает рядом преимуществ относительно предыдущей версии.
Всем, кому хоть раз приходилось работать с отсканированными копиями текстовых документов, известны возможности FineReader — с его помощью можно легко перевести бумажные документы, их изображения и PDF-файлы в электронные редактируемые форматы. Новая версия этой программы позволяет еще быстрее и проще обрабатывать многостраничные тексты, а также содержит новые возможности для улучшения качества как исходных изображений документов, так и их распознанных копий.
Новый FineReader точнее воссоздает и сохраняет структуру и форматирование сложных документов. Улучшено распознавание таблиц, диаграмм и графиков, что стало возможно благодаря изменениям в технологии ADRT® (Adaptive Document Recognition Technology, Технология адаптивного распознавания документов). Кроме того, для удобства пользователь может выбрать один из двух режимов распознавания: с приоритетом скорости или качества. В первом режиме документы будут обрабатываться практически вдвое быстрее.
Обзор MadCap Flare 10 (часть 1)
12.03.2014
Мы начинаем серию статей, составляющих обзор вышедшей на прошлой неделе новой версии продукта для технического документирования компании MadCap – Flare 10. Рассказывает о новых функциях и преимуществах Нэйл Перлин (Neil Perlin), генеральный директор компании Hyper/Word Services, имеющий 35-летний опыт работы техническим писателем, 29-летний опыт консультанта и тренера, а также являющийся сертифицированным пользователем MadCap и автором нескольких обзоров продуктов компании MadCap.В начале обзора Нэйл объясняет особенности адаптивного вывода контента и роль HTML5 в публикации контента и его обнаружении поисковиками.
Flare является относительным новичком в мире технической документации, он дебютировал в 2006 году. Но компания MadCap основательно расширила его в десятой версии, вышедшей на прошлой неделе (4 марта 2014 г.) и предлагающей новые функции и множество усовершенствований.
В этом обзоре я расскажу об основных функциях — адаптивном выводе документа, основанном на HTML5, слайд-шоу, системе помощи Eclipse и экспорте проекта, затем рассмотрю моменты, которые считаю основными усовершенствованиями.
Эджайл и технические коммуникации: командный подход (часть 3)
07.03.2014
В завершающей части статьи речь пойдёт о сворминге – что это, и чем хорош этот подход в эджайл-разработке, о работе над ошибками, а также о том, как допускать как можно меньше ошибок при командной работе и, таким образом, копить как можно меньше «технических задолженностей».
Сворминг
Чтобы командный подход стал успешным, инженерам по качеству и членам группы разработки информации нужны хорошая поддержка и обучение, которые помогут им адаптироваться к быстрому темпу эджайл-разработки. Тесное сотрудничество внутри команды может потребовать от ее членов освоения новых навыков, и действительно важно дать им время для этого. Одним из способов это осуществить является сворминг (от англ. Swarming — роение, обозначает совместную работу «всем скопом»).
Эджайл и технические коммуникации: командный подход (часть 2)
05.03.2014
Представляем вам продолжение статьи Алиссы Фокс о работе команд по эджайл-методологии. Сегодня вы узнаете, на ком лежит ответственность за результат при командном подходе, и о том, как обеспечить рациональное использование рабочего времени каждого члена команды вне зависимости от его роли и от времени выполнения своих функций представителями других ролей в команде.
Качество — это ответственность всей команды
Наряду с тем, что использование командного подхода, когда участвует вся команда целиком, даёт множество внутрикомандных преимуществ, наиболее очевидным внешним преимуществом является повышение качества продукта. Вся команда ответственна за разработку, тестирование и документирование по каждой из пользовательских историй до тех пор, пока спринт не будет окончен. Инженеры по качеству направляют эти усилия таким образом, чтобы вся команда работала над обеспечением выполнения всех этапов спринта.
Мы обнаружили, что для достижения наших целей в каждом спринте нам необходимо как можно больше автоматизировать тестирование. Автоматизированное тестирование быстрее, надежнее и менее подвержено ошибкам. Инженеры по качеству взаимодействует с группой разработки, чтобы обеспечить выполнение модульных тестов (unit tests) и повысить внимание к моментам, в которых существуют пробелы. Инженер по качеству должен также направлять усилия на разработку и автоматизацию приемочных тестов (acceptance tests), а также на выполнение исследовательских тестов (exploratory tests). Другими словами, ручное тестирование — это не самый гибкий (agile) способ получения высококачественного продукта. Для получения дополнительной информации о гибком тестировании и различных видах тестирования смотрите блог Лизы Криспин (Lisa Crispin) www.lisacrispin.com.