WPF和Silverlight强大的演示功能意味着像我这样的开发人员如今将越来越频繁地与图形设计师紧密合作，就像我的下一个项目一样。

从这两个角度来看，有没有人有任何技巧和经验(从这两个角度来看)？

例如，当我最近向设计人员提及源代码管理时，我很快就被告知我们无法源代码控制图形，图像等，因此浪费时间。所以我回答：好的，但是WPF / Silverlight中的XAML文件呢？

斯科特·汉塞尔曼(Scott Hanselman)在播客中谈到了这个话题，但是他更加关注工具，而我对沟通问题/方面更感兴趣。

解决方案

回答

这可能与主题无关(我要专门回答我们有关源代码管理和图形的问题)，但是我们可以将二进制数据(图像等)放入源代码管理(在我看来，在很多情况下应该如此)-它们只会占用更多的磁盘空间，我们不能使用差异视图来分析以任何有意义的方式更改的内容，但是我们获得的是提交消息的历史记录，其中记录了每个修订，回滚功能以及轻松归档的能力(以SVN术语标记修订版本)属于特定发行版/版本的所有文件(无论是视觉资产，文档，源代码，还是其他)。对于构建系统而言，从源代码管理中获取构建特定版本软件所需的所有内容也更加容易。

回答

让图形设计师参与早期的设计和架构会议。

我们想让他们参与进来，以揭示错位的假设，并建立一种合作的模式，而不是在墙上四处乱扔东西。

回答

我花了4个月的时间与设计师紧密合作，但他仍然没有接受CVS的基本概念(这不是我选择的源代码控制系统)。我在这里说的是模板文件，JavaScript和CSS。他并不傻，只是这些事情之一使他的工作更加艰难，因此他拒绝完全致力于这项工作。

在我的情况下，我不得不真正指出一个事实，即我几乎所有的JavaScript都依赖于标记，当他将纯基于CSS，基于DIV的CSS布局更改为基于表格的布局时，我没有告诉我所有的JS都将使用打破。

在项目进行过程中，我自己和设计师经常会相处得很好，并且在工作之余还可以踢足球，因此经常在项目工作过程中就各自的职责进行热烈的交流。如果我对他的了解还不够，以至于无法通过这些交流，那么我认为这将创造一个难以忍受的工作环境。因此，我认为重要的是，我们必须在双方之间以及与某种经理或者项目主管之间建立准确的对双方在项目期间的期望。

就我而言，最近出现的问题很少，因为已经解决了CVS的问题以及他不能随便更改标记的想法。设计人员仅尝试处理静态文件，而不是尝试创建模板文件并直接对其进行处理，而我有责任将其插入到我的模板文件中。

沟通和双方都需要一点妥协。

回答

坦率地说，我们应该告诉设计者图像可以，应该并且"将被放入源代码管理器中！" :)

它可能有点不合常规，我们将无法进行合并或者此类性质的任何操作，但是会有修订和历史记录等。图像也可以嵌入到资源文件中，该文件也将进入源代码管理。

XAML可以(并且应该)置于源代码管理中，并且作为其标记文件，它将受益于所有功能。

至于与设计师合作的技巧，仅与那条评论有关的工作就吓到我了，所以这可能归结为我们正在与谁合作。我将以一种很好的方式解释基本的最佳实践，然后从那里开始。

回答

我发现的一件事是，作为开发人员的我们如何设计代码会极大地影响设计人员使用它的能力。通常，我们从Web上下载Silverlight或者WPF示例应用程序，然后在Blend中打开它，只是因为代码在设计器内部运行不佳而使Blend崩溃。如果它不崩溃，则看起来很少像正在运行的应用程序。

我最近在澳大利亚和新西兰的Tech Ed上发表了有关可用于"为可设计性设计"的技术的演讲。简短的清单包括：

