Интерфейсы *

Представлен проект чат-бота SOCIALIST AI v1.0 с интерфейсом, который напоминает Microsoft TextUI.

Дизайн-культура в InfoWatch: что и почему мы решили менять

За последние два года подход к дизайну в компании изменился – от оформления интерфейсов мы перешли к полноценному дизайн-процессу. Под «дизайн‑культурой» часто понимают что‑то абстрактное. На практике все проще: дизайн‑культура начинается не тогда, когда у вас есть Figma и дизайн‑система, а когда вся команда (не только дизайнеры!) начинает думать о пользователе.

О нашем опыте на этом пути, о том, что там с человеческим фактором, повышением доверия и прозрачностью процессов в новой статье рассказывает ведущий дизайнер интерфейсов Вадим Корольков.

Привет, малюсенькое увеличение потенциала kui'я, добавил pv и pvc в список просмотра.

Творите, выдумывайте, пробуйте!)

Apple и Synchron показали, как Марк Джексон с мозговым имплантом может управлять iPad. Он получил мозговой имплант Stentrode, разработанный Synchron в сотрудничестве с Apple, и оптимизированным для работы с iPhone, iPad и Vision Pro. У Джексона боковой амиотрофический склероз, поэтому он не может пользоваться iPad руками. Но с помощью импланта он управляетпланшетом при помощи мыслей. Джексон может открывать приложения и писать сообщения, используя только свои мысли. Для управления используется протокол Switch Control, который воспринимает мозговой имплант за источник ввода. В текущей версии проект позволяет только нажимать на кнопки и писать текст. Имитировать прокрутку и пролистывать содержимое на экране нельзя.

Сложности перевода (локализации) люстры

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

Но в этом году так получилось, что я перешёл на русский Adobe Illustrator - вот.

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

Найдите 10 отличий:

Andrew Yaros воссоздал Apple Lisa. Это один из первых ПК, где появился курсор, иконки и окна в привычном нам виде. Визуальная система, типографика и поведение интерфейса сохранены точно как в оригинале.

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

Обожаю эстетику, в которой всё подчинено структуре: минимум элементов, монохром, строгость. Залипла уже на пол часа. Ностальгируем с удовольствием тут

Эстетика-юзабилити

Всем привет, на связи Вадим, я BI-аналитик и хочу затронуть тему интересную для меня тему. Мой канал в тг: https://t.me/breaking_data

В UI/UX-дизайне и BI-аналитике в частности есть такой эффект - эстетика-юзабилити. Основывается он том факте, что люди воспринимают "привлекательные" продукты как "удобные" и "полезные", даже если никаких отличий от аналогов нет. Важно отметить, что данный эффект работает только в тех случаях, когда никаких значимых технических или функциональных отличий у продуктов нет.

Подсмотрел этот термин у @nastengraph в отношении dataviz'a, но его вполне можно экстраполировать и на другие сферы. Не хочу быть Тайлером Дерденом, но мы живем в мире фаст-фуда. Уйма компаний построены лишь на факте того, что их Бренд или продукт были более "привлекательными" для потребителей:
Telegram - на момент его выхода уже существовал What's Up и был монополистом.
Apple с Iphone - десятки и сотни брендов, боровшиеся за первенство, но все решил пользовательский опыт. Сегодня в целом трудно представить как рынок смартфонов (читать "рынок монополий"), мог быть зеленым, где не было яркого лидера.
Яндекс - долгое время в лидерах российских браузеров был Рамблер, кто-то вообще помнит что это?
FaceBook - да, сегодня этому явлению трудно подобрать определение, но когда-то это был ультимативнопрорывной продукт, затмивший остальные соцсети.

Все вышеперечисленные компании - это IT/Tech сектор. Можно разобрать и более низкоуровневые примеры бытовой жизни.

Например, почему мы выбираем одну кофейню, хотя рядом может быть дешевле и вкуснее? Часто — из-за атмосферы, шрифта в меню, музыки, света и логотипа на стаканчике. Та же история с супермаркетами, где "упаковка" важнее продукта. Или с автомобилями, где бренд и "статус" и составляют ценность.

Что это значит?
Визуальная подача - имеет значение. В аналитике, жизни, при создании своих проектов всё это не только «про красоту», но и про доверие, удобство.

Мораль: эстетика — это не просто "украшение". Это часть восприятия юзабилити. Не только в BI, где «понятный» отчет часто означает «эффективный» отчет, или любом другом продукте. Красота может и не спасти плохой продукт, но точно может дать хороший шанс среднему (Хотя Феррари до сих пор покупают, возможно, силы эстетики еще изучены в недостаточной степени)

Из разговора с потенциальным клиентом…

