新传学院 订阅/关注/阅文/评论/公号
      10月前 最新ask:语音信息是否应支持加速播放? by 纯银V · 黄埔犬校

提问:你是一位与我共事的一款国内 IM 软件(类似微信、Facebook Messanger)的产品经理,我向你建议:要不要为我们产品中的语音播放功能提供一个可以类似 1.5/2 倍速度播放的选项,你会如何回复我?

zheng:
我会想知道你想加速的原因。

如果单纯是为了提高效率的话,我认为这也不失为一个办法,但并不能完全解决。一段40秒的语音,提高两倍速度的话需要还是要20秒,但变成文字的话10秒内就能看完了。如果从提升效率出发的话,我认为一键语言转文字会是一个更好的体验,但是不知道技术是否能够跟上。从我微信使用“转文字”功能的体验,有两个方面的顾虑,一是方言或中英夹杂的识别率;二是转换时间体验能否达到“一键”的效果。


leexz:
不会,从我观察�微信�使用情况来看,播放语音的时候人们习惯性点击播放直接拿到耳边,“点击--拿起“,已然成为一种习惯,中间加入速度选择,变成了“点击--选择--拿起“,在流程上打破习惯。 另外,作为即时通讯应用,会产生多长的语音文本??以至于需要快进来解决文本冗长的问题。


cicada:
@leexz 的观点很有说服力。“让用户选择“会摧毁这个功能的用户体验,选择动作完全打断了听语音消息的流畅性。


chenglong:
如果只加倍速,不一定能提高效率。腾讯视频有个倍速播放的功能,我确实为了效率会用,但是如果在看《奇葩说》,我就不会用,因为《奇葩说》的语速已经很快了;在用户的语速千差万别,同一段语音中的语速也有不同时,我不确定我调成了1.5倍速播放,是提高了效率,还是导致一部分听不清,还得重新听一次。


zzzzzzk:
作为用户,我怎么决策什么时候要按下这个快进播放的按钮?

回复(0)

共 211 条12345››... 11
10月前 ask:短视频适合评论还是弹幕? by 纯银V · 黄埔犬校

提问:最近工作中涉及到短视频的评论系统,目前有三种做法,一是评论+弹幕,二是纯评论,三是评论与弹幕合并。你们怎么看这三种选择呢?

cicada:
评论+弹幕的代表是B站与最右。

B站这么做很好理解,它既有长视频,也有短视频。长视频必然同时需要评论与弹幕系统,弹幕带氛围,评论看内容。

最右很有意思,最右的视频交互上倾向于弹幕,但评论数量压倒性地超过弹幕(B站弹幕更多一些)。用户宁肯看完短视频退出来评论,也不愿意一边看短视频一边发弹幕。这一点和最右的“神评论“社区文化相关。

纯评论的代表是快手。

评论与弹幕合并的代表是美拍。美拍在数据层只有评论,记录每一条评论的发布时间,将一部分评论转为弹幕。但美拍的弹幕交互极差,远不如B站和最右。长评论转弹幕的体验也是很差的。

然后我怎么看?我看短视频弹幕的内容性质。以B站和最右为例,大多数弹幕和评论没区别,以刷存在感为主,并没有针对特定的视频场景进行评论。同时短视频的内容相对扁平,很少有起伏曲折,多数情况下也不需要针对指定帧的评论,弹幕的优势少了一半。

在这种情况下我优先选择评论而不是弹幕,一是兼容较长的文字内容,二是支持回复评论和评论盖楼,增强社区互动,没必要同时上两套互动系统增加系统复杂度,何况弹幕的研发成本远高于评论。未来研发时间富余了,可以考虑美拍的做法,提取一部分评论转为弹幕,带带视频氛围,照顾那些特别喜欢弹幕的用户。


iveyhu:
如果视频内容不能引起情感共鸣,或是引发讨论撕逼,那评论区也会不太有生气,很鸡肋,还不如暂时不做评论。快手评论区给人的感觉就是这样,没啥意思。但是弹幕有氛围感,好像有很多人陪伴一样。正好大多数人看短视频的场景是夜里一个人无聊的时候。


cicada:
评论是对作者的极大鼓励,“弹幕的陪伴”则是一种因人而异的感觉。

短视频评论可以支持较长字数,可以支持互相回复,虽然快手里这类情况不多,但在最右里大量存在。换句话说,评论支持更丰富的互动行为,对社区运营有益。


harbuzi:
@cicada 今天正好又看了下最右,想起这个话题,从观看者的角度说一些。

对比B站和最右,可以很明确感受到弹幕在横屏和竖屏下有巨大差异。在横屏下,屏幕高度低,视觉集中度高,加上弹幕横向移动距离长,因此留给「阅读弹幕」注意力和时间要远比竖屏下多。带来的差异是B站的弹幕,更容易被「阅读」,而最右的弹幕,我很努力想去看弹幕的内容,但实在是看不进去,很累很累。加上最右都是短视频,真的不觉得看最右的视频,会有人认真看弹幕。

在B站,弹幕承担2个作用:1是增加(长)视频本身的信息量;2是让看视频的人觉得热闹。但在最右,我感觉其实只有后一种价值。也即是说,最右用弹幕做氛围,用评论做信息量的补充,不管有意无意,反正是把B站弹幕的双重作用拆分了。

以及,总觉得越年轻的人越需要「闹腾」的氛围,因此,最右这种选择还是有他的道理的。


yao126:
弹幕是“大家一起看电视”的感觉,评论是“看完后讨论的总结”或者是“与作者的交流”。若要取舍系统的话,根据自己产品研究这三个定位即可,例如视频长度、总结性讨论的必要性、与作者的交互性、话题的延展性。若要做好运营,考虑的会多一些,不过重要的是要想保证质量,产品必须有一定质量的种子用户基数再搞。

回复(1)

  • 匿名人士 江苏省南通市 (112.2.56.*): good   (2018-10-25 16:42:15)

送出评论

10月前 猫饼ö招聘全职设计师与运营实习生 by 纯银V · 产品

今年7月,产品经理圈的网红纯银…对…就是那个家伙,在短视频赛道发布了“猫饼ö”。

猫饼是一款“短视频创作工具”,特别适合编辑“自由度极高的视频”。和同类产品相比,有着“功能强大”和“操作简洁”的微妙的平衡性,将PC端繁复的视频编辑工具移植到手机上,帮助用户用手机剪辑高质量的视频。通过好用的工具,引导培育上百万的短视频创作人群,向内容平台转进。

目前的团队规模约20人+,已经拿到了两轮融资,投资方包括两家国内顶级VC。

猫饼在10月新开放两类职位。

工作地点:上海徐汇区,距离1/7/9号线10分钟步行距离
团队福利:10天带薪假期,提供早午餐,每月上门按摩,室内乒乓球桌

招聘设计师

工作内容:编辑器素材设计,安卓版UI设计
薪酬水准:月薪12-20K,每年13薪
职位要求:
1、因为猫饼的视频编辑器涉及大量素材设计,应聘者需具备丰富的平面设计经验,最好包括广告和插画经验,对字体搭配颇有研究。
2、熟悉AE操作,擅长用AE设计动画。
3、设计这事儿,看天赋,看作品,不看资历。从能力上来说,我们对平面设计和AE动画的要求都是中上,换算成正常履历大约是3-5年经验吧,但也接受天赋出众的1-2年经验。
★职位亮点:
猫饼有一位相当牛逼的UI设计师,可以在UI设计方面给予专业指导,很适合平面设计优秀,也希望在UI设计方面进阶的设计师。另外,我们的设计师从来不加班,对比广告行业……没有对比就没有伤害。

招聘邮箱:firecicada@gmail.com

招聘运营实习生(只接受在校生)

工作内容:用户运营
薪酬福利:月薪4K,日常福利和正式员工一样,零食按摩样样俱全
职位要求:
1、喜欢拍视频是基本要求,手机里没视频的就算了吧
2、能够使用手机App进行视频剪辑——最低限度,你总得会用猫饼吧
3、性格比较外向,天生“自来熟”,勾搭人是小意思
4、深度加入兴趣爱好社交圈,包括并不限于学校社团/二次元/美妆等
5、特别有耐心,擅长用搜索找人找内容
6、全职工作半年以上,但可以接受因为上课&论文短时间请假

招聘邮箱:lyracao@gmail.com

回复(0)

10月前 ask:Android原教旨主义失败了吗? by 纯银V · 黄埔犬校

提问:最近一两年,Android 原教旨主义者越来越少,iOS 底部�导航还是 Android 顶部导航的争论越来越少,这个月经引战贴是否以底部导航的胜利而告终了呢?

cicada:
这事儿要从头说起。

Android 从一开始就打算做大屏,当时 iOS 还没有横滑返回手势,为大屏定制了底部的物理返回键。我猜,为了避免底部的多层操作混乱(事实证明是多虑了),也为了跟 iOS 有所区隔,导航栏被放到了顶部。

顶部和底部的区别在哪里呢?

首先,顶部横滑切换 tab,要求各个 tab 之间是扁平化的关系,类似于从一个内容分类切换到另一个内容分类。如果 tab 不属于同一个维度,不属于“切换分类“的操作,而是“跳转到另一项功能页面“,这时候横滑就是不自然的操作。不自然,滑动切换率就会下降。

比这个更痛苦的是,如果存在两层导航,必然有一层导航得去点击而不是横滑。在 Android 大屏手机上,点击顶部导航必然是低频操作,这意味着放在这一层导航栏的所有功能页面都受到了极大损失。

因此,符合 Android 规范的顶部导航,仅仅适用于功能架构极简,不依赖两层导航的产品,而这样的产品为数极少。到目前为止所有自曝数据的产品,都认为底部导航的转化率更高,坚持 Android 原教旨主义的人,以我所见,以一线的 Android 爱好者居多,比如程序员,他们并不掌握大量的实战数据。

