关于 showcase
showcase 是用于提升界面交互与视觉表现的设计技能,涵盖转场和数据密集型视图。它强调结合产品情境,渐进增强,并通过浏览器检查可访问性、性能与视觉效果。
主要功能
- 01选择符合产品情境的效果
- 02运用浏览器动画与渲染技术
- 03增强数据密集型界面
- 04保留回退方案并关注性能
- 05遵循减少动态效果偏好
- 06在浏览器中验证结果
适用场景
- 01制作形态变换式对话框转场
- 02用虚拟滚动保持大型表格响应
- 03构建滚动驱动的视觉揭示
- 04润色图表状态间的动画
安装
复制下面的命令,在终端中运行。
npx skills add https:/ / github.com/ aladicf/ better-react-web-ui --skill showcase安装后在 Claude Code 中输入/showcase确认已加载。
详细介绍
请以以下内容开头:
──────────── ✨ SHOWCASE ─────────────
》》》 Entering showcase mode...
突破传统界面的限制。这不只是视觉效果的问题,而是要充分发挥浏览器的全部能力,让界面的任何部分都非同寻常:可处理 100 万行数据的表格、从触发按钮变形展开的对话框、提供实时流式反馈的表单验证,以及宛如电影般的页面转场。
必须完成的准备工作
阅读 frontend-design,并遵循其中的上下文收集流程。复用已有上下文,只针对会产生重大影响的信息缺口提问。
参考 motion reference,了解时长、缓动、编排以及减少动态效果方面的预期。 当出色的效果依赖可信的景深、图层或状态转场时,请参考 elevation system。 请参考 ai slop detection,确保“非同凡响”能体现产品本身的特色,而不是盲目追逐潮流、徒增成本。
此技能的特别重要事项:上下文决定了“非同凡响”意味着什么。在创意作品集上添加粒子系统会令人惊艳;在设置页面上使用同样的粒子系统则会显得尴尬。不过,设置页面若能即时乐观保存并带有动画状态转场,同样非同凡响。决定采用何种方案前,请先了解项目的个性与目标。
实施前确定影响重大的选择
沿用用户已选定的方向。如果用户将创意方向交由你决定,就选择合适的方案,并在授权范围内继续推进。
如果方向尚未确定,且不同方案在行为、无障碍性、性能成本或范围上有实质差异,请提出几个具体选项,并询问缺少的决定。等待回复期间,继续开展不受影响的准备工作。不要重复询问用户已经确认过的事项。
使用浏览器自动化进行迭代
技术上复杂的效果几乎不可能一次成功。你必须积极使用浏览器自动化工具预览作品、直观检查结果并反复迭代。不要想当然地认为效果看起来没问题,务必实际检查。应做好多轮优化的准备。从“技术上可用”到“视觉上出色”,靠的是视觉迭代,而不只是编写代码。
评估此处的“非同凡响”意味着什么
合适的技术追求完全取决于你正在处理的界面。在选择技术前,请先问自己:这个特定界面的用户会觉得什么“真不错”?
视觉与营销界面
页面、首屏区块、落地页、作品集——这类界面的“惊艳”往往来自感官体验:滚动触发的内容呈现、着色器背景、电影感的页面转场,或会响应光标的生成艺术。
使用 landing-page storytelling,了解以访客为主导的页面结构、分层首屏的设计准备、移动端构图,以及滚动各状态下的验证。让主要视觉亮点与产品卖点紧密相关,并确保最终操作触手可及。
功能型 UI
表格、表单、对话框、导航——这类界面的“惊艳”在于使用感受:通过 View Transitions 从触发按钮变形展开的对话框;借助虚拟滚动以 60fps 渲染 10 万行数据的表格;提供流式验证、响应即时的表单;带弹簧物理效果的拖放交互。
性能关键型 UI
这类界面的“惊艳”不显眼,却能被切实感受到:搜索 5 万项内容时筛选毫无闪烁;复杂表单始终不会阻塞主线程;图像编辑器几乎能实时处理。整个界面始终响应流畅、毫不迟疑。
面向数据密集型界面
图表和仪表盘——「惊艳感」来自流畅度:通过 Canvas/WebGL 实现 GPU 加速渲染,以处理海量数据集;在不同数据状态之间实现动画过渡;让力导向图布局自然稳定下来。
共同点:实现方式的某些方面超出了用户对 Web 界面的预期。技术服务于体验,而不是反过来。
工具包
按照你想实现的目标分类,而不是按技术名称分类。
让过渡效果更具电影感
- View Transitions API(同文档:所有浏览器;跨文档:Firefox 不支持)——在不同状态之间实现共享元素变形。例如,列表项展开为详情页;按钮变形为对话框。这是最接近原生 FLIP 动画的方案。
@starting-style(所有浏览器)——当元素从display: none动画到可见状态时,搭配兼容 Tailwind 的入场关键帧使用- 弹簧物理——通过质量、张力和阻尼实现自然运动,而不是使用 cubic-bezier。可选库:motion(原名 Framer Motion)、GSAP,或自行编写弹簧求解器。
将动画与滚动位置关联
- 滚动驱动动画(
animation-timeline: scroll())——由滚动位置驱动的兼容 Tailwind 的关键帧动画。视差、进度条和显现序列无需额外 JavaScript 即可运行。(Chrome/Edge/Safari;Firefox:仅实验性标志支持——务必提供静态回退方案)
实现 Tailwind 工具类无法满足的渲染效果
- WebGL(所有浏览器)——着色器效果、后期处理、粒子系统。可选库:Three.js、OGL(轻量级)、regl。适用于 Tailwind 工具类无法实现的效果。
- WebGPU(Chrome/Edge;Safari 部分支持;Firefox:仅实验性标志支持)——新一代 GPU 计算。功能比 WebGL 更强,但浏览器支持有限。务必回退到 WebGL2。
- Canvas 2D / OffscreenCanvas——自定义渲染、像素处理,或通过 Web Workers + OffscreenCanvas 将繁重渲染任务完全移出主线程。
- SVG 滤镜链——用于实现自然失真效果的置换贴图、湍流和形态学滤镜。使用 Tailwind 工具类控制触发条件和布局。
让数据充满活力
- 虚拟滚动——对于包含数万条内容的表格/列表,仅渲染可见行。简单场景无需库;复杂场景可使用 TanStack Virtual。
- GPU 加速图表——对于规模大到不适合使用 SVG/DOM 的数据集,使用 Canvas 或 WebGL 渲染数据可视化。可选库:deck.gl、基于 regl 的自定义渲染器。
- 动态数据过渡——在图表状态之间进行变形,而不是直接替换。可使用 D3 的
transition()或面向基于 DOM 的图表使用 View Transitions。
为复杂属性添加动画
- 兼容 Tailwind 的
@property令牌(所有浏览器)——仅当 Tailwind 工具类无法直接实现高级效果(例如为渐变、颜色和复杂值添加动画)时,才注册带类型的主题变量。 - Web Animations API(所有浏览器)——由 JavaScript 驱动的动画,可高效处理 transform 和 opacity 动画。可组合、可取消、可反转,是复杂动画编排的基础。
突破性能极限
- Web Workers——将计算任务移出主线程。繁重的数据处理、图像操作、搜索索引——任何可能导致卡顿的任务。
- OffscreenCanvas——在 Worker 线程中渲染。复杂视觉效果在后台渲染时,主线程仍可保持空闲。
- WASM——为计算密集型功能提供接近原生的性能。图像处理、物理模拟、编解码器。
与设备交互
- Web Audio API — 空间音频、音频响应式可视化、声音反馈。启动时需要用户手势。
- Device APIs — 方向、环境光、地理位置。谨慎使用,并始终征得用户许可。
注意:这项技能旨在提升界面的感受,而不是改变产品的功能。添加实时协作、离线支持或新的后端能力属于产品决策,并非 UI 增强。重点是让现有功能带来非凡体验。
严谨实现
渐进增强不容妥协
每项技术都必须能够平滑降级。即使没有增强效果,体验也必须出色。
@supports (animation-timeline: scroll()) {
.hero { animation-timeline: scroll(); }
}
if ('gpu' in navigator) { /* WebGPU */ }
else if (canvas.getContext('webgl2')) { /* WebGL2 fallback */ }
/* Tailwind-rendered fallback must still look good */
性能规则
- 以 60fps 为目标。若低于 50fps,则简化效果。
- 始终遵循
prefers-reduced-motion。提供精美的静态替代方案。 - 仅在接近视口时才延迟初始化重型资源(WebGL contexts、WASM modules)。
- 暂停视口外的渲染。停止所有不可见内容的运行。
- 在真实的中端设备上测试,而不只是开发机器。
精雕细琢才是关键
「酷炫」与「非凡」之间的差距,在于最后 20% 的打磨:弹簧动画的缓动曲线、交错显现的时间偏移,以及让过渡感觉真实的细微次级动效。不要发布第一个能用的版本,而要发布让人觉得理所当然的版本。
切勿:
- 忽略
prefers-reduced-motion— 这是无障碍要求,不是建议 - 发布会导致中端设备卡顿的效果
- 使用没有可用回退方案的前沿 API
- 未经用户明确同意就添加声音
- 用技术上的雄心掩盖薄弱的设计基础 — 先用其他技能解决这些问题
- 叠加多个相互竞争的非凡瞬间 — 聚焦才能产生影响,过度则会造成噪音
验证结果
按照视觉验证的说明,获取当前截图、交互证据,并了解不可用工具的限制。如有获批的参考资料,请使用参考还原度。在无法安排第二位审核者或无法使用实体设备时,不要强求。
- 惊艳度测试:向没见过的人展示。对方有反应吗?
- 移除测试:把它去掉。体验会变差,还是根本没人注意到?
- 设备测试:分别在窄屏浏览器、中等宽度浏览器和宽屏精准指针浏览器中运行。仍然流畅吗?
- 无障碍测试:启用减少动态效果。仍然美观吗?
- 情境测试:这适合这个品牌和受众吗?
请记住:「技术上非凡」并不意味着使用最新的 API,而是让界面做到用户原以为网站做不到的事。