Это вторая часть статьи про проектирование больших сайтов. В ней мы расскажем про визуальную часть проектирования, про интерфейсы. Если вы не читали первую часть, то рекомендую это сделать тут.

Динамический прототип

Рис. 9. Демонстрация динамического прототипа для проекта «Маркетплейс».

На этом этапе мы переходим от аналитики к интерфейсам, к визуальной части. На основе Mind map необходимо спроектировать интерфейсы для каждой функции и страницы. Таких интерфейсов у нас будет много, от нескольких десятков до нескольких сотен уникальных прототипов, а еще есть раскадровки, когда одна страница может иметь ряд состояний, всплывающих окон, выпадающих блоков и т.д. В процессе все прототипы объединяются в один большой динамический прототип и связываются между собой.

Почти 4 года назад мы написали одну из самых популярных статей в рунете про проектирование больших проектов с таким же названием, как и эта: часть 1 и часть 2. Только на Хабре её прочитало более 170 тыс. человек, а вообще она публиковалась в самых разных изданиях мира. Более 1000 стартапов использовали наработки из этой статьи для проектирования, и это только те, о которых я слышал и которые нам писали. Но время не стоит на месте, а мы постоянно развиваемся. С тех пор наша технология проектирования значительно эволюционировала и стала еще лучше. В этой статье мы опишем нашу обновленную технологию проектирования и покажем много живых примеров для каждой стадии.

Проектирование — это первый этап разработки любого большого проекта. Это основа его успешности. Когда мы строим небоскреб, нам нужно продумать все — до каждого болтика: внешний вид здания, количество этажей, локации внутри, используемые материалы. А еще нужно сделать его устойчивым к землетрясениям, позаботиться об экологии, сделать в нем офисы и магазины. Это все решается на этапе проектирования небоскреба. И проектирование в данном случае — это гарантия качества будущего строения, что оно не развалится и не похоронит под обломками людей. Этот этап позволяет понять властям города и владельцам, как именно будет выглядеть здание в итоге, увидеть предварительную проектную модель, провести точные расчеты.

В Интернете есть много разных материалов о том, как правильно делать новые интернет-проекты, как их потом продвигать, как улучшать уже существующий интерфейс и т.д. Но вот чего нет, так это системного взгляда на проблему поддержки и развития существующих проектов. Многие думают, что это как покупка хорошего нового автомобиля: купил и иногда масло меняешь, может новый коврик купишь за пару лет. На самом деле, это неправильный подход: недостаточно раз в год оплачивать хостинг и домен. Даже иногда вносить доработки недостаточно. Сайт — это инструмент, и он должен работать максимально эффективно. Над всеми успешными сайтами работа идет постоянно и непрерывно.

В этой статье я постараюсь системно посмотреть на проблемы уже работающих сайтов, а также дать рекомендации, как можно постоянно увеличивать их эффективность. Материал будет полезен владельцам существующих проектов, позволит всесторонне посмотреть на вопросы поддержки и развития с привязкой к экономической эффективности, а для некоторых, возможно, вдохнет новую жизнь в старый проект.

Мы живем во времена, когда люди не привыкли глубоко погружаться в какую-то тему. Это касается и дизайна. Сегодня все ценят победы на различных престижных конкурсах по дизайну, или, в худшем случае, оценивают личным «нравится / не нравится». У нас также есть международные награды по дизайну от Awwwards, Behance и других известных «оценщиков», которые диктуют современную моду в веб-дизайне. Но так ли они важны? Если всмотреться в суть дизайна, то он, как и многое в нашем мире, основывается на психологии восприятия. И психология — это основа любого успешного дизайна. Вы можете победить на конкурсе по дизайну, но сайт при этом будет лишь красивой картинкой, которая абсолютно не достигает поставленной цели. В этой статье мы поговорим о психологии и эффективности дизайна сайта, в частности, подробно разобрав такой важный аспект, как цвета.

