視覺設計原則:Salience – 凸顯

 

The fact of being important for or connected with what is happening or being discussed of     — definition from Cambridge Dictionary

視覺設計原則中,如何去“凸顯(salience)”重要的要素,是其中一個技巧。其目的便是能創造合適的對比,讓觀看者能快速地看到局部的特徵。

Points Of View : Salience Fig1
salience through visual features

從這篇Nature methods的文章Fig1-a,可以發現一眼望去,符號A相對於P,很容易就被看到,這樣的設計就是所謂的凸顯,可以使用顏色、大小、方向、形狀、標記、動作、分組的方式去達到這個目的。

凸顯的目的有二:

第一個,降低觀看者的認知負擔,減少其找尋到特定特徵和意義的時間,適合在像是簡報或是海報等,觀看者同時還在聆聽資訊,兩種感官在競爭觀看者的注意力。

第二個,加快使用者理解較複雜圖形的意義,以便理解設計者進一步疊加在視覺表達上的意義。

Points of View: Salience Fig2
Visual conjuctions

從Fig2的真實例子可以發現,如今的資料複雜度是越來越高的(所以視覺化設計的能力便需要提升),往往想要在一張圖中,放入多維度的意義,這樣就無法良好的凸顯想要傳達的一系列訊息,實際上,可以用Fig2-b的方式,有效地且次序地表達到想要呈現的資訊。這類的圖片通常需要觀者去執行所謂的Visual conjuction的搜尋(看圖標,然後進而去主圖中搜尋),當圖標過多種,此時就達不到良好的突顯,讓使用者找尋特定資訊和理解的時間增加。

 

閱讀參考:

Bang Wong(2010). Points Of View: Salience. Nature Methods
Ware, C. Visual Thinking for Design (Morgan Kaufmann Publishers, Burlington Massachusetts, USA, 2008).

視覺設計原則: Gestalt Principles

「gestalt」的圖片搜尋結果
Fig from WiKi

Gestalt principle是在1920年代被德國心理學家們(格式塔學派)所提出的人類視覺感知理論(Perception theory),Gestalt這個字是德文的形狀之意,這原則是用來說明人類如何去理解所看到的東西,並將其編碼成資訊。如今這理論可以反向用來做為各種視覺設計的原則,幾乎在平面設計、網站設計、前端設計、簡報設計等等會需要使用者“看”的領域,都有很重要的角色,比如Google Design這部談論設計的影片

Gestalt is the interplay between the parts and the whole. … The whole is ‘other’ than the sum of its parts          

而藉由設計平面上的物件根據這些原則便能添加多一層的資訊給與觀看者。

跟視覺設計有關的這些原則是什麼呢?

這邊我們來介紹一些跟"Grouping"概念有關的原則:相似性(Similarity), 相近性(Proximity), 連結性(Connection),包覆( Enclosure)。以上這四個原則會影響觀看者如何將獨立物件間做分群,

相似性(Similarity)

在閱讀或是觀看者會把外觀相似的事物歸類成同一個類別,會是認定它們間有所關聯,這特質算是我們人類蠻直覺有的視覺理解方式,所以利用相似性原則,我們圖形處理上,利用字型、顏色、物件方向和白色等等來創造視覺上的關聯性。

相近性(Proximity)

相近性的特質是利用空間上的相鄰,把物件關聯再一起,這特性可以讓我們用來安排如論文的圖片排列方式,用來控制觀看者的順序,比如有四張圖,我們希望觀看者兩張兩張的看,那麼經由排列的方式,兩個一組,組間間距加大,便能直覺上使用兩組兩組的看。

連結性(Connection)

相對於相似性、相近性的關聯效果,直接將兩個有關連的物件直接連結(最簡單的方式就是用線相連),可以直接且強烈的把兩個可能有距離或是外觀沒那麼相似的物件,釋放給觀看者兩者間可能有其他關聯性。

包覆(Enclosure)

包覆便是直接將同類或是想強調的物件們,用圖形包圍成塊,這種視覺暗示的方式力道非常強。

原則間效用的大小

