Дизайнеры и разработчики работают вместе [закрыто]

Question

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

Есть ли у кого-нибудь какие-нибудь советы и опыт (с обеих точек зрения), как сделать это более гладко?

Например, когда я недавно упомянул об управлении исходным кодом дизайнеру, мне быстро сказали, что вы не можете управлять исходным кодом графики, изображений и т. д., так что это пустая трата времени.Поэтому я ответил:хорошо, но как насчет файлов XAML в WPF/Silverlight?

Скотт Хансельман говорил на эту тему в подкаст, но он больше сосредоточился на инструментах, а меня больше интересуют вопросы/аспекты коммуникации.

Answer 1

Я потратил 4 месяца на проект, очень тесно работая с дизайнером, и он до сих пор не уловил основную идею CVS (это не мой выбор системы контроля версий).Здесь я говорю о файлах шаблонов, JavaScript и CSS.Он не глупый, это просто одна из этих вещей, которая усложняет его работу, поэтому он сопротивляется полностью посвятить себя ей.

В моем случае мне пришлось четко подчеркнуть, что почти весь мой JavaScript зависел от разметки, и когда он изменил свой чистый CSS и макет на основе DIV на табличный, не сказав мне, что весь мой JS будет работать. сломать.

Часто в ходе проекта я и дизайнер, с которым я довольно хорошо лажу и играю в футбол вне работы, очень жарко обсуждали наши обязанности.Если бы я не знал его достаточно хорошо, чтобы просто пройти мимо этих разговоров, то, думаю, это создало бы невыносимую рабочую атмосферу.Поэтому я думаю, что важно определить между вами обоими и с каким-нибудь менеджером или руководителем проекта, чего именно ожидают от обеих сторон в ходе проекта.

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

Все дело в общении и небольшом компромиссе с обеих сторон.

Answer 2

Одна из вещей, которые я обнаружил, заключается в том, что то, как вы, как разработчик, разрабатываете свой код, сильно влияет на то, что дизайнер может с ним делать.Часто вы загружаете пример приложения Silverlight или WPF из Интернета и открываете его в Blend только для того, чтобы у вас произошел сбой Blend из-за того, что код не работает хорошо внутри дизайнера.Если оно не выходит из строя, оно редко похоже на работающее приложение.

Недавно я выступил с докладом на Tech Ed в Австралии и Новой Зеландии о методах, которые можно применить к «проектированию для удобства проектирования».Включен краткий список:

1. Напишите код, который может использовать преимущества привязки данных.Модель-Представление-ViewModel или шаблон представления хорошо подходит для этого.

2. Предоставьте заглушки «времени разработки» для зависимостей вашего сервиса.Если класс, к которому вы привязываетесь, выполняет вызовы веб-службы, обязательно замените клиент веб-службы классом-заглушкой, который возвращает «фиктивные данные», которые дизайнер использует внутри blend.Это можно легко сделать с помощью IoC и внедрения зависимостей, внедрив одну реализацию, если HtmlPage.IsEnabled == false.

3. Используя привязку данных, вы можете ограничить количество «именованных элементов» в вашем файле XAML.Если вы пишете много кода позади себя, в конечном итоге вы связываете свой код C# с именованными элементами, такими как txtName или txtAddress, что позволяет дизайнеру легко «облажаться».

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

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

Другой совет — начать с малого.Если ваш дизайнер новичок в XAML, WPF и Silverlight, начните с представления его команде проекта и предложите ему выполнить базовые проекты с помощью знакомых им инструментов.Позвольте им создать несколько кнопок и иллюстраций в Adobe Illustrator, экспортировать их в XAML и показать им, как вы можете напрямую использовать их дизайнерские ресурсы.Продолжайте представлять все больше и больше, и, надеюсь, они заинтересуются и захотят перейти на Blend.Это довольно трудоемкий процесс обучения, но оно того стоит!

Удачи!

ПС:Я много писал о шаблонах и создании удобного для дизайнеров кода в своем блоге по адресу: http://jonas.follesoe.no.Вы также можете найти ссылки на видеозапись моего выступления на Tech Ed, а также множество ссылок на дополнительную информацию по этой теме.

Answer 3

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

Answer 4

Привлекайте графического дизайнера к ранним занятиям по дизайну и архитектуре.

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

Answer 5