简书的简叔两年前自曝过数据,Android 版从顶部导航切换到底部导航后,次日留存率大涨,说明新用户更愿意探索应用,而不是看完首页就走。这条微博毫不意外地遭到了 Android 原教旨主义者的谩骂,大意是简书做得烂,不要怪规范。然而谩骂解释不了“改版提升次日留存率“的数据。

除此之外,微博的来去之间,糗事百科的王坚都曾经站出来讲过,底部导航的转化率更高。所以顶部导航日趋式微是必然的,制定这项规范的时候,恐怕想象不到未来的产品结构趋于复杂,这也是 iOS 规范更具前瞻性的证明。


daniel:
Android 自己的 APP 都凌乱了,原教旨主义溃败啊。


taitaigao:
1、操作上,单手时底部 tab 挨着大拇指,点哪到哪,快捷方便;顶部导航从首栏到三栏要多划一次,麻烦;点击切换又要大拇指去够,费劲。如果因为去够而摔了手机,估计会恨死。而且顶部导航无论单双手操作,都会挡视线;底部 tab 不会。

2、界面上:顶部导航会两层甚至三层堆在一起,结构不分明,视觉上沉重。

3、习惯上:微信支付宝等主流应用都是底 tab,习惯已养成。 


qiaoxiaodu:
以前认为符合各平台规范的开发可以提高开发效率,但双版本维护不同样式,反而增加难度。两边一样,开发效率更高,维护成本也低,况且转化率也在那摆着呢,我记得微信网易新闻都是尝试过了以后就统一了。

回复(0)

10月前 ask:全栈程序员的市场价值在哪里? by 纯银V · 黄埔犬校

提问:全栈程序员的市场价值在哪里?
最近两年流行“全栈“这个概念,令我很迷惑。比如我司就有全栈程序员,对我来说,他的价值主要在于iOS 研发,繁重的 iOS 研发工作占满了他的时间,无暇支援其他栈的研发。
全栈是程序员的能力,也是程序员的骄傲。但在实际工作中,一个全栈程序员在一家公司总是做单一类型的编程,单一类型的编程已经忙不过来了,除非换一家公司,全栈的技能无从施展。
即便换一家公司,多半还是使用磨练得最多的技能。
全栈对我来说意味着“临时支援“,比如iOS 程序员还能抽10%的时间完成 H5页面,蝉小队就是这么干的,其他时候还是在单栈将时间占满——专注才能提高效率。如果我们这样精简的小团队都用不上全栈,大公司更用不上。那么全栈程序员的市场价值在哪里呢?

leexz:
不想为别人打工的时候,全栈是一条合适的选择,直接自己接全包。不承担创业风险,不用费心找合伙、不用扯皮如何分钱。


fors:
我觉得全栈的个人价值大于市场价值。接触过的全栈几乎都有做自己的side project,有的赚点零花钱,有的做着做着就自己去开公司了。对于雇佣全栈程序员的公司来讲,除了银叔说的“临时支援”,确实还没发现其他价值。


yisong:
说说Facebook的情况,未必适用于国内大公司。

Facebook是鼓励全栈的。最现实的理由是Android开发人员缺口太大,怎么招都招不满,因此必须动员大家对移动端的需求尽量自己解决。

另外公司在运作机制上的特点,比如工程师对业务负责(而不是对开发负责),比如极端鼓励大家换组,这在客观上也推广了全栈。


shrinklynn:
我觉得市场上的全栈有一部分言过其实,很多人自己单一类型的编程都做不好,跑个hello world写个小demo也叫会一项技术。号称全栈只是他们抬高身价的一种手段,真正的全栈感觉真的很难。

我司以前的CTO算是很厉害的全栈了,从初中就开始玩编程,之前获得过谷歌的offer,他在项目吃紧的时候过来帮忙,写的iOS还是一坨内存溢出,让我们后来一阵好找。


wuvist:
前端搞node的那帮『全栈』指望以一门语言吃遍各端,我觉得就是在扯淡,真正的全栈应该是深入了解各端不同的语言、技术,然后就可以去做个技术经理吧~很多时候前后端是需要紧密协作的,避免撕逼内耗的最佳方式,就是找个两端都懂的人去管理。

回复(0)

10月前 ask:Growing IO使用经验谈 by 纯银V · 黄埔犬校

提问:有使用过Growing IO的小伙伴吗?或者大家用的其他的什么第三方的数据系统?今天他们的销售过来做了一下演示和讲解,无埋点技术确实是企业类客户的痛点,至少对于尝试成本要低很多,我很心动想试一下,不过价格真贵。

xiaodou:
目前在用,不推荐。原因如下:

1.统计数据不全,只能统计前端层面数据,也就是pv、uv、点击等数据,业务层面还是要自己埋点,比如我们的电话功能,只能统计点击拨打数据,但不能统计电话量,也就意味着要看完整转化率,自己埋点少不了。

2.操作复杂,工程量不小。一个个建指标,建指标的方式本就不简单,稍微复杂的产品不低于200个吧,再加上多用户端,维护一份完整的指标成本很高,还需要对它各项功能给公司培训。反正我是后来放弃了。

3.如你所说,价格不低。相比自己做算下来并不会省太多。再加上第一点,意味着成本是两份。

4.高级功能,如智能漏斗什么的,从来没分析出正确的模型,也是看起来厉害,实际鸡肋。

也可能是我们姿势不对。

综上所述,试用下来我们决定自己建数据仓库了。如果是创业团队只要看关键数据的话,每次prd附上埋点需求并不难,可以每日或每周邮件的方式同步即可,稍大的团队做下关键指标看板,每个需求单独提埋点和统计需求以便复盘分析就够了!再大的团队就需要建BI部门了吧!


slsfzds:
有一个刚从 Growing IO 离职的产品经理,他的说法是,看衰这家公司的最大原因,是客户续费率太低。无埋点能解决 80% 的数据问题,但类似电商漏斗中,在购物车页面用户的一些操作,无埋点无法采集,而这些往往不能忽视,所以他们也开始往后端埋点的方式上走。


fors:
今年试用过一下Growing IO,我个人观点也是不太建议使用,原因和@dou 差不多。

另外我补充两点:
1. 如果团队技术不强,且产品不复杂,用GIO是OK的,无埋点确实上手门槛低。

2. 只要产品稍微复杂一点,或者想追踪的数据维度复杂一点,用GIO这种无埋点的反而更困难,因为自定义的空间太小。说简单点,GIO那边的程序能抓到哪些,你几乎就只能看哪些。

我个人一直使用Google Analytics + Google Tag Manager,自定义的程度非常高,几年用来下来很少碰到想抓但是抓不到的数据。


miyam4a1:
我经历的产品用过一些统计工具,像什么百度统计,友盟,腾讯什么的,只能统计基本的数据,说到精细化运营分析,必须自己埋点。现在在做的产品是客户管理方面的,后期要统计各种客户数据,产品数据,销售数据等,半个月前我列了三百多条埋点,开发边做边加,并不麻烦。


karryzhang:
谢谢大家,这个社区真的有价值。那么神策这类埋点的数据分析系统呢?是否可以大规模的降低自己研发的成本?


slsfzds:
@karryzhang 看你的视角,我去年自费参加过神策和 GIO 的增长培训,从数据分析师视角,神策完全触动了我,真正做到了分析思路产品化。但是它全程强调,一定要做后端埋点,我不是 RD,不太确定部署成本。


liuhanyu:
详细说下我用过的几个工具吧,友盟之类纯统计工具的现在劣势很明显,就不多说了。

Google Analytics 是 web 端分析的首选,极为强大,在统计时也不受墙的影响,只有分析的时候需要翻墙。但是 GA 的移动客户端分析工具很难用,也可能是我自己不习惯,国内用 GA 统计移动端日志的厂商应该也挺少。

GrowingIO 卖点是「无埋点」技术,无埋点也就导致了没有什么细分维度,基本上就是记录「谁」在「什么时候」点击了「哪个页面」的「哪个位置」,适合用于运营、Marketing 的同事快速看一下 PV、Click、和这个层面上的转化率,细一点的产品需求就较难满足。这点 @xiaodou 说的很全面了。

神策主打卖点是后端采集和私有化部署,那么当用户触发一个行为事件时,可以记录下用户当前行为产生的所有维度的数据,例如下订单时可以记录用户买了哪些分类的哪些商品、订单金额、订单来源、是否使用优惠、付款方式、用户地理位置、用户获取渠道、用户会员等级等等所有后端数据中的维度,这些数据构成了业务分析的基础。
神策的劣势在于埋点还是挺花时间的(神策也有无埋点的功能,但是我个人认为不如 GIO 好用),想偶尔看单个按钮的点击量不如 GrowingIO 好用。同时神策也需要产品经理对数据采集有比较成熟的分析思考,以事件为核心,而不是以 PV 为核心的统计模型,对于非产品和工程的同事也可能不那么好理解。
另外神策可以导出清洗后的事件日志,供 SQL 分析甚至直接接到内部系统上,这个在神策提供的分析功能不够用的时候还是非常实用的。


Miao Miao:
埋点主要分为四步:
第一步是后端产品提出哪些地方需要埋点。
第二步是研发根据需求埋点。
第三步是测试人员测试埋点是否准确。
第四步是数据分析人员根据埋点情况,为下一步的计划迭代提供建议和数据证明。

看似完美的过程,可能会存在很多问题。
第一步中,后端产品经理一般会选择尽可能的全部埋点,忽略了和业务的结合需求。没有考虑业务流程,只是为了追求全。
第二步中,研发人员埋点一般没有太多问题。但是,第三步中测试人员却可能存在对于埋点的理解偏差。
第四步,我觉得很多小公司压根没有根据每一次的迭代做数据分析,同时第一步考虑不周也会耽误很多事。有时候,埋点的方式不重要,重要的是别埋着埋着,忘了埋点的目的。