下面這張由Bang Wong文章裡的圖,清楚的讓人理解到這些原則間在視覺上創造的效果,彼此間的強烈程度。

screenshot.png

閱讀參考

來自Nature Methods education series Points of View,超棒的系列!對於生醫研究者對於資料視覺化有一定的幫助!
Bang Wong.(2010). Points Of View: Gestalt principles(Part 1/Part 2). Nature Methods

網路上介紹Gestalt principle在網站或是前端設計的文章

Cognitive psychology for UX: 7 Gestalt principles of visual perception
Gestalt Principles for Designers – Applying Visual Psychology to Modern Day Design
User Experience (UX) topic overview/definition :Gestalt Principles

搭建多層式網絡視覺化(visualization of the multilayer network)模型: 使用three.js, d3.js , Lodash 和observable(ㄧ)

screenshot.png

 

用多層次網絡(multilayer network )視覺化多組學資料

最近花了些時間把之前多組學(multi omic)資料分析的結果,往下延伸去做資料視覺化已呈現一些insights,到底該如何呈現一些複雜的觀念,來把高維度的資料,簡化成人眼有感覺的事情(好難啊!),整合了基因調控、基因產物間的互動和基因集的資料,當然,無法只用一張圖來說清楚一整個研究的思維,但總是希望能如提高Edward Tufte所說的data-ink ratio可參閱這篇 ),所以過程等於是一個打掉重做打掉再重做的過程

這設計其實是想要打破單純simple network的問題,因為回答或是用數據來解構生物問題時,常常會有不同層次的系統交疊,如今許多高通量的資料,他經過註解後,其實資料的維度是很高的,會需要用multilayer來把複雜性降低,以便讓想呈現的模式呈現,於是便需要用到multilayer network來架構這樣的multi-omic資料(可參閱這篇),不過話說,在多層次網絡這框架下,其實還很新,所以如何去設計layout背後的演算法,是個新的世界。

解決跨層間連線(between layer links)的視覺化問題

在keep simple的原則下,原本希望用css的transformation特性和d3.js就能完成這最初版本的多層網絡視覺化設計,但後來鑽研許久,把css 裡面的translate3d, rotate3d, perspective等特性來用在由d3.js產出的svg上,從實踐端踩了一遍,遇到蠻多有趣問題的(怪蟲xd)。關鍵在做“跨layer間的線”時會遇到很大的問題,其中一個關鍵是css 在做出3d效果時,所謂z座標的實現化,似乎是處在一個黑盒子,假如要完全模擬出來3d效果,其實就要重新用js改寫這些函數,來自己做這些座標的轉換,因為這樣做有點“重做輪子”的感覺,於是就硬者頭皮進入到webGL的領域,也就是原生的3d世界。

使用three.js來入手webGL的3d世界

老實說,three.js比d3.js更容易入手,這一點超乎我的想像,不過相對於d3.js在data-driven這一塊的設計,three.js就要自己重造視覺模塊跟資料的關聯,畢竟他其實不是為了“資料視覺化”(data-driven)而出現,是為了3d動畫、webVR而出現,但至少光3d的座標,就可以讓我直接使用(x,y,z)來做跨層間的資料處理,省下了一層功。另外,three.js也讓我看到了另外一種可能,因為在d3.js的操作下,很容易遇到速度瓶頸,尤其是在超複雜的視覺化上,速度會到一種慢到想哭的地步,每次render都要花到3-5分鐘,three.js則因為可以使用gpu來做視覺處理,皆有所謂的buffer設計,所以這特性可以好好用來做一些加速使用,甚至GPU運算。

用Observable來做快速prototyping

Mike Bostock新開發的Observalbe工具真的很棒,無痛版的jupyter,且越用越覺得他設計理念很棒,Observalbe基本上可以讓你直接使用各種js library,在上面邊寫邊摸索,且他引入蠻多interactive的概念,所以你可以設計一些reactive的參數,來調整資料,尤其在3d的世界中很重要,你通常要藉由直接嘗試來找到適當的呈現角度。

screenshot

可以看到observable notebook裡面可以設計滑動的參數,來調整觀看角度,因為three.js設計的方式,你會需要設定觀看角度的各種參數,所以使用這互動性的設計就能快速找到合適的觀賞方向。

