Дизайн

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

Сегодня мы рассмотрим свежую работу исследователей из Tencent, которые сделали прототип ассистента AppAgent для мобильных приложений. Этот ассистент способен учиться взаимодействовать с любыми приложениями, обеспечивая доступ к ним через голосовой интерфейс без необходимости интеграции с API или изменения пользовательского интерфейса. Теперь достаточно сказать: “Эй, банк, переведи 300 рублей Васе за обед на карту Сбера”, и AppAgent самостоятельно откроет ваше любимое банковское приложение, найдет друга и переведет ему деньги. Конечно, возможно пока приложение учится оно отправит не 300, а 3000 рублей и не Васе, а Пете, но прогресс не остановить и такое упрощение работы с девайсами наше будущее. Кстати, в статье утверждается, что на этапе прототипа уже достигнута точность (success rate) порядка 95%.

Добро пожаловать под КАТ за подробностями.

Dance Dance Revolution или «танцевальная революция» — ритм-аркада от Konami, ставшая легендарной танцевальной игрой конца 90-х — начала 2000-х в Японии, Южной Корее, Европе и США. Аркадные автоматы со светомузыкой, ковриком для танцев и зажигательными поп-хитами захватывали торговые центры и игровые залы, собирая вокруг толпы поклонников и зевак. Весёлые, активные и порой стыдные ритм-игры задали тренды для игровой индустрии и домашних консолей, а затем… исчезли с рынка, став частью истории. Вспоминаем расцвет и закат поп-культурного явления Dance Dance Revolution, делимся похожими играми и отвечаем на вопрос, возможна ли танцевальная революция 2.0. 

Друзья, вы уже в курсе, что IOS достигла версии 17, а Android версии 12? Уже более 10 лет как две огромные фирмы мучают людей и совершенно не собираются умнеть.
Начнем с простого действия. Которое на компьютерах называется ESC. Отмена. Или возврат к предыдущему состоянию. Функция та же что и у BACKSPACE, но не в применению к набору текста, а к любому действию, которое захотелось отменить.
Apple упорно лишает пользователей телефонов и планшетов этой функции.

Это явное насилие, ибо понять почему на клавиатуре нет этой кнопки невозможно. Тем более, что на компьютрах Apple она имеется. Но в планшете iPad ее нет.

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

Вот я из "Почты" нырнул в какое-то приложение. И возврат обратно вот такой мизерной незаметной строчкой. < Mail. Попасть в нее пальцем ну мягко говоря не просто. Равно как и разглядеть.

На немецком «эйнштейн» звучит как «один камень». Один - «ein», камень - «Stain». Всем известно, что под этой фамилией жил один замечательный человек, и звали его ... Но в статье речь не о нём. Речь о математической задаче по поиску одной плитки, такой чтобы составленная из неё мозаика была непериодической. «Один камень» - это про плитку. В мозаике Пенроуза таких плиток две, а хотелось бы возможности использовать только одну. Не вдаваясь в детали можно сказать, что задача одной плитки в этом году (2023) решена. Получены интересные красивые мозаики.

Сначала была найдена «шляпа эйнштейна» - плитка, похожая на шляпу. Или, по моему скромному мнению, на рубашку. Из неё можно сделать отличную непериодическую мозаику. Только, для построения используются как сами шляпы, так и их зеркальные отражения. Считать ли это одной плиткой? Можно и не считать.

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

Оказалось, такая мозаика, в которой есть одновременно и шляпы и черепахи, при обмене формой в момент, в котором длина граней становится одинаковой, составлена из плиток полностью одинаковой формы. То есть, существует ещё одна непериодическая мозаика, в которой плитка используется уже без своего зеркального отражения. Плитка, у которой грани модифицированы так, что она позволяет только непереодическое сложение названа «Spectre» (призрак). Задача решена, теперь уже точно.

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

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

В этой небольшой заметке хотелось бы поделиться результатами реализаций нескольких технологий из gamdev-а. В основном коснёмся двух тем. Первая тема - это использование navmesh-ей для нахождения путей в пространстве трёхмерной сцены. Вторая тема - это использование lightmap и lightprob-ов для освещения динамических объектов. По каждой из этих тем обсудим немного теории и то, как всё это можно использовать в браузерном игровом 3d-движке Playcanvas.

Мы уже поговорили об инди-студиях и об играх, которые разработчики создавали в одиночку. В комментариях к последней статье поступило замечание о том, что пропущены целые эпохи – и в их числе эпоха Flash-игр. Спасибо за идею! 

