惯性聚合 高效追踪和阅读你感兴趣的博客、新闻、科技资讯
阅读原文 在惯性聚合中打开

推荐订阅源

GbyAI
GbyAI
Threat Intelligence Blog | Flashpoint
Threat Intelligence Blog | Flashpoint
Hugging Face - Blog
Hugging Face - Blog
IT之家
IT之家
Jina AI
Jina AI
Google DeepMind News
Google DeepMind News
大猫的无限游戏
大猫的无限游戏
The GitHub Blog
The GitHub Blog
腾讯CDC
L
LangChain Blog
P
Proofpoint News Feed
M
MIT News - Artificial intelligence
F
Fortinet All Blogs
量子位
Apple Machine Learning Research
Apple Machine Learning Research
Cloudbric
Cloudbric
B
Blog RSS Feed
B
Blog
C
CXSECURITY Database RSS Feed - CXSecurity.com
Vercel News
Vercel News
S
Schneier on Security
Project Zero
Project Zero
宝玉的分享
宝玉的分享
美团技术团队
MyScale Blog
MyScale Blog
OSCHINA 社区最新新闻
OSCHINA 社区最新新闻
Spread Privacy
Spread Privacy
T
Threatpost
A
Arctic Wolf
Exploit-DB.com RSS Feed
Exploit-DB.com RSS Feed
Hacker News - Newest:
Hacker News - Newest: "LLM"
爱范儿
爱范儿
Recorded Future
Recorded Future
C
CERT Recently Published Vulnerability Notes
T
Threat Research - Cisco Blogs
cs.CV updates on arXiv.org
cs.CV updates on arXiv.org
SecWiki News
SecWiki News
H
Hacker News: Front Page
AWS News Blog
AWS News Blog
博客园_首页
freeCodeCamp Programming Tutorials: Python, JavaScript, Git & More
T
Tor Project blog
C
Check Point Blog
L
Lohrmann on Cybersecurity
F
Full Disclosure
TaoSecurity Blog
TaoSecurity Blog
Google Online Security Blog
Google Online Security Blog
云风的 BLOG
云风的 BLOG
The Last Watchdog
The Last Watchdog
Martin Fowler
Martin Fowler

人人都是产品经理