D3.js的d3.simulation來提供network的layout

screenshot.png

可以看到最頂層的那個網絡是有layout的,這個layout便是使用d3.js 的d3.simulation來做背後計算的,當然這就會產生一些資料延遲的問題,這部分之後詳細分享。

文獻閱讀:哈里遜內科學第3章 臨床決策的認知模型

這章節是由Daniel B. Mark(Duke University Hospital)和John B. Wong(Tufts Medical Center)兩位醫師所合著的,在談論臨床推演思維,如此飄渺的主題談論得深入淺出,且把臨床的認知推演模型描述得非常清楚。
要如何定義一位臨床高手呢?(這篇的重點便在談論如何解構一位高手臨床醫師的思維,所以便需要起手來一個定義)
這個問題很難回答,目前也沒有很好的方法可以來做評比,實際上,的確會有少數臨床醫師常被當其他醫師遇到困難案例時作為諮詢對象,但這些臨床醫師高手也無法說清楚,且實際上臨床能力(clinical virtuosity)也無法一概而論,通常每位醫師都會有專精的地方,厲害的眼科醫師可能連簡單的血壓都不會處理,反之亦然。
當代在探討推演思維的模型最常使用所謂的dual-process theory來做,也就是系統一(快思考)和系統二(慢思考),這邊借用來架構臨床思維的推演,可以簡單把臨床上的認知思維模式分成快思考和慢思考兩類,這邊主要談論的是關於疾病診斷上的思維方式。
 系統一(Intuition)快思考,主要是由模式辨認(pattern recognization)所來,有可能造成所謂的premature closure,過早地對於病人的症狀做結論而忽略了可能的問題所在,模式辨認這種認知模式可以稱為heuristics(cognitive shortcut or rules of thumbs),可以簡單分成四類:
  • representativeness heuristics
    • 定義when assessing a particular patient, clinicians often weight the similarity of that patient’s symptoms, signs, and risk factors against those of their mental representations of the diagnostic hypotheses being considered.
    • 將看到的案例跟腦海中的舊案例比較後,取出較類似的案例出來
  • availability heuristics
    • 定義involves judgements based of how easily prior similar cases or outcomes can be brought to mind
    • 將看到的案例後,腦海中第一個跑出來的想法和案例
  • anchoring heuristics (conservatism or stickiness).
    • 定義 involved estimating a probability of disease and then insufficiently adjusting that probability up or down when interpreting new data about the patient
    • 將看到的案例,依照之前最常碰到的案例來處理和思考
  • simplicity heuristic
    • 定義use the simplest explanation possible that will accout adequately for the patient’s symptoms or findings
    • 用最簡單的方式來解釋

除了套用簡單的認知模型來解釋系統一在臨床上演繹的種類,認知科學家發現臨床醫師在面對複雜問題時,會採用分析推演的方式(Analytic reasoning processess),或者稱作Hypothetico-dedutive model,藉由不斷假設,然後推翻,經過一連串所謂的"Diagnostic imperatives",是常使用的策略來面對那些不常發生的診斷或是確立最終問題根源的方式(所以常會在SOAP中看到需要rule out 什麼,這便是一種所謂的Hypothetico-dedutive model)。

資深臨床醫師常會將資料分成幾組,且儲存在工作記憶,用此來做各種分類和模式辨認。醫師通常藉由刻意的建立大群相互關聯的知識網,來提高其對於各類症狀、機制等等的連結。
Elaborate conceptual networks of memorized information or models of disease to aid in arriving at their conclusions. expertise involves an increased ability to connects symptoms, sign, and risk factors to one another in meaningful ways, relate those findings to possible diagnoses, and identify the additional information necessary to confirm the diagnosis.
未來的醫師更有機會且更容易接觸大量的資料,但能不能因此而快速成為專家等級的臨床醫師,還是需要花時間建立自己的external internalized database of knowledge and experience not available to novice.
increased attention is now being paid to understand how best to adjust group-level clinical evidence of treatment harms and benefits to account for the absolute level of risks faced by subgroups and even individual patients, using validated clinical risk scores.

 

