Rose debug info
---------------

Написал|

О прикладной редактуре, смысле и красоте

Учебный проект: потребности пользователей (часть 2/6)

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

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

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

Онбординг на стартовом экране

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

Но сначала немного философии.

Зачем изучать потребности

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

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

Живые люди куда сложнее абстрактных персон, которые иногда собирают проектировщики с маркетологами. Люди субъективны и иррациональны. Иногда они готовы мириться с неудобствами в сложных процессах, но теряют самообладание от неочевидных мелочей, а иногда наоборот. Угадать сложно.

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

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

Как изучать: интервью и Job Stories

Для диплома было достаточно провести пять-шесть интервью и на их основе составить с десяток Job Stories.

Job Stories — короткие записи, которыми фиксируют пользовательские ситуации и продуктовые фичи. Для удобства чтения Job Stories формулируют по строгой трёхчастной структуре: ситуация, мотивация и ожидаемый результат.

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

Чтобы Job Stories несли пользу, их нужно правильно формулировать:

  • Ситуация должна содержать проблему, а не просто описывать контекст. Например, я не просто зашел на кухню, а у меня там кипяток из трубы хлещет.
  • Мотивацию нельзя подстраивать под интерфейс, она должна описывать желание человека вне продукта. Я не номер телефона в приложении хочу найти, а вызвать мастера.
  • Результат должен иметь связь с продуктом. Если продукт совершенно не предусматривает вызова мастера, эта потребность не принесёт пользы проектированию.

Если все сделать правильно, Job Stories будут содержать ценные сведения о потребностях реального человека и помогать фокусироваться на пользе.

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

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

Job Stories для дипломного проекта. На реальных проектах их могут быть сотни

Сбор фич на основе потребностей

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

Стало также ясно, что сосредотачиваться нужно именно на общении. Все опрошенные отмечали, что теперь нельзя просто позвонить в УК и что-то узнать: ответит не очень умный робот, а поговорить с живым человеком не получится.

Итоговое продуктовое решение звучало так:

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

На основе Job Stories и фич конкурентов я собрал полный список функций приложения:

  • передача показаний счетчиков и история потребления
  • оплата квитанций по карте и через платежные сервисы
  • архив квитанций, заявок и обращений в УК
  • автоплатёж
  • напоминания о сроках отправки показаний и оплате квитанций
  • вызов мастера с выбором даты и времени, возможность подбора мастера по описанию проблемы и по типовым ситуациям
  • чат с операторами УК, возможность прикладывать к сообщениям фото и видео
  • экстренная связь с диспетчером аварийных бригад
  • заявки в УК с отслеживанием статуса
  • информирование о предстоящих плановых работах, авариях и чрезвычайных ситуациях
  • опросы и собрания жильцов
  • настраиваемые пуш-сообщения
  • оформление временных пропусков для гостей и курьеров
  • доступ к видеокамерам в подъезде, дворе и парковке
  • управление шлагбаумом и дверями пожарных выходов, кладовыми и другой домовой инфраструктурой
  • справочник по законам и нормам в сфере ЖКХ с релевантным поиском и поисковыми подсказками
  • управление домофоном во дворе и на входной двери
  • профиль пользователя и персональные настройки
  • информация по квартире: план, площадь и размеры комнат, высота потолков, точки подведения коммуникаций

В рамках диплома реализовать всё было нереально, поэтому я взял самые основные:

  • новости и оповещения
  • передачу показаний и оплату квитанций
  • вызов мастера и звонок диспетчеру
  • чат с оператором
  • камеры видеонаблюдения
  • справочник
  • заявления в УК

Далее я нарисовал принципиальные макеты в Миро, продумал Tone of Voice и сел рисовать интерактивный прототип и проводить промежуточные исследования. Об этом будет в следующих частях.

 

Интерактивный прототип в Фигме. Смотрите в режиме презентации.

Дипломная работа в гугл-документах

 

Все статьи об учебном проекте:

  1. Задачи и результат
  2. Потребности пользователей — вы находитесь здесь
  3. Основы ToV
  4. Интерактивные макеты
  5. UX-исследование
  6. Как ставить задачи UX-писателю (бонус-трек)
 Нет комментариев    24   10 дн   UX   кейс

Заметки беспечного путешественника

Мы с Ulv Vind выпустили книжку с картинками — короткую повесть о приключениях эльфа Мелентора и его друзей.

Всё сделали сами: придумали мир, написали историю, нарисовали иллюстрации и сверстали макет. Нам удалось напечатать небольшой тираж :3

Расскажу, о чём книга, зачем её читать и как мы её создавали. Ну, и где её купить, конечно же.

