FastAPI Voyager - это интерактивный инструмент визуализации для API, созданный на базе FastAPI. Позволяет наглядно представлять структуру API с возможностью масштабирования через прокрутку и детального изучения узлов двойным кликом. Особенность инструмента - режим просмотра зависимостей схемы (активируется через Shift+клик), который фильтрует несвязанные узлы, упрощая анализ сложных систем.

Проект поддерживает импорт данных JSON из ядра системы, что обеспечивает гибкость интеграции. Инструмент ориентирован на разработчиков, работающих с FastAPI, и помогает лучше понимать архитектуру API, выявлять связи между компонентами и оптимизировать структуру. Код проекта доступен на GitHub, что позволяет сообществу вносить вклад в развитие и адаптацию инструмента под конкретные нужды.

• Пользователи жалуются на неудобство визуализации сложных связей между эндпоинтами и моделями ответов в fastapi-voyager; требуется более интерактивный и «чистый» способ исследовать схему.
• Предложение: добавить взаимодействие при наведении курсора на узел, чтобы подсвечивать связанные с ним линии и скрывать остальные, а также дать возможность «проваливаться» внутрь подграфа.
• Пользователи просят улучшить UX: убрать «клубок» линий, дать возможность масштабировать и фильтровать отображаемое, а также предоставить обзорный режим, в котором детали раскрываются по мере необходимости.
• Проект вдохновлен GraphQL-voyager, но не реализует его фичи вроде подсветки связей при наведении мыши; автор отвечает, что проект на ранней стадии и приветствует PR-ы.

• Пользователи недовольны встроенными веб-вью (webview), так как они теряют контекст при переключении между приложениями и не позволяют вернуться к исходному месту.
• Мобильная платформа работает некорректно для неавторизованных пользователей, показывая бесполезные ошибки без указания на необходимость входа.
• Критикуются общее ухудшение пользовательского опыта, спамные практики и навязчивые методы увеличения вовлеченности (например, агрессивные клики по рекламе).
• Упомянуты спорные решения, такие как блокировка аккаунтов (например, PG) и изменение политики NSFW-контента в сервисах вроде Grok.
• Появились вопросы о предзагрузке ссылок в фоновом режиме, что может искусственно увеличивать трафик и представлять риски безопасности.

Автор выражает разочарование навязчивыми AI-функциями, которые портят продукты вместо улучшения. Изначально он был заинтересован в технологиях, даже считал Rabbit R1 перспективным, но со временем понял, что AI не только захватывает смартфоны, но и проникает во всю потребительскую электронику, превращая полезные устройства в набор бесполезных трюков.

Примеры неудачной интеграции AI повсюду: Google заменил работающий Assistant на медленный и ненадежный Gemini, Siri с "Apple Intelligence" стал еще хуже, а Copilot Microsoftа навязчиво появляется в Windows и даже на экране блокировки. Даже браузер Arc, чей преемник Dia полностью сосредоточился на AI, потерял свою уникальность. Автор вернулся к старому Google Assistant, потому что он хотя бы работал, когда был нужен.

• Пользователи жалуются на вездесущий AI, который не только не решает задачи, но и мешает нормально пользоваться продуктом, вызывая раздражение и вредя UX.
• Критика направлена не столько на саму технологию, сколько на то, как корпорации навязывают её ради отчетов перед инвесторами, в ущерб пользователям.
• Сторонники свободного и открытого ПО и самостоятельного контроля над устройством подчеркивают, что большинство жалоб можно было бы избежать, если бы не было корпоративной политики.
• Сообщество также обсуждает, что вместо того, чтобы улучшать продукты, компании вводят AI в качестве маркетингового хайпа, что приводит к ухудшению UX и вызывает раздражение.

Статья представляет собой воображаемый список курсов компьютерных наук, которых не существует, но должны. Автор предлагает такие курсы, как "Отказ от объектно-ориентированного программирования", где студенты изучат переменные вне иерархии объектов и "функции", а также "Классические исследования программного обеспечения", посвященные исторически значимым продуктам вроде VisiCalc и Zork. Особый интерес представляет курс "Написание быстрого кода на медленных языках", где учат писать на Python, который по производительности может превзойти C++, и "Пользовательский опыт командной строки", анализирующий принципы UX для консольных программ.