《刺胳針》期刊觀點 : Improvising Medicine – cultivating ensemble

screenshot.png

這是《刺胳針》期刊上的觀點專欄,是看到Eric Topol在Twitter上的轉推,優美的一篇文章。

Improvise, Verb 在劍橋字典上的定義:

  • to invent or make something, such as a speech or a device, at the time when it is needed without already having planned it
  • When actors or musicians improvise, they perform without prepared speech or music, making up the play, music, etc. as they perform it.

閱讀的時候也是蠻困惑什麼叫Improvising Medicine,難道是即興的治療嗎?那不就是等於隨便治療,原來他想表達的是醫療場域中各領域人員的合作就是一場即興表演,但在醫學教育中往往知識的記憶,技術的演練變成核心,但假如用爵士表演來比喻,那是在練習樂器的聲音本身。

Cultivating ensemble

作者Roger KneeBone醫師提到將醫療場域的行為,類比於爵士樂,是閱讀到一篇2007年由醫師同時也是爵士史愛好者Paul Haidet所寫的:

how jazz musicians become expert in “cultivating ensemble"(working with a team), “creating space" for the music to unfold, and “developing voice"(a fresh and original sound)

作者提到其外科訓練過程中,往往專注在手術的技術習得上,但直到其行醫多年後,才慢慢理解到不能只沈浸在自己的“手術”,還要在意團隊成員在做什麼,適時的保留空間,讓其他人發揮。我想這段想法其實可以拿來用在團隊合作,關鍵在留給別人空間,而非只關注在自己想要的事物上。

The confidence and stability only emerged from a long period of uncertainty, and trying on multiple identities before settling on one that worked.

閱讀參考:

Kneebone, Roger. Improvising medicine. The Lancet , Volume 391 , Issue 10135 , 2097

 

 

探索資料庫應用(二):Taiwan Biobank台灣生物資料庫計畫

台灣生物資料庫計畫是2012年開始的大型資料收集計劃,針對台灣人年紀在30-70歲之間的對象收集健康醫療資料,收集據點遍佈全台灣,第一波收集的方式主要向社區招集自願的民眾,用醫療卡車的方式來吸引民眾去貢獻自己的資料,第二波則是面向各醫學中心,針對十二項慢性疾病為目標,來招募患者。

screenshot.png

screenshot.png

第一波一般民眾預計招募20萬人。

這些個案會追蹤骨質疏鬆狀態、消化系統(腹部超音波)、甲狀腺(TSH, T3, T4, free T4)、心血管疾病(頸動脈超音波)、心電圖(心電圖)。檢體方面,則收集了血液、尿液。比較特別的是還做了各種完整的基因體資訊從基因晶片、甲基化、HLA分型、次世代定序等,是非常完善的資料。

第二波針對特定疾病

十二種疾病分別是肺癌、乳癌、大腸直腸癌、肝癌/肝炎、頭頸癌、心臟血管疾病、糖尿病、腦中風、阿茲海默氏症、氣喘、子宮內膜異位、慢性腎臟疾病),與台大、北榮、北醫、三總、中榮、中國醫、中山醫、彰基、成大、高醫、高榮和慈濟合作,預計招募10萬人。

Taiwan BioBank 開放基因資訊瀏覽器

目前台灣生物資料庫有架設基因資訊瀏覽器,方便去觀看目前的一些基因體資訊,網站功能蠻方便的,可以選擇資料來源的技術(illumina, Ion Proton, Affymetrix array),使用染色體位置或是基因區段來瀏覽資料。screenshot.png

 

screenshot.png

 

 

可申請的檢體種類

目前可以申請的檢體種類有尿液、血液,相關的資料可以有問券資料、理學檢查資訊、實驗資訊(各式基因資訊)。

screenshot.pngscreenshot.pngscreenshot.png

資料來源:
台灣生物資料庫計畫 沈志揚、楊壹懷、褚候維

書籍閱讀:Being Online在線-數據改變商業本質,計算重塑經濟未來

 

愛迪生發明了夜生活

screenshot.png