Первоначально предполагалось, что профессиональные дизайнеры будут работать в Expression Blend, а разработчики — в Visual Studio, внося изменения в единый общий набор исходных файлов.Хотя это, безусловно, возможно (при условии, что вы будете регулярно проверять, не сломали ли вы что-то, ожидаемое другим разработчиком.или инструмент проектирования), многие члены сообщества разработчиков, в том числе некоторые из Microsoft, обнаружили преимущества в разделении деятельности над проектами Blend и Visual Studio — вплоть до того, что вручную вырезали и вставляли тщательно реорганизованные версии Xaml, сгенерированные Blend, в «официальный» исходный код проекта VStudio, вместо того, чтобы позволять дизайнерам и разработчикам работать непосредственно с единой общей базой кода.Группа взаимодействия с пользователями Microsoft в Великобритании опубликовала видео, описывающее проблемы, с которыми они столкнулись, пытаясь скоординировать усилия дизайнеров и разработчиков над реальными проектами.

Real_World_WPF_DesignersAndDevelopersWorkingTogether

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

Answer 6

Представление Microsoft о единстве рабочего процесса дизайнера и разработчика определенно терпит крах в реальной жизни.У меня есть опыт работы над довольно крупномасштабным проектом WPF, в котором участвовали два выделенных ресурса по дизайну в течение примерно 4 месяцев.Вот некоторые факты, о которых Microsoft, похоже, часто забывает.

• Дизайнеры часто предпочитают использовать Mac (дизайнеры в моей компании — 100% Mac и 0% Windows)
• Blend не работает на Mac (что касается решений для виртуальных машин — дизайнеры обычно не любят необычные решения, такие как запуск странных приложений в чужой ОС).
• Дизайнеры используют свои профессиональные инструменты — Photoshop и Illustrator.Период.
• Агрессивность сегодняшних графиков обычно не оставляет дизайнерам достаточно времени для изучения совершенно новой среды приложений/проектирования (например, Blend).

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

Я оказался тем парнем (графически просвещенным программистом).Я потратил много времени на экспорт XAML из файлов Illustrator, очищая их вручную, когда это необходимо, и делая эти ресурсы удобными для отображения объектов отображения в Blend или VS.Были также случаи, когда я брал элемент дизайна и перерисовывал его с помощью Blend (обычно, когда исходный ресурс был основан на растровом изображении и имело смысл преобразовать его в вектор).

Мое приложение, возможно, не было типичным - поскольку оно было чрезвычайно богато графически, а независимость от разрешения была одной из основных целей, поскольку оно должно было хорошо выглядеть при различных разрешениях и соотношениях сторон (подумайте о трудностях проектирования для телевидения в сегодняшних условиях - вещи изменились). чтобы хорошо выглядеть как в SD с низким разрешением, так и хорошо масштабироваться до HD с высоким разрешением).

Подводя итог, я считаю, что WPF — это потрясающая технология и абсолютно шаг в правильном направлении для Microsoft.Однако это не окончательное решение для интеграции дизайнера в процесс разработки — если только вы не переопределите роль дизайнера.

Answer 7

Я Феликс Корке, дизайнер из упомянутого вами подкаста Hanselman, так что вот пара моментов от настоящего креативщика, а не от разработчика.

Потребовалось много времени, чтобы привыкнуть к инструментам разработчика — я никогда не слышал о Visual Studio, C# или каком-либо типе системы управления версиями, когда несколько лет назад впервые начал работать с xaml.Они были для меня такими же чужими, как, может быть, Illustrator или 3DsMax для вас.

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

К счастью, я научился становиться скорее интегратором, ориентированным на дизайн, чем простым креативщиком, и, возможно, вам нужно включить эту роль в свой проект.Это иллюстрация, которую я сделал для нашей красоты и компьютерного специалиста — сеанса дизайнера/разработчика в Mix — если кто-то из вас находится слишком далеко на любом конце спектра, может быть трудно понять, как работает другой и какова должна быть его роль.

Рад ответить на конкретные вопросы!

PS вам НЕ нужны файлы .psd размером более 100 МБ в системе контроля версий;)

Answer 8

Я твердо верю в подход интегратора, который на самом деле является той ролью, которую мне пришлось выполнять, чтобы наши усилия по WPF были успешными.

У Лорана Бюньона есть почта это описывает то, о чем я говорю. Робби Ингебрецен также является большим сторонником этого подхода.

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

