Hacker News Digest

Bluesky скрывает свой логотип в интерфейсе приложения, но оставляет его видимым на скриншотах. При обычном использовании логотип заменяется кнопкой «Follow», однако при делении скриншота он появляется в правом верхнем углу. Это происходит из-за специального компонента GrowthHack.tsx, который использует UITextField с включённым скрытием пароля (isSecureTextEntry). При скриншоте iOS автоматически блочит отображение этого UITextField, позволяя просвечивать логотипу, который на самом деле отрисован в его слое. Такой трюк, известный в приложениях вроде Telegram и Signal, позволяет обойти стандартные механизмы блокировки скриншотов. Логотип остаётся видимым только на скриншотах, а в реальном интерфейсе его заменяет другая кнопка.

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

• Спор: Некоторые считают, что это полезный способ атрибуции контента, так как Bluesky визуально похож на X, и логотип помогает определить источник; другие возражают, что любое изменение снимка экрана — это нарушение принципа, что пользователь должен видеть и сохранять то, что отображается на экране.

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

• Совет: Пользователь @rmwaite делится практическим способом обхода: если удерживать палец при свайпе вниз и обратно в центр управления, скриншот не содержит логотипа — это работает и для Twitter, что указывает на существование обходных путей в iOS.

• Совет: Пользователь @zzo38computer предлагает сделать функцию управления скриншотами настройкой в системе — с возможностью включения/отключения и указанием, какие приложения её используют, чтобы предотвратить злоупотребления и дать пользователю контроль.

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

• Пользователи отмечают, что X и Threads используют аналогичные методы, что подтверждает, что это не уникальная практика Bluesky, а отраслевой тренд, поддерживаемый платформой и направленный на маркетинг через скриншоты.

• Совет: Пользователь @vachina рекомендует использовать веб-версию приложений вместо нативных, чтобы избежать таких манипуляций, так как браузер не поддерживает подобные хаки и сохраняет чистый снимок экрана.

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

• Совет: Пользователь @Jaxkr предполагает, что этот трюк был изобретён Никитой Бьером при работе в X, что указывает на передачу метода между платформами и его системное внедрение в экосистеме соцсетей.

• Несколько пользователей отмечают, что подобные техники уже используются в вебе — например, Perplexity добавляет логотип при использовании сочетаний клавиш для скриншотов — что показывает, что это не только нативное поведение, но и распространённая практика.

• Спор: Один пользователь считает, что если приложение может показывать одно на экране и другое на скриншоте, это открывает путь к опасным сценариям — например, подмена QR-кодов или встраивание невидимых меток, что делает эту функцию потенциально опасной.

• Совет: Пользователь @user00005 ссылается на проблему в Graphene OS, призывая поддержать её, чтобы добиться блокировки таких функций на уровне ОС — это указывает на существование альтернативных платформ, стремящихся защитить пользовательский контроль.

• Пользователи отмечают, что подобные практики напоминают вирусный маркетинг iPhone — 'Sent from my iPhone' — и что это не новая тактика, а эволюция старого подхода: использовать каждый снимок как рекламу.

• Спор: Один пользователь выражает опасение, что если такие методы применяются к юридическим доказательствам — например, в суде — то невидимые метки в скриншотах могут использоваться для отслеживания источников, что ставит под угрозу конфиденциальность.

• Совет: Пользователь @thn-gap подтверждает, что использование веб-версии Bluesky и Twitter — это сознательный выбор, чтобы избежать таких манипуляций, и что это подтверждает, что веб-интерфейс остаётся более прозрачным и предсказуемым.

Цель «каждый кадр — идеальный» из Wayland стал принципом UI: любой скриншот программы должен полностью отражать её текущее состояние, а не показывать артефакты загрузки, мигания или несоответствия. Это создаёт доверие — пользователь, не видя код, оценивает качество по визуальному поведению, а плавные, согласованные анимации сигнализируют о тщательной проработке. Эта идея вытекает из принципа, что пользователь не видит код, поэтому визуальная целостность — единственный индикатор надёжности. Если в любой момент скриншот выглядит «правильно», значит разработчики уделили время не только функционалу, но и деталям.

На практике это требует отсутствия белых вспышек, частично загруженного контента и рассинхрона элементов интерфейса. Пример: в Safari курсор появляется слева, а placeholder движется от центра, поэтому в промежуточных кадрах они расходятся, создавая ложное ощущение изменения. Аналогичные рассинхроны встречаются в Photos, YouTube и других сервисах, где технические ограничения делают «идеальными» только конечные кадры. Следовательно, проверять нужно не только старт и конец, но и каждый промежуточный кадр, чтобы UI стал точным инструментом, а не анимационной игрушкой. В Photos граница обрезки «запирается» мгновенно, но её анимация продолжается, вводя в заблуждение.

• Критика «идеального кадра» в анимации UI и её влияние на восприятие пользователя
• Утверждение, что низкая задержка важнее визуального совершенства, а анимация часто ухудшает отзывчивость
• Примеры регрессий в macOS (Safari, Notes, диалог «Сохранить как») и сравнение с более плавными альтернативами
• Призыв к предоставлению конкретных улучшений и лучших практик вместо только указания на проблемы

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

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

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

