你如何制作原型？
我们对设计、GUI 进行原型设计，只是为了分析特定问题、概念验证等。有时我们会丢弃原型，有时它最终会出现在生产代码中。 我们使用不同的语言、技术、策略和风格来制作原型。
您通常会在哪些不同情况下进行原型设计以及如何进行原型设计？ 有什么好的资源可以掌握这门手艺吗？
We prototype a design, GUI, just to analyze a particular problem, proof of concept, etc. Sometimes we throw away the prototype, and sometimes it ends up in the production code. We use different languages, technologies, strategies, and styles to prototype.
What are the different situations you prototype usually and how do you prototype? Any good resource out there to master the craft?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（6）
我开始制作一个原型，使最有趣的部分发挥作用，然后我把它扔掉并转向一个新的、更有趣的项目......
*自杀*
I start off making a prototype that makes the most interesting part work, then I throw it away and move on to a new, more interesting project...
*kills self*
制作原型的主要原因是降低风险。 因此，我们制作 UI 原型，除非它们实际上做了用户可以玩的东西，否则实际上并没有多大帮助。 同样重要的是，我们还制作原型来证明某些东西可以工作或弄清楚某些东西是如何工作的。
The main reason for doing prototypes is reducing risk. Thus, we do UI prototypes, which are really not very helpful unless they actually do something that a user can play around with. Just as important, we also do prototypes to either prove that something can work or figure out how something does work.
对于 Web 应用程序，从纯 (x)HTML + CSS 模型开始，然后使用可以轻松实现功能的框架。
基于模板的框架对此非常有用，但我们在 JSF + Facelets + Seam 方面也有一些很好的经验。
For webapps, start with an pure (x)HTML + CSS mock-up, and then use a framework that makes it easy to implement the functionality.
Template-based frameworks are very good for this, but we've had some good experiences with JSF + Facelets + Seam, too.
现在我只是画画。 我想做更多，但要让用户比图片更容易理解，需要花费很多时间。
我有兴趣看到其中的一些回复:)
我应该提到我工作的地方只有我和另一个人扮演项目经理（收集数据、设计规范和应用程序）、数据库管理员、编码员、工具研究员/开发人员的角色等人的工作是为一家小公司制作应用程序。
Right now I just draw pictures. I would like to do more, but to get something to a point where the users would understand any better than a picture would cost to much time.
I am interested in seeing some of these responses :)
I should mention where I work is just me and one other guy to play the roles of project manager (collect data, design spec & app), dbas, coders, tool researcher/developer, et al that comes with the job of making an app for a small company.
就我个人而言，我认为真正的原型应该只不过是在纸上绘制的图表，以展示您想要实现的目标的流程。 然后，您可以使用这些记录的流程来运行多个场景，看看它是否适用于请求该功能的人。
一旦纸质原型被修改到可以工作的程度，就可以将其作为开始正确编码的基础。
此过程的好处是您最终无法在生产中实际使用原型代码，因为根本没有原型代码。 此外，与业务专家一起测试它要容易得多，因为没有任何代码可供他们理解。
Personally, I believe a true prototype should not be much more than diagrams drawn on paper to demonstrate the flow of whatever it is you are trying to achieve. You can then use these documented flows to run through several scenarios to see if it works with whoever has requested the functionality.
Once the paper prototype has been modified to a point where it works then use it as a basis to start coding properly.
The benefits of this process are that you can't end up actually using the prototype code in production because there isn't any. Also, it is much easier to test it with business experts as there is not any code for them to understand.
一个热门标题是软件制造商的有效原型。 问题在于存在多种思想流派。
快速原型设计。 使用奇特的工具； 得到
很快就完成了。
进化原型。 从原型发展到生产。
其中一些是遗留思维，基于工具原始且项目必须从一开始就精心规划的时代。 当我开始涉足这个行业时，“绿屏”字符模式应用程序非常科学，模拟起来非常痛苦。 工具和正式技术对于管理成本和风险至关重要。
这种想法被最近的一些想法所取代。
强大的工具消除了对复杂原型的需求。 HTML 模型可以快速组合在一起。 当您几乎不需要预算或计划时，它仍然是一个原型吗？
[您可以在 MS-Word 中模拟它并将其另存为 HTML。 业务分析师做这件事比指定它并让程序员做更快。]
此外，强大的工具可以降低错误的成本。 如果只需要一周的时间就可以将某些东西组合在一起（可以投入生产），那么正式的原型工作还有什么意义？
敏捷技术减少了进行如此详细的前期规划的需要。 当您将可用的东西快速交付到用户手中时，您就不需要在开始之前确保每个细微差别都正确。 它必须足够好才能被认为是进步。
可能发生的情况如下。 [隐藏的问题是：这仍然是“原型设计”吗？还是这只是一种具有强大工具的敏捷方法？]
使用 Django 等工具，您可以将基本的核心数据结构放在一起，并几乎立即使用它。 使用默认的 Django 管理页面，一旦您能够阐明数据结构并编写加载实用程序，您就应该可以启动并运行。
然后，添加围绕真实工作数据的演示文稿页面。 确保你做对了。 由于您只构建了数据模型和模板驱动的 HTML 页面，因此您的投资很小。 探索。
不断迭代，直到人们开始要求比默认管理页面中提供的交易更智能的交易。 此时，您正在从“发现”和“阐述”转向“构建”。 你做过原型设计吗？ 我想您丢弃的每个 HTML 模板都是一种原型。 就此而言，你把那些东西放在哪里了。
在整个过程中，您或多或少都可以与现场生产用户一起工作。
One hot title is Effective Prototyping for Software Makers. The issue is that there are several schools of thought.
Rapid Prototyping. Use fancy tools; get
something done soon.
Evolutionary Prototyping. Evolve from prototype to production.
Some of this is legacy thinking, based on an era where tools were primitive and projects had to be meticulously planned from the beginning. When I started in this industry, the "green-screen" character-mode applications where rocket science and very painful to mock up. Tools and formal techniques were essential to manage the costs and risks.
This thinking is trumped by some more recent thinking.
Powerful tools remove the need for complex prototypes. HTML mockups can be slapped together quickly. Is it still a prototype when you barely have to budget or plan for it?
[You can mock it up in MS-Word and save it as HTML. It's quicker for a Business Analyst to do it than to specify it and have a programmer do it.]
Also, powerful tools can reduce the cost of mistakes. If it only took a week to put something together -- production-ready -- what's the point of an formal prototype effort?
Agile techniques reduce the need to do quite so much detailed up-front planning. When you put something that works in the hands of users quickly, you don't have quite so much need to be sure every nuance is right before you start. It just has to be good enough to consider it progress.
What can happen is the following. [The hidden question is: is this still "prototyping" -- or is this just an Agile approach with powerful tools?]
Using tools like Django, you can put together the essential, core data structure and exercise it almost immediately. Use the default Django admin pages and you should be up and running as soon as you can articulate the data structures and write load utilities.
Then, add presentation pages wrapped around real, working data. Be sure you've got things right. Since you've only built data model and template-driven HTML pages, your investment is minimal. Explore.
Iterate until people start asking for smarter transactions than those available in the default admin pages. At this point, you're moving away from "discovery" and "elaboration" and into "construction". Did you do any prototyping? I suppose each HTML template you discarded was a kind of prototype. For that matter, so where the ones you kept.
The whole time, you can be working with more-or-less live, production users.