Готовые решения – отличная штука. Можно даже сказать, что это переворот в разработке сайтов, такой же, каким в свое время был фабричный пошив одежды и обуви. Проблема в том, что пока это все в теории. Готовые решения сейчас, по большей части ни фига неготовые. Их, обычно приходится обрабатывать наждачкой, а иногда напильником. И дело тут не кривых руках программиста. Конечному пользователю трудно оценить насколько программист наговнокодил. Но зато ему легко оценить косяки, которые допущены при проектировании и тестировании. Вот про них и поговорим. Полный текст статьи по ссылке.
Я перечислил 22 косяка, с которыми сталкивался как пользователь, работая с готовыми решениями. Ребята, не ленитесь пробегитесь по списку, проверьте как с этим обстоят дела в ваших готовых решениях. Именно проверьте. Вы будете думать что у вас этих косяков нет (потому что вы их не специально допустили), а на самом деле они есть. Это как с тем сусликом.
Кудренко Юрий написал: чего вы так кипятитесь? Много косяков из списка нашли у себя? Так это же хорошо, зато теперь их не будет, если конечно вы под каждый из них оправдание не придумаете.
Я нашёл в первую очередь вот те 2, что выделил. Я когда-то создавал тему, где спрашивал сообщество "как лучше" и ответа толком не получил. Я пытался и экспериментировал и убил огромное количество сил на "универсальный компонент" (в решении ПАЛ он есть), вот только пользователи простые, как вы сказали, им не пользуются. А опытных пугает количество настроек.
Кудренко Юрий написал: Да, лучше. Я вам как пользователь говорю. Если бы я был прогер, то скорее всего согласился с вами.
В том и дело, что я большую часть времени провожу в шкуре админа и менеджера. И к пользователям весьма близок. Так что проблему-то я вижу. А решения нет. Потому и говорю вам, что это объективно не честно валить вину за это неудобство на разработчика. Я считаю, что это объективно говорит о потребности повышения квалификации контент-менеджеров. Увы "простых пользователей", это не спасёт. Мне их искренне жаль, но решения я не вижу.
Кудренко Юрий написал: Статья про безопасность написана для обычных юзеров. Поверьте, им интересно прочитать об этом простым языком. У меня такая же статья есть про SEO в битрисе и будет еще похожая.
СЕО не занимаюсь уже несколько лет, поэтому нет желания его обсуждать. А вот что из себя представляет статья по безопасности я сказал. Я показал её 1 товарищу, который был моим клиентом по безопасности когда-то. Он сказал, что это не помогло бы ему нифига. нет конкретики что делать, куда жать. Мне кажется точно так же. А то может ещё напишете статью про АПИ битриксовое "для обычных юзеров"? Типа "с такого-то года появилось новое ядро D7, теперь не надо писать старые прямые запросы, но пока ещё оно не всё охватывает и getlist по прежнему необходим для выборки элементов инфоблока. Это большой шаг вперёд. Юзайте Д7".
Кудренко Юрий, уверены про шапку? В ней есть меню - оно полезно при чтении длинной статьи. В эмуляторе iphone5 шапка занимает примерно 1/4. В принципе не смертельно.
Кудренко Юрий написал: Целый инфоблок для "Контакты" - почему нет. Зато пользователю удобно. Хоть 20 инфоблоков, по одному на каждую статичную страницу. Некрасиво в админке? Но это точно лучше чем "некрасиво в публичке" когда юзер сломает вашу страницу при первой же правке.
Этот вариант не верен для пользователя, который занимается контентом(говорю по себе - пришлось в свое время столкнуться с таким решением). Динамика и статика потому так и различаются, что это совсем разные вещи. Статическая страница - это страница на которой что-то разместили и в ближайшие пару месяц, а то и год не лезут. С ней не работают постоянно, разместили пусть и сложный контент и забыли на длительное время. Динамические - вот тут да нужен инфоблок, и всю работу вести через него. Из своего опыта: сделана была страница на которой все блоки (~20) были компонентами и включаемыми областями. Мне как контенщику нужно было изменить содержимое этой страницы по заданиям маркетологов. Я на это тогда убил 2/3 дня, я предлагал объединить весь код на 1 страницу и просто быстро видя все целиком в нужных местах подправить и не создавать такие проблемы, но увы маркетологам нужно чтобы было не вводить html теги, а то что на изменение содержимого такой страницы превращается в ад это мелочи.
Статическая страница - это страница на которой что-то разместили и в ближайшие пару месяц, а то и год не лезут. С ней не работают постоянно, разместили пусть и сложный контент и забыли на длительное время
В готовых решениях, купленных в Маркетплейсе, как раз в том и фишка, что все статичные страницы правят сразу после покупки. Вносят свой контент.
Вот представьте, купил юзер "готовое" решение, думает, сейчас заменю инфу за 1-2 дня и будет у меня сайт. А фиг. Нужно сначала хтмл выучить, потаму что те кто проектировал и программил решение, думают что кусок кода в контенте более православно, чем создать лишний инфоблок. А если покупатель залез и сломал, что ему делать? Писать в техподдержку? Идти писать заявление об уходе? 21 первый век на дворе. А юзеру нет возможности удобно править контент на сайте.
Кудренко Юрий написал: В готовых решениях, купленных в Маркетплейсе, как раз в том и фишка, что все статичные страницы правят сразу после покупки. Вносят свой контент.
Но опять же только 1 раз и не верстку, а именно тексты - соответсвенно легче открыть 1 страницу и заменить текст в тех же блоках на свой чем разгадывать как было задумано править и лазать по 20 новым инфоблокам или включаемым областям в поисках где и что
Волков Алексей, Отчасти да. Но юзер же не ясновидящий, он не догадается что конкретно эту статичную страницу нельзя править в визуальном редакторе. Он ее поправит и сломает. Как вариант, я передлагал (выше, Алексею Задойному) сделать кучу включаемых областей. Но это с точки зрения прогера тоже "не аккуратненько".
Несколько(не кучу) областей, если они логичны обязательно нужно делать. А для того чтобы не сломать в виз редакторе там php кода быть не должно. Включаемые области это тоже php код и если открыть страницу через визредактор на которой есть включаемые области или компоненты +текст вот в этом случае вероятность поломки велика(из своего опыта) иначе нет. Опять же если человек не додумается что править текущую страницу через визредактор нельзя он с подключаемой областью может накосячить, а если их более 2, то эта вероятность повысится в разы, а если еще и часть будет с компонентами, боюсь процент за полтинник точно перевалит.
И вот так будет выглядеть режим редактирования 1 элемента (простите за массштаб, но вроде бы видно всё и даже читается):
Вы точно уверены, что это лучше? Я готов перейти на такой вид разметки. Она не позволит сформировать микроразметку, что будет печально с точки зрения SEO (либо потребуется ещё добавить полей). И по-моему, она убийственна для редактора в не меньшей степени, чем приведённый выше код.
Если я сделаю так, я точно исправлю в ваших глазах эти 2 косяка? Только честно, ибо я реально это реализую (и даже добавлю в мастер установки переключатель "установить в виде HTML кода (для опытных пользователей) / установить в виде инфоблока".
18. Есть возможность отключения части богатого функционала Некоторые решения имеют очень богатый функционал. Важно давать возможность отключать часть функционала. Например, обязательно должна присутствовать возможность отключать отзывы на странице с товаром, комменты, лайки, голосования.
Задойный Алексей, круто же? И никакие оправдания не придумывают. Нет функционала — дописали сами.
Если я сделаю так, я точно исправлю в ваших глазах эти 2 косяка? Только честно, ибо я реально это реализую (и даже добавлю в мастер установки переключатель "установить в виде HTML кода (для опытных пользователей) / установить в виде инфоблока".
Алексей, делайте как хотите. Это ваши пользователи. В моих глазах ничего не нужно исправлять. Можете заставить их заполнять по шаблону табличку в экселе, пристегивать получившийся файл, чтобы после парсить его при сохранении.
Хотелось бы от автора увидеть его решение собственное без этих косяков - есть такое?
Чтобы перечислить наиболее часто встречающиеся проблемы в ТР, не нужно уметь ходить по воде в белых одеждах.
Кстати, удивлен негативной реакцией. Конечно знал что будут кидаться какашками и тыкать пальцем, мол покажи сначала свое кунг-фу. Нет бы пробежаться по чеклисту и поправить у себя, хотябы мелочи. Но нет, будем тратить время на пустые споры и требовать конкретики, персонально к своему решению.
Я много работал с программистами. Даже говнокодеры всегда спорили с пеной у рта, что квадратные колеса, которые они придумали в велосипеде, плохо едут потому что архитектура битрикса кривая. В статье все с позиции пользователя (для них же работаем, разве нет?). Но, видимо, даже прогерам которые менеджеры проектов, трудно полноценно играть на стороне клиента, не подыгрывая временами брату-программисту.
21. У всех решений, которые я видел, 404 страницы были разными для разных случаев. Для статики одна, для отсутствующего элемента инфоблока другая. Иногда выводится страница 404, а код ответа у нее 200, что вообще нонсенс.
Кудренко Юрий написал: В статье все с позиции пользователя (для них же работаем, разве нет?).
Вот отсюда и начинается ботва.
Пользователей готовых решений можно условно разделить на 4 части: 1) плохо знает веб-технологии, не знает или почти не знает битрикс; 2) умеренно знает веб-технологии, не знает или почти не знает битрикс; 3) умеренно знает веб-технологии, слегка знает битрикс; 4) знает веб-технологии, хорошо знает битрикс.
Будете делать решение чисто для неопытных пользователей -- сделаете такое чудо на букву Г, от которого профи будет тошнить. И наоборот.
Многие пункты из ваших 22 можно оспорить, меняя позицию с 1 по 4. Ну, по приколу, давайте попробую:
1. Наличие в CSS нужных стилей для оформления контента (поз.1) Чо?
2. Наличие стилей в визуальном редакторе, чтобы их можно было удобно вставлять (поз. 1) Чо?
3. Предусмотрен адаптив под таблицы, видео, фотки (поз. 4) Это было в ТЗ? Включая тот код, который создаёт визредактор битрикса с его кошмаром типа <table width="1200">?
4. Простое создание статичных страниц (поз. 2) (голос со стороны): они в битриксе ваще шизанулись. Это чо, я должен что-то делать в админке, а что-то в публичке? Сделай нам так, чтобы всё редактирование сайта было в одном месте. В админке, блин!
5. Простая работа с контентом статичных страниц (поз. 2) (голос со стороны): ты уже сделал всё редактирование в одном месте? В админке, блин!
6. Контент во включаемых областях имеет минимум оформления и стилей (поз. 1-2-3) (голос со стороны): чо? Ты ваще пункт 4 читал?
8. Удобство работы с динамическим контентом (поз.4) А мне это уже говорили в комментариях к пункту 4.
9. Дизайн не ломается при включенном режиме редактирования страниц (поз. 4) Разумно
10. Удобно управлять меню навигации на сайте (поз. 1-2-3-4) Чо?
11. Возможность управлять структурой каталога (поз. 4) Надеюсь, под группировкой вы не имеете в виду GROUP BY?
12. Используется стандартная обжимка изображений - Не в теме -
13. Большие изображения хранятся в обработанном виде (поз. 1-2-3-4): Руки под одеяло! То есть, тьфу, руки прочь от чужих фоток!
14. В настройках компонента нет лишних/неработающих галочек (поз. 1, 2, 4) Дайте юзеру возможность настраивать компонент, и он всё сломает. Проверено.
15. Используются подсказки к полям (поз. 4) Ну, может быть.
16. Есть фавиконка (поз. 4) Если есть желание потрахаться с техподдержкой поз. 1-2, которые не могут сменить фавиконку, то вперёд.
17. Список продукции выглядит по-разному для разных товаров (поз. 1-2-3-4) Разумно
18. Есть возможность отключения части богатого функционала (поз. 1) Чо?
19. Верстка, с учетом возможного отсутствия каких-либо блоков на странице (поз. 1-2-3-4) Обязательно
20. На главной странице есть заголовок h1 (поз. 1-2-3-4) Обязательно
21. Корректная 404 страница (поз. 1-2-3-4) Обязательно
22. Возможность легко редактировать содержимое ланг-файлов (поз. 4) Пинайте битрикс на предмет усовершенствования их модуля перевода. В своём текущем виде он позволяет работать только с lang-файлами из /bitrix/.
Спасибо за статью, познавательно. Пожалуй, для меня из списка оказались актуальны лишь несколько (одно) замечаний:
3. Предусмотрен адаптив под таблицы, видео, фотки
Где-то добавили свои стили на эти случаи.
9. Дизайн не ломается при включенном режиме редактирования страниц
Вообще не напрягает, но верстка немного съезжает при включенном режиме редактирования. Это лечится?
18. Есть возможность отключения части богатого функционала
Как отметил Роман Забродин , эта проблема решена, неиспользуемые модули можно отключить, при чем отдельно на мобильной версии и ПК. Но не хватает возможности отключения js и css и прочих неиспользуемых ресурсов, т.к. все это в конечном счете влияет на быстродействие сайта.
Рамазанов Нариман написал: Но не хватает возможности отключения js и css и прочих неиспользуемых ресурсов, т.к. все это в конечном счете влияет на быстродействие сайта.
несколько раз писал с просьбой вынести все css и js файлы в компоненты, которые их используют... но пока тишина...
Группы на сайте создаются не только сотрудниками «1С-Битрикс», но и партнерами компании. Поэтому мнения участников групп могут не совпадать с позицией компании «1С-Битрикс».