Глянцевая печать, 143×200 (A5), 96 страниц, клеевой переплёт

О чём книга

Это по-хорошему юмористическое фэнтези, какие пишут по мотивам игр D&D. Немного Толкиена, чуток Пратчетта и горсть отсебятины.

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

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

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

Зачем читать

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

У книги два достоинства: она короткая и в ней три десятка иллюстраций. Некоторые дополняют историю деталями, которых нет в тексте.

Каждый эпизод дополняет иллюстрация

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

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

История

С чего мы решили писать книгу.

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

К концу марафона у нас кончились идеи и мы запаниковали взялись за фэнтези. Нам не хотелось писать очередную эпическую сагу, поэтому мы решили иронизировать. Ulv придумала путешественников в дремучем лесу, а я сочинил отрывок из дневника.

Первая картинка, с которой всё началось. Инктобер-2019, день 28

Дневник Мелентора. Пятый день пути. Ивар заявил, что он неплохой следопыт и проведёт нас напрямик через лес, поэтому лошадей мы решили взять в городке у Тлеющих гор. Мне начинает казаться, что мы заблудились: пару дней назад Ивар прекратил пить и хвастаться своим мастерством.

Следующий Инктобер мы целиком посвятили новому походу троицы. Продумали мир и основные события, набросали персонажей и план публикаций.

На марафоне планы разъехались, вылезла куча трудностей и выпускать по эпизоду в день было тяжело. Местами мы отчаянно импровизировали, правили сюжет на ходу и закрывали логические дыры, чем могли. Что из этого вышло, можно посмотреть по тегу #ДневникМелентора.

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

Как купить

ВК-паблик Ulv Vind

Если вы живёте в Уфе — напишите мне в телеграм: @vitalyfilatov

Мы напечатали всего 50 штук, 4 апреля оставалось 37.

Чуть позже сделаем PDF-версию.

 

Над книжкой работали

Ulv Vind — иллюстрации

Я, Виталий — текст и вёрстка

Ирина Малкавиан — корректор

Учебный проект: задачи и результат (часть 1/6)

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

Рассказ разбит на шесть частей. Эта часть о курсе, работе UX-писателя, задачах и результате. В конце — ссылки на следующие части и сам диплом.

Чем занимается UX-писатель

UX-писатель организует диалог пользователя с продуктом. По сути, это ещё один мозг, усиливающий UX-дизайнера. Разница в том, что дизайнер организует смысл интерфейсными элементами, а писатель — текстом. Для этого писатель вникает в логику продукта, потребности пользователей и бизнеса, продумывает порядок и стиль общения, а потом пишет все слова в продукте: кнопки, сообщения и инструкции.

Как организован курс

UX-писатель — новая профессия, учиться приходится по книгам, статьям и рассылкам. На начало 2021 года в Рунете был только один курс Нетологии, где предлагали систематизировать знания под присмотром практикующих экспертов.

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

Личный кабинет Нетологии. До диплома осталось получить один зачёт

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

Заказчик и его гипотеза

Строительный холдинг «Яркий» всё делает сам: строит дома, продаёт квартиры и управляет коммунальным хозяйством. В «Ярком» считают, что современное жильё — это сервис, и ставят на технологии и автоматизацию. Это привлекает жильцов комфортом, снижает издержки и репутационные риски.

Чтобы жильцам было удобно общаться с управляющей компанией, передавать показания счётчиков и взаимодействовать с домовой инфраструктурой, «Яркий» разрабатывает собственное мобильное приложение жильца — «Яркий Дом».

Для начала заказчик хотел убедиться, что жильцу нужно именно приложение. Его продуктовая гипотеза звучала так:

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

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

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

Задачи

Я решил, что подключился к проекту до начала разработки и совмещаю роли UX-писателя и дизайнера.

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

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

Подробнее о каждом этапе читайте в следующих статьях цикла.

Результат

Основная задача выполнена — создан прототип приложения на основе потребностей реальных людей.

Стартовый экран, дашборд, вызов мастера и чат с оператором

Проект длился 6 недель. На домашние работы и диплом ушло примерно 45 часов.

Работу похвалила преподаватель курса и мой дипломный руководитель Ирина Моторина, чем я теперь всюду хвастаюсь :3

Фрагмент письма о проверке дипломной работы. В комментариях я извинялся за пропущенную запятую в описании

После защиты я получил свидетельство об обучении. Удостоверение о повышении квалификации всё ещё идёт «Почтой России».

Я учился на шестом потоке, в группе UXCW-6

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

Интерактивный прототип в Фигме, смотрите в режиме презентации

Дипломная работа в гугл-документах

 

