对分页和瀑布流的UI呈现的再次理解
之前对分页和瀑布流的理解比较简单, 就是手机滑动更适合瀑布流而电脑点击更适合分页. 今天才发现自己想简单了.
确实, 电脑上鼠标拖拉和滚动都不如手机上的手指滑动操作方便.上滑就特别适合加载新的数据.
但是,数据呈现的目的是不同的,两种方式各有优劣. 虽然瀑布流在手机上发扬光大, 但两者不是以手机或电脑来区分的.
我最近做的小程序, 需要呈现很多数据, 并且这些数据还需要增删改查. 因为是手机用, 我想当然认为瀑布流体验更好(当然实现难度也大), 就选择了用瀑布流.
然而近期发现一些问题, 用户反馈有时候数据会乱, 常常是重复. 查了下不是数据库的问题, 而是界面呈现的问题. 当然这种情况重新进入小程序也能解决. 我增加了一些控制, 在从数据库取数据的时候禁止用户操作, 但只解决了一部分问题.
最近打算用js面向对象的方法重构这部分代码, 写到增删改查的时候想到了这个问题: 在UI设计中, 瀑布流的方式是否适合呈现有大量数据的增删改查的页面?
如果增加了一个数据, 需要考虑这个数据增加的位置. 如果增加的数据排在前面已经显示的数据中, 那么就要重新请求已显示的数据. 但数据库的查询是按分页进行的, 我应该请求哪些分页? 似乎从数据增加位置之后的分页都要请求. 那么新数据增加在第几页? 需要计算,且计算结果必须和数据库自己的排序计算结果一致. 如果请求这之后的所有分页,有可能数据量非常大. 而且界面现在显示了N页, 增加1条数据变成了N页+1条, 而数据库是按页请求, 这样又不对齐了, 显示的最后一条数据要么从显示中删除, 要么再请求一整页.
删除有同样的问题. 修改操作如果修改的是排序的依据, 也存在新数据排到了哪儿的问题, 新旧位置之间的数据都要更新,或者用算法保持与数据库端一致.
这个逻辑就会变得复杂. 根源是: 数据库是按照分页方式请求的, 前端的增删操作导致前端数据和数据库数据无法对齐. 需要大量操作使两端对齐, 耗费本地计算和带宽, 感觉很不经济.
用分页就解决了, 非常简单, 增删改查后, 只要再次请求当前页就好了!即便是删除数据导致当前页消失, 也很容易计算到最近还存在数据的页是第几页.
这个问题抛给了metaso和gpt4o,两者都给出了否定的回答, 都指出分页更适合.
根据metaso给出的链接参考: https://blog.csdn.net/weixin_64051447/article/details/129420444, 其中有一个引文很重要:
滚动是延续，而点击是决定。—— Josh Porter
瀑布流就是为了不断地让用户看新的东西(新数据不断延续没有终点), 而点击是用户自己决定要看哪一部分东西.
所以瀑布流适合给用户不断地灌输新的数据, 而分页适合让用户管理数据.
贴一下gpt4o的回答, 我觉得总结得挺好
gpt4o的回答
在UI设计中，瀑布流（也称为无限滚动）是一种常见的布局方式，尤其适用于展示大量内容，例如图片库、社交媒体动态等。然而，这种布局方式在某些场景中可能并不合适，特别是在需要对大量数据进行增删改查（CRUD操作）的页面上。
瀑布流布局的优势：
- 用户体验：用户可以不间断地浏览内容，不需要经过分页的过程。
- 视觉吸引力：对于展示图像、视频等多媒体内容时，瀑布流能够更好地利用屏幕空间，看起来更加美观。
- 加载效率：通过懒加载技术，可以动态加载内容，从而减少初始加载时间，提高性能。
在增删改查页面中使用瀑布流可能的问题：
- 可查找性差：当用户需要查找特定数据时，瀑布流不如分页结构直观。无限滚动让定位特定记录变得困难。
- 数据管理复杂：频繁的数据增删操作可能导致数据的顺序和显示出现问题，需要复杂的逻辑进行维护。
- 浏览状态难以保存：用户在进行编辑后需要返回列表时，不容易恢复到之前的浏览位置，这会影响用户体验。
- 性能问题：随着数据量增加，长时间滚动会占用更多内存，可能导致性能下降。
适合增删改查页面的替代设计方案：
-
分页设计：
- 每页显示固定数量的数据，便于管理和查找特定记录。
- 提供清晰的导航条，让用户能够快速跳转到不同页码。
-
列表视图和表格视图结合：
- 使用表格视图提供清晰的数据结构显示，便于排序和筛选。
- 提供简单直观的数据操作按钮，例如新增、编辑或删除。
-
搜索和筛选功能：
- 提供强大的搜索栏和筛选条件，让用户能够快速找到所需数据。
- 动态更新结果，提高交互效率。
-
分区加载：
- 结合懒加载技术，仅在用户需要时才加载更多内容，但采用明确的分段结构，而非无限滚动。
综上所述，对于有大量数据且涉及频繁增删改查操作的页面设计来说，更建议采取分页设计、结合列表和表格视图，以及提供强大的搜索和筛选功能来提升用户体验。瀑布流布局虽有其独特优势，但在这种场景中并不是最佳选择。