Клиент: Сколько страниц будет входить в аудит?
Я: Неизвестно. Почему неизвестно? Потому что у меня нет цели написать определённый объём правок и замечаний. Сколько их увижу — столько и зафиксирую. Если бы я проаудировал систему и не нашёл в ней ни одной проблемы — размер документа не превышал бы одной страницы.

Тут сразу пара моментов, которые хотел бы подсветить.

Я раньше, когда работал над документацией, считал, что «чем объёмнее — тем лучше». Это ещё со школы и универа. Реферат должен быть на пять листов. Эссе на семь. Доклад на три.

Акцент был на форме, а не на содержании. И это ужасно. В начале двухтысячных, когда работал в компании Webmaster.Spb проектировщиком, клиентам нравились толстые ТЗ. Точнее, представителям клиентов. Менеджерам. Сами-то клиенты эти ТЗ не читали, насколько мне известно.

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

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

Иногда ещё, знаете, решишь написать статью. И придумываешь ей заголовок «пять ошибок начинающих проектировщиков». И вот четыре ошибки легко расписал, а пятую никак придумать не можешь. И сидишь, мучаешься, тратишь время. А мог сначала статью написать, ограничившись четырьмя ошибками, а затем уже заголовок придумывать.

Прикиньте, кто-то сначала бы придумал тематику: пять начал (законов) термодинамики. И после четвёртого сидел бы и страдал.

Возвращаясь к моим аудитам: у меня нет задачи найти конкретное количество косяков. Задача — проверить, достигают ли пользователи интерфейса своих целей. Если достигают — и отлично! Радоваться надо, что в моём документе будет одна строчка текста («Всё идеально, красавчики»). Это как на чек-ап пойти ко врачу и переживать, что ничего не нашли.

К сожалению, на практике такого ещё ни разу не было. Всегда что-то нахожу.

П.С.
Представляете, я бы сказал, например: «Четыре страницы». Сделал бы аудит и нашёл бы ошибок на две страницы. И что бы делал? То же, что в школе и универе? (здесь должна быть какая-нибудь эмодзи с льющейся бессмысленной водой)

Надоела плоскость. Прямоугольники, которые притворяются кнопками.

Код.

Обновил сайт знакомств для айтишников

Наконец-то!
Уже 13 лет бесплатно ищет половинки. И без рекламы.

Ушел с jquery и bootstrap - перешел на alpine и tailwindcss.
Поменял дизайн на более современный и удобный, как мне кажется.

Знакомства для айтишников - просто наберите в поисковике (он всегда первый), ссылку не буду давать.

Как было раньше можно посмотреть в архиве интернета, с 2012 года.

Попробую публиковать серию постов про мои новые эксперименты с вайбкодингом.

Не использую v0, bolt - так как они совсем почти no-code + генерят react приложения, а мне интересно сейчас проработать поработать с Dart проектами.

Начал с крафта нового сайта для xsoulspace.dev (мой основной сайт по проектам, давным давно писал на flutter и очень давно не обновлял).

Основная идея в том, чтобы:

1. Как можно больше проработать паттернов вайбкодинга

2. Как можно качественнее научиться работать с дизайнерской точки зрения

3. Научиться учить агента новой информации (новый пишу на jaspr - а на нем крайне мало информации - и скорее всего не обучалась ни одна модель, поэтому вайбкодить на нем тяжело - если агенту дать задачу без правил и промптов - он не сможет завершить задачу и закопается в ошибках).

Пока что удалось сделать немного - восстановил навыки промптинга (которые прокачивал в прошлом году)

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

Частично удалось распараллелить работу (используя окна и табы агентов в cursor) и научиться давать относительно автономные задачи (по принципу PDSA (Plan Do Study Act))..

Исходный код открытый, поэтому буду делиться результатами когда завершу делать :) (надеюсь что скоро)

Пока что было две идеи:

