FastMediaSorter - Политика общения в интерфейсе
Канонический источник: COMMUNICATION_POLICY.md. Этот файл - зеркало на русском.
Происхождение: S0118 (friendly-ui-copy-revision). Обновлять при добавлении новых формул или каналов обратной связи.
Область: Все видимые пользователю строки во всех флейворах (standard, lite, photos, legacy), EN/RU/UK. Исключения: юридические тексты, Условия использования, машинно-читаемые технические артефакты (манифесты, метаданные).
1. Голос интерфейса
- Тон: дружелюбный, понятный, краткий. Лёгкая ирония допустима только как самоирония приложения или мягкий юмор над ситуацией - не над человеком.
- Никакой бюрократии: избегать «операция выполнена успешно», «уведомляем вас о том, что», «произошла ошибка».
- Никакого жаргона без расшифровки.
- Никаких эмодзи-картинок; редкие текстовые улыбки «))» или «:-)» допустимы только там, где они действительно уместны и не мешают пониманию.
- В спорных случаях - приоритет у ясности, а не у остроумия.
- Если от пользователя требуется действие - сказать прямо в тексте.
2. Формулы по типам сообщений
2.1 Краткое всплывающее уведомление (Toast)
- Одна короткая мысль, которую читают за один взгляд.
- Никаких следующих шагов, никакого дополнительного контекста.
- Примеры:
- ✓ «Сохранено.»
- ✓ «Соединение потеряно.»
- ✗ «Операция по сохранению данных была успешно завершена.»
2.2 Ошибка (встроенная или Snackbar)
- Человеческое объяснение того, что случилось + один понятный следующий шаг, если он есть.
- Не выносить «сырой» текст исключения как основное сообщение.
- Технические детали (стек, коды ошибок) - только во вторичный раздел «Подробности», не в заголовок.
- Примеры:
- ✓ «Не удалось подключиться - проверьте адрес сервера и попробуйте снова.»
- ✗ «java.net.SocketTimeoutException: timeout»
2.3 Диалог ошибки (развёрнутый)
- Может быть длиннее, если это помогает понять, что случилось, и что попробовать.
- Структура: [Что случилось] → [Что попробовать] → [необязательно: один следующий шаг].
- Голая констатация ошибки без полезного выхода недопустима.
2.4 Пустое состояние
- Объяснить, почему нет контента + естественное приглашение к действию.
- Пустое состояние не должно быть тупиком.
- Примеры:
- ✓ «Здесь пока ничего нет. Добавьте папку или сетевой ресурс, чтобы начать.»
- ✗ «Ничего не найдено.»
2.5 Процесс и загрузка
- Короткий спокойный статус. Избегать бюрократического «Выполняется..», если есть более конкретная формулировка.
- Примеры:
- ✓ «Загружаем файлы..»
- ✓ «Сканируем..»
- ✗ «Пожалуйста, подождите, пока операция будет выполнена.»
2.6 Подтверждение успеха
- Краткое подтверждение результата без тяжёлой официальности.
- Примеры:
- ✓ «Готово.» / «Перемещено.» / «Удалено.»
- ✗ «Операция была успешно выполнена.»
2.7 Диалог подтверждения опасного действия
- Прямо и вежливо, без шуток там, где есть риск потери данных.
- Написать, что произойдёт, а не просто «Вы уверены?».
- Примеры:
- ✓ «Все сохранённые подключения будут удалены. Их можно будет добавить снова.»
- ✗ «Вы уверены, что хотите удалить?»
2.8 Сетевая / ресурсная / доступовая ошибка
- Дружелюбное объяснение + корректирующий шаг, который пользователь реально может сделать.
- Примеры:
- ✓ «Сервер не отвечает - проверьте соединение или попробуйте позже.»
- ✗ «SMB STATUS_BAD_NETWORK_NAME»
3. Полезный следующий шаг (правило тупика)
Показывать не более одного контекстного следующего шага в тупиковых или проблемных сценариях. Никогда - в коротких уведомлениях. Никогда - как обязательное действие, блокирующее основной сценарий.
| Ситуация | Предпочтительный канал |
|---|---|
| Ошибка настройки / доступа, которую пользователь может исправить | Документация (сайт приложения) |
| Повторяющийся сбой или подозрение на дефект приложения | Сообщение о проблеме: sza@ukr.net |
| UX-тупик, экран справки или информация о приложении | Предложение улучшения / отзыв: Google Play |
Правила:
- Выбрать один наиболее уместный канал - не показывать все три одновременно.
- CTA следующего шага вторичен по отношению к основному сообщению и не заменяет корректирующий совет.
- Не показывать подсказки с обратной связью после каждого успешного действия - только в реальных тупиках и проблемных состояниях.
4. Каналы обратной связи
| Канал | Назначение |
|---|---|
| Сайт приложения / документация | Инструкции, руководства по настройке |
sza@ukr.net |
Сообщения об ошибках, воспроизводимые проблемы |
| Рецензии Google Play | Предложения по улучшению, общий пользовательский отзыв |
5. Правила локализации
- Каждая новая или обновлённая пользовательская строка должна быть в EN, RU и UK в одном коммите.
- Проверять паритет через
scripts/check_strings_localized.ps1- код выхода 1 является блокером. - EN - исходная локаль; RU и UK должны совпадать по структуре и смыслу, адаптированно (не дословный перевод).
..(две точки) как многоточие во всех локалях; никогда…(Unicode) или....
6. Чек-лист тона (перед интеграцией)
Перед тем как любой пакет новых или обновлённых строк попадёт в кодовую базу:
- Нет «сырого» текста исключений или кодов ошибок в основном пользовательском сообщении.
- Нет «Вы уверены?» без объяснения, что произойдёт.
- Нет формулировок «операция успешно выполнена».
- У каждого сообщения об ошибке есть следующий шаг или хотя бы человеческое объяснение.
- У каждого пустого состояния есть приглашение к действию.
- Строки помещаются на смартфоне без обрезки (проверить на ширине 360 dp).
- Паритет EN/RU/UK подтверждён (
check_strings_localized.ps1код выхода 0). - Нет эмодзи-картинок; текстовые улыбки используются редко и по делу.
- Юридические тексты и машинно-читаемые артефакты не затронуты.