Упростите передачу от эскиза к коду Visual Studio с помощью Indigo.Design
Опубликовано: 2022-03-10(Это спонсируемая статья.) Если подумать, команды программистов очень похожи на спортивные команды. Хотя каждый член команды работает для достижения одной и той же цели, роль, которую они играют, и действия, которые они предпринимают, сильно отличаются друг от друга.
Вот почему так важно иметь плавный способ передачи мяча от одного члена команды к другому.
К сожалению, передача функций, происходящая в командах разработчиков программного обеспечения, не так гладка, как в спорте. И одна из основных причин этого — разные системы и подходы, используемые для создания продуктов.
Дизайнеры создают в Sketch идеальные до пикселя пользовательские интерфейсы только для того, чтобы перевести их на язык, который разработчики могут использовать при создании приложений в Visual Studio Code IDE. Без беспрепятственного перемещения дизайна продукта по конвейеру такая неэффективность приводит к дорогостоящим доработкам и отладке после того, как приложение было передано от дизайнера к разработчику.
Излишне говорить, что решение проблемы переключения между Sketch и IDE появилось уже давно. Дело не в том, что команды разработчиков программного обеспечения не знают, как сотрудничать или хорошо общаться друг с другом. Просто их разрозненные системы и стратегии делают переход от одной команды к другой неуклюжим, трудоемким и полным ошибок.
Сегодня мы рассмотрим, почему это происходит и как ваше агентство может решить проблему с помощью двух плагинов и облачной платформы для прототипирования от Indigo.Design.
Где происходит сбой при передаче функций между дизайнером и разработчиком?
Во-первых, что мы действительно должны спросить:
Почему передача дизайнера-разработчика такая проблема?
Ник Бабич недавно писал о том, как дизайнеры идут на многое, чтобы создавать цифровые решения, которые идеально взвешены и последовательно создаются. Но дизайн-системы не могут быть плавно переведены в системы разработки.
Чем больше дизайнер делает с интерфейсом, тем больше ему приходится общаться с разработчиком. Таким образом, недостаточно передать файл дизайна Sketch и предоставить разработчику возможность работать с ним. Дизайнеры должны предоставить спецификации дизайна, которые объясняют, как все движущиеся части должны располагаться, располагаться на расстоянии друг от друга, стилизоваться, окрашиваться, задействоваться и так далее.
Это был единственный способ гарантировать, что приложение в конечном итоге будет идеальным до пикселя. Даже в этом случае от разработчика все еще требуется большая реализация, когда он находится внутри своей IDE.
Как вы понимаете, весь этот процесс занимает у дизайнера много времени. Но без спецификаций дизайна разработчикам приходится играть в рискованную игру в угадайку.
Мало того, разработчики обычно не имеют привычки кодировать с помощью HTML и CSS, что является утомительной работой и представляет собой только пользовательский интерфейс. За кулисами существует гораздо больше кода, который заставляет веб-приложение работать, и не все разработчики умеют или заинтересованы в обучении написанию разметки пользовательского интерфейса. Когда они вынуждены занимать эту позицию, крутая кривая обучения увеличивает время проектов, а возникающие в результате доработки и отладка приводят к тому, что затраты выходят из-под контроля.
Так что, действительно, передача дизайнера-разработчика стала вопросом чьего времени мы можем позволить себе тратить впустую?
“
Это дизайнер должен все переделать, чтобы разработчик знал, как воплотить дизайн в жизнь?
Или:
Это разработчик, который должен смотреть на дизайн, вручную измерять все на экране и надеяться, что он правильно усвоит все спецификации, просто взглянув на него?
Ни в том, ни в другом случае никто не выигрывает. И в процессе вы будете съедать свою прибыль.
Могут быть некоторые агентства, которые считают, что заставить дизайнеров и разработчиков работать на одной платформе — лучшее решение. Таким образом, нет необходимости выполнять весь этот перевод или интерпретацию во время передачи от Sketch к Visual Studio Code. Но это часто приводит к подавлению творчества со стороны дизайнера или затруднению способности создавать эффективные программные решения со стороны разработчика.
Итак, каков ответ?
Улучшите передачу дизайнера-разработчика с помощью Indigo.Design
Не то чтобы Indigo.Design — первая платформа, пытающаяся решить проблемы с передачей прав командам разработчиков. InVision и Zeplin предложили свои собственные решения.
Каждая из этих платформ сделала визуальные спецификации более доступными для разработчиков и, следовательно, повысила эффективность команд дизайнеров и разработчиков. Конкретно:
- Дизайнерам больше не нужно размечать пользовательский интерфейс, поскольку платформы обрабатывают красные линии.
- Разработчики могут вручную извлекать спецификации дизайна без помощи дизайнеров.
Тем не менее, с такими платформами, как InVision и Zeplin, разработчикам по-прежнему приходится проверять каждый элемент и вручную кодировать его на основе извлеченных спецификаций. Этим платформам также еще предстоит создать плавный мост между Sketch и Visual Studio Code.
Итак, если дизайнеры и разработчики хотят максимально эффективно работать друг с другом, Indigo.Design разработал решение их проблемы:
Шаг 1: Дизайн в Sketch
В действительности есть только одна вещь на этом этапе, которая должна измениться для дизайнера. Приложение, страницы и поток по-прежнему будут разрабатываться в Sketch, как обычно, с использованием компонентов из набора пользовательского интерфейса Indigo.Design.
Однако больше нет необходимости составлять пометки или спецификации для приложения. Indigo.Design позаботится об этом за вас.
Чтобы использовать это, ваш дизайнер должен отказаться от любой системы прототипирования, которую он использовал раньше. Благодаря этой новой оптимизированной и безошибочной системе ваш дизайнер может легко перенести свои проекты в облако с помощью плагина Indigo.Design.
Доступ к этому можно получить в Plugins menu > Indigo.Design > Publish Prototype
:
Дизайнеру не нужно экспортировать файлы и загружать их в другую систему для просмотра клиентами или для работы с разработчиками. Они остаются там, где они должны опубликовать прототип.
Для завершения процесса также требуется всего около минуты. Затем дизайнеру предоставляется ссылка на облако, которой он может поделиться с клиентами и другими пользователями, чтобы просмотреть и прокомментировать прототип.
Шаг 2. Работа в облаке Indigo.Design
Подключить других к облаку легко. Предоставленная ссылка перенесет их в облако опыта, где можно просмотреть дизайн:
Также легко оставлять комментарии поверх дизайна. Все, что нужно сделать пользователям, — это открыть панель «Комментарии», поставить булавку и прикрепить к ней свой комментарий:
Однако в этом программном обеспечении для совместной работы есть нечто большее. Прототип также можно редактировать из облака.
Чтобы получить к нему доступ, дизайнер, разработчик и любой другой пользователь с групповым доступом найдет проект в библиотеке прототипов:
Нажмите «Редактировать прототип», чтобы войти в редактор Indigo.Design:
После выбора экрана дизайнер может добавить точку доступа для создания нового взаимодействия в приложении.
Вы также можете использовать редактор Indigo.Design для проверки спецификаций пользовательского интерфейса приложения:
Наведение курсора на элемент показывает характеристики относительного интервала. При нажатии на элемент открывается гораздо больше деталей:
Разработчик также может редактировать или копировать чисто написанный и выведенный CSS с этой панели. (Хотя они и не должны этого делать, как я объясню в следующем шаге.)
Понимаете, что я имею в виду, говоря об экономии времени дизайнеров при создании спецификаций? Если просто отправить этот дизайн в облако Indigo.Design, спецификации будут сгенерированы автоматически.
Шаг 3. Сборка в коде Visual Studio
Теперь предположим, что ваш дизайн достаточно хорош для разработки. Перенос прототипа Indigo.Design в Visual Studio Code так же прост, как переход из Sketch.
Получите исходную ссылку на облако, предоставленную плагином Indigo.Design в Sketch. Если у вас его больше нет, это нормально. Вы можете получить его на экране библиотек в Indigo.Design:
Все, что нужно сделать разработчику, — это установить расширение Indigo.Design Code Generator. Именно это позволяет Visual Studio Code напрямую обращаться к Indigo.Design для получения прототипа.
После установки расширения разработчик сделает следующее:
Откройте уже разработанную оболочку приложения. Затем запустите генератор кода Indigo.Design. Здесь вы войдете в облачную ссылку:
Это откроет всплывающее окно с дизайном приложений, которые живут в облаке, а также с отдельными компонентами, из которых они состоят.
У разработчика есть возможность сгенерировать код для всех компонентов приложения или перейти покомпонентно, проверяя только те, которые ему нужны. Это особенно полезно, если приложение находится в разработке, и разработчику нужно только импортировать новые компоненты в VSC.
Нажав «Создать активы кода», выбранные компоненты будут добавлены в Angular в виде удобочитаемого и семантического HTML и CSS.
Теперь у разработчика меньше забот о перестроении стилей или настройке других спецификаций. Вместо этого они могут потратить свое время на создание бизнес-функциональности и реальное усовершенствование продукта.
Примечание об этом процессе
Важно отметить, что этот рабочий процесс Sketch — облако — Visual Studio Code работает не только с первой итерацией проекта. Разработчики могут строить, в то время как дизайнеры работают с обратной связью с клиентами или исследованиями удобства использования с пользователями — то, что Indigo.Design учитывает.
Итак, предположим, что дизайнер переместил пользовательский интерфейс формы входа через Indigo.Design, а разработчик сгенерировал код, чтобы все заработало.
Во время работы над формой разработчик реализовал некоторый код аутентификации в файле TypeScript.
Тем временем дизайнер получил сообщение от клиента, в котором сообщалось, что необходимо внедрить новый универсальный вход в Google. Это означает, что UX должен измениться.
Когда обновление готово и прототип синхронизирован с Indigo.Design, дизайнер сообщает разработчику об изменениях. Итак, разработчик еще раз запускает Генератор кода Visual Studio. Однако при повторном создании экрана входа они выбирают «Не переопределять» в файле TypeScript. Таким образом, они могут сохранить написанный код и одновременно импортировать новый HTML и CSS.
Затем разработчик может внести необходимые коррективы на основе обновленного дизайна.
Заворачивать
Indigo.Design эффективно создал эффективную и безошибочную передачу для дизайнеров, работающих в Sketch, и разработчиков, работающих в Visual Studio Code.
Дизайнеры не тратят время на проектирование на одной платформе и прототипирование на другой, составление спецификаций дизайна или экспорт файлов. Разработчики не тратят время на воссоздание замысла проекта из статического файла.
Как сказал Джейсон Берес, старший вице-президент по разработке продуктов Indigo.Design:
Генерация кода Indigo.Design позволяет избежать всех этих ошибок на 100 %. Не только поддерживается дух дизайна, но и создаются идеальные до пикселя HTML и CSS, поэтому разработчик не находится в неудачном положении, когда ему приходится вручную сопоставлять дизайн.
И, устранив технические недостатки в рабочих процессах дизайнера-разработчика и передаче, ваше агентство значительно снизит стоимость доработок и отладки. Вы также увеличите прибыль, предоставив вашей команде разработчиков более эффективный и быстрый способ запуска приложений в идеальном состоянии.