Все статьи об учебном проекте:

  1. Задачи и результат — вы находитесь здесь
  2. Потребности пользователей
  3. Основы ToV
  4. Интерактивные макеты
  5. UX-исследование
  6. Как ставить задачи UX-писателю
 Нет комментариев    136   3 мес   UX   кейс

Блог обновился, а дизайн слетел

Если вы вдруг читаете мой блог напрямую, а не через RSS, то вот две новости:

  1. Я обновил движок и открыл комментарии. Раньше они были закрыты из-за ботов. Чтобы высказаться, войдите по учётке Телеграма, Твиттера, ФБ или ВК.
  2. Я не успел перенести старый дизайн на новый движок, так что блог пока побудет со стандартной темой. Ваши комментарии мне важнее.

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

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

Вся драма с обновлениями, кому интересно

В Эгее 2.5 меня не устраивали мелкий текст, широкая колонка и масштабирование на смартфонах. Я нарисовал свой вариант и простоты ради вкрячил его прямо в код движка.

До 2019 всё шло неплохо, но потом спам-боты вконец озверели и стали неистово загаживать блог. Пришлось закрыть комментарии.

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

За пять лет вид блога перестал мне нравиться. Например, пора сменить Open Sans в заголовках на что-то выразительнее. Ну и раньше я рисовал в Фотошопе, а теперь у меня есть Фигма. Новая версия всяко выйдет лучше :3

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

Очевидные выводы

  1. Костыли выгодны только в краткосрочной перспективе. Потом придётся переделывать.
  2. Отклик читателей важнее дизайна.
  3. Тестовое зеркало сайта — это правильно.
  4. Бэкапы нужны всем и везде.
  5. Проблема может оказаться возможностью, просто нужно читать больше мотивационных книжек.
 1 комментарий    85   4 мес  

Улучшаем Мейлчимп за 15 минут

Мейлчимп — популярный сервис почтовых рассылок. На бесплатном тарифе у него куча ограничений, в том числе на количество отправок тестового письма. Черновик можно отправить только 12 раз, потом Мейлчимп начнет ругаться и намекать. Ограничение вполне разумное, но безразличное отношение Мейлчимпа фрустрирует. Смотрите.

Сначала всё хорошо:

Письмо уходит, вас хвалят:

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

...и предлагают отправить ещё одно.

Вы закрываете окошко, диалог отправки тестовых писем не меняется.

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

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

Если бы Мейлчимп прямо предупреждал о количестве тестовых писем и не давал попыток после превышения лимита, такого впечатления не возникало. Ясная демонстрация лучше передаёт главную идею:

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

Тем более что переменная с количеством попыток у Мейлчимпа уже есть. Её можно добавить двумя строчками кода, а заодно дать ссылку на справку. Например, так (накидал в код-инспекторе, за грамотность не ручаюсь):

Предупреждение в диалоге отправки. Осталось 12 писем
Сообщение об ошибке со ссылкой на справку
Вышли за лимит — почитайте справку

Мораль 01. Объясняйте, что происходит. Для этого не нужно рисовать новые страницы три спринта, достаточно написать под основной кнопкой.

Мораль 02. Если вы забыли вывести какое-то ограничение, пользователь обязательно на него когда-нибудь наткнётся, подумает, что вы специально с ним так, и напишет в бложик. А вы даже не узнаете :3

UPD. Я понимаю, что у Мейлчимпа сетка ограничений: на каждую кампанию и суммарно за сутки. Кажется, что разумнее сообщать о лимитах в окне успешной отправки, там где про бон вояж. Но чтобы решить точно, нужна статистика использования. По моей гипотезе лимит на одну кампанию достигается чаще.

 Нет комментариев    85   4 мес   UX

Буги на Красной Поляне

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

В Сочи нужно прилетать утром, когда восходящее солнце вычерчивает длинные тени на Кавказском хребте, а воздух подернут лёгкой дымкой. Когда летишь лоукостером, есть на что отвлечься от затёкших коленей и зловещего скрипа шпангоутов. Немного успокаивало, что я выбрал Боинг 737-800, который не MAX и падает только от старости. Больше опасений вызывала набирающая обороты пандемия: перспектива попасть в карантин со случайно чихнувшем бурятом пугала абсурдным реализмом.

Зайдя с моря, самолёт пронёсся над просыпающимся Адлером, грузно плюхнулся на полосу и покатил к терминалу, потряхивая крыльями на стыках плит. Кто-то по старой традиции похлопал пилотам, но его не поддержали: появился LTE и обновилась лента.

