sillydaddy 最近的时间轴更新
sillydaddy

sillydaddy

V2EX 第 472822 号会员,加入于 2020-02-27 19:30:20 +08:00
今日活跃度排名 966
[原创]4 千字长文,对原型工具的抽象分析
设计  •  sillydaddy  •  1 小时 35 分钟前  •  最后回复来自 sillydaddy
14
原创!在文章中添加“文字指纹”,追踪盗版源头
  •  1   
    奇思妙想  •  sillydaddy  •  9 天前  •  最后回复来自 c0xt30a
    103
    人 vs 猩猩,还是,人 ps 猩猩
    奇思妙想  •  sillydaddy  •  17 天前  •  最后回复来自 varzy
    4
    m1 mba 的白色文字太刺(亮)眼
    MacBook Pro  •  sillydaddy  •  20 天前  •  最后回复来自 morize
    24
    sillydaddy 最近回复了
    1 小时 35 分钟前
    回复了 sillydaddy 创建的主题 设计 [原创]4 千字长文,对原型工具的抽象分析
    @no1xsyzy
    高保真的交互,对于演示是最有帮助的,可以亲自体验,看视频和亲自操作肯定有差别。
    然后对于建立产品的完整感觉也有帮助,因为所有的交互都集成在一起了,切换体验不同的场景很方便。

    不过这些应该是到后面再做的。
    1 小时 40 分钟前
    回复了 sillydaddy 创建的主题 设计 [原创]4 千字长文,对原型工具的抽象分析
    @no1xsyzy
    想了一下,可能自己潜意识里一直想的是直接在原型上做产品概念的迭代,所以总想着要把原型一次做到位,后续把它作为迭代的基础,因为代表真实产品的样子嘛!想想其实大部分的原型应该只要示意图+说明,或者你说的多个贫血原型就足够了。毕竟涉及到交互的迭代还是占的比例很小,而产品设计的迭代占的比例更大,可以直接在低保真上面迭代。
    3 小时 20 分钟前
    回复了 sillydaddy 创建的主题 设计 [原创]4 千字长文,对原型工具的抽象分析
    @no1xsyzy
    我刚想起了一个具体的例子。可以表达清楚我的想法。

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

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

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

    如果设计师想让开发做的就是这种效果,那用言语表达肯定是难以沟通的,而正好是原型发挥作用的地方。设计师 mock 出来的这个东西,因为不完整所以也不能编译后用在真实的产品中。
    3 小时 51 分钟前
    回复了 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 时用的数据,以及呈现界面的方式,可以跟真实的代码逻辑有很大不同,虽然看起来一样,用起来一样,但总感觉少点啥,应该是因为复用比较难吧。
    5 小时 19 分钟前
    回复了 sillydaddy 创建的主题 设计 [原创]4 千字长文,对原型工具的抽象分析
    @no1xsyzy > “这三点其实原本是针对你上次提出的相对复杂的界面显隐逻辑的”
    哦。本来想着写完这篇主题再 @你一下的。但给忘记了。
    我比较怀疑界面的显隐逻辑能够变得复杂。上次主题说的复杂,主要是针对,界面在一系列操作之后,得到的结果数量可能非常多。比如我举的例子里面,N 多个显示元素都有各自的内部状态,而且可以自由操作,那么在一个页面上点击多次后,会形成复杂的组合。但界面本身的操作逻辑,并不复杂。之所以提到这个“数量组合爆炸”,是因为如果原型工具提供的功能本身不能消减这种组合爆炸,会导致有些原型制作不出来,而这些原型本身的逻辑很简单。
    最简单的一个例子,如果你尝试用 Figma 做一个界面上有很多个组件的页面,然后在页面上可以对每个组件独立交互,然后有个组件可以稍微影响某个其他的组件(也就是说界面的逻辑根本不复杂)。你会发现它用 overlay(覆盖层)来模拟组件状态变换的制作方式,会让人崩溃。所以 Figma 或者 Sketch 等工具,侧重点就在于界面的高保真设计,对于交互,它们只提供最基本的。

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

    > “在复杂的逻辑下,你要去发现某个 input 的逻辑是 check1 && check2 && check7 || check3 && check6,这显然强人所难。”
    如果说某个 input 能否输入,受控于这 5 个 checkbox 的状态,那么,这个逻辑是可以很直接的得出的,或者说是很直观的,哪怕是对于设计师,不需要经过多次步骤的运算得出这个逻辑表达式,而是一步就能得到。这也有点类似主题里说的“条件判断”,在用户对某个页面随意操作后,用户想把页面上的填充或选择作为输入,做下一步的业务操作,这里原型工具可以判断一下各个填充或者选择是否符合预设的条件,这个条件也许比较复杂,但不需要设计师去计算,而是可以直观一步得出的。我是这样想的,因为实在想不到界面上会产生复杂的逻辑流,如果确实产生了,那大概率是因为牵涉到了底层的业务逻辑,由业务驱动产生的数据变化反映在了界面上,这种情况又回到原型本身的能力边界讨论上了。
    6 小时 53 分钟前
    回复了 sillydaddy 创建的主题 设计 [原创]4 千字长文,对原型工具的抽象分析
    @no1xsyzy #3 >“打个比方,排版的时候,要么是 LaTeX 这种更抽象地描述的,要么是 Word 这种 WYSIWYG 的,你不太可能拿着 PostScript 这种拥有所有精确的底层功能的用。”

    其实原型工具本身就是 mock(“假装”)实际产品的交互效果的。比如你真实产品在加载数据的时候,是根据互联网上获取的数据,来逐渐填充页面内容的。到了原型工具这里,会直接给不同的页面内容设置不同的延迟,就能做出这种效果了,而且仅仅从界面和互动上看,100%保真。这种其实是不需要抽象的底层功能的。或者说,所需的抽象,远远不如真实产品那样复杂。如主题中所提到的,仅仅一个线性映射(比如 Principle 所用),就可以 mock 绝大部分的界面交互效果。因此也不会带来更大的操作难度。
    7 小时 10 分钟前
    回复了 sillydaddy 创建的主题 设计 [原创]4 千字长文,对原型工具的抽象分析
    其实我还是偏向你说的“充血原型”的,也就是能将真正产品的界面、交互、业务逻辑展现出来的。用设计界的术语叫“高保真”。

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

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

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

    > 3. 不要让前端自己猜或者自己从原型工具中挖掘逻辑
    你说的是从制作好的原型中挖掘交互逻辑吧?对于高保真原型,不存在这个问题啊,高保证原型展示的是真实产品的交互逻辑。页面怎么操作,是跟真实产品一样的。当然,原型想要做的好,需要对某个页面上可以执行哪些操作,要有必要的提示。现在的原型工具很多也能做到。可以看一下主题里“原型工具需要支持条件判断”那段描述。
    9 小时 0 分钟前
    回复了 sillydaddy 创建的主题 设计 [原创]4 千字长文,对原型工具的抽象分析
    @no1xsyzy
    嗯。这篇主要是从原型工具的完备性的角度谈的。

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

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

    其他有些原型工具也是这样的。本来是有实现某些东西的能力,但是这些能力却漏掉了一些情景。这就不是“贫血”和“充血”的选择问题了,而是不完备。
    1 天前
    回复了 chogath 创建的主题 生活 如何突围一潭死水一样的人生
    @37Y37 #39
    这么想的人很多。只是要不要做乌贼——自己是脱身了,但在整个社会变成大墨缸的过程中,也有自己出的一份力。
    我自己想看那种讲解具体应用案例的。怎么收集数据、怎么构建模型、怎么构建环境、怎么训练调参。。
    关于   ·   帮助文档   ·   FAQ   ·   API   ·   我们的愿景   ·   广告投放   ·   感谢   ·   实用小工具   ·   2563 人在线   最高记录 5497   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 18ms · UTC 11:18 · PVG 19:18 · LAX 04:18 · JFK 07:18
    ♥ Do have faith in what you're doing.