Интерфейсы *

Необычный лад это лад построенный не на натуральном звукоряде. Для кого-то необычные лады могут быть обычным явлением. Те кто имеет дело с сочинением блюза постоянно ими пользуются.

Для записи нот с применением необычного лада обычно рекомендуют использовать «случайные» знаки альтерации в каком-нибудь мажоре или миноре.

Но можно создать ключевые знаки для любого мыслимого лада.

Лад содержит звуки расположенные в определённой последовательности интервалов между ними. Обычно так их и запоминают. Но есть возможность не мучить себя формулами тон-полутон-полтора тона…

Для того чтобы построить тональность (лад с указанием тоники) можно применять программные графические средства.

Попробуем создать ключевые знаки для минорного блюза от ноты Фа-диез.

В качестве инструментов применим векторный редактор Inkscape и клавиши, чтобы прослушать то, что получилось.

В векторном редакторе предварительно создадим нотное поле и трафареты для работы с ним.

Время релиза. Открываешь Figma, берёшь скриншот из прода и начинаешь сравнивать с макетом:
— Цвета совпадают?
— Отступы правильные?
— Шрифты те?

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

Я подумал, что если создать AI-плагин для Figma, который будет делать дизайн-ревью автоматически?
Но ведь я дизайнер, а не разработчик. Решение скрывалось в Claude, Cursor и 4 неделях упорства.

Сегодня плагин:

✅ Находит расхождения в цветах
✅ Ловит ошибки в тексте
✅ Показывает информацию на превью

Я не стал разработчиком за месяц, но получилось создать работающий инструмент.

В этом посте пойдет рассказ о ToF-датчиках, которые мы с моей командой пытались обуздать чуть более недели. На рынке большое количество различных датчиков расстояния, их вариаций и модификаций. От ультразвуковых датчиков HC-SR04 мы решили сразу отказаться, так как нам нужна была максимальная точность и стабильность измерений.

Привет! Я — Лёша, принципал дизайнер, решаю бизнес-задачи с помощью дизайна уже больше 15-ти лет. Это моя вторая статья из серии посвященной дизайн-процессам, и в ней мы поговорим о втором ромбе системы Double Diamond и о том как же нам теперь закрыть выясненную боль пользователя, и превратить наши идеи в живой, простой, понятный и удобный продукт. Поехали!

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

Теперь пора перейти от проблем к решениям. Если первый ромб был про "Что?" и "Почему?", то второй — про "Как?".

Второй ромб так же состоит из двух, потенциально бесконечно повторяющихся внутри до нахождения нужного решения, фаз: Develop(Разработка) и Deliver (Доставка/Внедрение)).

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

Проект LUWRAIN — пример именно такой истории. Это платформа для разработки невизуальных приложений, которая тринадцать лет создаётся усилиями энтузиастов. Сегодня у неё появляется шанс сделать рывок — с помощью LLM и инженерных подходов, основанных на открытых технологиях. В случае LUWRAIN, как и в случае многих похожих инициатив, существует поиск правильного соотношения смысла и усилий. Поэкспериментировать и найти баланс в том числе помогла программа грантов Yandex Open Source.

Меня зовут Михаил Пожидаев, я работаю доцентом теоретической информатики в Томском государственном университете. Читаю такие предметы как обработка естественного языка, ОС UNIX, анализ социальных сетей и введение в программную инженерию. В этой статье расскажу о своём опыте создания программных продуктов, которые должны казаться странными и нелогичными в привычных обстоятельствах, но обстоятельства нестандартны.

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

Можно также отметить и следующие последствия:

не все архивы спешат переходить на цифру

цену доступа к оцифрованным документам регламентирует администрация субъекта

Привет! Я — Лёша, принципал дизайнер, решаю бизнес-задачи с помощью дизайна уже больше 15-ти лет. Это моя первая статья из небольшой, но насыщенной серии, и она полностью посвящена дизайн-процессам и взрослому, результативному подходу к работе. Я постараюсь рассказать все очень кратко, насколько это возможно чтобы не потерять суть, но емко. Сделаю это так, чтобы все процессы стали понятны даже новичку.

