Про чаты-помощники

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

Есть с десяток подобных сервисов и все они работают по принципу "пробная версия бесплатно, а дальше за деньги".
На хабре есть несколько статей, вот одна из них (http://habrahabr.ru/company/tuthost/blog/165365/), но, я уверен, аудитория Хабрахабра знает о чем речь.
Большинству людей подойдет бесплатный вариант любого такого сервиса: нужно всего-навсего зарегистрироваться и вставить на сайт кусок JS кода. Для тех у кого много менеджеров — придется платить: например Редхелпер на 10 операторов обойдется Вам:


Скорее всего — цена адекватная для тех, кто платит зарплату десяти менеджерам.

Но я решил изобрести бесплатный «велосипед» из подручных материалов.
Запуск у себя на сервере займет 15 минут. Всем, кому идея интересна — прошу под кат.

Обычный кран с горячей и холодной водой очень жесток к пользователю. В идеале его интерфейс решает три основные задачи:

• Позволяет выбрать напор воды.
• Позволяет выбрать температуру воды.
• И защищает систему от гидравлического удара.

Вот тут вы можете узнать пару своих знакомых кранов:



А это — очень страшный автомобильный диод, по нему только вперёд:



Итак, если вам интересно продолжение про интерфейсы в реальном мире – заходите в пост. Осторожно, трафик.

Что делать, если нужен монитор? Правильно, сначала определиться, зачем он нужен, затем идти в интернет и читать обзоры. Хочется работать с графикой и фотографиями? Важна цветопередача. Играть в игрушки и смотреть фильмы? Скорость отклика и input lag в приоритете. Ну а когда домашний компьютер используется и для работы, и для развлечений, и вообще трудится 24 часа в сутки, хочется соблюсти какой-никакой баланс и качества картинки, и динамических характеристик, и чтобы глаза не кровоточили уставали ни в яркий солнечный день, ни тёмными зимними вечерами. Дело за малым — выбрать монитор, чьи характеристики будут отлично покрывать эти юзкейсы и не сильно бить по кошельку.



С таким набором характеристик одним из самых интересных мониторов является EIZO Foris FS2434 (формально относящийся к игровой линейке), о котором сегодня и поговорим.

Любой маломальски опытный QA-инженер (или в простонародье тестировщик) сможет сходу назвать пяток различных видов тестов: удобство пользователя, дымовое, нагрузочное, регрессионное, конфигурационное, тестирование взаимодействия и т.д. Какие-то виды тестирования используются редко, например нагрузочное, почаще применяется тестирование удобства пользователя, о таких экзотических видах, как конфигурационное тестирование или тестирование взаимодействия, многие вообще слышали только в книгах Канера и Фолка «Тестирование программного обеспечения» и никогда не использовали в работе. Но есть вид тестирования, про который можно сказать совершенно четко: его делал каждый. Я говорю о регрессионном функциональном тестировании. Этот вид теста, пожалуй, является одним из наиболее важных, нудных и трудоемких.

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

Но какой бы интересной не была работа программиста, рано или поздно она неизбежно превращается в рутину. В силу интересности задач, ежедневный восьмичасовой рабочий день пролетал практически незаметно и два с лишним года в офисе после университета промелькнули, словно две недели. Остерегаясь пропустить еще лет 10 своей жизни, я решил, что нужно что то менять. Параллельно с основной работой я иногда фрилансил для расширения стека технологий и небольшого дополнительного заработка, поэтому появилась идея на некоторое время полностью перейти на фриланс, поездить по миру и поработать из разных городов. При этом хотелось посетить как можно больше стран, и не просто посетить «для галочки» города и известные достопримечательности, а получше узнать культуру каждой страны, быт и особенности местного населения, увидеть, чем, к примеру, восточная Чехия отличается от западной… И тут мне в голову пришла гениальная идея, поехать в Европу на велике.

В конце июня в Москве прошла конференция Bitrix Summer Fest, на которой было представлено много интересных и полезных докладов. Чтобы этот кладезь мудрости не пропадал, мы будем публиковать в нашем блоге материалы по выступлениям с конференции. И начать мы решили с доклада Антона Герасимюка, посвящённого оптимизации скорости загрузки страниц.

21 апреля Google поменял алгоритм ранжирования поисковой выдачи для мобильных устройств. Многие владельцы сайтов и администраторы получили письма, в которых сообщалось, что «ваш сайт не оптимизирован под мобильные устройства». И после 21 апреля на всех сайтах, которые перестали удовлетворять новым критериями, стал падать поисковый трафик с Google.

После пары лет поисков, мы в Alconost наконец-то нашли инструмент безболезненного управления задачами: Trello. Инструмент простой и не перегруженный лишним функционалом, по сути — это доски со стикерами-тикетами, перемещающимися от колонки “Идеи” или “Предложения” к колонке “Сделано”.

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

О том, как ребятам из Fog Creek Software удалось сделать такой удивительно простой и одновременно функциональный продукт — в посте Боби Грэйса (Bobby Grace) “How We Make Trello”

Переведено в Alconost.

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

Вступление

Меня зовут Роман. Последние пару лет я работаю в сфере разработки сайтов. За это время прошел путь от менеджера по продажам сайтов до проект-менеджера (великое достижение).

Мой коллега Дмитрий — прожженый дизайнер с 8-летним стажем.

Проработав последние полтора года на веб-студии Новосибирска, мы открыли свое дело.

Свое дело — это тоже студия (ужасное слово).
Рынок конкурентов в Сибири переполнен, поэтому мы решили якорной сделать одну услугу — проектирование.

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

Первое, что я заметил — множество советов как все настроить под большую нагрузку. Читайте их внимательно, обычно в тексте найдете, что речь про «высокую нагрузку» в 15-20 тысяч клиентов в сутки. У нас клиентов примерно миллион, активных, ежедневных.

У нас нет денег и мы все делаем за свой счет, поэтому экономим. Итог — весь миллион клиентов обслуживается на одном сервере, вот на таком — EX-60 на hetzner.

Недавно мы в «Я люблю ИП» закончили курсы по дизайну от trydesignlab.com. И это одна из самых важных статей, которую нам посоветовал ментор в процессе обучения. Именно поэтому мы решили её перевести. Посмотреть все наши работы с курсов можно в ВКонтакте по тэгу #design101@iloveip.

Вступление

Сначала о главном. Это руководство не для всех. Это руководство прежде всего для:

• разработчиков, которые хотят уметь делать хорошие интерфейсы для себя, если вдруг прижмёт;
• UX-дизайнеров, которые знают, что хороший UX-дизайн продаётся лучше в красивой UI-упаковке.

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

А пока давайте я расскажу, что вы найдёте в этой статье.

Менеджер по продукту – странная профессия, существующая в Кремниевой долине. Ты – это мини-CEO. Но не совсем. Ты умеешь всё, но ни в чём не достиг мастерства. У тебя – вся власть, и никакой власти. У тебя – вся ответственность, и никакой ответственности. Все эти утверждения верны, и в то же время не верны.

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

Я был МП для SaaS в большой компании пять лет. Настало время рассмотреть всё, что я узнал (кое-что), что я не узнал (много всего) и где я облажался (многократно). Интересно, что когда я начинал работу, я постоянно натыкался на объявления по найму МП, где говорилось об обязательном пятилетнем или даже десятилетнем опыте работы. И теперь, через пять лет, я понимаю, почему.

Не переживайте, если технари вас ненавидят. Вас все ненавидят. Привыкайте.

Не могу представить себе взаимоотношений, которые были бы в большей степени настроены на противостояние с самого начала. Вы говорите технарям, что делать – но у вас нет власти, и вам, видимо, надо убеждать их при помощи какого-то искажения реальности (которое было у Стива Джобса, и который был лучшим МП в мире. Ну разве он не был замечательным парнем?).

Конверсия Landing Page – вопрос, который волнует как владельцев бизнеса, так и веб-мастеров. В интернете существует тысячи статей о повышении конверсии. Мы же расскажем о четырех ключевых ошибках, убивающих конверсию через текст, и как их исправить.

«Галоп пикселя», часть I — базовые понятия, этапы взросления, прикладные упражнения (линк)
«Галоп пикселя», часть II — перспектива, цвет, анатомия и прикладные упражнения (линк)
«Галоп пикселя», часть III — Анимация (линк)
«Галоп пикселя», часть IV — Анимация света и тени (линк)
«Галоп пикселя», часть V — Анимация персонажей. Ходьба (линк)линк)