• 编写可以利用数据绑定的代码。 Model-View-ViewModel或者表示模式非常适合此操作。
• 为服务依赖项提供"设计时"存根。如果我们要绑定的类进行Web服务调用，请确保使用存根类替换Web服务客户端，该存根类将返回设计者在blend内部使用的"虚拟数据"。这可以通过IoC和依赖注入轻松完成，如果HtmlPage.IsEnabled == false，则注入一个实现。
• 通过使用数据绑定，可以限制XAML文件中"命名元素"的数量。如果在后面编写代码分配，最终会使C＃代码与诸如txtName或者txtAddress之类的命名元素耦合，这将使设计人员很容易"编写"。
• 在单击事件处理程序后面使用命令模式而不是代码。通过松散地耦合处理程序中事件的调用者，我们可以减少命名的元素，并使设计人员可以自由选择在Button或者Menu Item之间调用特定命令。
• 在Blend中测试代码！即使我们将自己视为纯粹的开发人员，也应该测试工具是否可以使用代码，并努力在设计时获得最佳体验。有人会认为一种工具不应该影响软件设计，就像有人抱怨"针对可测试性的设计"一样，并做出软件设计决策只是为了使代码更具可测试性。我认为这是一件很明智的事情，并且是使真正的设计师-开发人员工作流程顺利进行的唯一方法。

其他技巧是从小处着手。如果设计师是XAML，WPF和Silverlight的新手，则首先将其介绍给项目团队，并让他们在自己熟悉的工具中进行一些基本设计。让他们在Adobe Illustrator中做一些按钮和插图，然后将其导出到XAML，并向他们展示如何直接利用他们的设计资产。继续介绍越来越多的东西，希望他们对此感兴趣并希望切换到Blend。这是一个学习曲线，但确实值得！

祝你好运！

PS：我已经在http://jonas.follesoe.no的博客上写了关于模式和使设计者友好的代码的分配。我们还可以找到我的Tech Ed演讲的视频记录的链接，以及许多可以进一步阅读该主题的链接。

回答

最初，设想专业设计师将在Expression Blend中工作，而开发人员将在Visual Studio中工作，从而对一组共享的源文件进行更改。尽管当然可以做到这一点(只要我们定期检查是否没有破坏其他开发人员或者设计工具所期望的功能)，但开发人员社区的许多成员(包括Microsoft内部的一些成员)已经发现保持Blend和Visual Studio项目活动分离的好处-甚至可以手动剪切经过精心混合的Blend生成的Xaml版本并将其粘贴到"官方" VStudio项目源中，而不是允许设计人员和开发人员直接在单个共享库上进行操作代码库。微软在英国的用户体验团队发布了一段视频，描述了他们在尝试协调设计师和开发人员在实际项目上的工作时遇到的问题。

Real_World_WPF_DesignersAndDevelopers一起工作

获得的主要经验教训之一是，我们不能将完全不了解彼此领域的设计师和开发人员配备到项目中。开发人员需要对Blend足够熟悉，他们可以为设计人员提供有用的UI外壳供装饰人员使用，还可以为设计人员提供针对其进行交互性设计的有用数据"存根"，并且设计人员需要对他们不关心的开发问题有足够的了解不会执行删除控件之类的操作，而是用自定义视觉元素替换它们，而没有意识到它们破坏了与原始控件相关的所有功能。

回答

我是Integrator方法的忠实拥护者，而这正是我为使WPF努力取得成功而必须履行的职责。

Laurent Bugnion在此发表了一篇帖子，描述了我在说什么。罗比·英格布雷森(Robby Ingebretsen)也是这种方法的忠实拥护者。

但基本上，必须有人弥补开发人员和设计师之间存在的"差距"。通常发生的事情是，这个人来自开发者世界或者设计师世界。如果他们来自开发人员世界，那么他们很可能是具有设计趋势的开发人员(他们负责外观和感觉，应用程序中的视觉效果，屏幕布局等)。如果他们来自设计师世界，那么他们将不怕代码，时不时地潜入代码来获得动画或者任何闪闪发光的乐趣。

但是，无论他们来自哪个世界，他们通常都必须培养从未有过的技能。就我而言，我是一个喜欢用户界面层的开发人员，因此我想说我是一个具有设计倾向的开发人员。为了弥补这一空白并与我们的图形设计师进行富有成效的对话，我不得不学习很多设计师类型的技能，例如：学习使用Expression Design，XAM 3D等。