Думаю большинство читателей уже знакомы с известной системой «Double diamond» (двойной ромб), разработанной Британским Советом по дизайну еще в далеком 2005-м году. Называть его в русском варианте «Двойной алмаз» некорректно. Алмаз многогранен, а суть подхода именно в двух, при необходимости бесконечно повторяющихся этапах дивергенции и конвергенции внутри каждого ромба.

Если говорить простыми словами, то суть заключается в том, что сначала мы расширяем наш поиск во все возможные стороны, и только потом приступаем к поиску решений, объединяя все полученные знания, при этом сужая фокус внимания. Мы делаем какие-то выводы из полученных данных и оставляем только самое важное из того что мы смогли выяснить. У каждого ромба в этой системе есть два этапа (расширение и последующее объединение):

Меня зовут Светлана Палицына, я старший разработчик в мобильной команде «Лаборатории Касперского». Мы занимаемся разработкой EMM-решения для управления корпоративными телефонами и защиты хранящейся на них корпоративной информации. Защита мобильного начинается с экрана блокировки, и в этой статье расскажу про разные способы оформления этого экрана на Android, предоставляемые классом DevicePolicyManager.

Экран блокировки — своего рода визитная карточка всего мобильного интерфейса. Каждый виджет и UI-элемент тут требует особого внимания, чтобы не перегружать пользователя информацией и обеспечивать защиту корпоративных данных (например, скрывать показ содержимого уведомлений от посторонних, которым аппарат случайно может попасться на глаза). Но главное — важно, чтобы разблокировать его можно было исключительно одобренным корпоративными политиками методом. Многие компании, к примеру, запрещают биометрические методы разблокировки как не самые безопасные. В идеале для бизнеса (и самого пользователя) такой экран должен быть лаконичным, понятным и безопасным. И лучший способ достичь этого идеала — подробная кастомизация!

Мой сын любит LEGO. Но он не собирает замки, драконов и машины — ему скучно. Он строит существ. Иногда я даже не понимаю, что это. Пока я смотрел на его очередную коллекцию «непонятных, но гениальных» существ, я понял — он не играет по правилам. Он собирает то, что ему нужно прямо сейчас — завтра будет уже другое. Так появился дизайн моего приложения.

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

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

Привет, Хабр! Мы — Руслан Ильясов, дизайн-лид, и Антон Минеев, продукт-дизайнер. Работаем над внутренними продуктами МТС — системами, которые не видят клиенты, но которые обеспечивают работу экосистемы: помогают коллегам общаться, оформлять заявки, реагировать на инциденты и работать каждый день.

Привет, Хабр.

Красивый и интуитивно понятный интерфейс — это моя личная страсть. Я тратил дни, чтобы докрутить свои проекты до нужного мне уровня. В итоге я начал систематически собирать приёмы HTML и CSS, которые мгновенно улучшают восприятие пользователя.

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

Давайте посмотрим, что я вам подготовил.

Привет!

Меня зовут Андрей и я хочу поделиться своим опытом создания концепта для регионального поратала записи на прием к врачу.

Статусы вошли в жизнь пользователей коммуникационных инструментов очень давно: вспомните легендарную «Аську» или Mail.ru Агента. Это действительно удобно – заранее видеть информацию, которую потенциальный собеседник хочет сообщить о себе. В корпоративной среде статус играет более утилитарную роль. При помощи статусов сотрудник транслирует свой уровень доступности, сообщая коллегам важную информацию о том, что он, например, «В отпуске», «На больничном», «На звонке» или «На встрече».

Мы запустили статусы в июне 2025 года, и это стало долгожданным событием для сотен тысяч наших пользователей. Не каждое нововведение настолько круто «заходит» в корпоративной среде. И конечно, за удобной и простой фичей стояла большая работа. О том, как это было, мы расспросили в команде разработки eXpress.

Что важно фронтенд-разработчику при создании веб-приложений? Поддержка текущей кодовой базы, удобство внедрения новых фич и возможность повторно использовать компоненты. Создать такие условия помогает популярный подход к проектированию — FSD (Feature Sliced Design). Разбиваем интерфейс на независимые, переиспользуемые модули (виджеты, фичи и т. д.), получаем чёткие правила, единую структуру проекта и ускорение разработки за счёт переиспользования кода и изоляции ответственности.