回复(0)

10月前 ask:小团队怎样对待细节优化? by 纯银V · 黄埔犬校

提问:局部的小功能、流程、UI的优化,虽然直觉上有助于改进体验,但没有数据支撑,总是不够理直气壮,又觉得没有必要为此专门花精力去做A/B Test,小团队限于开发资源少,也不太可能去做。另外又有句话叫:魔鬼在细节中,用户体验就是一点一点的改进,从量变到质变。那么问题来了,在小团队中,类似这样的“优化”,究竟做还是不做呢?

escphoton:
首先关注那些明显拉低用户体验的问题。这类问题解决之后,一般来说产品会到达一个相对稳定的阶段,再去关注那些细节的优化,这个时候工程师团队应该会有闲置精力去做A/B Test。所以,关键是准确判断哪些问题严重,哪些问题可以搁置,排列出优先级。

道理是这个道理,但现实是,准确判断问题的严重程度非常困难,而且团队中不同成员会有不同看法和意见,达成一致更加艰难。


coen:
视项目开发阶段。已经定稿的,为了不影响进度,俺是不会坚持改进的,不影响当前阶段进度。下个阶段可以把优化和bug同步进行。新开发阶段中的优化,那就看这个阶段的项目开发量和时间,“尽量”塞一点点就逐步解决了。


flakegx5:
还有一个办法是之前听说的豌豆荚的方法。每个月都腾出来一周时间,去做那些因为收益不明显而被判断为低优先级的细节体验优化需求。


nick:
1. 紧扣项目目标和策略;例如,如果项目是为了快速上线去抢占市场/赚钱,那么尽量就不要在细节过于浪费时间;如果项目想打造口碑来获取留住用户(特别是工具类的产品),那么魔鬼细节还是值得去深究的。

2. 同样的开发成本下做得更好;例如,一开始产品和设计就把流程考虑细致一点、在开发有多个方案可选择,且成本差不多的时候,引导开发往体验更好的方案做。


cicada:
细节调优这件事,对成败没有影响,甚至于大部分细节调优对行为数据的影响都不大,调优这件事做不做,做到什么地步,都是产品经理的个人追求。

比如我,我还算是比较抠细节的人。我抠细节不是因为收益很大,就是对细节敏感,不抠我不舒服。

另一个案例是陌陌,陌陌的细节一直比较糙,who care?人家现在不也赚到盆满钵满吗?唐岩在一些访谈中明确表示过抠细节没意思——实质上是他不爱抠细节。你看张小龙抠细节也抠得乐呵乐呵的,甚至有传言说他会参与制定大部分的产品文案。

因人而异,没有定论。

在现实中,对细节不太敏感,但大方向把握得很好的创始人,产品经理,比如唐岩,这样的人是少数。对细节敏感的产品经理是多数。所以虽然抠细节的性价比不高,但PM还挺爱抠细节的,这不是对错选择,就是人群偏好。


escphoton:
@cicada 有一种情况,产品大方向已经基本上定型,可能只剩细节去抠了。这个时候,PM的工作也挺无聊的。

回复(0)

10月前 提问的技术 by 纯银V · 黄埔犬校

犬校目前的会员,除开管理员是210人。第三期续费率低至70%,因此最终留存估计是200人左右,周活100人左右。

为什么续费率偏低呢?因为活跃度下降了。为什么活跃度下降呢?虽然我很认真地回复了每一个问题,甚至是每一贴(我在微博曾经的挂牌回答价格是199元),但还是没什么新问题。提问频次从巅峰时期的一天5个,降低到一周两三个。

换句话说,存量问题消耗完毕,增量问题因为会员基数太少,增长迟缓,更多是紧跟行业热点的讨论——而热点不常有。这也是从第二期报名开始,我要求“先提三个问题”的原因。但我依然高估了同行,即便事先列举了大量的问题示范,强调“案例分析,一事一议”才是小社区好问题的标准,第三期报名(100+来信)的通过率依然不到40%。

以下不记名地列举几个坏问题作案例分析——每个未通过的报名者只选一个问题,保证样本分布均匀。

Q:最近我一直在思考一个问题,抛开内容层,从产品层去考虑,如何设计产品架构让产品本身就可以对用户产生一定的吸引,带给用户沉浸感,从而让用户在产品中留下更多的时间?不同产品内容形态也需要不同的思考,内容形态包括:短文章、长文章、图片、长视频、短视频、语音等。
A:我长成什么样子就可以对女人产生一定的吸引,让她们爱上我?

Q:产品推进中,如何提高沟通效率,降低沟通成本?
A:手持电锯,目露凶光。

Q:我个人在简书看到很多输出优质内容的作者,接收到的打赏不多,即便文章写的很好,原因是什么呢?
A:这真的是一个产品经理问出的问题吗?

Q:58到家给保洁阿姨派单,两种派单方案:1.商圈模式限定阿姨接单范围;2.全城按距离派单。分析两种方案的优劣。
A:这是在面试犬校成员做产品助理吗?

Q:用“自动摘要”技术做一个新闻摘要产品,如何才能在新闻这个领域与今日头条、一点资讯、和即刻这样的产品竞争取得局部优势?并进而拓展更大的空间?
A:汇100万¥到我的支付宝账户,我试着用一年时间回答1万字长文。

Q:在包括产品、设计和开发只有7个人的早期团队,如果你是产品经理,我告诉你在初期,我们应该为80%的主流正常用户提供好的体验,而不应该为20%的非正常情况花费太多时间和开发成本,你会怎么回复我?
A:常识不需要反复讨论,犬校又不是小白之家。

Q:微博赞赏以前是叫打赏,不少博主对这个词都不爽,觉得创作像是卖艺的。相比之下,赞赏一词接受度更高,能让读者和作者在心态上更加平等。由此可见细节对于用户心理的影响,但如果要把所有的细节都考虑到,这也是不切实际的事,那么请问什么样类型的细节问题,才有必要去改进优化?
A:请问什么样类型的生活作风问题,你才有必要为自己去改进优化?

Q:产品中可以采用的互动方式有很多,例如:送花、点赞、喜欢、转发、评论、关注、收藏、感谢、反对、不感兴趣。该如何根据产品特性选择创作者和浏览者的互动方式呢?可结合一款产品谈谈你的看法。
A:问题本身并不差,但语言风格像是笔试,资深产品经理(也就是最能输出的这批人)没人喜欢回答你的笔试。

Q:发现和订阅两个入口在各大app的排序并不尽相同。微博、知乎更在意用户的订阅和筛选出的信息,而诸如锤子阅读和新闻类app大多是优先发现,其次订阅。背后的选择逻辑是什么?
A:问题不差,但太外行。外行问题提多了,犬校成员也是会不高兴的。

Q:甲方要求我们在数据统计模块(针对广告主可以看到的数据)增加数据(造假)系数,我们该不该增加,为什么?
A:关我…事。

Q:最近一直在思考,一个产品经理如何持续的不断迭代自己,身为产品经理如何构建自己的产品思考体系?
A:我花5秒钟平复了一下情绪。

Q:很多时候产品模型是和业务管理模式密切相关的,当遇到业务管理模式经常变化的情况,这时候你作为产品是如何应对的?
A:跳楼自杀。

Q:设计不仅仅是美观层面,而是通过视觉语言增强易用性。同样功能布局,设计好的那个用户体验更好。产品经理容易从业务逻辑出发,设计师容易从用户体验出发,两者对于产品的角度不一样容易导致分歧。比如为了提升业绩,在订单详情页增加领券弹窗,设计师认为对用户造成干扰。那么产品经理要从哪些方面来平衡业务与体验呢?
A:认真学习八荣八耻。

Q:假设由你负责一个时尚美妆资讯类的app产品,目标用户是17~35岁以内的女性,运营团队只有1个编辑,你该如何设计最小化的产品功能?如何利用有限的人力完成内容建设?
A:暴打老板,用枪指着他的头逼他招人,不招就杀他全家。

Q:如何逆推出一款产品的feed流策略?比如今日头条的feed流规则是如何设计的?如果让你设计你会怎么做?
A:你对分发策略一无所知。

随便挑了15个人的15个问题,都是我看了以后会生气的那种。

知乎在“如何提一个烂问题”这方面,为我国作出了不可磨灭的贡献。同时又因为知乎的体量巨大,即便是一个宏大叙事的烂问题,也有小概率被热心网友举例说明分析——这些答案被推到聚光灯下,让人产生误解,觉得自己随便提一个烂问题,就能获得几千字的菊花宝典。但是,请看我的口型:

宏大叙事是渣渣!
终极发问是渣渣!
没礼貌的面试或笔试提问也是渣渣!

最后再重复一次犬校的规矩:“案例分析,一事一议,用思考交换思考。”浅薄的思考在犬校只会交换无声的嘲笑。

回复(0)

10月前 一年来,我做了一个什么样的饼 by 纯银V · 产品

从完成第一期组队到现在,已有一年,说说这一年来做的猫饼吧。

从旅行赛道切到短视频,我的切入点是“视频剪辑”,帮助更多用户在手机上剪辑视频,通过剪辑来提高视频的内容质量。

犬校有一位同学曾经提出疑问:视频是否好看,主要的影响因素是主题,而不是剪辑。他这个观点当然是对的。

我把“剪辑”比做“文笔”。

小说是否好看,主要的影响因素是故事,而不是文笔。但好文笔能加强高小说的阅读快感,尤其是较长篇幅的小说必然建立在“文笔”基础上。对比短视频,同样的拍摄主题,剪辑技巧能明显提升视频质量,也能支撑超过15s的视频——超过这个长度,若没有熟练的后期剪辑,99%的情况下会显得冗长乏味。

