『吃』出来的一些想法(二)

【2015-10-26更新】今天在下厨房传菜品被弹窗了,顺便更新了下,试用简要记录:
1)首页,以四个图标的形式重构,为『排行榜、看视频、买买买、菜谱分类』,之前首页直接展示的榜单等挪入『排行榜』,多出来的空间新增按天更新内容模块,直接以大图feed的形式展示某些优质的菜谱和单品,引入『公众号』发布的优质内容,如『中古厨房』等,感觉略凌乱,但有助于优质内容的直达-利于新用户or没啥动态可关注的用户阅读,
2)发布作品时可以点击图片关联商品,以tag的形式直接在作品上展示,之前国外一款卖家居的app上见过类似交互,挺优美的,但实际效果未知,找了几个达人发布的可能用到市集商品的作品貌似都没看到;
3)某些菜谱页出现了『一键购齐所有材料』,实际体验后并无太多惊喜,还得每样食材分别进入不同或相同的店铺添加、购买,低于预期。脑补了俩改进办法a)商品备选list页每个商品均提供评分、加购物车的按钮;b)商家认领某些明星菜谱直接定制半成品包-性价比,不浪费,降低用户尝试成本,加速其冲动消费;

其他app,味库加大了半成品菜的力度,引进了品牌餐厅的半成品包,如俏江南等(有意思,我脑子里一堆问题:某餐馆招牌菜我真的需要在家自己做吗?半成品菜包真的是餐馆加工的吗?是餐馆自己备菜的时候顺便打个包?待po主试用琢磨下)

【2015-08-20更新】正文分割线————-

昨天YY了下自己理想中的『吃』App,今天挑几个主要场景聊聊最近常用的几款,包括但不限于如下Apps:下厨房、豆果美食、美食天下、味库、美食杰,Kitchen Stories跟Yummly是国外的Apps,虽使用率虽不高,但偶尔会上去取取经(比如牛油果的切法,如何煮水波蛋神马的),菜谱页的设计和交互还是可圈可点的。

场景1:找菜谱/找灵感
这里不多说用户已知菜名or原材料,通过各类搜索抵达最终菜谱页这类主动行为(新用户触达跟关键路径处理可以单开一篇来说),主要说下在面对用户每天都要面临的世界性难题『早/中/午饭吃神魔』时,各家的做法。
下厨房,主要集编辑和用户之力,主要途径是首页的『本周最受欢迎』(推测算法主要基于菜谱的收藏数、做过数、评分以及编辑人工),流行菜单(编辑人工挑选的用户发布的菜单,内含各种场景,应季的,基于某食材,某厨具,等等),以及榜单(编辑选新、Top榜单),运营的各散播途径(微博、公众号、邮件等)内容质量上乘(图文情怀故事较多),印象中经常被下厨房发布的内容馋到然后被召回。唯一的缺点是首页似乎过于安静,所有内容均需点击之后才能进入列表进行查看,新用户进入之后可能由于无法迅速感知到整体的氛围而流失。
豆果美食,相比之下,豆果的首页排版有较大缺陷,占据第一屏大半个屏幕的轮播图,只推荐6个菜谱(互动的数据比如评论、大家上传数量级一般为10),推荐固定数量极少的菜谱将面临主要两个风险:1)众口难调;2)从推荐出来到用户做,再到上传,耗时较长,没准菜谱已不在首页,传上来的菜谱缺乏展现->缺乏用户间的互动(主要是称赞和评论),打击用户积极性。首页剩余部分,『每日佳作』(时间跨度太短,导致实际数据看上去颇为冷清)、『精选菜单』(数据冷清,做过数为个位,体现不出精选)、『时令精选』(仅以文字tab形式展现,但是点开之后是个菜谱list,分为综合最佳/收藏最多/做过最多三类,目测结果都非常靠谱,可惜了被放在这么各犄角旮旯),其他散播途径内容一般,未有被触动过。
美食天下,最早还在pc时代就已经开始,那时最深的印象是:菜谱复杂,照方子做出来跟方子完全不是一回事儿(那时候我还以为菜谱就是仅供参考的存在),后来有了手机版,最初的版本很简陋,直到4.0才开始重新关注。菜谱依旧是复杂的,App版面也比较繁杂,首页推荐的几个分类倒是比较实用(包括新菜谱、妈妈派、烘焙等,top菜谱用户互动的数据不错),一日三餐的菜谱推荐UI倒是别具一格,但是数据较惨(原因同豆果美食的轮播图推荐)。单独出菜谱tab页,除了空间开阔可以铺开了展示以外无甚亮点;魔方tab摇一摇随机出几个菜单,不知数据如何。
味库,最初打法是用户添加食材、厨具等,智能推荐菜谱,经验证不那么靠谱之后,首页的重点已经切换为半成品菜售卖,精品菜谱内容的图文混排结构看起来不呆板,层次分明,比较舒服,可惜点开后数据较惨淡(相同位置不同菜谱数据相差较大,可见运营和内容编辑有多重要,具体数据对比『缤纷水果树』和『炒方便面』)。
美食杰,首页按早中下午晚夜宵每类推荐3个菜谱,数量分类略多,但依旧逃不开『众口难调』,下拉之后展现了几个精选分类(固定展现),『食话』是运营主导的一些活动feed流,未知其展现规律,但实际数据表明效果不甚理想,最底部是『猜你喜欢』,推荐了大概几十个菜谱,也许是因为上传的菜谱太少,推荐的菜谱少有喜欢的呢(如何给新用户做内容推荐?这也是个挠头难题,第三方帐号登录的或许能觅得少许用户兴趣,用户浏览、点击、搜索关键字等均可入料,完全崭新的用户就全靠运营和产品具体如何考量了);另外有个『发现』tab页,展现了菜谱分类、菜单、排行、食材、附近等入口,以及『大家做什么ing』feed流(feed流坑实在太多,单是如何产生feed的规则、合理聚合多条feed避免刷屏的学问又可以写篇论文了)

场景2:做菜
对于像我老妈这样的资深厨神(跑外面饭馆吃个好吃的就能在家依照味觉+灵感来个复刻版),菜谱类的应用顶多用来找找灵感、拓宽思路,而像我这种半生不熟的小厨,一边做菜一边看菜谱是经常的事儿(所以有次清洁手机在耳机孔里掏出芝麻粒儿的事我会乱说嘛:p)。
在这个环节,各家的易用层次不等:
味库:无步骤大图可看(心思基本都放在半成品菜了无暇顾及);
美食天下、豆果美食:点击步骤查看大图;
下厨房:点击或者横着手机,查看大图;
美食杰:点击查看大图,支持语音操作(上一步、播放语音、下一步等简单命令);
从操作体验讲,美食杰做了新的尝试,但iOS版似乎不太灵光,没动静或者上一步下一步分不清时有发生,安卓版顺畅度和语音的自然度还算ok(最后一步有个必现的语音失效的bug),尤其在做不熟悉的烘焙时好用(菜谱简洁时体验更好),请脑补下满手面粉还要滑动手机屏幕查看菜谱的囧样;
从最终做出的成品与菜谱的差距、心理预期的差距来看,下厨房无疑胜出;不过,po主一直被『手机搁哪儿』这个小问题困扰,这事儿属于『只有当手机被菜汤泼到』才会想起寻求优化的需求,也许看到某个图文并茂的介绍帖一冲动就买了,但可惜还没有哪家App推过相关产品。

场景3:发菜谱/作品,互动氛围
发布菜谱这个功能使用频次虽低,但易用性以及发布出的菜谱可用性还是非常关键的(想想好不容易有个用户被其他用户一邀请,想要发布下某个菜谱,结果七搞八搞被难用的发布流程逼疯…)。易用性方面,『所见即所得』非常重要,这点做得最好的是下厨房,发布界面跟菜谱页基本长一样,图片、步骤的添加提示直观明了,简单菜谱的话,5分钟发布完全不是问题。其他家有各种难用的问题,其中较为集中的是非必需字段的添加(比如烹饪难度、时间、所用厨具等,讲真,按某些App提供的难度跟时间真心不咋靠谱,按某些不提供的App做出来的菜也没有差到哪里去,所用厨具各家也有各家做法)、食材用量的单位选择(同理,量词的添加真的有助于提升菜谱可用性吗?是否成为了顺利发布菜谱的绊脚石?),PM需要认清自家目标后审慎添加,尽量做到最简最流畅。