Поскольку современные браузеры стали поддерживать больше возможностей, а веб-индустрия стремительно перемещается в сторону мобильных устройств, появилась необходимость писать компактный и оптимизированный код, который не заставит долго ждать пользователя, пока загрузится сайт. Front-end хорош тем, что в нем содержится много простых стратегий и конвенций кода, которые мы можем использовать для обеспечения оптимальной производительности. В этой статье мы собрали 9 простых советов, которые помогут с оптимизацией кода.

Сразу должен сказать, что часть приемов было подсмотрено нами на западных просторах интернетов, а часть добавили мы. В любом случае, в рунете такого материала не было. Нам часто приходится писать большие системы и оптимизировать скорость загрузки, поэтому стараемся бороться за каждый байт. Отсюда и решили написать про эту важную тему.

Я давно работаю в стартапах и со стартапами. Тема для меня очень близка, у самого было 5 проектов за 4 года со следующей статистикой: 2 закрылось, 1 был целиком продан большой компании, 1 проект трансформировался в другой. Еще один превратился в небольшой действующий бизнес, а также полностью поменял фокус. По двум проектам привлекались достаточно серьезные инвестиции. Особенно по меркам рунета, порядка ~ 0,5 млн $.

Все любят красивые истории о том как стартап стал “единорогом”, но мало говорят о том чего ему это стоило. Вот именно об этом и будет моя статья — короткое эссе о личном опыте на конкретном примере успешного проекта.

Мы много занимаемся электронной коммерцией и часто встречаем задачу по выравниванию элементов. На первый взгляд все просто, в коде пишется несколько строк и все ок. Но на самом деле элементы бывают очень разные, правил применения тоже много, а еще есть адаптив.

Эта статья пригодится тем, кто часто встречается с проблемой выравнивания элементов по высоте в разных ситуациях.

Рис. 1. Порядок отображения группы товаров.

За годы работы я часто слышу вопросы о выборе технологий для того или иного веб-проекта. Кто-то спрашивает у нас, как у разработчиков, как правильно, а кто-то приходит и просит сделать на какой-то конкретной технологии. Проблема в том, что большинство выбирают технологии по субъективным причинам, и пока я не слышал достойного и понятного рассуждения, которое позволило бы выбрать технологию объективно, основываясь на фактах, а не желаниях. Даже немногие итишники могут правильно выбрать технологию, ведь для этого нужно: понимать специфику проекта, иметь многолетний опыт разработки на нескольких языках, знать, как устроены подобные проекты и т.д.

Но прежде, чем что-то выбирать, давайте посмотрим, какие технологии бывают, чем они отличаются и в каких случаях какую технологию выбрать.

Многие рассказываю о проектировании: как пользоваться Axure или Sketch, какие функции должен содержать сайт, как правильно спроектировать страницу товара. Это все, безусловно, очень полезно, но не показывает полную картину происходящего в проектировании. В интернете даже нет ни одного полного примера технического задания на проекты такого уровня. На самом деле, чтобы спроектировать большой сайт, нужно потратить сотни часов на исследования, прототипирование и разработку подробного ТЗ. В этой статье я впервые в рунете покажу все этапы проектирования и результаты по ним, полный динамический прототип (более 150 прототипов) и большое ТЗ (более 200 страниц описания). Все это мы будем делать на примере проектирования аналога крупнейшей в мире E-commerce площадки «Alibaba.com».

Наверняка всем знакома ситуация, когда развитием проекта упирается в какую-то стену, внедрение новых функций становится все более затратным по времени и финансам. И, к сожалению, нередки такие моменты, когда чаша весов с ценой, начинает значительно перевешивать возможную выгоду от реализации той, или иной функции.

Это достаточно стандартный и, во многом, привычный ход событий. С опытом, мы пытаемся делать разрозненные попытки улучшать ситуацию, и не допускать ошибок прошлого. Но часто, собрать все в кучу для организации какой-то вменяемой системы времени не хватает. И, какое-либо универсальное решение, до настоящего времени, найти было достаточно непросто.

