Готовые решения – отличная штука. Можно даже сказать, что это переворот в разработке сайтов, такой же, каким в свое время был фабричный пошив одежды и обуви. Проблема в том, что пока это все в теории. Готовые решения сейчас, по большей части ни фига неготовые. Их, обычно приходится обрабатывать наждачкой, а иногда напильником. И дело тут не кривых руках программиста. Конечному пользователю трудно оценить насколько программист наговнокодил. Но зато ему легко оценить косяки, которые допущены при проектировании и тестировании. Вот про них и поговорим. Полный текст статьи по ссылке.
Я перечислил 22 косяка, с которыми сталкивался как пользователь, работая с готовыми решениями. Ребята, не ленитесь пробегитесь по списку, проверьте как с этим обстоят дела в ваших готовых решениях. Именно проверьте. Вы будете думать что у вас этих косяков нет (потому что вы их не специально допустили), а на самом деле они есть. Это как с тем сусликом.
Кудренко Юрий, если инструмента нет, то почему это косяк РАЗРАБОТЧИКА ТИПОВОГО РЕШЕНИЯ?! В отличие от Алексея не буду выражать уважения к тому, кто просто пытается пиариться и разводит демагогию.
Вы сказали, что это ошибка. Я привёл вам конкретный пример. Он есть в моём типовом решении. Это не космос - это просто 4 колонки для вывода контактов. Элементарщина. И она нужна клиенту. И он может пожелать её изменить (сделать 3 колонки вместо 4). ОК, я допустил КОСЯК. Даже 2. КАК МНЕ ЕГО ИСПРАВИТЬ?!
Если 2 из 22 ваших пункта (т.е. почти 10%) просто ВРАНЬЁ, то почему кто-то должен доверять остальным вашим заявлениям?
Просто ни пункт 2, ни пункт 3 не решают проблему редактирования количества и геометрии колонок! Напомню:
Задойный Алексей написал: числом колонок (от 1 до 12, не для простоты без вложенности) шириной каждой колонки индивидуально (от 1 до 12) для каждого разрешения экрана (от 1 до 4) сдвигом колонки индивидуально (от 1 до 11) для каждого разрешения экрана (от 1 до 4) смещением колонки вправо (от 1 до 11) или влево (от 1 до 11) для каждого разрешения экрана (от 1 до 4)
Посчитаем количество параметров? 12*(1+4+4+4+4)=204 параметра!!! Если колонок будет не больше 4, то 4*(1+4+4+4+4)=68! И это только ГЕОМЕТРИЯ блока! ни один "обычный пользователь" в таком списке просто копаться не будет!
Алексей, Я вам ответил на ваш вопрос. Любой из вариантов, про который вы спросили "Серьезно?" точно лучше чем ваш вариант, когда код и оформление вставлены внутрь контента. Целый инфоблок для "Контакты" - почему нет. Зато пользователю удобно. Хоть 20 инфоблоков, по одному на каждую статичную страницу. Некрасиво в админке? Но это точно лучше чем "некрасиво в публичке" когда юзер сломает вашу страницу при первой же правке.
Алексей, я не буду с вами спорить. У вас своя программерская правда. Вы скидываете проблему на пользователя и уверены что правы. Это не правильно.
В отличие от Алексея не буду выражать уважения к тому, кто просто пытается пиариться и разводит демагогию.
Я заинтересован чтобы готовые решения приходилось меньше обрабатывать наждачкой. Этот пост написан специально, вдруг разработчики возьмут на вооружение. Потому что даже первые два пункта встречаются постоянно.
На этом спор с вами прекращаю. Не хотите прислушиваться к "голосу пользователя" - делайте как привыкли.
Целый инфоблок с 4 элементами контактов и 65 свойствами для описания геометрии каждого из них по вашему лучше?
Я вижу, что вы заинтересованы в самопиаре. Я смолчал когда вы в прошлый раз залили сюда ссылку на писюльку про безопасность. Хотя это был фактически рерайт маркетинговых материалов с сайта битрикса. Пользы от перечисления инстурментов 0.
беру свои слова обратно. инфоблок совсем разумный вариант. Ведь описывать у каждого элемента геометрию всех нет нужды.
Т.е. свойств останется 16. Но количество блоков либо не проверяем (и пользователь по прежнему может развалить сайт, хот ьи не так фатально, как если забудет закрыть div, но всё равно круто.
Алексей, чего вы так кипятитесь? Много косяков из списка нашли у себя? Так это же хорошо, зато теперь их не будет, если конечно вы под каждый из них оправдание не придумаете.
Целый инфоблок с 4 элементами контактов и 65 свойствами для описания геометрии каждого из них по вашему лучше?
Да, лучше. Я вам как пользователь говорю. Если бы я был прогер, то скорее всего согласился с вами.
Я вижу, что вы заинтересованы в самопиаре.
И в чем тут самопиар? Чтобы разработчики у меня что-то покупали? Разрабы битрикса не моя целевая аудитория. Да и если даже самопиар, он разве запрещен здесь? Тут многие свои продукты для МП пиарят.
Я смолчал когда вы в прошлый раз залили сюда ссылку на писюльку про безопасность.
Статья про безопасность написана для обычных юзеров. Поверьте, им интересно прочитать об этом простым языком. У меня такая же статья есть про SEO в битрисе и будет еще похожая.
Хотя это был фактически рерайт маркетинговых материалов с сайта битрикса. Пользы от перечисления инстурментов 0.
А еще там скриншоты из битрикса... Тоже косяк... ведь мог бы и с нуля нарисовать.
Кудренко Юрий написал: чего вы так кипятитесь? Много косяков из списка нашли у себя? Так это же хорошо, зато теперь их не будет, если конечно вы под каждый из них оправдание не придумаете.
Я нашёл в первую очередь вот те 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С-Битрикс».