1. Сделать в виде интерактивной игры (получились вырвиглазные кнопки

2. Каким-то образом придумать бенто..

Спасибо за ваше время и хорошего дня!

P.s.: почему-то на хабре нельзя загрузить больше одной картинки в пост:(

P.p.s.: почему-то нельзя опубликовать публикацию если хоть раз проставил галочку запланировать..

Тест на собеседовании на должность проектировщика интерфейсов

Ставим перед соискателем большую коробку с конструктором типа Лего. Задача: собрать его за час. А дальше наблюдать.

1. В коробке должно быть шесть пакетов и инструкция по сборке. В инструкции должно быть указано, что для успешной сборки понадобится семь пакетов. Если соискатель заметит это перед тем, как распечатает первый пакет, и укажет на невыполнимость задачи — он молодец.

2. Конструктор должно быть физически невозможно собрать за час. Первый пакет должен занимать в среднем пятнадцать минут, а остальные пакеты должны быть примерно такого же объёма и сложности и это должно быть заметно. Если соискатель, собрав первый пакет за пятнадцать минут, укажет на невыполнимость задачи — он молодец.

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

К сожалению, этот тест — плод моей фантазии развлекательного характера. Представляете, сколько это мороки — подготавливать и упаковывать в пакеты подобные наборы для каждого нового соискателя? Не, проще пообщаться. Но идея не даёт мне покоя :)

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

Несмотря на кадровый голод в IT занято огромное количество лишних людей деятельность которых в общем-то бесполезна. А все что бесполезно как известно приносит только вред. Возьмем к примеру новомодную отрасль UI/UX которая по задумке должна улучшать пользовательский опыт - так называемый "экспириенс". На планете существует целый зоопарк разных форматов дат: 1 ноября 2000, 01.11.2000 и т.д и т.п. Это мелочь, но и в мелочах можно тот самый "экспириенс" взять да и улучшить. И он был повсеместно "улучшен" до формата "3 года назад". Как правило без какой либо возможности вернуть нормальную дату.

Теперь просто хочется простереть руки к небу и крикнуть за что это мне?

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

Как получилось, что юристы используют среду для разработчиков?

e/acc часто пишет про изменение индустрий, вижн будущего, которые он берет из исследований либо из общения с фаундерами (со стороны инвестора). И я у него на канале не первый раз вижу упоминания одной странной штуки.

Мол, можно взять AI среду для разработчиков Cursor и настроить ее как рабочую программу для неразработческих задач. Звучит сомнительно. Но я попытался "покритиковать свою критику", вот что вышло:

Зачем вообще сложный Cursor вместо простого chatgpt?

1. Встроенная реализация агентов

   Система планирует новые действия на основе результатов предыдущих. Пример агента – openai deepresearch. Он понимает, на какие сайты еще сходить на основе того, что уже нагуглил.

   Агент выполняет сложную последовательность шагов (пройтись по гуглтабличке с ссылками на видосы, скачать их, вытащить из них аудиодорожку через ffmpeg, сделать транскрибацию, саммари и сохранить в файлики). Даже если она не известна заранее.

2. Рабочий контекст

   Часто у нас есть какой-то рабочий контекст. Файлики, таблички, инструкции. Программистам важно быстро добавлять нужный контекст к запросам, и Cursor поддерживает это by design. Можно сослаться на конкретный файл или папку. И результаты тоже сразу сохранятся в виде готовых файлов. Плюс есть .cursor/rules "настройками" поведения LLM под разные задачи.

3. Встроенная расширяемость

   Сейчас популярны MCP-серверы – унифицированные обертки над внешними сервисами, дающие к ним доступ LLM-агентам. В два клика даем системе доступ к корпоративному Notion или гугл календарю. Если подходящего нет, просто просим LLM написать его самому. А можно не трогать MCP, а просить разработчиков или LLM писать python-скрипты – агент будет их использовать в дальнейшем.

4. Очень удобная работа с текстом.

   Cursor – лучший инструмент для написания текстов. Он умеет завершать предложения за меня, на лету исправляет падежи, сам понимает, куда я хочу переместить курсор. Можно выделить часть текста и дать задачу чисто под нее. Можно сделать что-то со всем текстом и он подсветит изменения.

   По сути, если вы работали с Canvas режимом в ChatGPT, то на пальцах:

   ChatGPT < Canvas < Cursor

   А точнее

   ChatGPT < Canvas <<< Cursor

А что мешает сделать себе полноценный сервис под свою область (ко мне часто приходят с таким запросом)?

Реализовать нормальную агентскую систему – сложно. Бизнесу дешевле взять уже готовое и расширяемое. Но собственные системы можно и нужно делать, когда есть четкие повторяемые задачи, где есть потенциал свести участие человека к минимуму.

А вот если задач много, разных, они не разбиваются на заранее известную последовательность шагов + нужен человеческий контроль/планирование, то я пока не могу ничего лучше придумать, чем Cursor. Переобулся, короче.

P.s. у меня гораздо менее технооптимистичный взгляд, чем у e/acc, и вижу много сложностей во внедрении таких инструментов в реальном бизнесе, но где-то это может сэкономить десятки тысяч долларов.

Если нравится такой формат авторских разборов, добавляйтесь в мой тг канал AI и грабли – пишу свои выводы из того, с чем сталкиваюсь на практике. Например, инструкция, как анализировать чаты в тг

Привет, развил тему пропихивания стручков (pod'ов) в кубернетис, добавил в меню выбора типа объектов команду apply. Теперь kui'ем можно приколачивать мYAMLики, создавая любые типы объектов. По умолчанию предлагает создать стручок:

Но с помощью кнопки edit можно изменить мямлик, изменения сохранятся в файл ~/.kyml.

С удивлением обнаружил что хаб Кодобред переименован в Говнокод О_о Чтож, так даже интереснее.

Творите, выдумывайте, пробуйте!)

Привет, приспичило создать тестовый стручек (pod), проверить кое-что. Создал и добавил это в kui, в секцию "быстрых" команд:

Тестовый стручек создается вот такой командой:

kube run $quick_pod_name $ns --image=$quick_pod_image --command -- $quick_pod_command 2>&1

Для изменения названия, образа или команды стручка подредактируйте вот эти переменные в начале скрипта:

quick_pod_name=busytest          # Pod name for simple test pod
quick_pod_image=busybox:1.32     # Pod image for simple test pod
quick_pod_command="sleep 3600"   # Pod command for simple test pod

Творите, выдумывайте, пробуйте!)