Подход FSD во многом прекрасен, но всё же нам в нём не хватало некоторых важных аспектов: внятного разделения слоёв бизнес-логики, удобства работы с кастомными хуками (они быстро разрастаются, обрастают связями и становятся сложными для тестирования). Также было неясно, куда выносить сложные общие компоненты из разных частей проекта. И, например, как легко отделять один бизнес-модуль от другого, не ломая всю систему…

Меня зовут Иван Соснович, я тимлид фронтенд-разработки в СберТехе, тружусь в команде Platform V Kintsugi — это графический инструмент для сопровождения, мониторинга и диагностики Postgres-like СУБД. В этой статье я покажу, как мы доработали FSD под себя, и дам ссылку на пример со структурой приложения. Надеюсь, будет полезно фронтенд-разработчикам.

Привет, Хабр! На связи Юлия Жидкова, тимлид команды продуктового дизайна «МосТрансПроекта». В одной из прошлых статей мой коллега Руслан рассказывал о создании сервиса по оценке транспортной доступности жилых комплексов «Узнай про ЖК». Сегодня я расскажу, как мы разрабатывали дизайн сервиса, какие проблемы пришлось решать и почему «Узнай про ЖК» сегодня выглядит именно так, а не иначе.

Недавно состоялся очередной релиз Debian — одного из старейших дистрибутивов GNU/Linux, который ведёт свою историю с 1993 года. К отличительным чертам этой операционной системы относят высокую надёжность и поддержку широкого спектра вычислительных архитектур. Многие другие дистрибутивы используют Debian в качестве своей основы.

В этой статье речь пойдёт об одном из стандартных вариантов дистрибутива Debian, графический интерфейс пользователя которого построен на следующих компонентах:

• менеджер дисплеев LightDM;

• оконный менеджер Openbox;

• окружение рабочего стола LXDE — Lightweight X11 Desktop Environment.

На днях делился подборкой научных статей по open source — одна из них предлагает обращать внимание на определенные управленческие моменты при участии компаний в открытой разработке. Сегодня продолжим обсуждать тему, но в менее академическом ключе и сфокусируемся на примечательном практическом кейсе.

В центре внимания — открытая дизайн-система Т2. Как уточняет Сергей @OsipovSV лид данного направления в Т2, разговором с которым я делюсь далее, новую дизайн-систему пока сложно считать полноценным open source-продуктом. Однако для меня этот кейс интересен с точки зрения первых шагов компании в данном направлении.

Мы продолжаем нашу серию материалов о трендах в дизайне интерфейсов и начинаем с самого широкого пласта — культуры и общества.

Как постмодерн и метамодерн влияют на визуальные решения? Почему «ирония», «новая этика» и «необрутализм» становятся не просто стилями, а инструментами коммуникации?

Мы собрали более 50 источников — от Awwwards и Behance до академических публикаций — чтобы выделить ключевые мегатренды и показать, как они формируют язык современного UX/UI.

Это не короткий лонгрид, а полноценная исследовательская статья — на чашку кофе (или даже две). Запасайтесь вкусными напитками — будет объёмно, живо и очень интересно.

На прошлой неделе мы выпустили обновление кроссплатформенной библиотеки контролов Eremex Controls для Avalonia UI. О новых ее возможностях расскажем в этой статье, но уже в рамках нового корпоративного блога нашей компании Эремекс.

Меня зовут Витя, в Selectel я работаю проектировщиком интерфейсов. В нашей команде анализом решений, связанных с пользовательским образом, занимается дизайнер. Такой подход позволяет быть ближе к пользователям и проектировать сценарии взаимодействия, продумывая метрики, на которые мы будем смотреть в перспективе, и оценивать их эффективность. Возможно, вы читали мои статьи и знаете, как мы используем PostHog в работе.

За долгую практику работы с сервисом накопилось большое количество кейсов, когда PostHog помогал мне получать и обрабатывать данные. Хочу поделиться знаниями с начинающими дизайнерами, аналитиками и продактами.