Cloud Card是否能幹掉App
阿新 • • 發佈：2017-05-22
服務 又是 自主 fill dsm div 發的 系統 二維
算下來有一年沒寫blog了。這一年算是潛心做一件事情，隨著雲OS 3.0已公布。總算能夠向外界表達了我們想做個啥，非常多人也開始質疑，Cloud Card究竟是個啥？雲OS 3.0算不算自主研發的OS？等等，今天想就Cloud Card是否能幹掉App這個主題聊聊這些事情。
昨天三豐和我們開會講到一個觀點。IOS&Android以App為核心的OS過時了，用戶使用各種移動設備，要的不是App，是服務，盡管App也是承載服務的形式，但App與App之間是割裂的。
雲OS3.0公布會我們把理念拋了出來，以下這個架構圖還是非常受大家認可。
但從一些媒體試用反饋來看，感覺還是停留在一些粗淺的層面，沒有真正領會到Cloud Card真正想做的事情。可能因為眼下的交互形式。大家都把註意力放在首頁的入口卡片上，也就導致大家重點去比較H5和App的體驗，這事實上是一種誤解，我們想表達的不是H5的體驗比App能有多好，我們從不否認就眼下看來H5還是比不了App。Cloud Card假設僅僅是一個H5服務的入口。那我所說不論什麽觀點都是不成立的。我們真正想表達的也是眼下已做到的能夠看看以下這個樣例： 
這個樣例事實上是用戶一個真實的用戶場景： 1）用戶要出差，買了一張機票 2）收到出票短信（或是其它通知方式） 3）系統自己主動轉為機票卡片 4）環繞趕飛機出差這個用戶場景。系統推薦各種關聯服務，比方在線值機、預約打車去機場、目的地天氣等等 5）用戶使用在線值機後直接在卡片生成值機二維碼 6）飛機起飛前幾個小時，鎖屏上出現飛機票提醒 7）直接從鎖屏上呼出飛機票，掃描二維碼過安檢
用戶的需求非常easy。就是要一個趕飛機的服務，要完畢這個服務假設換成App，大家想想須要哪些App，攜程機票、快的、墨跡、高德、國航值機等等，關鍵是這些App之間是割裂的。用戶須要在各個App間來回切換，填參數，用完這些App嫌多了還要刪掉，對於一些老人家，哪知道要用這些App。我們做的事情事實上非常easy，通過OS的能力，盡可能的覆蓋用戶的日常生活點點滴滴，通過Cloud Card的形式匯集用戶一個個場景。然後基於這些特定的場景。讓第三方服務作為關聯插進來。滿足用戶特定的需求，用戶使用後又是一個新的場景。又會有針對新場景的關聯服務，從而形成閉環。
小小的Cloud Card的價值是顯而易見的。對於終端用戶來說，它讓僅僅需關註要做的事情，將使用服務的門檻和交互成本降到最低；對於第三方服務ISV來說。提供了一個個實際的用戶場景。使得提供的服務具有非常高的到達率和點擊率。
這僅僅是我們眼下做到的程度。論證了可行。但僅僅是開了個頭，遠遠不夠。我們後面真個OS團隊都會環繞著這個Cloud Card發力。
每件事情都有足夠的挑戰，但都是清晰可見和具有誘惑力。也須要很多其它的同學增加進來。眼下僅僅是一點點曙光而已，過了生死年，才幹看到明天的太陽。魅族、飛利浦.....一個個優質的手機廠商增加進來，一切就好玩了。
眼下看來，團隊規模遠遠不足以去完畢這些事情，須要各方有興趣的同學哥們增加進來，假設你理解了我們要做的事情。感興趣，而且感覺自己能在當中做點事情。請聯系我：[email protected]（不太方便放公司郵箱）
當然也請容許我說明一下職位情況。工作地點在杭州，公司是阿裏巴巴雲OS。職位有Java服務端、Androidclient、架構師、H5前端、OS底層等等，Head Count無限。
再次回到這次主題，Cloud Card是否能幹掉App事實上不重要。重要的是用戶能忽略這一切。
昨天三豐和我們開會講到一個觀點。IOS&Android以App為核心的OS過時了，用戶使用各種移動設備，要的不是App，是服務，盡管App也是承載服務的形式，但App與App之間是割裂的。
細致想想確實如此，我們如今為了做一件事情往往須要多個App來回折騰。用戶裝的App越來越歸一到幾個航母App（微信、淘寶、支付寶），航母App越做越大，上面集成各種其它第三方服務。比方公眾號。用戶使用移動設備有時需求事實上非常easy，僅僅想買一張電影票或者充話費，而且是非常暫時性的，假設這時你要他去找個app安裝，用完後刪掉。體驗確實不好，web幹掉PC端應用程序也是出於這個初衷，用戶要的就是一個買電影票或者充話費的服務，而不是一堆的App。於是乎我越發明確自己所做事情的價值，也明確為啥我們敢稱為自己是在做OS。把用戶須要服務在用戶真正須要的時候提供給用戶，這件事情僅僅能OS來做，也僅僅有在OS這個層面上才做得好，當然。有些航母App也在做這件事情，但它們畢竟僅僅是App。做不了OS能做的事情。回到今天的主題，Cloud Card是否能幹掉App，新的操作系統都有標誌性的符號，比方IOS帶來了App，Android帶來了通知中心，那麽雲OS想給大家帶來的符號就是Cloud Card。
理念就是通過Cloud Card這個唯一的符號。把用戶須要服務在用戶真正須要的時候提供給用戶，僅此而已。假設真正能做到，我相信今天的論題是成立的。
雲OS3.0公布會我們把理念拋了出來，以下這個架構圖還是非常受大家認可。
但從一些媒體試用反饋來看，感覺還是停留在一些粗淺的層面，沒有真正領會到Cloud Card真正想做的事情。可能因為眼下的交互形式。大家都把註意力放在首頁的入口卡片上，也就導致大家重點去比較H5和App的體驗，這事實上是一種誤解，我們想表達的不是H5的體驗比App能有多好，我們從不否認就眼下看來H5還是比不了App。Cloud Card假設僅僅是一個H5服務的入口。那我所說不論什麽觀點都是不成立的。我們真正想表達的也是眼下已做到的能夠看看以下這個樣例：
這個樣例事實上是用戶一個真實的用戶場景： 1）用戶要出差，買了一張機票 2）收到出票短信（或是其它通知方式） 3）系統自己主動轉為機票卡片 4）環繞趕飛機出差這個用戶場景。系統推薦各種關聯服務，比方在線值機、預約打車去機場、目的地天氣等等 5）用戶使用在線值機後直接在卡片生成值機二維碼 6）飛機起飛前幾個小時，鎖屏上出現飛機票提醒 7）直接從鎖屏上呼出飛機票，掃描二維碼過安檢
用戶的需求非常easy。就是要一個趕飛機的服務，要完畢這個服務假設換成App，大家想想須要哪些App，攜程機票、快的、墨跡、高德、國航值機等等，關鍵是這些App之間是割裂的。用戶須要在各個App間來回切換，填參數，用完這些App嫌多了還要刪掉，對於一些老人家，哪知道要用這些App。我們做的事情事實上非常easy，通過OS的能力，盡可能的覆蓋用戶的日常生活點點滴滴，通過Cloud Card的形式匯集用戶一個個場景。然後基於這些特定的場景。讓第三方服務作為關聯插進來。滿足用戶特定的需求，用戶使用後又是一個新的場景。又會有針對新場景的關聯服務，從而形成閉環。
小小的Cloud Card的價值是顯而易見的。對於終端用戶來說，它讓僅僅需關註要做的事情，將使用服務的門檻和交互成本降到最低；對於第三方服務ISV來說。提供了一個個實際的用戶場景。使得提供的服務具有非常高的到達率和點擊率。
針對ISV我還想多說兩句，對於高德和百度地圖兩個服務，假設僅僅是放在桌面上。從眼下情況來看，大部分還是會用百度。但假設高德把導航服務插到機票關聯服務中，直接提供給用戶到達機場的導航，那麽用戶肯定就不會再挑了，由於這種操作路徑最短。
這僅僅是我們眼下做到的程度。論證了可行。但僅僅是開了個頭，遠遠不夠。我們後面真個OS團隊都會環繞著這個Cloud Card發力。
眼下最緊急要做的三件事情：
1）把每一個場景做精做透。給用戶最好的體驗，真正做到他僅僅需關註要做的事情 2）讓Cloud Card在整個OS和相關終端上流轉起來，覆蓋用戶生活的點點滴滴 3）搭建開放平臺，把用戶場景開放出去，把第三方服務接進來每件事情都有足夠的挑戰，但都是清晰可見和具有誘惑力。也須要很多其它的同學增加進來。眼下僅僅是一點點曙光而已，過了生死年，才幹看到明天的太陽。魅族、飛利浦.....一個個優質的手機廠商增加進來，一切就好玩了。
眼下看來，團隊規模遠遠不足以去完畢這些事情，須要各方有興趣的同學哥們增加進來，假設你理解了我們要做的事情。感興趣，而且感覺自己能在當中做點事情。請聯系我：[email protected]（不太方便放公司郵箱）
當然也請容許我說明一下職位情況。工作地點在杭州，公司是阿裏巴巴雲OS。職位有Java服務端、Androidclient、架構師、H5前端、OS底層等等，Head Count無限。
再次回到這次主題，Cloud Card是否能幹掉App事實上不重要。重要的是用戶能忽略這一切。
Cloud Card是否能幹掉App