如何将视觉设计师融入到开发过程中？
我们使用 JQueryUI 和主题开发了一个稍微复杂的 Web 应用程序。我们选择这种方法是因为我们可以自己做，使用 Themeroller 构建主题和 JQueryUI 类或 JavaScript 中的 JQUI 感知插件，并且迭代配色方案、字体和其他样式元素的需求非常有限。
我刚刚开始收到设计人员的意见，并希望创建一个工作流程以允许样式的流畅变化。什么对你有用？
We have developed a mildly sophisticated web application using JQueryUI and themes. We chose this approach because we could do it ourselves, using Themeroller to build a theme and JQueryUI classes or JQUI-aware plugins in Javascript, and have had very limited need to iterate over color schemes, fonts and other styling elements.
I've just started to receive input from our design staff, and want to create a workflow to allow for fluid changes in styling. What works for you?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
可悲的是，优秀的图形/Ui 设计师，能够在 Flash 中进行设计/编码是稀有的宝石......对于 JavaScript：它们是不存在的（至少对我在我的国家来说）；
因此，我使用的工作流程（针对设计师）考虑到了这一点，并且对于我的 flash/JavaScript 项目保持不变；
角色
首先，从设计者的角度来看：有3个角色，如下所示。
1) 设计师：负责艺术指导和图形制作。
2) 接口-r：与其余部分一起实现图形和动画。
3) 逻辑编码器：编码类和功能：逻辑与接口隔离。
逻辑编码器可以有更多的子角色，但这超出了设计者的观点。角色不应该 100% 强制执行：互相学习和帮助是件好事；设计者不需要了解编码，编码员也不需要了解设计。然而，界面人员需要了解编码和一些设计：不好：但知道（尤其是动画）
工作流程
1）基本功能是由每个人制定的；虽然它实际上是一个编码员的角色：让每个人参与有助于想法生成的进展（程序员：设计师有时可以想出非常好的疯狂想法，你的工作是从逻辑上看它如何实现以及是否值得这样做）
2）模拟 UI 和类接口 这可能是您见过的最糟糕的 UI，但它给出了一个总体的工作方向：这是由每个人完成的。编码人员制定出独立的逻辑（根本没有图形；例如：服务器逻辑），而接口人员和设计人员则进行模型制作。
3.1）图形和动画图形设计师致力于他们精彩的设计/图形。而界面器将设计转换为实际界面（从 Photoshop 到 flash/HTML）。如果幸运的话，设计师甚至会知道如何做到这一点（切片等），而界面则专注于实现和动画。任何附加的图形动画（动态的东西，比如跟随鼠标或对鼠标做出反应的东西）。是由这些人讨论和开发的。 2. 这个过程很少涉及编码员介入。
3.2）编码员在逻辑上工作，同时确保它符合与接口者商定的编码接口。专注于让模型功能齐全（不是最好看的）。这通常是通过类接口和/或全局声明（如果可能的话避免）来完成的。
4）接口合并 接口器，然后将两者合并在一起：形成最终的应用程序。 XD
结束语
实际上，在第 2 阶段之后。工作流程处于第 3 阶段和第 4 阶段的连续循环中。拥有接口器的主要优点是确保设计人员或编码人员减慢对方的速度。因此，速度减慢是有限的:)然而，接口员的角色很艰难，需要非常灵活，而且更常见的是在小团队中不兼任项目负责人。因为只有他才能理解双方及其局限性。尽管他可能并不孤单，也不是最擅长的。
请注意，当双方都是重要角色时，这在 RAI 中被广泛使用。但是，如果您的项目的重点是 1 而不是另一个。您同样需要平衡人力（例如，摄影师互动博客可能主要需要设计师和界面人员来WOW，其中大多数照片数据库代码可能会从已经完成的或开源项目中重用（这是最重要的项目之一）我遇到的常见工作）
Sadly good graphical/Ui designer, that is able to design/code in flash are rare jewels... For JavaScript: they are non-existent (at least for me in my country);
So the workflow that I work with (for designers) take this into account, and stays the same for my flash/JavaScript projects;
Roles
Firstly, from the designer point of view: there are 3 roles, as of followed.
1) the designer : in charge of artistic direction and graphical production.
2) the interface-r : works with the rest in implementing the graphics and animation.
3) the logic coder : Codes classes and functionality: logic isolated from interface.
Logic coder can have further sub roles, but is beyond the designer point of view. And roles should not be 100% enforced: it's good to learn and help from one another; The designer is not required to know coding, the coder does not need to know design. The interfacer however needs to know coding, and a bit of design: Not good: but know (especially animation)
work flow
1) Base functionality is worked out by everyone; while it is actually a coder role: getting everyone involved helps the idea generation progress (programers: the designers can sometime come up with really good wild ideas, your job is to logically see how it can be implemented and If it is worth doing so)
2) Mock up UI and Class interface This may be the worst UI you may ever seen, but it gives a general direction to work towards: This is done by everyone. With coder working out the isolated logic (no graphic at all; eg: sever logic) and the interfacer and designer does the mockup.
3.1) Graphic and animation the graphic designer works on their wonderful design / graphics. while the interfacer translate the designs to an actual interface (from photoshop to flash/HTML). If you are lucky, the designers would know how to do this even (slicing etc) and the interfacer focuses on implementation and animation. Any additional graphical animation (dynamic stuff, like something following or reacting to the mouse). Is to be discuss and developed by these 2. This process rarely involves the coder to step in.
3.2) The coder works on the logic while ensuring it correspond to a coding interface as agreeded with the interfacer. Focusing on getting the mockup fully functional (not the best looking). This is usually done by usually classes interface and/or global declaration (avoided if possible)
4) Interface merge The interfacer, then merges the 2 together: to form the final app. XD
Ending note
While in reality, after stage 2. The workflow goes in a contineous cycle of 3 and 4. The main advantage of having an interfacer, is to ensure the designer nor the coder slow the other down. Hence, limited slowdowns :) the interfacer however has a tough role, needing to be extremely flexible, and more often then not double as project lead in small teams. For only he will understand both sides and their limitations. Though he may not be alone nor the best at either.
Note this is used extensively in RAI when both sides are important roles. However if you have projects that has emphasis of 1 over the other. You will need to balance the manpower likewise (eg, a photographer interactive blog may mainly require the designer and interfacer to WOW instead, where most of the photo database code may be reused from already done or open source project (this is one of the most common job I encounter)