Автор Джеймс Хейг, бывший программист, проектирующий видеоигры с 1980-х, подчеркивает, что программирование — это не технология ради самой технологии, а возможность реализации идей. Он также предлагает курс "Одобрения программистского ума", изучающий навязчивые темы, которыми часто увлекаются разработчики: форматирование кода, таксономия, системы типов и чрезмерное дробление проектов.

• Обсуждение показало, что академическая программа CS часто не охватывает такие темы, как история ПО, философия вычислений, практика командной работы и даже базовые навыки работы в консоли.
• Участники подчеркнули, что курсы вроде "Unlearning OOP" и "Classical Software Studies" должны быть обязательной частью образования, но их нет.
• Обсуждение подняло вопрос о том, что не хватает курсов по фундаментальным навыкам, таким как CI/CD, системное администрирование и работа с консолью.
• Было отмечено, что студенты часто не получают практических навыков, необходимых для работы в отрасли, и что курсы по таким темам как "как писать быстрый код на медленных языках" или "как не страдать от внутренних конфликтов в команде" отсутствуют.
• В конце концов, обсуждение подтолкнуло к тому, что вместо того, чтобы учить студентов тому, как создавать и поддерживать сложные системы, которые уже работают, они вместо этого вынуждены изучать фреймворки, которые могут исчезнуть через 5 лет.

OpenAI представила Apps SDK — фреймворк для разработки приложений, интегрируемых напрямую в ChatGPT. Он позволяет создавать инструменты на основе MCP-серверов, настраивать пользовательский интерфейс, управлять аутентификацией и хранить данные. Сейчас доступен в режиме предпросмотра для тестирования, а публичная отправка приложений откроется позже в этом году.

Разработчикам предлагаются чёткие руководства по дизайну, безопасности и метаданным, чтобы приложения соответствовали стандартам качества и органично вписывались в экосистему ChatGPT. Процесс включает планирование use-cases, развёртывание серверов и подключение к ChatGPT, с примерами и troubleshooting для упрощения разработки.

• OpenAI представляет платформу "Apps" на базе MCP, позволяющую интегрировать сторонние сервисы (например, бронирование отелей, поиск недвижимости) прямо в чат-интерфейс ChatGPT.
• Мнения разделились: одни видят в этом стратегический шаг к созданию экосистемы и монетизации (доля от транзакций, скрытая реклама), другие критикуют за слабую UX, бритвость и повторение прошлых неудач (как Custom GPTs).
• Поднимаются вопросы для разработчиков: монетизация, риск заблокирования будущими обновлениями ChatGPT и усиление зависимости от OpenAI.
• Техническая реализация вызывает вопросы: работа примеров кода, механизм внедрения интерактивных элементов (iframe?) и ограничения MCP.
• Обсуждается фундаментальный конфликт: должен ли чат быть универсальным интерфейсом или AI-функции лучше встраивать в традиционные приложения.

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

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

• Современные смартфоны, особенно iPhone, критикуются за излишнюю сложность интерфейса, непонятные жесты и запутанный процесс первоначальной настройки, что создает серьезные барьеры для пожилых пользователей.
• Многие пользователи предлагают создание упрощенных режимов (вроде Assistive Access) и возможность кастомизации интерфейса с самого начала настройки устройства, оставляя только самые необходимые функции (звонки, сообщения).
• Отмечается, что проблема не только в Apple, но и в общей тенденции усложнения UX across all platforms (Android, Windows), а также в плохо спроектированных приложениях (банки, госуслуги), которые часто требуются для повседневной жизни.
• Подчеркивается важность терпения и индивидуального подхода при обучении, фокусируясь только на тех задачах, которые действительно нужны пользователю, а не на демонстрации всех возможностей устройства.
• Обсуждается, что пожилые пользователи — не монолитная группа; некоторым удается успешно освоить устройства, в то время как для других даже упрощенные смартфоны остаются слишком сложными, и иногда более подходящим решением может быть простой кнопочный телефон.

