«Мелочи не играют решающей роли. Они решают всё»

Мысль, вынесенная в эпиграф данного топика, принадлежит Харви Маккею – американскому миллионеру, главному администратору корпорации Mackay Envelope. Впервые эта мысль была озвучена в его книге «Как плавать среди акул и не быть съеденным заживо», в которой автор на основе жизненного опыта повествует о том, как обойти конкурентов в торговле, управлении, мотивации и ведении переговоров.

«Мелочи решают всё», — утверждает состоявшийся миллионер, человек с огромным опытом ведения бизнеса. Так ли это на самом деле? Насколько данный тезис относится к управлению интернет-магазином? Давайте подумаем…

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

Методы монетизации аудитории

Традиционно существует два основных способа заработка на аудитории проекта: продажа его рекламных возможностей и предоставление пользователям платных сервисов.
И если про первый уже сказано достаточно много, то второй еще только начинает свое активное развитие.

По предоставляемых пользователям услуг можно выделить три основных категории сайтов:

• Специализированные интернет-магазины и сервисы (магазины программного обеспечения, музыки, видео, рефератов, темплейтов веб-дизайнов, документации, специализированных статей для профессионалов, сервисы доставки сообщений пользователям, розыгрыши и викторины, ответы на вопросы), основной задачей которых является предоставление посетителям специфических услуг или продажа контента (с оплатой за единицу контента). Такие ресурсы считают получение дохода от рекламы второстепенным заработком.
• Сайты, доступ к которым можно получить только на платной основе (нишевые и узкотематические профессиональные ресурсы с ценной информацией для определенной аудитории, ресурсы для взрослых) – обычно пользователям демонстрируют только общую информацию о ресурсе, а для того, чтобы получить к нему доступ, требуется сначала внести оплату. Рекламы на таких ресурсах практически не бывает.
• Ресурсы, предлагающие своим пользователям дополнительные сервисы и услуги – так, например, на сайте знакомств пользователи могут выделить свою анкету в результатах поиска, а в социальных сетях подарить другу какой-нибудь подарок.

В народе есть известная поговорка „Первый Блин Комом“, чего не могу сказать о своём свежем опыте интернет торговли. Скорее всего, это просто исключение подтверждающее правило, но, тем не менее, хочется рассказать о тех небольших выводах, что я сделал за последний месяц.

Итак, небольшая история о том, как можно довольно легко заработать за один месяц минимум 15 000 евро.

Мой профессиональный род деятельности — веб-разработка. Занимаюсь R&D в одной небольшой IT компании, пишу «навороченные» приложения для корпоративных интранетов и, в принципе, на жизнь не жалуюсь. Конечно, при таком раскладе хочется параллельно вести какой-нибудь интересный проект, чем неоднократно занимался в мире Open Source. Со временем, правда, захотелось на побочных проектах так же как-то зарабатывать, что с Open Source оказалось не так просто, как может показаться из статей на Хабре :) Потому и решил попробовать для себя что-то принципиально новое — открыть интернет магазин.

Прочитав много литературы по истории бизнеса и наблюдая рост популярности Интернет-торговли, автору этих строк хотелось реализовать свои знания на практике. Искали подходящую тему для проекта. Необходимыми условиями были:

1) Вложение не более $10 000
2) Прибыль не менее $1 000 в месяц
3) Минимальная рутина

По первым двум пунктам все понятно. А вот по третьему пункту поясню. К тому моменту я уже работал в собственной компании (сфера финансов). Это был 2009 год. Последствия кризиса еще сильно влияли на основной бизнес и работы было непочатый край. Много времени отвлекать на сторонний бизнес автор не мог.
Подходящий случай подвернулся в октябре 2009 года.

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

Некоторые нехорошие продавцы (поскольку они нехорошие, то будем и нехорошим словом их дальше называть — «мошенники»), в свою очередь, тоже хотят зарабатывать и не хотят вам платить.

В результате вы каждое утро получаете на свой сайт очередную тонну шлако-объявлений от «псевдочастников», которые только отпугивают пользователей вашего сайта (они же ищут частников, а в каждом втором объявлении попадают на очередного мошенника), а значит и ударяют по вашей прибыли.

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

Однако, в зависимости от вида, каждые 7, 11, 13 или 17 лет периодические цикады одновременно массово вылезают на свет и превращаются в шумных летающих тварей, спариваются и вскоре умирают.

Хотя наши странные цикады весело уходят в иной мир, возникает очевидный вопрос: это просто случайность, или числа 7, 11, 13 и 17 какие-то особенные?

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

«Нужно определить, какими устройствами могут пользоваться ваши посетители, проработать и создать для этих устройств представление вашего сайта, определить устройство посредством проверки заголовков браузеров, и отправить наиболее подходящее представление.»

Почему это глупо

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



Это скриншот из презентации «Beyond the mobile web by yiibu» (очень рекомендую).

Во-вторых, если вы не facebook или yandex, скорее всего, вы не потянете создание и поддержку разных версий сайта для каждого устройства. Да и это не имеет особого смысла. Потому что ситуация становится похожа на реалии пятнадцатилетней давности. Тогда делали сайт «под браузер», а сейчас автор предлагает делать сайт «под устройство».

