Привет всем! Это не обычная статья, это целый курс про UX-редактуру от Ozon. Мы с вами разберем, что такое UX-редактура, какие бывают форматы интерфейсных текстов и как их писать качественно, быстро и просто.

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

Этот курс подойдёт тем, кто только погружается в мир UX-редактуры и хочет стать продуктовым редактором. А также тем, кто вынужден писать тексты для приложений, но не умеет (или думает, что не умеет).

Я подготовила 4 урока, где разобрала, как мы пишем тексты в Ozon. Для вашего удобства основная информация продублирована в видеоуроках. В роликах есть ещё много приколов, которые невозможно передать в статье, так что можно и смотреть, и читать — как вам удобнее! 

Привет! Я Катя Глушанина, тестировщик в 2ГИС. В далёком 2019 год в нашей компании было не так много сотрудников, а тестировщиков в веб-отделе — ещё меньше. Мы все работали в офисе, много общались и решали вопросы на месте. Ламповость атмосферы была включена по умолчанию. Компания начала расти, и с этим пришли новые вызовы. Стало больше команд, тестировщиков, появились удалённые сотрудники.

Это привело к трём «побочным эффектам»:

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

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

Чувство изоляции. Одному дома может быть грустно: даже мем не с кем обсудить.

И мы поняли, что нужно что-то менять.

Меня зовут Женя Тютюев, я iOS-разработчик в компании 2ГИС. Хочу поделиться, как адаптировал наше приложение под VoiceOver: 

— Делюсь историей про сдвиг парадигмы и как перешёл из стадии «делать, потому что Эпл советует» в совершенно новую — «делать для людей». 

— Как разработал новый вид snapshot-тестирования, чтобы ничего не ломалось при добавлении новых неадаптированных элементов. 

— И описал несколько нюансов, которые важно учесть в работе: escape, динамический расчёт доступности, укрупнение элементов.

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

Привет, я Фируз Шоев, тестировщик в Отелло — сервисе бронирования отелей от 2ГИС. Мы в стадии активного роста и постоянно усиливаем команду. Несколько месяцев назад я подключился к найму тестировщиков и с тех пор провожу собеседования практически каждую неделю. За это время я стал замечать, что многие кандидаты не уделяют должного внимания тестированию фронтенда.

Почти в каждом втором собеседовании я слышу следующее:

— Во фронтенде можно максимум вёрстку протестировать отдельно от бэкенда.

— Фронтенд тестируем через end-to-end тесты, но они сложные и нестабильные.

— А как вообще тестировать фронтенд изолированно?

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

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

Мы добавили реалистичные дороги в навигатор 2ГИС. Теперь дорожное покрытие, разметка, объёмные развязки, съезды, островки безопасности и опоры на многоуровневых дорогах выглядят как в жизни. Под капотом — решение задачи по превращению «плоской» геометрии в объекты с реалистичными шириной и высотой. Чтобы не замедлять обновление дорожной сети, нам требовалась минимальная задержка между изменением дороги и обновлением её «объемного» представления.

Расскажу, как в одном сервисе формируем очереди в RabbitMQ, а в других — читаем и при помощи библиотеки NetTopologySuite превращаем плоские объекты в реалистичные. Выбранный нами подход с потоковой обработкой изменений универсален, поэтому статья может быть интересна всем, кто работает с геометрией и системами реального времени в целом.

Привет! Меня зовут Алина Бузинова, я менеджер продукта Отелло, сервиса бронирования отелей от 2ГИС.

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

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

Недавно в карте 2ГИС появились небо и туман, которые можно увидеть, увеличив масштаб и наклон. 

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

^{— Руководители проектов круче!} 

^{— Нет, продакт оунеры круче!} 

Мне, как руководителю проектного офиса, приходилось сталкиваться с тем, что продакт- и проджект-менеджеры:

— путаются в базовых терминах, таких как «проект» и «продукт»,

— не понимают, в чем отличия руководителя проектов и продакт оунера, 

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

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

Идея

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

В памяти есть какие-то онлайн-проекты.
Беглый поиск дает много примеров из разных городов: Портланд, Рейкьявик, Нью-Йорк: Бруклин, Манхеттен, Барселона, Любляна, Львов, и даже проект масштаба страны, — Нидерланды.
Про Петербург тоже кое-что есть: например, отличные данные на Петроградку: «Ретроспектива застройки Петербурга» и проект Делового Петербурга: «Как застраивался Петербург: история строительства города за 68 секунд».

Цель — бумажная карта, к идее сделать how-old-is-this.house приду в процессе. Начинаю искать сырые данные.

Современный мир разработки, по-своему, прекрасен. Хорошей практикой считается свободное распространение своих знаний и разработок. Стремление к знаниям создает спрос, а habr, toster (ныне qna), github, митапы, конференции и прочее являются отличным предложением. О митапах и конференциях я сегодня и хотел бы рассказать. Под катом история как я, будучи разработчиком и собственником IT-компании, начал выступать на IT конференциях.