在我发起这个项目的2016年,视频剪辑还是一件相当小众的事情。让更多人上手剪辑,就是我做猫饼的初衷。

┃视频编辑器

“首先,请大家看看最新的猫饼iOS版本,不要带着老印象去评价它。”

在最新版本里,我们实现了分段变速/分段配乐/分段录音,有独特的跳剪模式(适合制作定格动画),以及“一键鬼畜循环”功能。用户能灵活调整全片及每一个镜头的画面参数,也能二指缩放视频画面,动画字幕与过场字幕则是猫饼的传统优势。

目前市场上,视频剪辑产品主要是三家:小影、猫饼、一闪。小影的体量最大,我预测为国内100万日活,日新增8-10万激活,在这个领域深耕五年之后,小影的功能也是最全面的,猫饼和一闪则有更出色的交互设计和易用性,更高的剪辑效率。同为去年发布的VLOG工具,很多人会用猫饼和一闪对比,两款产品的交互有着截然不同的层级处理,背后是两种立场鲜明的设计出发点。

猫饼春节前发布的iOS1.53,在编辑器方面是令我自己满意的版本,当然也还有几十个优化点等待迭代。

安卓落后iOS两个版本,剪辑“可用”但还不够优秀。安卓端缺乏iOS端成熟的视频编辑库,大量功能需要自己来写而不是调用原生系统,这些自研的功能又得做大量的兼容性适配,研发难度远高于iOS版本。接下来预计增加50%的人力以及半年时间,才能接近iOS版本的体验。

通过业界同仁的努力,在手机上剪辑视频,已经消除了工具端的障碍。

┃贴纸底层库

一年来,我们做的最重要的两件事,除了视频编辑器之外,就是开发自己的贴纸底层库。它的用途是,设计师在AE上设计动效,一键导出为仅有几十K大小的二进制PAG文件,比如说自带动画效果的字幕贴纸,应用在编辑器里,用极低的设计成本去替代高昂的研发成本。

类似的产品中,最出名的是Airbnb开源的Lottie,但Lottie无法编辑文字,支持的文本样式有限,在iOS上应用于视频合成时会丢失部分动画,在安卓上渲染性能较差,导出插件未能导出我们需要的大量属性,所以无法扩展Lottie来满足视频字幕需求,只能研发自己的全套解决方案。

我们希望在自由修改文字的基础上,实现文字投影/描边/镂空/自动排版,以及反向遮罩等效果,用AE设计以字幕为主的,丰富的视频动效,在iOS和安卓端做到一致的硬件加速渲染。技术合伙人Dom撸起袖子,基于OpenGL/Skia,从导出插件到文件编解码再到渲染,完全用C++重写了一套和Lottie类似的贴纸库,应用游戏渲染里的大量优化技术,又称为“Dom的底库”。

这袖子一撸就是一年。

2017年底,贴纸库的主要部分研发完成,新版猫饼的抖动/飞旋/镂空字幕,动画过场字幕,都是底层迭代的功劳。在它的支持下,未来将实现更活泼的字幕,更华丽的特效,只需要AE设计后一键导出。

第二期贴纸库在一个半月前上线,对它的潜力挖掘才刚刚开始。第三期支持嵌入图片和声音后,可以在(字幕之外的)更多层面应用AE动效。我们有一些计划,轻松添加过去在电脑上煞费心思制作的视频特效,实现炫丽的转场效果,将PGC效果的高门槛降低到人人唾手可得。

┃内容与社区

前面提到过,视频是否好看,主要的影响因素是主题,包括“有魅力的人”和“有趣的事”。剪辑在这个基础上才能明显提升视频质量,这意味着三重筛选。因此,在通过工具feature拉到一定体量之前,剪辑工具很难大量产生高消费性的视频。

除此之外,目前的剪辑用户比较少考虑“内容消费”这件事,更偏向于为自己制作VLOG,而不是做给别人看的视频。这会导致画面精美但节奏拖沓,情绪饱满但缺乏看点。

因此,产品先得有体量,筛选出来足够多 “熟练剪辑的用户” + “有趣的主题”,然后运营引导头部用户从内容消费的角度来进行创作,建立榜样。

想必有人会问,这路径是不是太长了?

是的。

但只有在剪辑的支撑下,才能将短视频从目前15s以内的“表演与生活片段”,拓展到更复杂的“记事与个人表达”。换句话说,剪辑能大大扩充短视频的内容类型,让更多人发布之前PGC才能实现的内容,从而兼顾PUGC的质量与UGC的多样性。正是这个愿景吸引我们切入短视频赛道。

基于这一点,从工具到社区,指的是视频玩家社区,而不是大众社区。我曾经尝试用主题脚本的方式来运营玩家社区,后来意识到这个阶段的体量不足以拉动社区,还得通过工具夯实基础做大规模。因此先专注于编辑器,社区留待来年。

又及,猫饼首页的“连载”tab,是半年来积累的内容精华。现在发布的只是很小一部分,运营同学囤了一大批年货分批更新。

┃短视频赛道

短视频是一条大赛道,也是门槛极高的赛道。四年来,新产品只有抖音、火山、西瓜、VUE出头,其中的独立创业团队只有VUE。

由于内容模式是易于复制的,没有背景的团队只能像VUE一样,从工具切入。在主流的“拍摄视频”场景,VUE做得非常棒,我找不到切入点,转攻后期剪辑,同时我的内容基因也更适合走剪辑这条路。

一年过去了。回头来看,至少实现了当初为自己定下来的保底目标:一是做一款自己满意的视频编辑工具,二是切换到新赛道去学习新市场。

谢谢猫饼组,比心。

回复(0)

1年前 一年来,我做了一个什么样的饼 by 纯银V · 产品

从完成第一期组队到现在,已有一年,说说这一年来做的猫饼吧。

从旅行赛道切到短视频,我的切入点是“视频剪辑”,帮助更多用户在手机上剪辑视频,通过剪辑来提高视频的内容质量。

犬校有一位同学曾经提出疑问:视频是否好看,主要的影响因素是主题,而不是剪辑。他这个观点当然是对的。

我把“剪辑”比做“文笔”。

小说是否好看,主要的影响因素是故事,而不是文笔。但好文笔能加强高小说的阅读快感,尤其是较长篇幅的小说必然建立在“文笔”基础上。对比短视频,同样的拍摄主题,剪辑技巧能明显提升视频质量,也能支撑超过15s的视频——超过这个长度,若没有熟练的后期剪辑,99%的情况下会显得冗长乏味。

在我发起这个项目的2016年,视频剪辑还是一件相当小众的事情。让更多人上手剪辑,就是我做猫饼的初衷。

┃视频编辑器

“首先,请大家看看最新的猫饼iOS版本,不要带着老印象去评价它。”

在最新版本里,我们实现了分段变速/分段配乐/分段录音,有独特的跳剪模式(适合制作定格动画),以及“一键鬼畜循环”功能。用户能灵活调整全片及每一个镜头的画面参数,也能二指缩放视频画面,动画字幕与过场字幕则是猫饼的传统优势。

目前市场上,视频剪辑产品主要是三家:小影、猫饼、一闪。小影的体量最大,我预测为国内100万日活,日新增8-10万激活,在这个领域深耕五年之后,小影的功能也是最全面的,猫饼和一闪则有更出色的交互设计和易用性,更高的剪辑效率。同为去年发布的VLOG工具,很多人会用猫饼和一闪对比,两款产品的交互有着截然不同的层级处理,背后是两种立场鲜明的设计出发点。

猫饼春节前发布的iOS1.53,在编辑器方面是令我自己满意的版本,当然也还有几十个优化点等待迭代。

安卓落后iOS两个版本,剪辑“可用”但还不够优秀。安卓端缺乏iOS端成熟的视频编辑库,大量功能需要自己来写而不是调用原生系统,这些自研的功能又得做大量的兼容性适配,研发难度远高于iOS版本。接下来预计增加50%的人力以及半年时间,才能接近iOS版本的体验。

通过业界同仁的努力,在手机上剪辑视频,已经消除了工具端的障碍。

┃贴纸底层库

一年来,我们做的最重要的两件事,除了视频编辑器之外,就是开发自己的贴纸底层库。它的用途是,设计师在AE上设计动效,一键导出为仅有几十K大小的二进制PAG文件,比如说自带动画效果的字幕贴纸,应用在编辑器里,用极低的设计成本去替代高昂的研发成本。

类似的产品中,最出名的是Airbnb开源的Lottie,但Lottie无法编辑文字,支持的文本样式有限,在iOS上应用于视频合成时会丢失部分动画,在安卓上渲染性能较差,导出插件未能导出我们需要的大量属性,所以无法扩展Lottie来满足视频字幕需求,只能研发自己的全套解决方案。

我们希望在自由修改文字的基础上,实现文字投影/描边/镂空/自动排版,以及反向遮罩等效果,用AE设计以字幕为主的,丰富的视频动效,在iOS和安卓端做到一致的硬件加速渲染。技术合伙人Dom撸起袖子,基于OpenGL/Skia,从导出插件到文件编解码再到渲染,完全用C++重写了一套和Lottie类似的贴纸库,应用游戏渲染里的大量优化技术,又称为“Dom的底库”。

这袖子一撸就是一年。

2017年底,贴纸库的主要部分研发完成,新版猫饼的抖动/飞旋/镂空字幕,动画过场字幕,都是底层迭代的功劳。在它的支持下,未来将实现更活泼的字幕,更华丽的特效,只需要AE设计后一键导出。

第二期贴纸库在一个半月前上线,对它的潜力挖掘才刚刚开始。第三期支持嵌入图片和声音后,可以在(字幕之外的)更多层面应用AE动效。我们有一些计划,轻松添加过去在电脑上煞费心思制作的视频特效,实现炫丽的转场效果,将PGC效果的高门槛降低到人人唾手可得。

┃内容与社区

