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). - Немає емодзі-картинок; текстові посмішки використовуються рідко і доречно.
- Юридичні тексти та машинно-читані артефакти не торкнуті.