Первая статья данного цикла была воспринята тепло, вследствие чего затягивать с продолжением не имело никакого смысла, но, увы – это произошло. Зимнее наступление захлебнулось и плавно переросло в летнюю кампанию. В конце статьи я объясню почему, не хотелось бы вас огорчать с самых первых строк. Итак. Публика выразила желание ознакомиться с предметом глубже, чем предполагалось изначально. Большое количество писем пришло на почту, наряду с регулярными тычками в социальных сетях. В этом месте мне вспоминается одна фраза – «будьте осторожны в своих желаниях».

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

Не будем мешкать. Возьмем наши пиксельные лопатки и двинемся на врага сплоченной группой. Быть может, нам повезет, и кто-нибудь, выжив, расскажет потомкам о ещё одной битве Теоретического войска возле местечка, вошедшего в историю сети как Хаброва падь.

В нашей компании в процессе разработки принято придерживаться нескольких простых принципов. Возможно, кому-то они покажутся спорными, кому-то наивными, но, так же как и календарь, про который писал в прошлом году наш IT-директор (aka paulig), эти принципы — результат собственного опыта и ошибок. Кроме того, мы верим, что следование им даёт возможность решать задачи быстрее и эффективнее.

Зачем это было написано, если есть множество книжек по методологиям разработки (в том числе extreme programming, scrum, tdd), по программированию в целом и в частности, о том, «как пасти котов» и про «идеальный код»? Книг много, но разработчики, к несчастью, их читать не любят. Ну, ладно, любят, но не все. У них, мол, своя специфика. Квинтэссенция нужна. И проще, ближе, понятнее. Вот поэтому. И в жизни чаще всего приходится вспоминать, вернее, не забывать, именно те, которые перечислены ниже.