前面提到过,视频是否好看,主要的影响因素是主题,包括“有魅力的人”和“有趣的事”。剪辑在这个基础上才能明显提升视频质量,这意味着三重筛选。因此,在通过工具feature拉到一定体量之前,剪辑工具很难大量产生高消费性的视频。

除此之外,目前的剪辑用户比较少考虑“内容消费”这件事,更偏向于为自己制作VLOG,而不是做给别人看的视频。这会导致画面精美但节奏拖沓,情绪饱满但缺乏看点。

因此,产品先得有体量,筛选出来足够多 “熟练剪辑的用户” + “有趣的主题”,然后运营引导头部用户从内容消费的角度来进行创作,建立榜样。

想必有人会问,这路径是不是太长了?

是的。

但只有在剪辑的支撑下,才能将短视频从目前15s以内的“表演与生活片段”,拓展到更复杂的“记事与个人表达”。换句话说,剪辑能大大扩充短视频的内容类型,让更多人发布之前PGC才能实现的内容,从而兼顾PUGC的质量与UGC的多样性。正是这个愿景吸引我们切入短视频赛道。

基于这一点,从工具到社区,指的是视频玩家社区,而不是大众社区。我曾经尝试用主题脚本的方式来运营玩家社区,后来意识到这个阶段的体量不足以拉动社区,还得通过工具夯实基础做大规模。因此先专注于编辑器,社区留待来年。

又及,猫饼首页的“连载”tab,是半年来积累的内容精华。现在发布的只是很小一部分,运营同学囤了一大批年货分批更新。

┃短视频赛道

短视频是一条大赛道,也是门槛极高的赛道。四年来,新产品只有抖音、火山、西瓜、VUE出头,其中的独立创业团队只有VUE。

由于内容模式是易于复制的,没有背景的团队只能像VUE一样,从工具切入。在主流的“拍摄视频”场景,VUE做得非常棒,我找不到切入点,转攻后期剪辑,同时我的内容基因也更适合走剪辑这条路。

一年过去了。回头来看,至少实现了当初为自己定下来的保底目标:一是做一款自己满意的视频编辑工具,二是切换到新赛道去学习新市场。

谢谢猫饼组,比心。

回复(0)

1年前 ask:微信搜索为什么要前置分类? by 纯银V · 黄埔犬校

提问:微信搜索为什么有个指定分类的功能?现在比较少见此类搜索方式,一般都做的像Google那样,一个框就结束了。为什么不直接全都搜索,然后在结果中再做区分?

henuwangkai:
微信搜索结果包含以下几个元素:
1、联系人
2、群聊内容
3、聊天记录
4、收藏
5、查找未添加的微信号
6、查找已关注的公众号
7、文章、朋友圈、小说、音乐和表情等。

你可以测试一下,聊天记录和群聊搜索结果特别容易混淆。

公众号和微信号特别容易混淆。

我觉得搜索内容容易混淆、增加识别成本应该是其考虑一点。

另外一点是:增加结果分类后不仅没有占用太多搜索结果空间影响体验,还能提升识别效率。

还有一点是:聊天记录中有“查看更多聊天记录”的标识,当你在搜索一个特别大众的词汇时,可能你的聊天记录很多,需要进入二级页面,这时候就需要给出二级入口,还是需要给出搜索结果分类。


tony:
搜索作为一个谷歌百度出现之前没有清晰对标物的产品。严重不看好微信做全网搜索,微信做聊天记录,朋友圈,公众号的搜索我觉得还有点谱。微信做全网搜索会严重冲乱微信的产品定位,这样做的结果很可能是用户觉得微信“搜全网又搜不全”,且“搜微信内部信息又显得效率太低”,最终会退回搜微信生态内部的内容。况且,分类这个产品动作本身就非常不自然。


henuwangkai:
@tony 我们都把问题理解错了。微信搜索页面确实不同于Google、百度而有指定内容。但你可以发现没有“聊天记录”、“联系人”等分类。

这个问题就特别简单了: @chenglong 你测试一下微信搜索结果页,会发现底部有“搜一搜文章、朋友圈、小说、音乐和表情等”。

微信把这个分类前置了,并且前置的呈现效果要比在结果页在像Google、百度分类别搜索体验更好。


zcegger:
倒是觉得微信这么做是考量过用户场景的,Google 类的搜索指向性不明显,通常一个 query 出的结果并不能明确到某一领域或场景;反而用户在微信里搜的时候多半在搜之前就已经知道自己要的是联系人还是聊天记录还是�公众号了。做预选择是降低结果页的复杂度。在微信里请求全网搜索的用户心智,我认为还不像用百度他们那么强。


henuwangkai:
我们完全排除现有解决方案,如果是我们自己来做有以下几种方案:
1)像百度、Google一样的搜索结果呈现;
2)搜索结果分类呈现;
3)部分常用搜索结果分类呈现,不常用或新添加的归为一类,需要进行二次搜索;

目前肯定是第三种方案体验最优(这个应该是共识吧),因为“朋友圈”、“文章”等结果内容非常多、被搜索需求也没有联系人、公众号、群聊更强烈,更重要的是:微信一级搜索结果中都是关系链呈现,二级搜索(文章、表情、朋友圈)都是内容呈现。

目前微信应该一级搜索结果满足大部分需求,所以隐藏了内容相对多的二级搜索结果。这时候就面临和百度等搜索引擎不一样的局面,把二级搜索结果前置并不增加负担却能增加体验。


tony:
@henuwangkai 是的,我的理解也不准确,导致回答太跳跃。@chenlong的问题是“微信为什么不像google那样对搜索结果进行后置分类”

针对这个问题的答案是:微信目前没有能力去做全搜索结果的后置分类。

这里的“没有能力”是个中性词,因为和网页这种格式化标准化的内容组织形式不一样,微信内部的内容格式高度不统一,难以统一搜索。

比如现在微信的搜索结果是有分类的,分类是1,最常使用;2,联系人;3,群聊;4,公众号;5,聊天记录;6,收藏;7,内容搜索(搜一搜)。其中有可能还插入一个“游戏类别”。同时前置也有分类,分别是“朋友圈”,“文章”,“表情”,“小说”,“音乐”,“表情”。

可以看到这些分类对应的内容可能是通讯录的联系人,可能是群聊名称,也可能是公众号名称等等。这些格式不统一的内容之间,缺乏一种像网页pagerank,社交媒体feed的edgerank的排名算法,这在技术上就形成了很大的挑战,微信很可能“没有能力”。因为内容形式不统一,就很难用同一个标准算法衡量每种内容的权重,即使是淘宝的商品,因为统一是商品,所以基于“好评”“购买量”“价格”等特征来做rank的技术挑战也比微信要在“联系人”“群聊”“公众号”“朋友圈”“表情”这些纷杂的内容形态之间做rank要简单的多。

简单说,如果只搜联系人,微信能做排名;只搜朋友圈,微信也能做排名;但是揉在一起,微信就不知道怎么做排名了:联系人应该排第一栏还是朋友圈内容应该排第一栏,或者说是表情包应该排第一栏?这个结论如何得出?

因为微信没有能力做这些不同格式内容的搜索排名,或者说控制不了把多种不同格式内容糅合在一起进行搜索的用户体验。他只能采取“后置分类倾向于IM产品的应用内搜索,如联系人,群聊,公众号”,“前置分类倾向于内容分类搜索,如表情,小说,音乐”。来达到一个虽然不如google百度这样流畅自然,但足够可控的,比较稳定的搜索体验。

回复(0)

1年前 ask:语音信息是否应支持加速播放? by 纯银V · 黄埔犬校

提问:你是一位与我共事的一款国内 IM 软件(类似微信、Facebook Messanger)的产品经理,我向你建议:要不要为我们产品中的语音播放功能提供一个可以类似 1.5/2 倍速度播放的选项,你会如何回复我?

zheng:
我会想知道你想加速的原因。

如果单纯是为了提高效率的话,我认为这也不失为一个办法,但并不能完全解决。一段40秒的语音,提高两倍速度的话需要还是要20秒,但变成文字的话10秒内就能看完了。如果从提升效率出发的话,我认为一键语言转文字会是一个更好的体验,但是不知道技术是否能够跟上。从我微信使用“转文字”功能的体验,有两个方面的顾虑,一是方言或中英夹杂的识别率;二是转换时间体验能否达到“一键”的效果。


leexz:
不会,从我观察�微信�使用情况来看,播放语音的时候人们习惯性点击播放直接拿到耳边,“点击--拿起“,已然成为一种习惯,中间加入速度选择,变成了“点击--选择--拿起“,在流程上打破习惯。 另外,作为即时通讯应用,会产生多长的语音文本??以至于需要快进来解决文本冗长的问题。


cicada:
@leexz 的观点很有说服力。“让用户选择“会摧毁这个功能的用户体验,选择动作完全打断了听语音消息的流畅性。


chenglong:
如果只加倍速,不一定能提高效率。腾讯视频有个倍速播放的功能,我确实为了效率会用,但是如果在看《奇葩说》,我就不会用,因为《奇葩说》的语速已经很快了;在用户的语速千差万别,同一段语音中的语速也有不同时,我不确定我调成了1.5倍速播放,是提高了效率,还是导致一部分听不清,还得重新听一次。


zzzzzzk:
作为用户,我怎么决策什么时候要按下这个快进播放的按钮?

回复(0)

1年前 ask:短视频适合评论还是弹幕? by 纯银V · 黄埔犬校

提问:最近工作中涉及到短视频的评论系统,目前有三种做法,一是评论+弹幕,二是纯评论,三是评论与弹幕合并。你们怎么看这三种选择呢?

cicada:
评论+弹幕的代表是B站与最右。

B站这么做很好理解,它既有长视频,也有短视频。长视频必然同时需要评论与弹幕系统,弹幕带氛围,评论看内容。