发布作品,最关键是发布之后的展现,这决定了用户后续的活跃度。从入口位置、集中度等来细分,各家做法不一,从实际的体验来讲,仍是下厨房最优。入口位置,最自然是在菜谱单页处提供明显的晒作品入口,但此法属于厚积薄发,展现量取决于该菜谱的曝光量,上传作品可能很长时间都没人点赞,互动的时效性和用户积极性都大打折扣;简单粗暴的做法是直接来个tab展现『全站最新上传作品』,但此法需慎用,最好配合一定的人工筛选,避免渣作品拉低产品整体品质。其他入口,主要遵照用户本身的习惯及网站的需求产生,可以看到,下厨房常驻首页首屏有『本周流行菜单』、『每日三餐』,这两个入口实际使用下来效果惊人,颜值略高些的作品在正常时段发布常常几分钟内就会收获很多赞(多次手动验证过绝大部分都是真实用户),其他App以豆果为例,有类似做法,但实际作品数(相对各自用户量来说)和互动氛围远不如下厨房,主要原因1)入口不明显,豆果需要在首页滚动屏幕才会看到当天某一餐的入口,2)上传后,可参加的话题数量过多(至少十几个)导致流量分散,3)单个菜谱停驻首页寿命过短,这在场景1里说过了,最明显的位置只显示有限几个菜谱是不明智的,且不说这几个菜谱的选择是否到位正中用户下怀,显示时间的长短也不好拿捏,过长,虽然能提升上传量、互动时效性但会让人觉得单调,过短,就是现在这个样子,像下厨房这样以周为单位,定期用算法、人工等策略更换优质的菜谱,是比较可行的办法。

场景4:买食材/厨具及周边
各家电商均有尝试,但最终固定在下厨房(挖掘新东西最多)和豆果美食(购买最多,价格略低以及提供半成品菜)。
从实际的购买来说,于我个人而言,体验提升较多的是半成品菜(较为突出的是青年菜君和暖食),其次是某些食材和厨具的晒单比淘宝or其他电商平台详细(这块儿下厨房做的比较突出,得益于其运营模式『爱尝鲜』:用户购买后对商品进行评价可以获得价格同等数量的积分,每800积分可获得『爱尝鲜』价格,以非常实惠的价格购买市集将上架的新品)。在新食材/吃食/厨具的发掘方面,下厨房除去使用常规手段(消息/EDM推送、首页banner展示等),菜谱的渗透做了一些尝试(比如上传作品时可以点击图片添加关联的商品、菜谱单页提供一键购买但体验未达到理想),其他app,比如豆果、美食杰会在菜谱下方推荐相关的食材或厨具(这个效果很一般基本无购买欲望)。

其他场景先不一一详述了,后面有想起来值得细写的再单写,关于『吃』的互联网产品,甭管表面的运营、产品手段如何变化,或是对已有资源重新优化和配置(比如餐桌分享or众筹厨具or农产品树上预订等),最终能让吃货们便捷、便宜地吃上更好的,吃出更多趣味,涨了各种吃的姿势的,才会是最终的胜出者吧。

『吃』出来的一些想法(一)

作为一枚吃货,不知不觉浸泡在吃相关的App、剧或纪录片、书籍等各种吃相关产品中也很长一段时间了(比如坚持在家做早饭吃都快3年),最近这两三年间,『吃』方面互联网产品变化较大,准备写个『吃』系列从自己熟悉常用的好好梳理下,今天这篇是关于『吃』产品的分类和概况,以及自己期望的『吃』产品。

『吃』产品的分类和概况

『出去吃』和『其他』,前者太老,后者太新,暂时没有太多感(tu)想(cao)。

『在家吃』的『外卖』和『请人上门做』,较典型O2O产品,尚处在烧钱跑马圈地阶段,所以多次体验下来,很方便,性价比很高(饿了么的100元年卡,爱大厨的69元上门包工包料烧菜套餐,连我老妈都觉得这是要亏死的节奏),但不知道钱烧完之后会是怎样,暂且关注之,体验之,后续有想法和体验再整理。

『自己做』算是长期使用和关注的领域,从最初使用浏览器收藏食谱页面、关注美食博客,到现在各类吃相关的Apps、厨具、食材包,感叹吃的多样性和便利性大大改进的同时,也会思考怎样的一个关于『吃』的平台会吸引并留住我呢?

我想,首先,1)这个平台必须有海量、可行度高(以按照菜谱做出来不难吃甚至很好吃为标准)的菜谱,当然,是以有趣的方式来展现。何为『有趣的展现』?也许可以根据『吃』的人数(一人食/两人餐/小家庭/大爬梯…)、人物关系(情侣/母子/父女…)、季节/节气/节日(这个就不用说了,各地的时令菜真是三天三夜都说不完…)、地域特色(武汉热干面/陕西肉夹馍/重庆小面/柳州螺丝粉/日式味增汤/欧软面包/美式烤猪排…中外均可包含)、影视剧特色(孤独美食家/深夜食堂/舌尖上的中国/海鸥食堂/中华小当家…)、顶级食材(神户牛/澳洲和牛/松茸/玉兰片)等等主题来划分,根据『天时地利』适时展现,引导用户的同时还能适度的『超乎用户的想象』,这依赖于好的内容运营(包括平台方的内容选择与引导,也包括平台本身的氛围使得用户乐意UGC出来一些有趣的内容)。

2)良好的互动氛围,具体是指厨友间的互动,包括对彼此作品的点赞、提问及解答,如果能有美食达人亲自参与更好。有很多人说起自己为什么会开始做饭的理由是『爱上一个人』,也有人是因为『有了孩子』,『出国了』,这些固然是做饭的主要动力,但是来自『同行』的赞美、鼓励和讨论,同样也是非常重要的推动力和粘合剂,甚至可以从讨论中得到一些非常实用的生活tips(比如我在逛豆果时就知道了还有一种油叫『稻米油』,在下厨房知道了离我家不远有家不错的烘焙材料店铺,以及非常多简单快手美味的好菜谱),有了这些,想让人离开这个平台都难啊。

3)能方便、实惠的购买到某个(类)菜所需的全部厨具和食材,简言之,即能将看菜谱时的冲动–>吃到嘴之间的门槛降到最低,帮用户迅速获得满足感(吃到时的美味)和成就感(家人的满足、厨友们的赞)。 最常见的场景是菜谱下方推荐相关产品,可以是主料、配料,或者半成品包更好;还有个场景是各类节日的特卖,比方这阵子各Apps七夕都会推特辑,一般把牛排、起泡酒、甜点等单款商品弄个活动页面就算完事儿;做得好的会做出一个故事,故事里配上让人垂涎的美食图片,图片下边把食材包配好(包括牛排、意面、时蔬、黑椒汁),所用到的煎锅,盘碟刀叉餐垫,起泡酒+酒杯,甚至烛台和蜡烛,如果你愿意,可以一键下单,分分钟送货到家,美梦成真。又及,很多西餐看起来诱人,无奈调料list一长列就让人生畏,迟迟不敢动手(比如我看中某个肉桂牛角包的方子一段时间了,但是肉桂粉大部分都是大包出售我一直在犹豫万一面包做失败了我真要拿剩下的肉桂粉冲水喝嘛),如果平台能够整合一套完整的方案,除了将图片上的西餐打包成一个食材包,甚至能清楚的指导我哪些调料作为中国人也许吃不惯,可以改良,哪些调料是『长青款』可以长期备着,哪些品牌的哪些厨具(比如肉锤、条纹煎锅)是秘诀值得入手,哪些盘碟是经典款,相应的购买链接都准备好,如果真的有平台存这样做,估计千手观音也是不够剁的;p

其他方面,虽没那么重要,但也都是加分项了:比如厨艺各类基本功、Tips可按中西餐体系分块儿,从食材挑选、厨具挑选、各类常见食材的刀功、炒法、如何摆盘、拍照技巧等,个人感觉视频会比图文版的更形象(我一直学不会的切圆白菜丝、牛油果切片等总算在youtube、Kitchen Story上看视频学会了),由美食达人或者专业的厨师进行演示;更进阶、系统的学习,可以合作一些靠谱的长短期线下厨艺班;相关的出版物(类似食帖出的特辑)、视频/纪录片、线下活动(美食节、集市等)也可以配套整起;美食的发掘(半成品或饭馆拼饭都ok),私厨上门或者上私厨的店里吃,这些活动没准可以基于某个菜谱或菜单进行(比如『请你吃全北京最好吃的宫爆鸡丁』或者『这些菜都是我最爱』),我都会非常乐意参与。

以上,全部揉进一个Apps如何?乍一看或许会有点儿多,其实只有1-3,及厨艺各类基本功教学,是需要固定在Apps里的,其他内容可以以活动、商品等形式揉进来,考验的是运营策划和整合的功力,非资深吃货美食家产品运营汪不可驾驭啊~