Посмотрев на историю страницы в нашем корпоративном twiki, я обратил внимание, что небольшой список с пояснениями, на основе которого сделана эта публикация, начал своё существование в 2006 году и неспешно дополнялся до 2011 года. Потом почему-то заглохло. Может быть, у кого-нибудь из читателей появится желание что-то добавить?

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

Привет, Хабр!

Хочу поделиться с общественностью своей небольшой (всего 6 Кбайт) js-библиотекой, которая сильно облегчает мне работу с формами при разработке сайтов, и позволяет сократить написание кода.

Оптимизация веб-сайтов, известная под именем А/Б тестирование набрала популярность в качестве рабочей техники для многих команд, создающих сайты. Но до сих пор по ней слишком мало всеобъемлющих книг, статей или обучающих материалов, направленных на одиночных разработчиков, стремящихся ввести эту технику у себя в организации.

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

Основы: что такое оптимизация веб-сайтов?

Это метод экспериментов, проверяющих, какой дизайн лучше подходит для вашего сайта. Идея проста:

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

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

От переводчика.
Это перевод статьи Филипа Бернарда с сайта css-tricks.com. Часть статьи, содержащую описание работы с созданным им сервисом, я позволил себе опустить. Если вы найдете ошибки, просьба сообщить о них в личном сообщении.

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

Фавикон был представлен в 1999 году, в Internet Explorer 5 (источник) и стандартизирован W3C несколько месяцев спустя. Это была маленькая иконка, представляющая сайт.



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

Введение

Несколько лет назад я писал статью на Хабр о приложении-справочнике по математике для Android, которое стало моим первым опытом в разработке для GooglePlay. Сегодня, оглядываясь назад на свой прошлый хабрапост и прошлую версию приложения, мне становится страшно (чтобы содрогнуться достаточно взглянуть на первый скриншот ниже). За прошедшие несколько лет многое поменялось: AndroidMarket стал называться GooglePlay с новыми правилами и прочим, выходили новые версии ОС, появилась некая общая google-концепция к дизайну приложений material-design, появились новые среды разработки, да и Хабр изменился.

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

Сегодня я расскажу как и зачем мы построили интерфейс нового сервиса Вирусдай на перекрывающихся слоях, как это сказалось на UX и как мы сформулировали принцип «Looks like an app. Works like an app».



За время, прошедшее с 2012 года мы несколько раз модернизировали как сам сервис, так и его интерфейс. Однако, всему однажды приходится сказать «прощай» и идти дальше. Настал момент, когда ни архитектура, ни интерфейс сервиса уже не отвечали нашим запросам. Нам предстояло превратить простой антивирус для сайтов в нечто большее – в целый набор связанных и удобных инструментов для лечения и защиты сайтов. Назревало только одно решение – делать новый сервис «с нуля». Архитектура, технологии, сценарии, интерфейсы – все должно было быть абсолютно новым. Нашей главной целью было достижение максимального уровня комфорта для пользователя при работе с новым сервисом.

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