Designers and developers working togetherWPF和Silverlight强大的演示功能意味着像我这样的开发人员如今将越来越频繁地与图形设计师紧密合作，就像我的下一个项目一样。 从这两个角度来看，有没有人有任何技巧和经验(从这两个角度来看)？ 例如，当我最近向设计人员提到源代码管理时，我很快被告知您不能源代码控制图形，图像等，因此这是浪费时间。 所以我回答：好的，但是WPF / Silverlight中的XAML文件呢？ 斯科特·汉塞尔曼(Scott Hanselman)在播客中谈到了这个话题，但是他更加关注工具，而我对沟通问题/方面更感兴趣。 我发现的一件事是，作为开发人员的您如何设计代码会极大地影响设计人员使用它的能力。通常，您是从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演讲的视频录像的链接，以及用于进一步阅读该主题的大量链接。 我花了4个月的时间与设计师紧密合作，但他仍然没有接受CVS的基本概念(这不是我选择的源代码控制系统)。我在这里谈论模板文件，JavaScript和CSS。他并不傻，只是这些事情之一使他的工作更加艰辛，因此他拒绝完全致力于这项工作。 在我的情况下，我必须真正意识到几乎所有JavaScript都依赖于标记，并且当他将纯基于CSS，基于DIV的CSS布局更改为基于表的布局时，我没有告诉我我所有的JS都会使用打破。 在项目进行过程中，我自己和设计师经常会相处得很好，并且在工作之外踢足球，常常在我各自的职责上进行激烈的交流。如果我对他的了解不足够，无法通过这些交流，那么我认为这将创造一个难以忍受的工作环境。因此，我认为，在您之间以及与某种经理或项目主管之间建立准确的对双方的期望是很重要的。 就我而言，最近出现的问题很少，因为已经解决了CVS的问题以及他不能随便更改标记的想法。设计人员仅尝试处理静态文件，而不是尝试创建模板文件并直接对其进行处理，而我有责任将其插入到我的模板文件中。 沟通和双方都需要一点妥协。 这可能是个话题(我专门回答您有关源代码管理和图形的问题)，但是您可以将二进制数据(图像等)放入源代码管理(在我看来，在很多情况下应该如此)- -它们只会占用更多的磁盘空间，您不能使用差异视图来分析以任何有意义的方式更改的内容，但是您获得的是提交消息的历史记录，记录了每个修订版本，回滚功能以及轻松存档的功能(以SVN术语标记修订)将属于特定发行版/版本的所有文件(无论是视觉资产，文档，源代码，还是其他)一起在一起。对于构建系统来说，从源代码管理中获取构建特定版本软件所需的所有内容也更加容易。 最初，设想专业设计师将在Expression Blend中工作，而开发人员将在Visual Studio中工作，从而对一组共享的源文件进行更改。尽管当然可以做到这一点(只要您定期检查是否没有破坏其他开发人员或设计工具所期望的功能)，但开发人员社区的许多成员(包括Microsoft内部的一些成员)已经发现保持Blend和Visual Studio项目活动分离的好处-甚至可以手动剪切将Blend生成的Xaml的经过仔细重构的版本粘贴到"官方" VStudio项目源中，而不是允许设计人员和开发人员直接在单个平台上操作共享代码库。微软在英国的用户体验团队发布了一个视频，描述了他们在试图协调设计师和开发人员在实际项目上的努力时遇到的问题。 Real_World_WPF_DesignersAndDevelopers一起工作 获得的主要经验教训之一是，您不能将完全不了解彼此领域的设计师和开发人员配备到项目中。开发人员需要对Blend足够熟悉，他们可以为设计师提供有用的UI外壳供装饰，设计师可以使用有用的数据"存根"来设计交互性，并且设计师需要对他们不关心的开发问题有足够的了解不会执行删除控件之类的操作并将其替换为自定义视觉元素-并未意识到它们破坏了与原始控件相关的所有功能。 让图形设计师参与早期的设计和架构会议。 您想让他们参与进来，以揭示错位的假设，并建立一种共同工作的模式，而不是在墙上乱扔东西。 微软在设计人员/开发人员工作流程结合方面的愿景在现实生活中似乎确实破裂了。我有一个大型WPF项目的工作经验，该项目涉及2个专用设计资源，历时约4个月。以下是Microsoft似乎经常忘记的一些事实。
因此，鉴于以上所述，我注意到这创建了一种新的工作类型-要么是技术含量很高的设计师，要么是图形化的程序员。基本上，可以以原始格式(通常是.psd或illustrator格式)获取设计资产并将其按需要应用于申请过程的人。 我原来是那个人(图形开明的程序员)。我花了很多时间从Illustrator文件中导出XAML，在必要时手动清理它们，并使这些资产在Blend或VS中易于使用。有时候，我会采用一个设计元素并使用blend重新绘制它(通常，当原始资产基于位图并且将其转换为矢量时更有意义)。 我的应用程序可能不是典型的应用程序-它具有极其丰富的图形，并且分辨率独立性是主要目标之一，因为它需要在多种分辨率和宽高比上看起来都不错(想想在当今环境下设计电视的困难-事情已经在低分辨率SD上看起来都不错，并且可以放大到高分辨率HD)。 总之，我认为WPF是一项很棒的技术，绝对是Microsoft向正确方向迈出的一步。但是，它并不是将设计师整合到开发过程中的最终解决方案-除非您重新定义设计师的角色。 我是Felix Corke，您提到的hanselman播客中的设计师，所以这里有一些来自真正的创意而非开发人员的观点。 花了很长时间习惯了开发人员工具-几年前我第一次开始做xaml工作时，我从未听说过Visual Studio，C＃或任何类型的源代码控制。它们对我来说就像Illustrator或3DsMax对您一样陌生。 我最大的要点是，不能期望设计师了解开发人员的实践-请准备好进行大量工作。您无需学习任何新知识，而设计师将被带入应用程序开发的一个全新的令人恐惧的方面。我把一些解决方案和签入弄得一团糟(并且仍然这样做)。 幸运的是，我已经学会了更多地成为专注于设计的集成商，而不是单纯的创意人，也许这是您需要在项目中包含的角色。这是我为我们的美丽和怪胎所做的例证-在Mix的设计师/开发人员会议上-如果你们中的任何一个人都离谱太远，可能很难理解另一个人的工作原理和角色。
很高兴回答任何具体问题！ ps，您不希望源代码管理中包含100Mb + .psd文件；) 设计人员有资格离开与构建软件产品相关的整个工作的范围，这是一个更大的问题，需要解决。不要为任何设计师所表达的权利而ander之以鼻，不必知道他们的作品如何融入到整体中。 在设计师社区中长大的那种特殊专业化是软件开发行业面临的最大的行业成熟问题之一。在一定程度上，这是专业化的程度，可以创造更多的返工和更长的周期时间。 开发人员的权利感也很幸福，他们毫不犹豫地不知道交互设计和实现。 极端专业化始终是生产力问题的指数倍增器。通过采用促进学习文化的流程来有组织地解决它。这是大多数其他生产行业已经意识到的成熟度，并且软件严重地落后了。 在开发工作流程中的每个地方，在过度专业化之间都会进行切换，因此会形成工作队列和缓冲区。软件仍然是少数几个没有将其视为我们面临的最大问题之一的行业之一。由于过度专业化似乎越来越普遍，这归因于Microsoft通过其工具和指南对过度专业化的永久保留，这在Microsoft社区中更加恶化。除非您能够承担与Microsoft在开发工作上一样多的金钱，否则您应该寻求在流程和生产力问题上能更好地掌握信息的方法。 因此，无法测试的开发人员和无法编写代码的测试人员是同样的工业不成熟的症状。 您不会从TFS的Scrum模板中学到任何东西。微软在以最基本的形式进行敏捷思考方面落后了很多年，而现在，我们正在向精益思维发展，距离将精益思维纳入其产品线还需要三到五年的时间。 。不要等到Microsoft告诉您如何组建团队和工作流程。您现在可以向人们学习，Microsoft最终将在几年内关注这些人员。 我是Integrator方法的忠实拥护者，而这正是我为使WPF努力取得成功而必须履行的职责。 Laurent Bugnion在此发表了一篇帖子，描述了我在说什么。罗比·英格布雷森(Robby Ingebretsen)也是这种方法的忠实拥护者。 但基本上，必须有人弥补开发人员和设计师之间存在的"差距"。通常发生的事情是这个人来自开发人员世界或设计师世界。如果他们来自开发人员世界，那么他们可能是具有设计趋势的开发人员(他们负责外观和感觉，应用程序中的视觉效果，屏幕布局等)。如果他们来自设计师世界，那么他们将不怕代码，时不时地潜入代码中以获得该动画或其他任何闪光的乐趣。 但是，无论他们来自哪个世界，他们通常都必须培养从未有过的技能。就我而言，我是喜欢用户界面层的开发人员，因此我想说我是一名具有设计倾向的开发人员。为了弥补这一空白并与我们的图形设计师进行富有成效的对话，我不得不学习很多设计师类型的技能，例如：学习使用Expression Design，XAM 3D等。 香农·布劳恩(Shannon Braun)最近在一次本地开发商会议上作了有关开发商/设计师关系以及社区正在为其寻找工作的工作流程的演讲。我没有参加会议，但我认为他的幻灯片是关于此事的精彩讨论。 自您提到SL以来，我将假设您是指RIA项目。 我曾与Adobe设计和开发应用程序和服务一起工作过很多RIA项目。 我可以根据您在UX和Visual设计师方面的14年经验，以及一些编程经验为您提供最佳建议，尽管与你们相比是可悲的。 接受你不会互相了解。 程序员考虑应该做什么功能，设计师考虑应该如何工作。 对于开发人员而言，按钮通常是通用的，对于设计人员而言并非如此。设计师考虑组成，开发人员考虑框架。 因此，要了解自己的责任是不同的。 您需要开发人员考虑一下代码的通用性，而又不能将所有内容都视为唯一且经过硬编码的编写。除非您可以通过某种方式使该唯一性自动化。 设计人员确实需要考虑应用程序或服务是否具有独特性。这可能意味着按钮不是按钮。可能有不同的大小或颜色或其他烦恼。 因此，请确认您了解设计师的责任并确保他了解您的责任，以确保与设计师建立良好的关系。 这并不是说您对制作世界上最好的应用程序不感兴趣。只是其中一些设计决策需要大量时间。 确保您非常清楚设计师应如何交付给您，这样您就不会浪费自己或自己的时间。什么格式的资产？命名？ 从一个范例到另一个范例的交付中涉及的所有事物。 并且最重要的是，交流和尊重他们不知道如何使用JavaScript或如何理解CVS的基本思想。 大多数开发人员都不知道如何精打细算以挽救生命，寡妇是什么，如何最好地对FireWorks进行分层或创建逼真的图标，想出一个不错的标语或用4个字使普通的Joe可以理解。您不知道什么是网格或对齐方式，并且倾向于将事物变成黑色的绿色和紫色。 设计人员应该理解，仅仅因为您从事编程工作并不意味着您是机器人，就没有创意和解决方案。他还应该尝试学习如何对至少伪程序进行编程，以便他了解制作项目所涉及的内容。 而且最重要的是。不要开始争论Mac与PC ：)因此，项目已被取消。 以我的经验，除非(小型)团队中的每个人都能执行此角色，否则实际上需要在此过程中涉及集成者或"设计者"角色。这是非常罕见的情况。通常，您会发现开发人员非常擅长开发，但在设计/可用性方面并不那么出色，而设计师在美学/可用性方面却很出色，但又不想或没有受过足够的编码方面的知识。有一个可以跨入两个世界并"说语言"的人非常重要。 集成商需要将正在开发的控件与设计人员正在创建的设计资产进行协调。在我们当前的项目中，我们有6位活跃的开发人员和2位来自外部商店的设计师。我是该项目的集成商，大部分时间都在Expression Blend中度过。开发人员主要从事VS的创建符合我们产品规格的控件的工作，而设计商店正在设计最终产品的外观。设计师正在Illustrator中工作。我的工作是获取Illustrator文件并从中创建控件样式，然后将其应用于我们的开发团队开发的控件。随着我们转向对PSD和AI文件具有原生支持的Blend 3，这项任务变得更加容易。 在与应用程序主干不同的解决方案中为应用程序创建"外观"，然后将您的ResourceDictionaries合并到主应用程序中，这非常有帮助。您可以得到正确的外观和感觉，而不必过于陷入可能仍不完整的控件中。 坦白地说，您应该告诉设计者图像可以，应该并且"将被放入源代码管理器中！" :) 它可能有点不合常规，您将无法进行合并或任何其他性质的操作，但是会有修订和历史记录等。图像也可以嵌入到资源文件中，该文件也将进入源代码管理。 XAML可以(并且应该)置于源代码管理中，并且作为其标记文件，它将受益于所有功能。 至于与设计师一起工作的技巧，您正在与之打交道的人仅凭此评论就吓到了我，所以这可能归结为您与之合作的WHO。我将以一种很好的方式解释基本的最佳实践，然后从那里开始。 |
