Блог Статьи

Житейские советы — технические детали в документации модулей

Иногда откроешь страницу модуля в любой площадке, чтобы посмотреть описание, и понимаешь, что желание создавать литературные произведения попросту заложено  у некоторых в крови. Огромные тексты, порой достигающие 10 000+ знаков! И это просто описание модуля!

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

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

1. Поиск и сео продвижение.

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

Вот, например, у меня есть модуль IMCallMeAskMe, который имеет «слегка» переоптимизированное название — «Заказать обратный звонок / Задать вопрос (всплывающие окна)».

С одной стороны, можно было бы обойтись одним названием «всплывающие окна», так как это почти полностью отражает суть модуля. Кроме того, сегодня эту фразу знают даже те, кто далек от технической стороны.

С другой стороны, вот попробуйте открыть любую площадку и поискать по частям из названия модуля (или вообще используя отдельные слова). Вы удивитесь, насколько разные результаты поиска будут показаны. Причем периодически, в эти результаты будут попадать и вообще «левые» модули.

Поэтому, большое и объемное описание, конечно, без всякой ахинеи — это большой плюс как покупателям, которые смогут найти качественные решения для своих интернет-магазинов, так и авторам, чьи решения будут видны в поиске.

2. Неожиданные сюрпризы модуля и скорость решения проблем.

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

А ведь как приятно смотреть на маленькое, коротенькое, красивое, качественно оформленное описание размером где-то в половину страницы.

Конечно, многие эти вопросы решаются, но это все время.

С точки зрения покупателя. Вам нужно описать проблему. Потом вам придется ждать, когда же вы дождетесь ответа. Потом возможно узнать, что проблема не решаема, или же решаема, но не просто так, или же модуль и вовсе такого не предусматривает. Если же проблема решаема, то снова переписываться, чтобы все же настроить модуль. И так далее.

С точки зрения автора. Это необходимость разбираться в проблеме, которая нерешаема, либо решаема, но не без доделок, либо решаема, но просто пользователь настроил все некорректно (при этом весьма вероятно, что придется еще и много чего описывать). И так далее. В итоге, это так же занимает кучу времени и сил, которые лучше бы потратить на расширение функционала модулей или же создание других.

Поэтому, это банально выгодно и покупателям, и авторам.

3. А модуль так может?

Конечно, многим лень читать большую и скучную документацию. Пощелками демо-версию, посмотрели, что модуль корректно функционирует. Купили. Установили в свой интернет-магазин. Все настроили и радуетесь.

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

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

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

Допустим, описание вы не нашли и полей ввода так же. Будем честными, все прекрасно понимают, что стоимость «допила» отличается от стоимости модуля, так как модуль можно продать много раз, а допил продается один раз (банально такова схема рынка модулей для интернет-магазина). Поэтому, вы снова потратите кучу времени в поисках других модулей, где в описании или демке встречается нужная вам функциональность (ведь это попросту будет дешевле). Если нашли, то дальше все происходит по аналогичной схеме с той, что указанна вначале пункта. При этом вполне возможно, что еще модули могут начать конфликтовать и многое другое.

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

В итоге, модуль либо переписывается, так как «в модуле хоть и обнаружены какие-то схожие механизмы, но — ну нафиг, а вдруг там все кривое», либо функциональность вообще начинает прикрепляться где-то сбоку.

Для покупателей, как вы, вероятно, уже догадались, полная документация (включая технические детали) у модуля полезна, как минимум, тем, что не придется заниматься всем описанным выше.

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

Конечно, существуют и другие моменты, но даже из этих видно, что чем полнее описание, тем больше это может сэкономить времени, сил и нервов как покупателю, так и автору.