【转】产品经理从零到一技术进阶:不懂代码也能愉快地与开发相处

在36氪看到的文章,挺实用的,值得反复看及有时间时深入学习、拓展,so搬运过来,附原文链接

产品汪在力所能及的范围内懂点技术,具备一些与RD相同的知识背景,是完成有效/良好沟通的基础(当然不是让你拿着半桶水去RD面前指手画脚哈),也是对产品整体效果负责任的一种体现。

———–以下是原文————

36氪微信号:wow36kr

这是 NEXT 「产品经理从零到一技术进阶:不懂代码也能愉快地与开发相处」线下活动的笔记。主讲者张元一,产品原型工具墨刀的创始人,见证了 Web 开发从 99 年 HTML4.0 到去年 12 月 HTML5 最终定稿这之间整个 Web 开发变迁史的 15 年「码龄」全栈工程师。

NEXT 本次活动收到了近 1000 多个报名,大家对周日线上和线下的互动学习反馈也不错。因此我们将笔记分享出来,希望让更多产品人、创业者够快速了解基本技术知识,更好地把握产品周期与项目进度。当然,你也可以观看网聚直播提供的视频回放:http://wangju.tv/live/3k562amaskvzg 。

概览

以下这张图就是元一分享的干货内容,它基本涵盖了一个初级码农需要知道的所有基础入门知识。但这张图的目的并非用来吓人,这其中的所有技术名词,将以最通俗易懂的方式串联起来—— 即我们上网时的慢动作解析:打开一个网页或 App,这背后都运用了那些技术来让这个网页和 App 的内容呈现在浏览器和手机上;驱动这些动作背后的技术名词都是什么,各自有着怎样的优缺点,彼此间是如何协作和运转的,以及怎样合理地评估技术能力和开发难度。当然,元一也推荐了丰富的学习资料。

这中间涉及的技术知识,前端包括 HTML,CSS,JavaScript,jQuery 以及 Bootstrap ;后端包括 HTTP 服务器,后端编程语言,数据库以及 Cookie 和 Session;移动开发分为原生,混合式,HTML5,以及不同的移动端技术选择在功能和开发成本上的比较。

什么是前端?什么是后端?二者是如何配合运转的?

前后端的划分,可以简单地理解为凡是运行在用户设备上的技术都可以称为前端技术( 比如 HTML / CSS / JS,甚至移动设备的 Obj-C / Swift );而后端的作用就是负责将这些东西封装在 HTTP 的数据包中然后通过网络传送到前端。当然除了这些前端文件,后端还有一个更重要的职能,即保存和提供用户数据,比如移动端常见的 JSON 就是目前最流行的在后端和前端之间传输的一个文件格式。

前端与后端是如何配合的?如上图,以 Web 端为例,在浏览器输入一个网址后,浏览器向服务器发送了一个 HTTP 请求;服务器通过一个 HTTP 响应,把显示这个网页所需要的资源传回给了浏览器。而需要在浏览器中执行的技术,HTML / CSS / Javascript 等就叫做前端;需要在服务器端执行的、通常我们看不到技术就叫做后端。

Web 前端的运行逻辑

假设我们要访问 Google,从我们在浏览器输入 Google.com 到最后这个页面出现在眼前,这其中涉及许多前端的技术反应和代码组合,总体而言可以简化为两步:

1/ 浏览器向 Google 的服务器发送了一个请求。

2/ 服务器收到了一个 HTTP 响应,这个响应中就包含了执行这个命令所需要的所有资源(注:可以通过 Chrome 浏览器的开发者工具来进一步观察 HTTP 协议的运行情况;下图为 Google 的 HTTP 协议运行情况)。

上图这个界面看起来很复杂,但对于非程序员而言,HTTP 协议运行情况只要关注其中的几个关键部分:第一列,即资源的 URL;第四列是这个资源的类型。在第一个请求和后续的请求之间有一根蓝线,即进度条。而 HTTP 协议中运行的项目越少,浏览器加载的速度越快。图中 Google 就处理得很好,只有 10 个左右的请求。

Web 前端技术语言介绍

  • HTML 和带样式的 HTML

HTML 就是一组标签和文本的组合,是一个最基本的网页。它已经包含了网页常见的元素,实际上在 Web 早期的很长一段时期内,网页都是这个样子。后来随着使用网络的人群越来越广泛,在 HTML3.0 中引入了对网页样式的定义,某种程度上可以说,也是从这个时候开始产生了网页设计师的角色。

  • CSS

带样式的 HTML 也拥有一个缺点,它需要为每个标题和文字都设定样式,工作量非常庞大。 CSS 就是在这样的情况下诞生了。CSS ,又称叠层样式表,简言之是一种用来表现 HTML 文件样式的样式设计语言。CSS 能够对网页中的对象的位置排版进行像素级的精确控制,实现基础的静态的交互设计;而CSS 目前的最新版本 CSS3 能够真正做到网页表现与内容分离。

  • Javascript

差不多在 CSS 诞生的同一时间,大家开始觉得这样静态的网页似乎略显无聊,能不能给网页加入一些可以动起来的元素?比如点击一个按钮之后变个颜色。当时网景公司的工程师Brendan Eich 就给他们自家的浏览器引入了这种实现动态效果的脚本语言,这就是 Javascript(简称 JS)的诞生。所以通俗来说,Javascript 就是用来给 HTML 网页增加动态功能,实现更炫酷的交互。

提到 Javascript ,就得提一下 jQuery 。 jQuery 是一个优秀的 Javascript 库。jQuery 使用户能更方便地处理 HTML ,它能够使用户的 HTML 页面保持代码和 HTML 内容分离,通过 jQuery ,可以不用在 HTML 里面插入一堆 JS 来调用命令,只需要定义 ID 即可。此外,由 Twitter 设计师 Mark Otto 和 Jacob Thornton 合作开发的 Bootstrap 也是一个受欢迎的前端框架。

HTML5 简史和响应式设计

HTML 在刚诞生的前 10 年发展是非常迅速的,在 1999 年,我们现在常说的 HTML5 的上一个版本 HTML4.0.1 就已经发布了,那么为什么从 4.0 到 5.0 会拖了 15 年之久?

首先,HTML4 的发布时间和门户时代(即 Web 1.0 时代)是基本吻合的,也就是说 HTML4 实际上是为门户型网站设计的。在门户网站经历的 4,5 的年发展之后,大家开始觉得只是单一接受信息的互联网太过无聊枯燥了,差不多 2004、2005 年开始,大家希望在网页中加入更多的互动元素,也就是我们常说的 Web 2.0。

但是这个时候大家就发现,为 Web 1.0 设计的 HTML4 无法胜任这个工作,但是有另外一个技术却非常适合,那就是 Flash。所以在 Web 2.0 的早期,当时最炫酷的网站有很多是完全用 Flash 开发的,在以后的很长一段时间里,有很多网站都是 HTML 和 Flash 的混合式网站。所以在 2005 – 2010 年这段时间,HTML5 中的新标准主要是为了取代 Flash。

刚刚搞定了 Flash,又进入了移动开发时代,所以 HTML5 又花了 5 年时间制定各种针对移动平台的标准。但是到目前为止,虽然 HTML5 已定定稿,但是对移动平台的适应其实还在进行中,所以在未来很长一段时间内,就像当初的 Flash 一样,我们会看到越来越多的混合式应用。

在 iPhone 出现之前,大家访问 Web 的主要方式还是通过桌面浏览器,所以设计网页时只要考虑桌面浏览器的显示效果就足够了。但是在 iPhone 和 iPad 出现之后,就需要考虑同一个网页在不同设备上的显示效果,第一个问题的答案就是响应式,响应式的核心就是让同一个网页可以在不同设备上呈现出不同的显示效果,主要是通过CSS来实现的。

除了响应式设计,HTML 在移动端遇到的另外两个问题就是如何利用移动设备的各种传感器,比如 GPS,摄像头等等;以及性能问题。为了解决这些问题,HTML5中添加了地理位置,拍照,3D 动画加速等等 API,可以部分的利用手机设备的一些新硬件,并且新的 API 还在不断的加入进来,这也是为什么现在的 HTML5 应用可以越来越炫酷的原因。但是,HTML5 并不是专为移动设备设计的,它是由 HTML5,CSS3 以及大量的 Javascript API 共同组成的一个标准合集,微信中的 HTML5 应用只是 HTML5 应用场景中的很小一部分。

如何判断一个前端的能力?

