Так уж получилось, что 2015 год стал первым годом коммерческой жизни нашего ещё совсем молодого проекта Бонджойн. Несмотря на то, что мы набрали около 85 0000 партнёров, которые выполнили большинство заказов, понятно, что нам расти и расти. Мы уже рассказывали о некоторых муках разработки, а сегодня решили сделать староновогодний пост про шишки web-разработчиков: столь же популярные и неизбежные, как оливье на наших новогодних столах. Какие-то из них мы набивали сами, какие-то заботливо собрали у знакомых и не совсем знакомых разработчиков. В лучших традициях приготовления ещё не до конца ушедшего новогоднего настроения расскажем обо всём подряд, вразнобой, сдобрив комиксами, которые мы перевели специально по случаю. В общем, угощайтесь!
Отсутствие проверки данных, вводимых пользователем на сайте. Как правило, фреймворки изначально поставляют такие проверки, но тут и кроется опасность — подход разработчика может быть формальным. К тому же, алгоритм проверки фреймворка может быть хорошо известен злоумышленникам. Не поленитесь написать лишний код, чтобы защитить свой сайт (портал) от неприятностей, среди которых уверенное лидерство лидерство держит обычная SQL-инъекция.
Односложная авторизация. Чем отличается аутентификация от авторизации? Аутентификация рассказывает нам, кто зашёл на сайт и с какими данными (узнаём пользователя), авторизация даёт пользователю право совершать на сайте какие-то действия. Иногда случается, что разработчик предусматривает только авторизацию, без предварительной аутентификации, а это чревато тем, что под похищенным логином и паролем пользователя скрывается совсем не он. Продумайте механизм совмещения аутентификации и авторизации на сайте, а если ваш веб-сервис предполагает серьёзную работу с данными пользователя, внедрите дополнительные проверки подлинности пользователя (например, периодическое подтверждение e-mail).
Раз речь зашла о мошенниках, то ещё одна оплошность — невнимание к безопасности, если предусмотрена оплата через сайт. Используйте надёжные платёжные шлюзы (платёжных систем или банков), избегайте оплаты через квитанцию или на счёт кошелька частного лица. Во-первых, ненадёжную платёжную систему можно подвергнуть фишингу, а во-вторых пользователи стали продвинутыми и использование оплаты по принципу «номер кошелька для оплаты» резко снижает уровень доверия к сайту.
Плохо спрогнозированные нагрузка на сайт и будущие планы развития проекта. Это практически тест на оптимизм — верит разработчик в проект или заранее определил ему потолок роста. А если серьёзно, то на этапе разработки многие компании не задумываются о будущем росте (часто по причине спешки перед публичным запуском) и в итоге сайт не выдерживает даже средних нагрузок. Та же история с масштабируемостью — изначально неграмотно спроектированные веб-сервис и база данных создают узкие рамки для сайта и в случае расширения приходится всё переписывать практически с нуля. Между тем, рынок не ждёт. Поверьте, можно выйти на рынок с минимальным набором функционала, но при этом иметь мощную основу и на ней развиваться. С нашим Бонджойн вышло ровно так же: мы начали с небольшого набора разделов и возможностей, но хорошо продуманный бэкенд даёт на большую гибкость, возможность быстрого выпуска релизов и, уже в дальнейшем, развязывает руки как для функционального наполнения, так и для изменения дизайна.
Как ни странно, но многие не думают о SEO на начальном этапе разработки. Может, раньше, при продвижении купленными ссылками, эта экономия времени и была оправдана, но сегодня, с ростом веса поведенческих факторов и роли качества и организации контента, лучше думать о поисковом продвижении сразу. Тогда ещё на этапе создания сайта или портала вы сможете отследить дублирование контента, выстроить правильную архитектуру сайта (с максимальным удобством навигации для пользователей, а не для роботов), поработаете над временем загрузки (это критично!), проработаете механизм возвращения к предыдущей странице, поиска на сайте, изначально решите вопрос перелинковки.
Тяжеловесный контент — серьёзная ошибка разработчиков, особенно, если он уже промахнулся с масштабом будущего сайта. Огромные фото, видео, тяжёлые фоновые изображения, безусловно, красивы, но пользователи их могут не увитдеть, покинув сайт, который медленно загружается. Как правило, тестируется сайт в локальной сети и вопросов с подгрузкой большого объёма контента не возникает. Однако, несмотря на вот уже вторую неделю 2016 года, у многих пользователей скорости соединения остаются весьма скромными. Прибавьте к этому 3G на мобильных и планшетах — и вот вы уже потеряли свой сегмент. Так что, делая навороты, помните о пользователях. А заодно продумайте, где будет размещаться контент и хватит ли, например, для многочисленных пользовательских галерей мощности вашего собственного сервера.
Кстати, о 3G. До сих пор многие разработчики закрывают глаза на мобильную версию сайта и полностью игнорируют респонсивность. Если вы сомневаетесь в необходимости адаптировать сайт под мобильные устройства, зайдите в любой магазин гаджетов и посмотрите на размах размеров экранов — все эти устройства уже в руках у ваших будущих клиентов. Существует множество моделей для респонсибилизации веб-сервиса и практик по созданию соответствующих веб-приложений, есть общие, есть специфические для платформ. Из популярных и простых, наверное, стоит выделить Twitter Bootstrap, опенсорсный HTML, CSS, JavaScript фреймворк, работающий на всех платформах. С ним вы получите хорошо адаптированный сайт без лишних накладных расходов.
Однако адаптироваться нужно не только к размеру экрана, но и к зоопарку браузеров. Нередко разработчики игнорируют кроссбраузерность или отказываются поддерживать старые версии. Если лично вы проводите 90% времени в Google Chrome, это не значит, что так же поступают остальные — после запуска эта гипотеза легко проверяется с помощью Яндекс.Метрики и Google Analytics. На самом деле, есть множество мнений о том, что разрабатывать нужно под один браузер или только под самые популярные, однако это не совсем верно. перед запуском проекта нужно проводить тестирование кроссбраузерности, а дальше действовать по обстоятельствам: либо прописывать правила поведения для отдельных браузеров, либо исключать для них неподдерживаемый функционал. Главное, не в ущерб пользователям.
Сайт может быть приложением для бизнеса (например, для продавца строительных материалов — это каталог и прайс онлайн), может быть частью бизнеса (техподдержка и продажи через сайт вендора CRM), а может быть и самим бизнесом (СМИ, сервисы, тот же наш Бонджойн). И если в первом варианте некачественная работа с сайтом приведёт к затуханию одного из каналов продаж, то в двух остальных вполне способна парализовать бизнес. Поэтому нужно расценивать проект именно как бизнес, о чём многие забывают.
Неверная стоимость проекта. Зачастую, заказывая сайт или рассчитывая сделать его силами сотрудников, компании забывают, что получить свои страницы в своём домене — это начало пути. Непредвиденные и вполне обычные траты могут ожидать вас с самого начала: работа дизайнера, покупка фотографий и шрифтов, оплата хостинга для медиа-контента, SEO-оптимизация, контекстная реклама и т.д. Не говоря о том, что стоимость проекта может измениться вследствие изменения требований.
О требованиях также часто забывают. А они делятся на те, которые предъявляет к ресурсу бизнес и те, которые исходят от пользователей. Последние могут изменяться едва ли не раз в полгода, а значит, нужно закладывать в проект стоимость потенциальных изменений. Косность — плохой союзник для бизнеса, завязанного на интернете или на e-commerce. Поэтому будьте готовы вкладываться в развитие продукта на каждом этапе его существования. Иначе можно потерять рынок.
Наконец, самый большой блок рисков — это риски, связанные с юзабилити и дизайном сайта. Их существует бесконечно много и практически ни один сайт не обходится без своих историй, связанных с некорректным или перемудрёным дизайном. Мы рассмотрим наиболее общие случаи.
Сайт нравится дизайнеру и отражает всю меру его таланта. Сайт должен нравиться пользователям и решать его проблемы. Приоритет должен быть у практической пользы и юзабилити, а потом уже у дизайнерских находок. Интерфейс должен отвечать потребностям посетителей и помогать находить кратчайший путь до искомой информации, а вот чрезмерно креативный дизайн может запутать пользователя и отнять время на поиск нужного контента.
Сложные регистрационные формы. Перед тем, как внедрить на сайт форму с парой десятков обязательных полей или, чего доброго, ещё и с опросником, подумайте, какая информация является для вас по-настоящему ценной. Обычно после раздумий начинает хватать имени, телефона и электронной почты. Если предусмотрена покупка с сайта, то остальные данные можно получить при регистрации в сервисе или в ходе оформления заказа. Если поля обязательны, обозначайте их привычной звёздочкой — они не должны стать сюрпризом после заполнения всей формы и ввода умопомрачительной капчи (с ней тоже нужно оставаться людьми!).
На сайте нет поиска. Если на вашем сайте довольно много контента, то поиск по сайту обязателен. Для решения этой задачи можно использовать API Яндекса или Google Custom Search — формы добавляются в несколько строк кода и решают множество проблем, в том числе освобождают место от устаревших облаков тегов.
Сайт нечитабелен. Если вдохновения для организации текста, полученного на просторах Сети, вам недостаточно, обратитесь к самому популярному месту жительства текста — книгам. Обратите внимание на разбиение по абзацам и главам, вёрстку, буквицы, кернинг и проч. Вот и на сайте стоит избавиться от смешения шрифтов различных типов, причудливых букв, избежать игр с размерами. Не забывайте и о цветовых схемах. Пара проверенных советов: для тестирования цветовых схем используйте Adobe Kuler, а шрифты выбирайте без засечек (sans serif).
Контент организован нелогично, есть скрытые блоки. Не стоит избегать заголовков, подзаголовков и параграфов (если они нужны), вовремя избавляйтесь от устаревшего контента. Не нужно стремиться заполнить текстом и медиа весь предоставленный объём — экономия «бумаги» на сайте выглядит всегда душно, оставляйте незаполненные места для переключения внимания.
Плохая навигация чревата не только неудобством для пользователя, но и проблемами с поведенческим фактором в SEO. Считается, что если пользователь не находит информацию за три клика, он с большой вероятностью покидает сайт. Ссылки и переходы должны быть очевидными и логичными, если есть неразрешимая проблема разночтения, лучше добавьте к элементу меню или ссылке тултип с подсказкой.
Горизонтальный скроллинг — дизайнерское решение, так и не нашедшее себя в web. Он относится явно к нестандартному поведению пользователя и может ввести в замешательство даже опытного посетителя. Рецепт прост: используйте горизонтальные решение, с якорями, скроллом и прочими эффектами.
Небольшие, но значимые вещи, о которых стоит помнить при старте любого web-проекта.
Кажется, что изложены довольно очевидные вещи. Но они повторяются на различных сайтах с завидной частотой. Надеемся, что наш чек-лист поможет разработчикам, стартующим очередной web-проект. Прошедший год для команды Бонджойн был насыщенным и мы рады поделиться опытом буквально через несколько дней после его окончания. Желаем вам успешных проектов, юзабельных интерфейсов, умных и красивых решений, правильного скроллинга и задела для роста! Спасибо, что были с нами, ругали, вдохновляли и меняли нас. С Новым рабочим годом, Хабр!
P.S.: За основу комиксов взяты работы дизайнера Джерри Кинга (Jerry King). Если вы цените юмор на английском языке и любите веб-дизайн, остальные комиксы можно посмотреть на www.webdesignerdepot.com. Ну и вообще там много полезного материала — как раз к началу нового рабочего года.
Пользовательские риски
Отсутствие проверки данных, вводимых пользователем на сайте. Как правило, фреймворки изначально поставляют такие проверки, но тут и кроется опасность — подход разработчика может быть формальным. К тому же, алгоритм проверки фреймворка может быть хорошо известен злоумышленникам. Не поленитесь написать лишний код, чтобы защитить свой сайт (портал) от неприятностей, среди которых уверенное лидерство лидерство держит обычная SQL-инъекция.
Односложная авторизация. Чем отличается аутентификация от авторизации? Аутентификация рассказывает нам, кто зашёл на сайт и с какими данными (узнаём пользователя), авторизация даёт пользователю право совершать на сайте какие-то действия. Иногда случается, что разработчик предусматривает только авторизацию, без предварительной аутентификации, а это чревато тем, что под похищенным логином и паролем пользователя скрывается совсем не он. Продумайте механизм совмещения аутентификации и авторизации на сайте, а если ваш веб-сервис предполагает серьёзную работу с данными пользователя, внедрите дополнительные проверки подлинности пользователя (например, периодическое подтверждение e-mail).
Раз речь зашла о мошенниках, то ещё одна оплошность — невнимание к безопасности, если предусмотрена оплата через сайт. Используйте надёжные платёжные шлюзы (платёжных систем или банков), избегайте оплаты через квитанцию или на счёт кошелька частного лица. Во-первых, ненадёжную платёжную систему можно подвергнуть фишингу, а во-вторых пользователи стали продвинутыми и использование оплаты по принципу «номер кошелька для оплаты» резко снижает уровень доверия к сайту.
Плохо спрогнозированные нагрузка на сайт и будущие планы развития проекта. Это практически тест на оптимизм — верит разработчик в проект или заранее определил ему потолок роста. А если серьёзно, то на этапе разработки многие компании не задумываются о будущем росте (часто по причине спешки перед публичным запуском) и в итоге сайт не выдерживает даже средних нагрузок. Та же история с масштабируемостью — изначально неграмотно спроектированные веб-сервис и база данных создают узкие рамки для сайта и в случае расширения приходится всё переписывать практически с нуля. Между тем, рынок не ждёт. Поверьте, можно выйти на рынок с минимальным набором функционала, но при этом иметь мощную основу и на ней развиваться. С нашим Бонджойн вышло ровно так же: мы начали с небольшого набора разделов и возможностей, но хорошо продуманный бэкенд даёт на большую гибкость, возможность быстрого выпуска релизов и, уже в дальнейшем, развязывает руки как для функционального наполнения, так и для изменения дизайна.
Как ни странно, но многие не думают о SEO на начальном этапе разработки. Может, раньше, при продвижении купленными ссылками, эта экономия времени и была оправдана, но сегодня, с ростом веса поведенческих факторов и роли качества и организации контента, лучше думать о поисковом продвижении сразу. Тогда ещё на этапе создания сайта или портала вы сможете отследить дублирование контента, выстроить правильную архитектуру сайта (с максимальным удобством навигации для пользователей, а не для роботов), поработаете над временем загрузки (это критично!), проработаете механизм возвращения к предыдущей странице, поиска на сайте, изначально решите вопрос перелинковки.
Тяжеловесный контент — серьёзная ошибка разработчиков, особенно, если он уже промахнулся с масштабом будущего сайта. Огромные фото, видео, тяжёлые фоновые изображения, безусловно, красивы, но пользователи их могут не увитдеть, покинув сайт, который медленно загружается. Как правило, тестируется сайт в локальной сети и вопросов с подгрузкой большого объёма контента не возникает. Однако, несмотря на вот уже вторую неделю 2016 года, у многих пользователей скорости соединения остаются весьма скромными. Прибавьте к этому 3G на мобильных и планшетах — и вот вы уже потеряли свой сегмент. Так что, делая навороты, помните о пользователях. А заодно продумайте, где будет размещаться контент и хватит ли, например, для многочисленных пользовательских галерей мощности вашего собственного сервера.
Кстати, о 3G. До сих пор многие разработчики закрывают глаза на мобильную версию сайта и полностью игнорируют респонсивность. Если вы сомневаетесь в необходимости адаптировать сайт под мобильные устройства, зайдите в любой магазин гаджетов и посмотрите на размах размеров экранов — все эти устройства уже в руках у ваших будущих клиентов. Существует множество моделей для респонсибилизации веб-сервиса и практик по созданию соответствующих веб-приложений, есть общие, есть специфические для платформ. Из популярных и простых, наверное, стоит выделить Twitter Bootstrap, опенсорсный HTML, CSS, JavaScript фреймворк, работающий на всех платформах. С ним вы получите хорошо адаптированный сайт без лишних накладных расходов.
Однако адаптироваться нужно не только к размеру экрана, но и к зоопарку браузеров. Нередко разработчики игнорируют кроссбраузерность или отказываются поддерживать старые версии. Если лично вы проводите 90% времени в Google Chrome, это не значит, что так же поступают остальные — после запуска эта гипотеза легко проверяется с помощью Яндекс.Метрики и Google Analytics. На самом деле, есть множество мнений о том, что разрабатывать нужно под один браузер или только под самые популярные, однако это не совсем верно. перед запуском проекта нужно проводить тестирование кроссбраузерности, а дальше действовать по обстоятельствам: либо прописывать правила поведения для отдельных браузеров, либо исключать для них неподдерживаемый функционал. Главное, не в ущерб пользователям.
Бизнес-риски
Сайт может быть приложением для бизнеса (например, для продавца строительных материалов — это каталог и прайс онлайн), может быть частью бизнеса (техподдержка и продажи через сайт вендора CRM), а может быть и самим бизнесом (СМИ, сервисы, тот же наш Бонджойн). И если в первом варианте некачественная работа с сайтом приведёт к затуханию одного из каналов продаж, то в двух остальных вполне способна парализовать бизнес. Поэтому нужно расценивать проект именно как бизнес, о чём многие забывают.
Неверная стоимость проекта. Зачастую, заказывая сайт или рассчитывая сделать его силами сотрудников, компании забывают, что получить свои страницы в своём домене — это начало пути. Непредвиденные и вполне обычные траты могут ожидать вас с самого начала: работа дизайнера, покупка фотографий и шрифтов, оплата хостинга для медиа-контента, SEO-оптимизация, контекстная реклама и т.д. Не говоря о том, что стоимость проекта может измениться вследствие изменения требований.
О требованиях также часто забывают. А они делятся на те, которые предъявляет к ресурсу бизнес и те, которые исходят от пользователей. Последние могут изменяться едва ли не раз в полгода, а значит, нужно закладывать в проект стоимость потенциальных изменений. Косность — плохой союзник для бизнеса, завязанного на интернете или на e-commerce. Поэтому будьте готовы вкладываться в развитие продукта на каждом этапе его существования. Иначе можно потерять рынок.
Дизайнерские риски
Наконец, самый большой блок рисков — это риски, связанные с юзабилити и дизайном сайта. Их существует бесконечно много и практически ни один сайт не обходится без своих историй, связанных с некорректным или перемудрёным дизайном. Мы рассмотрим наиболее общие случаи.
Сайт нравится дизайнеру и отражает всю меру его таланта. Сайт должен нравиться пользователям и решать его проблемы. Приоритет должен быть у практической пользы и юзабилити, а потом уже у дизайнерских находок. Интерфейс должен отвечать потребностям посетителей и помогать находить кратчайший путь до искомой информации, а вот чрезмерно креативный дизайн может запутать пользователя и отнять время на поиск нужного контента.
Сложные регистрационные формы. Перед тем, как внедрить на сайт форму с парой десятков обязательных полей или, чего доброго, ещё и с опросником, подумайте, какая информация является для вас по-настоящему ценной. Обычно после раздумий начинает хватать имени, телефона и электронной почты. Если предусмотрена покупка с сайта, то остальные данные можно получить при регистрации в сервисе или в ходе оформления заказа. Если поля обязательны, обозначайте их привычной звёздочкой — они не должны стать сюрпризом после заполнения всей формы и ввода умопомрачительной капчи (с ней тоже нужно оставаться людьми!).
На сайте нет поиска. Если на вашем сайте довольно много контента, то поиск по сайту обязателен. Для решения этой задачи можно использовать API Яндекса или Google Custom Search — формы добавляются в несколько строк кода и решают множество проблем, в том числе освобождают место от устаревших облаков тегов.
Сайт нечитабелен. Если вдохновения для организации текста, полученного на просторах Сети, вам недостаточно, обратитесь к самому популярному месту жительства текста — книгам. Обратите внимание на разбиение по абзацам и главам, вёрстку, буквицы, кернинг и проч. Вот и на сайте стоит избавиться от смешения шрифтов различных типов, причудливых букв, избежать игр с размерами. Не забывайте и о цветовых схемах. Пара проверенных советов: для тестирования цветовых схем используйте Adobe Kuler, а шрифты выбирайте без засечек (sans serif).
Контент организован нелогично, есть скрытые блоки. Не стоит избегать заголовков, подзаголовков и параграфов (если они нужны), вовремя избавляйтесь от устаревшего контента. Не нужно стремиться заполнить текстом и медиа весь предоставленный объём — экономия «бумаги» на сайте выглядит всегда душно, оставляйте незаполненные места для переключения внимания.
Плохая навигация чревата не только неудобством для пользователя, но и проблемами с поведенческим фактором в SEO. Считается, что если пользователь не находит информацию за три клика, он с большой вероятностью покидает сайт. Ссылки и переходы должны быть очевидными и логичными, если есть неразрешимая проблема разночтения, лучше добавьте к элементу меню или ссылке тултип с подсказкой.
Горизонтальный скроллинг — дизайнерское решение, так и не нашедшее себя в web. Он относится явно к нестандартному поведению пользователя и может ввести в замешательство даже опытного посетителя. Рецепт прост: используйте горизонтальные решение, с якорями, скроллом и прочими эффектами.
Соль, перец по норме
Небольшие, но значимые вещи, о которых стоит помнить при старте любого web-проекта.
- Не стоит использовать картинки, карусели, анимацию и Flash без нужды.
- Не используйте на сайте звуковые эффекты, если в этом не прямой необходимости — это может раздражать пользователя.
- Встраивайте рекламные блоки и баннеры органично — если ваш сайт не будут посещать из-за перегруженности спамом, больше вы не заработаете.
- Предусматривайте средства воспроизведения видео и аудио, не оставляйте пользователю шанс уйти на сторонний сайт.
- Делайте области для клика по ссылке или элементу меню шире: пальцем и курсором легко промахнуться.
- Оставляйте контакты, формы обратной связи и реагируйте на фидбэк.
- Не забывайте делать переход на главную страницу сайта по клику на логотип или название компании на странице.
- Следите за скоростью загрузки.
- Следите за статистикой сайта, особенно в разрезе используемых технологий.
Кажется, что изложены довольно очевидные вещи. Но они повторяются на различных сайтах с завидной частотой. Надеемся, что наш чек-лист поможет разработчикам, стартующим очередной web-проект. Прошедший год для команды Бонджойн был насыщенным и мы рады поделиться опытом буквально через несколько дней после его окончания. Желаем вам успешных проектов, юзабельных интерфейсов, умных и красивых решений, правильного скроллинга и задела для роста! Спасибо, что были с нами, ругали, вдохновляли и меняли нас. С Новым рабочим годом, Хабр!
P.S.: За основу комиксов взяты работы дизайнера Джерри Кинга (Jerry King). Если вы цените юмор на английском языке и любите веб-дизайн, остальные комиксы можно посмотреть на www.webdesignerdepot.com. Ну и вообще там много полезного материала — как раз к началу нового рабочего года.