Мы разработали автоматизацию по контролю качества кода, которая уже работает в нашей компании и в некоторых других. Данная реализация создана для языка PHP. Ранее она была только для Java и C#. Однако принципы и подходы применимы ко всем современным языкам, поэтому приглашаем к обсуждению этой важной темы.

Вот уже 11 лет я занимаюсь веб-разработкой и интернет-маркетингом. Был как на стороне заказчика, так и на стороне исполнителя. Своими руками когда-то проектировал, верстал, программировал, тестировал, продвигал, затем управлял проектами, после учил это делать других, а сейчас я их придумываю и запускаю. Единственное, что я никогда не делал своими руками — это дизайн. Другими словами, я не просто видел жизненный цикл проекта изнутри, я участвовал почти во всех этапах разработки, часто в довольно больших проектах. И вот, видя всю кухню изнутри, я постоянно наблюдаю одни и те же причины успехов и поражений. В этой статье я попытаюсь рассказать, что я увидел за 11 лет работы и более 100 стартапов, которых я касался и как же все же создать большой и успешный проект.

Прежде, чем говорить об успехе, давайте поговорим о причинах поражений, чтобы иметь возможность их избежать и тем самым повысить свои шансы на успех. Относительно недавно вышло замечательное исследование про топ 20 причин провалов стартапов. В нем описаны вроде бы очевидные вещи, о которых так или иначе думает каждый предприниматель, но если разобрать каждый пункт отдельно, то можно найти много интересных неочевидных фактов:

Рынок электронной коммерции и в мире и в рунете очень активно развивается, не смотря на кризисы и другие негативные явления. В мире в год средние темпы роста по данным eMarketer составляют около 18-20% в год, в России и Украине темпы роста доходят до 17-18%. Это примерно 3-4% от общего ритейла в России (в Украине чуть меньше, рынок развит меньше и сейчас глубокий кризис) и до 10-12% в США и других развитых странах. Средний уровень в мире составляет примерно 6%. Единственное исключение, в прошлом году в Украине из-за глубокого экономического кризиса рынок не вырос в долларовом эквиваленте, но для местных компаний это шанс нагнать упущенное раньше. Самое интересное, что мы все еще находимся в стадии зарождения рынка. По многим прогнозам доля электронной коммерции в общем ритейле достигнет 20% в ближайшие несколько лет. Для компаний данного сектора игнорирование этого рынка сегодня равносильно смерти завтра.



Интересен также и тот факт, что многие крупнейшие игроки электронной коммерции в США имеют оффлайн-корни, а США – это некая лакмусовая бумажка, катализатор рынка, который нам показывает, что произойдет на наших рынках в этом же сегменте через 3-5 лет. Этому уже есть подтверждение: в России ряд крупных интернет-магазинов уже давно принадлежат крупным оффлайн-сетям и поглощения продолжаются. В Украине с этим сложнее, хотя это процесс активно идет, так несколько месяцев назад компания «Фокстрот» выкупила 100% интернет-магазина Sokol.ua

Mobile commerce

На современном этапе тестирование занимает очень важное положение в программировании любых продуктов. Веб программирование на яваскрипт не является исключением. В этой статье коснемся такого часного случая, как тестирование модулей RequireJS в связке с Symfony2.

Данная статья является логическим продолжением предыдущей, по-этому чтение рекомендую начинать с первой статьи в этой серии «Оптимизация модулей RequireJS в Symfony2», чтобы четче понимать то, что здесь происходит.

Итак, чтобы иметь возможность тестировать те модули, которые мы создаем на яваскрипте с помощью RequireJS, воспользуемся такой распространенной библиотекой для тестирования яваскриптов, как Qunit. Для этого, как пишут на оффсайте необходимо создать небольшую html страницу, на которой будут отображаться проводимые тесты. Поскольку мы имеем дело с Symfony2, нам потребуется сделать простейший контроллер, прописать к нему роут и подцепить вьюшку. В зависимости от конкретного случая, это можно с делать в отдельном бандле, или в каком-либо из уже имеющихся. Чтобы не нагромождать статью лишним кодом, предположим, что существует WebBundle в котором мы это и сделаем.