Где-то над Кавказским хребтом

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

  1. Снег у моря бывает раз в год, падает ночью и к утру тает.
  2. После дождя дороги становятся чище.
  3. До зимней олимпиады тут ничего не было и дикий лось бродил меж дерев. К олимпиаде построили всё: горнолыжные курорты, трассы, подъёмники, новую дорогу, трамплин для прыжков в длину и бессчётное количество прочего.
  4. Каждый местный знает, что при строительстве трамплина чеченские подрядчики украли семь миллиардов. Сколько было украдено на трёх туннелях для новой дороги — не знает никто.
  5. Красная Поляна находится в селе Эстосадóк, там раньше жили эстонцы, греки и армяне. Теперь там живут московские дачники и уральские нувориши.
  6. Пристёгиваются только приезжие.
  7. Сочи — главный поставщик мимоз. Их собирают в каждом дворе и возят по всей России. Мы проехали двор с чем-то жёлтым, так что причин сомневаться не оставалось.

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

Яндекс-карты предлагают сразу ехать по новой дороге

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

Вид на Эстосадок и Красную поляну на 960 метрах с Вершины 2200

Село Эстосадок расположено на 600 метров выше уровня моря и в часе езды от берега, климат почти континентальный. На юге возвышается хребет Аибга, а через село течёт Мзымта — коварная и перекатистая горная речушка, чьи мутные воды рискованно переходить без брода.

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

На центральной улице. Все либо на склоне, либо ходят внутри квартала с магазинами и кафе

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

В кабинке, едем на 960 по карточкам из отеля

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

Вид на площадь перед канатной дорогой. За площадью видны отели. Обзорная площадка между отелями покрыта вязью Покраса Лампаса

На следующий день мы забрались уже на 2200. Ехали с тремя пересадками: сначала на 960, потом на 1460, потом уже до конечной. В кабинку помещается восемь человек. Чтобы не ехать рандомно, объявляем себя командой по скоростной посадке. Первый раз садимся за 10 секунд, на обратном пути уже 7,5 — по 0,93 секунды на человека.

Чёрная пирамида — вершина в хребте Аибга, 2375 метров. Мы были на вершине справа, её нет в кадре

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

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

Из развлечений на вершине обзорная площадка, ресторан, качели над пропастью и зиплайн. Разработчики Василий и Игорь отправляются стоять в очереди на зиплайн, а мы — ждать красивого кадра на финише.

Игорь приехал первым и объяснил свой отрыв массой мозга

Обедаем в ресторане «Вершина 2200». Кормят ощутимо дорого, безусловно вкусно, премиально помпезно и немного театрально. Игорь признаётся, что отведал лучший цезарь с курицей за всю жизнь. После обеда коричневый от загара фотограф ведёт нас на обзорную площадку над рестораном, позировать в фирменных худи на фоне гор, неба и блогерш.

Часть команды Девхаба, добравшаяся до Сочи. Фото приглашенного фотографа

После обеда решаем посмотреть подвесной мост через ущелье в Скайпарке. Это огромный комплекс в двадцати минутах от Адлера. Предлагают кучу всего, от тандем-зиплайна до верёвочного парка, но главный аттракцион — прыжки со свободным падением. У начала моста прыгают с 69 метров, в середине — со всех 200. Пока нет желающих, инструкторы прыгают сами.

Вид на начало моста. В павильоне впереди — прыжковая станция на 69 метров

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

Середина моста

С непривычки уровень сервиса удивляет. В Скайпарке с нами радушно поздоровались все — от охраны на входе до баристы и отдыхающих инструкторов. Я поставил рюкзак на пол, но кто-то принёс маленький табурет и переставил рюкзак на него. В ресторанчике с варёными раками нам тактично намекнули не брать гигантских, а взять просто больших. Гигантские криво масштабируются, и их шейки отстают в размерах.

На четвёртый день экспедиция официально завершилась, команда начала разъезжаться по домам. В аэропорт меня отвозил таксист из Марий Эл, мы разговорились о Казани и культуре массовой застройки. Он спросил, как прошла командировка, а я ответил, что ездил не по работе. И это было чертовски здорово :3

Как написать отзыв о компании

В интернете ожесточённо борются за лайки и отзывы. Компании просят заказчиков, друзей и сотрудников оставлять отзывы всюду, где есть соответствующая форма: на Яндекс-картах, Маркете, Хабре и ещё в десятке мест.

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

Общие правила. Что такое хороший отзыв:

  1. Не хвалите компанию просто так. Пишите конкретику: что бы вам понравилось, будь вы заказчиком или соискателем. Такой отзыв будет честен и поможет другим принять взвешенное решение.
  2. В отзыве можно указывать на слабые стороны. Этим вы покажете, что отзыв настоящий. Главное не пересолить: слабости должны подчеркивать конкурентные преимущества.
  3. Пишите грамотно, избегайте эмодзи и восклицательных знаков. Не пишите капсом. Проверяйте текст спелл-чекерами или покажите вашему редактору. Уверен, он любит такое.
  4. Не пишите много. Достаточно одного-двух простых утверждений. Например, команда работает удалённо, но этого не ощущается.
  5. Не агитируйте. Высока вероятность, что читатель увидит в этом попытку манипуляции и проигнорирует смысл.