关于前端,可以简单的把它理解为,凡是在我们的电脑,手机上运行的技术,HTML,CSS,Javascript,这些都属于前端技术,使用这些技术的我们就称为前端工程师。如何判断一个前端的能力呢?下面是一个简单的前端能力链:

1/ 只会 HTML/CSS 的,这种我们俗称切图的,基本上就是淘宝几十块切一张图的;

2/ 懂一些简单的 Javascript,主要是使用一些现成的框架,比如 jQuery,bootstrap 等等;

3/ 知道 jQuery 和 Bootstrap 的局限,必要时能写一些原生的 JS/CSS 代码;

4/ 对JS/CSS非常了解,执着于使用浏览器的各种最新特性来实现各种炫酷效果,这种我们成为炫技派;

5/ 可以自己写出类似 jQuery / Bootstrap 这样的前端框架供其他人使用。

前端学习资料

http://www.w3schools.com

http://onemonth.com

http://www.codecademy.com/

https://github.com/alex/what-happens-when

https://qdan.me/list/VNBugw7ObupFRdlE

大家可能比较关心如果我要开发一个网站需要多少时间?这个问题虽然很难回答,元一还是来试着回答了。现在前端有了 jQuery,bootstrap 这样的框架,后端又有了 Ruby on Rails 这样的快速 Web 开发框架,如果从头学的话,像是一个简易的 Pinterest,大概一个月就可以了。如果是一个有经验的程序员,可能 1 个星期就可以开发出一个大概的原型出来。

后端服务器

后端的任务实际上就是向前端提供需要显示网页和 APP 内容的数据,可能是 HTML,也可能是JSON 数据,也可以是音视频或者 PDF 文件。简单的来划分,一个服务器包含3个部分:

1/ HTTP 服务器

2/ 应用服务器

3/ 数据库

HTTP 服务器的唯一任务就是把需要返回给客户端的资源文件封装在 HTTP 数据包里,这个资源有可能是它后面的应用服务器动态生成的,也有可能是保存在硬盘上的静态文件。这是所有后端程序都必须有的,也是直接和我们的浏览器通信,返回给我们数据的程序。它的作用就是把它后面的编程语言生成的各种 HTML/CSS/Javascript,打包成一个 HTTP 请求,然后再封装到一个 TCP/IP 的数据包里发回给我们。而最常用的两个 HTTP 服务器叫做 Apach 和 Nginx。

应用服务器就是通常意义上所说的码农负责的部分。他们的职责就是生成前端需要的HTML/CSS/JS 交给浏览器。

后端语言

1/ .net/java

庞大,复杂。但 Java 的优点就是适合处理特别大的数据量,如果你的项目会很快实现大爆发,需要处理海量的请求,那么 Java 是一个不错的选择。

2/ PHP

可以快速上手,相比其他语言,可以更快的为应用添加各种新功能。当然,可维护性就另当别论了。

3/ Ruby

非常接近自然语言,基本上即使不懂编程,也能看明白 70% 或 80%。04 年出现了一个用 Ruby 编写的 Web 开发框架 Ruby on Rails,当时的效果是非常震撼的,以前需要一个团队才能搞定的事情,使用 Ruby on Rails 后 1 个人就可以胜任了,所以 Ruby on Rails 在极短的时间内就成为了 Ruby 的代名词,也成为了新手学习 Web 开发的不二选择,但是 Ruby 语言也并非十全十美,快的同时,他的最大短板就是性能。Twitter 最早就是使用 Ruby on Rails 开发的,但是随着用户数的逐步增长,Twitter 的宕机开始变得非常频繁,后来他们迫不得已将整个系统从 Ruby 迁移到到了一个从 Java 派生出来的语言 Scala。

4/ node.js

简单来说,可以把 node.js 理解为跑在服务器上的 javascript,再直白一点,就是一个跑在服务器上的浏览器,因为 node.js 最早就是从 chrome 浏览器的Javascript 引擎 V8 中剥离出来的。相比 Ruby,Node.js 程序可以获得更高的并发性能,这在一些高并发的场景下(比如群聊,多人协作等)会很有优势。

5/ 其它(python,closure 等)

6/ 无后端(leancloud)

无后端编程是最近的一个新趋势,但她并非说是真的没有后端,而只是把后端交给一些第三方的云平台,比如 Leancloud,Firebase 等。如果你开发一个手机 App,这样的好处就是你可以在早期没有后端程序员的情况下快速开工,像Leancloud 这样的云平台已经可以胜任大部分的应用场景,如果后期业务逻辑复杂之后再寻找合适的后端工程师迁移也不迟。

7/ 最强编程语言 Lisp

如果要评选一个最强的编程语言,该是哪个呢?答案就是Lisp。为什么是 Lisp?Lisp 的作者在很早以前就从数学的层面总结了一个完美的编程语言应该具备的 9 种能力,而 Lisp 就是为了配合他的这个理论而产生出来的语言。Hacker News 是由 YC 的创始人 Paul Graham 开发的,而 Paul Graham 本身就是一个 Lisp 程序员,他为了开发 Hacker News,专门发明了一种新语言叫做 Arc,但因为它是基于 Lisp 的,所以也被归为了 Lisp 的方言之一。

数据库

我们平常访问的大部分网站都是需要登录操作的,登录之后我们看到的就是只和自己相关的那部分内容。这些用户信息是保存在什么地方的呢?这就需要用到数据库。关于数据库,代表性的有两个:

1/ MySQL

2/ MongoDB

MySQL 是最常用的结构化数据库,也是大多数创业公司的选择。为什么是结构化的?就是说它的表的结构是固定的,比如我们常见的 User 表在 MySQL 中就是这样的:

如果我们需要取得一条用户记录来检查他输入的密码是否正确,这时我们就需要使用 SQL,SQL 就是结构化查询语言。

简单来说,SQL 数据库保存的是结构化数据,NOSQL 数据库则可以保存非结构化数据。举个例子,还拿上面的用户表来举例,如果我们现在想要给产品集小妹增加一些额外的属性,比如她给某个产品点赞可以效果 x2,那么如果是 SQL 数据库,我们就需要给数据库增加一个新的字段来保存这个属性:

但是如果是 MongoDB 这样的 NOSQL 数据库,我们就不需要给所有用户都增加一个x2的属性,只需要给产品集小妹单独增加就可以了,NOSQL 中保存到数据是如下这个样子的:

Cookie 和 Session

服务器要处理成千上万用户的请求,那么他是如何区分每个用户,并返回给每个用户他所需要的内容的 ?这就要涉及到 Cookie 和 Session。我们可以将 Cookie 理解为是服务器给每个用户分配的唯一 ID,这个 ID 由用户浏览器保存,而 Session 则是服务器为了维护这个会话在服务器端保存的与 cookie 对应的用户数据。

移动端开发

移动端和浏览器的区别就在于,大部分 App,我们打开的一瞬间,就已经看到了它的界面,而不用再去向服务器来拿显示界面的 HTML 等文件。所以移动端,开发原生应用所运用到的技术(比如 Objective C,swift)就相当于前端的 HTML,只不过它是直接保存在应用本地的。这样就产生了一个问题:如何来获取应用数据?如果是网页应用,我们可以直接将数据包含在HTML 中一并反馈给浏览器;但是对于移动应用就需要有一个专门的协议来传送应用需要的数据,这就是 JSON。

移动应用的前端技术,目前来说主要有以下三种:

1/ 原生

2/ 混合式

3/ HTML5

HTML5 必经要经过浏览器这个中间层,所以在性能上多少会有些损失,所以如果你的应用对性能特别敏感,原生就会是比较好的选择;对于普通的性能要求没那么严格的应用来说,HTML5是完全可以满足的。而如果已经有了一个移动端的网站,这种情况下混合式就会是一个比较好的选择,它可以最大程度的利用已有的资源。如果说你是从头开发一个移动应用,并且这个应用对用户体验的要求也不是特别严格,那么 HTML5 就会是一个很好的选择,HTML5 移动应用比较显著的应用就是 Dailycost 。

如果说开发一个原生应用需要 4-6 周,那么同样功能的应用如果我们把其中的一部分用 HTML来实现,那么可能就只需要 3-4 周的时间,但是如果我们全部使用 HTML ,可能就只需要1-2周。

此外,活动另一位嘉宾、 bearchat 工程师 Loddit 分享了关于数据抓取的干货知识和 tips ,感兴趣可前往 http://36kr_data_capture.meteor.com 下载 PPT。

『书架清理活动』副产品-电子阅读漫谈