Что не так с кассами самообслуживания? Разбор ошибки в UX

Взяв продукты в Магните, я пошла на кассу самообслуживания. После сканирования товаров, нажала на кнопку «Карта лояльности". Появилась модалка с подсказкой: "Отсканируйте карту в нижнем углу". Я пробовала сканировать её разными способами, но сканер не распознавал телефон. Сотрудник подсказал: "Положите телефон вертикально». Оке, заветный писк машины - задача решена.

После этого на экране появилась вторая модалка с текстом: "Количество баллов — ХХХ, списание баллов невозможно по тех причинам". И две кнопки: «Начислить баллы» и «Вернуться назад». Я случайно нажимаю "Вернуться назад", и карта сбросилась. Снова сканирование, снова модалка — на этот раз всё прошло нормально, скидка применена, баллы начислены. Задача вроде бы простая: получить скидку и баллы за покупку, но процесс оказался не таким уж очевидным. Давайте разбираться. 

Что не так

— Неочевидный сценарий
Когда я сканирую карту лояльности, я ожидаю два простых результата:
• Применение скидки по карте
• Начисление баллов за покупку

Но вместо этого мне показывают два возможных действия, которые непонятны на интуитивном уровне: «Начислить баллы» и «Вернуться назад». Как пользователь, я не сразу поняла, что мне делать, и случайно сбросила карту.

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

Как можно улучшить

— Объединение шагов.
Зачем разделять информацию на две разные кнопки, если можно предоставить все нужные данные в одном окне? Вместо того, чтобы показывать «начисление баллов» и «сбросить», лучше использовать одну универсальную кнопку с кнопкой «Продолжить», которая будет обрабатывать все сразу.

— Упрощение текста.
Модалку можно отредактировать, чтобы она содержала только нужную информацию для пользователя в одном окне:

модалка
Количество баллов: 36,8
Будет начислено за покупку: 17
Списание баллов невозможно по техническим причинам.
[продолжить] 

Всё, процесс завершён! Всё становится понятно с первого взгляда, и пользователь не теряет время на лишние шаги.

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

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

Привет, зачастую после тыкания в какой-нибудь стручок (pod) приходится подниматься на уровень выше в деплой, стейтфулсет или даемонсет. Для этого в kui надо было сначала посмотреть чем контролируется стручок, сделав describe, потом сменить тип объекта, найти нужный... Хватить теребонькать эти стручки! Добавил для стручков команду Controlled by, она сразу тыкает kui в нужное место!

Творите, выдумывайте, пробуйте!)

Хочу поделиться удобным сервисом для создания резюме. Изначально мы делали его как часть внутреннего продукта, но «Резюмеха» быстра выросла в отдельный сервис и теперь живёт своей собственной жизнью.

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

Формат — максимально читабельный и компактный.  Мы постарались учесть всё, что может понадобиться для создания чистого и современного резюме. И, конечно, вы можете заполнить резюме как на русском, так и на английском.

Пользуйтесь, с удовольствием!

Android-приложение «Контакты»: работает — не трогай

У многих полей контакта есть типы. Например, у номеров телефонов или адресов электронной почты по умолчанию есть типы «рабочий» и «домашний». Аналитики сказали, что нужно реализовать дополнительные типы и дать пользователю возможность создавать свои. Звучит легко, но на деле оказалось совсем непросто.

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

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

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

Создание схемы БД и инициализация стандартными значениями происходила в отдельном потоке, так что у нас получилась небольшая гонка потоков. UI готов отобразить экран и идет в БД за данными, но БД не успевает инициализироваться, так что запрос приводил к критической ошибке. Баг воспроизводился при попытке обратиться к БД только при первом холодном запуске на устройстве или после очистки данных, так как здесь приложению приходится заново создавать схему базы данных.

Пришлось опять добавлять костыль: в отдельной корутине ожидать инициализации БД и только потом начинать рисовать экран...

Дмитрий Бражник, старший инженер-программист в департаменте разработки мобильных приложений YADRO, рассказал в статье, как его команда пыталась допилить стандартное AOSP-приложение «Контакты» и к чему они в итоге пришли.