5 месяцев, 26 дней и сколько-то часов прошло с момента коммита в git первых строчек кода Футубры. Столько времени у нас ушло, чтобы собрать команду, провести ряд исследований, проработать концепцию и реализовать проект, который сделает жизнь людей интереснее.
За эти полгода мы уже столкнулись (и продолжаем сталкиваться каждый день) c целым рядом задач и проблем логического, интерфейсного, технического и организационного характера. Опытом решения самых интересных из них мы и будем делиться с вами в этом блоге.
Первый пост хочется посвятить самому важному – базовым принципам, на которых строится Футубра:
- progressive enhancement
- mobile first
- responsive web design
Футубра – сервис мультимедийных микроблогов, публичную бета-версию которого мы открыли вчера.
Создавая Футубру, мы, прежде всего, думали о людях, похожих на нас с вами – активных, интересующихся новыми технологиями, мобильных, стремящиеся быть в курсе событий, познающих мир и открытых для всего нового. У такой аудитории ярко выражена потребность жить интереснее и Футубра создается, чтобы эту потребность удовлетворить. Мы делаем проект, которым сами будем с удовольствием пользоваться и которым сможем гордиться.
Первым принципом, которого мы договорились придерживаться при создании Футубры стал…
Progressive enhancement
Этот принцип сформулировал Steven Champeon аж в 2003 году и заключается он в использовании простой семантической html-верстки для представления всего контента и функционала, а CSS и JS должны быть лишь приятным улучшением пользовательского взаимодействия. Другими словами, ваш сервис должен быть полноценным и полнофункциональным даже при отключенном CSS и javascript на стороне клиента.
Этот принцип является противоположным традиционному принципу graceful degradation, когда разработчики ориентируются на самые развитые браузеры, а корректность работы проекта в старых или не поддерживающих каких-то возможностей браузерах реализуется по остаточному принципу.
Мотив
Новые модели мобильных телефонов появляются каждый день, количество мобильных платформ и различных по возможностям браузеров в них также постоянно меняется. Кроме того, в последнее время наметилась тенденция встраивания браузеров в неведомые до сих пор устройства, например, бортовые компьютеры автомобилей или телевизоры.
Мы хотели, чтобы Футуброй можно было пользоваться с любого устройства, где есть браузер и доступ в интернет, поэтому мы приняли решение придерживаться принципа progressive enhancement.
Плюсы
- Гарантированная работа проекта в любом браузере, поддерживающем html. Любая функциональность сначала проектируется и реализуется в семантическом html-коде без CSS и JS и лишь затем к ней добавляются стили и интерактивное взаимодействие с помощью JS.
- Возможность выкатывать новые возможности и изменения раньше. Так как сначала быстро реализуется самый базовый вариант функциональности на голом html, без всякого аякса и красивостей, вы можете сразу после этого выкатить обновление проекта для пользователей и сразу начать получать фидбэк, не дожидаясь иногда долгой обвязки JS’ом.
Минусы
- Увеличение сложности реализации back-end’а. Большинство современных проектов очень активно использует JS для улучшения пользовательского взаимодействия: динамическая подгрузка блоков, отправка форм, вывод уведомлений без перезагрузки страниц, … И все эти функции нужно реализовывать как для версии без JS, так и для полноценной версии. Чтобы избежать дублирования кода шаблонов и backend’а, придется придумать стройное архитектурное решение.
Наш опыт
Мы дважды радовались, что применяем progressive enhancement, а не graceful degradation.
Сначала — когда определяли политику поддержки браузеров. Верстка под IE6 никому из верстальщиков удовольствия не доставляет и съедает кучу лишнего времени, а тенденции его использования говорят о практически полной кончине. Поэтому мы искусственно отключили в нем поддержку CSS и JS. Открыв Футубру в IE6, вы увидите не самый красивый, но полностью функциональный сервис.
Затем, когда поняли, что не успеваем все-все “зааяксить”, но базовая версия полностью работает (пусть с перезагрузкой страницы, но работает).
Техническая реализация единых шаблонов для backend и frontend далась нам тяжело, мы несколько раз меняли шаблонизаторы и не можем сказать, что полностью довольны текущим решением. Но это тема для отдельной статьи.
Вторым базовым принципом, о котором мы договорились “на берегу”, стал…
Mobile First
Это подход, при котором вы начинаете проектирование сервиса с мобильной версии, а не с версии для больших экранов, как это делается повсеместно. Подробнее об этом подходе вы можете прочитать в блоге Люка Врублевски или в его книге Mobile First
Мотив
Перед нами не стоял вопрос, нужно ли нам в принципе делать мобильную версию Футубры или нет – мы сразу делали ставку на мобильность по нескольким причинам.
Во-первых, взрывной рост мобильного интернета, который давно начался в мире, начал докатываться и до России. Уже почти 8% всех посетителей в рунете ходит на сайты со смартфонов и планшетов, а это более 5 миллионов устройств (на самом деле, больше, т.к. учитываются не все телефоны с opera mini/mobile).
Во-вторых, из базовой потребности (хочу жить интереснее) вытекала целевая аудитория проекта (18-45, активные, прогрессивные), которая, отчасти, как раз и является драйвером роста мобильного интернета.
В-третьих, сама суть сервиса подразумевает использование “на ходу” — увидел что-то интересное по дороге на работу или учебу, сфоткал, запостил. Скучно, нечем заняться в магазине, пока девушка примеряет платье – открыл Футубру, почитал.
Но и без “большой” веб-версии проект существовать не может, так как пользователи социальных сервисов добрую половину времени сидят в них из дома или с работы.
У нас, как всегда, был дефицит рабочих рук и времени, поэтому нужно было выбрать, какую версию начинать делать первой. Мы приняли решение следовать концепции mobile first, т.е. начать проектирование и разработку с мобильной веб-версии.
Плюсы
- Фокус на самом главном. Маленький размер экрана волей-неволей заставляет тебя фокусироваться на самой сути и оставить в проекте только самое главное – на второстепенное на экране просто нет места. Логика проекта стала прорабатываться детально, дефицитное место на экране использоваться с умом и бережливостью, а все “вот давайте сюда еще накрутим няшечку” пошли лесом :)
- Полнофункциональная мобильная версия. Так как изначально мы делали только мобильную версию, весь имеющийся функционал сервиса в ней есть, и у вас не будет такой ситуации, когда с большого веба вы можете сделать какое-то действие, а с мобильного — нет.
- Мобильная версия может хорошо работать в “большом” вебе. Разрабатывая только мобильную версию, проверяли и пользовались ей мы в основном со своих рабочих компьютеров и это не вызывало отторжения.
Минусы
- У вас не сразу будет версия для большого веба. Если вы поймете, что без отдельной версии для большого веба вам не обойтись, получите вы ее не скоро. И если в вашем проекте основная ставка делается на большой веб, а сроки запуска жмут, вы можете просто не успеть сделать две версии.
- Подход сложно применим для развесистых порталов с сотнями сущностей. Если вы разрабатываете Amazon, Ebay или Yelp, проектирование по данному подходу может занять очень много времени и закончиться неудачей.
Наш опыт
Ограниченное место очень сильно помогло нам простроить логику и не допустить в проекте ничего лишнего. Мы определили минимальное поддерживаемое разрешение — 240 пикселей по ширине — и начали прототипировать:
И как-то, сами того не замечая, мы пришли к использованию…
Responsive web design
Суть этого принципа состоит в том, что вы делаете одну версию вашего веб-проекта для всех устройств с любым размером экрана, и делаете ее так, чтобы она хорошо смотрелась как в маленьком окошке мобильного телефона, так и на дизайнерском 27’ мониторе.
Про этот принцип хорошо и достаточно подробно написал Hellcunt, так же вы можете прочитать хорошую книгу.
Мотив
Со временем мы поняли, что отдельная версия Футубры для “большого” веба нам не нужна — мы очень привыкли к супер-сфокусированному и лаконичному дизайну в одну колонку и не хотели от него отказываться. Поэтому мы решили просто развить нашу мобильную версию, чтобы она хорошо работала на всех устройствах.
Плюсы
- Одна версия сайта. Один набор шаблонов и контроллеров, что облегчает поддержку и развитие, минимизирует вероятность появления “подземных стуков” в отдельных версиях проекта.
- Преемственность интерфейса. На любом устройстве вы увидите знакомый и понятный интерфейс. Пользователи это оценят.
Минусы
- Одна версия сайта. Один набор шаблонов и контроллеров приводит к усложнению логики внутри кода — если грамотно не управлять этой сложностью, то поддержка и развитие превратятся в головную боль.
- Неоптимальное использование возможностей всех устройств. Вы вступаете на путь компромисса в интерфейсе. Вам придется выбирать не лучшее решение для экрана конкретного устройства, а оптимальное для целого диапазона размеров.
- Возрастают требования к проработке интерфейса и дизайна. Проектируя любой кусочек сервиса, вам придется всегда помнить про все устройства, на которых данный функционал должен работать. Сначала это может показаться утомительным, но со временем вырабатывается привычка и все встает на свои места.
Наш опыт
Мы отказались от поддомена m.futubra.com, вынесли весь код на основной домен, определили 3 диапазона размера экрана по ширине в пикселях:
- от 240 до 320
- от 320 до 480
- от 480 и больше
И с помощью media queries и fluid images оптимизировали проблемные блоки под каждый диапазон:
Обратите внимание на верхнее меню, ссылки действия под сообщением и фоновое изображение на большой версии. Все это одна и та же версия Футубры, никакой магии :)
Не обошлось и без проблем — в дизайне некоторых блоков сайта мы не учли все возможные размеры экрана, поэтому сейчас местами наблюдаются артефакты на самых маленьких экранах. Мы работаем над устранением этих недоработок.
Выводы
Mobile first, progressive enhancement и responsive web design — три столпа, на которых стоит Футубра. Вместо массового и классического подхода “сверху вниз” (graceful degradation, сначала проектируем десктоп, потом отдельная мобильная версия) мы применили подход “снизу вверх” и очень довольны результатом. Испытав на своей шкуре этот подход, мы рекомендуем вам выбирать именно такой фундамент в своих проектах.
Если вам интересно узнать поподробнее про какой-то отдельный аспект – спрашивайте, обязательно ответим в комментариях или напишем подробный обзор.
PS: если у вас есть какие-то замечания или пожелания по самой Футубре, обязательно напишите их в комментариях или на info@futubra.com. Ваше мнение очень важно.
