@adrianzhang

帐号解决的是不同用户的权限问题。

我想的是不同 App 的权限问题——App 只能访问给予权限的那些文件(夹)，而且这些文件(夹)可以细化。

App 可能不是 Mac App Store(官方应用商店)下载的

@GeruzoniAnsasu
我贴链接就是为了给自己写的东西引流。。哈哈
论文查重有点不太一样：抄袭论文的人总是会故意特意打乱原有的论文。但在网上留言的人，应该很少特意去掩饰自己的语言习惯。

是的。
就是#43 楼的 @swulling 提到的概率。
如果觉得 50%概率太高，可以换一个说法：每秒产出千万个 uuid，连续产出 85 年，才有百万分之五十的概率存在一次碰撞。如果换成每秒百万个 uuid，那么 85 年产生一次碰撞的概率就是一亿分之五十。

典型的“生日问题”：( https://zh.wikipedia.org/wiki/生日問題 )，里面有概率的计算公式。

@matrix67 #7
真是神帖啊。浪费了一个小时，不过看得过瘾，哈哈。
是不是马甲，每个人都心里有数。
不过也真巧，正好应了我在 4 楼提到的“文字指纹”——可以把各方的发言找出来，验一验文字指纹就知道了，这事有够无聊，也挺有意思 ( 逃

同意 3 楼。
看看我设计的“文字指纹”是怎么惨被差分攻击破解的：( /t/774059 )

@no1xsyzy
高保真的交互，对于演示是最有帮助的，可以亲自体验，看视频和亲自操作肯定有差别。
然后对于建立产品的完整感觉也有帮助，因为所有的交互都集成在一起了，切换体验不同的场景很方便。

不过这些应该是到后面再做的。

@no1xsyzy
想了一下，可能自己潜意识里一直想的是直接在原型上做产品概念的迭代，所以总想着要把原型一次做到位，后续把它作为迭代的基础，因为代表真实产品的样子嘛！想想其实大部分的原型应该只要示意图+说明，或者你说的多个贫血原型就足够了。毕竟涉及到交互的迭代还是占的比例很小，而产品设计的迭代占的比例更大，可以直接在低保真上面迭代。

@no1xsyzy
我刚想起了一个具体的例子。可以表达清楚我的想法。

下面这个是 React 写的一个组件，可以交互式操作的。链接里面有动图，表现怎样以交互方式修改一棵树的结构。
https://github.com/frontend-collective/react-sortable-tree

虽然它看起来是纯界面的东西，但其实连续的多次操作涉及到了后面的数据结构(树状列表)，在不编程的情况下，是非常难以用原型工具把它做出来的，正像你说的，如果能做出，那离 WYSIWYG 就一步远了。

但是，原型工具是可以 mock(模拟)出它的单次操作的交互效果的，而且可以保证交互效果完全一致——甚至鼠标连续移动对应的连续状态变化也可以做出来，而不需要引入编程。这就是用前面说的，针对“拖拽条目排序”这种业务操作，选取一条预设的演示路径，拖拽预设的条目到预设的位置。什么是界面操作，什么是业务操作，也不是绝对的，这个例子可以给人很多启发。

如果设计师想让开发做的就是这种效果，那用言语表达肯定是难以沟通的，而正好是原型发挥作用的地方。设计师 mock 出来的这个东西，因为不完整所以也不能编译后用在真实的产品中。

@no1xsyzy
对于这个 Apply - Cancel - OK，我倾向于认为它是业务逻辑，而不是界面逻辑。

界面逻辑就是界面元素之间如何互动。比如对于 7 楼提到的例子，就是父级 checkbox 与子级 checkbox 间的交互互动。再比如对于 PageScroll(滚动翻页)来说，业务数据已经完全交付在页面中的 Container(容器)里面了，然后后续的滑动、翻页这些交互都是界面范畴的交互，而不再涉及业务和数据的处理了。类似的例子还有很多。

Apply-Cancel-OK，如果要演示的话，也只需要一条典型的演示路径就可以。比如我在原型的设置页面 A 里面，设置一些选项配置。然后点击 Apply-Cancel-OK，观察配置所引起的效果，就要切换到页面 B 。(页面 B 体现的是设置对后台数据的影响，哪怕只是这个产品的一些设置项，对于原型来说，也是产品的后台数据)。原型是不可能做到针对页面 A 里的每个不同的配置组合，都修改对应的产品数据的。所以原型能做的就是，在页面 A 中，允许自由交互，但在点击 Apply-Cancel-OK 时，提示只能应用预设的数据，然后再展示预设的页面 B 。这对于演示 Apply-Cancel-OK 的逻辑，完全没有问题。

> “你的设计不符合直观，那就是糟糕设计；符合直观，就不需要搞充血原型”
我还是觉得是一图胜千言。尤其是对于动效来说。

>“另一方面就是其实和 WYSIWYG 一步之遥。这个原型写出来能不能直接编译到”
这个我觉得 mock 出来某个效果，跟实际去做某个效果，工作量还是差不少的。首先 2 者依赖的工具或框架不同，你说的直接编译其实 FramerX 就在做，它的原型是基于 React 来做显示的，原型组件对应的 React 组件可以直接用在产品上。但像 Principle 或 Origami 这些工具，它们提供的交互效果依赖于它们自己提供的环境去运行，估计也很难脱离出来。再者，mock 时用的数据，以及呈现界面的方式，可以跟真实的代码逻辑有很大不同，虽然看起来一样，用起来一样，但总感觉少点啥，应该是因为复用比较难吧。

@no1xsyzy > “这三点其实原本是针对你上次提出的相对复杂的界面显隐逻辑的”
哦。本来想着写完这篇主题再 @你一下的。但给忘记了。
我比较怀疑界面的显隐逻辑能够变得复杂。上次主题说的复杂，主要是针对，界面在一系列操作之后，得到的结果数量可能非常多。比如我举的例子里面，N 多个显示元素都有各自的内部状态，而且可以自由操作，那么在一个页面上点击多次后，会形成复杂的组合。但界面本身的操作逻辑，并不复杂。之所以提到这个“数量组合爆炸”，是因为如果原型工具提供的功能本身不能消减这种组合爆炸，会导致有些原型制作不出来，而这些原型本身的逻辑很简单。
最简单的一个例子，如果你尝试用 Figma 做一个界面上有很多个组件的页面，然后在页面上可以对每个组件独立交互，然后有个组件可以稍微影响某个其他的组件(也就是说界面的逻辑根本不复杂)。你会发现它用 overlay(覆盖层)来模拟组件状态变换的制作方式，会让人崩溃。所以 Figma 或者 Sketch 等工具，侧重点就在于界面的高保真设计，对于交互，它们只提供最基本的。

我现在能想到的最复杂的界面逻辑，就是下面这个：
1 个父 checkbox，下面有 2 个子 checkbox 。
触发选中 /取消选中父 checkbox 时，子 checkbox 也随之选中 /取消选中，不管它们当前处于什么状态；
而触发选中 /取消选中每个子 checkbox 时，该子 checkbox 也会切换选中 /取消选中，而不受父 checkbox 当时状态的影响。

> “在复杂的逻辑下，你要去发现某个 input 的逻辑是 check1 && check2 && check7 || check3 && check6，这显然强人所难。”
如果说某个 input 能否输入，受控于这 5 个 checkbox 的状态，那么，这个逻辑是可以很直接的得出的，或者说是很直观的，哪怕是对于设计师，不需要经过多次步骤的运算得出这个逻辑表达式，而是一步就能得到。这也有点类似主题里说的“条件判断”，在用户对某个页面随意操作后，用户想把页面上的填充或选择作为输入，做下一步的业务操作，这里原型工具可以判断一下各个填充或者选择是否符合预设的条件，这个条件也许比较复杂，但不需要设计师去计算，而是可以直观一步得出的。我是这样想的，因为实在想不到界面上会产生复杂的逻辑流，如果确实产生了，那大概率是因为牵涉到了底层的业务逻辑，由业务驱动产生的数据变化反映在了界面上，这种情况又回到原型本身的能力边界讨论上了。

@no1xsyzy #3 >“打个比方，排版的时候，要么是 LaTeX 这种更抽象地描述的，要么是 Word 这种 WYSIWYG 的，你不太可能拿着 PostScript 这种拥有所有精确的底层功能的用。”

其实原型工具本身就是 mock(“假装”)实际产品的交互效果的。比如你真实产品在加载数据的时候，是根据互联网上获取的数据，来逐渐填充页面内容的。到了原型工具这里，会直接给不同的页面内容设置不同的延迟，就能做出这种效果了，而且仅仅从界面和互动上看，100%保真。这种其实是不需要抽象的底层功能的。或者说，所需的抽象，远远不如真实产品那样复杂。如主题中所提到的，仅仅一个线性映射(比如 Principle 所用)，就可以 mock 绝大部分的界面交互效果。因此也不会带来更大的操作难度。

其实我还是偏向你说的“充血原型”的，也就是能将真正产品的界面、交互、业务逻辑展现出来的。用设计界的术语叫“高保真”。

1. 界面高保真： 这块太容易理解了，不多说了，也不在主题的讨论范围呢。
2. 交互高保真：意思是，别管你底层的业务逻辑多复杂，原型上展现的界面，基本就是真实产品的界面。真实产品上能够交互的显示元素，也要能在原型上交互。当然，这个前提是，只是界面的交互，而不能涉及到产品的复杂逻辑。这点是原型完全可以做到的。
3. 业务逻辑：原型不支持编程，肯定无法做到保真业务逻辑。在主题里也提到了原型怎样展现业务逻辑(这里的业务逻辑，在原型上的体现其实就是一连串的交互动作，可能涉及到多个页面的切换，多个页面是有复杂的因果影响的，背后是业务逻辑和数据在支撑。而原型到此应该止步了，它展现业务逻辑的方式，应该是针对某个业务场景从无数条操作路径中只取一条，来体现业务逻辑对应的页面逻辑)。

> 1. 不要在原型阶段考虑逻辑；
你说的这个逻辑是业务逻辑吗？如果是的话，原型阶段为啥不考虑呢？原型就是为了演示业务逻辑啊。

> 2. 不要指望设计人员能写对复杂逻辑；
没有复杂的逻辑，复杂的以至于需要编程才能实现的逻辑，是不能在原型工具上实现的。业务逻辑是一定会体现在界面的交互逻辑上的。复杂的业务逻辑要想体现为界面的交互逻辑，也只能拆解成一系列简单的业务操作。比如在原型上对数据任意的增删改查，哪怕是增删改查这 4 个操作各执行一遍，原型也是不可能做到的。原型能做到的是，分别针对增、删、改、查，提供一些交互，把这 4 种操作，演示一遍，而且还只能使用预设的数据。这已经是原型的能力极限了，但对于演示产品的业务逻辑，也已经足够保真了。

> 3. 不要让前端自己猜或者自己从原型工具中挖掘逻辑
你说的是从制作好的原型中挖掘交互逻辑吧？对于高保真原型，不存在这个问题啊，高保证原型展示的是真实产品的交互逻辑。页面怎么操作，是跟真实产品一样的。当然，原型想要做的好，需要对某个页面上可以执行哪些操作，要有必要的提示。现在的原型工具很多也能做到。可以看一下主题里“原型工具需要支持条件判断”那段描述。

@no1xsyzy
嗯。这篇主要是从原型工具的完备性的角度谈的。

你说的“交互有多么丰富”，即使再丰富，也是有一个顶的，是能够达到的。

原型工具本来就是各有侧重的。但有一个问题：
比如说某个原型工具甚至支持连续触发。也支持组件，也支持动作。但却不支持一个触发对应多个动作。
对，我说的就是 Principle 。

其他有些原型工具也是这样的。本来是有实现某些东西的能力，但是这些能力却漏掉了一些情景。这就不是“贫血”和“充血”的选择问题了，而是不完备。

@37Y37 #39
这么想的人很多。只是要不要做乌贼——自己是脱身了，但在整个社会变成大墨缸的过程中，也有自己出的一份力。

我自己想看那种讲解具体应用案例的。怎么收集数据、怎么构建模型、怎么构建环境、怎么训练调参。。

@AlwaysBee 楼主真是高产哪

思路很不错，甚至发起协助的操作都放在协助者这边了。

为啥你们都是学几天然后不熟就能做出这种效果呢？ ？？
收藏学习了。