香农·布劳恩(Shannon Braun)最近在一次本地开发商会议上作了有关开发商/设计师关系以及社区正在为他们寻找工作的工作流程的演讲。我没有参加会议，但我认为他的幻灯片是关于此事的精彩讨论。

回答

微软在设计人员/开发人员工作流程结合方面的愿景似乎在现实生活中已被打破。我有一个大型WPF项目的工作经验，该项目涉及2个专用设计资源，历时约4个月。以下是Microsoft似乎经常忘记的一些事实。

• 设计师通常更喜欢使用Mac(我公司的设计师是100％Mac-0％Windows)
• Blend不能在Mac上运行(就VM解决方案而言-设计人员通常不喜欢怪异的解决方案，例如在外部OS中运行怪异的应用程序)。
• 设计师使用他们的专业工具-Photoshop和Illustrator。时期。
• 今天的进度表的激进性通常不能为设计人员提供足够的时间来学习全新的应用程序/设计环境(例如Blend)。

因此，鉴于以上所述，我注意到这会创建一个新的工作类型，或者是非常有技巧的设计师，或者是图形化的程序员。基本上，可以采用原始格式的.psd或者illustrator格式获取设计资产并将其按需要应用于申请过程的人。

我原来是那个家伙(图形开明的程序员)。我花了很多时间从Illustrator文件中导出XAML，在需要时手动清理它们，并使这些资产在Blend或者VS中易于使用。有时候，我会采用一个设计元素并使用blend重新绘制它(通常，当原始资产基于位图并且将其转换为矢量时更有意义)。

我的应用程序可能不是典型的应用程序，因为它具有极其丰富的图形，并且分辨率独立性是主要目标之一，因为它需要在多种分辨率和宽高比上保持良好的外观(想想在当今风景电视设计中所遇到的困难)在低分辨率SD上表现出色，并可以扩展到高分辨率HD)。

总而言之，我认为WPF是一项很棒的技术，绝对是Microsoft向正确方向迈出的一步。但是，除非重新定义设计者的角色，否则它并不是将设计者集成到开发过程中的最终解决方案。

回答

以我的经验，集成人员或者"设计者"角色确实需要参与此过程，除非(小型)团队中的每个人都能够执行此角色。这是非常罕见的情况。通常，我们会发现开发人员非常擅长开发，但是在设计/可用性方面并不那么擅长，而设计师在美学/可用性方面却很出色，但又不想或者没有受过足够的编码培训。有一个可以跨入两个世界并"说语言"的人非常重要。

集成商需要将正在开发的控件与设计人员正在创建的设计资产进行协调。在我们当前的项目中，我们有6位活跃的开发人员和2位来自外部商店的设计师。我是该项目的集成商，大部分时间都在Expression Blend中度过。开发人员主要在VS中创建符合我们产品规格的控件，而设计商店正在设计最终产品的外观。设计人员正在Illustrator中工作。我的工作是获取Illustrator文件并从中创建控件样式，然后将其应用于我们的开发团队开发的控件。随着我们转向对PSD和AI文件具有原生支持的Blend 3，这项任务变得更加容易。

在与应用程序主干不同的解决方案中为应用程序创建"外观"，然后将ResourceDictionaries合并到主应用程序中，这非常有帮助。我们可以得到正确的外观和感觉，而不必过于陷入可能仍不完整的控件中。

回答

自从提到SL以来，我将假设我们是指RIA项目。

我曾与Adobe设计和开发应用程序和服务一起工作过很多RIA项目。

我可以根据我们在UX和Visual设计师方面的14年经验，以及一些编程经验为我们提供最佳建议，尽管与你们相比是可悲的。

接受你不会互相了解。

程序员考虑应该做什么功能，设计师考虑应该如何工作。

对于开发人员而言，按钮通常是通用的，对于设计人员而言并非如此。设计师考虑组成，开发人员考虑框架。

因此，要了解自己的责任是不同的。

我们需要开发人员考虑一下代码的通用性，而又不能将所有内容都视为唯一且经过硬编码的编写。除非我们可以通过某种方式使该唯一性自动化。

