Дизайнеры и разработчики работают вместе
Богатые возможности презентаций WPF и Silverlight означают, что такие разработчики, как я, будут чаще работать в тесном сотрудничестве с графическими дизайнерами, как в моем следующем проекте.
Есть ли у кого-нибудь какие-либо советы и опыт (с обеих точек зрения), как сделать это более гладким?
Например, когда я недавно упоминал об управлении исходным кодом дизайнера, мне быстро сказали, что вы не можете контролировать исходную графику, изображения и т. Д., Так что это пустая трата времени. Поэтому я ответил: хорошо, но как насчет файлов XAML в WPF/Silverlight?
Скотт Хансельман говорил об этой теме в подкасте, но он больше сосредоточился на инструментах, в то время как меня больше интересуют вопросы / аспекты общения.
12 ответов
Я потратил 4 месяца на проект, работая в тесном контакте с дизайнером, и он до сих пор не понял основную идею CVS (что не является моим выбором системы контроля версий). Я говорю о файлах шаблонов, JavaScript и CSS здесь. Он не дурак, это всего лишь одна из тех вещей, которые усложняют его работу, поэтому он полностью сопротивляется этому.
В моем случае мне нужно было разобраться с тем, что почти весь мой JavaScript зависел от разметки, и когда он изменил свой чистый CSS, макет на основе DIV на табличный, не сказав мне тогда, что все мои JS будут работать сломать.
Часто в ходе проекта я и дизайнер, с которыми я неплохо ладил и играю в футбол вне работы, очень горячо обсуждали наши соответствующие обязанности. Если бы я не знал его достаточно хорошо, чтобы просто пройти эти обмены, то я думаю, что это создало бы невыносимую рабочую среду. Поэтому я думаю, что важно установить между вами обоими и каким-то менеджером или руководителем проекта именно то, что ожидается от обеих сторон в ходе проекта.
В моем случае в последнее время было очень мало проблем, потому что ситуация с CVS была разобрана, а также идея, что он не может просто пойти и изменить наценку, когда ему так хочется. Вместо того, чтобы пытаться создавать файлы шаблонов и работать с ними напрямую, дизайнер работает только со статическими файлами, и я несу ответственность за их подключение к моим файлам шаблонов.
Все дело в общении и небольшом компромиссе с обеих сторон.
Одна из вещей, которые я обнаружил, заключается в том, что то, как вы, как разработчик, разрабатываете свой код, сильно влияет на то, что дизайнер может с ним сделать. Часто вы загружаете образец приложения Silverlight или WPF из Интернета и открываете его в Blend, просто чтобы вызвать сбой Blend, потому что код плохо работает внутри дизайнера. Если он не падает, он редко выглядит как работающее приложение.
Недавно я выступил с докладом в Tech Ed в Австралии и Новой Зеландии о методах, которые можно применять для "проектирования для проектирования". Короткий маркированный список включен:
Напишите код, который может использовать преимущества привязки данных. Model-View-ViewModel или шаблон представления хорошо подходят для этого.
Поставьте заглушки "времени разработки" для ваших служебных зависимостей. Если класс, к которому вы привязываете, делает вызовы веб-службы, обязательно замените клиент веб-службы классом-заглушкой, который возвращает "фиктивные данные", которые дизайнер использует внутри blend. Это легко сделать с помощью IoC и Dependency Injection, внедрив одну реализацию, если HtmlPage.IsEnabled == false.
Используя привязку данных, вы можете ограничить количество "именованных элементов" в вашем файле XAML. Если вы пишете много кода позади, вы в конечном итоге связываете свой код C# с именованными элементами, такими как txtName или txtAddress, что облегчает дизайнеру "облажаться".
Используйте шаблон команды вместо кода позади обработчиков событий щелчка. Свободно связав инициатор события с обработчиком, вы можете иметь менее именованные элементы, и вы даете дизайнеру свободу выбора между кнопкой или элементом меню для вызова определенной команды.
Проверьте свой код в Blend! Даже если вы считаете себя чистым разработчиком, вы должны проверить, что ваш код потребляемый инструментом, и стремиться получить максимально возможный опыт во время разработки. Некоторые утверждают, что инструмент не должен влиять на ваш дизайн программного обеспечения, точно так же, как кто-то жалуется на "дизайн для тестируемости" и принятие решений о дизайне программного обеспечения, чтобы сделать код более тестируемым. Я думаю, что это разумно, и только так вы можете начать работу с настоящим дизайнером-разработчиком.
Другие советы будут начинаться с малого. Если ваш дизайнер является новичком в XAML, WPF и Silverlight, начните с представления их команде разработчиков и предложите им выполнить некоторые базовые проекты с помощью инструментов, которые они знают. Позвольте им сделать несколько кнопок и иллюстраций в Adobe Illustrator, экспортируйте их в XAML и покажите им, как вы можете напрямую использовать их ресурсы дизайна. Продолжайте вводить все больше и больше, и, надеюсь, они заинтересуются и захотят перейти на Blend. Это довольно круто, но оно того стоит!
Удачи!
PS: я написал много статей о шаблонах и создании удобного для разработчиков кода в своем блоге по адресу http://jonas.follesoe.no/. Вы также можете найти ссылки на видео-запись моего выступления Tech Ed, а также множество ссылок для дальнейшего чтения по этой теме.
Это может быть немного не по теме (я отвечаю конкретно на ваш вопрос об управлении исходным кодом и графике), но вы можете поместить двоичные данные (изображения и т. Д.) В управление исходным кодом (и, по моему мнению, во многих случаях следует) -- они просто занимают больше дискового пространства, и вы не можете использовать представление diff для анализа того, что изменилось каким-либо значимым образом, но вы получаете историю сообщений фиксации, документирующих каждую ревизию, возможность отката и возможность легко архивировать (помечая ревизию в терминах SVN) все файлы (будь то визуальные ресурсы, документация, исходный код и т. д.), принадлежащие конкретному выпуску / версии вместе. Вашей системе сборки также проще получить все необходимое для создания определенной версии вашего программного обеспечения из системы управления версиями.
Первоначально предполагалось, что профессиональные дизайнеры будут работать в Expression Blend, а разработчики - в Visual Studio, внося изменения в единый общий набор исходных файлов. Хотя это, безусловно, возможно (если вы регулярно проверяете, не сломали ли вы что-то, ожидаемое другим разработчиком или инструментом разработки), многие члены сообщества разработчиков, в том числе внутри Microsoft, обнаружили Преимущества в сохранении активности проектов Blend и Visual Studio SEPARATE - даже в том, что касается ручного вырезания и вставки тщательно реорганизованных версий сгенерированного Blend Xaml в "официальный" исходный код проекта VStudio, вместо того, чтобы позволить дизайнерам и разработчикам работать непосредственно с одним база общего кода. Команда Microsoft User Experience Team в Великобритании опубликовала видео, описывающее проблемы, с которыми они столкнулись, пытаясь координировать усилия дизайнеров и разработчиков над реальными проектами.
http://channel9.msdn.com/posts/Charles/Real-World-WPF--Designers-and-Developers-working-together/
Один из основных извлеченных уроков заключается в том, что вы не можете укомплектовать проект дизайнерами и разработчиками, которые совершенно не знают доменов друг друга. Разработчики должны быть достаточно знакомы с Blend, чтобы они могли предоставить дизайнерам полезные оболочки пользовательского интерфейса, которые дизайнер мог бы декорировать, и полезные "заглушки" данных, с которыми проектировщик мог бы проектировать интерактивность, и дизайнеру должно быть достаточно понимания проблем разработки, которые они надевают. не делайте такие вещи, как удаление элементов управления и замену их пользовательскими визуальными элементами, не понимая, что они нарушают все функции, связанные с исходным элементом управления.
Привлекайте графического дизайнера на ранних сессиях по дизайну и архитектуре.
Вы хотите привлечь их, чтобы выявить смещенные предположения и установить схему совместной работы, а не бросать вещи назад и вперед через стену.
Представление Microsoft о браке между проектировщиком и разработчиком определенно рушится в реальной жизни. У меня есть опыт работы над довольно масштабным проектом WPF, который включал 2 выделенных ресурса дизайна в течение примерно 4 месяцев. Вот некоторые факты, которые Microsoft, похоже, часто забывает.
- Дизайнеры часто предпочитают использовать Mac (дизайнеры в моей компании - 100% Mac - 0% Windows)
- Blend не работает на Mac (что касается решений для виртуальных машин - разработчикам, как правило, не нравятся такие отвратительные решения, как запуск странных приложений в чужой ОС).
- Дизайнеры используют свои инструменты торговли - Photoshop и Illustrator. Период.
- Агрессивность сегодняшних графиков обычно не дает разработчикам достаточно времени для изучения совершенно новой среды приложений / дизайна (например, Blend).
Поэтому, учитывая вышеизложенное, я заметил, что это создает новый тип работы - либо очень сложный дизайнер, либо программист с графическим образованием. По сути, тот, кто может взять ресурсы проекта в необработанном виде - обычно в формате.psd или в формате иллюстратора и применить их по мере необходимости к процессу приложения.
Я оказался тем парнем (графически просвещенным программистом). Я потратил много времени на экспорт XAML из файлов Illustrator, очищая их вручную при необходимости и делая эти активы легко используемыми для отображения объектов в Blend или VS. Также были случаи, когда я брал элемент дизайна и перерисовывал его, используя blend (обычно, когда исходный ресурс был основан на растровом изображении, и имело больше смысла преобразовать его в вектор).
Мое приложение, возможно, не было типичным - поскольку оно было чрезвычайно графически богатым, и независимость от разрешения была одной из основных целей, поскольку требовалось хорошо выглядеть на нескольких разрешениях и в пропорциях (подумайте о трудностях проектирования телевизора в современном ландшафте - вещи имеют хорошо смотреться как в низком разрешении SD, так и в хорошем качестве до высокого разрешения HD).
Таким образом, я думаю, что WPF - это потрясающая технология и абсолютно шаг в правильном направлении для Microsoft. Тем не менее, это не самое главное решение для интеграции дизайнера в процесс разработки - если только вы не переопределите роль дизайнера.
Меня зовут Феликс Корке, дизайнер из подкаста hanselman, о котором вы упомянули, поэтому вот пара моментов от настоящего креатива в отличие от разработчика.
Потребовалось много времени, чтобы привыкнуть к инструментам разработчика - я никогда не слышал о Visual Studio, C# или каком-либо другом типе управления исходным кодом, когда впервые начал заниматься xaml-работой несколько лет назад. Они были для меня такими же чуждыми, как Illustrator или 3DsMax.
Мое главное замечание в том, что нельзя ожидать, что дизайнер знаком с практиками разработчиков - пожалуйста, будьте готовы к тому, чтобы держать себя в руках. Вам не нужно будет изучать что-то новое, в то время как дизайнер будет запущен в совершенно новую страшную сторону разработки приложений. Я сделал правильный беспорядок из нескольких решений и проверок (и до сих пор делают).
К счастью, я научился быть скорее интегратором, ориентированным на дизайн, а не просто креативом, и, возможно, именно эту роль вам необходимо включить в ваш проект. Это иллюстрация, которую я сделал для нашей красавицы и гика - сессии дизайнеров / разработчиков в Mix - если один из вас находится слишком далеко на обоих концах спектра, может быть трудно понять, как работают другие и какова их роль.
С удовольствием отвечу на любые конкретные вопросы!
PS вы НЕ хотите, чтобы 100Mb+ .psd файлы в системе контроля версий;)
Я твердо верю в подход Интегратора, и это действительно та роль, которую мне пришлось выполнять, чтобы сделать наши усилия в WPF успешными.
У Лорана Бюньона есть пост на эту тему, который описывает то, о чем я говорю. Робби Ингебретсен также является сторонником такого подхода.
Но по сути, кто-то должен покрыть "разрыв", который существует между миром разработчиков и миром дизайнеров. Обычно происходит то, что этот человек происходит из мира разработчиков или из мира дизайнеров. Если они выходцы из мира разработчиков, то они, вероятно, разработчики с тенденциями дизайнеров (они отвечают за внешний вид, визуальные эффекты в приложении, расположение экранов и т. Д.). Если они приходят из мира дизайнеров, то они не боятся кода и удовольствия время от времени погружаются в код, чтобы получить анимацию или что-то еще.
Тем не менее, независимо от того, из какого они мира, им обычно приходится приобретать навыки, которых у них никогда не было. В моем случае я разработчик, которому нравится уровень пользовательского интерфейса, и поэтому я бы сказал, что я разработчик с дизайнерскими тенденциями. Чтобы восполнить этот пробел и провести продуктивные беседы с нашим графическим дизайнером, мне пришлось приобрести целый набор навыков дизайнерского типа, таких как: обучение использованию Expression Design, XAM 3D и т. Д.
Шеннон Браун недавно выступил с докладом на местной конференции разработчиков об отношениях между разработчиком и дизайнером и рабочих процессах, которые сообщество открывает для них, работает. Я не посещал конференцию, но я думал, что его слайды были отличной дискуссией по этому вопросу.
Степень, в которой дизайнеры почувствовали себя вправе дистанцироваться от всей работы, связанной с созданием программного продукта, представляет собой гораздо большую проблему, которую необходимо решить. Не потворствуйте выраженному праву дизайнеров не знать, как их работа интегрируется в целое.
Вид абсолютной специализации, которая выросла в сообществе дизайнеров, является одной из самых больших проблем зрелости промышленности, с которой сталкивается индустрия разработки программного обеспечения. Это степень специализации, которая предсказуемо создает больше переделок и увеличивает продолжительность цикла.
Это также относится и к чувству права разработчиков блаженно не знать о дизайне и реализации взаимодействия.
Экстремальная специализация всегда экспоненциальный множитель в проблемах производительности. Решите это организационно, приняв процессы, которые способствуют культуре обучения. Это уровень зрелости, который уже достигнут большинством других производственных отраслей, и что программное обеспечение печально отстает.
В каждом месте рабочего процесса разработки, где происходит переключение между чрезмерной специализацией, рабочими очередями и формированием буферов. Программное обеспечение остается одной из немногих отраслей, которые не признают это одной из самых больших проблем, с которыми мы сталкиваемся. Это еще более усугубляется в сообществе Microsoft, поскольку чрезмерная специализация кажется все более нормальной из-за увековечивания Microsoft чрезмерной специализации с помощью своих инструментов и рекомендаций. Если вы не можете позволить себе тратить столько денег, сколько Microsoft тратит на разработку, вам следует обратиться к методологиям, которые гораздо лучше осведомлены о вопросах потока и производительности.
Следовательно, разработчик, который не может тестировать, и тестер, который не может кодировать, являются признаком той же промышленной незрелости.
Вы не узнаете ничего из этого из шаблона Scrum для TFS. На протяжении многих лет Microsoft была на грани гибкого мышления даже в самых элементарных формах, и теперь, когда мы прогрессируем в мышлении Lean, Microsoft еще через три-пять лет от попыток внедрить мышление Lean в свои продуктовые линейки., Не ждите, пока Microsoft скажет вам, как сформировать команду и рабочий процесс. Вы можете узнать прямо сейчас от людей, на которых Microsoft в конечном итоге обратит внимание через несколько лет.
По моему опыту, роль интегратора или "разработчика" действительно должна быть вовлечена в этот процесс, если только все члены (небольшой) команды не смогут выполнить эту роль. Это очень редкое обстоятельство. Обычно вы обнаруживаете, что разработчики очень хороши в разработке, но не так хороши с дизайном / юзабилити, а дизайнеры хороши с эстетичностью / юзабилити, но не хотят или не достаточно образованы для написания кода. Наличие кого-то, кто может пересечь оба мира и "говорить на языке", очень важно.
Интегратору необходимо согласовать разрабатываемые элементы управления с активами проекта, создаваемыми дизайнерами. В нашем текущем проекте у нас есть 6 активных разработчиков и 2 дизайнера из внешнего магазина. Я являюсь интегратором этого проекта и большую часть своего дня провожу в Expression Blend. Разработчики работают в основном над созданием элементов управления, которые соответствуют спецификации нашего продукта, а дизайнерский магазин разрабатывает, как будет выглядеть конечный продукт. Дизайнеры работают в Illustrator. Моя задача - взять файлы Illustrator и создать из них стили элементов управления, а затем применить их к элементам управления, разработанным нашей командой разработчиков. По мере продвижения к Blend 3 с собственной поддержкой файлов PSD и AI эта задача становится намного проще.
Очень полезно создать "внешний вид" вашего приложения в отдельном решении от основного ствола приложения, а затем объединить ваши ResourceDictionaries с основным приложением. Вы можете выглядеть и чувствовать себя правильно, не слишком увлекаясь тем, что все еще может быть неполным контролем.
Я собираюсь предположить, что вы имеете в виду проекты RIA с момента вашего упоминания SL.
Я работал над несколькими проектами RIA с Adobe, проектируя и разрабатывая приложения и сервисы.
Лучший совет, который я могу вам дать, основанный на моем 14-летнем опыте работы в качестве UX и визуального дизайнера с некоторым опытом программирования, хотя и жалким по сравнению с вами, ребята.
Примите, что вы не понимаете друг друга.
Программист думает, какую функциональность следует выполнять, дизайнер думает, как эта функциональность должна вести себя.
Для разработчика кнопка является в основном общей, для дизайнера это не так. Дизайнеры думают по композиции, разработчики - по фреймворкам.
Поэтому научитесь понимать, что ваша ответственность отличается.
Вы, разработчик, ДОЛЖНЫ думать о том, насколько универсален ваш код, и не можете позволить себе рассматривать все как уникальную и жестко запрограммированную композицию. Это если вы не можете как-то автоматизировать эту уникальность.
Разработчик ДОЛЖЕН думать о приложении или услуге как об уникальном. Это может означать, что кнопка не является кнопкой. Там могут быть разные размеры или цвета или другие неприятности.
Поэтому убедитесь, что вы развиваете хорошие отношения с дизайнером, признавая, что понимаете ответственность дизайнера и убедитесь, что он понимает вашу.
Дело не в том, что вы не заинтересованы в создании лучшего приложения в мире. Просто некоторые из этих дизайнерских решений занимают довольно много времени.
Удостоверьтесь, что вы очень четко понимаете, как дизайнер должен предоставить вам, чтобы вы не тратили свое или свое время. Какой формат, активы? Именование?
Все вещи, которые участвуют в доставке из одной парадигмы в другую.
И самое главное, общаться и уважать, что они не знают, как сделать JavaScript или как понять основные идеи CVS.
Большинство разработчиков, которых вы не знали бы, как спасти свою жизнь, что такое вдова, как лучше наложить слои FireWorks или создать фотореалистичную иконку, придумали хороший слоган или сделали что-то понятное для среднего Джо в 4 словах. Вы не знаете, что такое сетка или выравнивание, и вы склонны делать вещи зелеными и фиолетовыми на черном.
И дизайнер должен понимать, что если вы занимаетесь программированием, это не значит, что вы робот, что у вас не может быть креативных идей и решений. Он также должен попытаться научиться программировать хотя бы псевдопрограмму, чтобы он понимал, что входит в создание вашего проекта.
И, самое главное. Не начинайте обсуждать Mac против ПК:) Из-за этого проекты были отменены.
Откровенно говоря, вы должны сказать дизайнеру, что изображения могут, должны и "будут помещены в систему управления версиями!":)
Это может быть немного нетрадиционно, и вы не сможете выполнить слияние или что-то в этом роде, но будут ревизии и история и т. Д. Изображения также могут быть встроены в файл ресурсов, который также входит в систему контроля версий.,
XAML может (и должен) быть помещен в систему контроля версий и в качестве файла разметки будет использовать все функции.
Что касается советов по работе с дизайнером, то тот, с которым вы работаете, пугает меня до чертиков только одним этим комментарием, так что все может сводиться к тому, с кем вы работаете. Я бы хорошо объяснил основные передовые практики и приступил бы к этому.