Дизайн

🤔 Как заставить кодинг-агента делать красивый и неоднотипный дизайн? На самом деле вам нужны всего три скилла и одно простое действие. И начнем со скилов 👇 Первый — Impeccable. Он чистит типичный нейросеточный дизайн от лишнего мусора и помогает собрать нормальную дизайн-систему под ваши предпочтения. Второй — Taste Design Frontend. По сути, добавляет агенту вкуса: элементы становятся современнее, дороже и просто приятнее визуально. Третий — Animate. Чтобы анимации были плавными и человеческими, а не с этими лютыми нейросеточными подергиваниями. 🤷‍♂️Но просто поставить эти три скилла недостаточно. Перед тем как что-то генерировать, найдите 3–5 референсов сайтов, которые вам реально нравятся. Потом запускаете Impeccable Init, скидываете туда референсы и собираете вместе дизайн-систему. Дальше подключаете Taste Design Frontend для визуала и Animate, если нужны анимации. Все. 😅 🚨 Главное не пропускайте шаг со сбором примеров. Потому что даже с лучшими скиллами но без примеров агент все равно будет делать довольно шаблонный дизайн. Свята место | 10МДК | YHub

Хорошее исследование Отличный пример, как сделать хорошее исследование на примере Sable. Поскольку игра в открытом мире, там всегда думают о том, с какой стороны игрок подойдёт к тому или иному месту. Например, у нас есть какой-то очевидный вход на корабль, но можно подойти к нему с другой стороны, где этот вход изначально не увидишь. Разработчики добавляют ценный лут с другой стороны (в данном случае яйцо Чамов, они нужны для прокачки выносливости в игре), и когда игрок за ним забирается, он практически гарантированно видит вход, либо следующую точку маршрута (скрин 1). Это простая штука, но работает крайне эффективно и заставляет игрока чувствовать себя очень умным) Мало того, что нашёл лут, так ещё и открылась новая локация. А ещё эти Чамы любят располагать на каких-то точках обзора в городах так, чтобы эти штуки было видно снизу, и чтобы когда игрок на них забрался, он видел не только весь город как на ладони, но и следующие спрятанные айтемы (скрин 2). На скриншоте я уже всё подобрал, но с этой точки видно ещё 4 или 5 таких же Чамов. А некоторые айтемы располагают по цепочке, чтобы тебе каждый раз был виден только следующий Чам. Таким образом, игрока подробно ведут по маршруту и проще дать гарантированно интересное исследование. Очень простые приёмы, но если грамотно применять, работают хорошо и используются в большом количестве проектов с хорошим эксплорингом. Sable в этом плане хрестоматия таких вот маленьких удачных решений дизайна уровней. #Sable #leveldesign #анализ

Ming Image Prompt Builder Визуальный редактор структурированных промптов для Ming-Image-0.1-Design в #ComfyUI. Рисуешь прямоугольники на холсте, описываешь объекты и точный текст - на выходе готовый Ming JSON • прямоугольники для семантических групп - объекты, точный текст, цвета #RRGGBB • превью раскладки прямо в ноде • импорт и экспорт JSON с валидацией • region-редактор: resize, копирование, переключатель слоев фронт/бэк • работает с официальным текстовым энкодером Ming и с comfyui_ming_native Схема промпта: canvas_settings + layers с координатами, иерархией и цветами. Геометрия - подсказка для модели, не детерминированный контроль. Без инференса и загрузки моделей - только сборка JSON *Пишут что Ming очень хорош в изображении тиекста #prompting #mingimage MAX