Анатомия отзыва. Чтобы не писать абстрактные фразы о молодой демонически развивающей команде, инновационно стартапящей самые актуальные веб-стеки, соберите отзыв из ответов на вопросы:

  1. Что вы хотели получить от взаимодействия с компанией и каким оказался результат?
  2. Для чего обращались? Решили ли свою задачу?
  3. Особенности. Что понравилось и не понравилось?
  4. Кому рекомендуете и не рекомендуете?

На все можно не отвечать, возьмите два-три.

Примеры. Заказчик мог бы написать так:

Грамотные и вежливые ребята (3). Обращался с проектом мобильного приложения под iOS (2), переписали под все платформы и помогли с дизайном интерфейса (1). Работают удаленно, поэтому общение через Скайп и Зум (3). Не рекомендую тем, у кого горит: писать код начинают только после исследования, поэтому за неделю не сделают, нужно закладывать время (4).

А соискатель примерно так:

Искал работу по UX-проектированию, нашел вакансию, решил написать (2). Быстро ответили, выслали тестовое. По результатам не прошел (1), но подробно ответили по тестовому и помогли найти ошибки (3). Попробую ещё раз через полгода.

Добавьте о людях

Зарисовка о писательском ступоре и смыслах. Выводы в конце.

В Девхабе выпустили приложение сервиса Попути и собрали кейс. В черновиках заголовок был такой:

Cервис удалённого заказа кофе на маршруте или в ближайшем заведении

Пока писал остальное, глаз замылился, заголовок казался рабочим. Утром коллеги пришли с критикой: заголовок звучит безграмотно и угловато, как киношный чиновник из села. «На маршруте» — так говорят, вообще? Перечитываю, пугаюсь «ближайшего заведения». Хочется легче и веселее.

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

Качаюсь на стуле и понимаю, что проблема не в поиске слов, а в смысле. В тексте и так много о маршруте и заведениях, в заголовке про них можно не говорить. Лучше сказать, чьи проблемы решает сервис. Получается так:

Сервис удалённого заказа кофе для водителей и пешеходов

Вот, теперь хорошо. Было описание функций, стало — перечисление групп пользователей.

Вывод: проблема со словами чаще всего означает проблему со смыслами. Если не получается внятно описать что это, добавьте для кого это.

Картинка Ulv Vind

Сайт курса по бэкенду

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

Авторы курса — Евгений и Сергей — за десять лет практики собрали все грабли, устали от унылого хаоса в разработке и решили передать свой опыт в формате онлайн-курса. Курсу требовался сайт, который бы объяснял пользу, показывал экспертность авторов и отличался от лендингов с перепродажей чужих лекций. Получилось так: howto.stringconcat.com

Работа над сайтом условно делится на шесть смысловых этапов:

уточнение задачи → сбор и анализ материала → поиск структуры → текстовый макет → подбор иллюстраций → вёрстка

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

Уточнение задачи

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

Исследование

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

Для сайта курса я изучил черновики рекламных писем, заметки по ЦА, сценарий вводного ролика, посмотрел несколько лекций, изучил учебный план, почитал Хабр и Ebanoe.it. Это помогло погрузиться в тему, собрать вопросы для интервью и наметить способы демонстрации полезного действия курса.

Поиск структуры

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

Хорошая структура появляется эволюционным путём

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

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

По мере работы с текстом становится яснее, какие вопросы могут возникнуть у пользователя, и структура немного меняется.

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

Текстовый макет

Когда материал собран и распределён по смысловым блокам, остаётся придать ему форму, дописать и подобрать иллюстрации: картинки, схемы, таблицы, ролики, примеры. Рисовать их пока рано, достаточно обозначить функции и схематический вид.

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

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

Как разработать продукт, за который не стыдно

Как поддерживать и развивать проект, не жертвуя сном и здоровьем

Перестать выгорать и начать жить

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

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

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

Иллюстрации

Самая важная и самая сложная часть. Иллюстрации создают настроение и убеждают сильнее слов, демонстрируя работу продукта.

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

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

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

Картинку в шапке сделал Сергей и она идеальна. Мы долго обсуждали, что туда поставить, пока Сергей не предложил описать курс на языке Kotlin.