Контроллер будет выглядеть очень просто:

Последняя часть статьи про проектирование больших интернет-магазинов, по крайней мере, их внешнюю часть. В это части вы узнаете про связь с Off-Line торговлей, мультивалютность, мультиязычность, мультибрендовость, статьи, новости, опросы и исследования, поведенческую систему (персонализацию), партнерские программы, адаптивную верстку и приложения, микроформаты, Social CRM, аналитические системы, интеграцию с 1С, интеграцию с внешними БД, интеграцию с торговыми площадками, парсеры, экспорт данных и многое другое. Дальше еще будет серия статей про проектирование внутренней части магазинов, в которую входят бухгалтерия, логистика, CRM, документооборот и многое другое.

Прошлые статьи серии можно найти тут:

«Проектирование магазина. Исследования»
«Проектирование магазина. Модули интернет-магазина»
«Проектирование магазина. Карточка товара и не только»
«Проектирование магазина. Субституты, комплементы, сравнение и другие инструменты увеличения конверсии»
«Проектирование магазина. Личный кабинет, корзина, доставка-оплата, рассылка и другое»

*Эта статья впервые была опубликована в журнале Forbes от 27 Июня 2014 года. На Хабре публикуется её полная версия.

Вот уже 9 лет я занимаюсь интернет-бизнесом и за это время успел создать и вывести на прибыльность 5 собственных стартапов. Кроме того, один из основных моих бизнесов – это заказная веб-разработка, куда часто приходят клиенты, которые хотят разработать свой интернет-стартап и поэтому я все 9 лет каждый день сталкиваюсь с разными проектами, многие из которых являются стартапами в полном смысле этого слова.

Очередная статья большого обзора функционала интернет-магазинов. Сегодня я расскажу про личный кабинет, избранное, интеграцию с социальными сетями, корзину, доставку-оплату, рассылку и уведомления. Всего, вместе с этой частью статьи, я рассмотрел около 50 модулей современных интернет-магазинов.

Прошлые статьи серии можно найти тут:

«Серьезное проектирование серьезного магазина. Часть 1. Исследования»
«Серьезное проектирование серьезного магазина. Часть 2. Модули интернет-магазина»
«Серьезное проектирование серьезного магазина. Часть 3. Карточка товара и не только»
«Серьезное проектирование серьезного магазина. Часть 4. Субституты, комплементы, сравнение и другие инструменты увеличения конверсии»

Регистрация / личный кабинет

Для любого интернет-магазина важно, чтобы пользователи регистрировались на сайте и оставляли о себе много информации. Это позволяет увеличить средний чек и сильно повышает шансы интернет-магазина превратить разового покупателя в постоянного.

Сама регистрация должна быть очень простой, чтобы не стать барьером для пользователя, а интернет-магазин должен стимулировать пользователей зарегистрироваться. Некоторые крупные интернет-магазины запрещают совершать покупки незарегистрированным пользователям – это довольно спорный способ заставить зарегистрироваться, но он показывает важность регистрации на сайте. Мотивация зарегистрироваться может быть самой разной: специальная скидка для зарегистрированных пользователей, доступ к любым акциям только для зарегистрированных, особые условия зарегистрированным и т.д.

Рис. 1. Личный кабинет.

О пользе модульного подхода в программировании на любом языке говорилось уже достаточно много, по-этому приведу кратко основные положительные моменты для JS особо не вдаваясь в подробности. Разделение приложения на модули позволяет сделать код:

• значительно более читабельным и прозрачным для понимания
• гораздо более простым в поддержке
• гибким и расширяемым
• пригодным для написания достаточно больших приложений
• легко тестируемым и более простым в отладке

Так же документация модульного кода гораздо более эффективна.

Модульность, наряду с фреймворками, помогает вывести яваскрипт на качественно новый уровень и позволяет ему перейти из ранга вспомогательных и дополнительных в ранг серьезных самостоятельных языков программирования.

