Adobe assets что это
С каждым годом условия для разработчиков становятся всё лучше и лучше: появляется много движков и инструментов, изобретаются и становятся общедоступными новые техники, количество уроков просто зашкаливает.
Тоже самое происходит и с ассетами: с каждым годом их становится всё больше и больше на любой вкус. Более того, появились даже генераторы ассетов с очень мягкой лицензией!
Но за лёгкостью идут и последствия: игр из готовых ассетов стало настолько много, что к их использованию относятся крайне негативно, обвиняя разработчиков в поиске наилегчайшего пути и отсутствии авторского видения.
Стоит ли их использовать? Как? И где их брать? Узнаете в этом материале.
Ассет (asset) — это набор ресурсов, которые вы можете использовать в своей игре. Потенциально в эту категорию может входить всё что угодно, но обычно под ними имеются в виду готовые программные модули, спрайты, модели, анимации, звуки.
Чаще всего такие наборы объединены какой-то конкретной областью применения, например одна модель с множеством анимаций, система инвентаря, набор спрайтов в схожем стиле. Но это может быть и не так.
Готовые ассеты — это такие наборы, которые лежат в готовом виде в сети и вы можете их приобрести на каких-то условиях и использовать. Впрочем, это можете сделать не только вы, но и все остальные.
Стоит заметить, что готовые ассеты — это не только сделанная за вас работа, но и сделанная качественно. В отличии от фрилансеров, которые делают ассеты на заказ, а потому не стопроцентно гарантируют их готовность и качество, готовые ассеты уже подготовлены не просто к единичному, но к массовому использованию, уже многократно протестированы и наверняка исправлены. А сам тот факт, что автор не побоялся выставить их на всеобщее обозрение, да ещё и за фиксированную цену, уже о многом говорит о его уверенности в себе как в специалисте.
Помимо платных ассетов есть ещё и огромное количество бесплатных ассетов, которые вы можете установить и протестировать прямо сейчас. Их качество никто не гарантирует, но перебором из нескольких вариантов можно быстро найти то, что надо.
Готовые ассеты можно использовать не только напрямую, но и косвенно: использовать в качестве референсов, а ещё изучение внутренностей ассетов может многому вас научить. Впрочем, это уже совсем хардкорный способ обучения.
Почти у всех готовых ассетов указана лицензия. За платные ассеты придётся заплатить. За бесплатные ассеты нужно будет указывать авторство, если не указано обратное. Поэтому конечно мало что вам достанется бесплатно.
Но есть исключение — лицензия Creative Commons, по которой ассеты могут распространяться бесплатно. В мире очень много апологетов свободных ресурсов, набивающих руку начинающих специалистов и просто добрых людей, которые готовы распространять свои работы по этой лицензии. Отдельно стоит упомянуть лицензию CC0 — "Никаких прав не предусмотрено", то есть вы можете делать с этими работами всё что угодно и как угодно.
Чаще всего ассеты представлены в удобном автору виде, а не в виде, удобному вам. Поэтому ассеты придётся адаптировать под свой проект и расширять, будьте к этому готовы. Да, это всё ещё проще, чем делать самому с нуля, но навык приобрести придётся.
Помимо вышеназванных ограничений, есть и прямые недостатки, которые будут тянуть общее качество вашей игры на дно, и с этим стоит считаться.
Прежде всего, стоит упомянуть уникальность. Если кто-то использует тот же готовый ассет, что и у вас в игре, или же тем более вы используете ассет, который был в другой игре — это сразу уронит тень недоверия на вас обоих. Никто не будет разбираться, откуда вы это взяли и имели ли вы право использовать эти ассеты, люди просто рассмеются и пойдут дальше, а вашу игру будут менее серьёзно воспринимать.
Ну и самое главное — отсутствие авторского замысла. Готовые ассеты сделаны не для вашей игры, у всех них наверняка разный стиль. Если объединить их в одну игру, не приводя к общему виду, у игроков возникнет чувство негармоничности, что будет только отталкивать.
Во-первых, чем меньше вы используете ассетов, тем лучше. Дело даже не в том, что вы выбрали простую дорожку и это нехорошо. Просто чем меньше ассетов вы используете, тем меньше стилистических расхождений между ними. Лучше подбирать большие наборы.
Во-вторых, потратьте время на перебор ассетов. Хорошо проверьте, подходит ли он вам. Если подходит не очень — лучше подобрать другой. В будущем это окупится.
В-третьих, проверяйте лицензию перед использованием. И не скачивайте ничего с торрентов.
В-четвёртых, если у вас есть такая возможность — будьте готовы выделить время для адаптации ассетов под свои нужды. Изучите для этого необходимое ПО.
Ассеты можно делать и своими руками. И если это не касается программного кода, то зачастую для этого не нужно особых навыков, только лишь авторское видение.
В последнее время в сети появляется много генераторов, особенно на основе нейронных сетей. Технологии поражают! Вы можете использовать поисковики для того, чтобы их найти, например с помощью запросов «sound generator» или «planet generator». Не для всего есть варианты, но выбор есть.
Если генератора нет, всё ещё можно использовать старые добрые фильтры. Для картинок это различные визуальные эффекты, которых полно в Photoshop. Для звуков это аудио-эффекты, которых полно в Audacity. Модели можно пересобрать использовать различные инструменты в Blender.
Но это очень тёмный и неосторожный путь. Переделанный ассет должен кардинально отличаться от исходника, чтобы вы могли его свободно использовать на правах производного произведения. Иначе же лицензии вам не избежать. Поэтому лучше использовать чужие работы как референс и пытаться их воспроизвести вручную.
В поисковике! В сети есть буквально десятки магазинов ассетов с десятком тысяч ассетов каждый. А ещё есть подборки магазинов ассетов, написанные уже без меня, вот например такая.
Вы также можете обратиться в поисковик с запросом «редактор аудио/изображений/моделей» или «model/art/audio editor», есть много опций, доступных прямо в браузере. И помните про генераторы! Ищите, обязательно ищите, это не так сложно, как кажется.
Модернизация любого сайта похожа на плавание в незнакомых водах — никогда не знаешь, на какие подводные рифы натолкнешься. А что, если ваш сайт — это большая запутанная система, состоящая из множества каналов, каждый из которых ещё и построен на своем стеке технологий? Можно не только выбрать неправильный курс, но и утонуть, пытаясь разобраться во всех особенностях функционирования сайта заказчиков.
В сегодняшней статье мы бы хотели поделиться опытом успешной модернизации с помощью Аdobe Experience Manager и рассказать, как применить данное решение для мультиканального сайта.
Читать далее
Помимо вышеперечисленных моментов, хотелось бы отметить и тот факт, что каждый канал обновляемого нами сайта жил своей собственной жизнью. Подобная «независимость» приводила к тому, что внесение даже простейших изменений требовало участия разработчиков. Простое обновление вроде одновременной загрузки нового логотипа для всех каналов становилось довольно сложной процедурой в плане координации билдов и деплойментов в момент тестирования. Сложность добавления новых бизнесов и поддержки существующих, а также отсутствие поддержки мобильных устройств и планшетов (что в наше время уже довольно критично) и проблемы с локализацией и стали причиной того, что заказчик обратился к нам за оптимизацией сайта.
Почему Adobe Experience Manager?
Данное решение обладает теми возможностями, которые идеально подходят для оптимизации мультиканального сайта. Прежде всего, это высокий уровень многократного использования базовых компонент и секций (как back-end, так и front-end), что в нашем случае крайне важно, так как их можно оптимизировать под новые каналы, доработав недостающую функциональность, и тем самым сократить время и усилия. Второй момент — поддержка интернационализации и локализации из коробки, что значительно упрощает разработку, поскольку у заказчиков есть планы по расширению бизнеса на другие страны. AEM — это также content management и experience management система, которая обладает большой гибкостью в управлением тем, что мы видим на сайте. Среди прочего, это редактирование контента: возможность разбиения функциональности на модули и управления ими без привлечения программистов и написания кода, создание back-end логики благодаря технологии OSGi, масштабирование и персонализация контента.
Модернизация: что использовали, что сделали и почему
Как уже понятно из текста выше, за основу мы взяли технологию Adobe Experience Manager благодаря ее возможностям и удобству для администраторов. Разумеется, использования одной этой технологии было недостаточно. На основе Bootstrap мы переработали статический шаблон сайта, добавив back-end часть и бизнес-логику (появилась адаптивная верстка, в том числе для мобильных устройств, использовался HTML 5, в общем, добавили все плюшки, свойственные современным сайтам). Также мы доработали функциональность и оптимизировали производительность под разные виды устройств, добавили дополнительные архитектурные решения по масштабируемости приложения через добавление облачных сервисов.
Поскольку многие направления бизнеса заказчика сходны между собой, было принято решение создать компоненты для многократного использования. Зачем каждый раз разрабатывать новую компоненту для другого канала, если по сути она одна и та же, просто иначе сконфигурирована (разный текст или способ отправки данных на сервис)? Для различных бизнес-кейсов мы настроили базовые и специфичные опции для компонент, что упростило их использование в сходных случаях. Благодаря подобному решению добавление новой функциональности и интеграция сервиса стали гораздо прозрачнее. Конечно, небольшие обновления на back-end необходимы, чтобы научить сервис понимать новое поле, но сам front-end стал намного проще. Теперь, чтобы добавить новую функциональность, необходимо зайти через редактор, совершить необходимые манипуляции по конфигурации компоненты в зависимости от ее назначения и результатов smoke-тестирования, и опубликовать страницу.
Сложность была не только в том, чтобы создать компоненты, пригодные для многократного использования, но и в том, чтобы разработать фреймворк, позволяющий добавлять все эти компоненты на страницу, и реализовать определенную логику взаимодействия между ними. Например, на одном из каналов сайта нам необходимо было настроить следующую логику: при выборе различных видов жилой собственности, пользователю должны задаваться определенные виды вопросов. То есть, если пользователь выбирает, что он живет в многоквартирном доме, должен задаваться вопрос, на каком же этаже он живет. Следовательно, если он проживает в частном доме, то такой вопрос для него нерелевантен.
Как мы это сделали? Для реализации подобной функциональности, взаимодействия между компонентами и сохранения и отправки на сервис, мы интегрировали возможности Adobe Experience Manager и Angular.js. Например, для управления логикой отображения у каждой компоненты, используещейся в АЕМ, есть поле в конфигурации, которое называется visibility. Это поле определяет, будет ли видна компонента пользователям или нет. Стоит признать, что поле не самое удобное в применении, но благодаря ему можно использовать не чистый JavaScript для написания каких-то функций, а интегрировать компоненту в эко-систему Angular. Примером здесь может послужить выражение user.answers.dateOfBirth > 01-01-1970, выполняющее валидацию по дате рождения, которое подставляется в ng-if директиву, оборачивающую заданный компонент. Благодаря наличию two-way binding в Angular внесение изменений в какое-либо поле не остается незамеченным, так как все они объединены в единое целое. После внесения изменений происходит пересчет, должны ли мы теперь показывать данное поле или нет.
Что ещё интересного использовалось?
Ещё одно любопытное решение, которое мы применили, — это отделение схемы хранения данных на front-end от схемы отправки на back-end. Поскольку сайт заказчика во многом состоит из форм для заполнения, мы сделали так, что ответы пользователя сохраняются в local storage (функциональность HTML5) в формате JSON. Далее происходит разделение данных, предназначенных для front-end и back-end, и отправка последних на АЕМ для последующей трансформации. Преобразование входящих данных в схему сервиса происходит на уровне интеграции front-end части с REST-сервисами, которые и занимаются поиском подходящих услуг для пользователей сайта. Таким же образом мы совершаем преобразование данных и в обратную сторону: если пользователь залогинен и хочет выбрать что-то из уже заполненных данных, то опять происходит трансформация данных, которые предоставляет REST-сервис, в формат данных, используемых на front-end. Чтобы этого добиться, мы каждую интеграцию с сервисом (например, отправку данных на сервис, занимающийся поиском наиболее подходящих продуктов в базе ), описали в соответствующем формате и сохранили в АЕМ-репозитории в виде структурных нод.
Описание трансформации в виде нод в репозитории Мы берем выходной JSON, который будет использоваться для отправки на сервис, и описываем его в том же формате, в котором должен быть исходящий JSON, т.е. структура нод в репозитории повторяет структуру JSON-документа. Каждая нода может быть просто использованием одного из значений из входящего JSON. В случае какой-то более сложной логики, мы можем использовать server-side JS для трансформации входного JSON в выходной. К примеру, мы знаем, что в JS-файле, который находится под нодой, есть функция transform, которая должна вернуть выходящие данные. Если требуемое поле не пусто и определено, то мы его возвращаем. Если же оно пусто, то мы возвращаем заранее заданное значение — единицу. Это пример несложного преобразования данных из одного формата в другой с использованием JavaScript. Исполнение скриптов, лежащих в репозитории и описывающих трансформацию входных данных в выходные, выполняется JS-движком Rhino, полностью написанным на Java.Возможности по персонализации
АЕМ хорош тем, что предоставляет отличные возможности для персонализации контента. В нашем случае, мы воспользовались модулем, который поставляется из коробки вместе с фреймворком, оптимизировали его под себя, создав дополнительные сегменты пользователей к уже существующим. Что получилось в итоге? Главная страница канала стала персонализированной, имеет приветствие и отображает историю запросов пользователя. В случае, если пользователь выйдет из аккаунта, страница все ещё будет помнить имя пользователя, но уже предложит залогиниться. Если же пользователь будет настаивать, что система ошибается, и это совсем не он/она, то им будет предложено использовать сайт в качестве анонимного пользователя, и в данном случае будет показываться совершенно другой контент. В принципе, на все типы пользователей можно настроить различный контент, вплоть до удаления приветствия и замены его на какую-то другую компоненту. Для этого нужно создать новый компонент, а администраторам сайта сконфигурировать его, то есть выбрать правила из заранее доступного набора, в каком случае этот компонент должен показываться.
Однако не все так просто, как выглядит…
Первый канал сайта мы разрабатывали примерно год до первого live-выпуска. В пике работало пять команд по десять человек, которые писали непосредственно фреймворк по интеграции с сервисами и по построению архитектуры компонент, интеграции между ними, по трансформации сервисов и т.д. плюс занимались нефункциональными сервисами и оптимизацией производительности сайта. Второй канал удалось обновить приблизительно за полгода, и вторичное использование компонент составило порядка 60-70%, что очень много.
Сейчас над проектом работает три команды по десять человек, которые дорабатывают функциональность в соответствии с бизнес-требованиями, обновлениями, пожеланиями по улучшению компонент, а также работают над архитектурными проблемами, возникающими по ходу создания новых компонент.
Сама архитектура сайта представляет собой пассивный кластеринг, и в данный момент у нас три сервера приложений, которые служат для обработки запросов пользователей. Однако все построено таким образом, что в случае каких-либо проблем с производительностью, мы можем довольного легко и быстро начать горизонтальное масштабирование системы. С помощью скриптов развертывания, через Vagrant/Docker и Amazon Cloud мы можем поднять виртуальную машину, установить АЕМ и развернуть на ней последние исходники нашего сайта, добавив ее во всю эко-систему приложения.
Что касается производительности, в особенности на мобильных устройствах, то поскольку мы использовали Angular, легко было уйти в непроизводительное приложение с большим потреблением процессора на клиенте. В данном случае нам помогла оптимизация структуры HTML, использование one-way binding для уменьшения количества watcher-функций на Angular и переписка некоторых Angular-директив.
Для оптимизации производительности самого сайта применяется высокий уровень кэширования данных. Большая часть контента, которую видят пользователи, является статической информацией, которую выдает веб-сервер — мы значительно снизили количество обращений к серверу приложения. Это обуславливается best practices работы с АЕМ, так как в большинстве проектов есть диспатчер, который служит для кэширования статической информации. В идеале, запрос на сервер приложения должен доходить только в случае, если поменялись данные на самом сервере или сайте либо туда выкатился новый код.
Также очень много улучшений мы сделали, чтобы добиться высокой Google page score статистики. Чтобы по максимуму использовать кэш браузера, мы оптимизировали количество запросов на сайт через конкатенацию JS, CSS и т.д., объединение картинок в спрайты, SVG-подходы, fingerprinting-функциональность. Это, конечно, не что-то сверхестественное, но забывать об этом тоже не стоит.
Заказчикам в любом случае нужна ваша помощь
Не смотря на все плюсы AEM, заказчикам в любом случае нужна ваша помощь в разработке компонент, необходимых специально для какого-то конкретного направления, либо описание каких-то экзотических сценариев вроде добавления нового сегмента пользователей и т.д.
Разумеется, технически здесь есть ещё поле для развития: можно бесконечно упрощать JavaScript, создавать новые high-level функции, которые заказчики смогут использовать в дальнейшем, и многое другое.
Нас ещё ожидает разработка новых компонентов для других каналов сайта, решение архитектурных проблем, перепроектирование компонент и остальные интересные задачи. Однако благодаря уже имеющемуся опыту с АЕМ, обновление оставшихся каналов — дело времени. И тем приятнее осознавать, что благодаря этому решению мы даем довольно большую гибкость нашим заказчикам — на основе того, что мы уже сделали, они могут, как из кирпичиков, строить новые бизнесы. И это здорово.
В июне 2014 года была написана статья, посвященная прекрасному инструменту для извлечения кода из PSD-макета - проекту компании Adobe под названием Project Parfait. Это был бесплатный online-инструмент, цель которого состояла в создании процесса преобразования PSD-макетов в код для команд разработчиков, использующих Photoshop как основной инструмент при создании различных дизайнов.
Компания Adobe произвела реинкарнацию проекта Project Parfait, добавив в него поддержку бесплатного дискового пространства и сервиса обмена Creative Cloud Assets, а также переименовав его в Extract:
Проект Extract сохранил всю существующую функциональность Project Parfait, а интеграция с CC Files наряду с новой возможностью обмена файлами позволила улучшить и ускорить взаимодействие между веб-дизайнерами и веб-разработчиками.
Ниже представлен пример работы в Extract.
Загрузка или синхронизация файлов
Загрузить файлы на сервер можно двумя способами. Первый способ заключается в использовании web-интерфейса , доступного через любой web-браузер. Второй способ основан на использовании специального desktop-приложения, с помощью которого можно автоматически синхронизировать файлы на локальном компьютере с файлами в облачном сервисе Creative Cloud:
Второй способ является наиболее простым и надежным, поэтому в дальнейших шагах этой статьи будет использоваться именно этот способ.
Первым делом, необходимо скачать приложение и установить его в системе, а затем авторизоваться в нем с помощью личного Adobe ID. Открыв приложение, необходимо в нем перейти на вкладку Assets, а внутри этой вкладки перейти в еще одну вкладку Files. Должно получиться примерно следующее:
В этом окне опускаемся вниз и нажимаем кнопку Open Folder, что приведет к автоматическому открытию папки Creative Cloud Files на локальном компьютере. Находясь внутри этой папки, необходимо скопировать PSD-файл из другого источника сюда, что автоматически запустит синхронизацию с облачным пространством Creative Cloud.
Когда операция загрузки на сервер Creative Cloud будет успешно завершена, на миниатюре PSD-файла появиться маленькая зеленая галочка, как в данном случае:
Если теперь снова вернуться назад, в web-интерфейс Creative Cloud, то обнаружим там миниатюру только что загруженного PSD-файла, готового для открытия в Extract:
Работа в Extract
Для того, чтобы открыть загруженный в Creative Cloud файл Photoshop, нужно щелкнуть мышью по миниатюре этого файла, затем снова щелкнуть мышью на этот раз по вкладке Extract (на изображении ниже она помечена как Preview). PSD-файл тотчас же отобразится в окне приложения Extract, готовый для извлечения из него CSS-кода:
Процесс извлечения кода из PSD-файла в Extract остался неизменным, каким он был в приложении Project Parfait, о чем было подробно описано в предыдущей статье "Конвертирование файлов Photoshop с помощью Project Parfait". Однако, с того момента в Extract были добавлены несколько новых возможностей, которые будут рассмотрены ниже.
Новые возможности Extract
Некоторые из новых возможностей приложения Extract были унаследованы им от Project Parfait спустя некоторое время после опубликования ранее упоминавшейся статьи-обзора "Конвертирование файлов Photoshop с помощью Project Parfait". Другие же новшества появились в Extract благодаря его интеграции с сервисом Creative Cloud.
Прозрачность тени
Ранее тени на CSS генерировались без поддержки прозрачности, значениями в формате HEX. Теперь имеется поддержка прозрачности теней в сгенерированном CSS-коде, значениями в формате RGBA:
Настройки шрифта
Теперь нет необходимости работать только с пикселями (px) в качестве размера шрифтов в сгенерированном CSS-коде. В Extract добавлена поддержка единиц измерения em и rem для шрифтов:
Также добавлена возможность установки базового шрифта для всей страницы в целом. Размеры шрифтов всех остальных элементов страницы будут расчитываться на основе этого базового размера, в тех единицах измерения ( em или rem ), которые были выбраны ранее:
Препроцессоры и миксины
В Extract была добавлена поддержка препроцессоров Sass(SCSS) и LESS совместно с библиотеками миксинов для этих препроцессоров. Таким образом, теперь можно выбрать - генерировать код не в чистом CSS, а в SCSS + Bourbon или LESS + LESSHat . Такая возможность дает большие преимущества для тех веб-разработчиков, которые используют какой-либо из этих препроцессоров:
Я надеюсь, что в дальнейшем в Extract будет добавлена поддержка препроцессора Stylus (поклонником которого являюсь), совместно с библиотеками миксинов под этот препроцессор - Nib и Kuoto Swiss . Этого было бы более чем достаточно в плане поддержки препроцессоров в Extract.
Примечание переводчика: на момент перевода данной статьи в Extract добавлена поддержка препроцессора Stylus и его библиотеки миксинов Nib ; поддержка библиотеки Kuoto Swiss отсутствует; помимо этого, добавлена поддержка супер-популярной библиотеки Compass под препроцессор Sass .
Действия
В результате интеграции сервиса Creative Cloud в Extract добавилось новое меню Actions, в котором можно выбрать действия над редактируемым PSD-файлом: скачать файл, переименовать файл, архивировать файл или переместить файл:
Общий доступ
Также благодаря интеграции Creative Cloud в Extract появилась возможность предоставления общего доступа к файлам с помощью меню Share, откуда можно выложить выполненную работу прямо в своем портфолио на Behance.
Веб-разработчику даже нет необходимости иметь учетную запись в Creative Cloud для того, чтобы пользоваться инструментом Extract. Это означает, что любой из членов команды разработчиков, который специализируется на создании кода, теперь совсем не обязан иметь дело с такими программами для рисования графики, как Photoshop:
Timeline
Приложение Extract абсолютно бесплатно для использования. Проект Project Parfait все еще остается доступным вплоть до октября 2014 года, с целью предоставить достаточно времени всем разработчикам, использующим его, чтобы своевременно перейти на проект Extract.
У вас нет никакой необходимости быть платным подписчиком, чтобы иметь возможность использовать приложение Extract; поэтому, даже если вы являетесь платным подписчиком программы Photoshop, вы можете свободно отправлять свои дизайнерские наработки другим веб-разработчикам для кодинга. С другой стороны, веб-разработчик, который получил от вас ссылку на вашу наработку, совсем необязательно должен быть платным подписчиком, чтобы открыть эту ссылку. И даже больше - этот разработчик может вообще не иметь учетной записи в Creative Cloud, чтобы пользоваться приложением Extract.
Я приглашаю всех читателей этой статьи воспользоваться сервисом Adobe Extract и высказать свои пожелания по поводу использования этого ресурса.
Сегодня мы с Вами поговорим о замечательном инструменте в арсенале Adobe Muse –папке Assets.
При создании сайта Adobe Muse генерирует несколько папок при экспорте в HTML, среди которых такие знакомые нам: image, css и scripts. Дело все в том, что поместить в эту папку файл возможно только уже после экспорта в HTML…
Это не позволяет нам работать с этим файлом в самом проекте Muse, а нам иногда это очень даже необходимо. Особенно это актуально для виджетов, ведь в нем часто приходится ссылается на различные файлы. Для этих целей и существует возможность помещать файлы в папку Assets.
Assets – это единственная папка, в которую возможно поместить нужные файлы и мы сможем на них указать относительный путь.
Для того, чтоб поместить файл в эту папку необходимо зайти в:
Меню -> Файл -> Добавить файл для передачи -> Выбираем нужный файл.
Теперь файл уже доступен в нашем проекте для использования. Его мы можем увидеть в панели инструментов во вкладке ресурсы и при необходимости переподвязать файл, или удалить, если Вы передумали его помещать.
Чем же эта папка так важна для виджетов? В коде виджета часто приходится ссылается на различные файлы для их последующего отображения, или использования в виджете. Этими файлами чаще всего бывают таблицы стилей css, файлы и библиотеки скриптов js.
Давайте разберем сразу на примере как это будет выглядеть:
Допустим Вам в бекграунд какого-то элемента не обходимо поместить картинку image.jpg. Делаем следующие действия:
-> Файл -> Добавить файл для передачи -> поместить image.jpg
Теперь мы можем сослаться на этот файл для отображения в бекграунде и это будет выглядеть следующим образом:
В результате image.jpg будет отображен как бекграунд элемента someID и будет видна при предпросмотре сайта в браузере.
Если же Вам необходимо указать путь к скрипту, то в этом случае это будет выглядеть следующим образом:
Подобные ссылки пишутся в теле самого виджета и тогда виджет сможет прочитать этот файл и отобразить в предпросмотре и при генерации HTML версти сайта.
Следует отметить, что очень часто в самих файлах которые нужно добавить существуют ссылки на другие файлы и в случае их наличия эти ссылки необходимо изменить на ссылку в папку assets, куда вы этот файл в последствии поместите.
Читайте также: