Дизайн
Doubletapp
5886

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

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

В закладки
Аудио

В статье мы рассмотрим типичные проблемы в UX, которые встречаются в приложениях как стартапов, так и больших корпораций.

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

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

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

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

Очень часто такие вещи не детализируются в задаче, которая попадает к разработчику. Я наблюдал такое и в стартапах, и в корпорациях (особенно в тех, что «с атмосферой стартапа»), и ранее в нашей студии.

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

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

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

Всегда ставьте себя на место пользователя!

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

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

Маленькая область нажатия

В Android размеры области нажатия должны быть в ширину и высоту не меньше, чем 48 dp, в iOS не менее 44 points. Мнение Google и Apple.

Частый сценарий: что делать, если у вас картинка 24 dp x 24 dp? Нужно сделать элементу внутренний отступ (padding) во все стороны по 12 dp (пример для Android).

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

Если у этой картинки есть внешние отступы (margin) от других элементов, то увеличенный размер самой картинки надо не забыть учесть при высчитывании margin-ов. То есть, если картинка у вас (или в макете) была 24dp, margin справа был 16dp, то теперь margin справа станет 4 dp, так как 12dp съел padding.

Нет реакции на нажатие

У кликабельных элементов должна быть реакция на нажатие. Это важно, потому что:

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

  • Создает ощущение «Responsive UI» — например, если следующий экран не открывается в тот же момент, как нажали (приложению надо чуть-чуть подумать), то пользователь видит, что система реагирует — нет ощущения лага. Даже в веб-приложениях для этого стали использовать реакцию на нажатие.

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

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

Есть реакция на нажатие, когда не надо

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

Нет скролла

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

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

Особенно это может быть проблемой, если есть поле для ввода и что-то под ним — если покажется клавиатура, то посмотреть, что под ней, можно только скрыв ее, что неудобно.

Клавиатура не появляется автоматически

Частая ошибка. Например, у вас открывается экран поиска. Или открывается диалог, в котором нужно ввести название чего-нибудь. Или экран с вводом кода из смс. В общем, если в 9 случаях из 10 пользователь на этом экране тут же нажмет на форму ввода текста, то стоит ему помочь: автоматически установить фокус в поле ввода и открыть клавиатуру.

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

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

Не скрывается автоматически клавиатура

Ошибка встречается на Android: пользователь ввел данные, нажал «Submit», экран сменился, или диалог закрылся, а клавиатура осталась. Хотя поля для ввода уже нет. Или вариация: на «submit» клавиатура закрывается, но не закрывается, если пользователь уходит с экрана через кнопку назад в левом верхнем углу в тулбаре. Клавиатуру в таких ситуациях нужно автоматически закрывать.

Ввод текста не начинается с большой буквы

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

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

Нет фокуса на следующем поле ввода при нажатии Enter

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

Здесь, если пользователь заполнил поле «Имя», то при нажатии на клавиатуре «Enter» (кнопка должна автоматически называться «Далее»), фокус должен автоматом перейти на следующее поле ввода. На Android система обычно делает это автоматически (но за ней стоит проверить), на iOS это поведение надо задавать вручную.

Нет автосабмита при нажатии enter

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

Чаще всего после заполнения последнего поля, пользователь сразу готов к отправке формы. Поэтому при нажатии им на enter на клавиатуре, нужно вызвать отправку формы программно, как если бы пользователь нажал на кнопку «Submit».

Тут, например, если пользователь, после того, как введет пароль, нажмет на клавиатуре «Enter», автоматически должен произойти submit (то есть то же самое, что и нажатие на кнопку «Войти»).

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

Нет индикатора прогресса

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

  • Диалог с прогрессом. Не идеальное решение, так как слишком агрессивно прерывает взаимодействие пользователя с приложением. В системе Android соответствующий класс объявлен как устаревший (deprecated).

  • Показать где-то прогресс бар или спиннер. Где именно? Можно заменить кнопку, которая выступает submit-ом, на спиннер — это хорошо еще и тем, что пользователь не нажмет на нее второй раз.

Если речь идет не про отправку, а про загрузку данных, то опять же нужен индикатор. Типовые решения: вместо места, где будут данные, показать спиннер. Если список с pull-to-refresh, можно показать pull-to-refresh.

Можно засабмитить форму, хотя она уже в процессе сабмита

Было упомянуто в предыдущем пункте. Допустим, на экране логина пользователь ввел данные, нажал кнопку «Войти». Если кнопка не заблокировалась, то, пока идет общение с сервером, пользователь может нажать на неё еще раз.

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

Свайпабл вьюхи не свайпаются как надо

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

Нажатие назад ведет не туда

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

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

Тормоза, прыжки, лаги

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

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

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

{ "author_name": "Doubletapp", "author_type": "self", "tags": ["ux","mobile","ios","android"], "comments": 43, "likes": 52, "favorites": 254, "is_advertisement": false, "subsite_label": "design", "id": 126302, "is_wide": true, "is_ugc": true, "date": "Thu, 21 May 2020 12:17:28 +0300", "is_special": false }
Техника
По пути Папы Карло: от деревянного сканера к реальному бизнесу
Сейчас, когда каждый из нас послушно сидит на самоизоляции, мы искренне скучаем по офису, разработке и…
Объявление на vc.ru
0
43 комментария
Популярные
По порядку
Написать комментарий...
19

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

Ответить
3

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

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

Ответить
6