为什么你的产品找不到差异化?90%的失败都卡在第一步上(下) – 人人都是产品经理, 3年从30万到1300万用户、获2200万美元融资,这个AI教育产品用“抽卡”破解了获客难题 – 人人都是产品经理, 园区招商系统怎么做才能真正帮到去化?我加了这一个功能,推广链接转发400次阅读过万 – 人人都是产品经理, AI大事件:OpenAI发完网络安全模型又搞药物研发,小鹏汽车要抓”DeepSeek时刻” – 人人都是产品经理, 电商不是卖货,是一场更残酷的产品经理实战 – 人人都是产品经理, 没想到,活动营销又回来了! – 人人都是产品经理, 为何All-in海外KOC:一场关于AI时代窗口期的豪赌 – 人人都是产品经理, 重新理解企业的内部协作 – 人人都是产品经理, 苹果的 AI 战略到底是什么? – 人人都是产品经理, 医疗智能体·第2讲——合规护城河:等保、PIPL与HIPAA的架构实战 – 人人都是产品经理, 向量知识库五步法:从“答非所问”到“精准回复” – 人人都是产品经理, 鸿蒙PC三方库构建总指挥HPKBUILD(sha)库为例 – 人人都是产品经理, 何时该用LLM?AI产品经理的LLM设计指南 – 人人都是产品经理, 医疗信息领域的需求方、决策方、准入方以及关注点(二) – 人人都是产品经理, 即梦涨价:一场被误读的「傲慢」 – 人人都是产品经理, 面试AI PM必答题:Hermes和OpenClaw的区别,如何讲清楚业务价值 – 人人都是产品经理, AI的下一张船票:世界模型——AI产品经理必须理解的技术拐点 – 人人都是产品经理, 小红书做GEO,怎么让AI信你?记住这 3 个重要信息 – 人人都是产品经理, 5 家印度 AI 初创公司,看看印度 AI 再做什么 – 人人都是产品经理, AI项目跨团队协作:产品技术业务如何不打架 – 人人都是产品经理, Agentic Workflow(智能体工作流):让AI从”答案生成器”变成”数字员工” – 人人都是产品经理, lycium_plusplus 项目全景解读:OpenHarmony 三方库构建的“大管家” – 人人都是产品经理, 从爆单救火到前置履约:两套预采策略,把生鲜大促履约效率拉满 – 人人都是产品经理, 什么时候该补货?我用一轮数据做了一个决定 – 人人都是产品经理, 从“机械兜底”到“动态分流”:AI客服重复进线治理的4大底层逻辑 – 人人都是产品经理, 抖音拼效率,红书拼洞察 – 人人都是产品经理, 全民狂欢与退潮——为什么龙虾这波热潮冷却得如此之快? – 人人都是产品经理, Stripe押注!MPP重塑全球支付 – 人人都是产品经理, 小红书GEO:AI引用你的内容,不是因为你对,而是因为你看起来可信 – 人人都是产品经理, 前百度副总裁押注办公Agent,日韩付费爆发,Manus迎来强劲对手 – 人人都是产品经理, 企事业单位数字化的业务供需本质 – 人人都是产品经理, 医疗智能体·第1讲——医疗信息化重构:从“辅助软件”到“自主智能体”的范式转移 – 人人都是产品经理, 粉丝量就是空气!!! – 人人都是产品经理, 用户说“薯片碎了”,机器回“要买吗?”:意图识别的翻车与破局 – 人人都是产品经理, RAG召回准确率从75到90 我做对了这三件事 – 人人都是产品经理, AI大事件:Anthropic改收费、OpenAI发安全版、手术机器人纳入医保、阿里发布”秒悟” – 人人都是产品经理, Chrome 推出 Skills 新功能,Agent 重塑上网方式 – 人人都是产品经理, GitHub前创始人拿了a16z的1700万美元,做Agent时代的Git – 人人都是产品经理 拷贝或克隆其他 Flutter OH 项目到本地后无法运行 – 人人都是产品经理, 优惠券设计:优惠券创建 – 人人都是产品经理, 不用死磕文档!AI 助手 1 小时搞定飞书 CLI 安装 + 配置 + 知识库 – 人人都是产品经理, 用小龙虾做竞品分析报告:从2天到20分钟,我是怎么做到的 – 人人都是产品经理 用小龙虾做市场分析报告:搞懂这3个公式,市场规模不再靠猜 – 人人都是产品经理, 你早就在做 Harness 工程,只是不知道它叫这个名字 – 人人都是产品经理, Think Long就够?你可能想多了! – 人人都是产品经理, 货代SRM实战:供应商准入怎么做,才能让资源池不是通讯录而是可交付网络? – 人人都是产品经理, 如何做好用户调研?详解基本技巧 – 人人都是产品经理, 木鸟、途家、美团对打,平台春天行动开“卷” – 人人都是产品经理, 入职才发现公司不靠谱?小红书从业者求职避坑指南 – 人人都是产品经理, 美国 AI 三巨头联手封堵,中国 AI 突围之路在何方 – 人人都是产品经理, 小红书,放在需求对面的镜子 – 人人都是产品经理, AI 会带来大规模失业吗? – 人人都是产品经理, 从出单到补货前,我第一次犹豫:该不该放大? – 人人都是产品经理, Flutter 三方库鸿蒙化适配:5 种高效检查方式,快速判断是否需要适配 – 人人都是产品经理, 从做产品进阶拿结果:医美机构产品经理转岗科室运营经理 – 人人都是产品经理, 阿里HappyHorse,一场关于“Token经济”的阳谋 – 人人都是产品经理, To B AI:客户留存落地的观察与思考 – 人人都是产品经理, AI产品的“生命线”——数据采集、标注、清洗的产品化设计 – 人人都是产品经理, 谈谈AI Agent(二):当“孩子”能自己“体验世界”时,你该学什么? – 人人都是产品经理, UI/UX设计师的3层能力进阶,前两层让你活下来,第三层…才是真正的分水岭 – 人人都是产品经理, 2分钟 → 30秒,效率提升75%:B端产品经理如何用「规则枷锁」驯服AI幻觉? – 人人都是产品经理, 还没来得及学OpenClaw,来了个更猛的:Hermes Agent – 人人都是产品经理, AI日报:宇树机器人跑出10m/s刷新世界纪录 – 人人都是产品经理, 一文说透基金互金如何用情绪价值引导用户决策做转化 – 人人都是产品经理, 当浏览器开始替你”看”网页:AI 浏览器正在亲手拆掉它脚下的那张网 – 人人都是产品经理, 0代码,一天时间我Vibe Coding了个网站 – 人人都是产品经理, Hermes 和 OpenClaw 之争,Agent 的能力应该“装上去”还是“长出来”? – 人人都是产品经理 视频生成的“桌子”,字节Seedance 2掀完,阿里快乐马掀 – 人人都是产品经理, 从听不懂到完全信任:我的 Codex 深度产品体验 – 人人都是产品经理, 当虚拟偶像有了北京户口,与真人偶像还有什么区别? – 人人都是产品经理, 会说,远远比会做更重要 —— 对 SBTI 爆火现象的五层观察 – 人人都是产品经理, AI产品经理必看:当“搭环境”比“选模型”更重要,你的认知还在2024年吗? – 人人都是产品经理, 2026年AI产品商业化核心逻辑:从功能demo到规模化营收的3个必破卡点 – 人人都是产品经理, 京东围绕供应链,卷起裤腿下场的那些事儿 – 人人都是产品经理, SBTI一夜刷屏:它赢在了“太会说人话” – 人人都是产品经理, 折扣零售的真相:不是便宜,而是价值感! – 人人都是产品经理, 和甲方吵了一架,最后加钱做了——我学到的ToB产品经理生存法则 – 人人都是产品经理, 和几位小红书操盘手聊了8小时,干货全在这 – 人人都是产品经理, 智谱GLM-5.1登场,开源模型首超Opus4.6!!! – 人人都是产品经理 Anthropic收入凭什么反超OpenAI,终于有人把这事说清楚了 – 人人都是产品经理, 史上最有故事感的技术报告——Claude最强模型Mythos 7个极其精彩的细节 – 人人都是产品经理, 模型不是壁垒,Harness 也不是 – 人人都是产品经理, 抖音本地生活业务思考21 – 人人都是产品经理, Superpowers:145k Star的AI编码框架,到底是什么来头? Superpowers:145k Star的AI编码框架,到底是什么来头? – 人人都是产品经理, OpenAI 的路走错了,Anthropic Harness 解法启示:模型需要实践专科生 – 人人都是产品经理, 画原型图的前一步:设计站点地图 – 人人都是产品经理, 给 DeepSeek 的最后一封催更信 – 人人都是产品经理, 手把手教你用 Claude Code 搭建 AI 营销团队:5 个 Agent、12 项技能,独立完成研究、写作、设计全流程 – 人人都是产品经理, 你以为大模型在学语言?不,它在重新发明语言学 – 人人都是产品经理 所谓Skill,不过是AI时代的工业垃圾 – 人人都是产品经理, 聊一聊内容传播的几个方法 – 人人都是产品经理, 当平台开始吃掉生态:从 OpenClaw 被封杀,读懂 Anthropic 的这盘棋 – 人人都是产品经理, 你装了 10 个 AI 插件,Obsidian 还是一个文件夹 – 人人都是产品经理 关于AI智能体架构演进的系统性思考:从单体试水到多体协同的重构 – 人人都是产品经理, 当“人”变成Skill,我们又该何去何从? – 人人都是产品经理 Mythos 事件:前沿 AI 治理的意外实验 – 人人都是产品经理, 货代CRM:信用与风险管理怎么做,才能把坏账风险拦在放货之前? – 人人都是产品经理, 从HR收集自拍照到员工自助录入——我见证了园区人脸识别从”不可用”到”真好用”的全过程 – 人人都是产品经理 千问闯关AI混沌期:阿里画靶,吴嘉张弓,马云射箭? – 人人都是产品经理,
B端交互|从组件、栅格和响应式入手来制定全局框架
酸梅干超人 · 2022-09-01 · via 人人都是产品经理

