20.04.2011, 17:46 | #1 |
Участник
|
Как создавать и обновлять справку в Ax2009
Как создавать и обновлять справку в Ax2009? Можно ли использовать старый функционал SysHelpOverview или только HTML?
|
|
20.04.2011, 18:33 | #2 |
Модератор
|
Создание Help System со страницы 1-10 (тренинг) AX2009_ENUS_DEVIII_01.pdf
__________________
This posting is provided "AS IS" with no warranties, and confers no rights. Последний раз редактировалось Poleax; 20.04.2011 в 23:23. Причина: только информация где почитать |
|
20.04.2011, 18:41 | #3 |
Участник
|
Я правильно понял, что для того, чтобы добавить новую статью в один из стандратных CHM я должен вручную декомпилировать соответствующий CHM, добавить статью и снова скомпилировать в CHM?
|
|
21.04.2011, 08:47 | #4 |
Участник
|
Видимо, да, только зачем же добавлять статью в стандартные CHM-файлы? С ними возни много, глядишь, с каким-нить rollup'ом обновятся, чего доброго, - придется все переделывать. Проще, по-моему, свой отдельный файл завести.
|
|
21.04.2011, 17:37 | #5 |
Участник
|
Надо понимать так, что никто и никогда не пишет справки по собственному функционалу? "Не царское это дело"?
|
|
21.04.2011, 17:43 | #6 |
Участник
|
На проектах обычно пишут руководство пользователя / инструкцию. А формальное описание полей и кнопок мало кого интересует. Да и подсказки должны быть достаточно информативными, чтобы в хелп не смотреть. А вот расписывать все варианты реализации БП в хелпе, по моему, без толку.
__________________
Ivanhoe as is.. |
|
21.04.2011, 18:07 | #7 |
Участник
|
Ну, создали Вы новую настроечную форму. Разве Вы не пишите краткую справку о том, для чего эта форма нужна и где используются сделанные в ней настройки?
Создали новый отчет. Разве Вы не пишите что именно этот отчет выводит, по какому алгоритму отбирает и формирует данные, что обозначают те или иные настройки в этом отчете? Неужели все "настолько очевидно" по внешнему виду? Или каждый пользователь всегда обращается к "руководству пользователя" и начинает судорожно искать где же там описание нужной формы/отчета? |
|
21.04.2011, 18:59 | #8 |
Участник
|
Цитата:
Сообщение от Владимир Максимов
Ну, создали Вы новую настроечную форму. Разве Вы не пишите краткую справку о том, для чего эта форма нужна и где используются сделанные в ней настройки? Создали новый отчет. Разве Вы не пишите что именно этот отчет выводит, по какому алгоритму отбирает и формирует данные, что обозначают те или иные настройки в этом отчете?
Обычно новые настроечные формы и отчеты создаются не от нечего делать, а по конкретному запросу от пользователей, которым нужен новый функционал, либо от консультантов, кроме которых те же настроечные формы подчас никто и не увидит. Так вот, пользователи обычно заранее примерно представляют чего они хотят и чего получат в результате, поэтому справку какую-то отдельную рисовать им не надо, а для новых сотрудников есть инструкции и, может, даже видеоуроки, где наглядно все показано и рассказано. Я лично еще люблю проверять те же формы на неподготовленных пользователях - смогут ли разобраться без подсказки; это, по-моему, неплохой "тест на вшивость" для дизайна формы и реализованного взаимодействия с пользователем. |
|
21.04.2011, 19:32 | #9 |
Участник
|
Вообще-то, как ни странно, справка нужна скорее разработчику, чем пользователю. Хотя и пишется так, чтобы пользователю было достаточно понятно. Пользователь вобще никогда и ничего не читает Описываю то, с чем я постоянно имею дело.
Присылают запрос: почему вот в этом отчете вот такие цифры, а вот в этом - другие? Ответ простой, именно потому, что отчеты разрабатывались под разные требования и, соответственно, использовали разный алгоритм расчета. Хотя поля отчета называются совершенно одинаково, что, собственно, и вводит в заблуждение пользователя. Но это если знаешь ответ. А если не знаешь? Оба отчета разрабатывали X лет тому и все разработчики и заказчики уже благополучно уволились? Читать ТЗ и инструкции? Ну, и где они эти ТЗ и инструкции? Названия-то хоть известно? С момента создания этих отчетов структура каталогов и архивов менялась столько раз, что и не упомнишь. Да и кому интересны те ТЗ, если отчеты многократно переписывались? Какое из множества разных ТЗ нужно? В результате, приходится тратить многие часы, чтобы понять, в чем же отличаются алгоритмы расчета этих отчетов. И почему их вообще нельзя сравнивать? С другой стороны, справка, вызываемая по F1 всегда "под рукой". Ее просто нельзя потерять. Разве что, вместе с системой. Поэтому, либо сам быстро "пробегаешься" по справке и объясняешь все пользователю, либо, если пользователи очень уж "достали" можно просто сказать: нажмите F1 и читайте в чем отличие. С настроечными формами другая проблема. С течением времени они обрастают огромным количеством разных полей, смысл которых теряется "в глубине веков" . И опять встает вопрос документирования что за что отвечает. Все "внешние" (по отношению к Axapta) источники еще надо найти (и не факт, что они вообще есть). Другими словами, несмотря на то, что справка пишется вроде как для пользователя, реальную пользу она приносит именно аналитикам и разработчикам. |
|
21.04.2011, 19:50 | #10 |
Модератор
|
Насколько я понимаю, проекты делаются (ну по крайней мере, должны ) в соответствии с методологией.
Рекомендуемая методология для внедрения Dynamics AX - Microsoft SureStep Насколько я помню методологию, там есть раздел "Внедрение", который подразумевает подготовку инструкций пользователей и их обучение. Насколько я помню методологию, в ней ничего не сказано про компиляцию CHM-справки. С Уважением, Георгий |
|
21.04.2011, 20:04 | #11 |
Участник
|
Мой опыт показывает, что справка нужна не столько для внедрения, сколько для сопровождения системы. Внедренцу-то что, он сделал свое "черное дело" и ушел . А мне с этим надо как-то дальше работать
PS: Ничего удивительного, что нет ни слова про CHM. Это слишком неудобно для модификации справки. Лучше уж "по старинке" через SysHelpOverview. Тем более, что она вполне нормально работает и в Ax2009. Надо только исправить парочку глюков, тянущихся с Ax2.5 |
|
21.04.2011, 20:39 | #12 |
Участник
|
Если вы теряете документацию на систему (т.е. она вам не нужна), то почему вы думаете, что кто-то будет писать / обновлять справку? Да и зачастую алгоритм либо простой, что и без справки разберешься, либо сложный настолько, что нужно в хелпе тогда всю постановку писать. Да и в стандарте хелп не самый лучший - не описывать же стандартную систему заново?
На своих проектах всегда веду реестр модификаций прямо в системе, с приложенными заданиями на разработку. Если вопрос действительно возникнет - всегда можно посмотреть кто, когда, зачем и для кого делал (понятно, что с определенными ограничениями .
__________________
Ivanhoe as is.. |
|
21.04.2011, 20:42 | #13 |
Участник
|
|
|
21.04.2011, 20:53 | #14 |
Участник
|
Самописная система регистрации модификаций с привязкой к стандартным проектам разработки. В принципе ничего не мешает вести реестр в отдельном трекере, системе HelpDesk и т.п. Да хоть и в Excel - было бы желание.
Просто в вашей идее ведения хелпа, кроме решения стандартных проблем с плохой документацией (отстутствует, не актуальна, не достаточна и т.п.), придется решать технические проблемы - те же файлы справки делать.
__________________
Ivanhoe as is.. |
|
21.04.2011, 21:04 | #15 |
Axapta
|
Справкой не пользуемся. У нас вот так: в Аксапте написан некий баг-трекер, в котором (в том числе) есть как полное описание задачи с ТЗ, так и ссылка на проект в Аксапте.
Чтобы узнать, в рамках какой (каких) модификаций менялся некий объект, достаточно простейшего джобика, который пробежится по всем проектам и составит список проектов, в которые данный объект входит. Дальше фильтр по баг-трекеру и вуалля, есть полный список модификаций, затрагивающий данный объект. Это для особо сложных случаев. В более простом случае достаточно посмотреть на метку модификации в коде, которая обязательно ссылается на проект приложения. Далее опять лезем в трекер и читаем ТЗ. Основная проблема тут в том, что старые задания со временем теряют актуальность, поэтому иногда читать приходится "нарастающим итогом". |
|
21.04.2011, 21:15 | #16 |
Участник
|
Цитата:
Цитата:
Справка пишется по мере необходимости и при внесении модификаций. В основном, для не стандартного функционала. |
|
|
За это сообщение автора поблагодарили: Ivanhoe (3). |
21.04.2011, 21:25 | #17 |
Участник
|
Цитата:
Основная проблема - это факт хранения документации вне Axapta. Как следствие, проблема поиска. Пока справка внутри Axapta самый оптимальный вариант хранения описания. |
|
21.04.2011, 21:28 | #18 |
Axapta
|
Текст задания хранится на VSS в виде документа Word. Из соответствующей задачи баг-трекера открывается нажатием кнопки. О какой проблеме поиска идет речь?
|
|
21.04.2011, 21:33 | #19 |
Участник
|
Самой прямой и непосредственной. Как определять где именно лежит нужный документ и лежит ли он вообще.
"Баг-треккер" - это функционал Ax2009? |
|
21.04.2011, 21:37 | #20 |
Axapta
|
Не-не, трекер нами написан. Если к задаче прикреплено ТЗ, то оно открывается из VSS нажатием кнопки. Ничего искать не надо.
|
|
Теги |
ax2009, help update, документация, справка |
|
|