Почему-то все камни летят именно в разработчиков..
И никто даже не вспоминает, что одни элементы и детали программисту реализовать проще, чем другие и выглядеть они будут лучше на бОльшем числе разных устройств.
Это к слову о том, что нынче дизайнеры очень любят делать верстку какого-нибудь кроссплатформенного приложения( iOS + Android ) исходя исключительно из габаритов iPhone X.
На десятке то оно, допустим, в итоге будет норм смотреться, а на всем, что не_десятка по габаритам экрана и соотношению сторон( множество старых яблок и почти все андройдофоны ) - просто "***" ( "так себе" ), поскольку проблемы либо с масштабированием, либо - с тем, чтобы затолкать содержимое одного экрана( которое норм умещается на длинном экране десятки ), собсно, в один экран, либо - даже на простых экранах появляется необходимость прокрутки.

Ответить
2

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

Ответить
1

Они далеко не всегда должны быть именно адаптивными и под разные платформы итд итп, т.к это еще сильнее может все усложнить( особенно, если речь о разработке кроссплатформенного мобильного приложения на условно-универсальной платформе. Т.е когда проект условно один, но ОСей - несколько ).
Но оно должно быть продумано таким образом, чтобы легко и однообразно переносилось на разные устройства с разным соотношением сторон, размером экрана и разной ОС( "а вдруг пользователю на андройде будет непонятно, как год в календаре настраивать - давайте там тоже яблочную 'вертелку' использовать " ).

Ответить
0

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

Ответить
1

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

Ответить
0

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

ну и не во всех студиях такая схема работает.

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

Ответить
0

Лайк за красивую аву :D

Ответить
4

Спасибо! Как раз собираемся пилить апп под Андроид. Поможете? : )

Ответить
1

Первый коммент написали не туда)

Конечно запилим, напишите нам на hi@doubletapp.ai!

Ответить
4

Какая у вас классная нативочка получилась 😉

Ответить
4

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

Ответить
0

У меня есть пароли с пробелами

Ответить
0

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

Ответить
0

чё эт недопустимы? Всё допустимо. Просто некоторые боятся по привычке.

Ответить
2

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

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

Ответить
1

согласен с вами. лучше сделать возможность сворачивать клавиатуру

Ответить
0

она в андроиде и так сворачивается по кнопки "назад", ну

Ответить
0

а без кнопки назад?

Ответить
0

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

Ответить
0

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

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

Ответить
0

чаще всего при нажатии enter вообще ниче не меняется :) приходится самому сворачивать клаву ( а может еще и вернуться назад на экран ) проверять текст (Которые перекрывает клава ) потом опять тыкать в клаву и так 20 действий вместо 3

Ответить
0

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

Ответить
5

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

Ответить
2

дизайнер программировать? 
имхо это уже слишком

Ответить
–1

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

Ответить
1

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

Ответить
1

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

Ответить
0

не лучше ли разрабам подучить дизайн? 
Что за наезды необоснованные? ЗАЧЕМ кому то знать 5-10 вещей на 30% вместо одной на 90% ? кому лучше? 
Я в дизайне то не успеваю не то что учить новое а просто применять старое а вы хотите чтоб я еще и кодил? ))

Ответить
1

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

И вообще, вы ж в Game Dev Tycoon не делаете персонажей, которые тупо с Design-поинтами либо только с Tech-поинтами, там даже самый первый сотрудник будет с соотношением 50:50 развит.

Ответить
0

ну я ответил конкретно на эту фразу: "многие дизайнеры почему-то сегодня не хотят учиться программировать, хотя я бы такого с руками отрывал, если бы был представителем бизнеса" 

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

мне нравиться ваше сравнение с игрой :) 
Да можно найти совершенно разных людей с разной "раскачкой" пойнтов
Кто то вложил все 100 очков в дизайн или фронт например и он СПЕЦ! 
Кто то 50 на 50 или 70 на 30
Кто то ( как я) имеет 5-10 сфер вместо одной 
И все это для разных целей и задач.

Ответить
0

Чаще действительно приходится разобраться разработчику в дизайне, а не наоборот.
Но вообще, это дискуссия о T-shaped и I-shaped специалистах. Не то что бы кто-то кого-то лучше. Но если речь не идет об ограниченных ресурсах, то дизайнер должен довести дело до конца. Если же задача сделать быстро и дешево, то лучше T-shaped команда.

Ответить
1

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

Ответить
0

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

Ответить

Комментарий удален

1

Ну, чёт описаны правила типа 2*2=4. Так что пропущу их дух и просто зацеплюсь за фразы. Например, вот:

Например, у вас открывается экран поиска.

И пользователю может быть удобно выбрать из подсказок, которые клавиатура перекроет

Или экран с вводом кода из смс.

Для этого в Android есть готовое API. Приложение объявляет системе, что сейчас придёт код активации и тогда система сама передаст этот код в приложение. Удобная штука, которой мало кто пользуется

Ответить
1

Ну, чёт описаны правила типа 2*2=4.

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

И пользователю может быть удобно выбрать из подсказок, которые клавиатура перекроет

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

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

Ответить
0

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

Ответить
0

В прошлом году появилась, вроде. А зачем её двигать? Была статья в девелоперском блоге, чего ещё надо? Презентацию для фичи?

Ответить
1

Надеюсь, фронтендеры некоего сайта vc.ru прочтут эту статью и добавят пикселей 20 вокруг слова "развернуть" в разделе уведомлений)) А то нажимаешь, а вместо "развернуть" перекидывает на статью.

Ответить
0

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

Ответить

Комментарий удален

0

Основные проблемы: 

1. Нет фичи А.
2. Есть фича А.

Ответить
0

Поясните, пожалуйста, что вы имели ввиду?

Ответить

Прямой эфир