我们在制定全局框架时,对于组件和响应式设计可能没有那么熟练,不知道如何进行调整,作者总结了详细的做法,希望对你有所帮助。

一、全局框架中的组件

1. 浮层组件

(1)全局提示

全局提示是指在全局场景中都会触发的通知、警示、反馈的悬浮组件类型。通常,全局提示包含两种类型的组件:

我们需要根据项目的实际情况,选择需要使用的类型,再为它们分配严格的使用场景和触发条件。比如:

  • Meassage:断网、上传失败、已登出、暂无权限…
  • Notification:站内信、用户留言、进度通知…

当然,也并不是每个项目都要使用到这两个组件。有时候为了精简悬浮内容,可以只使用 Meassage 来覆盖所有通知内容,比如将 Notification 的大段文本内容去掉,在提示中添加一个 ”查看按钮“ 让用户进行跳转做替代。

确定好使用的类型以后,才能制定它们的交互方式。分别显示在页面的哪个位置,对齐的模式,多通知堆叠的逻辑等等。

(2)对话框弹窗

对话框弹窗也可以叫模态(Modal)弹窗,只要用来指应用了黑色透明遮罩的悬浮窗口。这类窗口通常是用来促使用户必须关注弹窗内容,并完成对应操作后才能进行后续操作。