Однако независимо от того, из какого мира они родом, им обычно приходится приобретать навыки, которых у них никогда раньше не было.В моем случае я разработчик, который любит уровень пользовательского интерфейса, и поэтому я бы сказал, что я разработчик с дизайнерскими наклонностями.Чтобы восполнить этот пробел и продуктивно поговорить с нашим графическим дизайнером, мне пришлось овладеть целым набором дизайнерских навыков, таких как:научиться использовать Expression Design, XAM 3D и т. д.

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

Answer 9

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

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

Это также относится и к ощущению права разработчиков оставаться в блаженном неведении о проектировании и реализации взаимодействия.

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

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

Следовательно, разработчик, который не умеет тестировать, и тестировщик, который не умеет кодировать, являются симптомами одной и той же индустриальной незрелости.

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

Answer 10

По моему опыту, роль интегратора или «разработчика» действительно должна быть вовлечена в этот процесс, если только все члены (маленькой) команды не способны выполнять эту роль.Это очень редкое обстоятельство.Обычно вы обнаружите, что разработчики очень хороши в разработке, но не так хороши в дизайне/удобстве использования, а дизайнеры хороши в эстетике/удобстве использования, но не хотят или недостаточно образованы для кодирования.Очень важно иметь кого-то, кто может переходить в оба мира и «говорить на языке».

Интегратору необходимо скоординировать разрабатываемые элементы управления с проектными ресурсами, создаваемыми проектировщиками.В нашем текущем проекте работают 6 активных разработчиков и 2 дизайнера из стороннего магазина.Я являюсь интегратором этого проекта и большую часть своего дня провожу в Expression Blend.Разработчики работают в основном над VS, создавая элементы управления, соответствующие спецификациям нашего продукта, а дизайнерская мастерская проектирует, как будет выглядеть конечный продукт.Дизайнеры работают в Illustrator.Моя работа — взять файлы Illustrator и создать из них стили элементов управления, а затем применить их к элементам управления, разработанным нашей командой разработчиков.По мере того, как мы переходим к Blend 3 с встроенной поддержкой файлов PSD и AI, эта задача становится намного проще.

Очень полезно создать внешний вид вашего приложения в отдельном решении от основного ствола приложения, а затем позже объединить ваши ResourceDictionaries с основным приложением.Вы можете добиться правильного внешнего вида, не слишком увлекаясь тем, что все еще может быть неполным контролем.

Answer 11

Я предполагаю, что вы имеете в виду проекты RIA после упоминания SL.

Я работал с Adobe над несколькими проектами RIA, занимаясь проектированием и разработкой приложений и услуг.

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

Примите тот факт, что вы не поймете друг друга.

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

Для разработчика кнопка обычно является общей, для дизайнера это не так.Дизайнеры мыслят композицией, разработчики думают фреймворками.

Так что научитесь понимать, что ваша ответственность другая.

Вы, разработчик, ДЕЙСТВИТЕЛЬНО должны думать о том, насколько универсален ваш код, и вы не можете позволить себе рассматривать все как уникальное и жестко запрограммированное сочетание.Это если только вы не сможете каким-то образом автоматизировать эту уникальность.

Дизайнеру НЕОБХОДИМО думать о приложении или услуге как о чем-то уникальном.Это может означать, что кнопка — это не кнопка.Могут быть разные размеры, цвета или другие неприятности.

Поэтому убедитесь, что у вас сложились хорошие отношения с дизайнером, признав, что вы понимаете ответственность дизайнера, и убедитесь, что он понимает вашу.

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

Убедитесь, что вы четко понимаете, как дизайнер должен донести до вас, чтобы вы не тратили зря его или свое время.Какой формат, активы?Именование?

Все, что связано с переходом от одной парадигмы к другой.

И самое главное, сообщайте и уважайте, что они не знают, как использовать JavaScript или как понимать основные идеи CVS.

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

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

И самое важное.Не начинайте обсуждать Mac vs.ПК :) Из-за этого проекты отменены.

Answer 12

Откровенно говоря, вы должны сказать дизайнеру, что изображения могут, должны и «будут помещены в Mister!» :)

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

XAML можно (и нужно) поместить в систему контроля версий, и поскольку это файл разметки, он будет использовать все функции.

Что касается советов по работе с дизайнером, тот, с которым вы работаете, меня до чертиков пугает уже одним этим комментарием, так что все может сводиться к тому, с КЕМ вы работаете.Я бы объяснил основные лучшие практики в хорошей форме и продолжил бы оттуда.