Однако, модульный подход на выходе обеспечивает нас множеством файлов, которые совершенно неэффективно вытягивать с сервера на клиент по одиночке из вполне очевидных причин.

Существуют хорошо зарекомендовавшие себя библиотеки способные решить большинство поставленных задач и избежать отрицательных моментов. Одной из наиболее популярных библиотек для написания модульных приложений на яваскрипт является RequireJS. RequireJS хорошо документирована и касаться разработки с ее использованием в этой статье мы не будем. Рассмотрим подробнее как интегрировать RequireJS в Symfony2 с последующей оптимизацией созданных нами модулей. Для подобной цели очень кстати может оказаться HearsayRequireJSBundle, так что, какая проблема, берем бандл инсталлируем через компоузер и все! Возможно у кого-то так и получилось, однако могли возникнуть и некоторые нюансы. Чтобы максимально сгладить процесс знакомства с подобной интеграцией предлагаю прочесть то, что изложено ниже.

В последний год мы написали много статей по UX / UI проектированию eCommerce проектов и не только. Концепция проекта и интерфейсы – это, безусловно, очень важно, однако есть еще несколько крайне важных вещей, которые нужно учесть. Не важно, кто их будет учитывать: UX / UI Designer, SEO Specialist, Web Developer, Project Manager или кто-то еще, важно на каком этапе жизни проекта. А сделать это нужно задолго до запуска проекта, на этапе разработки.

Необходимо заложить в проектировании требования к SEO, сделать их частью технического задания, чтобы потом не переделывать проект с маркетологами, как это часто бывает. Крупнейшие поисковые системы постоянно выпускают рекомендации по правильной оптимизации сайтов, но для интернет-магазинов тут есть определенные особенности, которые я кратко разберу ниже:

1. Robots.txt. Файл для правил индексации поисковыми системами. Создать и положить в корень сайта. В идеале индексация должна быть открыта всем поисковым системам и всему сайту (за исключением закрытых разделов, таких, как личный кабинет).
2. Файл Sitemap.xml. Карта сайта для поисковых систем. Создать и положить в корень сайта. Сделать автогенерацию с заранее заданным весом страниц разбитым по типам информации (например, страница товара 8, страница категории 9, страница статьи 7 и т.д.). Загрузить файл в поисковые системы.
3. Карта сайта. Кроме Sitemap.xml еще желательно сделать отдельную страницу на сайте, дать ссылку на неё в нижней части сайта и также поместить ссылки на основные страницы. На одной странице не должно быть больше 300 ссылок. Если на сайте больше страниц, то проблему можно решить через пагинацию внизу страницы «Карта сайта».

Каждый разработчик, который работает на той или иной технологии, постоянно читает о ней что-то новенькое и углубляет свои знания. И мы не исключение. PHP довольно старый и популярный язык, на котором есть много разных фреимворков. Один из самых популярных и серьезных – это Symfony и так уж исторически получилось, что мы на нем пишем. По этому фреимфорку в рунете не так много информации, как хотелось бы, мы часто читаем разные статьи, обзоры и интервью на английском языке, чтобы быть в курсе последних событий. Эта статья – обзор больших сайтов, которые сделаны на PHP / Symfony с уникальной для рунета информацией, а также описание некоторых технологий, которые применяются в связке с ними. И да, мы знаем, что PHP «уже не торт» и что использовать его уже не модно, однако эта технология имеет большую долю рынка, много наработок и отличную документацию, поэтому мы её используем наравне с Python, Ruby, Java и другими.

Таблица известных проектов (на основе данных http://builtwith.com/), кликабельно:

Новая статья по проектированию интернет-магазинов, на этот раз описана механика ряда блоков, которые увеличивают конверсию. В этой части мы расскажем про субституты, комплементы, сравнение и другие инструменты увеличения конверсии. В прошлый раз мы осветили несколько десятков функциональных блоков магазинов: «Проектирование интернет-магазина: исследования», «Проектирование интернет-магазина: модули интернет-магазина» и «Проектирование интернет-магазина: карточка товара и не только» эта статья логическое продолжение.