Skip to content

Структура документации #75

@gromdron

Description

@gromdron

Мне кажется документация начинает сильно вырастать и из технической местами стремиться превратится в руководство администратора.
Я не против того, чтобы важные аспекты касающиеся подсистем были описаны и наглядно показаны на скриншотах, но фокус внимания теряется.

Пример текущего дня: коллеге надо было отправить письмо определенного шаблона из Битрикс24. Я помню что в новой документации были понятные и простые примеры кода и найти их было легко. Сначала я интуитивно попытался выполнить поиск статьи в "Фреймворке", но понял свою ошибку - почтовая подсистема часть CMS и пошел в соответствующий раздел и довольно быстро нашел статью - "Работа с почтой", но открыв ее первое что я увидел - это настройки модуля почты.
В правом меню гордо красовалось двухстраничное оглавление которое описывало: системные почтовый ящик, создание правил для получения писем, настройка сервера для отправки письма, макросы. Устав листать. Здесь я не выдержал (да-да, каюсь, решение было близко) и пошел в поиск для того чтобы нагуглить Event::send. Был сильно удивлен что поиск ничего не нашел, потому что два двоеточия видимо запрещенный прием. Пришлось возвращаться и перечитывать статью и пользоваться поиском на странице.

Улавливаете к чему весь этот большой монолог?

На выполнение простой задачи: отправить письмо с определенным текстом по определенному шаблону ушло слишком много времени.
Я предлагаю ре-структурировать разделы и постепенно добавлять в левое меню третий уровень вложенности.
Искать нужную информацию в длинных статьях очень не просто.

Sub-issues

Metadata

Metadata

Assignees

Labels

No labels
No labels

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions