Одним из самых популярных телевизионных героев детских мультфильмов в Чехии был Крот, невинное безмолвное и веселое существо, которое помогает другим животным в лесу.
Телевизионные герои часто сражаются против людей, которые разрушают их естественную среду. При просмотре мультфильма с моими детьми, я иногда представляю Крота как мобильного пользователя. Вы хотите знать, почему?
Мы, как веб-дизайнеры, часто относимся к нашим пользователям так же, как “плохие парни” относятся к Кроту, особенно на мобильных сайтах.
Один из эпизодов этой серии особенно драматичен. Старик пытается избавиться от крота в саду любыми средствами и в конечном счете пытается отравить его. Веб-дизайнеры делают то же самое, когда делают трудным использование мобильной версии веб-сайта и попытаются “отравить” пользователя, что в конце концов приводит к тому, что они покидают сайт.
Так что сегодня давайте будем немного саркастичными и попытаемся отравить мобильного пользователя. Как вам это? Просто следуйте моим инструкциям.
Давайте сделаем медленный веб-сайт, отключим масштабирование, скроем навигацию и заполним страницу элементами с фиксированным позиционированием. Я готов поспорить, что бедные мобильные пользователи не смогут этого пережить.
Создание сайта который медленно загружается – это лучше оружие против мобильных пользователей. Может посетитель успеет пойти на почтовое отделение и вернуться обратно до того, как сайт окончательно загрузится? Тогда вы делаете свою работу хорошо! Вы эффективно травите мобильного пользователя.
Теперь, давайте быть серьезными. Скорость передачи данных в сетях мобильной связи идет медленно, и даже если скорость увеличивается до 3G и 4G, сети есть не везде, и они просто не могут конкурировать с проводными.
Различные испытания и исследования показывают, что скорость загрузки сайта имеет существенное влияние на количество конверсий и общую эффективность сайта. Пользователь не должен ждать больше, чем на пару секунд пока сайт отрендерится, даже при использовании соединения EDGE.
Кроме того, не забывайте, что скорость сайта является одним из критериев, которые Google считает для результатов поиска и кампаний AdWords. Таким образом, она затрагивает не только конверсии, но и будут ли пользователи попадать на ваш сайт вообще.
Решение довольно простое: Подумайте о скорости, когда вы разрабатываете концепцию веб-сайта. Начните с бюджета производительности.
Оптимизация скорости загрузки не так уж и сложна. Позвольте мне поделиться с вами некоторыми практическими советы от Google:
- Сведение к минимуму передачу данных.
Минимизируйте CSS, JavaScript и HTML.
- Не блокировать визуализацию.
Удалите код JavaScript, препятствующий показу страницы.
Приоритетность видимого содержимого.
- Оптимизация back end.
Улучшение время отклика сервера.
Избегайте ненужных переадресаций.
У вас нет времени, чтобы прочитать это сейчас? Я полностью Вас понимаю. Сохранить текст для последующего использования. К счастью, есть доступные инструменты, чтобы сообщить вам, что случилось с вашим сайтом. Во-первых, проверить свой веб-сайт с PageSpeed Insights, а затем продолжите с WebPagetest.
Пользователь никогда не вернется.
Это правда, что различные исследования про карусели явно не говорят, что они не подходят. Тем не менее, карусели сложны как в реализации так и в пользовательском опыте. Таким образом, их использование является рискованным.
Карусель компании Nike (слева) не дает понять, что содержание по-прежнему справа. Best Buy (справа) продумали это лучше: Последующие элементы видны, и поэтому, очевидно, можно прокрутить вправо. (В увеличенной версии)
Весьма вероятно, что с помощью каруселей, вы будете скрываться некоторое содержимое, вместо того, чтобы продвигать его.
Согласно некоторым опросам, подавляющее большинство пользователей видят только первое изображение, и баннер на основе каруселей, как правило, просто игнорируются из-за «баннерной слепоты».
Если вы планируете использовать карусель в мобильных, убедитесь, что она соответствует следующим критериям:
- Не используйте карусель ради красивой картинки или чтобы скрыть ненужный контент.
Карусели сильны в рекламе вторичного контента, который связан с основным контентом.
- Используйте первый слайд, чтобы объявить другие слайды.
Основная цель первого слайда побудить пользователя просмотреть второй и третий слайды.
- Сделайте навигацию доступной на маленьких телефонах.
Эти маленькие точки, используемые в качестве навигации на рабочем столе, не считаются "годными" на мобильных телефонах!
- Убедитесь, что пользовательские жесты не вступают в конфликт с браузерными жестами по умолчанию.
Вы используете свайп? Убедитесь, что он не вступает в противоречие со встроенными в браузер жестами.
- Не замедляйте сайт.
Это связано в первую очередь со спросом и реализацией карусели данных.
Карусель NewEgg (слева) представляет собой традиционный подход. B&H (справа) является хорошим примером того как сохранение вертикального пространства и заманивание пользователя просматривать дополнительные слайды, показывая следующий.(В увеличенной версии)
Сделать навигацию легкодоступной? Давайте, серьезно! Вы могли бы покончить с тысячами пользователей.
Когда вы скрываете на сайте меню, люди перестанут использовать его. В недавно опубликованном исследовании,Nielsen Norman Group обнаружила что скрытая навигация на мобильном телефоне оказывает негативное влияние на понятность содержания, выполнения задачи и время, затраченное на нее.
Если есть что-то важное в навигации, и вы можете отобразить ее, сделайте это. Если вы не можете показать все меню, а затем упростить его или по крайней мере показать важные его части. По этой причине я склонен рекомендовать "приоритет плюс" навигационный шаблон.
Если навигация также несет содержание, всегда показывайте по крайней
мере несколько пунктов.(В увеличенной версии)
Что делать, если вы не можете показать важные детали? Хорошо, тогда, скрывайте его под значком «гамбургера», назовите его "Menu", и убедитесь, что пользователи могут использовать веб-сайт без меню.
Разогнать всех пользователей с помощью свайпа.
Я считаю, менее распространенные жесты более рискованными для мобильного интерфейса, по двум причинам:
- Пользовательские жесты могут вступать в конфликт с жестами в браузере по умолчанию.
Если ваша карусель поддерживает свайпы, например, пользователь может случайно выполнить "свайп за краешек" (жест очень похожий на обычное прикосновение), который некоторые мобильные браузеры интерпретируют как команду для перемещения по истории просмотра.
- Менее распространенные жесты неизвестны многим пользователям.
Таким образом, вы будете учить пользователя. Это имеет смысл, если мы говорим о ежедневно используемых приложениях, но не о сайтах.
Использование карусели не должно быть такой проблемой. Тем не менее, я видел новостные сайты поддерживающие свайп для навигации между статьями. Для пользователя, это необычно и сбивает с толку.
Свайп это не единственная проблема. При нажатии на нижнюю часть браузера Safari в iOS будет открыто скрытое меню. Поэтому, если вы вставляете элементы навигации в нижней части, пользователь возможно придется нажать дважды.
Перед использованием любого необычного жеста, тестируйте, нет ли конфликтов с браузерами в которых встроено использование жестов.
Один миллиметр достаточно хорошо.
Хорошо, давайте быть серьезными. Достаточно ли велики Ваши тап-области, что бы баскетболист мог легко нажать их своим большим пальцем?
В своей книге Дизайн для Тач, Джон Кларк ссылается на исследование Стивена Хубера и Патии Шанк. Исследователи обнаружили, что, если тап-области поместить в центре мобильного экрана, мишень может быть размером до 7 квадратных миллиметров; тем не менее, если их поместить в верхней или нижней части, оно должно быть не менее 11 квадратных миллиметров.
Тем не менее, миллиметры весьма непрактичны для использования в вебе. Мы используем пиксели, не так ли? Итак, как же мы имеем дело с разнообразием DPIs на мобильных устройствах? Вероятно, к удивлению большинства читателей, Джош Кларк говорит в своей книге:
Почти все мобильные браузеры теперь используют device-width аппаратно-ширину, размеров виртуального пикселя на примерно такую же плотность пикселей: 160 DPI является стандартом де-факто для сенсорного экрана веб-пикселей.
Опять же, все, что вам нужно сделать, это правильно установить мета-тег вьюпорта:
<meta name="viewport" content="width=device-width, initial-scale=1">
Существует еще один шаг: Используйте em или rem единицы, которые наилучшим образом подходят к адаптивным дизайнам. Размер шрифта по умолчанию для большинства браузеров составляет 16 пикселей, поэтому мы можем использовать следующее преобразование:
/* 7mm = 44px = 2.75rem */
.touch { height: 2.75rem; }
/* 11mm = 69px = 4.3125rem */
.touch-big { height: 4.3125rem; }
Вот так, ребята. Не забудьте указать фолбэк для старых браузеров. И если вы в курсе, я предлагаю вам купить книгу Джоша.
Заставить пользователя покинуть свой веб-сайт. Заставить их пойти купить телефон, который имеет "правильное" разрешение.
Мы сталкиваемся с огромным разнообразием разрешений экрана на мобильных устройствах. Раньше, только платформа Android была втянута, но теперь устройства компании Apple, тоже.
Даже если ваш сайт не "предназначен" для мобильных устройств, нет никаких
причин, чтобы не позволить мобильным пользователям получить быстрый взгляд.
Некоторые веб-сайты не приспособлены к конкретным размерам вьюпорта.
Какой позор!(В увеличенной версии)
Мы не можем предположить, что экраны смартфонов примерно 320 пикселей, что планшеты около 768 пикселей и настольные компьютеры более чем 1024 пикселей. Страница должна легко подстраиваться на экраны, которые 768 пикселей и ниже.
Итак, какие разрешения мы должны принимать во внимание? Все, мой друг.
В моей карьере разработчика, я тестировал отзывчивые сайты от 240 до примерно 2600 пикселей в ширину. Я признаю, что заставить сайт выглядеть отлично для всех размеров иногда не реально, но суть в том, что раскладка не должна развалиться - если ваши намерения не отпугнуть пользователей мобильных устройств.
Как и большинство из вас, я просто изменяю ширину окна браузера (или использую адаптивный режим в инструментах разработчика ) от наименьшего размера до полной ширины. Это своего рода "Ай! Режим ", найденный у Брэда Фроста в инструментах для тестирования.
Также, не изменять конструкцию, когда телефон переключается из портретной ориентации в ландшафтный режим.
Я думаю, что пользователи ожидают того же, или по крайней мере очень похоже, выглядят при просмотре веб-сайта, независимо от того, как они держат свой телефон. Я помню один из участников моих лекций рассказывал мне историю. Когда его компания переделывала веб-сайт, многие люди начали звонить в службу поддержки. Все они жаловались на конкретной ошибки: Меню сайта исчезало. Через некоторое время, они обнаружили, что это были пользователи планшетов. Когда они рассматривали сайт в ландшафтном режиме, меню было там. Если планшет был повернут в портретном режиме, меню было скрыто под иконкой "гамбургера".
Заставьте пользователя сердиться. Не допустить набор мобильного телефона прямо с сайта.
Контактирование с вами для мобильного пользователя сущий пустяк. Просто установите телефонный номер в виде ссылки, которая открывает меню вызова с уже набранным телефонным номером. Это похоже на активацию FaceTime, SMS и Skype на устройствах от Apple.
У нас есть проблема. Люди, как правило, не могут совершать звонки с настольного браузера. Тем не менее, вместо того, чтобы игнорировать телефонные ссылки, настольные браузеры открывают непонятное диалоговое окно, приглашающая пользователя выбрать приложение, чтобы сделать звонок. В большинстве случаев, нет такого подходящего приложения.
Дорогой друг, мы не хотим, отравить пользователей настольных компьютеров. Так, в этом редком случае, я рекомендую использовать обнаружение устройства и вставки активной ссылки только для мобильных пользователей.
В HTML, номер телефона будет неактивным. Мы просто обернуть его в тег span и
применяем Javascript позже
Phone: <span class="phone-number">123456789</span>
Использование JQuery и библиотеки обнаружения isMobile мы заменим
элемент a с классом phone-number:
if(isMobile.phone) {
$('.phone-number').each(function() {
$(this).replaceWith(
$('<a href="tel:' + this.innerHTML + '">' + this.innerHTML + '</a>')
);
});
}
На смартфоны, разметка выглядит следующим образом:
Phone: <a href="tel:123456789" class="phone-number">123456789</a>
Отключите масштабирование, если вы действительно хотите, достать пользователя. Это бесчеловечно - и очень эффективно.
Но если серьезно, отключив масштабирование, вы не только делаете жизнь немного более сложной для пользователей с плохим зрением. Даже пользователи с хорошим зрением зумят на мобильных устройствах, по разным причинам:
- чтобы увидеть изображение с близкого расстояния,
- более легко выбрать текст,
- для увеличения содержания с низкой контрастностью.
Масштабирование фактически отключено на значительной доле мобильных веб-сайтов. Рассмотрим важность просмотра деталей изображения в интернет-магазине. Масштабирование отключено на 40% сайтов электронной коммерции протестирована в институте Баймарда. Нелепо, не так ли?
Подобно тому, как пользователи настольных компьютеров не могут обойтись без кнопки возврата и прокрутки, так и мобильные пользователи нуждаются в масштабировании. Рекомендации по доступности от WCAG говорят нам, что пользователи должны иметь возможность увеличить размер текста на 200%.
Конечно, бывают случаи, когда нужно отключить масштабирование, например, для
неподвижных элементов. Но изменение масштаба иногда бывает невозможно случайно,
например, путем введения неправильного мета тега viewport. Одним единственно
правильным вариантом, в то время как неправильные теги содержат параметры,
такие как maximum-scale=1 и user-scalable=no.
<meta name="viewport" content="width=device-width, initial-scale=1">
Некоторые пользователи будут посещать ваш любимый веб-сайт и скопировать весь текст. Это шокирует и должно быть остановлено.
Дорогие друзья, установка свойства user-select в none может
быть полезным, но только в части интерфейса, который вы ожидаете взаимодействия
пользователя , где выделение не может сделать ничего хорошего.
Поэтому я рекомендую не с помощью user-select: none только для следующих
элементов:
- иконку элемента навигации,
- каруселей с накладным текстом,
- элементы управления, такие как выпадающие и навигация.
Пожалуйста, никогда не отключайте выделение статического текста и изображений.
Если пользователь живет, чтобы увидеть загрузку страницы, убить их навсегда, сделав шрифт мерцающим или полностью скрыв содержимое.
Использование веб-шрифтов не является неправильным, но мы должны убедиться, что они являются первыми элементами веб-сайта для загрузки. Некоторые браузеры ждут веб-шрифты для загрузки перед отображением содержимого. Это известно как вспышка невидимого текста (Foit). Другие браузеры (Edge и Explorer) показывают правильную систему шрифтов, где вы меньше всего хотите, известный как вспышка текста без стилей (FOUT).
Существует третья возможность, вспышка поддельного текста (FOFT). При этом, содержание оказывается с обычным веб-шрифтом, а затем полужирным и курсивным отображаются сразу после.
FOUT на практике: Показаны системные шрифты лучше, чем показывает
пустой экран во время загрузки веб-шрифтов.(В увеличенной версии)
Мои проекты, как правило, на контентно-ориентированные веб-сайты, так что я предпочитаю, отобразить содержимое как можно быстрее, используя системный шрифт (FOUT). Это когда мне нравится браузеры Microsoft. Я также использую небольшую библиотеку с названием Font Face Observer. Давайте посмотрим на код. Во-первых, JavaScript:
var font = new FontFaceObserver('Webfont family');
font.load().then(function () {
document.documentElement.className += ' webfont-loaded';
});
А вот CSS:
body {
font-family: sans-serif;
}
.webfont-loaded body {
font-family: Webfont Family;
}
Каждый веб-сайт требует что-то разное. Обратитесь к Zach Leatherman в "исчерпывающее руководство по стратегии загрузки шрифтов.”
Если вы не можете отравить их с Вашей собственной стряпней, используйте соседскую.
Facebook, Twitter и Google кнопки не удобны для пользователей мобильных устройств, по двум причинам:
- Они загружают огромное количество данных и замедляют загрузку и рендеринг веб-сайтов.
Тесты показывают, что при использовании официальных кнопок социального обмена, посетители смогут скачать более 300 Кб в течение более чем 20 запросов.
- Они, как правило, бесполезно. Социальный обмен часто интегрируется в операционную систему.
Исследование Moovweb проводилось в течение одного года за 61 млн мобильных сессий показал, что только 0,2% пользователей мобильной связи занимаются социальным шарингом.
Подавляющее большинство социальных кнопок бесполезны, даже на рабочем столе. Использование особенно бесполезно в интернет-магазине, так как низкий показатель шарринга является демотивирующим для покупателя. Но давайте не будем идти туда. Мы пытаемся отравить мобильных чудовищ.
Если вы не хотите отравить мобильного пользователя, но Вам нужны кнопки социальных действий, попробуйте использовать URL-адресов в соцсети или плагин, такие как Social Likes, которая реализует их с меньшим воздействием на скорости загрузки.
“Убийца” разработчик, который имеет m. версию веб-сайта, еще один способ отравить пользователя. Ура!
Мы видим неисправные переадресации на практически любой другой веб-сайт с m с точкой версию.
Правильное применение выглядит следующим образом:
-
Если мобильный пользователь идет на
www.example.com/example, сервер обнаруживает их устройство и перенаправляет их наm.example.com/example(неm.example.com). То же самое происходит на мобильной версии, доступ с рабочего стола. -
Если URL-адрес не существует, то оставляя пользователя на настольной версии лучше, чем при перенаправлении их на главную страницу м-точка.
-
Пусть поисковые системы знают о двух версиях сайта с помощью
<link rel="alternate">или указав его в файле sitemap.xml. Подробное руководство находится в разделе помощи Google для веб-мастеров.
Идеальное решение является отзывчивый сайт, который обслуживает те же URL-адреса для всех устройств. М с точкой версия веб-сайта увеличивает затраты на разработку и обслуживание. Кроме того, это не единственный тип веб-сайта, которые могут быть оптимизированы для сильного смартфон UX или для скорости мобильной сети.
Прочитайте, что говорит Карен МакГрейн в своей книге Вперед Отзывчивый, ссылаясь на исследования Дуга Силларса, техническое руководство по производительности в программе Developer AT & T в:
Это миф, что единственный способ сделать быструю загрузку сайта на мобильных устройствах является т-точка. Хорошее кодирование и практика принятия решений может обслуживать до отзывчивые сайты, которые столь же быстро, как и любой другой метод.
Теперь, единственное, что осталось сделать, это скрыть то, что не нужно - контент, например
Скрыть контент от мобильного пользователя. Им не нужно это в любом случае.
Нравится вам это или нет, люди посещают веб-сайты, чтобы увидеть контент. Да, мы вынуждены жить среди таких злобных существ.
Пользователь ищет контент. Дайте им это как можно быстрее. Затем,
вы можете заставить их загрузить приложение или отправить свои контактные данные.
(В увеличенной версии)
К сожалению, много сайтов скрывают содержимое, по причинам, которые я не понимаю. Возможно, контент не тот, но я считаю, что трудно поверить. Многочисленные элементы могут скрывать нужное содержимое:
- Разрешение использование куков
Некоторые европейские сайты обязаны показывать уведомление о необходимости использования куков. И мы ничего не можем поделать. Тем не менее, это не означает, что объявление о куках должно быть фиксированным и занимать половину экрана.
- Окно чата или подписка на рассылку
Позиционирование элементов как зафиксированных очень неудачное на мобильных устройствах. Вы скрываете контент, за которым пришел пользователь, чтобы он увидел контент, в котором он не заинтересован. Использование этих элементов нормально, но избегайте фиксации их положения на мобильных устройствах.
- Скачать приложение в промежутке
Это больно. Некоторые веб-сайты приглашают Вас установить сопровождающие приложения, вместо того чтобы показывать вам содержимое. Но пользователи пришли посмотреть на веб-сайт! Вместо того, чтобы использовать смарт-баннеры или привычное приложение установить баннеры на Android, чтобы рекламировать свое родное приложение.
Google решил что, начиная с января 2017 года, перекрывание контента на мобильных сайтах будут применены штрафные санкции:
Контент, который визуально затемняется межстранично разочаровывают пользователей, потому что они не могут легко получить доступ к содержимому, что они ожидали, когда они проходили по результату поиска.
Страницы, которые показывают навязчивую межстраничную информацию ухудшают пользовательский опыт больше, чем страницы, содержание которых непосредственно доступно
Замечание, Google не будет штрафовать сайты, которые показывают межстраничную информацию, такие как разрешение на куки или подтверждения возраста на сайтах для взрослых.
Вот об этом. Теперь, давайте быть серьезными. Выше не было ничего "нового", не так ли?
Все больше оснований сожалеть о том, что подавляющее большинство отзывчивых сайтов отравляют мобильных пользователей.
Давайте подведем критическую информацию в короткий контрольный чек-лист:
- Достаточно ли быстро загружается ваш сайт?
Есть ли менее важные элементы которые блокируют более важные из них? Вы выбрали оптимальную стратегию для визуализации веб-шрифта? Сторонних плагинов (например, для социальных медиа) замедляя сайт?
- Вы скрываете контент?
Фиксированные элементы, появляющиеся на пути? Вы скрываете контент для конкретных разрешений или в ландшафтном или портретном режиме?
- Подходит ли пользовательский интерфейс для мобильных устройств?
Являются ли тап-цели достаточно большими? Есть сложные элементы интерфейса, такие как карусели правильно реализованы ли они на мобильном телефоне? Интерактивны ли номера телефонов? Контент доступен для выделения? Вы делаете навигацию видимой везде, где это возможно?
- Уважаете ли родные браузеры?
Вы отключаете масштабирование случайно? Поддерживаете ли вы жесты, которые конфликтуют с браузером по умолчанию?
- Ваше перенаправление реализовано правильно (если вы используете м-точка версии)?
Будьте добры к мобильным пользователям. Не будь нечестивым стариком, который пытается избавиться от Крота во дворе своего дома. Вы хотите знать, как заканчивается сказка? Крот выживает, смеется над стариком и переезжает в другой сад.