产品设计

七牛在线管理图片预览chrome插件

七牛在线管理图片预览chrome插件

月盾
七牛云图片存储有10G的免费额度,对于个人来说足够使用了。使用七牛图片存储涉及到图片上传,查看,管理的问题。为了能提高使用效率,我们可以利用好一些工具。 vscode插件上传图片到七牛 vsocode扩展市场有很多上传到七牛的插件,大家可以根据需要自己选择。 上传的图片多了以后,有时需要找一些已经上传的图片来使用,目前我所知道的方法还仅限于登录的七牛后台上查看。 可以看到,七牛的管理后台做的不能说很差,可以说是很气人。要预览图片必须点击“详情”,当你关掉预览窗口时却不知道查看的是哪张图片,也没有个高亮聚焦。而且也没有时间排序,只有名称排序,真的是很难用。 为了能够直观的看到图片,决定开发一款chrome插件,将图片直接显示出来,而不用再点击查看。 关于chrome插件开发的细节本文暂不细说,直接上代码。 代码展示 manifest.json { "manifest_version": 2, "name": "chome-plugin", "version": "0.0.1", "description": "chrome示例插件", "icons": { "16": "images/icon-16x16.png", "48": "images/icon-48x48.png", "128": "images/icon-128x128.png" }, "page_action": { "default_icon": { "48": "images/icon-48x48.png" }, "default_popup": "html/popup.html", "default_title": "Hello yuedun" }, "author": "yuedun", "background": { "scripts": [ "scripts/jquery.min.js", "scripts/background.js" ] }, "devtools_page": "html/devtools-page.html", "content_scripts": [ { "js": [ "scripts/jquery.min.js", "scripts/content.js" ], "css": [ "styles/yuedun-insert.css" ], "matches": [ "https://portal.qiniu.com/kodo/bucket/resource?bucketName=*" ], "run_at": "document_start" } ], "permissions": [ "cookies", "*://*/*", "webRequest" ], "homepage_url": "https://www.

让代码配置化

月盾
背景 面对运营频繁的页面修改,每次都是换个图,改个字,要么就是在现有的页面基础上新做一个,再稍微的改点东西,虽然这种需求做起来也不是很费事,但也架不住一天一次修改(有点夸张,但的确很多)。日积月累,就开发出很多相似页面,大多数都用作abtest,在众多页面中选出个别页面,其他页面只能被打入冷宫,永远没有访问的机会。显然这些页面留在项目中额外增加了打包编译负担,甚至拖累其他页面速度。 原来 日常开发流程是这样的: 开发 -> 合代码 -> 上测试环境 -> 测试 -> 合代码 -> 上uat环境 -> 测试 -> 合代码 -> 提发布申请 -> 发布 -> 验收 就算是一个3分钟搞定的需求,流程也需要1天,因为中间有太多的环境切换和人员流转。 这样的经历所有做过运营活动的童鞋或多或少都有体验,所以很多人也想过做一个编辑器,比如拖拉组件的方式实现一个页面。 我们曾经有种设想是直接给运营做一个活动编辑器,让他们自己去修改,自己去做页面,自己发布。说实话这个也做过,但是没用起来,原因呢大概就是人性的贪婪与懒惰,当初做出第一版的时候觉得太简单,不能满足使用需求,第二版的时候功能倒是挺丰富,但是运营又不会用。想想那么多css样式,你以为图形化了他们就会用?太天真!干脆教他们写代码好了! 现在 所以这个项目就夭折了。本文演示的是一个将代码配置化的平台。期望解决的是代码冗余,但同时也有效率的提升。 这个平台最终流程变成了这样: 开发 -> 测试 -> 发布 -> 验收 是的,由原来的11步直接变成了4步,其中开发和发布也比原来更简单了,你可以选择自己喜欢的编辑方式和开发框架,或vscode,或devtool,或工具提供的文本框,或jquery,或vue。可单独对css,js,html修改,将修改的内容直接提交即可看到效果。 为什么会减少这么多?因为没有了测试环境和uat环境的流转,直接在生产环境操作的。 是不是会有疑问——直接在生产环境开发会不会有风险? 答案是:不会!项目本身是分为两个环境,一个是开发环境,另一个是访问环境。开发环境是用于内部开发和测试使用,不对外开放,只有发布后才将开发数据同步到公开环境。 上图展示的是一个示例程序,提供一种思路,可根据自己需求开发相应功能。比如支持多环境发布,回滚,都可以做到点个按钮就行,不需要等待编译和重启等耗时。因为开发完成后的一切操作都是数据的操作,并不会涉及到编译,所以无论是发布还是回滚都是毫秒完成。 这种做法适合频繁修改的页面,万年不变的页面就不需要这样做了。 核心思想 这个项目的核心思想是将代码做成配置,我们都喜欢做配置平台,让业务来操作数据省去了修改代码,为什么不可以将代码也做成配置?

互联网产品体验分析

月盾
在寫產品體驗報告的時候,經常會陷入這樣的一個困境,即把體驗報告寫成了這個產品的說明書或者營銷文案,幾乎把這個產品的所有功能又複述了一遍,重點不突出。在網上看了不少的體驗報告,基本也都陷入了這樣的一個怪圈。很多人一上來就很宏大地開始架構諸如『產品定位』、『戰略發展』、『市場狀況』、『商業模式』、『產品結構』等字眼。 關於這樣的分析方法有不少問題。一方面是缺少足夠的信息來源。比如『商業模式』的決定是需要有不少的信息輸入作為參考的,而你又並非這個公司的人,憑著在網上搜刮的一點資料難道就可以做出決定嗎?另一方面時,研究一個產品的重心應該放在哪個方面?面面俱到的分析方法必然會失去重心。 對於這個問題,我自己的結論是:分析一個產品無需宏大整體的架構,只需要把自己當成用戶,問自己幾個問題即可。 這幾個問題是: 你會繼續使用這個產品嗎?( 第一關,該產品是否能繼續在該用戶的手機上存在。) 你會使用它的什麼功能?( 該產品給用戶提供了什麼價值。) 如果跟XX 擺在一起, 你會選擇哪一個?( 該產品的差異化優勢) 為什麼選擇這樣幾個問題而非宏觀地進行分析呢?這個問題可以從我們最近流行起來的幾個App看出端倪。無論是足跡和臉萌,都有一個很重要的特點,即它們的某一個功能很明顯地比其它功能要突出很多,甚至其它功能都不被用戶意識到,但是就這麼一個功能,就能使它們成為一個好的產品。也就是說,用戶在感知一個產品的時候,並不會去感知這個產品的整體,而只會關注一個問題:這個產品能幫助我什麼?如果這個產品的這個功能能夠為我帶來價值,就算其它功能都是雞肋,那留著也就留著吧,我不關心。 大多數玩微信的人不玩遊戲,也不關心『我的錢包』裡面豐富的服務,但不妨礙他們成為微信的重度用戶。 由此我們得出一個什麼結論呢?結論是:一個好產品可能并不遵守木桶理論,只要最長的那根木板足夠長,這個產品就足夠好。因此,當我們去分析一個產品的時候,我們應該分析這個產品的關鍵驅動因素是什麼?它最亮的那個亮點是什麼?它亮到什麼程度以至於我決定把這個產品給收下來而不是長按刪除。不要再寫那些長長的貌似很系統的分析報告了吧,我相信微信里的很多頁面你從沒進去過。 内容摘自知乎:http://www.zhihu.com/question/19851117