• Пользователи обсуждают, что профили Firefox существуют уже много лет, но новый UI не решает проблему с их использованием и не показывает старые профили.
• Создание нового профиля через новый интерфейс не создаёт отдельную папку профиля, что вызывает вопросы о том, как перенести данные.
• Некоторые пользователи отмечают, что новый интерфейс не позволяет выбрать, какой профиль использовать при открытии ссылки из внешнего приложения.
• Обсуждается, что контейнеры и профили разные вещи, но новый UI не делает это ясным.
• Несколько комментаторов выражают разочарование в том, что Mozilla не делает ясным, что именно нового вносит новый UI, и что именно он улучшается.

Ghostty получил обновление, которое добавило незаметные уведомления об обновлениях в macOS. Чтобы не повторить сценарий OpenAI, где демо-версия прервала презентацию, автор решил сделать уведомления незаметными. Он использовал Sparkle и встроил кастомный UI в заголовок окна. Процесс включал в себя AI-агентов, которые генерировали код, а затем он сам его дорабатывал. Итоговая стоимость токенов и время разработки оказались вполне приемлимыми.

• Обсуждение в основном вращается вокруг того, как разработчики используют AI-агентов: кто-то считает их незаменимыми для прототипирования и устранения рутины, другие подчеркивают важность человеческого аудита и контроля качества.
• Участники поделились личными практиками: кто-то использует агента как «музу» для преодоления «белого листа», кто-то отмечает, что агенты особенно полезны для UI-фреймворков, а кто-то подчеркивает, что важно сохранять критическое мышление и не полагаться на агента как на «черную коробку».
• Обсуждались также риски и этика: участники отмечали, что важно не допускать, чтобы агенты порождали «slop», и что важно сохранять человеческий контроль над качеством кода.
• Наконец, обсуждались и инструменты вроде Ghostty, и участники отмечали, что нехватка таких базовых функций, как поиск, может отпугнуть пользователей, и что важно различать «vibe coding» от ответственного использования AI.

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

В архиве представлено 362 сайта с фильтрацией по тегам — от 3D-анимации и типографики до звукового дизайна и глитчей. Примеры вроде rude-captcha.xyz или slingshot.trudy.computer демонстрируют, как можно творчески использовать возможности телефона. Цель проекта — стимулировать сообщество к обсуждению и эксперименту в mobile-first дизайне.

• Пользователи обсуждают нестандартный веб-дизайн представленных сайтов, отмечая как их креативность и ностальгическую ценность, так и проблемы с юзабилити и доступностью.
• Критике подвергаются отдельные элементы, такие как изменение поведения ссылок при наведении и невозможность добраться до нижней части страницы из-за бесконечной подгрузки контента.
• Участники делятся воспоминаниями о легендарных сайтах прошлого (Kaliber 10000) и обмениваются ссылками на аналогичные ресурсы и агрегаторы необычных сайтов.
• Высказываются опасения, что подобный дизайн часто непрактичен для представления реального контента и создания призывов к действию, а также создает барьеры для доступности.
• Часть сообщества ценит представленные работы за их художественную ценность и вдохновляющий потенциал, призывая не зацикливаться на мелких недостатках.

При обращении к данным пользователя в интерфейсах часто возникает вопрос: использовать «мой» или «ваш»? Например: «Мой аккаунт» или «Ваш аккаунт»? Но часто префикс не нужен вовсе — достаточно просто «Аккаунт», «Заказы», «Дела», как это делает Amazon.

Однако если в продукте есть элементы, принадлежащие и пользователю, и другим (например, система дел, где есть «мои дела» и «все дела»), возникает сложность. Использование «мои дела» в меню навигации кажется уместным, но вне меню — в onboarding, email-уведомлениях или справке — фраза «перейдите в мои дела» звучит неестественно. Если я скажу вам «перейдите в мои дела», вы подумаете о своих, а не о моих. Поддержка может рекомендовать «перейдите в ваши дела», что конфликтует с интерфейсом, где написано «мои дела».

С «ваш» таких проблем не возникает — этот подход проверен на множестве продуктов и не вызывает затруднений у пользователей.

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

Итог:

• Используйте «ваш», когда обращаетесь к пользователю.
• Используйте «мой», когда пользователь обращается к системе.

• Рекомендуется использовать местоимение «your» (ваш/ваша/ваше) в интерфейсах, когда система обращается к пользователю, и «my» (мой/моя/моё), когда пользователь дает команду системе.
• Многие участники выступают против использования местоимений вообще, считая их избыточными и предлагая убирать притяжательные формы для упрощения (например, «Pictures» вместо «My Pictures»).
• Критикуется использование местоимения «we» (мы) системой, так как это создает ощущение патернализма и ложной вовлеченности пользователя в процесс («Let's add your account»).
• Подчеркивается важность контекста и согласованности в формулировках, особенно при локализации, поскольку в разных языках существуют разные нормы вежливости и формальности.
• Отмечается, что неправильное использование местоимений может приводить к путанице, особенно если продукт или функция уже содержит слово «My» в названии (например, «Your My Card»).
• Некоторые участники предпочитают, чтобы интерфейсы и системы общались более формально и машинообразно, без попыток казаться «дружелюбными» или человечными.
• Указывается на проблемы перевода и локализации, когда недостаток контекста для строк интерфейса приводит к ошибкам и неоднозначностям.
• Обсуждается, что лучшей практикой является обработка элементов интерфейса как собственных имен (использование кавычек, выделение) в инструкциях и поддержке, чтобы избежать путаницы с местоимениями.