• <meter id="ddfke"><delect id="ddfke"></delect></meter><tt id="ddfke"></tt>
    1. <small id="ddfke"></small><var id="ddfke"><ol id="ddfke"></ol></var><code id="ddfke"><delect id="ddfke"><source id="ddfke"></source></delect></code>

        害子弹短信下架的资讯流,怎一个“鸡肋”了得

        2018-10-10 09:18 稿源:航通社  0条评论

        图片版权所属:站长之家

        “本文由航通社(微信ID:lifeissohappy | 微信搜索:航通社 | 微博:@lishuhang)授权发布,未经许可请勿转载或引用。”

        仅仅用“鸡肋”这个词,远远不能形容我对于插进?#19979;?#23376;弹短信 App 里的“资讯流”功能的感受。

        昨天?#24418;?#23376;弹短信的 iOS 版本被苹果 App Store 下架,在一片猜测声中,官方给出的理由是在“资讯流”里的两篇文章引用了版权图片,但是没有处理好版权事宜。目前还不知道这事是视觉中国还是东方 IC 干的。

        现在打开子弹短信,在“资讯流”部分可以看到两大内容?#35789;?#38180;子原本自营的“锤子阅读”和网易新闻,而网易新闻来源的全部文章现在?#23478;?#32463;刷不出,这也侧面佐证了理由不虚。

        因版权下架的理由还算合理

        可能?#34892;?#27809;做过 iOS 开发的人不知道这是个多么大的坑,但是因为开发者没有交图片版权费,而导致 App 被下架的事情是确实发生过的,这个解释是完全的合情合理。

        早前视觉中国曾和经纬创投的张颖之间发生一阵恩怨,此后有媒体也发布批评文章,一度导致在A股上市的视觉中国收到问询函。不过在此之后,一切又转为风平?#21496;玻?#26082;定的商?#30340;?#24335;没有受?#25509;?#21709;。

        我曾经写过一篇相关的文章,说了为什么图片版权对于第三方来说可能是个坑:

        “去年以来,视觉中国已经开始将自己的图片库与百度、腾讯、阿里巴巴、一点资讯/凤?#35828;?#20114;联网?#25945;?#30340;自媒体?#25945;?#25171;通。”

        这种方式让只在一个?#25945;?#20869;部发稿的用户,可以免费选用任何视觉中国的照片,但图片仅限在该?#25945;?#20869;部流通,一旦被转发走,?#22836;?#29983;了侵权?#24418;?#20294;其实这是一个更大的“坑”。

        因为xx号的免费使用往往不能被搬运到其他?#25945;ǎ?#25152;以对“一处水源供全球”的发布者而言,往往是按下发布按钮的那一刻就注定要侵权

        说得极端点,哪怕视觉中国同时授权了百度和腾讯,你在百度后台用了一张图,被?#36828;?#21516;步?#25945;?#35759;的时候,因为授权步骤没有走,?#19981;?#34987;判侵权。

        这种制度的出现,一方面让摄影师得到的利润少于直接向用图者销售单张图片,另一方面也使得用图者由于自身“无心之失”而陷入侵权的可能性指数?#23545;?#21152;。

        不管怎样,挨打了就要站好。既然侵权了,先第一时间停?#32929;?#23244;业务自查,然后该赔偿赔偿,该关停关停,态度好一点,事情终归会解决。

        然而,具体到子弹短信,这一闷棍打下来却显得颇为不值。说起来,为什么主张自己是一个血统?#31354;?#30340; IM 的子弹短信一定要有一个“资讯流”这样的东西存在?如果不做“资讯流”不行吗?不做了会给这个产品的逻辑以及整个公司带来多大的损失?

        资讯流引发了很多问题

        其实在锤子科技论坛中相关子弹短信的板块里,锤友们一直质疑声不绝,都在说为什么子弹短信一定要包含资讯,其实资讯是一个非常没用的设定。具体来说,没用在哪里呢?

        现在子弹短信内的资讯是只能浏览而不能评论的,点击“查看原文?#20445;?#20320;会发现绝大多数资讯原来都是采集自微信公众号的文章。而我们知道,微信公众号的评论区非常丰富和活跃,但是只能在微信客户端里看到。

        所以我如果在子弹短信里看到一篇文章,觉得我有话要说,我的下意识的动作并不是把它分享给子弹好友,而是点击原?#27169;?#23558;文章分享到微信,然后在“文件传输助手”里面点开文章看评论区。

        一方面,这是因为我的子弹好友基本跟我一样都走光了,只是等软件出了事再过来观光。就在官方论坛当中,也有人说现在子弹短信已经变成了“坟场”。另外一方面,因为我不能直接在文章底下评论,所以这个交互是不自然的,就算假设我有很多活跃的子弹好友,但没?#24418;?#31456;评论区,没有“子弹朋友圈?#20445;?#20063;一样很反直觉。

        ——倒不是说所有 IM 都得有个朋友圈,子弹短信把原本应该是朋友圈的位置留给了“收藏流?#20445;?#36825;部分如果能跟朋友互动的话也不错。问题的关键是在这个位置上该有的交互没有,让我不爽。

        资讯流引发的另外一个问题是它太不稳定了,锤子本身没有强内容运营团队,拆出来的快如科技就更是自顾不暇,上架之后几个星期内连续遭遇了合作伙伴的一换再换。最早的两大合作伙伴是今日头条和腾讯新闻,经过腾讯方面公开质疑之后,子弹短信撤下了腾讯新闻,但是今日头条也不见了,不禁让人怀疑它?#23548;?#19978;没真的去跟两家谈过合作,而是拿来主义,先斩后奏的。

        今天我实测发现,现在的资讯流是由锤子自己的“锤子阅读”和网易新闻来提供。选择网易也很顺理成章,因为子弹短信的核心的 IM 引擎就是由网?#33258;?#20449;来提供支持的,所以这下应该是不会有翻脸之虞了。但是?#19968;?#26159;不太懂,为什么需要将两个不同的新闻源?#26049;?#26368;顶端的标签页来切换。这种切换对于最终读者来说毫无意义。

        随着网易新闻源惹到子弹短信 App 下架,这?#33268;?#28902;大于?#20040;?#30340;交易,也不知道还能不能继续下去。

        还剩下一个锤子自己的“锤子阅读”。我在曾经用 T1 的时候就用过,当时它是一个很反映?#19979;?#31934;神洁癖的应用,其中的频道分类,新闻源选择,版权维护都是做得很到位的,但代价就是新闻不多,不及时。要?#30001;?#30495;正够全的网易新闻呢,又出了事。

        如果最后变成锤子阅读长期?#24230;?#23376;弹短信,那么单机版锤子阅读 App 的命运又将如何?它也没多少人用,那要不要合并了呢?

        用更大的问题来掩盖原来的小问题

        就像这样,在子弹短信的开发过程当中,逐渐的浮现出一个又一个的逻辑矛盾。然而开发团队采取的措施,?#35789;?#29992;新的、更大的问题,来掩盖或者是弥补原来的问题。例如爱范儿做过一个采访,现在再回头看会让?#21496;?#24471;匪夷所思。

        我的同事对于「语音能够显著提升效率」这点产生了强烈质疑,认为文字是深?#38469;?#34385;之后的表达,而语音则会充斥了大量停顿和杂讯的无用信息。

        关于这点,郝浠杰(快如科技联合?#35789;?#20154;)是这样回应的:

        “对,语音可能并不是特别多思考之后的东西,所以我们之后会做一个类似「断点续传」的功能,如果你觉得没想?#23186;?#19979;来的话怎么说,没关系,只要想好之后再继续说就可以了。”

        的确,我个人使用语音的经验,确实是说一段话之后要停顿一会儿。但是我这么做是在我写文章的时候,需要长篇大论的时候。这又和子弹短信一开始自称的那种用于群发、快速的决断,像对?#19981;?#19968;样说话的环境不相符。

        而且这种基于语音的能力显然是经过训练才能得来的。大多数人都习惯了只有在打字的时候,才能够整理自己的思维,那么语音对他们就是不合适的。

        如果这个功能不合我的胃口,反正子弹短信也有键盘,我不用语音就得了。但是上面这位产品?#35789;?#20154;在回答问题的时候,所表现出来的产品设计思路却足以让?#21496;?#24789;:如果我们发现某个功能?#24418;?#39064;,就开发一个新的功能来解决这个问题。

        这是万万要不得的。甚至这就像是当你要?#19981;?#30340;时候,需要用一个更大的谎言,?#38180;?#30422;现有的谎言。如果你发现现有的功能,乃至产品逻辑出了问题,先停下手头的工作,站在当下的基础上来解决这个问题,或者给出更好的方案才是正经的,而不是急于反驳。

        不过,从子弹短信“快如子弹”的融资进度,媒体曝光,下载量像过山车一样高开低走的诸多情况看来,开发团队现在没有时间,也没有耐心去仔细的构想产品逻辑到?#23376;?#27809;?#24418;?#39064;。

        所以,就算有很多粉丝?#23478;?#32463;提出了“资讯流”是一个完全不知所谓的功能,建议把它去掉,或者至少做更多的调整和打磨,子弹短信团队也只是耐心的在官方微博以及论坛帖子下面回复说:

        “感谢您的建议,?#19968;?#21453;馈到产品部门,他们会综合考虑,再次感谢您对我们的帮助与支持。”

        然后就没有然后了。

        立一块牌子,说这里是用来赚钱的

        很多针对子弹短信的产品分析已经注意到了资讯流这部分,它显得十分?#22238;#?#20294;既然在刚开始很吸引眼球的阶段它还是一个很正面的案例,那自然也少不了很尬的那种分析,说为什么要有这样的设计。

        其实我觉得目的已经很显然了,这部分资讯功能就是为了给自?#33322;?#21518;的生存?#19994;?#19968;个盈利方向。我们当然也能理解这种努力,如果信息流真的成为大家使用子弹短信的一个理由,并且能够增加用户粘性,那么它确?#30340;?#22815;为企业带来一定的自我造血的能力。

        但是在子弹短信这款产品当中,至少是截至目前来看,信息流在里面所?#24230;?#30340;状态实在是太生硬了,就像是插了一个网页框架(iframe)一样不自然,跟其它功能之间的结合几乎是零。这就好像是立着一块牌子,说这个位置就是我用来赚钱的地方。这样大?#19968;?#20250;过去用吗?

        航通社曾经在滴滴?#25764;?#36710;出事的时候,问过为什么做专车的、做天气的、航旅纵横、支付宝都曾经动过社交的心思。当时的答案是:

        单纯做工具是?#20154;潰?#27963;跃度换不来钱,迟早会以烧光钱作为结局。做社交相当于“?#23452;馈保?#20165;仅“初衷是好的?#20445;?#21364;给自己平白添了一大堆麻?#22330;?/p>

        那该怎么办呢?

        我们要牢记工具做社交的本意是为了保?#21482;?#36291;,增加留存和停留在应用内部的时间,带?#38180;?#22810;的盈利机会。如果有其他替代手段可?#28304;?#21040;相近的效果,那自然可以避免跳入社交的火坑。

        这么看的话,如果说子弹短信做“资讯流”是为了增加主要的社交业务的粘性,整件事情将变得极为搞笑。在别人都觉得做社交能让自己起死回生的时候,你本身就是一个做社交的,你连一个聊天的功能都做不起来,你还能指望通过别的什么更?#34892;?#30340;方式拉新促活?

        目前“资讯流”这样的设置,只能是暴露出子弹短信团队对自身产品未来如何维持生存这件事,可?#36816;?#26159;完全没有想法,先做了再说。

        我非常欣赏子弹短信带来的一些“微创新?#20445;?#20043;前也曾经写文章总结过。在大原则上,它将每一项权限开关都交给用户,在国产安卓的大环境中殊为不易;在外链分享过程中也不会人为添加各种阻碍,同时能保存加群之前曾经的?#27627;?#35760;录。后来也有人提醒我,它的“扫一扫”界面直接把自己的二维码放进来,解决了“我扫你?#34987;?#26159;“你扫我”这一世纪难题。

        你看,这些改进?#22270;?#25345;,都很锤子。怎么?#30340;兀?#23601;像是在大军压阵之下,仍然能有上城楼顶端,挥挥羽扇又抚琴的心思。

        但是,现在差不多所有人都知道子弹短信的背后是一座“空城”了,那么这“空城计”到底还使不使得出来?

        如果按照?#19979;?#23545;团队的要求,都能给 OpenSSL 捐款了,那版权问题大概是不会出现在一个打磨好的产品上的。但现在问题有了,只能?#24471;?#20182;们已经顾头顾不了尾,快要坚持不住原本那么优雅的节奏了。

        这可真不是什么好兆头。

        有好的文章希望站长之家帮助分享推广,猛戳这里我要投稿

        相关文章

        相关热点

        查看更多
        ?
        双色球复式价格表图
      1. <meter id="ddfke"><delect id="ddfke"></delect></meter><tt id="ddfke"></tt>
        1. <small id="ddfke"></small><var id="ddfke"><ol id="ddfke"></ol></var><code id="ddfke"><delect id="ddfke"><source id="ddfke"></source></delect></code>

          1. <meter id="ddfke"><delect id="ddfke"></delect></meter><tt id="ddfke"></tt>
            1. <small id="ddfke"></small><var id="ddfke"><ol id="ddfke"></ol></var><code id="ddfke"><delect id="ddfke"><source id="ddfke"></source></delect></code>