最右很有意思,最右的视频交互上倾向于弹幕,但评论数量压倒性地超过弹幕(B站弹幕更多一些)。用户宁肯看完短视频退出来评论,也不愿意一边看短视频一边发弹幕。这一点和最右的“神评论“社区文化相关。

纯评论的代表是快手。

评论与弹幕合并的代表是美拍。美拍在数据层只有评论,记录每一条评论的发布时间,将一部分评论转为弹幕。但美拍的弹幕交互极差,远不如B站和最右。长评论转弹幕的体验也是很差的。

然后我怎么看?我看短视频弹幕的内容性质。以B站和最右为例,大多数弹幕和评论没区别,以刷存在感为主,并没有针对特定的视频场景进行评论。同时短视频的内容相对扁平,很少有起伏曲折,多数情况下也不需要针对指定帧的评论,弹幕的优势少了一半。

在这种情况下我优先选择评论而不是弹幕,一是兼容较长的文字内容,二是支持回复评论和评论盖楼,增强社区互动,没必要同时上两套互动系统增加系统复杂度,何况弹幕的研发成本远高于评论。未来研发时间富余了,可以考虑美拍的做法,提取一部分评论转为弹幕,带带视频氛围,照顾那些特别喜欢弹幕的用户。


iveyhu:
如果视频内容不能引起情感共鸣,或是引发讨论撕逼,那评论区也会不太有生气,很鸡肋,还不如暂时不做评论。快手评论区给人的感觉就是这样,没啥意思。但是弹幕有氛围感,好像有很多人陪伴一样。正好大多数人看短视频的场景是夜里一个人无聊的时候。


cicada:
评论是对作者的极大鼓励,“弹幕的陪伴”则是一种因人而异的感觉。

短视频评论可以支持较长字数,可以支持互相回复,虽然快手里这类情况不多,但在最右里大量存在。换句话说,评论支持更丰富的互动行为,对社区运营有益。


harbuzi:
@cicada 今天正好又看了下最右,想起这个话题,从观看者的角度说一些。

对比B站和最右,可以很明确感受到弹幕在横屏和竖屏下有巨大差异。在横屏下,屏幕高度低,视觉集中度高,加上弹幕横向移动距离长,因此留给「阅读弹幕」注意力和时间要远比竖屏下多。带来的差异是B站的弹幕,更容易被「阅读」,而最右的弹幕,我很努力想去看弹幕的内容,但实在是看不进去,很累很累。加上最右都是短视频,真的不觉得看最右的视频,会有人认真看弹幕。

在B站,弹幕承担2个作用:1是增加(长)视频本身的信息量;2是让看视频的人觉得热闹。但在最右,我感觉其实只有后一种价值。也即是说,最右用弹幕做氛围,用评论做信息量的补充,不管有意无意,反正是把B站弹幕的双重作用拆分了。

以及,总觉得越年轻的人越需要「闹腾」的氛围,因此,最右这种选择还是有他的道理的。


yao126:
弹幕是“大家一起看电视”的感觉,评论是“看完后讨论的总结”或者是“与作者的交流”。若要取舍系统的话,根据自己产品研究这三个定位即可,例如视频长度、总结性讨论的必要性、与作者的交互性、话题的延展性。若要做好运营,考虑的会多一些,不过重要的是要想保证质量,产品必须有一定质量的种子用户基数再搞。

回复(0)

1年前 猫饼ö招聘全职设计师与运营实习生 by 纯银V · 产品

今年7月,产品经理圈的网红纯银…对…就是那个家伙,在短视频赛道发布了“猫饼ö”。

猫饼是一款“短视频创作工具”,特别适合编辑“自由度极高的视频”。和同类产品相比,有着“功能强大”和“操作简洁”的微妙的平衡性,将PC端繁复的视频编辑工具移植到手机上,帮助用户用手机剪辑高质量的视频。通过好用的工具,引导培育上百万的短视频创作人群,向内容平台转进。

目前的团队规模约20人+,已经拿到了两轮融资,投资方包括两家国内顶级VC。

猫饼在10月新开放两类职位。

工作地点:上海徐汇区,距离1/7/9号线10分钟步行距离
团队福利:10天带薪假期,提供早午餐,每月上门按摩,室内乒乓球桌

招聘设计师

工作内容:编辑器素材设计,安卓版UI设计
薪酬水准:月薪12-20K,每年13薪
职位要求:
1、因为猫饼的视频编辑器涉及大量素材设计,应聘者需具备丰富的平面设计经验,最好包括广告和插画经验,对字体搭配颇有研究。
2、熟悉AE操作,擅长用AE设计动画。
3、设计这事儿,看天赋,看作品,不看资历。从能力上来说,我们对平面设计和AE动画的要求都是中上,换算成正常履历大约是3-5年经验吧,但也接受天赋出众的1-2年经验。
★职位亮点:
猫饼有一位相当牛逼的UI设计师,可以在UI设计方面给予专业指导,很适合平面设计优秀,也希望在UI设计方面进阶的设计师。另外,我们的设计师从来不加班,对比广告行业……没有对比就没有伤害。

招聘邮箱:firecicada@gmail.com

招聘运营实习生(只接受在校生)

工作内容:用户运营
薪酬福利:月薪4K,日常福利和正式员工一样,零食按摩样样俱全
职位要求:
1、喜欢拍视频是基本要求,手机里没视频的就算了吧
2、能够使用手机App进行视频剪辑——最低限度,你总得会用猫饼吧
3、性格比较外向,天生“自来熟”,勾搭人是小意思
4、深度加入兴趣爱好社交圈,包括并不限于学校社团/二次元/美妆等
5、特别有耐心,擅长用搜索找人找内容
6、全职工作半年以上,但可以接受因为上课&论文短时间请假

招聘邮箱:lyracao@gmail.com

回复(0)

1年前 ask:Android原教旨主义失败了吗? by 纯银V · 黄埔犬校

提问:最近一两年,Android 原教旨主义者越来越少,iOS 底部�导航还是 Android 顶部导航的争论越来越少,这个月经引战贴是否以底部导航的胜利而告终了呢?

cicada:
这事儿要从头说起。

Android 从一开始就打算做大屏,当时 iOS 还没有横滑返回手势,为大屏定制了底部的物理返回键。我猜,为了避免底部的多层操作混乱(事实证明是多虑了),也为了跟 iOS 有所区隔,导航栏被放到了顶部。

顶部和底部的区别在哪里呢?

首先,顶部横滑切换 tab,要求各个 tab 之间是扁平化的关系,类似于从一个内容分类切换到另一个内容分类。如果 tab 不属于同一个维度,不属于“切换分类“的操作,而是“跳转到另一项功能页面“,这时候横滑就是不自然的操作。不自然,滑动切换率就会下降。

比这个更痛苦的是,如果存在两层导航,必然有一层导航得去点击而不是横滑。在 Android 大屏手机上,点击顶部导航必然是低频操作,这意味着放在这一层导航栏的所有功能页面都受到了极大损失。

因此,符合 Android 规范的顶部导航,仅仅适用于功能架构极简,不依赖两层导航的产品,而这样的产品为数极少。到目前为止所有自曝数据的产品,都认为底部导航的转化率更高,坚持 Android 原教旨主义的人,以我所见,以一线的 Android 爱好者居多,比如程序员,他们并不掌握大量的实战数据。

简书的简叔两年前自曝过数据,Android 版从顶部导航切换到底部导航后,次日留存率大涨,说明新用户更愿意探索应用,而不是看完首页就走。这条微博毫不意外地遭到了 Android 原教旨主义者的谩骂,大意是简书做得烂,不要怪规范。然而谩骂解释不了“改版提升次日留存率“的数据。

除此之外,微博的来去之间,糗事百科的王坚都曾经站出来讲过,底部导航的转化率更高。所以顶部导航日趋式微是必然的,制定这项规范的时候,恐怕想象不到未来的产品结构趋于复杂,这也是 iOS 规范更具前瞻性的证明。


daniel:
Android 自己的 APP 都凌乱了,原教旨主义溃败啊。


taitaigao:
1、操作上,单手时底部 tab 挨着大拇指,点哪到哪,快捷方便;顶部导航从首栏到三栏要多划一次,麻烦;点击切换又要大拇指去够,费劲。如果因为去够而摔了手机,估计会恨死。而且顶部导航无论单双手操作,都会挡视线;底部 tab 不会。

2、界面上:顶部导航会两层甚至三层堆在一起,结构不分明,视觉上沉重。

3、习惯上:微信支付宝等主流应用都是底 tab,习惯已养成。 


qiaoxiaodu:
以前认为符合各平台规范的开发可以提高开发效率,但双版本维护不同样式,反而增加难度。两边一样,开发效率更高,维护成本也低,况且转化率也在那摆着呢,我记得微信网易新闻都是尝试过了以后就统一了。

回复(0)

1年前 ask:全栈程序员的市场价值在哪里? by 纯银V · 黄埔犬校

提问:全栈程序员的市场价值在哪里?
最近两年流行“全栈“这个概念,令我很迷惑。比如我司就有全栈程序员,对我来说,他的价值主要在于iOS 研发,繁重的 iOS 研发工作占满了他的时间,无暇支援其他栈的研发。
全栈是程序员的能力,也是程序员的骄傲。但在实际工作中,一个全栈程序员在一家公司总是做单一类型的编程,单一类型的编程已经忙不过来了,除非换一家公司,全栈的技能无从施展。
即便换一家公司,多半还是使用磨练得最多的技能。
全栈对我来说意味着“临时支援“,比如iOS 程序员还能抽10%的时间完成 H5页面,蝉小队就是这么干的,其他时候还是在单栈将时间占满——专注才能提高效率。如果我们这样精简的小团队都用不上全栈,大公司更用不上。那么全栈程序员的市场价值在哪里呢?

