Системы контроля доступа (СКУД) встречают нас в жизни на каждом шагу: в офисах, домах, транспорте и почти в любой сфере ежедневного применения. За последние десятилетия СКУД прошли большой путь эволюции. В данной статье мы не очень глубоко разберём некоторые важные аспекты реализации СКУД c использованием OSDP Crypto.
Осенью 2026-го страна встала в очереди за бензином. Пока одни карты честно красили пустые баки красными точками, а официальные приложения сетей деликатно молчали о сухих колонках, мы задали неудобный вопрос: а что, если показывать не только где топлива НЕТ, но и где его ВОТ-ВОТ привезут? За пару дней 1 051 человек нажал кнопку «Тоже жду» — и мы поняли, что попали в нерв.
ГдеЗаправка (gdezapravka.ru) — народная карта наличия топлива на заправках России. Не приложение нефтяной компании и не рекламная витрина сети: обычные водители отмечают, где сейчас реально есть 92-й, 95-й и дизель, а мы собираем это в одну живую карту. Наличие — краудсорсинг от людей на местах, цены — открытый скрейп. Без единой строчки данных от владельцев АЗС. Отметиться можно анонимно, без регистрации и номера телефона — по отпечатку устройства.
Интерфейс можно описывать не только через доступные действия, но и через продолжения, которые он делает более лёгкими. В статье предлагается рамка “архитектуры продолжений”: как после действия один следующий ход становится естественным, а другие остаются возможными, но требуют отдельного усилия.
Привет! Хочу рассказать вам о том, как мы применили продуктовый подход к исследованию опыта разработчиков при работе с Figma, чтобы создать единый стандарт оформления макетов в компании.
На Хабре уже есть несколько отличных разборов того, как разные команды наводят порядок в Figma: аннотации, стрелки, сценарии, раскладки макетов и так далее. Я видел материалы Ozon Tech, t2, Иннотех — это классные справочники правил, можно брать и пользоваться. Но, когда в 2024 году я взялся за задачу подготовки стандарта для нашей компании, то столкнулся с вопросами, о которых нигде ничего не нашел. Как разработать единый подход? Что считать правильным и почему? Как упаковать эту идею и «продать» остальным членам команды, а главное: что делать дальше?
В этой статье поделюсь нашим методом поиска ответов на эти вопросы.
Статья про то, как AI-агенту дали знание о дизайн-системе, чтобы он перестал придумывать несуществующие компоненты и начал верстать из того, что реально есть в проекте.
Закрываем очень практичную боль: агент видит макет, умеет писать код, но не понимает, какими компонентами из вашего проекта этот экран нужно собирать.
Внутри: Figma MCP, свой DS MCP, React, Jetpack Compose и SwiftUI, поиск по компонентам, ChromaDB, RAG, embeddings, препроцессор для описания дизайн-системы, грабли с чтением файлов, шумом в контексте, устаревающим SKILL.md и честное сравнение подходов по tool calls, токенам и результату.
Заходите, читайте и рассказывайте, как вы решаете эту проблему у себя ❤️
Краткая история внешней памяти и пять функций листа бумаги
Не претендуя на гениальность задался простым, на первый взгляд, вопросом: "На моем столе в 2026г всегда лежит лист черновика и пара карандашей?" Ответ оказался не таким коротким, как ожидал. Приглашаю к прочтению!
Это третья статья из цикла статей о создании компактной кросс‑платформенной библиотеки для разработки приложений с графическим интерфейсом на языке C++ — Frenchie. Для тех, кто привык изучать исходный код самостоятельно, репозиторий с исходным кодом библиотеки можно найти по ссылке. В данном материале я продолжу рассказывать про ту часть библиотеки, которая управляет состоянием контекстного окна и отслеживает связанные с ним события.
Цель всего цикла материалов — дать представление о том, как устроены подобные проекты, начиная от открытия контекстного окна и управления его состоянием, заканчивая рисованием графических примитивов. Надеюсь, что весь цикл материалов окажется полезным как для тех, кто начинает свой путь в разработке приложений с графическим интерфейсом, так и для опытных разработчиков.
Это вторая статья из цикла статей о создании компактной кросс‑платформенной библиотеки для разработки приложений с графическим интерфейсом на языке C++ — Frenchie. Для тех, кто привык изучать исходный код самостоятельно, репозиторий с исходным кодом библиотеки находится по ссылке. В данном материале я расскажу, про ту часть библиотеки, которая управляет состоянием контекстного окна и отслеживает связанные с ним события - platform backend.
Цель всего цикла материалов — дать представление о том, как устроены подобные проекты, начиная от открытия контекстного окна и управления его состоянием, заканчивая рисованием графических примитивов. Надеюсь, что весь цикл материалов окажется полезным как для тех, кто начинает свой путь в разработке приложений с графическим интерфейсом, так и для опытных разработчиков.
Я объясняла, что такое доступный дизайн, наверное, сто раз. В статьях, на созвонах, в комментариях. И каждый раз ловила одну и ту же реакцию: люди кивают, соглашаются, что это важно, — и через неделю выкатывают серую кнопку на сером фоне.
Дело не в том, что они плохие дизайнеры или им всё равно. Дело в том, что доступность невозможно понять головой. Её можно только почувствовать. А пока проблема не твоя — ты её не чувствуешь.
Я долго думала, как это починить. И в итоге перестала объяснять словами. Я сделала штуку, которая даёт побыть тем самым пользователем — на несколько секунд. Расскажу, как она устроена и почему чек-листы не работают.
Это начало цикла статей о создании компактной кросс‑платформенной библиотеки для разработки приложений с графическим интерфейсом на языке C++ — Frenchie. Я расскажу про то, как пришел к созданию этой библиотеки, а также постараюсь максимально понятно и просто описать общие принципы её работы и архитектуру.
Цель всего цикла материалов — дать представление о том, как устроены подобные проекты, начиная от открытия контекстного окна и управления его состоянием, заканчивая рисованием графических примитивов. Надеюсь, что весь цикл материалов окажется полезным как для тех, кто начинает свой путь в разработке приложений с графическим интерфейсом, так и для опытных разработчиков.
В нулевых у пользователя Windows было две системы.
Первая Windows XP, загружалась с диска, показывала ядовито‑зелёный «Пуск», синюю панель задач, загрузчик браузера и уверенно делала вид, что этого достаточно.
Вторую пользователь собирал сам.
Снизу ставился RocketDock, чтобы было почти как на Mac. Поверх XP натягивалась тема под Vista, потому что сама Vista уже выглядела красиво. В угол попадал CPU‑Meter с температурой процессора, погодой, сетью и другими признаками того, что компьютер не просто работает, а живёт насыщенной внутренней жизнью. По горячей клавише вызывался Launchy. Окна прятались в трей CaptainTay‑ем, с обязательнным Boss‑Key. Раскладку спасал Punto Switcher. Скриншоты делал отдельный скриншотер. Хоткеи держались на AutoHotkey.
Это была не коллекция утилит. Это была функциональная прослойка на условных рефлексах между человеком и системой.
Днем унылые пары, а ночью Vista Transformation Pack на свежепереустановленный ZverXP, потому что хотелось красоты. Дикий рынок, пиратские диски, форумные сборки, доверие на честном «у всех антивирь ругается» и надежда на то, что если программа весит меньше мегабайта, значит, она почти святая.
Сегодня большая часть этих динозавров вымерла. Сайты пропали, сертификаты истекли, последние версии лежат на загрузочных агрегаторах как цифровые окаменелости. Но вся странность в том, что сами функции не умерли.
Они победили.
Просто теперь быстрый запуск, поиск, хоткеи, скриншоты, виджеты, command palette и автоматизация живут внутри ОС, браузеров, редакторов, SaaS‑продуктов, PowerToys, Alfred, Raycast, скриптов и AI‑ассистентов.
Классический лаунчер умер не потому, что стал не нужен. Он умер потому, что его разобрали на органы и пересадили в платформы.
Пожар в Нотр-Дам-де-Пари в 2019 году часто представляют как трагичный случай, разрушивший исторический памятник. Но для проектировщика в этой истории важен ещё один слой: система обнаружила проблему, выдала сообщение с зоной и номером датчика, а человек не смог быстро превратить эти данные в действие. Формально информация была передана. На практике интерфейс не помог понять, где именно возник пожар и что нужно сделать дальше.
Пользовательские ошибки часто воспринимают как проблему плохого обучения, невнимательности или недостаточного опыта: кто-то не туда нажал, не прочитал подсказку, выбрал не тот пункт или пропустил обязательное поле. Но в сложных системах ошибка не всегда возникает только на стороне пользователя. Чаще она появляется на стыке интерфейса, задачи, контекста и ментальной модели человека.
Меня зовут Елизавета Давыдова, я UX-исследователь в экосистеме Лукоморье. Под катом расскажу, как теории человеческой ошибки и методы когнитивной эргономики помогают смотреть на интерфейс через потенциальные сбои в действиях пользователя. На нашем кейсе покажу, как мы применили методологию SHERPA и иерархический анализ задач к интерфейсу таск-трекера: разложили пользовательский сценарий на шаги, классифицировали возможные ошибки и использовали эту модель как основу для проектировочных решений.
Итеративный дизайн на самом деле не только про дизайн, но и про подход к созданию продукта. Он связывает дизайнеров, команду разработки, PO (product owner), PM (project manager) и пользователей в систему, где каждый влияет на то, каким становится продукт.
Дизайнер перестаёт быть исполнителем макетов и становится участником продуктовых решений. Разработчик перестаёт просто отрисовывать экраны по макету и влияет на продукт на протяжении всего его жизненного цикла, замечает то, что не видно на этапе проектирования, и предлагает свои гипотезы. Пользователь получает возможность формировать будущее продукта через свою обратную связь, а команда быстрее проверять гипотезы и корректировать направление работы. PO перестаёт быть просто постановщиком задачи, он помогает расставлять приоритеты и принимает решения на основе того, что показала каждая итерация.
В этой статье поделимся опытом использования итеративного подхода в дизайне в разных масштабах: на крупных веб-сервисах и больших продуктовых итерациях, на маленьких недельных спринтах и на более локальных задачах — презентациях, сайтах, лендингах. С какими сложностями столкнулись, в чём преимущества и недостатки.
Не “проводник”, а визуальное пространство документов, что-то ближе к COSMOS (от Waves)-подходу, где файлы живут плитками, имеют вес, цвет, превью, теги, статус и историю.
Всем привет. :?*(*%:%=)
Ниже разбор, как мы шли от красивых, но тяжёлых плиток к более живому и быстрому интерфейсу на C#
И давайте сразу разберемся с плитками (Тут только о плитках)
Не так давно я читал о протоколе Wayland и мне врезалась в память эта фраза:
Заявленная цель Wayland — «каждый кадр идеален».
Я считаю, что к этой цели должны стремиться мы все. В Wayland говорилось о технической стороне дела (современные стеки GPU очень сложные, а Wayland пытается вернуть себе контроль), но этот принцип можно применить и к UI.
Эмпирическое правило таково:
Если сделать скриншот приложения в любой момент времени, должно быть понятно, что на нём происходит
Дополнение: раньше оно заканчивалось «..., должно иметь смысл», но в таком случае не учитываются сложные техники анимации, например, размазанные кадры и тому подобное.
Почему нам важен каждый кадр? Потому что это нарабатывает доверие. Пользователи не могут увидеть код, поэтому судить о качестве приложения могут судить только по UI. Если UI хорош, значит, у разработчиков было время на его совершенствование, а значит, они, вероятно, потратили сравнимое количество времени на отладку кода. Это эвристика, но вполне разумная.
В девелоперском проекте технико-экономические показатели — это не просто таблица с площадями. Это данные, на которые завязано множество подразделений и управленческих решений внутри компании.
В этой статье я поделюсь опытом работы с ТЭП на основе BIM-моделей и расскажу о разработке инструмента «ТЭП Контроль».
Эта статья написана по результату проектирования информационной системы на базе ИИ для медицинских работников. Я не буду описывать интерфейсы системы, но хочу остановиться на отдельном ее элементе, который нередко оказывается за рамками внимания дизайнеров и начинающих разработчиков, потому что основная часть всего описываемого процесса находится вне интерфейса, и только некоторые небольшие фрагменты системы торчат на уровне пользователя.
Свежее исследование Стэнфорда (Nature Health, январь 2026) связало дальтонизм с поздней диагностикой рака мочевого пузыря — у пациентов-дальтоников смертность за 20 лет на 52% выше. Причина в том, что главный ранний симптом, кровь в моче, они просто не видят: цвет для них не считывается. Это медицинская история, но она точно описывает ошибку, которую дизайнеры делают каждый день — кодируют критическую информацию одним только цветом. Разбираю, как устроена эта ошибка в интерфейсах и что с ней делать на практике.
Жизненный цикл разработки ПО (Software Development Life Cycle, SDLC) — это процесс управления программным обеспечением на протяжении всего времени его существования, от планирования до вывода из эксплуатации. API относится к программному обеспечению, поэтому термин «жизненный цикл API» синонимичен SDLC. Даже если ваш API не пройдет полный цикл, понимание того, из каких этапов тот состоит, поможет вам выработать подход к разработке.
Жизненный цикл API состоит из таких этапов, как: планирование, проектирование, реализация, тестирование, развертывание, сопровождение и выведение из эксплуатации.
LLM уже умеют быстро собирать мобильные макеты, и на первый взгляд результат часто выглядит убедительно. Кнопки похожи на кнопки, bottom sheet на bottom sheet, экран не разваливается, и его можно показать на обсуждении. Но на практике это всего лишь аккуратный черновик, который ещё нужно как следует доработать: посмотреть компоненты, состояния, навигацию, safe area, длинные тексты и поведение на маленьком экране.
Поэтому предлагаю разобраться, где LLM-инструменты действительно снижают стоимость первой итерации, а где просто переносят сложность на следующий этап: дизайн-ревью, разбор состояний и ручную адаптацию под мобильный контекст. Зафиксируем практические границы применимости LLM при работе с мобильными макетами.
