Weavely

Weavely 是什么

这里的表单是在一个设计应用里拼装出来的。组件来自那个程序中的组件库，所以它长什么样是在设计师已经在工作的地方决定的，而不是在一个提供固定版式的编辑器里。

发布出来的成果是一个带逻辑、有答案去处的可用 Web 表单，而这通常正是逼着设计师把工作交给会做这件事的人的那个节点。先要说明：厂商自己的地址返回未找到，完整域名与缩写域名都是，所以这里没有任何内容来自它的营销页——这些依据来自帮助页面，以及它在一个设计工具社区里的条目。

你可以用它做什么

元素从那个组件库里拖进来，设计直接上线成一个可交互的东西，而不是被导出成一张图片。

逻辑可以依赖前面的回答，题目因此出现或消失，这就是表单与文档里的问卷之间的差别。答案被收集起来并可通过连接转发，结果可以到达工作继续的地方，而不是留在一个工具里。外观像一个设计文件一样自由，这正是全部论点：常规构建器的限制消失了，需要开发者这件事也跟着消失。价格完全读不到，因为没有可访问的价格页；运营主体、发布日期与作者在任何可获取的地方都没有出现。

适合谁使用

需要表单精确匹配品牌、不愿接受构建器提供什么就用什么的设计师与产品团队。

接下来是替客户做东西的工作室与小型团队，因为一个长得不一样的表单，恰好是客户会注意到、并且为之付费的东西之一。

想要「没人能悄悄弄坏」的逻辑的团队，可能更适合带内置校验的传统构建器。在外观就是客户购买的东西的地方，这个工具把「表单该长什么样」的争论消掉了。

需要留意什么

填进表单的答案是个人信息进入一家公司的路径，而把一个表单上线就意味着接手相应义务：每个字段都要有合法依据、一句目的说明、一个留存期限，以及一条让人可以要求删除的路径。把它设计得好看不能免除其中任何一项，而定制的表单读起来比朴素表单更可信，这会加强而不是削弱把「你在收集什么」说清楚的责任。

同理，脱离工程师拼装出来的问卷也是题目不断增殖的地方。只因为设计者一时想到就索要别人的出生日期或政府编号，这是在收集受保护信息却没有说明理由，而让这个工具有吸引力的那份自由，并不附带构建器可能会给的那种「为什么需要这个字段」的提示。当它嵌在访客认识的站点里，没有任何东西告诉访客究竟是哪一个服务在接收答案，所以由哪一方处理答案、数据存放在哪个国家，必须在任何人回复之前书面定下来——人不可能同意一份发布者自己都没读过的条款。主地址返回未找到这件事本身就是要解决的：它的文档与它在那款程序组件库里的条目都能打开，说明东西是存在的，但在依赖它之前，销售页面失效而帮助页面可用这件事应当向卖方提出。