leexz:
不想为别人打工的时候,全栈是一条合适的选择,直接自己接全包。不承担创业风险,不用费心找合伙、不用扯皮如何分钱。


fors:
我觉得全栈的个人价值大于市场价值。接触过的全栈几乎都有做自己的side project,有的赚点零花钱,有的做着做着就自己去开公司了。对于雇佣全栈程序员的公司来讲,除了银叔说的“临时支援”,确实还没发现其他价值。


yisong:
说说Facebook的情况,未必适用于国内大公司。

Facebook是鼓励全栈的。最现实的理由是Android开发人员缺口太大,怎么招都招不满,因此必须动员大家对移动端的需求尽量自己解决。

另外公司在运作机制上的特点,比如工程师对业务负责(而不是对开发负责),比如极端鼓励大家换组,这在客观上也推广了全栈。


shrinklynn:
我觉得市场上的全栈有一部分言过其实,很多人自己单一类型的编程都做不好,跑个hello world写个小demo也叫会一项技术。号称全栈只是他们抬高身价的一种手段,真正的全栈感觉真的很难。

我司以前的CTO算是很厉害的全栈了,从初中就开始玩编程,之前获得过谷歌的offer,他在项目吃紧的时候过来帮忙,写的iOS还是一坨内存溢出,让我们后来一阵好找。


wuvist:
前端搞node的那帮『全栈』指望以一门语言吃遍各端,我觉得就是在扯淡,真正的全栈应该是深入了解各端不同的语言、技术,然后就可以去做个技术经理吧~很多时候前后端是需要紧密协作的,避免撕逼内耗的最佳方式,就是找个两端都懂的人去管理。

回复(0)

1年前 ask:Growing IO使用经验谈 by 纯银V · 黄埔犬校

提问:有使用过Growing IO的小伙伴吗?或者大家用的其他的什么第三方的数据系统?今天他们的销售过来做了一下演示和讲解,无埋点技术确实是企业类客户的痛点,至少对于尝试成本要低很多,我很心动想试一下,不过价格真贵。

xiaodou:
目前在用,不推荐。原因如下:

1.统计数据不全,只能统计前端层面数据,也就是pv、uv、点击等数据,业务层面还是要自己埋点,比如我们的电话功能,只能统计点击拨打数据,但不能统计电话量,也就意味着要看完整转化率,自己埋点少不了。

2.操作复杂,工程量不小。一个个建指标,建指标的方式本就不简单,稍微复杂的产品不低于200个吧,再加上多用户端,维护一份完整的指标成本很高,还需要对它各项功能给公司培训。反正我是后来放弃了。

3.如你所说,价格不低。相比自己做算下来并不会省太多。再加上第一点,意味着成本是两份。

4.高级功能,如智能漏斗什么的,从来没分析出正确的模型,也是看起来厉害,实际鸡肋。

也可能是我们姿势不对。

综上所述,试用下来我们决定自己建数据仓库了。如果是创业团队只要看关键数据的话,每次prd附上埋点需求并不难,可以每日或每周邮件的方式同步即可,稍大的团队做下关键指标看板,每个需求单独提埋点和统计需求以便复盘分析就够了!再大的团队就需要建BI部门了吧!


slsfzds:
有一个刚从 Growing IO 离职的产品经理,他的说法是,看衰这家公司的最大原因,是客户续费率太低。无埋点能解决 80% 的数据问题,但类似电商漏斗中,在购物车页面用户的一些操作,无埋点无法采集,而这些往往不能忽视,所以他们也开始往后端埋点的方式上走。


fors:
今年试用过一下Growing IO,我个人观点也是不太建议使用,原因和@dou 差不多。

另外我补充两点:
1. 如果团队技术不强,且产品不复杂,用GIO是OK的,无埋点确实上手门槛低。

2. 只要产品稍微复杂一点,或者想追踪的数据维度复杂一点,用GIO这种无埋点的反而更困难,因为自定义的空间太小。说简单点,GIO那边的程序能抓到哪些,你几乎就只能看哪些。

我个人一直使用Google Analytics + Google Tag Manager,自定义的程度非常高,几年用来下来很少碰到想抓但是抓不到的数据。


miyam4a1:
我经历的产品用过一些统计工具,像什么百度统计,友盟,腾讯什么的,只能统计基本的数据,说到精细化运营分析,必须自己埋点。现在在做的产品是客户管理方面的,后期要统计各种客户数据,产品数据,销售数据等,半个月前我列了三百多条埋点,开发边做边加,并不麻烦。


karryzhang:
谢谢大家,这个社区真的有价值。那么神策这类埋点的数据分析系统呢?是否可以大规模的降低自己研发的成本?


slsfzds:
@karryzhang 看你的视角,我去年自费参加过神策和 GIO 的增长培训,从数据分析师视角,神策完全触动了我,真正做到了分析思路产品化。但是它全程强调,一定要做后端埋点,我不是 RD,不太确定部署成本。


liuhanyu:
详细说下我用过的几个工具吧,友盟之类纯统计工具的现在劣势很明显,就不多说了。

Google Analytics 是 web 端分析的首选,极为强大,在统计时也不受墙的影响,只有分析的时候需要翻墙。但是 GA 的移动客户端分析工具很难用,也可能是我自己不习惯,国内用 GA 统计移动端日志的厂商应该也挺少。

GrowingIO 卖点是「无埋点」技术,无埋点也就导致了没有什么细分维度,基本上就是记录「谁」在「什么时候」点击了「哪个页面」的「哪个位置」,适合用于运营、Marketing 的同事快速看一下 PV、Click、和这个层面上的转化率,细一点的产品需求就较难满足。这点 @xiaodou 说的很全面了。

神策主打卖点是后端采集和私有化部署,那么当用户触发一个行为事件时,可以记录下用户当前行为产生的所有维度的数据,例如下订单时可以记录用户买了哪些分类的哪些商品、订单金额、订单来源、是否使用优惠、付款方式、用户地理位置、用户获取渠道、用户会员等级等等所有后端数据中的维度,这些数据构成了业务分析的基础。
神策的劣势在于埋点还是挺花时间的(神策也有无埋点的功能,但是我个人认为不如 GIO 好用),想偶尔看单个按钮的点击量不如 GrowingIO 好用。同时神策也需要产品经理对数据采集有比较成熟的分析思考,以事件为核心,而不是以 PV 为核心的统计模型,对于非产品和工程的同事也可能不那么好理解。
另外神策可以导出清洗后的事件日志,供 SQL 分析甚至直接接到内部系统上,这个在神策提供的分析功能不够用的时候还是非常实用的。


Miao Miao:
埋点主要分为四步:
第一步是后端产品提出哪些地方需要埋点。
第二步是研发根据需求埋点。
第三步是测试人员测试埋点是否准确。
第四步是数据分析人员根据埋点情况,为下一步的计划迭代提供建议和数据证明。

看似完美的过程,可能会存在很多问题。
第一步中,后端产品经理一般会选择尽可能的全部埋点,忽略了和业务的结合需求。没有考虑业务流程,只是为了追求全。
第二步中,研发人员埋点一般没有太多问题。但是,第三步中测试人员却可能存在对于埋点的理解偏差。
第四步,我觉得很多小公司压根没有根据每一次的迭代做数据分析,同时第一步考虑不周也会耽误很多事。有时候,埋点的方式不重要,重要的是别埋着埋着,忘了埋点的目的。

回复(0)

1年前 ask:小团队怎样对待细节优化? by 纯银V · 黄埔犬校

提问:局部的小功能、流程、UI的优化,虽然直觉上有助于改进体验,但没有数据支撑,总是不够理直气壮,又觉得没有必要为此专门花精力去做A/B Test,小团队限于开发资源少,也不太可能去做。另外又有句话叫:魔鬼在细节中,用户体验就是一点一点的改进,从量变到质变。那么问题来了,在小团队中,类似这样的“优化”,究竟做还是不做呢?

escphoton:
首先关注那些明显拉低用户体验的问题。这类问题解决之后,一般来说产品会到达一个相对稳定的阶段,再去关注那些细节的优化,这个时候工程师团队应该会有闲置精力去做A/B Test。所以,关键是准确判断哪些问题严重,哪些问题可以搁置,排列出优先级。

道理是这个道理,但现实是,准确判断问题的严重程度非常困难,而且团队中不同成员会有不同看法和意见,达成一致更加艰难。


coen:
视项目开发阶段。已经定稿的,为了不影响进度,俺是不会坚持改进的,不影响当前阶段进度。下个阶段可以把优化和bug同步进行。新开发阶段中的优化,那就看这个阶段的项目开发量和时间,“尽量”塞一点点就逐步解决了。


flakegx5:
还有一个办法是之前听说的豌豆荚的方法。每个月都腾出来一周时间,去做那些因为收益不明显而被判断为低优先级的细节体验优化需求。


nick:
1. 紧扣项目目标和策略;例如,如果项目是为了快速上线去抢占市场/赚钱,那么尽量就不要在细节过于浪费时间;如果项目想打造口碑来获取留住用户(特别是工具类的产品),那么魔鬼细节还是值得去深究的。

2. 同样的开发成本下做得更好;例如,一开始产品和设计就把流程考虑细致一点、在开发有多个方案可选择,且成本差不多的时候,引导开发往体验更好的方案做。


cicada:
细节调优这件事,对成败没有影响,甚至于大部分细节调优对行为数据的影响都不大,调优这件事做不做,做到什么地步,都是产品经理的个人追求。

比如我,我还算是比较抠细节的人。我抠细节不是因为收益很大,就是对细节敏感,不抠我不舒服。

另一个案例是陌陌,陌陌的细节一直比较糙,who care?人家现在不也赚到盆满钵满吗?唐岩在一些访谈中明确表示过抠细节没意思——实质上是他不爱抠细节。你看张小龙抠细节也抠得乐呵乐呵的,甚至有传言说他会参与制定大部分的产品文案。