Как сделать один сайт для всех устройств

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

Неужели нам остаётся лишь сносить эту му́ку? Что ж, теперь нет! Недавно я обнаружил подход, который позволит дизайнерам распрощаться с открытием 23 PSD-файлов только ради смены цвета элемента в шапке. Вместо этого мы можем поступать разумно, как наши коллеги, разработчики, и импортировать внешние файлы при помощи кое-чего с названием «Variables (Переменные)».

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

Разрешите представить вам перевод статьи «Cross-Browser Inline-Block», написанной Райном Доэрти холодным февралем 2009 года. В статье рассказывается о верстке элементов списка с установкой для свойства display значения inline-block. Статья об этом, а также о трудностях, возникающих в процессе достижения результата и о методах их «лечения».

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

К сожалению еще не все браузеры поддерживают эти возможности и поэтому мы попытались сосредоточиться на использовании этих возможностей в Firefox 4.

Почему валидация формы со стороны браузера?

Идея валидации формы в HTML5 состоит в том, чтобы отказаться от использования JavaScript при проверке содержания полей: действительно ли этот адрес электронной почты допустим? заполнено ли это поле? соответствуют ли пароли? Раньше в большинстве случаев для этих целей использовался JavaScript. Вы можете написать свой собственный javascript-код или воспользоваться javascript-библиотекой, но это всегда будет повторной, скучной и подверженной ошибкам задачей. С формами, проверенными браузером, Вы больше не должны заботиться о этих задачах, достаточно записать простой HTML.

Вы PM. Как узнать – готова ли вёрстка к реальному использованию?
Вы заказчик. Как убедиться, что работа выполнена качественно?
Как оценить качество вёрстки?

Когда я стал тим-лидом, а позже PM, передо мной стала задача проверять вёрстку наших проектов. Нужно было выработать формальные, легкопроверяемые критерии, соответствие кода которым, должно было давать некую гарантию, что не будет факапов и ни клиент, ни программеры не сказажут потом “WTF?”.

Клиенту неважно насколько красив ваш код, но ему важен результат. Качественный код нужен фирме, т.к. он надёжней и в будущем его будет легче поддерживать.

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

Итак что же это за список?

Краткая версия теперь доступна на html5checklist.com (github), где можно вносить pull-request'ы.

История обновлений:

• 2015/08/11: Актуализировал рекомендации по оптимизации скорости загрузки. Добавил требование поддержки Retina. Дополнил «19. Мелочи» требованием что изображения должны масштабироваться в зависимости от размера окна.
• 2015/08/10: актуализирован список исключений для CSSLint
• 2015/07/29: актуализирован пункт №13 «плохо»/«хорошо»
• 2015/04/08: добавлено требование использования препроцессоров и рекомендация использования систем сборки
• 2013/04/25: добавлены анализаторами качества кода: CSSLint и JSHint, указан сайт подбора css font stack (спасибо @fliptheweb), мелкие уточнения (работу интерактивных элементов страницы, что не пропадает фон на высоких разрешениях, не должно быть пустых презентационных блоков, при проверках контента — пробовать удалять заголовки, менять местами блоки)
• 2013/04/24: добавил пункт об минимизации каскада (БЭМ-техники, MCSS, SMACSS), необходимости вписывания в экран моб. устройства, заменил ссылку на проверочный текст отображения стандартного html на код с normalize.css, поправил пример где в рекомендации встречался длинный каскад, упомянул про Opera на Presto и новый уровень семантики — в именах классов BEM.
• 2012/04/12: отсортировал пункты проверки в порядке важности, выделил главные, дополнил статью подробностями
• 2011/12/07: дополнил согласно доклада на WSD Минск'2011.
• 2011/07/19: добавлено про повышение надёжности вёрстки благодаря html5-тэгам, про необходимость favicon/apple-touch-icon, отсутствие багов при ресайзе textarea
• 2011/06/15: добавил пояснения какие ошибки валидации допустимы, рассказал про отсутствие официальной кнопки «HTML5 Valid» и про официальное лого HTML5 на сайте.

Валидация форм была педантичным занятием с момента появления web. Первой пришла серверная валидация. Затем она развилась в валидацию на стороне клиента для проверки результатов в браузере. Теперь у нас есть такие гиганты как HTML5 и CSS3: глава о формах HTML5 предлагает нам новые типы для input полей и атрибуты, которые делают возможным проверку ограничений поля. Базовый UI модуль CSS3 предоставляет несколько псевдо-классов, которые помогают нам стилизовать состояние валидности и менять внешний вид поля в зависимости от действий пользователя. Давайте взглянем на комбинацию обоих для создания валидатора форм основанного на CSS, который имеет достаточно широкую поддержку браузеров.

Чем больше мы можем дать подсказок пользователю, как правильно заполнять форму, в процессе заполнения, тем меньше шансов, что он сделает ошибку. Взгляните на пример CSS3 валидации форм в браузере поддерживающем CSS3 UI псевдо-классы, например Chrome 4+, Safari 5+ или Opera 9.6+. Я использовал CSS3 UI псевдо-классы и HTML5 атрибуты форм для создания валидации основанной на CSS. Давайте посмотрим как это работает.