对话框弹窗是一个非常灵活的组件,可以作为多种内容的载体形式,如:

  • 重要提示:对删除、修改、替换、登录等场景进行二次确认
  • 信息公告:展示一些特定的信息,如站内公告、注意事项、广告信息等
  • 表单操作:填写一些基础的表单,如数量设置、添加用户、修改标题等
  • 弹窗页面:基本可以理解成是将一个完整的页面以弹窗的形式展示

对话弹窗因为它太灵活,所以很容易在项目中被滥用,导致整个项目各类对话框层出不穷,缺乏统一的样式和操作方法,尤其是作为页面载体的弹窗。

所以,我们并不能把对话框弹窗只当成一个组件,而是一个同类组件的合集。要针对每个分类制定对应的应用场景、内容结构、操作方式。

而表单、页面型弹窗,还可以做进一步的分类(类似 PS 中不同类型的设置弹窗),比如表单包含基础表单、穿梭表单、上传表单等等。

(3)侧边抽屉

侧边抽屉是一个通常在右侧打开的浮层,可以理解成是用来展示在右侧的临时页面。

它的主要作用是让用户不用跳出当前的页面直接展开一些下级的页面,如列表详情、表单填写、系统设置等等,提升用户的页面跳转效率。

抽屉作为页面的载体,如果要在项目中使用,就需要设计师在前期制定应用的场景,或指定哪些页面使用抽屉。要避免其应用和独立页面、对话框产生冲突,这会非常影响使用体验。

并且,还要决定打开抽屉是否要使用遮罩(模态),有的业务需求需要打开侧边栏后依旧保留左侧区域的操作,尽量在项目中只使用一种形态。

(4)固钉元素

固钉元素我更喜欢叫固定元素,意思是固定在页面某个位置的悬浮元素。

比如在 SAAS 系统右侧的帮助、客服,或者设置、回到顶部、风格切换等,都是可以长期在全局中存在的固定元素。

固钉元素没有太复杂的设置,只要在前期确定有哪些按钮、字段是需要做成固钉的,并确定它们所在的位置即可。

以上就是全局框架中包含的主要组件类型了,在项目设计过程中,就要根据需求提前设计它们的布局和交互方式,以此确定整个项目的基本操作路径,为整个项目的交互方法奠基。

二、栅格和响应式架构

有了全局框架,就要考虑页面的栅格和响应式规则了。

因为主流电脑屏幕分辨率宽度从 1280-3440px 不等,在跨度这么大的显示差异下,怎么保证产品的正常使用并平衡用户体验,就成为前期交互工作中的必要环节。

多数新手对栅格和响应式的使用存在非常大的误解,所以我会在下面对它们分别做出解释。

1. B 端中的栅格制定

网页中的栅格,是脱胎于平面网格系统的一种网页格线系统,让设计师使用平面排版的技巧来完成网页的排版,可以很高效的输出富有设计感的页面。

早期的网页栅格仅仅是在设计过程中辅助设计师排版的工具,在开发代码中并不会有相关的体现。但随着 HTML5 的登场, Bootstrap 响应式框架的问世和普及,栅格就不再只是设计的工具,也成为开发用来制定页面显示逻辑、响应规则的重要依据。

所以在主流的前端开源框架中,都会包含栅格的应用说明。

但是,这些说明并不是作为栅格的应用教学,而是 ——告诉你系统支持的栅格方式有哪些!

两者之间是有天壤之别的,前者只是把规则做好,你去执行就好。后者是提供了很多种方法和支持的方式,你得理解以后再自己制定。

所以,不管你有没有用这些开源框架,都需要制定出一套符合项目需要的栅格规则,应用在后续的界面设计和实际开发环节。

栅格系统的制定,就是在前期确定栅格的列数(Row)、列宽(Width)、外边距( Margin )、列间隔(Gutter)。

其中,列数基本是以 24 列为主,除非有自己对项目应用场景的想法,否则不会是用 12、16、20 列栅格。