因人而异,没有定论。

在现实中,对细节不太敏感,但大方向把握得很好的创始人,产品经理,比如唐岩,这样的人是少数。对细节敏感的产品经理是多数。所以虽然抠细节的性价比不高,但PM还挺爱抠细节的,这不是对错选择,就是人群偏好。


escphoton:
@cicada 有一种情况,产品大方向已经基本上定型,可能只剩细节去抠了。这个时候,PM的工作也挺无聊的。

回复(0)

1年前 提问的技术 by 纯银V · 黄埔犬校

犬校目前的会员,除开管理员是210人。第三期续费率低至70%,因此最终留存估计是200人左右,周活100人左右。

为什么续费率偏低呢?因为活跃度下降了。为什么活跃度下降呢?虽然我很认真地回复了每一个问题,甚至是每一贴(我在微博曾经的挂牌回答价格是199元),但还是没什么新问题。提问频次从巅峰时期的一天5个,降低到一周两三个。

换句话说,存量问题消耗完毕,增量问题因为会员基数太少,增长迟缓,更多是紧跟行业热点的讨论——而热点不常有。这也是从第二期报名开始,我要求“先提三个问题”的原因。但我依然高估了同行,即便事先列举了大量的问题示范,强调“案例分析,一事一议”才是小社区好问题的标准,第三期报名(100+来信)的通过率依然不到40%。

以下不记名地列举几个坏问题作案例分析——每个未通过的报名者只选一个问题,保证样本分布均匀。

Q:最近我一直在思考一个问题,抛开内容层,从产品层去考虑,如何设计产品架构让产品本身就可以对用户产生一定的吸引,带给用户沉浸感,从而让用户在产品中留下更多的时间?不同产品内容形态也需要不同的思考,内容形态包括:短文章、长文章、图片、长视频、短视频、语音等。
A:我长成什么样子就可以对女人产生一定的吸引,让她们爱上我?

Q:产品推进中,如何提高沟通效率,降低沟通成本?
A:手持电锯,目露凶光。

Q:我个人在简书看到很多输出优质内容的作者,接收到的打赏不多,即便文章写的很好,原因是什么呢?
A:这真的是一个产品经理问出的问题吗?

Q:58到家给保洁阿姨派单,两种派单方案:1.商圈模式限定阿姨接单范围;2.全城按距离派单。分析两种方案的优劣。
A:这是在面试犬校成员做产品助理吗?

Q:用“自动摘要”技术做一个新闻摘要产品,如何才能在新闻这个领域与今日头条、一点资讯、和即刻这样的产品竞争取得局部优势?并进而拓展更大的空间?
A:汇100万¥到我的支付宝账户,我试着用一年时间回答1万字长文。

Q:在包括产品、设计和开发只有7个人的早期团队,如果你是产品经理,我告诉你在初期,我们应该为80%的主流正常用户提供好的体验,而不应该为20%的非正常情况花费太多时间和开发成本,你会怎么回复我?
A:常识不需要反复讨论,犬校又不是小白之家。

Q:微博赞赏以前是叫打赏,不少博主对这个词都不爽,觉得创作像是卖艺的。相比之下,赞赏一词接受度更高,能让读者和作者在心态上更加平等。由此可见细节对于用户心理的影响,但如果要把所有的细节都考虑到,这也是不切实际的事,那么请问什么样类型的细节问题,才有必要去改进优化?
A:请问什么样类型的生活作风问题,你才有必要为自己去改进优化?

Q:产品中可以采用的互动方式有很多,例如:送花、点赞、喜欢、转发、评论、关注、收藏、感谢、反对、不感兴趣。该如何根据产品特性选择创作者和浏览者的互动方式呢?可结合一款产品谈谈你的看法。
A:问题本身并不差,但语言风格像是笔试,资深产品经理(也就是最能输出的这批人)没人喜欢回答你的笔试。

Q:发现和订阅两个入口在各大app的排序并不尽相同。微博、知乎更在意用户的订阅和筛选出的信息,而诸如锤子阅读和新闻类app大多是优先发现,其次订阅。背后的选择逻辑是什么?
A:问题不差,但太外行。外行问题提多了,犬校成员也是会不高兴的。

Q:甲方要求我们在数据统计模块(针对广告主可以看到的数据)增加数据(造假)系数,我们该不该增加,为什么?
A:关我…事。

Q:最近一直在思考,一个产品经理如何持续的不断迭代自己,身为产品经理如何构建自己的产品思考体系?
A:我花5秒钟平复了一下情绪。

Q:很多时候产品模型是和业务管理模式密切相关的,当遇到业务管理模式经常变化的情况,这时候你作为产品是如何应对的?
A:跳楼自杀。

Q:设计不仅仅是美观层面,而是通过视觉语言增强易用性。同样功能布局,设计好的那个用户体验更好。产品经理容易从业务逻辑出发,设计师容易从用户体验出发,两者对于产品的角度不一样容易导致分歧。比如为了提升业绩,在订单详情页增加领券弹窗,设计师认为对用户造成干扰。那么产品经理要从哪些方面来平衡业务与体验呢?
A:认真学习八荣八耻。

Q:假设由你负责一个时尚美妆资讯类的app产品,目标用户是17~35岁以内的女性,运营团队只有1个编辑,你该如何设计最小化的产品功能?如何利用有限的人力完成内容建设?
A:暴打老板,用枪指着他的头逼他招人,不招就杀他全家。

Q:如何逆推出一款产品的feed流策略?比如今日头条的feed流规则是如何设计的?如果让你设计你会怎么做?
A:你对分发策略一无所知。

随便挑了15个人的15个问题,都是我看了以后会生气的那种。

知乎在“如何提一个烂问题”这方面,为我国作出了不可磨灭的贡献。同时又因为知乎的体量巨大,即便是一个宏大叙事的烂问题,也有小概率被热心网友举例说明分析——这些答案被推到聚光灯下,让人产生误解,觉得自己随便提一个烂问题,就能获得几千字的菊花宝典。但是,请看我的口型:

宏大叙事是渣渣!
终极发问是渣渣!
没礼貌的面试或笔试提问也是渣渣!

最后再重复一次犬校的规矩:“案例分析,一事一议,用思考交换思考。”浅薄的思考在犬校只会交换无声的嘲笑。

回复(0)

1年前 ask:Android原教旨主义失败了吗? by 纯银V · 黄埔犬校

提问:最近一两年,Android 原教旨主义者越来越少,iOS 底部�导航还是 Android 顶部导航的争论越来越少,这个月经引战贴是否以底部导航的胜利而告终了呢?

cicada:
这事儿要从头说起。

Android 从一开始就打算做大屏,当时 iOS 还没有横滑返回手势,为大屏定制了底部的物理返回键。我猜,为了避免底部的多层操作混乱(事实证明是多虑了),也为了跟 iOS 有所区隔,导航栏被放到了顶部。

顶部和底部的区别在哪里呢?

首先,顶部横滑切换 tab,要求各个 tab 之间是扁平化的关系,类似于从一个内容分类切换到另一个内容分类。如果 tab 不属于同一个维度,不属于“切换分类“的操作,而是“跳转到另一项功能页面“,这时候横滑就是不自然的操作。不自然,滑动切换率就会下降。

比这个更痛苦的是,如果存在两层导航,必然有一层导航得去点击而不是横滑。在 Android 大屏手机上,点击顶部导航必然是低频操作,这意味着放在这一层导航栏的所有功能页面都受到了极大损失。

因此,符合 Android 规范的顶部导航,仅仅适用于功能架构极简,不依赖两层导航的产品,而这样的产品为数极少。到目前为止所有自曝数据的产品,都认为底部导航的转化率更高,坚持 Android 原教旨主义的人,以我所见,以一线的 Android 爱好者居多,比如程序员,他们并不掌握大量的实战数据。

简书的简叔两年前自曝过数据,Android 版从顶部导航切换到底部导航后,次日留存率大涨,说明新用户更愿意探索应用,而不是看完首页就走。这条微博毫不意外地遭到了 Android 原教旨主义者的谩骂,大意是简书做得烂,不要怪规范。然而谩骂解释不了“改版提升次日留存率“的数据。

除此之外,微博的来去之间,糗事百科的王坚都曾经站出来讲过,底部导航的转化率更高。所以顶部导航日趋式微是必然的,制定这项规范的时候,恐怕想象不到未来的产品结构趋于复杂,这也是 iOS 规范更具前瞻性的证明。


daniel:
Android 自己的 APP 都凌乱了,原教旨主义溃败啊。


taitaigao:
1、操作上,单手时底部 tab 挨着大拇指,点哪到哪,快捷方便;顶部导航从首栏到三栏要多划一次,麻烦;点击切换又要大拇指去够,费劲。如果因为去够而摔了手机,估计会恨死。而且顶部导航无论单双手操作,都会挡视线;底部 tab 不会。

2、界面上:顶部导航会两层甚至三层堆在一起,结构不分明,视觉上沉重。

3、习惯上:微信支付宝等主流应用都是底 tab,习惯已养成。 


qiaoxiaodu:
以前认为符合各平台规范的开发可以提高开发效率,但双版本维护不同样式,反而增加难度。两边一样,开发效率更高,维护成本也低,况且转化率也在那摆着呢,我记得微信网易新闻都是尝试过了以后就统一了。

回复(1)

  • 匿名人士 江苏省南通市 (112.2.56.*): 另外,大屏标配与物理按键废除,这两个导致安卓UI必变。   (2018-01-15 19:10:00)

送出评论

共 211 条12345››... 11
数据统计:24 小时内发布128条 ... 一周内发布662条 ... 总发布数 246753
新传学院 订阅/关注/阅文/评论/公号XCST填写您的邮件地址,订阅我们的精彩内容: