sillydaddy 最近的时间轴更新 sillydaddy 最近的时间轴更新 |
sillydaddyV2EX 第 472822 号会员，加入于 2020-02-27 19:30:20 +08:00今日活跃度排名 6155 |
| 可以限定 macOS App 只能访问某个**子**文件夹吗？ macOS • sillydaddy • 1 天前 • 最后回复来自 billlee | 6 |
| [原创]4 千字长文，对原型工具的抽象分析 设计 • sillydaddy • 3 天前 • 最后回复来自 no1xsyzy | 15 |
| 迫于帖子荒，发个创意十足的“折纸”程序，并看看折纸界的“hello world” 分享发现 • sillydaddy • 9 天前 • 最后回复来自 fffang | 1 |
| 你们用的原型工具，是怎样做到页面内部的不同显示效果切换的呢？ 设计 • sillydaddy • 9 天前 • 最后回复来自 no1xsyzy | 4 |
| 苹果上架了几台 m1 的官翻机，有需要的上， air 和 pro 优惠信息 • sillydaddy • 8 天前 • 最后回复来自 liangguge696 | 16 |
| 原创！在文章中添加“文字指纹”，追踪盗版源头
1 奇思妙想 • sillydaddy • 12 天前 • 最后回复来自 c0xt30a
|
103 |
| 对 Framer 真是相见恨晚，发一些感概。请进来聊聊对原型工具的理解吧。 设计 • sillydaddy • 11 天前 • 最后回复来自 xingzhi | 26 |
| 人 vs 猩猩，还是，人 ps 猩猩 奇思妙想 • sillydaddy • 20 天前 • 最后回复来自 varzy | 4 |
| 能不能应用密码学，解决订单操纵，实现收益分摊？ 奇思妙想 • sillydaddy • 12 天前 • 最后回复来自 israinbow | 42 |
| m1 mba 的白色文字太刺(亮)眼 MacBook Pro • sillydaddy • 24 天前 • 最后回复来自 morize | 24 |
sillydaddy 最近回复了
1 天前 回复了 sillydaddy 创建的主题 › macOS › 可以限定 macOS App 只能访问某个**子**文件夹吗？ |
1 天前 回复了 sillydaddy 创建的主题 › macOS › 可以限定 macOS App 只能访问某个**子**文件夹吗？ |
App 可能不是 Mac App Store(官方应用商店)下载的
1 天前 回复了 3dwelcome 创建的主题 › 程序员 › 友情联动：发支付宝口令红包，欢迎大家破解. |
1 天前 回复了 3dwelcome 创建的主题 › 分享发现 › 看了 Windows 的 GUID 生成算法，惊掉我下巴。 |
是的。
就是#43 楼的 @swulling 提到的概率。
如果觉得 50%概率太高，可以换一个说法：每秒产出千万个 uuid，连续产出 85 年，才有百万分之五十的概率存在一次碰撞。如果换成每秒百万个 uuid，那么 85 年产生一次碰撞的概率就是一亿分之五十。
典型的“生日问题”：( https://zh.wikipedia.org/wiki/生日問題 )，里面有概率的计算公式。
就是#43 楼的 @swulling 提到的概率。
如果觉得 50%概率太高，可以换一个说法：每秒产出千万个 uuid，连续产出 85 年，才有百万分之五十的概率存在一次碰撞。如果换成每秒百万个 uuid，那么 85 年产生一次碰撞的概率就是一亿分之五十。
典型的“生日问题”：( https://zh.wikipedia.org/wiki/生日問題 )，里面有概率的计算公式。
2 天前 回复了 3dwelcome 创建的主题 › 程序员 › 友情联动：发支付宝口令红包，欢迎大家破解. |
@matrix67 #7
真是神帖啊。浪费了一个小时，不过看得过瘾，哈哈。
是不是马甲，每个人都心里有数。
不过也真巧，正好应了我在 4 楼提到的“文字指纹”——可以把各方的发言找出来，验一验文字指纹就知道了，这事有够无聊，也挺有意思 ( 逃
真是神帖啊。浪费了一个小时，不过看得过瘾，哈哈。
是不是马甲，每个人都心里有数。
不过也真巧，正好应了我在 4 楼提到的“文字指纹”——可以把各方的发言找出来，验一验文字指纹就知道了，这事有够无聊，也挺有意思 ( 逃
2 天前 回复了 3dwelcome 创建的主题 › 程序员 › 友情联动：发支付宝口令红包，欢迎大家破解. |
同意 3 楼。
看看我设计的“文字指纹”是怎么惨被差分攻击破解的：( /t/774059 )
看看我设计的“文字指纹”是怎么惨被差分攻击破解的：( /t/774059 )
3 天前 回复了 sillydaddy 创建的主题 › 设计 › [原创]4 千字长文，对原型工具的抽象分析 |
@no1xsyzy
高保真的交互，对于演示是最有帮助的，可以亲自体验，看视频和亲自操作肯定有差别。
然后对于建立产品的完整感觉也有帮助，因为所有的交互都集成在一起了，切换体验不同的场景很方便。
不过这些应该是到后面再做的。
高保真的交互，对于演示是最有帮助的，可以亲自体验，看视频和亲自操作肯定有差别。
然后对于建立产品的完整感觉也有帮助，因为所有的交互都集成在一起了，切换体验不同的场景很方便。
不过这些应该是到后面再做的。
3 天前 回复了 sillydaddy 创建的主题 › 设计 › [原创]4 千字长文，对原型工具的抽象分析 |
@no1xsyzy
想了一下，可能自己潜意识里一直想的是直接在原型上做产品概念的迭代，所以总想着要把原型一次做到位，后续把它作为迭代的基础，因为代表真实产品的样子嘛！想想其实大部分的原型应该只要示意图+说明，或者你说的多个贫血原型就足够了。毕竟涉及到交互的迭代还是占的比例很小，而产品设计的迭代占的比例更大，可以直接在低保真上面迭代。
想了一下，可能自己潜意识里一直想的是直接在原型上做产品概念的迭代，所以总想着要把原型一次做到位，后续把它作为迭代的基础，因为代表真实产品的样子嘛！想想其实大部分的原型应该只要示意图+说明，或者你说的多个贫血原型就足够了。毕竟涉及到交互的迭代还是占的比例很小，而产品设计的迭代占的比例更大，可以直接在低保真上面迭代。
3 天前 回复了 sillydaddy 创建的主题 › 设计 › [原创]4 千字长文，对原型工具的抽象分析 |
@no1xsyzy
我刚想起了一个具体的例子。可以表达清楚我的想法。
下面这个是 React 写的一个组件，可以交互式操作的。链接里面有动图，表现怎样以交互方式修改一棵树的结构。
https://github.com/frontend-collective/react-sortable-tree
虽然它看起来是纯界面的东西，但其实连续的多次操作涉及到了后面的数据结构(树状列表)，在不编程的情况下，是非常难以用原型工具把它做出来的，正像你说的，如果能做出，那离 WYSIWYG 就一步远了。
但是，原型工具是可以 mock(模拟)出它的单次操作的交互效果的，而且可以保证交互效果完全一致——甚至鼠标连续移动对应的连续状态变化也可以做出来，而不需要引入编程。这就是用前面说的，针对“拖拽条目排序”这种业务操作，选取一条预设的演示路径，拖拽预设的条目到预设的位置。什么是界面操作，什么是业务操作，也不是绝对的，这个例子可以给人很多启发。
如果设计师想让开发做的就是这种效果，那用言语表达肯定是难以沟通的，而正好是原型发挥作用的地方。设计师 mock 出来的这个东西，因为不完整所以也不能编译后用在真实的产品中。
我刚想起了一个具体的例子。可以表达清楚我的想法。
下面这个是 React 写的一个组件，可以交互式操作的。链接里面有动图，表现怎样以交互方式修改一棵树的结构。
https://github.com/frontend-collective/react-sortable-tree
虽然它看起来是纯界面的东西，但其实连续的多次操作涉及到了后面的数据结构(树状列表)，在不编程的情况下，是非常难以用原型工具把它做出来的，正像你说的，如果能做出，那离 WYSIWYG 就一步远了。
但是，原型工具是可以 mock(模拟)出它的单次操作的交互效果的，而且可以保证交互效果完全一致——甚至鼠标连续移动对应的连续状态变化也可以做出来，而不需要引入编程。这就是用前面说的，针对“拖拽条目排序”这种业务操作，选取一条预设的演示路径，拖拽预设的条目到预设的位置。什么是界面操作，什么是业务操作，也不是绝对的，这个例子可以给人很多启发。
如果设计师想让开发做的就是这种效果，那用言语表达肯定是难以沟通的，而正好是原型发挥作用的地方。设计师 mock 出来的这个东西，因为不完整所以也不能编译后用在真实的产品中。
3 天前 回复了 sillydaddy 创建的主题 › 设计 › [原创]4 千字长文，对原型工具的抽象分析 |
@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 时用的数据，以及呈现界面的方式，可以跟真实的代码逻辑有很大不同，虽然看起来一样，用起来一样，但总感觉少点啥，应该是因为复用比较难吧。
对于这个 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 时用的数据，以及呈现界面的方式，可以跟真实的代码逻辑有很大不同，虽然看起来一样，用起来一样，但总感觉少点啥，应该是因为复用比较难吧。
Select Language