Kagi News предлагает новый подход к потреблению новостей, основанный на принципе «сигнал вместо шума». Сервис агрегирует тысячи RSS-лент из разнообразных мировых источников, курируемых сообществом, и создаёт единый ежедневный дайджест около полудня по UTC. Это позволяет получать полное представление о событиях за пять минут без бесконечного скроллинга и трекинга внимания.

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

• Обсуждение нового сервиса Kagi News, который агрегирует и суммирует новости с помощью ИИ, с акцентом на ежедневное обновление для борьбы с бесконечным скроллингом.
• Выражены опасения по поводу использования ИИ для генерации новостей: потеря контекста, отсутствие авторской ответственности и возможные галлюцинации моделей.
• Подняты вопросы о компенсации авторам оригинальных статей и этичности агрегации контента без прямого вознаграждения первоисточникам.
• Критика функциональности и UX продукта: навигация, синхронизация между устройствами, отсутствие темы для OLED-экранов и предпочтение человеческой курации.
• Общая поддержка миссии Kagi по улучшению потребления информации, но скептицизм относительно перерасширения компании и качества новостной ленты.

• Обсуждаются новые функции Claude Code: расширение для VS Code, команда /rewind для отмены изменений, переработанный интерфейс и управление контекстом.
• Пользователи сравнивают Claude Code с конкурентами (Cursor, Aider, Goose), отмечая его преимущества и недостатки, такие как интеграция с инструментами и эргономика.
• Поднимаются вопросы о конфиденциальности данных, потреблении ресурсов (ОЗУ) и проблемах с UX/UI в новом расширении VS Code.
• Обсуждаются технические аспекты: работа с CJK-вводом, управление памятью, поддержка MCP, а также использование тегов и магических команд в промптах.
• Высказываются предложения по улучшению: индикация функции в diff, отображение оставшегося контекста, отмена выполнения промпта и улучшение команды /resume.

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

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

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

Дизайн-лидер Джейсон Шпильман возглавлял создание NotebookLM — инструмента, который решает проблему «перегруженности вкладками» и разрозненности рабочих процессов. Продукт объединяет чтение, письмо и создание контента в едином пространстве, используя ИИ для снижения трения между этапами работы.

Ключевым решением стала адаптивная трёхпанельная структура: источники, чат и заметки. Она масштабируется под нужды пользователя — например, можно сосредоточиться на чтении с чатом, на письме или на комбинации этих режимов. Система сохраняет быстрый доступ к ключевым элементам даже при минимальных размерах панелей. Ментальная модель строится вокруг последовательности: входные данные → обсуждение → результаты, что делает сложные ИИ-взаимодействия интуитивно понятными.

• Пользователи критикуют сложный и перегруженный интерфейс NotebookLM, который затрудняет навигацию и использование базовых функций, таких как чат с загруженными файлами.
• Отмечаются проблемы с UX: неинтуитивное управление, отсутствие сохранения истории чатов, сложности с редактированием текста и экспортом данных.
• Подчеркивается, что успех продукта обусловлен мощными backend-возможностями (работа с большим контекстом, аудиогенерация), а не дизайном.
• Пользователи находят ценными конкретные функции: создание подкастов, карточек, викторин и ментальных карт, а также анализ сложных документов (научные статьи, правила игр, техническая документация).
• Высказываются пожелания по улучшению: упрощение интерфейса, возможность оплаты для конфиденциальности данных, лучшая интеграция с другими сервисами.

У вас не было вкуса до появления ИИ

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

Что такое вкус?

В контексте ИИ под вкусом обычно понимают:

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

Эти навыки не новы — ими всегда должно было руководствоваться качественной работе. Вопрос в том, почему о вкусе заговорили только сейчас.

Безвкусица

Многие, кто жалуется на безвкусный контент от ИИ, сами грешили тем же:

• Копировали код без понимания.
• Рассылали непроверенные резюме и письма.
• Создавали шаблонные дизайны сайтов.
• Пересказывали тренды без осмысления.

Проблема не в ИИ, а в людях, которые не развивали критическое мышление. Как в «Рататуе»: готовить может каждый, но шеф-повар — не все.

Спектр вкуса