最近在进行『书架清理活动』,作为一个进阶中的非重度阅读爱好者,kindle虽书多+不伤眼,偶尔翻翻小说还凑活,但简陋的排版和pdf阅读体验实在无法忍受(刷多看系统掉电又太厉害),所以目前大块时间常用的是iPad mini+豆瓣阅读和多看,手机上也装了相应的Apps以打发碎片时间,没有好的电子书或特别支持的一般会买实体书看。

这些天实体书、豆瓣跟多看上的库存都看了些,脑子里一直冒出跟『电子阅读』相关的内容,试着梳理下。

先描绘下po主心中理想的电子阅读:多看的排版+kindle的书量&E-ink设备+豆瓣的低价&社区&独特内容。说具体一些,就是有个像kindle这样顺手的E-ink小设备,最好能是彩色不伤眼的;书当然越多越好,最好冷门、原创的书(或内容)都有;书的排版不要求跟实体书一样但也别像90年代的网页一样带着大蓝色链接和莫名其妙的折行、漏字,挤成一团,跟多看差不多我会非常乐意购买;价格最好别高过实体书的一半,制作特别精致的可以无上限;社区这块儿,最钟意豆瓣的书评、批注弹幕和跟作者的互动。

按照这个理想的存在,各家的做法是如下这样的(数据均从各家官网的书籍分类数目手动统计,不保证准确性):

kindle虽说从去年开始重视排版,可惜我最近想看的几本书排版还是无甚改进,搜到这篇文章链接里所说的几个出版社的书看,确实比其他书排版要好一丢丢,但是离好(比如多看)还差得比较远(模糊的封面、蓝色紧密的目录、奇怪拥挤的行距真是没欲望继续看下去–果然我还是太肤浅:p);

多看的书目前不到6万本,比上不足比下有余,书确实是非常精致,尤其以《唐诗三百首》为经典,简直业界良心&标杆,在iPad mini上看体验很棒,除古诗及注解以外,还介绍了吟诵相关的知识、诗人的生平、轶事,涨姿势的同时还能听吟诵版和朗读版。社区方面多看的书友圈和书评广场上线有段时间了但很遗憾的是暂时还没有吸引到我,除了邀约的名人稿子很少看到出彩的书评,倒是有个任务系统+限时免费挺有意思的,敦促我在3天内认真的看完了2本书,还做了笔记并导出到了evernote(笔记看起来也挺精致),以后需要再用到这些书时估计会优先在多看买,如果多看如果能推出包含这些好书的会员制(特殊的超贵的书可以单拎出去,会员有折扣价之类的,包含在会员里的书可以按阅读量给出版社分成),每个月十几二十块最好(京东电子书倒是有类似服务但书的质量跟kindle差不多…),对我吸引力会比较大;

豆瓣阅读,从诞生起就从未停止探(zhe)索(teng)的脚步啊,阅读弹幕、投稿系统+专栏/连载/原创作品、原创作品大赛和各种读书小活动,作品量虽不多(加上原创不到2万)但偶尔也有些独家电子书及有趣独特的内容时不时地吸引我(对网络小说一向没啥兴趣但啃硬书又啃得不太积极)。书的排版引擎改进过几次后,精致程度虽不如多看,但是比kindle强不少;今年初新发布了2.0版本强推自媒体结果在知乎上被黑出翔,黑点主要集中在1)新logo丑;2)强制展示首页;3)书架拆成已购和本地,删掉了老版本里本地数据,阅读进度丢失,已购里书和连载、专栏混杂,随着版本的迭代,2已经优化,1、3依旧,1中原logo跟加载时跳来跳去的那只鸟换成现在这样其实还挺可惜的,3中损失了升级前1.9版本的本地数据,对我而言最大的损失是有些试读但当时迟疑未购买的作品,后面新版本里已经找不到了,汗…以上这些,对书多的老用户1.x升2.0冲击的确有点儿大,知乎上有人吐槽产品汪不尊重人神马的,我看更像是策略失误以及豆瓣一贯的『边做边改』,『用心』、『考虑周全』、『细节把控』此等产品汪重要技能,都是在用户骂声中积攒的所以有时候并不到位-正所谓『心有余而力不足』,你把时间拉长可以看到,豆瓣的汪们心意是够的,你看他们一直在坚持做一些不同的有趣的东西,2.0之后的版本迭代也在积极地修改和优化,个人或集体的决策、方向随时可能会出纰漏,更何况产品需求本身就存在『众口难调』的难题(比如我至今仍不适应已购跟本地作品分隔的那么开,哪怕本地书籍是基于『枕边书』的概念来设计的,像多看的书架以试读、下载的图标或『仅显示本地』的分类来区分不是更简洁高效么?这样我还不至于损失1.9版本里的试读书籍呢,且不同设备间的试读作品要如何保持连续呢?),再者,产品本身的特性和气质也是要有的,并非一味迎合用户才是最好的产品,所以还是给点耐心和时间看看他们到底会做成啥样,话说,豆瓣阅读要是黄了还真不知道上哪儿找替代品呀。

关于各家共同的难题:电子书制作成本高(也即豆瓣、多看电子书数量少,kindle电子书品质渣的原因),这篇文章 或许能出一定程度的解释,kindle试图通过推行工具+排版规范+出版社『自转码』来降低成本,尽早达成质、量双收,无奈有觉悟和实力的出版社还不多,要等大部分出版社规范起来似乎不太现实那有没可能用众包的方式来做呢?比如先由电子书平台获得出版社授权后,由读者认领书籍,基于不规范的电子文档在平台方的电子书制作平台上对目录版式等进行加工,再由平台方统一审核,报酬可以是这本书,也可以是别的电子书,这样就把加工成本以电子书的形式消化了,出版社、平台、读者都高兴,这么好的法子为什么现在没有人这么做呢?粗略想了下,多人协作的编辑平台、众包活动的运营、电子书排版质量的把控等等一堆难点估计足以把这想法扼杀在摇篮了,不过,如果我是相关平台的产品汪,估计会先找些读者跟出版方调研下,万一行得通呢?想想,亚马逊要是能这么干,威力简直无法想象。

豆瓣阅读是早就想开了,没跟别人盲目比书的数量,而是依托豆瓣社区,电子书只抓住最新热门好书,估计还有Top想看的书(豆瓣),自出版深挖掘草根作者+深运营,相信也能黏住一部分用户(我是被黏住了,不知不觉这几年花费近千元了,像《斫琴记》这样的作品目前还只有豆瓣有呢),但不知道这样的用户能有多少。

这两年我在书上的支出远超出之前的总和,纸质书跟电子书,大概2:3的样子,但数量上,电子书远超纸质书一个数量级(其实也就是百跟十的差距啦,:p),这也让我的阅读量大涨,尤其一些大部头(比如《失控》,几年前买的纸书,挑战过数次都没读完,后来买了电子书,最近终于看完了第一遍…),电子书真心方便,坐车、等人的碎片时间都能充分用起来。

这不禁让人想起那个经典的问题:『电子书多大程度能代替纸质书?』从我自身的经历和感受来讲,关键取决于电子书最终体验的到位程度,包括书的版式、多媒体交互、各种体验(笔记、跳转等),读者、作者间的互动(豆瓣阅读的弹幕批注还是挺有乐趣的)等,完全替代,在我看来短时间内不太可能,总有些书你会在看完电子版之后忍不住还要买本纸质放在床边书架上的(比如李娟的《冬牧场》,村上春树的《挪威的森林》等等),还有些书我只有纸质版(比如《小王子》,有各种不同的版本),这时候纸质书已经演化成一种超越阅读本身的存在了,从可行性角度讲也是so easy的,按需出版就能很好的解决库存仓储等难题。

还在吃螃蟹的路上-bong II体验

说起智能手环,虽然去年Jawbone up2吃螃蟹扎破了嘴,但也没有掐灭po主的关注热情。国外的有Nike+ Fuelband、Fitbit Flex、Misfit Shine,国内的有bong,各种比较、观望但一直没入手(还是觉得智能手环不够成熟且价格偏高)。

后来的故事大家都是知道的,bong II『预备–推出』时,小米手环『花擦』提前以79元的触底价格发布了,一上来就是踹飞大伙儿饭碗的架势,紧接着 bong II也(只能)以99元价格发布(心里估计有一万匹草泥马奔腾),可bong I的价格是690哎,眼见bong微信社区老用户骂声一片…po主表示很理解这种心情,但这就是吃螃蟹的代价啊(这时po主得知硬件成本价格只有几十块的时候简直心绞痛嘤嘤嘤T__T…),

因着bong I还不错的口碑,以及bong II之前在微信公众号的造势,『自动识别状态』『无感佩戴』、『一年超长待机』、『IP67超强防水』各亮点都是比着Jawbone的缺点来做的(之前bong还做过J尸体免费换bong II的活动不过po主没赶上),再加上不到J十分之一的价格,不心动不行啊,遂预订了一条。