Помните мои тесты в Blender с кораблём и как я ещё недавно был в шоке от того, что с ним смогла сделать Astra? В общем вот, что уже получается с Opus 5.5, я не то что сделал полноценную игровую модель, а собираюсь делать свою анимацию с сюжетом и персонажами😅 Я пришёл к моменту, когда меня теперь тормозят именно мои вычислительные мощности, а не способности моделей, которые воплощают задумки... На рендер этого видео ушло около 4~5 часов на 8гб видеокарте. Вся сцена: 1,92 млн полигонов (3,35 млн треугольников), 1 820 объектов. Из них: 871 — корабль с кракеном; 385 — море, льдины, ледник, горы; 538 — невидимые физические коллайдеры; 26 — 13 камер и 13 точек, куда они смотрят. Движущиеся части корабля: 312 объектов Все звуки и музыка созданы локально с помощью YuE2-3B и StableAudio3-SFX весь флоу выложу позже, когда уже будет финал с персонажами И это только начало😐

Как Сиракьюса переезжал на Айфон 18 Про В последнем выпуске АТП Джон Сиракьюса жалуется на то, как переезжал на Айфон 18 Про. Это в начале, где-то на восьмой минуте уже: https://atp.fm/710 Проблема в том, что процесс переезда с телефона на телефон предельно хрупкий. На телефоны нельзя дышать, и малейшая неаккуратность приводит к тому, что весь многочасовой процесс отменяется. После этого новый телефон нужно сбрасывать до заводского состояния и начинать всё с начала. Джон уже жаловался на этот процесс в прошлом или позапрошлом году. Тогда Джону удалось завершить переезд с третьего или четвёртого раза. Одна из «ошибок» была такой. Новый телефон предложил настроить Сири, и в ходе этого процесса надо было произнести «Hey, Siri». Джон так и поступил. Старый телефон среагировал и перешёл в режим Сири, что отменило весь процесс. Такую ошибку проектирования можно допустить только если буквально ни разу не попробовать воспользоваться этой фичей. Как устроен процесс тестирования у Эпла остаётся только гадать. В этом году ситуация не стала лучше, но у Джона-то опыт. Поэтому можно было бы предположить, что в этот раз всё получится. Но нет: он снова переехал с четвёртого раза. Вот одна из «ошибок»: Джону нужно было воткнуть в телефон зарядник, и он случайно нажал на кнопку камеры. А вот другая. Сначала оба телефона что-то напряжённо делали, а потом на старом загорелась надпись «Finish on the new iPhone» в шторке с крестиком. Джон, разумеется, воспринял это так, что всё, от этого телефона ничего больше не нужно, дальше уже новый сам что-то доделывает. Как только он закрыл шторку, весь процесс снова отменился. Я не представляю, как это может с первого раза пройти обычный пользователь, если даже Джон запинается несколько раз. И это ведь не какая-то экзотическая ситуация, а самая обычная, причём на пути получения первого впечатления! Что происходит в Эпле, что они это выпускают? Отдельно хочу обратить внимание проектировщиков на значение текста в интерфейсе. В последнем случае всё сломала именно неудачная формулировка. В некоторых компаниях бывает, что дизайнеры дизайнят как-то приблизительно, без текста, а текст пишут какие-то текстовые люди потом отдельно. Это очевидный бред: что это за дизайнер, если он не умеет писать текст? Это же главный инструмент ясной мысли. Если человек не может написать текст, как он может что-то задизайнить? И что за дизайн без текста? Это же главный инструмент коммуникации. Если вы дизайнер и не считаете текст предметом своей работы, стоит задуматься.