而网页中的列宽,则是一个变量数值,它是通过页面宽度减去外边距、列间距后除以列数得出的宽度。它的获取公式:

列宽 = ( 页面宽 – 列间隔总宽 – 外边距总宽 ) / 24

这么做的目的是后面页面宽度变更,列宽也会按比例缩放。所以列宽是一个非固定数值,不需要我们在这个阶段制定。

而外边距的制定则是重点,外边距一般指栅格区域左右的留空区域,很多新手以为这个数值就像平面的出血线一样,保证左右有一定留白就可以了。但实际上,这是用来告知浏览器哪些区域不参与响应式的依据。

比如最常见的情况,就是移除左侧导航栏的区域,不让它们参与响应式,因为大多数情况下,导航是一个定宽的组件,它没有参与宽度变更的需要。

所以目前的软件栅格设置中,都有单独定义边距的选项,符合真实项目的使用需要。

还有一些特殊的场景,比如页面右侧可以展开聊天、日志、任务等面板(非浮层),这些面板也是定宽的,但会挤压内容区域,于是我们就会额外进行说明,哪些场景外边距数值会变更。

最后,就是列间隔数值的制定。列间隔一般以 4 的倍数为主,要用 5 的倍数也可以,这个数值决定了布局的宽松程度。设置栅格唯一的标准,就是根据亲密原则,不大于外边距即可。

确定好参数,就要通过交互文档或者创建标准的栅格系统画布进行说明。

栅格的数值定义一定是要满足指导后续页面设计和布局要求的,而线上很多作品集中的栅格系统标注漏洞百出,证明他们本身并没有理解栅格的制定要素。

2. 项目的响应式规则

如果完全理解栅格和响应式的关系,应该知道栅格定好了,那么响应式的依据似乎也就有了,还需要制定什么响应式的规则呢?

包含下面几个关键的要素:页面宽度支持、非响应式页面、组件响应逻辑。

首先,页面宽度支持就是确定一个可以触发响应式的画布区间,因为响应式不可能无差别适配所有宽度,比如只有 100px 的浏览器画布宽,怎么适配?或者类似 32:9 的超宽屏幕比例,适配它有什么必要?

所以,尽量要提前制定出项目支持的最小和最大尺寸。最小尺寸建议不小于 800px,因为没有适配移动端的必要,而最大宽度支持到 2560px 即可,再宽的分辨率占比极低( 4K屏幕会应用 HIDPI 合并成 2K 或 1080p 而不是 3840 px 宽)。

第二就是确定不应用响应式页面的情况,响应式虽然看起来很万能,但并不是所有页面都需要使用响应式,强行使用只会收获反面效果。

比如基本的表单页面、文本页面、效果页面等,都是使用定宽设计的效果会远远优于响应式。所以,我们要确定非响应式的页面场景,以及对应的页面框架(下一章节会具体说)。

第三组件响应逻辑,就是下级组件中对于响应式的支持情况。

这里要做个区分,有些组件是游离与响应规则之外的,比如前面提到的导航,还有弹窗、抽屉、固钉等,都是定宽即可的元素,没必要参与响应规则。

但是需要应用到响应的组件,就需要为它们分配基本的响应逻辑。举个例子,前面提到的内容模块组件,就可以制定固定内间距、标题左对齐、按钮居中对齐的适配规则,来满足页面的响应需要。

同理,一些非常复杂的大型组件,也需要在前期做好响应适配的规则制定,如表格、层级穿梭框、列表等,就不在这里展开,我们会在之后的组件交互章节具体说明。

最后,还有一个在响应式架构中非常重要的参数 —— 断点 BreakPoint,我没有提,就是因为它在 B 端项目中能够发挥的作用并不是太大,引入断点的概念会让上方的组件响应逻辑复杂几个量级。

所以前面我强调了支持最小和最大的显示区间,就是为了尽可能杜绝页面过窄过宽从而必须应用断点适配的问题。

当然上方的参数都是个人建议,如果你项目经验丰富,对于参数的应用和响应式规则了如执掌,可以随心所欲的驾驭数值,就不需要被我的建议还其它条条框框束缚,大胆发挥……

作者:酸梅干超人;公众号:超人的电话亭(ID:Superman_Call)

本文由 @超人的电话亭 原创发布于人人都是产品经理,未经许可,禁止转载。

题图来自Unsplash ,基于 CC0 协议。

该文观点仅代表作者本人,人人都是产品经理平台仅提供信息存储空间服务。