22 самых популярных ошибки в готовых сайтах и магазинах в Маркеплейсе 1С-Битрикса

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

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

Те мелочи, которые для разработчика несущественные, которые исправляются за 5 минут, обычному пользователю, купившему готовое решение — непреодолимая преграда. Выхода обычно два. Первый — заплатить за интеграцию. Второй — долго переписываться с техподдержкой, в час по чайной ложке исправляя косяки, которых быть не должно изначально. Конечно, когда пользователь уже купил готовый сайт в маркетплейсе, деваться ему некуда и приходится идти до конца. Но ведь это неправильно. Решения должны быть более-менее законченными, не тратить время и не жечь нервы покупателя.

Когда покупатель готового решения сталкивается с проблемами, которых быть не должно, тратит  на устранение багов еще столько же денег, сколько на покупку битрикса+ТР, какие тут могут быть положительные эмоции как от Маркетплейса так и от Битрикса в целом? Какие он даст рекомендации знакомым, которые будут спрашивать его «брать-небрать»?

После сборки обработать наждачкой

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

1. Наличие в CSS нужных стилей для оформления контента

Часто в CSS не предусмотрены самые простейшие стили для оформления контента в публичной части:

• Вертикальные отступы между абзацами,
• Заголовки h1-h4,
• Нумерованные списки,
• Маркированный списки,
• Таблица,
• Подпись под фотографией,
• Другие стандартные стили, кнопки для которых есть в виз.редакторе Битрикса.

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

2. Наличие стилей в визуальном редакторе, чтобы их можно было удобно вставлять

Бывает, наоборот, в CSS стили есть, а в визредакторе их применить не получится. Потому что разработчик не предусмотрел их удобное отображение в выпадающем списке. Только вручную можно вписывать class. Для этого, его нужно как минимум знать, что рядовому юзеру трудно и не нужно.

3. Предусмотрен адаптив под таблицы, видео, фотки

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

4. Простое создание статичных страниц

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

Не нужно так делать. Вся обязательная обертка должна быть в шаблоне.

5. Простая работа с контентом статичных страниц

Пункт отчасти похожий на предыдущий. Но тут речь о статичных страницах, редактирование которых невозможно без знания html. Такие страницы легко сломать. Достаточно что-то добавить в визуальном редакторе. Особенно касается версий с адаптивом. Юзер, который не разбирается в html, легко сломает такую страницу в виз.редакторе. А, значит, будет недоволен результатом. Ну и как побочный эффект – кривые страницы на сайтах клиентов, сделанных на ваших готовых решениях. Что явно не способствует маркетингу.

UPD. Коллеги по цеху раскритиковали меня за этот пункт. Якобы бывают ситуации, когда по-другому сделать нельзя. Я категорически с этим несогласен. Перекладывать свои ограничения на пользователя – нечестно. Нет возможности сделать по-другому? Значит, при проектировании вы не учитывали реальные возможности Битрикса для правки контента. Или, не захотели напрячься и реализовать на инфоблоке. Или, если инфоблок, по каким-то причинам не вариант, поленились написать свою удобную форуму для редактирования этой страницы.

Кто-то говорит, что статичные страницы потому и статичные, что их редко правят. Отчасти это так. Но это не относится к готовым решениям, про которые эта статья. Потому что приобретая готовое решение, покупатель меняет на сайте сразу ВСЮ инфу. Ему нужно заменить все, от логотипа и заканчивая стандартными уведомлениями при отправке формы обратной связи.

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

UPD. 2. Если кто-то несогласен с этим пунктом или любым другим, он всегда может закрыть мой блог и продолжить жить дальше как привык. Переубеждать я никого не буду. 

6. Контент во включаемых областях имеет минимум оформления и стилей

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

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

7. Правильные настройки «по умолчанию»

Часто в готовых решениях, забывают правильно расставить галочки «по-умолчанию». Например, когда функционал не содержит детальных страниц («Вопросы и ответы», «Баннеры», «Слайдер» и т. п.), важно прописывать в настройках инфоблока детальную страницу правильно. Или закрывать инфоблок от индексирования внутренним поиском. Иначе, если в поиске найдут инфу из этого инфоблока, то при переходе пользователь попадет на 404 страницу.

Другой пример, когда для заказов, которые падают в отдельный инфоблок, забывают запретить индексацию и правильно указать доступ. Таким образом, заявки могут попасть в результаты поиска по сайту.

8. Удобство работы с динамическим контентом

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

9. Дизайн не ломается при включенном режиме редактирования страниц

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

10. Удобно управлять меню навигации на сайте

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

11. Возможность управлять структурой каталога

Иногда в готовых решениях нет возможности изменять структуру каталога. Например, в разделе «Услуги» в корпоративном сайте. Как разработчик предусмотрел структуру в 3 уровня, так пользователь и должен делать свой сайт, подстраиваясь под нее. Это неверно. Структура разделов должна быть гибкой хотя бы в каких-то пределах. Если услуг в компании мало, то должна быть возможность выводить их без группировки по разделам. Если много, то с группировкой. Понятно, что это относится не только к разделу «Услуги».

12. Используется стандартная обжимка изображений

Разработчики, для обработки изображений для вкладок «Анонс» и «Подробнее» используют собственные обработчики, которые нельзя настроить иначе, кроме как, подправив код. Используйте там, где можно стандартный битриксный функционал.

13. Большие изображения хранятся в обработанном виде

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

14. В настройках компонента нет лишних/неработающих галочек

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

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

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

15. Используются подсказки к полям

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

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

16. Есть фавиконка

Пусть стандартная, но есть. Чтобы пользователь, увидев ее, захотел ее заменить (или не захотел). Но это точно лучше чем если ее совсем не будет. Кстати, было бы здорово, чтобы в Битриксе, в настройках для конкретного сайта появилось поле «Фавиконка», где можно было бы указать путь до своего файла favicon.ico или загрузить его. Один раз загрузить фавиконку вручную нетрудно. Но мы же говорим сейчас про готовые решения, в которых нужно дать юзеру по максимум возможностей заменить контент на свой. В этом плане фавиконка ничем не хуже логотипа.

17. Список продукции выглядит по-разному для разных товаров

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

18. Есть возможность отключения части богатого функционала

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

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

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

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

19. Верстка, с учетом возможного отсутствия каких-либо блоков на странице

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

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

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

20. На главной странице есть заголовок h1

Удивительно, но во многих готовых решениях на главных страницах нет заголовка H1. 

Сеошники негодуэ.

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

Встречаются противоположные ситуации. Когда заголовков H1 на главной странице больше одного. Это тоже неправильно.

21. Корректная 404 страница

У всех решений, которые я видел, 404 страницы были разными для разных случаев. Для статики одна, для отсутствующего элемента инфоблока другая. Иногда выводится страница 404, а код ответа у нее 200, что вообще нонсенс. Друзья, тестируйте 404 страницы.

22. Возможность легко редактировать содержимое ланг-файлов

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

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

Заключение

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

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

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