Вкус может быть глубинным (экспертиза в одной области) или широким (понимание множества доменов). С ИИ чаще полезен широкий вкус — он позволяет быстро переключаться между контекстами, поддерживать качество и знать, когда обратиться к эксперту.

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

• Обсуждение вращается вокруг субъективности понятия «вкус» и его связи с использованием ИИ, где одни видят в нём инструмент для усиления креативности, а другие — угрозу оригинальности и качеству.
• Многие участники отмечают, что ИИ не создаёт ничего принципиально нового, а лишь ускоряет производство контента, что может усугублять отсутствие вкуса, а не исправлять его.
• Поднимается вопрос о парадоксе прибыли: стремление к финансовой выгоде часто воспринимается как безвкусное, хотя именно оно движет профессиональной деятельностью.
• Критикуется некритичное принятие результатов работы ИИ как идеальных, что приводит к снижению стандартов качества и отсутствию глубокого понимания у пользователей.
• Высказывается опасение, что широкое использование ИИ может привести к homogenization вкуса и утрате культурного разнообразия, так как инструмент формирует предпочтения следующего поколения.
• Отмечается, что настоящая проблема может заключаться не в ИИ, а в изначальной склонности общества к конформизму и воспроизводству банальностей, которые ИИ лишь усиливает.
• Часть дискуссии посвящена разграничению понятий «вкус», «качество» и «мастерство», где вкус рассматривается как способность к автономному суждению, а не просто следование трендам.

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

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

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

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

Итог:

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

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

Анимации не всегда нужны

Хорошая анимация делает интерфейс предсказуемым и живым, плохая — раздражает и снижает доверие.
Перед добавлением спроси себя: зачем она нужна?

• Объясняет (как на linear.app/ai) — ок.
• Подтверждает действие (кнопка слегка уменьшается) — ок.
• Просто «красиво» — допустимо, если пользователь видит это редко.

Частота использования
Если элемент открывают сотни раз в день (Raycast, список команд), анимации быть не должно — они только тормозят.
Клавиатурные переходы никогда не анимируются.

Скорость
Всё, что дольше 300 мс, воспринимается как лаг.
Спиннеры быстрее = кажется, что грузит быстрее.
Тултипу нужна задержка при первом появлении, но при наведении на соседние — мгновенно и без анимации.

Итог
Добавляй анимацию, если она:

1. решает задачу,
2. видна редко,
3. длится < 300 мс.
   Иначе — не добавляй.

• Большинство участников сходятся: анимация должна быть почти невидимой (<150 мс) или вовсе отключаться, иначе она превращается в тормоз.
• Главный критерий целесообразности — объясняет ли анимация изменение состояния; если пользователь ждёт её окончания, чтобы продолжить, значит, она лишняя.
• «Делайт» и «восторг» нужны в основном самим дизайнерам; обычные пользователи после третьего раза хотят выключить всё, что мешает работать.
• Частые повторяющиеся действия (разблокировка, чекаут, корпоративные формы) требуют минимума анимации; для единичных экранов-онбордингов допустима более заметная, но быстрая подсказка.
• Практически каждый советует добавлять системную настройку «отключить анимацию» и уважать prefers-reduced-motion.

Ты должен почувствовать это

Галочки стоят: сроки, документация, демо — всё готово. Повышение близко.
Но ты не почувствовал. Не почувствовал.

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

Когда ты чувствуешь — знаешь: функция заставляет улыбнуться, будто всегда была здесь. Хочется использовать снова и рассказать другим.

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

Ты должен почувствовать это.

• Всё сводится к чувствам: даже «рациональные» решения в итоге определяются «вайбом».
• Корпоративная машина чувств не имеет, поэтому продукты без души побеждают по метрикам, но не вызывают восторга.
• «Тест выходного дня»: если хочется ковыряться в проекте в свободное время — значит, он «чувствуется» правильно.
• Некоторые считают, что чувства можно (и нужно) анализировать, другие — что это неизмеримая эволюционная сверхспособность.
• Маленькие команды могут позволить себе «неправильные» продукты, которые не проходят корпоративные чек-листы, но вызывают любовь пользователей.