V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
V2EX  ›  also24  ›  全部回复第 53 页 / 共 286 页
回复总数  5701
1 ... 49  50  51  52  53  54  55  56  57  58 ... 286  
2021-04-13 01:32:24 +08:00
回复了 Latin 创建的主题 分享发现 [非推广]红警在线版
感觉这篇文章,和这个帖子有很大关联

https://mp.weixin.qq.com/s/nvSaf2qTr4usvwOHALp00g
2021-04-07 21:10:28 +08:00
回复了 whcoding 创建的主题 问与答 大佬们 问一下 nuc8i7beh 黑苹果做主力开发机怎么样 ?
i7 版本对比 i5 版本优势非常小,建议 i5 版就行。

带两块 4K 没感觉到啥问题,也尝试过一段时间将分辨率调整为 2K hidpi (相当于渲染 5K )单屏,没啥特殊的感觉。


另:使用 10.15.7 系统,而不是 bug sur
2021-04-07 00:24:01 +08:00
回复了 1258280950 创建的主题 问与答 买的惠普台式机装了一张假的显卡!
@ajaxfunction
@1258280950
@ajaxfunction
@privil
楼上的几位不会以为这是一张真的 GT730 吧,注意核心代号 GF116,ROPs 8,这卡撑死是一张 GTS450 而已。

https://zh.wikipedia.org/wiki/NVIDIA%E9%A1%AF%E7%A4%BA%E6%A0%B8%E5%BF%83%E5%88%97%E8%A1%A8#GeForce_400


这不禁让我想起了这个视频:
https://www.bilibili.com/video/BV13p4y1a7i9
2021-04-07 00:00:37 +08:00
回复了 haruhi 创建的主题 分享发现 令人绝望的 Android 后退、主页、多任务 Navbar 设计
@haruhi #65
关于 『点击 Navbar 的后退是回到上一个 App,而不是在当前 App 里后退』

其实是很好理解的,因为 Android 系统的返回按钮,是在『 APP 外』的:
那么自然是以 APP 外(系统)的视角来后退页面,也就是上一个 APP 内。

如果想要 『在当前 App 里后退』,那很简单啊,需要点击『 APP 内』的后退按钮:
也就是点击 "Up Button",结果也是符合预期的,返回了 『 APP 内』的上一个页面。


iOS 的返回按钮为什么符合你的想法,因为 iOS 只有『 APP 内』的返回按钮啊。
2021-04-06 23:54:49 +08:00
回复了 haruhi 创建的主题 分享发现 令人绝望的 Android 后退、主页、多任务 Navbar 设计
@haruhi #64
感谢,想起来了,我第一次吐槽这东西应该就是吐槽这个 Today 精选,它真的是太丢 iOS 的脸面了。
2021-04-06 23:47:31 +08:00
回复了 haruhi 创建的主题 分享发现 令人绝望的 Android 后退、主页、多任务 Navbar 设计
@haruhi #62
1 、(一个全新的)用户首次遇到这个场景的时候,不管是 Android 还是 iOS,都不存在明确的预期。
只有当已经使用了一些 APP 之后,积攒了使用经验才会带来预期,如果大家都遵循规范,那预期就会更『准确』。
所谓的预期,实际上就是该平台下交互方式的『趋同』状态。


2 、如我在 45# 所说,换到 iOS 平台上,这个例子仍然是会引发迷惑的,因为不同的应用对 『连续打开两条 Tweet 』这个情况的处理不同,导致部分应用会返回 Tweet A,部分应用会返回 Twitter 首页。
对于文章中的 『永远都指向一个行为』我表示不认同。