Как проектировать продукты для мышления Самая частая причина провала продуктов для запоминания/обучения чему-либо не плохой движок/интерфейс, а то, что пользователь продакт не смог ответить, ЗАЧЕМ именно ЭТО нужно помнить. Решить, ЧТО достойно быть запомненным – вот главная работа, которая а) не автоматизируется; б) не решается никаким механизмом удержания и вовлечения и она первичнее того, как это запоминать. Правильный продукт для мышления открывает мысли, которые без него не могли бы случиться, поэтому правильный вопрос такого любого продукта не «что должен делать продукт», а «какие мысли он позволит подумать». Забавная игра слов и смыслов в пятницу, ага. Модель продукта для мышления ≠ Продукт Модель продукта, в которой развитие мышления строится на интервальном повторении крива и нестабильна, потому что интервальное повторение всего лишь один один из десятков механизмов для развития мышления. Строишь продукт вокруг одной модели и он станет её потолком и блоком. 10 механизмов удержания в памяти: множественность форм одного вопроса, атомарность вопроса, dual-coding (текст+образ), вариации контекста, обогащение связей, сторителлинг смысла(ов), чанкинг (укрупнение единиц восприятия), калибровка внимания. 10 механизмов мышления как такового: расконцентрация/уединение, задержка первого ответа, наблюдение ощущений до, петля инсайт↔создание, сеть связей, а не изолированные факты, смена уровня абстракций, воплощение абстракции в предмет, поиск контрпримеров и опровержений, эмоциональная включённость, вопрос без заранее заданной цели. Проектируй Сети, а не точки Единица ценности – в Сети ты знаешь сам чего Структура связей делает забывание сложным. 1) Давай знание минимум в двух кодах одновременно. Текст + образ вспоминается устойчивее вместе с параллельным каналом кодирования той же единицы смысла. Экспериментируй с ними. 2) Варьируй контекст(ы), а не только содержание. Одно и то же место, время, фон снижает удержание на 40% относительно вариативного контекста. Продукт, который всегда выглядит и ощущается одинаково при повторном касании, недоиспользует потенциал памяти сам по себе. Вариативность интерфейса это новый механизм. Плотность чанков важнее объёма знаний, а значит, что продукт должен ускорять именно сборку чанков у пользователя через укрупнение единиц восприятия форм. Чанки – это небольшие квадратные участки, на которые игры (например, Minecraft) делят свои большие миры для экономии памяти и быстрой прорисовки 🍌Но и здесь скрыта очередная ловушка мозга: так, пользователь обучается узнавать форму вопроса раньше, чем осмыслять его, и начинает отвечать на паттерн, а не на суть. Поэтому снова упаковывай один и тот же смысл, но в 2+ разных формы, иначе ты тренируешь узнавание интерфейса, а не мышление. Эмоция – несущая конструкция в продуктах, а эмоциональная связь пользователя с материалом первичней материала как объекта. Великая цель-петля таких продуктов – изменение знаний всего человечества, которое возвращается и меняет тебя, твой продукт и мир. Они рождаются только тогда, когда их создатель решает свою собственную реальную задачу и делится этим процессом с окружающими миром через свой продукт. Они растут только вместе с пользователем, расширяющееся понимание и мышление которого должно менять как пользователя, так и сам продукт, порождая у обоих новое понимание предмета мышления. Всё есть петля, пространство, круг и цикл. Ты начнёшь строишь благо, не осознавая это.

Сегодня поделюсь одной простой идеей для e-com, которую я пока почему-то нигде не встречал Замечали, что почти во всех iOS-аппах при вводе адреса такие поля, как квартира, подъезд, этаж и домофон, по умолчанию открывают обычную буквенную клавиатуру? Логика понятна: разработчики перестраховываются, ведь изредка адрес содержит буквы (например, квартира И-214). Но стандартный нумпад в iOS не даёт переключиться на буквы, поэтому всем нам открывают полноразмерную клавиатуру Проблема в том, что буквы в этих полях — редкое исключение. В итоге абсолютное большинство пользователей каждый раз вынуждены: 1⃣ Вручную тапать «123» для смены раскладки 2⃣ Набирать цифры на менее удобных мелких кнопках верхнего ряда Как это решить нативно и красиво? 1⃣ Оставляем нумпад по умолчанию, но даём быстрый свитч на буквы прямо над клавиатурой. Вешаем тулбар в inputAccessoryView: слева кнопка «Abc», по центру flexibleSpace, справа — «Готово». 2⃣ Ставим нумпад по дефолту: textField.keyboardType = .numberPad 3⃣ По тапу на «Abc» переключаем тип клавиатуры: textField.keyboardType = .default textField.reloadInputViews() В случае с тем же Ozon 😊 (драфт решения прикрепил) мы экономим пользователю до 4 лишних тапов при оформлении заказа (по одному переключению на квартиру, подъезд, этаж и домофон) и делаем сам ввод удобнее Мобильные разработчики, вопрос к вам: почему так до сих пор массово не делают? В чём подвох или дело просто в приоритетах бэклога? 👇🏻

