Материал подготовлен с AI-помощью. Пример ниже выполнен локально в Node.js на синтетическом тексте. Он проверяет поведение объектов File; диалог браузера, загрузка по сети и обработка изображения в этом запуске не проверялись.

Что делает диалог выбора

Атрибут accept="image/png,.png" у input type="file" задаёт подсказку о нужных типах. MDN прямо отделяет её от проверки содержимого: во многих диалогах пользователь может переключить фильтр и выбрать другой файл. Поэтому наличие accept в разметке не подтверждает выполнение требований к загрузке. Источник: https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/Attributes/accept

Такая подсказка всё равно полезна: человеку проще найти подходящий файл. Рядом стоит назвать допустимые форматы и ограничения размера, которые действительно применяет продукт. Текст «Выберите PNG» описывает ожидаемое действие. Сообщение «Файл проверен» уже требует отдельного основания, а не только подходящего расширения в имени.

Имя и MIME описывают разные свойства

У File есть имя и свойство type, унаследованное от Blob. По документации MDN, тип может остаться пустой строкой; браузерное определение может зависеть от расширения и конфигурации клиента. MDN не рекомендует использовать это свойство как единственный способ валидации. Источник: https://developer.mozilla.org/en-US/docs/Web/API/Blob/type

В конструкторе File значение type можно передать явно. Для наглядной проверки достаточно обычной строки, без настоящей картинки и без обращения к серверу. Конструктор принимает содержимое, имя и параметры как разные аргументы. Описание API: https://developer.mozilla.org/en-US/docs/Web/API/File/File

const file = new File(['учебный текст'], 'cover.png', {
  type: 'image/png'
});
console.log(file.name);         // cover.png
console.log(file.type);         // image/png
console.log(await file.text()); // учебный текст

Локальный запуск вывел cover.png, image/png и исходный учебный текст. Дополнительная проверка создала из той же строки объект note.txt с типом text/plain. Их байтовое содержимое совпало. Третий объект, созданный без параметра type, вернул пустую строку типа и сохранил тот же текст. Восемь утверждений завершились успешно.

Из этого следует узкий вывод: в проверенном конструкторе метаданные не доказывают соответствие содержимого выбранному формату. Этот пример не оценивает качество PNG-декодера и не показывает обход конкретного сервиса. Он помогает увидеть, почему проверке file.type === "image/png" нельзя приписывать работу, которую она не выполняла.

Разделить ответственность в задании

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

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

В приёмочный сценарий полезно включить подходящий файл, неподходящее содержимое под знакомым именем, пустой MIME и превышение установленного размера. Результат каждого случая должен объяснять, какая сторона принимает решение и что видит человек. Синтетические объекты удобны для части таких проверок; работу реального выбора и серверной обработки нужно проверять своими сценариями.

Так в задании для разработчика или AI-ассистента появляются три проверяемых результата: подсказка при выборе, ранняя обратная связь клиента и самостоятельное решение сервера. Это помогает обсуждать конкретное поведение загрузки вместо общей отметки «валидация добавлена».

Олжас Азирали, разработчик приложений из Астаны, основатель AZIRAL с 2019 года.

Материал подготовлен с помощью AI-ассистента по открытым материалам MDN и W3C. Портрет и обложка также созданы с помощью ИИ. Все экраны и надписи ниже являются учебными предложениями.

Представим вымышленный веб-редактор заметок с локальным хранением, синхронизацией и экспортом. Человек дописал список дел и увидел «Сохранено». Затем открыл редактор на другом устройстве или решил получить отдельный файл. Одной короткой надписи недостаточно, чтобы объяснить все три результата.

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

1. Где доступна локальная запись?

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

В веб-приложении один из возможных механизмов описан в MDN о localStorage: данные относятся к определённому источнику страницы и сохраняются между сессиями браузера. Для приватного режима MDN указывает очистку после закрытия последней приватной вкладки. Это свойства конкретного хранилища; они сами по себе не сообщают о доставке записи на другой телефон или в общий сервис.

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

2. Какую версию подтвердил общий сервис?

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

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

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

3. Что произошло с отдельным файлом?

Экспорт добавляет третье событие. Человек может получить файл только с выбранной заметкой или с определённой частью её содержимого. Назначение экспорта лучше указать рядом с действием: какой формат и какие сведения будут подготовлены.

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

Если редактор знает только о подготовке данных и передаче запроса браузеру, сообщение должно описывать именно этот этап. Например: «Файл подготовлен. Запрос на скачивание передан браузеру». Утверждение о файле в конкретной папке уместно при наличии соответствующего подтверждения. Содержимое файла также стоит связать с моментом экспорта, чтобы последующие правки заметки не воспринимались как автоматическое обновление уже полученной копии.

4. Проверить обещание одним сценарием

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

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

Слово «Сохранено» становится точнее, когда у команды есть ясное описание подтверждённого результата. Так короткая надпись помогает человеку решить, можно ли закрыть экран, перейти на другое устройство или завершить получение файла.

Материалы MDN и W3C проверены 30 октября 2026 года.

Олжас Азирали / Olzhas Azirali, основатель AZIRAL с 2019 года и разработчик приложений.

Материал подготовлен с помощью AI-ассистента по опубликованным описаниям Finance Bro и документации поддержки.

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

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

Разделить прочитанное и предложенное

В качестве конкретного примера можно взять Finance Bro в App Store. Описание приложения предлагает проверять суммы, даты, направление операций и категории перед сохранением поддерживаемой выписки.

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

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

Показать последствие на коротком примере

Рассмотрим условную запись: 5 000 тенге, магазин, 30 октября. Это учебный пример, а не данные пользователя или результат измерения качества Finance Bro.

• Прочитано: сумма и дата из выбранной строки.
• Предложено: направление «расход» и подходящая категория.
• Требует решения: счёт, к которому относится операция.

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

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

Дать сомнению видимое место

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

Поддержка Finance Bro объясняет, что категории предлагаются по локальным словам в названии продавца; незнакомое название может остаться без категории. Это конкретный пример ограниченного правила, назначение которого можно объяснить пользователю.

Для разработчика отсюда следует полезный вопрос: умеет ли интерфейс сообщить «здесь нужно ваше решение»? Поле может оставаться незаполненным, строка может требовать проверки, а подсказка - объяснять причину. Важно, чтобы такое состояние отличалось от ошибки чтения файла и от уже подтверждённой операции.

Считать повтор вопросом к данным

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

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

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

Не смешивать запись и оплату

Автоматическое заполнение учёта и исполнение банковской операции - разные действия. По текущему описанию, Finance Bro не проводит банковские платежи. Созданная запись отражает информацию в приложении; она не означает новое списание денег банком.

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

Проверять понятность завершения

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

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

Другие продукты и материалы: Олжас Азирали / AZIRAL. Finance Bro развивается на открытой Flutter-основе; происхождение приложения раскрыто в продуктовой заметке.

Описания проверены 30 октября 2026 года. В App Store показана версия 1.0.9. Поддерживаемые форматы и доступность функций нужно сопоставлять с установленной версией приложения.