這算是本老書,在2016年出版的,去年2017年底商業周刊重新發行了繁體版,稍微更訂了內容。作者是王堅,再加入阿里巴巴之前曾任微軟亞洲研究院常務副院長、杭州大學、浙江大學心理系教授、博士生導師兼任主任,再加入阿里巴巴後從一開始擔任首席架構師到現在阿里巴巴集團技術委員會主席。

這本書在用一個非常寬廣且初心的方式去闡述這世界因為網路而造成的改變,其中在談“在線”這件事情對於人類的影響。

這邊有關於王堅的演講視頻在騰訊大學裡分享技術領導力的影片

2016年的氛圍大都在談論“大數據”,而此本書便是在這樣脈絡下撰寫的,現在閱讀起來完全不會讓人感受到“不受用”,對比當下在“人工智能”的氛圍,其實這本書談論的“在線”更加本質,的確是可以幫助自己以更高的角度來看當下所處的時代。書中寫道:

在線,需要以世紀這一時間單位來度量,來進化,來討論

從數字到在線的進化

有了網路之後,許多事情影響力都放大了,不論是生產連接器的公司、戰亂地區的極端事件影片之散播、地圖從傳統數據轉成在線地圖,到把研究論文放置到arxiv網站的數學家,維基百科對比於大英百科全書,“連接”這件事情在本質上跨大了單點的影響力,且賦予了新的意義。以前獲取5000萬用戶需要50-60年,而如今的時代一個服務要獲得一億用戶,可能只需要兩年的時間,一個人能用好雲計算公司的服務,哪怕只有一個人,也可以擁有10000人公司的計算能力。

從信息到數據的進化

數據比功能重要

在互聯網的時代,數據才能帶來不可替代的社會價值,用數據去解決一個今天已知的問題,那部匯市數據最大的價值,頂多只是眾多價值中的一部分,數據可以讓你看到你還不知道的問題,同時幫你解決這個問題。為何數據比功能還重要呢?王堅舉了三個例子:(仔細思考,會發現這邊可以用另一個角度來看,可以參W.Brian Arthur的書The Nature of Technology,如何去看待到科技)
1. 伽利略的望遠鏡:讓人們可以觀察地球以外的世界
2. 顯微鏡:讓世界可以開始理解微觀世界
3. 雷達:讓現代戰爭成為數據的戰爭

如何讓在線的數據成為可能,要先有成熟而令人信任的雲服務,此時所謂的大數據才能開始奠基,而在線的數據緊接者有另一個特點,來加速其擴大,便是利用開放與分享的特性,開放不是免費,開放的關鍵在於原則上大家處於平等的關係,分享的重點則在於資源不會那麼容易被獨佔,壟斷變得非常困難。這一章感覺是在埋阿里雲的理念,假如未來數據是最具價值的,而這些數據是以在綫方式存在,那麼阿里雲的存在,好比銀行在上個世紀的角色,所以阿里雲必須在這個點上努力爭取讓使用者對其的信任。

從計算機到計算的進化

事物之間的區別,有時候不是由它的物理型態決定,而是由他的服務形式決定

這章談的是將雲計算的普及會遭遇的障礙類比於電力系統普及的過程,以前沒有大型電網系統的時候,人們需要用發電機來支持自家的電力供應,當特斯拉用交流電的方式發展大型電力系統時,曾經造成人們的恐懼,如今電力之於人類,就像是服務一樣容易取得,而計算有一天也會脫離所謂的計算機,變成人們唾手可得的服務一樣。

這章最後談了一個關於電影院與空調兩個事物,相輔相成的例子來談雲計算普及後,將只是未來變革的其中一個化學反應,而另一個就是各行各業的應用場景。

兩樣東西的結合,可以產生化學反應從而誕生新的東西。雲計算就是化學反應的一部分。

“過去看電影,只能晚上看,因為天黑了才能看清影像;另外,看電影還得冬天看,如果是夏天,門一關,一堆人擠在電影院裡面,會熱壞的。