预售时承诺9月发货,结果到8月底微信公众号木了动静,可想而知又是骂声一片,然后bong站出来说了,因为异型锂电池量产的问题,需要推迟到9月底发货…此处又是骂声一片,不过po主本着破罐破摔的原则(一年前比这贵10倍的水漂都打了不是我有说神马吗),继续保持等待(这里感觉bong的公关确实不咋滴,创业团队做东西,总会有各种意想不到的因素导致跳票,至于如何在跳票时提前跟用户解释,可以好好研究下罗永浩的锤子手机跳票的例子)。

于是昨天,9月倒数的第二天,我终于收到了传说中的bong II。截止到现在,使用一天多,大概说下使用体验。

实物外观么,个人感觉比小米略好一丢丢(其实俩都丑),比起bong I,金属主体由方形变为椭圆,还增加了圆形yes键,一下感觉丑了好多;橡胶质地偏硬,很薄,不过做工还算精细,戴在上手的确是没啥存在感。鉴于小米手环主体存在容易脱落的毛病,我抠了抠bong的主体,很紧实不容易抠下,但戴时间长了橡胶老化就不好说了。

心情平静的(如果你像我一样经历了这么多大概也不会有啥兴奋劲儿了)装上App,连接,设置,看起来似乎一切很顺利,于是戴着下楼走了一圈儿测试下数据,结果上楼死活同步不了…说好的自动后台同步,下拉界面更新呢…一直提示『同步失败』…最后通过多次开关蓝牙终于搞定。此时po主的血槽已掉一半。

自动识别的数据还是靠谱的,散步几分钟,跑步几分钟,记得很准确,还奖励了1点活跃点活跃点跑步5分钟累计1点=1元,可在bong商城兑换售卖的商品(大概十几种,有手环、智能体重秤之类的),1点=1元还是非常吸引人的,此处略有回血。不过目测不会是长久之计,随着用户的增多,活跃点的兑换价值应该会越来越低,暂时来看,算卖点,也能激励一些用户运动(论坛里有些用户靠活跃点换购好几条bongI了…)

睡前继续探索App,整体分为主页、互动、活跃点、拓展、设置5个tab用户可通过App对手环进行设置,满足其日常活动、睡眠的数据记录,同时还有好友社交功能及十几个拓展的H5应用,对你没看错,bong对自己的定位是做成开放平台。

听起来很棒是不是,但实际的体验如下:1)UI简陋到觉得有必要单拎出来吐槽,尤其主页上用弯弯扭扭的曲线展示一天的状态,简直不能更丑(虽然与众不同很重要,但是请务必保持优美)且探索一番没有找到轨迹记录…2)互动里有排行榜、一起睡、加好友,排行榜是与好友pk,因为还不算bong的老用户,没有好友,所以暂无法体验;『一起睡』类似『翻牌子』,根据睡眠数据算出一个匹配度,可以指定性别,每次展现一个用户大头照,不满意可以无限翻,几十张翻下来,真人头像的不多且搓(囧),或者是小猫,花草等,一天内收到两个异性加好友的请求,为了体验我也通过了,不过并无下文(估计是不知道该怎么样有下文吧…),所以可以大概判断,『一起睡』这个点子或许还不错,但bong并未下功夫运营和引导;加好友,推测主要途径是通过『一起睡』、通讯录、公开自己帐号,居然没有附近bong友?也没有类似广场的功能,能让用户自然的通过bong这个共同点社交起来,实在令人费解;3)拓展应用试装了几个,『睡眠助手』会针对睡眠数据给出一些具体的建议并无出彩、『运动数据』主要是运动、睡眠、热量三者一天总和的Excel版横柱图~丑哭(你们的设计师是程序员兼职的嘛…);『小bong龙』可以用活跃点对电子宠物bong龙进行喂养,点子还不错,不过设计和交互就无力吐槽了;『我的排名』是自己在整个bong社区的排名,还是浓浓的Excel风;『30天减肥计划』,只是简单的设定减脂斤数,然后吐出一个每天需要燃烧的卡路里,底下是总进度和总天数的统计;其他应用的图标看起来都非常随意,整个拓展中心弥漫着敷衍、随意的气息,所以做开放平台是个很有想象空间的事儿,但bong的打开方式目前看起来随意了些,摊子铺的有些大,所以每个功能看起来都比较草率和敷衍

最后,po主抱着重温Jawbone up振动闹钟体验的想法设置了个起床闹钟,结果,到点了并没有振,上网查才知道,因为闹钟那个点我是醒着的,所以,智能闹钟并没有振…这闹钟是不是智能过头了…一般人都怎么使用闹钟的?像po主这样提前醒了但是非要等闹钟响才起床的人莫非不是大多数?

另,久坐振动提醒的功能也是木有的,踩椭圆机也不能识别成运动状态…已无力吐槽

看来bong这个螃蟹又咯到牙了,不过胜在便宜,下次也许会再试试小米手环。

豆瓣App使用感受

千呼万唤的,豆娘终于出App了~图标居然不是『豆』字,居然是个绿杨桃(绿星星)。哎,用了差不多一周,说说感受。

就『手边的书影音资料库』这一场景来说,确实比之前大有改观。之前总有没在电脑前,但是又想查个电影、书的时候,从手机浏览器上打开豆瓣简直噩梦,自动跳转成H5页面,加载慢不说,还各种找不到功能(比如搜索),帐号也是经常莫名其妙用着用着就登出了,这些问题在App里都得到了妥善解决。另外搜索增加了图书二维码扫描,这对爱逛实体书店的人来说无疑是个好消息,随手扫了几本书(新旧流行小众都有)均能正确找到并显示该条目页。

最大的亮点是每个条目下都有即时讨论组,这个功能有人叫好有人唱衰,结合我自己的使用经历,热门影片(比如《后会无期》)讨论人数众多,点进去看,刷屏较快,讨论内容非常水,大多是过来尝鲜的,也有求种子,求勾搭的;非热门的(如《孤独美食家》)一共也没几条,不过有个人讲话比较有趣,点头像过去大致了解之后加了关注。这个功能,个人认为,具体的条目+即时性,其实很有爆发潜力,但需要搭配合理的内容引导和规范,除了做一些官方组织的讨论活动之外,没准有豆瓣用户能用出花儿来可以作为传播素材(刚才脑补了个勾搭妹子的技巧:有些非常小众的条目可以先加到讨论组,然后就是守株待兔了呀~不过至于是会有妹子还是汉子进组跟你讨论那就看命了:p),这里估计豆瓣还是它的惯常打法,搭个大架子让用户自己先用起来,然后看数据(比如对加关注、日活跃等指标有无拉动),观察用户,慢慢细化。

整体采用了Tab结构,共四个,与web端差较大,这是必须的。说起手机端的大豆瓣,直接照搬web端肯定是不行的,如何取舍,如何避免做得过于复杂,恐怕大家都要挠头。来看看豆瓣自己是咋取舍的,Tab页里『豆瓣首页』包含搜索、书影音活动的入口以及热门推荐,『讨论』是各个已参与的讨论列表,『心愿单』是想看的书影音列表集合,『我的』评分、关注等内容,功能暂时还很简单,点到个人主页神马的还是跳转的页面,我个人比较常用的喜欢、广播、豆列、豆邮、评论暂时还没有,另外,虽然豆瓣上可进行的操作挺多了(比如各类做标记、加关注等),但基于手机特性的操作,像拍照发状态、基于地理位置的各类应用等,应该也是可以多发掘下的。

总之呢,作为第一版豆瓣App,已经成功勾起我对后续版本的向往,但愿这款应用豆瓣不要太慢了,后续你们要做的事情真的还非常多呢~

我为什么一直在用《下厨房》

前几天写《味库》试用的时候,还想着是不是可以跟《下厨房》对比下,后来想算了,《下厨房》使用时间(2012年3月加入,7月发布第一个菜)也蛮久了,是我手机上的老住户,两者的主场景跟定位也不太一样,等多攒几个再来横向对比吧,今天先说说自己为何一直在用《下厨房》。

《下厨房》的主场景其实挺传统的,就是照菜谱做菜,以及分享菜谱,我的使用频率一般,发布的菜谱也不多,粉丝也没几个,但这种不紧不慢的使用居然也维系了两年,我想大概的原因是以下这些:

1、菜谱简单还原度高,上手简单,评分较为靠谱。

