Сподвиг изложить некоторые соображения редизайн одного из сайтов коллег. Как результат, уже изложил Какой «профи» не мечтает о «хлебных крошках»? Но такой момент – лишь частный случай. Проблематика – гораздо шире.
Уважать посетителя и учитывать его психологию
Пожалуй, это самое главное.
Та или иная степень Usability – следствие, а не причина.
И либо вы понимаете, что делаете, для кого, что радует посетителя, а что раздражает… Либо не понимаете.
Существенный момент, последнее относится не к разработчику сайта, а к заказчику.
Разработчик за деньги заказчика сделает все, что тот захочет. Единственно, сделает — как умеет.
И да, разработчика поменять можно, но если именно заказчик не уважает потенциального посетителя и не способен учитывать его психологию, какой в этом смысл?
Конечно, «объять необъятное невозможно». Тот или иной представитель заказчика в силу разных причин может и не быть «в теме». Оставим «за скобками» — «зачем он такой».
Тем не менее,
«в менеджменте нет правильных или неправильных решений, но есть решения, которые влекут за собой те или иные последствия».
И потому, неплохо бы, если не заказчику в целом, то хотя бы его представителю, пусть даже он сам и будет не «в теме», слушать и слышать специалистов.
Дизайн – не только внешний вид, но и технологии
Технологии интернета и технологии психологии.
Одно и тоже отобразить можно различными способами. Но заказчику, даже если он и сам этого не осознает, нужен не внешний вид, а его эффективность.
Главным образом – исходя из психологии посетителя.
Забота о скорости загрузки сайта – в этой связи не кем-то навязанная самоцель, а следствие. Следствие обеспечения максимальной эффективности.
Размещение тех или иных элементов, в т.ч. рекламы, и их последовательность, либо отказ от их использования – тоже не самоцель, а следствие обеспечения максимальной эффективности.
Как и учет взаимодействия контентного сайта со сторонними сервисами.
В противном случае – «за ради чего» вся затея?
Разумеется, технологии интернета эволюционируют быстрее, чем психология восприятия посетителя. И изменения необходимо отслеживать, оценивать, в необходимых случаях – использовать. Но снова – не как самоцель, а как средство достижения максимальной эффективности.
«Mobile First» — «забили» на «Desktop»?
Разумеется, аудитория контентного сайта, особенно новостного, по типам устройств примерно такова:
Смартфоны – 80-85 процентов,
Планшеты – до 5 процентов,
Десктопы – 15-20 процентов.
Доля последних, прямо скажем, не велика.
Но означает ли это, что таких посетителей можно перестать уважать и заботиться о них?
Всего один момент: ширина отображаемого текста. К примеру, на мониторе диагональю более 20-ти дюймов.
Можно по-разному относиться к Яндекс Дзен, но ширина основного текста при отображении на мониторе 1920х1080 составляет 600px – даже меньше, чем треть. У Пульса в полнотексте или блоге — 630px.
Можно было бы привести аналогичный пример для декстопного варианта turbo-страниц Яндекса, но их поддержку остановили.
Конечно, можно считать, что многие разработчики и заказчики понимают в психологии посетителя намного больше, чем сотрудники Яндекса. Как минимум, те, что заставляют совершать голову декстопного посетителя движения «влево-вправо», чтобы охватить размещенную почти на всю ширину монитора строку от начала до конца.
А другие – даже на десктопе отображают основной текст шириной от 500 до 600 пикселей. Потому как «скролить», т.е. крутить колесико «мышки», посетителю намного менее напряжно.
Или так называемая «выключка» текста, в любом текстовом редакторе есть, вспомните: «влево», «вправо», «по ширине». На бумажном документе последняя часто выглядит достойно, четкие границы, так и веет официозной выверенностью.
А на сайте? Особенно при просмотре текста на смартфоне? На мой взгляд, отвратительно. Судя по всему, и на взгляд многих, что называется, законодателей. Тем не менее есть те, кто и в этом стремиться быть «отличным от других». Остается удивляться лишь тому, что желающих ездить по встречке, исходя точно такого же принципа, все же меньше.
Для чего редизайн?
Вариантов ответа у заказчика может быть много, например, такие:
— «хотца!»,
— «на то они и друзья, чтоб дать заработать своим!»,
— «админ хочет – пусть делает, лишь бы отстал».
Можно привести и более экзотические.
А самый простой:
чтобы было лучше, как с точки зрения технологии, так с точки зрения психологии посетителя, как для восприятия собственно контента, так и рекламы (последнее не только для красоты, но и для повышения доходности).
Единственно, всегда ли действительно становится лучше? Особенно, если и заказчик, и подрядчик-разработчик не знают – «что такое хорошо, что такое плохо» на самом деле.
Казалось бы, мелочь, но если после редизайна скорость загрузки страницы сайта стала хуже – оно действительно того стоило?
И да, самый простой способ эту скорость проверить — PageSpeed Insights.
Начните проверку с главной страницы, затем – собственно публикации и архивы.
Если ваш сайт на выделенном сервере, но с кодом Яндекс Метрики и РСЯ, увы, для мобильной версии хороший результат показателя «Производительность» и 60-80 баллов. Без них – 95-100.
Когда будете смотреть на результаты сайта, основное внимание обратите на 2 показателя:
Largest Contentful Paint;
Cumulative Layout Shift.
Первый для мобильных устройств должен быть не более 2,5 секунд, для компьютеров — не более 1 секунды.
Второй показатель — менее 0,1 для всех типов устройств. Нюанс, значения показателей даже на одной и той же странице могут «гулять». Причин может быть много, разных, не все будут зависеть непосредственно от сайта и хостинга. Тем не менее, значения показателей в большинстве проверок должны быть именно такими, как указано.
Если у вас хуже – обязаны переспросить разработчика.
Если грубо, плохо на скорость загрузки могут влиять:
— сторонние коды,
— реализация сайта разработчиком,
— не соблюдение рекомендаций разработчика сотрудниками редакции (например, в части изображений).
С первым — вариантов не много: либо использовать, либо нет.
Со вторым – даже если разработчики друзья, должны переделать, вне зависимости от изначальной цены вопроса, как минимум потому, что вряд ли кто-то обязывал делать плохо.
С третьим – что делать, но кто-то же должен и сотрудников редакции контролировать. И либо это происходит, либо нет.
Но не редко есть и такой вариант: разработчик говорил «низя» и даже объяснял почему, но заказчик настоял. Вариант, кстати, не редкий. Но для разработчиков, пожалуй, самый неприятный. Ибо виновны, как правило, все равно будут они. Как минимум, именно так будут описывать «плодотворное» сотрудничество представители заказчика.
А самый весомый даже не «звоночек», а «набат» о том, что редизайн «удался на славу», когда число посетителей не увеличилось, а стало меньше. Увы, и такое бывает.
И причин последнего может быть очень много. С высокой степенью вероятности, чтобы исправить, придется обратиться к специалисту. Но это только если действительно надо.