В 1996 году появилась платформа FutureSplash Animator, которая открыла новые возможности для создания игр и анимации. С одной стороны, разработчики получили удобный инструмент; с другой – сделанными ими результатами можно было пользоваться прямо в браузере без необходимости скачивания. Об эволюции Flash вы можете прочесть в этой статье.

Во многом благодаря этой технологии была запущена целая отдельная индустрия “инди-игр”. От самых простых – вроде вирусных Dancing Bush и BaffOtron до таких шедевров, как Crush the Castle (тот же подход переизобрели в Angry Birds), и аркадной Sonny. Разработчики фантазировали, используя Flash для создания абсолютно разных механик – и смена направления гравитации, и управление разными частями тела, и классические платформеры в стиле Prince of Persia. 

Но мы поговорим именно об играх, созданных одним человеком. Не считая, правда, композитора в одном из примеров как второго члена команды. 

Для решения различных задач с использованием современных устройств нужны различные интерфейсы управления. Здесь под интерфейсами будем иметь в виду различные устройства для ввода информации.

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

Инди-команды не имея опыта в программировании собирают целые игры исключительно на нодах, а большие игры-сервисы удерживают исходники проекта в текстовом варианте? В нескольких проектах, с которыми я работал, были инструменты и системы визуального программирования: от древнего, тогда еще самостоятельного Bolt до монстров FlowCanvas/NodeCanvas и BluePrints в Unreal Engine.

После такого разнообразного опыта и раздумий, в сюжетном проекте столкнулся с FlowCanvas, который оказался очень нужен даже мне, как программисту и архитектору. Поработав с ним и интегрировав его в архитектуру проекта, имею вам кое-что сказать за визуальное программирование. В начале - много текста, процессов, методологии и проектирования, но в конце - это приводит к короткой и (надеюсь) понятной реализации. Рассчитываю на вдумчивых читателей и обсуждение в комментариях.

Привет, Хабр! Меня зовут Коля Кремер, уже 4 года я работаю в команде мобильного приложения Маруси, где мы постоянно стараемся сделать так, чтобы с нашим помощником было удобно и интересно общаться. 

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

Казалось бы, простая задача - сверстать список пар ключ-значение. Бери <div> и делай. Но что, если захотелось подушнить? Этим и займёмся в статье...
Рассмотрим три подхода к решению этой задачи: <div>, <dl>, <dt>, и <dd>, и <table>. Обсудим преимущества, недостатки и примеры.
Цель - помочь выбрать наиболее подходящий подход для конкретной задачи.

Привет, Хабр. Меня зовут Алексей, я разрабатываю мобильные приложения на Flutter в Пиробайте. Помимо этого увлекаюсь моушн-дизайном. В прошлый раз рассказывал о том, почему Flutter Web (не) мертв. Сегодня предлагаю продолжить наш тру-крайм в мире разработки и снова узнать кто кого убил, за что убил и убил ли вообще. Наш сегодняшний герой — инструмент для создания анимации Rive. 

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

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

Привет, меня зовут Евгения Береснева, и я старший технический писатель в X5 Tech. Пожалуй, выглядит странным, что технический писатель пишет статью с таким названием. Так что для начала небольшой дисклеймер:

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

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

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

Технические писатели создают текстовые документы, но что если для процесса одного текста мало? Тогда приходится учиться монтировать и делать видеоинструкции.

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

Должно быть интересно!

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

В этой статье мы при помощи CSS и SVG сгенерируем цветной шум, позволяющий добавлять текстуру к градиенту.

Я впервые столкнулся с разработкой для незрячих пользователей в 2008 году, когда принимал участие в разработке программного телефона для контакт-центров, в котором большое число агентов было незрячими. 

Когда один из моих коллег потерял зрение, у меня было 10 лет опыта с технологической точки зрения. По возвращении коллеги на работу моей задачей была подготовка для него отчетов о качестве звука в зависимости от используемых каналов связи, моделей телефонных аппаратов, версий программного обеспечения, вариантов используемых кодеков и массы прочих факторов.

Такую информацию логично было сводить в таблицы. Коллега слушал бы их, получая нужную информацию.

Но, как быстро выяснилось, информация в чистом виде очень плохо воспринимается на слух. Её нужно специально подготавливать, чтобы было кратко и информативно. И даже незначительные изменения в форматировании текста приводят к тому, что он полностью меняется при озвучании скрин-ридерами.

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

Набором этих правил я и хочу поделиться.