第一次用已经记不得是因为什么了,但我猜跟味库差不多,估计也是在哪儿看到推荐,然后就开始用了,最开始只是单纯的看看,收藏下自己想吃的菜谱,那会儿做菜我一般参照美食天下的菜谱,但有两个略头疼的问题,一是菜谱看起来都不太简单(又蒸又炸又卤的),二是按步骤做完发现甭管卖相还是味道都跟图片相差忒多。

《下厨房》呢,可能是用户匹配度较高的缘故,菜谱的描述、步骤、配图、tips什么的,非常口语化和有自己的调调,最关键,随便挑个7、8分的菜谱照着步骤做出来的菜味道卖相什么的居然还不错。我第一道按照《下厨房》菜谱做出来的菜是清蒸鲈鱼,是一次朋友聚会做的,收到大家一致好评(这种情况下自然回评菜谱一个『好极了』)。这为我继续使用开了一个很好的头。

2、赞和讨论神速。

印象中上传了这道鲈鱼,很迅速就收到别人的评论和赞,起初以为是马甲用户,结果点过去一看,还真不是,于是顺道看看别人做的菜,看到好的也就自然要点个赞回应下加个关注咯。一来二往的,自然有了互动和黏性,不做菜的时候,也可以看看厨友们都做了什么好吃的。

后来才知迅速的原因:《下厨房》的神器『赞』用起来真的很方便,无论大图小图,鼠标悬上去就能赞(后来有了手机App,点赞也很方便),另外『全站更新』的展示应该也是能让新用户迅速融入社区的好手段(需要严控产品质量)。

3、内容各种优质可读性甚强。

不管推送、各处文案、用户上传的菜谱(其中有很多《下厨房》原创的菜谱),整体内容的水准都比较高,这跟创始人的品位和要求很有关系(UI设计师出身的品位就是不一般^__^)。

文案的水准,举个栗子来说,下厨房的Newsletter我基本上每期都会点开看(有次在一个热门菜谱上看评论发现像我这样的用户还真不少),随手都能写出几个我有印象的来(其实是好的我都记到Evernote了啦:p):『唯有美食与爱不可辜负』、『是谁来自山川湖海,却囿于昼夜,厨房与爱』、「没人生来就是好厨师」、『把美食与爱装进口袋』、『我们对食物能表达的最高敬意』、『料理是一场原地的旅行』,就是这些诗句般优雅的文案,一次又一次把我拉回网站。

拉用户互动的文案也比较贴切,充满鼓励:

用户上传的菜谱就更不用说了,随便点开几个,要么是美cry:

要么就是看上去很原生态很好吃呀:

黑暗料理也是有的:

大家配的心得也是各种,有写自己Tips的、随笔、自黑的,总之五花八门千奇百怪可读性十足,话说我有段时间项目压力大,每天会给自己留20分钟逛《下厨房》解压,疗效特别好哦~

4、菜谱的场景化异常丰富和有特色。

早餐、快手菜、宿舍、单身食谱、外貌协会、便当、素食、孕妇、产妇、婴儿、儿童、时令、本周最佳、流行菜单,等等,每个分类都对应着活生生的使用场景;然后是各类特色的菜谱list(类似豆列),神马『懒人福音-塔吉锅菜谱』、『十分钟早餐系列』、『深夜食堂系列』、『电饼铛系列』、『电饭锅系列』;后来又增加了每日三餐的美食记录区(其实功能非常简单,就是首页开个窟窿,每日三餐分三个轮播图,点开之后可以看到厨友们上传的作品,也可以自己上传),总结起来,有生活场景的、热门剧集的、针对专门厨具的,对内容的深耕细匀做得确实行云流水,信手拈来,非常到位。

以上总结起来,《下厨房》功能简单易用(除了菜谱相关的功能这么久了也就加了个购买清单还挺实用的至少不会忘记买葱姜什么的配料了)但内容丰富优质,社区互动便捷活跃,再加上适时的一些唤回措施(针对节气、节日、热门事件等),想让人离开都难呢。

至于日后如何拓展、盈利举个我自己的栗子,我有一家吃了一年多的食材淘宝店就是在下厨房的侧栏广告(还是博客?)里看到的,非常靠谱,累计购买额已经2000+了(自己吃也买了送人,宝贝评论里也看到不少从下厨房过去的厨友)。如能保持品质,《下厨房》以后出食材、厨具类的电商,从中赚钱合理利润,或者干脆众筹做一些高品质性价比的厨具、食材(有些高端厨具买起来真是肉痛啊有没有一些性价比高的推荐呢?食材有没有主料配料都配齐的新奇一些的呢?这些我们在经历着的痛点,能够妥善解决的方案即商机啊),甚至其旗下开张没多久的料理工作室『山川与湖海』,没准也能拓展成料理人通过『下厨房』孵化(众筹)自己的私房菜馆、烘焙馆…(哎~吃饱了就是容易胡思乱想)关于吃的拓展和盈利,不要太多~~

说回来,赚钱的手段可以有千万种,但最最关键也是最最难得的,其实是始终不要忘记自己作为吃货那颗初心:吃得好些,吃得放心些,吃得方便些。

ps:像这种自来水文总是忘记说说不足,非要说不足,就不得不提起早期《下厨房》误删数据库的乌龙事件了,不知是否有心理阴影,总感觉网站有时候访问起来速度慢,或者担心一下蹦个404,希望《下厨房》早日赚钱早日找到技术大神吧…

味库的一些使用感受

前几天看到最美应用推荐,爱做饭的吃货当然不会错过,当即下载,试用了几天,说下感受:

最主要的使用场景(或者说味库最希望用户如此使用的场景):冰箱里有些食材,但不知道做什么菜好。

这种场景下,一般可分为两种用户,一是完全的厨房新手,稀里糊涂买了些自己爱吃食材,但胸中其实没有『谱』;二是厨房老手,常做的菜吃腻了想探索下新菜,或者临时冰箱里就剩那么几样食材了,看看能做什么。本人可以勉强算作第二类用户。

要在这个场景下发挥作用,我们需要先使用味库做些准备工作:1)电子化我的厨房-将厨房中各种食材和厨具添加进Apps,可以通过手动勾选、搜索、扫描条形码三种方式。等我做完这项工作,已经是一小时以后了,共添加了100多个食材和厨具。我自己也没想到自己厨房有这么多东西呢…这里有小小的成就感,不过更大的问题是比较累人,a.手动勾选可选项实在太多,勾了几个之后改手动搜索了;b.条形码扫描的成功率大概60%,像万字酱油、黄油、酸黄瓜罐头等不算太小众的食品均无法识别;c.一个食材用完之后需要手动删除。

接下来就是2)推荐菜谱了。

大概是因为我厨房里有面粉、黄油和烤箱么?推荐的菜谱前几页基本都是烘焙。真遗憾,恰好我是个对烘焙无感的人(可能觉得太麻烦吃的也少偶尔想吃了会去店里买),厨房的面粉其实是买来清洗猪肚,以及偶尔做个早餐蛋饼,黄油是小盒装涂抹面包用,烤箱是公司抽奖来的,做过几次烤鸡翅而已。

以及『牛奶芒果西米露』、『鱼香茄子煲』,这更奇怪了,我的食材里只有牛奶、豆瓣酱而已,这是让我去邻居家借芒果跟茄子的节奏么…

不看推荐的话,添加好的食材和厨具可以看到其效用、搭配、注意事项、大家的评论和其专用的菜谱,可以当厨房小百科来用,稍显鸡肋。

然后可以3)根据推荐的菜谱做菜了。

点开一个凉面菜谱,里头需要的『姜蒜末』、『葱花』、『香油』我的厨房统统没有,以我粗浅的厨艺推断,缺了这几样应该是不会好吃了,于是又点开了另外一个稍有点兴趣的菜谱,依然是缺胳膊少腿的情况。

综合2、3来说,味库推荐的菜谱靠谱程度较低我想这跟大中华饮食的千变万化复杂情况是分不开的,但推荐的算法、食材的结构化(至少要能把主料跟配料区分开,最好配料还能分主要跟次要)也还需要狠狠调优。

味库并没有主动创建菜谱的功能(据说是全网抓取的菜谱),推荐的菜谱头图上会显示创建者id(并非所有菜谱都有,且id不可点击),被收藏的次数,被做过的次数,做菜的具体步骤、评论、其他人晒的厨艺。评论里偶尔看到几条询问的,但都无人解答,其他人晒的厨艺,也只展示了图片和id而已,且id不可点击,图片也不可点赞。不知是否味库刻意将自己定位为工具,弱化用户间的互动,还是打算后续加上。总之从整体的氛围来看,非常冷清,非常不利于激发吃货用户使用并晒出自己的作品。