Как сделать прайс-лист, который продаёт 💬 Пишите просто. Избегайте сложных формулировок и профессионального жаргона. Клиент должен сразу понимать, что и за сколько он получает. ⭐️ Покажите главное. Разместите популярные позиции в начале списка — это ускорит выбор и подчеркнёт ваш флагманский продукт. 📊 Ориентируйтесь на спрос. Если статистики нет, проведите опросы среди клиентов. Это поможет определить, какие услуги или товары стоит продвигать первыми. 🔍 Анализируйте рынок. Изучите прайсы конкурентов: обратите внимание на их ошибки, структуру и визуальные решения, чтобы создать собственный, более удобный вариант. 🧾 Минимализм в дизайне. Изображения и графика должны дополнять, а не отвлекать. Главный принцип — чистота, читабельность и логика расположения информации. Фаундер | Бизнес и Стартапы

⚡️ inclusionAI открыла две модели для генерации и редактирования дизайна Ming-Image-0.1-Design создаёт интерфейсы, дашборды, инфографику и постеры с разрешением до 2048×2048. Модель хорошо работает с текстом и умеет сразу генерировать изображения с прозрачным RGBA-фоном. Ming-Image-0.1-Design-Layer решает обратную задачу: разбирает готовую картинку на отдельные редактируемые RGBA-слои, сохраняя исходные пропорции. Обе модели имеют 6 млрд параметров и опубликованы под лицензией MIT. Design лидирует среди моделей с открытыми весами в рейтинге UI/UX от Artificial Analysis, а Layer показала лучший результат во всех 12 тестах Crello. https://modelscope.ai/models/inclusionAI/Ming-Image-0.1-Design https://modelscope.ai/models/inclusionAI/Ming-Image-0.1-Design-Layer

Об уважении к клиенту Одна из утилит, которой часто пользуюсь – скриншотер. Нажал горячую клавишу, выделил часть экрана, где какая-то фигня случилась, подрисовал стрелочку к проблемному элементу и пару слов комментария, отправил разработчику. Полезно, удобно. Нужно не только мне. Существует целый класс продуктов с такой функцией. Предыдущий выбор мне надоел, я пошел искать новый. Узнал, что на моем компьютере он уже есть: Microsoft с 2002 года разрабатывает и держит в составе Windows ровно такую программулину – #стартапдня Snipping Tool. И это не что-то заброшенное, команда там работает, буквально прошлой осенью вышло большое обновление. Тем не менее, приложение плохое. К интерфейсу можно привыкнуть, дело вкуса. И с отсутствием выбора горячей клавиши можно смириться. Стив Джобс и Генри Форд стиль: цвет может быть любой, если он черный. Но, блин, Snipping Tool не позволяет сам подпись на картинке нарисовать – предлагает в Paint, полноценный редактор, для этого переключиться. И даже в Paint стрелки только горизонтальные и вертикальные, произвольных нет. Я могу объяснить, почему для корпорации скриншотилка – стотысячный приоритет. Я могу понять, что начальство у продакта и сам продакт сидят на Mac, и в жизни никогда не сталкиваются со своей поделкой. Но принять такое отношение к миллиарду [реально миллиарду!] пользователей я не могу. Эх. #корпоративный

