Дизайн

Полезно было бы уметь генерировать по текстовому описанию не только картинки, а полноценный 3D-объект, который можно рассмотреть со всех сторон. Это открывает огромные возможности для дизайна, игр, виртуальной реальности. Однако генерация 3D-контента — задача непростая. Современные методы требуют огромных объемов данных для обучения и страдают от несогласованности между разными ракурсами.  

Авторы DiffSplat предлагают подход, который решает эти проблемы элегантно и, что более важно, быстро! Вместо того чтобы создавать 3D-модели с нуля, создатели используют уже предобученные text-to-image модели. И просто «перепрофилируют» их для работы с 3D-гауссовыми сплатами.  

Привет! Я Влад — старший дизайнер в Альфа-Банке, занимаюсь фичами в «Платежах и переводах». Неровно дышу к улучшению внутренних процессов в компании, поэтому часто выступаю с различными инициативами, одна из которых — разработка стандарта оформления макетов для мобильного банка.

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

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

Привет, Хабр. Я Илья Сластен, продуктовый дизайнер интерактивной карты ПГК Диджитал. В своей предыдущей статье я рассмотрел ключевые аспекты работы с локальными переменными в Figma и подход Atomic Design. Сегодня предлагаю поговорить о минимализме в дизайне.

В мире, где цифровая реальность меняется стремительно, а каждый клик важен, создание успешных веб-сайтов и приложений становится задачей, от решения которой зависит многое. Говоря о самых успешных подходах, минимализм в дизайне выходит на передний план. Это не просто эстетический выбор, это философия, которая стремится к ясности, эффективности и функциональности. Как же принцип «меньше — значит больше» помогает нам создавать более удобные и интуитивно понятные интерфейсы? Давайте разберемся.

Привет! Я Илона Арзуманян, лид продуктового дизайна веб-канала в t2 Digital. Сегодня я хочу рассказать про такую крутую командную активность как прожарка. Если вы думаете, что это мероприятие, на котором все друг про друга шутят (и иногда очень даже обидно), то в нашем контексте это не так. Мы называем так активность, в рамках которой мы разбираем по косточкам флоу и интерфейсы других компаний, причем рассматриваем и UX, и UI. Это классно развивает критическое мышление и насмотренность. В этой статье я расскажу зачем это нужно, как мы это делаем и как на это смотрит команда.

Почему прожарка – это круто?

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

Удобный чайник можно определить через такие параметры:

1. Насколько он напрягает руку – какой крутящий момент (нагрузку) создаёт чайник, когда мы его держим на весу ровно и какую, когда наливаем (считаем "ход" такого движения 90 градусов, чтобы вылить полностью воду). У чайников с верхней ручкой (1 и 2) максимально расслаблена рука в первом положении, т.к. центр масс находится прямо под точкой хвата, и максимально напряжена во втором, при наклоне, т.к. центр масс чайника уходит из-под руки. Тем более, кисть должна вывернуться в несвойственное ей положение на запредельные углы под самой большой нагрузкой. У чайников с боковой ручкой (3 и 4) всё наоборот – максимум нагрузки в положении вертикальном и почти полное расслабление при наклоне. При этом рука движется в анатомически привычных углах. Высокая верхняя ручка (2) ещё больше увеличивает нагрузку при наклоне, т.к. эта высота переходит в рычаг нагрузки при наклоне чайника. И у чайников с высокой ручкой самые большие проблемы с углом поворота кисти при наливании. Оптимальной видится ручка, расположенная в середине пути, т.е. точка хвата расположена примерно на 45 градусах к центру масс чайника относительно горизонта.

Структура мини-курса Мини-курс API-интерфейсы для самых маленьких.

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

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

Традиционные подходы к тестированию на многих уровнях уже не успевают за реалиями разработки: ручное тестирование становится слишком трудоёмким, а написание unit- или end-to-end-тестов не всегда позволяет отследить именно визуальные изменения. И здесь на помощь приходит методология скриншотного тестирования — мощный инструмент для выявления визуальных багов, появляющихся в интерфейсе. Он позволяет убедиться в том, что ваш продукт отображается так, как задумано, и избавляет команду от многих сюрпризов.

Каждый день миллионы изображений, видео и аудиофайлов загружаются в интернет. Мы смотрим фильмы, слушаем музыку, листаем соцсети, даже не задумываясь о том, какие алгоритмы стоят за тем, чтобы контент отображался корректно и не повторялся. Но что, если вам нужно сравнивать медиаконтент автоматически? Как понять, одинаковые ли две фотографии, если одна немного темнее? Как сравнить два видео, если они сняты под разными углами? А что делать, если вам нужно найти дубликат аудиофайла, но на одной записи есть шум?

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

Хочешь увеличить качество видео, но ценник у Topaz Video AI вызывает сердечный приступ? Спокойно! Сегодня разберём 5 БЕСПЛАТНЫХ программ, которые помогут улучшить твои видео. И да, результат может удивить! Дочитай до конца, потому что в конце я покажу таблицу, какая из них даёт лучший результат (на примере масштабирования исходного видео в разрешении FullHD 1080х1920 30fps до 4к 30fps). Поехали!