1925年,威利斯。開利(Willis Carrier)說服派拉蒙電影公司在紐約時代廣場新建的李沃立大劇院安裝空調系統,承諾能為其觀眾提供涼爽的空氣。劇院開張時非常成功,人們紛紛湧向劇院,空調變得和電影本身依樣享受空調就是在電影院裡面。五年內,全美300多家影院安裝了空調系統。”

App很好,Web更好

我感覺App裡面是長不出亞馬遜叢林的,但是互聯網上可以找出雅馬遜森林,Web上也可以

這章從APP系統談到Web世界,主要在談阿里自主研發的YunOS,其大概的開發始由,緊接者則是談論所謂線上和線下的融合,關於生活因為在線後邊界的改變。

推薦閱讀:

王坚博士,那个行走于现在与未来之间的大顽童 | 二叉树视频

初探系統設計概念:基本流程、需求

閱讀Ray Dalio那本時,腦中印象深刻的是“計劃(設計)永遠優先於執行”這句話,畢竟在推崇執行力至上的社會氛圍,常會把花很多時間在設計及思考的行為認定為守舊和保守,但在某方面來說,我更相信經典背後的智慧如:"人無遠慮,必有近憂",這恰恰呼應了Ray Dalio提到的,這算是在“認知模式”層面的想法,鐵定可以套用在各領域,比如專案管理或是產品開發,甚至是這篇想要分享的軟體工程概念(不在文章標題寫上"軟體工程",是希望….這篇的觀念是可以用來在更高層次來活用的)。

軟體工程是門頗有趣的學科,會發現裡頭其實藏了很多不確定性,甚至可以說是在工程學門裡加入人文色彩。另一方面,這套想法其實也能套用在做其他事情,規劃研究計畫、解決日常問題、臨床問題的處理,其實都能把這些做法稍稍修改套用進去。

傳統的軟體開發:瀑布式開發Waterfall

瀑布式開發,可以想成是為了“一次成功”的開發方式,從客戶需求到完成成品,一次完成。這方法在過往非互聯網時代,開發桌機軟體時,頗適合的,因為使用者的反饋慢,需求變化少,產品週期慢。

瀑布式開發最簡單的流程如下
Requirement => Design => Implementation => Validation => Operation/Maintenance

顧聞思義,一步步地從定義需求、設計軟體架構、小代碼實踐、驗證、操作和維持,在以往的桌機軟體就是以這種模式來進行的,當然,隨者業務的變化特性,鐵定會有不同變形存在,比如 V-model/ Sashimi Model/ RUP model/ Incremental Model/ Spiral Model。

敏捷開發(Agile): 更多偏向心態(mindset)的轉變

如此,隨者軟體使用者的情境改變,開發和產品週期變短變快,所謂的敏捷開發(Agile)概念被提出來,而敏捷開發談的是開發時心態的改變,而非一套死板的實踐方法,強調短週期開發閉環,如scrum開發,其實就是建立在敏捷開發上的實踐版本。

許多的基於這框架下的想法和觀念被提出,其實核心思想都在思考如何在新的開發和產品週期特性下,組建適合的團隊和心態:
1. Lean startup
2. Design thinking
3. Project Aristotle Google
4. Growth Mindset
5. Dan Pink Drive
6. Autonomy Mastery Purpose

 簡單來說,就是以漸進式地方式演化和迭代,且盡量每個週期能得到最終使用者的意見回饋,而團隊的建立也必須有良好的內在激勵方式和讓團隊成員有能犯錯的安全感。

開發起手式:需求與規格 Software Requirement Specification

就像任何計畫的關鍵是訂立目標,而軟體的構建是為了滿足需求,和特定規格,所以軟體工程的第一步確立需求和規格。在釐清需求以及規格的過程,是以問題導向為主的方式,這過程會建立清楚地描述,來區分什麼是所設計系統要符合的要件,用什麼判斷設計出的系統是對的還是錯的,而其中會產生出文檔,就是傳統所說的SRS文件,這件事的重要性在於釐清了需求和規格,才能在經濟上去估算成本,以及工程實做面去降低支出。

需求規格文檔其撰寫的對象有兩個,或者說是兩類語言,一個是用使用者所熟悉的語言(需求),一個則是開發者的角度(規格),而通常還會有一部分所謂的non-functional requirement,就是無法歸類在使用者的需求或是根據與此衍生的規格,可分三類:

1. Product Requirement:可能產品大牛有特定的想法,作為開發時候的方向
2. Organization Requirement:在公司內開發的話,會有針對現有使用技術的規格
3. External Requirement:比如醫療軟體上會有法規的要求

而是否有好用的模型可以用來分析需求或是規格呢?那WRSPM model算是蠻傳統好用的

screenshot.png

如同這模型所顯示的,右邊的系統是我們要設計出來的,而左邊則代表真實世界(或社會環境),需求來自於社會環境,而規格則是藉由理解工程的人理解需求後對應出來的。

閱讀參考:

Software Development Processes and Methologies

TED: Dan Pink 出乎意料的動機
What Google Learned From Its Quest to Build the Perfect Team
Managing the risk of learning
Automony Mastery Purpose

康威法則Conway’s Law: 人與系統和功能的關係

康威法則(Conway’s Law)在看極客邦楊波對於架構的介紹時提到的,任何組織所設計的系統架構最終都會反應其組織內的溝通架構。

Any organization that designs a system (defined more broadly here than just information systems) will inevitably produce a design whose structure is a copy of the organization’s communication structure.   

——Melvin Conway, 1967

 

讓人與人和機器與機器工作時,溝通效率和開發效率變成一件很重要的事情,這讓我聯想到人體這複雜系統,似乎也是如此,“how cool it is!!”,我們有各種器官,而器官的組成細胞功能都緊緊扣緊其最終要提供的功能,來看看肝臟細胞:

「liver cell」的圖片搜尋結果

哇喔!很美的組織架構吧!假如細胞是一個人,那麼這組織非常有效率地構築了這個器官!在肝臟裡面的細胞,不會跟肌肉細胞一樣,果然很多事物的原理其實都有那麼共通的法則,之餘生物,當然也之餘人類社會。cool!

反之,康威法則也讓我聯想到,當細胞數量很少(員工很少時),就不要把系統架構弄得太複雜,如同人類胚胎組織在發育的過程,細胞的可塑型強,也就沒那麼需要有層次,區分說哪個細胞要幹什麼,逐漸逐漸地隨者胚胎變成一個人類,架構也就這麼演變成非常複雜,隨者功能需求的改變,所以公司成長之於細胞發育原來是有那麼一點的相似。

來看看這由Manu Cornet所繪製的組織架構圖,是不是有那麼一點跟他們的產品性質很像呢!

“正經"的相關閱讀:

youtube

Hacking Conway’s Law – Raffi Krikorian

部落格

楊波 每個架構師都應該了解一下康威法則

Apply Conway’s Law

康威定律:這50年前都提出來的概念你聽過嗎

 

簡介 快速健康照護互通資源 (FHIR)及相關學習資源

HL7-FHIR快速健康照護互通資源(FHIR)是HL7組織所推出貼近移動醫療的資訊交換標準,關於HL7的介紹可以看這兩篇之前所撰寫的Health Level 7(HL7)研究筆記:五大基本架構, 健康資訊交換第七層協定(Health Level Seven):醫療資訊系統的框架

這邊有兩篇由林口長庚王子豪教授在台灣精準醫學協會所撰寫的介紹文,可以作為入手:

1.快速健康照護互通資源 (FHIR)

2.基於FHIR標準來整合基因體數據到臨床應用的進展

近一步如何利用FHIR的標準,則可以觀看下面這一系列由英國Interop Summit在2018的youtube影片:

Part 1: Welcome and introduction to modelling with ClinFHIR
Part 2: Introduction to FHIR
Part 3: Building a Scenario
Part 4: Structured Data and Profiling

這四部影片,主要由Dr. David Hay這位FHIR標準制定核心人物來講授,教臨床醫師如何將臨床需求轉換成以FHIR標準的模型,使用clinFHIR這個為了讓初學者方便學習使用FHIR概念的網頁工具。

在往FHIR細項的文檔來爬梳,可以閱讀Dr.David Hay的部落格,裡面提供非常多第一線關於FHIR的洞見。