同样的我在 45# 也提到了,Android 对于这种场景,是有规范的,只是很多人不遵守而已;
iOS 对这种场景,却是连个规范都没有,我认为 iOS 在这个场景下表现,实际上是更差的。
(深究原因的话,我觉得是因为这是一个『多窗口』场景,详见 41# )

3 、虽然我确实是开发,但我不认为这部分属于研发角度,更应当属于交互设计方面,这实际上是与应用自身的逻辑结构相关的,而应用自身的逻辑结构,决定了交互的大框架。


题外话:
实际上,这个事情压根不适合拿 iOS 和 Android 来比较优劣,因为二者压根不是一个东西。
拿 iOS 的设计逻辑来套 Android,或者 Android 的设计逻辑来套 iOS,都是非常不合理的。

我更建议在各自的体系之内,从其自身本源的设计逻辑上入手来查缺补漏。
2021-04-06 19:43:56 +08:00
回复了 antiy 创建的主题 职场话题 毕业学长分享就业经验
去年哈理工计算机专业毕业,然后 7 年前就发帖招聘了? /t/131952
2021-04-06 17:30:32 +08:00
回复了 haruhi 创建的主题 分享发现 令人绝望的 Android 后退、主页、多任务 Navbar 设计
@abersheeran #54
没必要先划定标签,这样是不利于清晰的讨论问题的。
爱之深恨之切,有一些尖锐的声音,往往是重度使用群体才会发出的。

其实看看楼主的博客,楼主更像是一个 Android 粉,或者说的严谨一点:Pixel 历代机型使用者。
https://bilibi.li/2020/05/02/google-pixel-4-xl-review
2021-04-06 15:25:47 +08:00
回复了 haruhi 创建的主题 分享发现 令人绝望的 Android 后退、主页、多任务 Navbar 设计
@mygreens #48
单纯 『从左往右滑的语义』这部分,我觉得没有任何问题。

甚至于,这是比底部的虚拟返回键更明确的语义,因为『按照规范』来说,这时候『 task 栈的逻辑一定是返回上一个页面』,这是非常明确的。

该死的是谁?该死的是那些不按照规范设计的,『 task 栈的逻辑不一定是返回上一个页面』的 APP,是他们导致了这个不明确,而不是完全遵照规范设计的 Android 的手势。
2021-04-06 15:08:20 +08:00
回复了 haruhi 创建的主题 分享发现 令人绝望的 Android 后退、主页、多任务 Navbar 设计
@mygreens #43
我一直强调谷歌的规范,按规范来说,是很明确的,此时一定是返回微信。
(至少从 2015 年至今,谷歌从未修改过这个规范)


实际上,楼主文章中举的例子,在 iOS 上的动作同样是不明确的:
a. 当用户打开一个 Twitter,并点开了 Tweet A ;
b. 然后用户去 Chrome 里搜索一个内容,搜索结果里有另一条 Tweet B,用户很感兴趣,点击了这条搜索结果;
c. 这时候浏览器跳出,自动打开了 Twitter 应用,并跳转到了 Tweet B,这时候,用户点击后退,是应该回到 Tweet A,还是回到浏览器的搜索结果?


在 iOS 上,步骤 C 的迷惑略有不同:
这时候,用户点击后退,是应该回到 Tweet A,还是回到 Twitter 应用的首页?


需要注意的是,iOS 是没有针对这种场景的规范的(至少我没翻到);
可能有点沾边的是 HIG 中的 Navigation 部分,暗示了不同类型的 Navigation 可以采取不同的方式处理:
https://developer.apple.com/design/human-interface-guidelines/ios/app-architecture/navigation/
2021-04-06 14:40:49 +08:00
回复了 haruhi 创建的主题 分享发现 令人绝望的 Android 后退、主页、多任务 Navbar 设计
继续补充一下关于 Android 的 Task 机制,这个机制为什么在文档上看起来非常复杂呢?

实际上,这个机制对应的就是 『单应用多窗口』,这个在桌面操作系统上习以为常的功能。
而 iOS 系统,实际上一直只支持 『单应用单窗口』,只有在 iPadOS 之后,才引入了 『单应用多窗口』。

『单应用多窗口』的最常见应用场景,就是微信小程序:
Android 上的微信小程序,是可以展示为和微信同一层级的独立 Task 的,可以直接在多任务界面切换。
而 iOS 系统由于只支持『单应用单窗口』,就需要先切换到 wechatOS,再选择具体的小程序。

当然,在小小的手机屏幕上,引入这种重量级的功能,许多 APP 又不适配,选择将自己做成『单应用单窗口』形态,那必然会引起更多的麻烦,包括对返回键的适配难题。
这样来想,这可能也是为什么 Apple 只在尺寸更大的 iPadOS 上引入这个功能吧。

以上,无关优劣,各有取舍罢了。
2021-04-06 14:25:53 +08:00
回复了 haruhi 创建的主题 分享发现 令人绝望的 Android 后退、主页、多任务 Navbar 设计
@mygreens #38
『官方给的文档开发者看都晦涩,更别指望用户能理解』

这段话不太同意,Android 的这套逻辑,实际上就是为了『辛苦开发者,解放用户』,如果开发者按规矩做了适配,用户层面来说,只要体验保持一致,是没有太大的认知障碍的。
(此处要补一条:不要把其它操作系统的逻辑,先入为主的带入进来,评价 Win 和 macOS 的时候也是同理)


『最大的问题还是谷歌的短见,没有给出成熟的解决方案』

这段话同意一半:
同意的部分是在控件、手势层面上,谷歌确实是三番五次的打自己的脸,折磨开发者,自作自受。
但是在逻辑层面上,其实 Task 的概念一直都未有改变,我前面贴的关于 Task 的文档,印象中至少存在了 6~8 年左右。
2021-04-06 13:59:13 +08:00
回复了 haruhi 创建的主题 分享发现 令人绝望的 Android 后退、主页、多任务 Navbar 设计
@wipbssldo
我不太确定 iOS14 的『待办事项』是否修理了这个问题,实在懒得更新到 14 了,至少 iOS13 还是存在这个问题的。
第三方 APP 里应该也有存在这个问题的,不过需要找一下,之所以选『待办事项』,是因为它是第一方应用,更有讽刺性。

这个问题之前还是引发了大量讨论的,回头我翻一下历史。
2021-04-06 13:42:45 +08:00
回复了 haruhi 创建的主题 分享发现 令人绝望的 Android 后退、主页、多任务 Navbar 设计
@mygreens #31
『 iOS App 不乱实现的话』这段话很重要,系统提供的边缘侧滑返回,实际上是和 UINavigationController 的 Push Pop 相关的,如果你只这样使用,不触碰其它的坑,自然是不会遇到问题。

但是确实没有『乱实现』的么?翻个帖子看看: https://v2ex.com/t/669493


另外,iOS13 之后,Present Modally 的出现,加入了下拉返回的逻辑,带来了更多交互上的迷糊。
想要体验的话,打开『待办事项』,点击新建,在新建页面从左侧边缘向内侧滑,随着从左向右的手势,页面很配合的来了一个下滑的动画。


随着系统的发展、硬件的更迭,新旧交互逻辑混在一起是两家都存在的顽疾,大家都是满脸灰,真就谁也别来嘲笑谁。
至少在我看来,这些问题更大的责任方是第三方 APP,是否有研究对应平台的设计逻辑,做出与平台相匹配的产品。
1 ... 49  50  51  52  53  54  55  56  57  58 ... 286  
关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   2795 人在线   最高记录 6679   ·     Select Language
创意工作者们的社区
World is powered by solitude
VERSION: 3.9.8.5 · 48ms · UTC 12:40 · PVG 20:40 · LAX 04:40 · JFK 07:40
Developed with CodeLauncher
♥ Do have faith in what you're doing.