sillydaddy 最近的时间轴更新
sillydaddy

sillydaddy

V2EX 第 472822 号会员,加入于 2020-02-27 19:30:20 +08:00
可以限定 macOS App 只能访问某个**子**文件夹吗?
macOS  •  sillydaddy  •  17 小时 14 分钟前  •  最后回复来自 billlee
6
[原创]4 千字长文,对原型工具的抽象分析
设计  •  sillydaddy  •  2 天前  •  最后回复来自 no1xsyzy
15
原创!在文章中添加“文字指纹”,追踪盗版源头
  •  1   
    奇思妙想  •  sillydaddy  •  11 天前  •  最后回复来自 c0xt30a
    103
    人 vs 猩猩,还是,人 ps 猩猩
    奇思妙想  •  sillydaddy  •  19 天前  •  最后回复来自 varzy
    4
    m1 mba 的白色文字太刺(亮)眼
    MacBook Pro  •  sillydaddy  •  23 天前  •  最后回复来自 morize
    24
    sillydaddy 最近回复了
    17 小时 57 分钟前
    回复了 sillydaddy 创建的主题 macOS 可以限定 macOS App 只能访问某个**子**文件夹吗?
    @adrianzhang

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

    我想的是不同 App 的权限问题——App 只能访问给予权限的那些文件(夹),而且这些文件(夹)可以细化。
    18 小时 18 分钟前
    回复了 sillydaddy 创建的主题 macOS 可以限定 macOS App 只能访问某个**子**文件夹吗?
    App 可能不是 Mac App Store(官方应用商店)下载的
    21 小时 41 分钟前
    回复了 3dwelcome 创建的主题 程序员 友情联动:发支付宝口令红包,欢迎大家破解.
    @GeruzoniAnsasu
    我贴链接就是为了给自己写的东西引流。。哈哈
    论文查重有点不太一样:抄袭论文的人总是会故意特意打乱原有的论文。但在网上留言的人,应该很少特意去掩饰自己的语言习惯。
    22 小时 7 分钟前
    回复了 3dwelcome 创建的主题 分享发现 看了 Windows 的 GUID 生成算法,惊掉我下巴。
    是的。
    就是#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 时用的数据,以及呈现界面的方式,可以跟真实的代码逻辑有很大不同,虽然看起来一样,用起来一样,但总感觉少点啥,应该是因为复用比较难吧。
    关于   ·   帮助文档   ·   FAQ   ·   API   ·   我们的愿景   ·   广告投放   ·   感谢   ·   实用小工具   ·   1316 人在线   最高记录 5497   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 25ms · UTC 00:22 · PVG 08:22 · LAX 17:22 · JFK 20:22
    ♥ Do have faith in what you're doing.