(Сразу хотел бы предупредить - статья длинная, в Word при шрифте = 12 она заняла 28 страниц).

Примечание 1.

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

Примечание 2.

В рамках статьи: Python = Питон, Visual Studio Code = VSCode, Нейросеть = ИИ = AI.

Примечание 3.

В рамках данной статьи считается, что вы не умеете работать: с кодом, GitHub-ом и прочее. Поэтому все действия будут объяснены детально.

В Главе 6 мы узнали о проектировании API, создавая свои собственные. На данный момент у нас есть много с трудом заработанных знаний, и пришло время, чтобы они начали приносить пользу. Мы готовы увидеть, как мы можем заставить API работать на нас. В этой главе мы узнаем четыре способа достижения коммуникации в реальном времени через API.

Структура мини-курса Мини-курс API-интерфейсы для самых маленьких.

Глава 6 знаменует собой поворотный момент в нашем приключении с API. Мы закончили рассматривать основы и теперь готовы увидеть, как предыдущие концепции объединяются, чтобы сформировать API. В этой главе мы обсудим компоненты API, проектируя его.

Недавно разбирал любопытные материалы про замену на атомоходе пультов управления с традиционных на сенсорные. Там персонал взвыл от плохого и непродуманного интерфейса управления силовой установкой и каким-то там важным валом. Раньше для управления этими критическими величинами использовалась приличных таких размеров очень хваткая круглая рукоятка (задатчик), оператор обхватывал её всей ладонью и её поворотом на механическом кольце выставлял нужную величину. Чтобы персоналу было привычнее, на сенсорном экране управление этими величинами сделали тоже круговым – нужно поставить пальчик на экран и двигать по кругу виртуальную ручку. Пальчиком по кругу. На корабле. Вы всё правильно поняли. Кстати, при использовании традиционных (не сенсорных) задатчика и средств отображения информации вероятность безошибочного решения оператором этой задачи составляла 0,992. Для сенсорных панелей такие исследования не проводились (почему бы это, а?).

Привет, Хабр! На связи UX-редакция ecom.tech. Наша команда занимается созданием текстов для интерфейса Самоката. Мы помогаем поддерживать голос бренда, делаем приложение и сайт удобным и понятным для пользователя. В этой статье расскажем, как сделать сайт понятным, писать просто о сложном и не раздражать пользователей текстами. Рассказываем всё на примере сайта Самоката.

Вы читаете приквел, к моему предыдущему лонгриду на VC «Как за 5 недель я написал свою программу вообще без опыта программирования». Говорят, зашло нормально. Но в лучших традициях жанра — читать можно в любом порядке.

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

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

Множество хороших идей пришло в похожих ситуациях...

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

Привет, Хабр! Меня зовут Артём, и я 3D-моделлер, который много лет работает в 3ds Max. Недавно я решил освоить Unreal Engine через создание пет-проектов, и результатом стала игра Run Eternal Depths — roguelike с процедурной генерацией подземелий, которая уже доступна для добавления в вишлист в Steam. Релиз запланирован на 21 марта, и в этой статье я расскажу о технических аспектах разработки, включая мою реализацию генерации подземелий.

1. Идея и начало разработки

Изначально Run Eternal Depths задумывалась как тестовый проект для экспериментов с процедурной генерацией подземелий. Мне нужно было реализовать эту механику для другого проекта, но я решил сделать это в чистом проекте, чтобы не рисковать основным. Со временем идея переросла в полноценный roguelike с упором на исследование подземелий.

2. Технические аспекты разработки

Движок и инструменты

В Главе 4 мы упомянули, что большинство веб-сайтов используют имя пользователя и пароль для аутентификации учетных данных. Мы также обсудили, что повторное использование этих учетных данных для доступа к API небезопасно, поэтому API часто требуют другой набор учетных данных, нежели те, которые используются для входа на веб-сайт. Распространенным примером являются ключи API. В этой главе мы рассмотрим другое решение — открытую авторизацию (OAuth), которая становится наиболее широко используемой схемой аутентификации в Интернете.

В нашем понимании API все начинает проясняться. Мы знаем, кто такие клиент и сервер, мы знаем, что они используют HTTP для общения друг с другом, и мы знаем, что они используют в определенные форматы данных, чтобы понимать друг друга. Однако знание того, как общаться, оставляет важный вопрос: как сервер узнает, что клиент — тот, за кого себя выдает? В этой главе мы рассмотрим два способа, которыми клиент может доказать свою идентичность серверу.

Глава 3: Типы и форматы API

До сих пор мы узнали, что HTTP (протокол передачи гипертекста) (Hyper-Text Transfer Protocol) является основой API в сети и что для их использования нам нужно знать, как работает HTTP. В этой главе мы рассмотрим данные, предоставляемые API, как они форматируются и как HTTP делает это возможным.