Замкнутость интерфейса Замкнутость интерфейса — это полнота и непротиворечивость правил, определяющих его состояния и переходы между ними при всех допустимых сочетаниях данных, условий и событий. Для любого допустимого сочетания данных и условий ясно, как выглядит и ведёт себя интерфейс. Например, список может быть пустым, содержать одно значение или тысячу, и мы понимаем, как они выглядят. Это состояния. В каждом состоянии определён перечень допустимых событий, включая действия пользователя, которые влияют на интерфейс, например, значения можно добавлять и удалять, и нам тоже ясно, как это всё работает. Это переходы. Самое интересное и сложное — это то, что переход должен полностью определяться состоянием и событием. Он не может зависеть от истории предыдущих состояний (если только это не буквально переход по истории состояний типа «Назад» или «Анду»). Если переход из некоторого состояния S при событии E зависит от того, попали мы в S из Q или R, то это значит, что нет никакого состояния S, а есть состояния S1 (S после Q) и S2 (S после R), и важно это осознать. Может показаться, что это какая-то заумь и вообще, какая разница. Но если не обращать внимания на это, то в интерфейсе возникают неявные состояния, в которых вид и переходы не определены. Дизайнер-то думает, что рассмотрел состояние S, да вот только это мифическое состояние, а настоящие состояния S1 и S2 он не рассмотрел. При проектировании сложного интерфейса иногда непреднамеренно возникают состояния, из которых невозможно выбраться, или до которых невозможно добраться, или до которых можно добраться только, если сразу пойти по правильному пути. Для дизайнера важно научиться видеть это. Часто бывает, что я спрашиваю, например, «А в этом случае что будет?», и дизайнер только в этот момент понимает, что такой случай вообще существует. Внимательно разбираться с замкнутостью — кропотливая работа. Обычно мы рассматривает разные состояния и переходы в контексте некоторого флоу, то есть пути пользователя. Мы рисуем экраны друг за другом и представляем, как человек проходит между ними. Нам кажется логичным, что после такого-то экрана при таком-то действии появляется сякой-то, и мы не замечаем, что в другом флоу на таком же экране при таком же действии появляется другой экран. Когда мы думаем про этот флоу и смотрим на это глазами пользователя, мы почти всегда думаем о любом состоянии в контексте предыдущих состояний, и не отдаём себе в этом отчёт. В моём примере с автодополнением отдельные решения сначала кажутся нормальным, пока не начинаешь смотреть, какие запутанные состояния и переходы они порождают. Исправление каждой возникающей неприятности создаёт исключение, усложняя систему и добавляя неприятностей: https://ilyabirman.ru/meanwhile/all/ui-completeness-example/ Я приводил примеры вопросов, которые помогают проверить интерфейс, но понятно, что ответы даже на все вопросы сами по себе не гарантируют замкнутость: https://ilyabirman.ru/meanwhile/all/completeness-questions/ О замкнутости следует думать как о математическом качестве. Возьмём такую теорему: «Число 60 делится на все числа». Это легко проверить: на 1 делится, на 2 делится, на 3 делится, на 4 делится. Мне продолжать? Ну на 5 делится, на 6 делится, сколько ещё примеров надо? Какое число ни возьми — на всё делится: 10, 15, 20... Так ведь? Но нет, это ничего не доказывает. Чтобы доказать теорему, нужно искать не удачные примеры в большом количестве, а саму фундаментальную причину, по которой она неизбежно верна. В данном случае такой причины нет. При проектировании интерфейса сложно требовать от дизайнеров рисования полного графа состояний и переходов. Не уверен, что делал такое хоть раз в жизни. Но всё же полезно хотя бы понять, что это такое. Полезен и опыт программирования — оно развивает интуицию на такие вещи. Смотришь на проект интерфейса, и чутьё подсказывает: что-то не то, сейчас найду дыры. И дыры находятся. Вообще, чем больше для описания интерфейса приходится придумывать частных исключений, тем больше возникает подозрений в том, что общее правило плохое или вообще не придумано.