Всё по делу: стиль и формат кода, среда разработки, ночная тема, структура проекта на боковой панели и названия вкладок

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

Оригинал и результат. Евгений демонстрирует позитив, спокойную уверенность и открытость

Вёрстка

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

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

Всё, кроме шапки, сделано на типовых блоках Тильды. Шапка — зеро-блок с вариантами под разные устройства.

Рассказ о курсе свёрстан в две колонки. Левая кратко пересказывает правую и работает как якорь, чтобы взгляду было за что зацепиться.

Всё набрано шрифтом Open Sans. У него почти нет характера, открытый рисунок и широкий диапазон жирности. Сейчас я бы сделал заголовки чем-то более выразительным, например, шрифтом IBM Plex.

Для удобства чтения размер основного текста подобран так, чтобы в строке было не больше 80 знаков. Местами текст немного подрезан или переписан, чтобы выровнять правый край абзаца. Где не получилось переписать, стоят мягкие переносы.

Особый шик — колонки одинаковой высоты:

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

Отзыв из переписки Евгения

Рерайт: как позвонить в квартиру

Разбираемся в визуальном контрасте, иерархии и сценариях на примере короткой инструкции к домофону.

В геометрическом центре Уфы построили жилой комплекс «Идель Тауэр» с небоскрёбом, подземной парковкой и забором. На входе висит домофон с инструкцией вызова квартиры:

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

Определять подъезд по номеру квартиры просто, с этим справится даже детский электронный конструктор. Конкретно этот домофон просто не предусматривает сквозной нумерации квартир в отдельных зданиях, но умеет перенаправлять вызов, как офисная АТС.

Изменить или заменить домофон мы не можем, поэтому работаем с инструкцией. Попробуем сделать её проще для восприятия.

Собираем проблемы

У текста нет видимой структуры. Чтобы понять суть, табличку приходится читать последовательно. Немного помогает деление на блоки, но текст всё равно сливается в полотно и разбираться в нём не хочется.

Чтобы проверить структуру, достаточно посмотреть на текст издалека или без очков. Если всё выглядит монотонно, структура плохая.

При беглом взгляде табличка похожа на какое-то объявление администрации

Непонятно, для кого эта инструкция. В заголовке обращаются к жителям, в тексте объясняют, как позвонить консьержу и в квартиру. Есть гипотеза, что после канцелярского обращения «Уважаемые…» включится булщит-фильтр и читатель решит не тратить время.

Таблички часто начинают с крупных «Внимание!» и «Уважаемые…», потому что это работает в устной речи. В письменной речи вниманием управляют заголовки, поэтому лучше писать крупно саму суть: Не паркуйтесь у ворот, скорая не сможет подъехать.

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

Изучаем сценарии

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

  1. Позвонить в квартиру
  2. Вызвать консьержа
  3. Открыть дверь ключом

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

Звонок в квартиру — самый сложный сценарий. Нужно объяснить порядок набора и показать таблицу с делением квартир по подъездам и секциям:

Секции А, Б и В — это строительная маркировка, 2 — вторая очередь строительства. Жители привыкли к номерам секций, поэтому их стоит оставить. Возможно, кто-то так и говорит гостям: 501 квартира в 2В.

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

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

Пишем текст и рисуем

Делим текст на сценарии, выделяем заголовки, собираем номера квартир и подъезды в табличку, рисуем иллюстрации.

Получается так:

Стало и было

Процесс по шагам в Фигмe

Обсуждение в ВК

Вавилонская формула

Как я убеждал читателя выдуманным графиком. История сразу про всё: внутреннюю рассылку Девхаба, Хабр, древний Вавилон и математику. В конце — выводы. Ведь из каждой истории можно сделать вывод.

Ситуация

В 2018 Хабр Карьера анонсировала сервис публичных оценок компаний. Сотрудники анонимно оценивают работодателя по 12 критериям, пользователи портала видят усреднённые оценки, а руководство получает обратную связь.

Как только сервис запустили, мы попросили команду поучаствовать и получили 12 отзывов — сходила примерно треть. Этого было мало для выводов, поэтому мы решили позвать всех ещё раз.

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

Больше отзывов → яснее картина происходящего → точнее курс.

Гифки и мемы не годились, хотелось чего-то шуточного, но с понятным посылом. Поэтому я решил нарисовать график роста ясности и отметить на нём текущее положение дел:

12 отзывов проясняют ситуацию только на четверть

Замысел

График задумывался как пародия на популярные бизнес-метрики. Реальной зависимости он не показывал, а просто притягивал внимание и развлекал. Расчёт был запомниться абсурдностью: некая ясность в диапазоне от 0 до 1 и очевидно ускоряющийся её рост с каждым новым голосом. Читатель посмеётся, а позже возможно вспомнит синюю полоску и невольно подумает про отзывы.