设计人员确实需要考虑应用程序或者服务是否具有独特性。这可能意味着按钮不是按钮。可能有不同的大小或者颜色或者其他烦人的地方。

因此，请确认我们了解设计师的责任并确保他了解责任，以确保与设计师建立良好的关系。

这并不是说我们对制作世界上最好的应用程序不感兴趣。只是其中一些设计决策需要大量时间。

确保我们非常清楚设计师应如何交付给我们，这样我们就不会浪费自己或者自己的时间。什么格式的资产？命名吗？

从一个范例到另一个范例的交付中涉及的所有事物。

并且最重要的是，交流和尊重他们不知道如何使用JavaScript或者如何理解CVS的基本思想。

大多数开发人员都不知道如何精打细算以挽救他们的生命，寡妇是什么，如何最好地对FireWorks进行分层或者创建逼真的图标，想出一个好的标语或者用4个词使普通的Joe可以理解。我们不知道什么是网格或者对齐方式，并且倾向于将事物变成绿色和紫色。

设计人员应该理解，仅仅因为我们从事编程工作并不意味着我们是机器人，就不能拥有创造性的想法和解决方案。他还应该尝试学习如何编写至少伪程序的程序，以便他了解制作项目所涉及的内容。

而且最重要的是。不要开始争论Mac与PC ：)因此，项目已被取消。

回答

我是Felix Corke，我们提到的hanselman播客中的设计师，所以这里有一些来自真正的创意而非开发人员的观点。

几年前我开始做xaml工作时，花了很长时间习惯了我从未听说过的Visual Studio，Cor的任何类型的源代码管理工具。它们对我来说就像Illustrator或者3DsMax对我们一样陌生。

我最大的一点是，不能期望设计师知道开发人员的实践，请做好准备进行大量工作。我们无需学习任何新知识，而设计师将被带入应用程序开发的一个全新的令人恐惧的方面。我把一些解决方案和签入弄得一团糟(并且仍然这样做)。

幸运的是，我已经学会了更多地成为专注于设计的集成商，而不是单纯的创意人，也许这是我们需要在项目中包含的角色。这是我为Mix进行的美妆和极客设计师/开发者会议所做的插图，如果你们中的任何一个人在频谱的任何一端都离得太远，可能很难理解其他人的工作方式以及他们应该扮演的角色。

很高兴回答任何具体问题！

ps，我们不希望源代码管理中包含100Mb + .psd文件；)

回答

设计人员觉得自己有资格远离构建软件产品所涉及的全部工作的程度，这是一个更大的问题，需要解决。不要为任何设计师所表达的权利而ander之以鼻，不必知道他们的作品如何被整合到整体中。

在设计师社区中长大的那种特殊专业化是软件开发行业面临的最大的行业成熟问题之一。在一定程度上，这是专业化的程度，可以创造更多的返工和更长的周期时间。

开发人员的权利感也很幸福，他们毫不犹豫地不知道交互设计和实现。

极端专业化始终是生产力问题的指数倍增器。通过采用促进学习文化的流程来从组织上解决它。这是大多数其他生产行业已经意识到的成熟度，而软件则严重地落后了。

在开发工作流程中的每个地方，在过度专业化之间都会进行切换，因此会形成工作队列和缓冲区。软件仍然是少数几个没有将其视为我们面临的最大问题之一的行业之一。由于过度专业化似乎越来越普遍，这归因于Microsoft通过其工具和指南过度专业化，这在Microsoft社区中更加严重。除非我们能够承担与Microsoft在开发工作上一样多的金钱，否则我们应该寻求在流程和生产力问题上能更好地掌握信息的方法。

因此，无法测试的开发人员和无法编写代码的测试人员是同样的工业不成熟的症状。

我们不会从TFS的Scrum模板中学到任何这些。微软在以最基本的形式进行敏捷思考方面落后了很多年，而现在，我们正在向精益思维发展，距离将精益思维纳入其产品线还需要三到五年的时间。 。不要等到Microsoft告诉我们如何组建团队和工作流程。我们现在可以向人们学习，Microsoft最终会在几年内对其予以关注。