v1.1 上线观察 + 后续 v1.2 规划
大家好,v1.1 已经上线一周。这周我做了一轮简单的访谈和数据观察,把发现整理在这里,请各位看一下后给意见。
数据侧:
- 讨论区打开率: 从 38% 提升到 52%, 混合态 C 让"看到讨论氛围"的时间窗变长
- 首条讨论发起率: +17%, "我也来参加讨论" 的引导文案有效降低门槛
- 但"标记已解决"使用率非常低, 一周只有 6 次
用户访谈: 访谈了 4 位活跃用户后我发现, 大家对"Thread"这个概念是困惑的。原话: "我点进去看到一堆白底卡片, 不太确定是评论还是任务"——这条反馈非常重要。
v1.2 我建议这样调整 (详见 requirement-v1.2.md):
- 概念回归: 不再使用 Thread, 回到 Topic + Event 两层
- 视觉降噪: 去掉所有状态 chip 和 meta, 让注意力回到"讲了什么"
- 用 @ 驱动「来看」列表: 替换原 My 待办, 更轻量
- 富内容: 发言里支持 @ 人、链接、图片、文件
麻烦 @钟嘉辉 @肖迈 @李丹阳 看下, 下面留两个讨论方向, 我先抛砖:
讨论
10
c
技术架构/部门
想再讨论下红点消失逻辑: 现在是用户点击 Topic 即清除未读, 但如果他只是一扫而过没真正阅读, 红点就丢了, 后续新动态他反而感知不到。 我倾向"停留 > 3s 或滚动到底部"才算已读。@肖迈
2 小时前
回复
编辑
删除
s
技术架构/部门
同意这个判断。"3s 停留" 是行业里相对成熟的判定, 我们可以加个埋点先观测一周。
2 小时前
回复
d
产品/部门
补充一下: 滚动到底部这个条件很关键, 长 Event 用户经常滑到一半就走, 不能因此判定为已读。
1 小时前
回复
p
前端/部门
实现方面: 用 IntersectionObserver 判定底部是否进入视口, 加上 setTimeout 3s 即可, 复杂度可控。
52 分钟前
回复
x
设计/部门
从设计角度也认同。可以考虑做一个微动效: 已读瞬间红点慢慢淡出, 而不是直接消失, 让用户有"我刚才看过"的反馈。
30 分钟前
回复
c
技术架构/部门
那我下周开埋点 + 出技术方案, 这里先 close。@肖迈 关于淡出动效, 给个具体的曲线参数？
5 分钟前
回复
编辑
删除
s
技术架构/部门
另外说一下飞书集成方案。我们之前调研过一轮, @李培伦 你看 webhook 还是 OpenAPI 哪个更适合? 我个人倾向哪个更稳就用哪个, 长期维护成本敏感。
对比表 · webhook vs OpenAPI
点击展开
昨天
回复
p
前端/部门
调研下来 OpenAPI 更稳, webhook 经常丢消息(飞书侧没有重试机制)。但 OpenAPI 要做 token 刷新、限流、错误降级一整套, 工作量稍大。完整对比在这里:
PDF
飞书集成方案对比.pdf
1.2 MB · 12 页
昨天
回复
x
设计/部门
同意 OpenAPI。token 刷新封装成 SDK 后续也能复用到其他第三方集成里。可以看下 larksuite/oapi-sdk-go 这个开源 SDK。
larksuite/oapi-sdk-go: Lark/Feishu Open API SDK
github.com/larksuite/oapi-sdk-go
昨天
回复
s
技术架构/部门
那这块就这么定, @李培伦 这周出技术方案？
12 分钟前
回复