Удивлять чем-то неожиданным и запоминающееся — старый рекламный трюк. Например, ВВС США завлекают женщин на контрактную службу детёнышем транспортника C-17:

Большие стёкла кабины, короткие крылья и фюзеляж рефлекторно вызывают умиление

Реализация

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

Известные мне нелинейные функции не годились, и я обратился к приятелю-математику Илье (Илья, привет!) Он выслушал постановку, посмеялся и сотворил нечто из начал анализа:

Натягиваем сову на глобус: Σ — ясность, N — общее количество участников, x — количество полученных оценок

Графику требовалась формула, а формуле — история, которая бы объясняла её абсурдность. Я почитал Википедию, написал фрагмент вымышленной книги «Знаменитые математические формулы» и оформил её как халтурный рип из электронной библиотеки.

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

Результат и выводы

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

В 2018 Хабр Карьера ещё была Моим Кругом

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

Выводы из этой истории:

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

Приходите обсуждать ко мне Вконтакт.

Как вас подведут картинки из гугл-доков

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

UPD. В письма тоже не вставляйте.

Для начала три истории из моей практики.

Как бывает: в компании всё пишут в гугл-доках. Маркетолог готовит статью с фотографиями, публикует её в корпоративном блоге, через полгода увольняется, а ещё через год кто-то заходит в статью и видит битые ссылки. Фотки приходится искать в архиве, заново обрабатывать и заливать.

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

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

Причины подобных ситуаций в неочевидной особенности работы гугл-доков с изображениями.

Гугл-док это веб-страница, которая хранит текст с оформлением и адреса картинок. Файлы картинок хранятся где-то в недрах Гугла и напрямую недоступны: их нельзя скопировать и вставить, как в Ворде.

При копировании гугл-док отдаёт в буфер обмена html-код с текстом и адресами картинок. Сами картинки в новое место не копируются, а остаются в хранилище Гугла. Визуальный редактор Мейлчимпа или блога распознаёт разметку и отображает картинки, словно они перенеслись вместе с текстом. Кажется, что всё в порядке.

Результат вставки в Мейлчимп, блог на Ghost и самописный скрипт для чистки гугл-доков. В коде выделен адрес картинки, ведущий куда-то в Гугл

Картинки остаются на месте только пока документ жив. Но если автор удалит документ за ненадобностью, его отключат от корпоративного домена Гугл Сьют или дата-центр Гугла заденет хвостом комета, документ исчезнет, а вместе с ним и картинки. Восстановить их будет невозможно.

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

Чтобы картинки не зависели от гугл-дока, вставляйте их отдельно. Если визуальный редактор блога или базы знаний не умеет загружать и вставлять картинки при перетаскивании, придётся заливать их в облачное хранилище или публичную папку на сервере и вставлять по URL. Это хлопотно, но зато вы ничего не потеряете.

Сохраняйте исходники картинок. Давайте файлам осмысленные имена и подписывайте картинки в документе, чтобы не путаться на вёрстке.

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

Изображение и его полный адрес на сервере

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

Соблюдайте эти простые советы, и ваш редактор не будет вопить, из-за того, что в иллюстрированной инструкции трёхлетней давности вдруг пропали скриншоты.

Комментарии в ВК

Хтонического ворона в начале статьи нарисовала Ulv Vind. Его зовут Эдгар.

Что общего у веб-сервиса и звездолёта

Шутка про IT и глупые клише в современной фантастике. Кратко:

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

Кинофантастика последних лет стала точнее описывать тенденции технического прогресса. Теперь в космических кораблях будущего все глобальные проблемы решаются на высоком системном уровне: переключениями светящихся проводов, спортивным хаком ядра ОС и прочими впрысками макгаффина в консоль реактора.

Энсин Тилли спасает Дискавери
Энсин Тилли спасает Дискавери с закрытыми глазами

Глупостей хватает в любой космоопере, приведу три примера на мотив свежего Стартрека.

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

— Я знаю, что делать! Переключим дефрижератор на амрижератор по обводному контуру и инвертируем тахионную центрифугу!

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

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

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

Бип и Буп нашли задачу по силам
Бип и Буп нашли задачу по силам

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

К сожалению, пока в такое будущее довольно легко поверить. Современные программы становятся примитивнее по функциям, но сложнее и запутаннее внутри, стремясь занять всё доступные ресурсы и сетевой трафик. Сайты страдают ожирением от скриптов и подгружаемых модулей, Фотошоп задыхается от собственного веса, а многие мобильные приложения просто не работают без сети. Нет ничего цельного, всё собрано второпях из плохо подогнанных кусков и скачивается откуда-то из Малайзии. Дальше появится 6G и искусственный интеллект, который сам начнёт кодить, и мир утонет в сложных зависимостях или типа того.

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

