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

File Uploader представляет собой элемент интерфейса, который позволяет пользователям выбирать и загружать файлы. Обычно он состоит из кнопки «Выбрать файл» или поля для перетаскивания файлов, которые пользователь может выбрать для загрузки.

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

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

Вводные

В прошлой версии нашей дизайн-системы уже имелся File uploader, но:

• он не покрывал многие сценарии;

• не был адаптирован под мобилу : ));

• морально подустал и визуально устарел. Короче говоря, не соответствовал нашему новому клёвому редизайну.

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

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

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

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

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

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

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

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

Ограничения и особенности в мобильной версии

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

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

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

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

4. Операционная система и приложения. Различные операционные системы могут иметь разные способы загрузки файлов.

5. Ограничения по количеству символов в названии файла. Более компактное отображение названия без потери информативности.

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

7. Ограничение размера устройства. Мобильные компоненты, как правило, ограничены по ширине.

Накладываем на это особенности запросов для нашего сервиса:

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

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

3. Многопрофильные сценарии. Вариации компонента под разные сценарии, без потери согласованности.

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

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

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

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

Сборка

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

• File row. Строка, отображающая загруженные файлы, в основном предусмотрена для таких ситуаций, когда загружаются только документы, где важен только тип файла (pdf, jpg и т. д.), а также важно видеть файлы списком. 

  

• File photo. Когда мы загружаем фотографии, нам важно контролировать то, что мы хотим подгрузить в систему, поэтому важен предпросмотр, чтобы можно было легко идентифицировать объект на фото прежде, чем он попадёт в систему :) 

  

  

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

  

  

Состав компонента

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

• Предпросмотр (полный или сжатый). Важный элемент компонента, который первостепенно считывается пользователем на уровне с названием файла. Является постоянным наполнением.

  

• Название файла и его расширение. В нашем компоненте название ограничено количеством строк, а именно максимальной длиной названия является две строки, далее текст скрывается в три точки. Является постоянным наполнением в двух типах компонента 

  

• Subtitle. Для указания доли загрузки или, в последующем, для описания веса файла, даты загрузки или др. То есть какой-либо полезной информации, которая вписывается в зависимости от потребности командой дизайнеров, которые берут компонент в работу. Является постоянным наполнением в одном типе компонента.

  

• Возможность выбора файла. Такая функция может быть включена или выключена в зависимости от заложенного процесса. Является непостоянным наполнением.

  

• Кнопки совершения действий с файлом. Действия, заложенные компонентом, можно изменять в зависимости от потребностей. В мобильной версии используется только одна кнопка для экономии пространства, и действия выводятся по нажатию через BottomSheet. В десктопе же допустимо использовать до трёх кнопок. Является постоянным наполнением в одном типе компонента.

  

• Badge. Для отображения того или иного статуса документа. Такая функция может быть включена или выключена, в зависимости от заложенного процесса. Является непостоянным наполнением.

  

• Swap-зона. Для размещение негабаритных дополнительных элементов, которые не предусмотрены компонентом. Какие-то узкоспециализированные сценарии на усмотрение дизайнеров. Является непостоянным наполнением.

  

Badge и swap-зона выделены в единую группу, которую можно полностью отключить.

Документация и технические аспекты

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

Помимо описания работы компонента сюда же подтягиваются и особенности носителя, платформы и т. д. Например, кнопка «more», они же три точки, на iOS и Android будет иметь разное отображение. Это обусловлено разным поведением этого элемента внутри самой системы. В мобильной версии компонента мы можем подтягивать предпросмотр фотографии в процессе загрузки, а в десктопе это сделать невозможно по техническим причинам.

Применение

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

Визуал

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

• Согласованность и соответствие всем остальным элементам в вашей библиотеке. Допустим, если вы хотите сделать скругления компонента 20px, но ваша библиотека основана на скруглениях 12px, то не стоит выделять свой компонент среди других. Это только создаст дисгармонию при использовании компонента дизайнерами в своих макетах.

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

  

• Важно рассмотреть на этапе проектирования компонента все его состояния и реакции, сопоставить это со всеми возможными сценариями в продукте. Это предотвратит дальнейшие ошибки при сборке макета и сократит количество обращений дизайнеров к вам с просьбой «поправить макет» :)

• Предусмотрите компактную и расширенную версию компонента. В случае загрузчика файлов мы приняли как сокращённую версию (min) карточку без отступов, а как расширенную версию (max) — полноценную карточку с отступами. 

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

Заключение

Ну, кажется, всё! 

Резюмирую:

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

• Собирайте компонент достаточно пластичным, но не перегружайте его настройками. 

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

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