NovЗакрытый проект не должен выглядеть доступным ещё неделю
Как технический статус проекта должен быстро попадать в каталог, сравнение, поиск и связанные блоки после изменения.
Материал отражает практическую позицию указанного эксперта. Как готовятся и проверяются публикации — в редакционной политике NovAsia.
Представим, что продажи проекта остановлены. На основной странице статус уже исправили, а карточка в каталоге продолжает показывать «доступен».
Для пользователя это не мелкий визуальный сбой. Он начинает путь с устаревшего обещания, тратит время на объект, который уже нельзя купить на заявленных условиях, и только позже узнаёт, что интерфейс отстал от реальности.
Если объект меняет статус, это должно отражаться во всём каталоге проектов, а не только на одной карточке, которую успели поправить вручную.
Статус — это состояние системы, а не подпись на странице
Проблема становится заметнее, когда у проекта больше двух состояний. «Доступен» и «закрыт» редко описывают весь жизненный цикл. Могут быть продажи по запросу, временная пауза, завершённые продажи, архивное состояние или ситуация, когда актуальность ещё не подтверждена.
Если эти варианты сведены к одному логическому переключателю, интерфейс начинает додумывать смысл. Например, отсутствие свежего статуса может превратиться в «доступен» просто потому, что так было задано по умолчанию. Для каталога это опасное поведение: неизвестность лучше показывать как неизвестность, а не как удобное положительное значение.
Мне нужна модель, в которой статус задаётся явно, а каждое состояние имеет понятное поведение: где объект показывается, какие действия доступны, что видит человек в сравнении и как обозначается возраст информации.
Обновление должно знать, какие места от него зависят
Такие ошибки обычно появляются не в момент редактирования статуса, а на стыке систем. Основная страница уже читает новое значение, а каталог держит старую копию. Поиск обновился, но блок похожих проектов ещё живёт в кэше. Одна языковая версия получила изменение, другая осталась на прежнем состоянии.
Поэтому для меня важна карта зависимостей: какие страницы, карточки и инструменты должны отреагировать на изменение одного поля. Если цепочка построена автоматически, её всё равно нужно проверять. Если часть системы обновляется по расписанию, пользователь не должен получать видимость мгновенной актуальности там, где её технически нет.
Хороший технический сценарий включает и неудачное обновление. Если внешний источник перестал отвечать, безопаснее сохранить последнее подтверждённое значение с понятной датой, чем молча подставить статус по умолчанию.
Устаревшее состояние тоже нужно уметь показывать
Не каждое изменение означает удаление страницы. Иногда проект должен остаться доступным как справочная информация: человек мог сохранить ссылку, сравнивать старые цены или искать сведения о уже построенном объекте.
В таком случае страница может продолжать существовать, но должна честно показывать своё состояние: продажи закрыты, данные архивные, последняя проверка была тогда-то. Это полезнее, чем либо притворяться, что предложение живо, либо полностью стирать страницу вместе с накопленным контекстом.
Техническая задача — не решить за редакцию, что писать. Она должна обеспечить, чтобы выбранный статус последовательно отображался везде, где пользователь может встретить проект.
Хорошая система умеет не только публиковать новое, но и корректно старить старое.