Живите долго и процветайте!

Живите долго и процветайте!

К чему приводят ошибки валидации

У меня есть суперспособность — попадать в системные дыры и ломать процессы. Я могу заблудиться в аэропорту, переночевать в уже сданном номере, на мне ломается электронная очередь, глючат паркоматы и скрипты в сервисных центрах.

Расскажу одну такую историю, а в конце поделюсь выводами.

Я купил в московском магазине железяку с доставкой до двери компанией СДЭК. Железяка быстро доехала, но вручить посылку у транспортной компании просто так не получилось: Плутон стал ретроградным и я вновь попал в какой-то каскадный баг.

Мне написал менеджер магазина: посылка уже в городе, но в СДЭК не могут со мной связаться. В пропущенных было пусто, поэтому я решил проверить реквизиты в накладной СДЭК и в договоре с магазином.

Номер телефона был указан верно — форма отслеживания посылки его принимала, — но в адресе из номера дома исчезла дробь. Поменять адрес доставки на сайте СДЭК не получилось: форма отказалась принимать адрес с дробью, выдав неустранимую ошибку с расплывчатой формулировкой. «Корпус» и «корп.» вместо дроби тоже не помогли. В итоге форма всё же отправила данные, но изменились только валидные: дата и время доставки.

Связаться непосредственно со СДЭК не вышло. На горячей линии никто не отвечал, виджет онлайн-звонка два раза подряд выдал маркетинговой чепухи, сослался на занятость операторов и закрылся. Форма заказа обратного звонка попросила обязательные имя, телефон, город, тему запроса и номер договора. Затем она сломалась и перестала показывать города после буквы «б». Я выбрал Абакан, но мне всё равно никто не перезвонил. Не особо надеясь на ответ, я написал СДЭК в ВК-сообщество.

Скрин от 11 мая. Если не актуально, можно и не читать

Решил действовать через магазин. Менеджер оперативно связался со СДЭК, но выяснил только, что курьер приезжал, не дозвонился и доставку перенесли на завтра. Адрес в СДЭК не исправили, сказав, что курьер всё уточнит перед поездкой. Но ему никто ничего не сказал, поэтому сначала курьер попробовал сдать посылку по неверному адресу.

Транспортные компании требуют предъявлять паспорт, но курьеры часто отдают посылки без проверки документов. Это логично: какая разница, кто заберёт груз, если адрес правильный. Теоретически, на первом адресе без дроби могли оказаться ушлые шутники и мне пришлось бы нудно бодаться вначале со СДЭК, а потом и с магазином.

Выводы

Как избежать каскадной жести.

  1. Типовые сообщения для ошибок — зло. Хорошо подсказывать пользователю, что он делает не так. Например, в каком формате следует вводить адрес, если некому научить форму парсить эти данные самостоятельно.
  2. Если отваливается справочник городов, нужно давать пользователю указывать город произвольно. Выпадающий список должен показывать, что он сломан, данные не загружены и следует попробовать позже.
  3. На выходные и праздники стоит менять скрипт автоответчика, чтобы пользователь не ждал ответа. Робот не должен просто обрывать звонок, если операторы долго не отвечают, а подсказывать альтернативные способы связи.
  4. Чтобы сервис работал, компании нужно сервисное мышление, а не сервисные ценности.
  5. Клиентским сервисам лучше совсем не принимать сообщения через ВКонтакт, чем отвечать через трое суток.
  6. Формальная вежливость лучшее, чем безразличие. Хорошо доводить любой диалог до логического конца, это оставляет положительное впечатление.

Upd. Комменты закрыты из-за спама, приходите в ВК-пост.

Ошибки и задачи с известным решением

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

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

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

Учебные и игровые задачи предусматривают решение.

Более того, подразумевается, что учебные и игровые задачи рассчитаны на некий усреднённый уровень интеллекта. Отсюда негативные оценки при неудаче: ошибся → дурак.

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

Реальные задачи могут вообще не иметь решений по независящим от нас причинам.

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

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

В реальном мире ошибки неизбежны, а полный контроль недостижим.

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

  1. Стараться находить ошибки вовремя
  2. Оперативно исправлять, что получится
  3. Научиться оценивать последствия
  4. Разбирать причины и степень своего влияния на ситуацию
  5. Исключать повторение уже известных

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

upd. Я устал чистить комменты от спама, поэтому они закрыты. Приходите в комментарии под ВК-постом :)

Ранее Ctrl + ↓
UX