做好菜就可以4)晒图了,味库这个功能简直槽点满满。a.从照片库中选取图片后直接就上传了,没有任何你可以填写内容的机会,也无任何提示,反倒是底部出现如图的三个图标,给人感觉以为是要直接分享到这三个途径,结果『取消』之后,在我的厨艺里看到了刚才上传的图片,还默认配了一段挺弱的文案;

b.分享出去的内容,只有这个菜谱跟味库的下载链接而已,跟分享者没有一毛钱的关系,纯粹是赤果果的骗用户推广啊(但效果还很差)…

另外的功能,像首页的菜谱和发现(关于吃的七七八八),也无太多亮点。

综上,虽然『电子化厨房』、『智能推荐菜谱』等概念听起来很酷很炫,但实际用起来却感觉非常一般。究其原因,一方面是味库目前具体的产品形态和交互确实存在不少问题,另一方面也许是味库选取的主场景并非厨房用户的痛点吧?至于哪些可能是痛点呢?作为一枚还算经常下厨的吃货,可以举出几个,比如每次做完一餐,调味品、葱姜蒜总会剩下然后被丢掉;尝试新菜式(比如西餐、日餐等)时需要配齐所有调料才能开始,但频次太低,过了保质期后只能再买新的,太浪费;比如某些菜、各种肉、洋葱等等的切法,菜谱上很少提及细节;比如其他人菜谱中提及的一些原材料或厨具应该去哪里买靠谱的;等等,其他类型的厨房用户(比如全职家庭主妇、纯新手等)他们应该也有各自的痛点,真正深入到厨房活动的进行过程当中,待改进或颠覆的点还是有不少的。

鉴于味库目前才刚开始起步,也算是提供了厨房经济的一些新的方向,会保留下来继续观察。

由一篇穿越游记想起的

想去台湾提前做准备的缘故(预计十一去现在就开始准备是不是有点儿太提前了喂~),最近重新开始使用蝉游记。这两天看到一位可爱大叔发了他30年前的旅游攻略,图文并茂从行程、住宿、饮食、物价等各方面介绍30年前去张家界旅游的一些细节,有代替身份证的介绍信、粮票、景点旁边的帐篷旅馆、小硬卡片式火车票、塑料质地的景点门票,等等,一大堆我没见过的事物,可读性和还原度很高(拿给父母看他俩看得都觉很亲切都开始忆往昔了),活生生的微型民间历史书。

以上加深了我对旅行的理解:旅行最大的魅力除去当下空间上的穿越带来各种独特体验,时间上经过岁月发酵,某天重新被阅读时的副产品(于己于人)绝对会有各种惊喜和收获(所以po主每次出去旅行后的总结要么拖延要么渣是肿么回事?靠谱的旅行总结赶紧整起来哟~)。

感叹大叔的收集整理好习惯经过时间沉淀带来的神奇感觉之余,也好奇蝉游记上的高质量游记为何如此之多?像大叔这样的高龄用户是怎么被吸引过来的呢?蝉游记到底做了神马?一脑袋的好奇,用产品汪的行话概括成一个问题『蝉游记如何做的产品运营以及有何可借鉴之处?』

综合对蝉游记的创始人&产品经理@纯银 的一直关注以及产品的试用、观察,揣测+总结到如下几点,记录备查,时刻学习体会之:

还未开始的时候:蝉游记尚未立项,@纯银 已经做好原型,并从竞品观察、用户访谈、运营准备各方面提前做了翔实有效的准备,其中运营准备方面,已有种子用户的大概轮廓和模糊标准,即『有国外旅行经验的年轻女性』更贴切,排斥何种用户和题材内容均有定义,然后种子用户的寻找和主推广阵地也已经基本确立。这点除了告诉我们成功绝非偶然,还让绝大部分同行(包括我)汗颜(不过『临渊羡鱼,不如退而结网』啦),高质量的基因在还未开始时就已经汹涌流淌所以影响深远是有坚实基础的,现在看过去,大部分内容品质、格调基本没怎么走样。

开始的时候:强运营+独特的产品架构+貌美,留下深刻的第一印象。记得大概是12年8月,蝉游记PC站发布的时候,『火车流』横向画卷样式和大量旅行美照使得蝉游记从一大堆旅行社区网站中脱颖而出,但那时候并未开放发布游记的入口,至13年发布iOS App的时候,发布游记的入口也很隐蔽,看到知乎上有些用户提到当时受邀试用,不难揣测出最初内容的高质量来自运营同学的强力控制和努力,这一步对奠定产品调性和氛围也是非常关键的,『宁缺毋滥』被执行的很彻底。

推广:初步的高质量内容有了,该针对目标用户进行推广了。这里需要M一下的是,@纯银 最开始的推广策略就是着重微博,不从竞争对手处挖角,看似吃亏,实际上避免了早期萌芽状态就得罪人打草惊蛇,省了不少麻烦事儿,可谓『另辟蹊径』。推广手段总结下来,主要有微博粉丝通、微博大号,各类App推广渠道(比如美图、苹果园、同步推、PP助手,各大应用市场)。根据产品的不同类型和特点,具体推广手段是多样的,罗列具体手段意义不大(最笨的法子就是把市面上有的推广方法一一尝试,提前数据埋点以便对比,同时结合数据和反馈适时调整渠道/方法),这里需要学习的是@纯银 关于每个渠道推广效果的密切关注、对比以及思考

步入正轨:慢慢的用户自行发游记的多起来了,看游记的人也多了,反馈的人也多起来了,口碑也起来了,产品也开始迅速迭代,这时候重点依然是牢记最初的标准『量体裁衣』。今天可以看到蝉游记不管是首页、旅行地里一眼能看到的图文依然高质,但点到旅行地相关的游记,多翻几页,渣图渣游记也是有不少的,不过整体上,甚至中度使用频度下,它的内容仍然美出其他竞品一大截儿。这么好的效果当然不是一天速成一帆风顺的,从@纯银 分享的微博来看,即便坚决贯彻『在用户容易接触的区域刻意筛选发布符合产品形象的内容』原则如蝉游记,也吃过『附近游记』的亏,但一旦渣内容冒出立即撤下毫不手软,直至想出合适的产品形式。

以上的坚持跟付出最终是有回报的,蝉游记数次被推荐到App Store精品推荐及各类专题页中就是最好的证明。当然最有力的证明-用户使用体验还有待时间给出答案,这里我只说下我的个例,去年五一去香港,去之前做攻略,兴冲冲下载了蝉游记,动不动闪退,遂怒删之,转战PC Web,发现除了美图一无是处,最后是用蚂蜂窝+穷游搞定;最近被台湾游记勾引重新启用,目前用的最多的是收藏旅行地和游记,对台湾有了大致的印象和无限向往,仅就这个使用目的来说,体验是很愉悦的。至于实际到了旅行地,会不会用『附近旅行地』,回来之后会不会发游记,到时候再看咯,还有好几个月呢,还挺期待那时候的蝉游记的。

 

背痛星人自救良方-BackpainRelief

【2014年11月19日更新】今天发现有更新,名字更新为Yoga for Back Pain Relief,且神奇的发现售价变为18元(难道po主是限免时下载的?)推荐指数立即跌为负值…好吧,各位请直接移步『每日瑜伽』,里头有免费的背部课程,动作较多,各位可以参考本文的5和9个关键动作进行取舍。

介绍一款最近拯救po主,极其简单的瑜伽App:BackpainRelief,对坐姿不良、脊椎错位等引起的背痛灰常有效果。

BackpainRelief分为两档难易度,分别包含5和9个动作,可设定背景音乐,全程3D人物动画演示(各角度展示)和讲解动作要点(只有英文但是简单易懂)、数息,用户只需要打开Apps,跟着做就好了,做的过程中可暂停、快进/退、停止,全程9分钟(9个动作是17分钟)

5个动作:backpain1

9个动作:backpain2

无广告,免费,讲解专业,声优平和优美,简直Apps业界良心啊~

附正确使用注意事项:
1、重要前提:先对着镜子或者找人矫正好姿势再进行,以防姿势错误影响功效或受伤;
2、瑜伽过程中请注意安全,各动作如觉得有难度,请量力而行,尽力即可,可慢慢的循序渐进地做到位;
3、坚持每周3-5次,如果有条件,可以每天都进行(床脚边铺着一块儿瑜伽毯就好啦),这点其实是最重要的,
4、日常工作中,注意坐姿(如下图),且时常起身舒展下身体(像小时候上课隔1小时起身喝喝水,舒展舒展),有条件的壕还可以来一把好椅子