Slack & Jive-n

之前曾經開過一隻Slack來玩,幾有趣。
Slack定位是team collaboration site。又或者說,Slack是channel based platform。
最基本的玩法,你可以隨意create channel,好似chatroom咁。
但Slack的真正玩法是其豐富的integration plugin。
Integration plugin都是寫成bot的形式放到channel中。

例子:
把一個schedule meeting的bot加到channel中,
然後我問bot我什麼時間可以schedule到meeting,bot就幫我看時間空檔,提供選擇建議。
全部東西都是在channel裡做,而end user(我)要做的就是像在chatroom中問問助手(bot)。

其他例子:
用Slack bot自動build code﹑deploy﹑…etc

 

如果只是單單把東西做成bot,那value在哪裡?真正令Slack強大的地方是什麼?
有一篇文章講得不錯:
The REAL reason Slack became a billion dollar company (https://www.linkedin.com/pulse/real-reason-slack-became-billion-dollar-company-satya-van-heummen)

文章大意是說,Slack的channel是你要長期留意,否則你可能會lost了一些converssation。
Slack的東西某程度上塑造了你在公司的價值感﹑認同感﹑參與感。
而由於常常生怕miss了一些converssation,所以你會不知不覺間上癮。
最後,全部人都會留意Slack,而Slack就成為了公司/team的single source of information。

 

我看這文章的感想是:

Slack為一間公司/team 帶來的value在於帶來了一個single source of information platform。
Channel conversation + bot的玩法,可以很好地做到event-driven automation。
而因為可以做到event-driven automation,所以很多workflow其實都可以shift到在Slack上面去做。
慢慢地,Slack除了是single source of information platform,更加是single workflow platform,不同workflow之間更加互相緊扣。
日常公司/team做的應用流程,都只需在同一介面上與bot「傾計」就做到;
而相比傳統做法,去找某某網頁﹑send email﹑填form﹑……,要switch context,流程不統一繁複。
由於人們在slack上做到大部份公司/team所應用到的flow,所以他們stick to這platform,所以這更加令platform有很大內聚力,相輔相成。

 


 

話說後來我公司的Collaboration site都由tibbr轉了做Jive-n。
我都曾經想過與Slack比較的問題。
但其實Slack的成功可能主要適用於small-to-middle scale的company/team。
至於enterprise scale,say有5K人,我就不肯定Slack的solution能否依然apply得到。

我去reddit看過一些討論:
https://www.reddit.com/r/sysadmin/comments/4tf031/slack_corporate_environment_anyone_use_it_company/d5gsall
其實都有一些case是有50k員工的公司是轉用Slack而其評價是「It’s a critical business tool.」。
如果把5萬個員工放在一個big hall,其實是一個nightmare。
那位網民說他公司的做法是mirror org-chart structure來建構391條channel,不同team然後再有他們自己的channel。

但相對地,其實亦有一些case是adopt了Slack而最後發覺太多channel太亂而放棄的:
https://blog.agilebits.com/2016/04/19/curing-our-slack-addiction/
其中有一個reply comment說得很好:
「The basic problem I see is that people are using what is fundamentally a tool for synchronous discussions (everyone present at the same time) for asynchronous discussions (people are not expected to follow up immediately).
Asynchronous discussions require threads, unified inboxes etc. Unfortunately, the go-to tool for asynchronous discussions have too many flaws to count.」

 

其實Slack channel是一種synchronous discussions。
而相對而言,Slack就缺乏了傳統email那種asynchronous discussions。
而這方面比較之下,Jive-n那類collaboration product就做得比較好。

 

 

借鑑Slack的成功之下,Jive-n platform可以做好的是:
– 不單只是去想Integration with office 360/document,還要更進一步地去想如何更緊密地緊扣日常公司/team的workflow。
– 可以開放一些Jive-n built-in的REST API給員工,可以讓員工自己做到些automation之類的東西。
– 可以把一些workflow慢慢轉移到Jive-n platform之上,最好當然是可以做到某程度上的event-driven auotmation。

社運two speed

對左翼或本土派來說,其實也需要學習反省。

和理非非的一套抗爭model,是否能跟得上當下社會形勢?
形勢使然很難升級抗爭固然是現實,但假若他日形勢許可時,此model設的限制,能否comtatible with行動升級?
長遠來看,這model是把抗爭局限於一個被動抗爭狀態以內,還是創造著升級的空間?
左翼面應的問題,是upgrade compatibility問題。

本土派面對的問題是,在勇武之餘,也不能忽略和理性非非的一面發展。
本土派的抗爭model需要修正去掌握一套雙軌模式。

———————————————————

我自己是唔建議太執著於一種「和理非非vs勇武」either one的二元對立思維的。
香港傳統社運本身的問題不在「和理非非」,而是「只限於和理非非」。
社運發展出路應該是建構一種論述,是既compatible with「和理非非」文宣﹑低成本抗爭﹑儲人數,而同時亦compatible with行動升級。

題外講多幾句。
其實即係好似IT automation講two speed,都唔係either快or慢二元對立,而是重點在於快慢雙軌如何做好並行﹑互相帶動。
eventually d人終會明白「和理非非」同「勇武」其實就係two speed形態。
最終要做好件事,其實就是要做好雙軌並行﹑互相帶動。

Framework VS Platform

Framework就是框架。
你做了框架,出面developer以框架為骨幹去develop。
做Framework常遇到的問題是,你做了的框架,不是別人exactly想要的框架,但卻綁死了developer’s application的形態。
然後framework owner為了adopt change,又要把框架弄得flexible,但又很易簡單複雜化。

做platform其實會好些,
因為platform與application之間不是骨幹與實體的裡內關係,而是兩個應用層面的外在接洽。

實際技術層面角度去看這問題。
Framework往往是做SDK。
而platform可以是往一堆REST API的方向走。
application用framework是adopt SDK,增加了很多dependency﹑complexity。
application用platform,是用通用的HTTP protocol(主流都是) call REST service,很多東西都透過industrial standard串連起來,比較乾淨。

做platform的話,實際做的時候其實不應以做framework的心態一樣做給人用。
否則就會很易回到之前說過的問題:
「你做了的框架,不是別人exactly想要的框架,但卻綁死了developer’s application的形態。」
「為了adopt change,又要把框架弄得flexible,但又很易簡單複雜化。」

做platform的話,其實有些東西不應自己勞心。
盡量分拆成很多小型unit service API,提供一些局部的「可能性」﹑「小積木」。
platform只是提供一堆「可能性」,透過API去定義什麼可以做﹑什麼不可以做;然之後就交給application自己發揮。

對未來遊戲發展的FF展望

其實AR技術對Pokemon Go成功影響不大。有很多人其實也disable了AR來玩。
要說影響力的話,用真實地圖來做遊戲地圖的「AR概念」比起AR技術來得更大影響。
「AR真實地圖概念」的基礎,是開發商透過Ingress累積下來寶貴的地標data,也是其他遊戲開發商難以複制的。

我之前出過post講過一些遊戲發展的推測大約是咁:

1) 遊戲的發展會是先由現實輔助遊戲中的虛擬。
例如pokemon go,雖然用了現實地圖元素,但對玩家來說遊戲仍是在mobile device上進行。
遊戲的本位還是在遊戲機之中。

2) 之後隨VR/AR/3D投影技術發展的成熟,以及真實世界的各種大數據,會有些遊戲的本位由遊戲機(包括mobile)轉移到現實。
那時候玩那些遊戲,玩家不會低頭打機,而是望住現實世界周圍黎玩。
遊戲指示會投射在現實的牆上/地上,遊戲的場境會投射到周圍,或者透過輕便的AR眼鏡來實現。
簡單的作比喻,可以想像下遊戲王卡通那種模式。

3) 之後其實很遠,但我自己FF想像的話就是,VR/AR技術+念動力操縱。
遊戲能透過玩家腦電波控制操作input,而透過一些virtual-bio-feedback令玩家得到虛擬而真實感很強的生物訊息。
玩家真實地感覺到自己在跑動﹑攻擊﹑進行各種動作,但實際上只是在坐著FF。

但如果真係有日viable,其實除了遊戲還有很多其他用途:
1) VR-sex,remote-sex。
2) 制作真正的3D電影(你可以在電影場景中走動)。