В первой части Терминатора Рис Кайл рассказывает о том, как круто роботы научились маскироваться под людей. Что сейчас у них настоящие кожа и волосы, они потеют и т. п. Про предыдущие же модели он говорил, что их легко было отличить по резиновой коже.

Думаю, что ещё более ранние модели отличались совсем просто — они говорили: «Солдат Крис Катарн, убил 10 враг, потратил 342 патрон, получил 0 ранение» и т. п., чем сразу палились.

Ведь до сих пор, несмотря на развитие веба, на многих сайтах можно встретить «50 пользователи», «1 комментарии», «0 сообщения» и т. п. А ведь насколько приятней, когда сайт говорит с тобой на человеческом языке и правильно спрягает слова по числам.

И ведь сделать это совсем несложно.

Да, да, это очередная статья про html5 и тэг < video >. Но главным ее отличием будет то, что здесь будут рассмотрены самые базовые понятия и теории. Так что приготовились внимательно читать и записывать, let html5 rocks!

Данный топик — это не изложение азов на тему «Как сделать на своей странице две колонки с использованием div'ов и css». Передо мной стояла задача разбить монолитный текст на две колонки, подобно тому, как это делает MS Word. Стандартного тэга в css для этого не существует, поэтому пришлось немного потанцевать с бубном для решения поставленной задачи.
Ширина колонки с текстом очень сильно влияет на простоту восприятия информации пользователем. И поэтому, учитывая нынешнюю популярность широкоформатных мониторов, разбивка текста на колонки существенно увеличивает его «читабельность».

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

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

Google Font API — API для подключеня нестандартных шрифтов.

<html>
  <head>
    <link rel="stylesheet" type="text/css" href="_http://fonts.googleapis.com/css?family=Tangerine">
    <style>
      body {
        font-family: 'Tangerine', serif;
        font-size: 48px;
      }
    </style>
  </head>
  <body>
    <h1>Making the Web Beautiful!</h1>
  </body>
</html>

Рад сообщить, что обновлённый jQuery Wysiwyg 0.6 вышел в свет.

В контексте одного из моих текущих проектов была поставлена задача сделать «мокрый пол». Картинок на пол планировалось класть огромное количество (но всего по паре на страницу, с заменой). В перспективе. В перспективе, кстати, временной и пространственной.

Не найдя ничего стоящего, я взялся написать свой велосипед. И, по-сидев два с лишним вечера, сочинилась небольшая js-библиотека с generic-названием iWet.

UPD: Версия 0.2

• Добавил белую маску. См. Демо.
• Выложил исходик маски в .psd
• Вылечил баг с мельканием картинки при загрузке страницы
• Добавил readme.txt и licence.txt
• Минимальные косметические изменения кода

(От перев. Данная статья не претендует на полноту и непротиворечивость, потому мы не будем строить на ее основании никаких теорий. Это всего лишь практическое пособие для разработчиков, немного исправленное и дополненное мной под реалии Рунета.)

Одним из самых странных статистических фактов, связанных с использованием браузеров, является широкая распространенность Internet Explorer версии 6, 7 и 8. На сегодняшний день все версии Internet Explorer вместе занимают примерно 65% рынка используемых в настоящее время браузеров. Среди веб-разработчиков эта цифра ниже, здесь доля пользователей IE составляет лишь 40% рынка.
(От перев. Надеюсь, эти 40% составляют лишь несчастные верстальщики, проверяющие свои сайты на предмет кроссбраузерности. Статистика по Рунету доступна, например, здесь. Заметьте, в сентябре у всех браузеров IE-семьи график без видимых причин подскочил — это вернулись за свои компьютеры офисные пользователи, самые преданные почитатели наших героев.)

Интересно, что популярность браузеров семейства IE примерно одинакова, нельзя выделить один доменирующий браузер, как это было ранее. (От перев. Конечно, нельзя. Вот смотрю и ну никак не могу выделить доминирующий браузер. =) ) Таким образом, сейчас веб-разработчики обязаны проверять работоспособность своего проекта в различных браузерах, разрабатывая как сайты для своих заказчиков, так и персональные странички.

Конечно, благодаря различным Javascript-библиотекам, кроссбраузерное тестирование сейчас стало настолько хорошим, насколько данная ситуация вообще позволяет это сделать. (От перев. А еще есть возможность сделать скриншоты в разных браузерах, IE Collection и тому подобные ухищрения) Но есть в этом что-то неправильное, особенно если взглянуть на результат работы трех использующихся версий IE.

Эта статья является попыткой дать исчерпывающую, легкую в восприятии информацию для веб-разработчиков, пытающихся понять различия в обработке CSS между IE6, IE7 и IE8. Здесь собраны краткие описания для свойств, поддерживаемых одним или двумя браузерами, но не всеми тремя сразу. Здесь не рассматриваются свойства, не выполняемые ни одним из IE, а также специфичные только им. Таким образом, акцент стоит именно на различиях между браузерами, а не на недостатке поддержки ими тех или иных CSS-свойств.