起初我們…

最近台灣、對岸與世界的政經情勢,變化不歇,然而島內的氣氛卻十分詳和,沒太多變化,無論是餅中被抓,還是勞資糾紛,一律抗議人數有限,網路聲量正反都有。乍聽起來好像是整個社會變得成熟了,然而真相卻是整個社會對現狀的無感與局勢的退縮。

雖然這裡的宗旨原先包涵「不談政治」,但我們一日不扯政治,政治就一日又一日地扯著我們

繼續閱讀全文 … »

並聯、串聯的思考方式


想和大家分享,今年最能夠幫助我思考工作方式,或者是行為模式的概念。網路、書店、演講總是可以看到、聽到很多關於工作的方法論,還蠻喜歡聽到有趣的想法就實踐看看,但很多方法都蠻複雜而且需要練習一段時間才會習慣,又或者是太單純強調勇敢、毅力的精神狀態,因此實踐起來其實不會太實用,也很少能夠幫助同時出現的許多小決策,這種小決策是生活中最頻繁瑣碎出現的。

因此,我一直想要尋找一種思維模式,像是筷子這樣的設計,可以符合多元的使用狀況,但是卻簡單、乾淨,而不是拿出一整套餐具的感覺。

而我尋找到的方法就是串聯、並聯的概念,沒有特別去尋找理論基礎,但在很多地方幫助自己許多,串聯、並聯是小時候上自然課,接電的時候一定會想起來的概念,我所體悟的方法就是將串聯、並聯的概念運用在工作、生活各種樣貌,這可以幫助我們擁有更多的時間,感覺擁有更多時間,如果認為效率可以幫助人生某些部分,也許可以試試看這個方法。

先就小範圍的工作來舉例,如果今天已經找不到時間開會,我們可能會考慮邊吃午餐邊聊一下工作,因此我們讓會議與吃飯的時間並聯在一起。又或者我現在手邊正專注在一件重要的任務上,等我忙完之後發現其他的工作怎麼停滯沒有跟著一起往前,這就是我們常忽略有些工作或任務是串聯的概念。

透過這樣思考的方式,對我來說就可以同時推進很多工作、生活需求,做時間分配的決策時也會比較明確而且快速。

而這樣的想法隨著應用範圍越大,越遠,所帶來的回饋越是正面,接著來看較大範圍的狀況,若同時考量工作和夢想,先完成工作,再完成夢想,或者考量財富累積和生活,先有財富累積再有生活品質,這些狀況若要變得有效率,決策應該偏向並聯的方式,雖然我自身的例子還不足以作為參考,不過這大概是我能提供最有感觸並且真實的例子:以我自己為例,非常在乎工作的成果,每一次都希望工作成果有所突破,這樣發展下去,花在生活品質和生活中的人際關係大概會越來越低,因此我開始思考邊約會邊工作的想法;邊玩電動邊思考團隊合作或分工的細節;邊工作邊玩的心態讓人感覺同時享受到生活也完成自己的嚮往,並且會發現很多道理或思考都有很多可以互相參考的部分。當然外在因素加進來,不完全像我描述的這樣順利或舒服,但實現部分就已經對人生充滿希望。

就像是交朋友,以我來說,都蠻喜歡和工作扯上關係,工作和友情並行,感覺其實很棒。

最後我想以設計或設計師的角度來說明像是產品開發這樣特定的小範圍工作,也有很多可以應用到串聯、並聯的概念,在我的觀察或經驗中,公司若分工較細常常會將職位分工和串聯、並聯的順序混亂,那些工作必須先完成;那些工作必須同時進行常常會有誤解,是設計師先做規劃、還是PM做規劃;是由工程師尋找核心技術、還是以商業模式作為門檻。

管理者希望達到明確的目標,卻要求不同職業的人一起思考提供各種開放的提案,若是明確的目標,這麼做也許就不太適合,明確目標或工作主體通常是串聯的結構,用並聯的方式會讓資源應用顯的不合適。將職位設計安排符合最佳的串、並聯任務,也許可以讓團隊合作更順利。

這樣平凡的概念,應該不太需要總結,希望這簡單的思維方式可以幫忙到閱讀文章的人。

文章圖片出處請參考

 

因為工作的關係,年中時有幸聽到趨勢家「佛里曼」談到他從2007到2017這十年間對科技趨勢的觀察心得,包括三個M,Market (市場),Moore’s Law (摩爾定律),和Mother Nature (大自然),雖然演講內容和他的書「Thank You for Being Late 謝謝你遲到了」大同小異,但不得不佩服他是一個一流說書人。該場演講最大的Take away就是:「如何激發動機並且持續學習」是他針對往後十年來自AI、大自然、與地緣政治的挑戰提出的最根本也最直白的解方。

如何激發動機並且持續學習,我覺得最好方法就是讓學習變得容易。如果是書籍類的,我喜歡聽有聲書,例如 audible.com 我覺得是一個很棒的資源,可以學知識同時可以練英文。如果是數位技能2014年時我曾經分享了Lynda.com,一個挺優秀的跨界終身學習/職能訓練平台,2015年它被LinkedIn以1億5千萬美金(約450億台幣)收編了,因此也開始推出一些所謂「Career Track」型態的課程庫,也增加了很多Business Skill的訓練。

台灣這兩年也端出了「Yotta」與「好學校 Hahow」兩個不錯的線上學習平台,與Lynda.com不同的是這兩個平台都用課程募資的方式來試水溫,收集資到一定的學生人數才能開課。因為最近正在自學資訊設計(Information Design)和動態圖文(Motion Graphics)因此推薦平台上兩門課:
不懂設計,也能學會的資訊圖像化密技! by 圖文不符
動畫師私藏系列|從轉場學會拆解 Motion Graphics

此外,我最近也發現一個對於新鮮或是想創業的設計人可能是福音的新頻道「The Futur」。頻道主持人Chris Do是一位於知名美國藝術學院Art Center任教,並執業22年的視覺、品牌、廣播設計師,他針對普遍內向害羞的設計師型人格打造了一個教「設計師如何談生意(The Business of Design)」的節目。持續邀請各種不同型態的設計師,以及在職涯不同階段的設計師上節目來做「設計職涯諮詢 Design Career Consulting」。目前頻道內點閱率第二高的是「設計服務如何定價+怎麼提高報價 How To Price Design Services & Make More Money」徹底解析一個LOGO設計應該要如何報價,真心希望我大學畢業時就聽到這段!

希望大家在終身學習的路上不孤單,找到自己的動力,持續向前。如果有發現什麼好的教學資源也歡迎和我分享喔 Mr. Happy Day

同場加映:
今年年中,同樣因為工作的關係,有幸請到世界級倫理學巨星「邁可桑德爾」來台演說「21世紀領導力與倫理學」。他分別探討了年金改革、核廢料、婚姻平權與人工智能App等四個熱門的議題。有興趣可以閱讀天下雜誌的摘錄,或是收看公視的錄影

DevOps 經驗談

其實我想寫這個,是因為某天我看到了這個文章,這篇是國外某個很有名的科技部落格 techcrunch 所寫的, 我近年來工作的範圍已慢慢從 team lead 轉向了 DevOps, 看了這個文章特別有感想.

假如各位讀者不了解這是做什麼的,我稍微解釋一下,Dev 是 development, Ops 是 Operations, Development 我想大家都很清楚,基本上就是寫寫code,Operations 我想了半天,最好的解釋應該是搞流程的,譬如說假如有一群人想要做一件事,裡面有好幾個步驟,怎樣把這一些人很有效率的完成這幾個步驟,這就是搞流程的主要的工作,DevOps 就是一個職業要把這兩件事合而為一,寫寫搞流程的 code, 也就是我們常說的 automation (自動化).

DevOps 的重要性近幾年來,慢慢的變得重要起來,尤其是現在大家很流行用 agile 來做事,agile 追求的是什麼?在很短的時間把所謂的高質量的少量成品放上去,在每兩個禮拜的sprint中,得交出點東西,但是萬一某天出了environment issue,你的工作就停擺了三天,那你的 10 天的工作日,就剩下了七天,還要扣掉給QA的時間,demo的時間,規劃的時間,東西做不完,又要流回 backlog list(這個在我們公司是家常便飯的事情) ,再加上近來流行 TDD,所謂的 test driven development, 簡單的說,就是要先寫 failed test 再寫 code,讓 failed test 變成 pass test.老實說,這是一個很好的概念,一開始會slow 整個 team 的進度,但是後來會讓整個 project的 code 質量變高,QA 的效率也會加快很多,但是問題來了,test 越寫越多,跑這些 tests 總是需要時間,就像目前我們 team 有一個主要的對外網站,光是 tests 就有六千多個,一台電腦全部跑完要四個小時,我們對 developer的要求又是,當自己的 code 要進入主 branch時,你的 code  一定要跑過這六千個 tests,但是,你總不能要求 developer  每天都等個四個小時,才能把自己的 code 放進去,這時候就是需要很多台很快的 server 能同時把六千個 tests 分散,讓 tests 很快速的跑完, 每台 server 怎麼設,怎樣才能最有效的,這就是 devOps 進入的地方.

介紹了半天,我都沒說到那篇文章,那篇文章簡單的說,就是 devOps 其實是一個將死的職業,作者基於的理由有二,第一現在很多都是走雲端,管理維護的需求基本不存在,唯一的差別就是使用各種 tools,作者覺得身為一個 developer,自己學一下就好了,說老實話,我覺得他說得蠻有道理的,因為我就是從 developer開始的,一開始沒有 server,就在自己電腦上建虛擬機器,沒有任何工具,就是自己寫,慢慢得越來越多人用,漸漸變成一個基準,每個人都得跟隨這個流程,server移到了雲端,說實話,也沒什麼要維護的,工具也很成熟,感覺上應該工作就變得很輕鬆了,就像文章所說,沒有這個職業也是可以存活的...真的嗎?

但是事實上,我還是很忙,原因很簡單,所謂的最佳化,是永遠做不完的,你永遠都有方法提高效率,即使有時候只有一點點,就像我之前所說的六千個tests,我有天做了小改變,減少了十分鐘的時間,聽起來是很小的變化,但是每個developer每天少十分鐘等待的時間,一個25人的團隊,就多了四小時,一天四小時,一年就是960小時,這樣感覺就很多了吧(我都是這樣騙我的老闆的)

今年十二月某日是我在矽谷某大公司就職三周年的紀念日。想藉這個機會來寫些感想。然而,矽谷許多大公司乍看之下非常開明,員工如果有發言造成公司形象損失,最嚴重有可能會被資遣。我不打算一面倒的說公司好話或壞話,但為了避免不必要的麻煩,就不直接講是哪個公司了,我們姑且稱之為 Hooli 吧。雖然我主要是寫自己公司,但我想內文當中的許多點也會滿適用於其他矽谷中大型科技公司,就請大家不要太計較倒底是哪家公司了吧。

在進入 Hooli 之前,我就跟許多外部的人一樣,對這家傳奇性的公司充滿了憧憬。三年之後,我仍然覺得這是一家不錯的公司,但是離完美仍然有一段不小的距離。外界把這間公司神話得太多,以致於面對現實的時候落差越大。

每個員工都天才?

Hooli 已經成長到幾萬人,除非你的定義很寬鬆,不然我是不覺得這個世界上有幾萬個天才 (而且還剛好都是同一個專業)。說實在話,比較早期的員工,平均來說好像真的有比較強一點。在某個時間點開始,員工的徵選變得越來越標準化,也就是外界常說的刷題。從那之後當然面試題還是會間接考到一些 desirable 的工程師特性,但基本上就是刷題刷很熟的人具有優勢。而我最近一兩年看到的是標準更快速的下降。很遺憾的是,我感覺公司已經不覺得招 top 1% 的工程師是 top priority 了 (可能 top 10% 甚至 top 25% 就 ok ),而是有其他的 agenda. 這可能也反映了日常工作的細碎化及 routine 化,可能有少數部門還是非常需要 top talent 來搞定,但其餘很多工作只要是還算不錯的 coder 來作就行了。好啦,我可能也是這樣混進來的,所以也不能抱怨什麼。當然公司還是有非常多強者跟神人的,平均水準高於其他公司應該還是沒錯的,但 hiring bar 漸漸變低我是覺得是滿顯著的。

超好康的福利?

是有提供三餐啦。不過我從一些待比較久的員工聽到的是,以前是的確有提供那種被媒體報也不奇怪的 level. 現在的狀況是不但退步很多 (最起碼矽谷總部是這樣),對一些比較挑食的員工甚至已經達到會構成 productivity 上障礙的程度了。比方說吧,我是還滿常自主留在公司加班的員工,但是最近晚餐已經難吃到我必須要回家吃飯才行。諸如此類的福利退步許多,在此不一一詳述。更令人失望的是領導層不時會用一些官僚話術來迴避正面回答這些問題。我覺得現在公司的態度就是,反正我們薪水給的還不錯,其他方面本來就不是你應得的,don’t be entitled. 當然我覺得在商言商,這個講法也沒有錯。但這樣的公司遠遠不是被外界神話的,Hooli 自許的技客天才們的迪士尼樂園,這就是一份 pay 還不錯的工作罷了。

Promotion 的正反面

說到 pay 的話,不能不提一下 Hooli 的 perf 與 promo 制度 (performance 跟 promotion 的縮寫)。簡單來說,一年有機會拿到兩次 perf rating, 同一時間點有機會 apply for promo (即職等上的升級). 收入跟這兩個參數有非常直接的關係。Hooli 希望儘量把這兩個過程公平化,而不是讓 manager 可以單獨決定,那容易造成一種儘量討好直屬上司的馬屁文化。同時,也希望各個部門之間的 promo bar 是相近的,而不會鼓勵大家去一些簡單好升職的單位。所以整個過程簡單來說就是由想要升職的人員寫出一份 package,列出自己的貢獻,然後由隨機構成的匿名升職委員會來審查 (能坐在委員會裡面的大多是職等較高的人員)。我認為關於這點 Hooli 的立意是值得稱讚的,也的確讓 perf/promo 比其他公司公平許多。
然而,由於委員會必須要審查來自不同部門的 applicants, 這導致他們必須著重於客觀數據。具體上來說:
(1) 一個產品或功能有沒有 launch. 如果有,她的各項數據為何。(e.g., 用戶數、點擊數的變化等等)
(2) 開發產品與功能的複雜度。這可能比較難量化,但應當可以從技術層面客觀說明。

用意都是好的,(1) 的用意大概是希望大家不要領公司的錢,作些自己感興趣但對公司沒用的 hackathon-ish project。然而副作用是沒有發布就沒有 credit. 就算你把自己的部分作得好棒棒,如果因為其他小組的 dependency 還沒作完,或是其他你不能控制的因素 (VP 換人然後突然說我們不作了),恭喜你,你過去幾個月努力作的東西就白作了,最起碼在 perf/promo 上是算不了 credit. 不幸的是,在組職日益龐大的今天,以上種種並不少見,這讓在 Hooli 工作這件事變得非常 frustrating. (如果你介意 perf/promo/comp 的話)。另外的副作用包括:產品還沒完全準備好就發布出去 (因為 promo 的時間點要到了 而且一年只有兩次),或是不傾向改進既有產品,而是砍掉重練,導致同性質產品好幾個讓 user 非常 confused.

(2) 的用意是讓大家敢於挑戰困難的專案,而不是永遠在挑軟柿子吃。然而其副作用則是讓大家不喜歡修小 bug. 因為修一百個小 bug 也無法證明問題的複雜度,不如集中精神作一個大 project。再跟上述 (1) 合在一起就讓 Hooli 充斥著不少半調子的功能跟產品。也說明了為什麼 Hooli 產品的 UX 常常都滿爛的 (以一個世界頂尖公司的標準來說),然後過一陣子再跟大家宣布,不好意思某某產品要收起來了,謝謝大家的照顧。

最後,這個制度也帶來了對公司文化上的副作用。在物價房價 (尤其是房價) 非常高的舊金山灣區,可以想像大家對於收入是非常執著的。而公司又樂於強調 perf 與 promo 的重要性。Again, 公司的立意一開始應該也是好的。因為 Hooli 基本上是個相對高薪又安全的的工作,如果不強調 perf 與 promo 的重要性,員工不會更加積極工作。然而過與不及都不好。如今的 Hooli 比較像是大多數的人作什麼事情都先問,「這對我的 perf 跟 promo 會有什麼影響」?而不是「我要怎麼樣作出更棒的產品」?這對公司顯然不好,而對員工個人來說也不是愉快的事情,因為這表示了人是為了外在的獎勵而工作的 (翻譯: $$$),而不是什麼值得燃燒熱情用科技改變世界的偉大使命。當然還是比為了不要被開除而努力工作來得積極很多啦,但絕不是最佳的狀況。

結語

看到這裡讀者可能會問,奇怪,感覺你好像說了很多 Hooli 的壞話,那為什麼不離開呢?簡單來講,我沒有看到什麼很好的 alternative. 各方面綜合條件看起來,我仍然覺得 Hooli 目前來講就算不是業界 the best employer 也應該可以排進 top 3. 當然我也可以去其他綜合條件很好的公司,矽谷所在多有。但是因為換工作本身有丟掉過去在這個公司積累知識的成本,所以如果沒有顯著的好處 (e.g., level+n, comp+x%,超有趣 project),其實是不怎麼划算的決定。我自己覺得如果已經進到 Hooli,下一步應該是自己創業,或是加入一些較早期的公司比較有意思。當然要走到這一步是需要許多準備的,所以短中期內我是打算繼續待在 Hooli 的,儘管她不是那麼完美。

背景介紹:漸藍白領一枚,已有伴侶有小孩,週一到週五白天上班晚上趕回家顧小孩,週末顧小孩偶爾探視長輩。週一到週五固定的行程是早上花約一個半小時開車上班,先載小孩去保母家,再載老婆去上班,然後再前往公司,這段時間稱為上班通勤時間。因為老婆對我有興趣的東西不感興趣,所以無法在上班通勤時間前段開始聽我自己感興趣的資訊,直到送老婆到公司後,後半段的時間才能利用。通常約有四十分鐘,如果塞車會花到一個小時。因為邊開車,所以只能播放音頻資訊。再次提醒大家唷開車別低頭使用手機!也因為邊開車,最好的資訊長度是可以半小時以上,讓我不必開車中途還需要低頭操作手機,點播新的資訊。

繼續閱讀全文 … »

這幾天筆者加購了一台配備高解析螢幕的筆電,由於平時使用的並不是 Apple 系統,且筆電算算也有六年沒換,雖說蹭別人的 Mac Book Pro 玩過幾次,以高解析螢幕為主的使用經驗,在此之前還真沒有過。筆電來了,自然要把附帶的 Windows 10 縮一縮,裝上慣用的 Ubuntu 才是正辦。過程中,又碰上老問題:字太小。

這問題快十年前就碰過,大約知道是 DPI 設定不正確。雖說本行不是幹這個,但為了顧眼睛還是得處理一下,還可寫篇文章談談不專業的豆知識交差。先從字型大小說起。

字型尺寸當然是從電腦出現之前就存在,pt 是 point 縮寫,雖在歷史上幾經變遷,最終在數位出版時代訂立 desktop publishing point,長度為 1/72 英寸,大約 0.353 公釐。說到這似乎已說完了:那麼,12 pt 字,當然就是 12/72,也就是 1/6 英寸(又稱 1 pica),會有什麼問題呢?

然而對電腦使用者而言,卻往往不是如此。我們知道 12 pt 的字,用印表機印出時,大小是固定的。但在一般解析度螢幕上,字比較大,而在高解析度螢幕,字就變小了。這似乎可以自圓其說:高解析度下,一個螢幕上的「點」比較小,所以如果螢幕上的字是由固定點數所組成的,那麼每一點越小,字當然就比較小了。早期的字型的確是這樣的,叫做點陣字,也的確會有在不同解析度大小不一致的問題。但後來向量字型出現,可以平順的縮小放大,也開始用 pt 為標示單位,為何還是有大小不一致的情況呢?

要說明這個,就必須先說明 DPI 是什麼。DPI 是 dots per inch 的縮寫,表示每英寸點數。數字越大,解析度越高。例如印刷常用的 300 dpi,看起來已經非常清晰,一般 24″ 的 1080p 螢幕是 92 dpi,Apple 的 Retina 筆電多半落在 200 多,而 iPhone 由於觀看距離更近,可高達 300 多,iPhone X 更高達 458 dpi (註 1)。有了 DPI 概念之後,再回去想想 pt 的問題,就比較清楚了:假定某印表機以 300 dpi 列印,那麼 12 pt,也就是 1/6 寸的字型,其大小就是 50 點 (dots),而若是在解析度比較低的螢幕,例如 90 dpi,就是 15 點。如此,同樣的字型尺寸,顯示在不同解析度的螢幕上,就是一樣大,只是精細程度不同。

這麼說來,只要知道螢幕 DPI,字型大小的問題照理說就可以得到解決,但為何沒有呢?這又是另外一個故事。1980 年代,Apple Macintosh(麥金塔)電腦設定的解析度是 72 dpi,讀者可發現這跟 point 單位一致,也就是 1 point 剛好對應到 1 dot,12 pt 在螢幕上就用 12 dots 表示。當時搭配的螢幕是 512 x 342,換算下來寬度大約是 7.1 in,而北美慣用的 letter 大小紙張寬度 8.5 in,兩邊扣掉 0.7 in 的留白,恰好是 7.1 in,所以若螢幕不設定兩邊留白,字型大小就會完全一致。這乍看是非常合理的設定,但也產生一些問題。例如 12 pt 的字,在 300 dpi 下,每個字可以用  50 點表示,相當足夠,但在螢幕上,就只剩 12 點,加上英文字母上下有突出,主要的部份例如字母 x,只剩下 6 點可用,看起來就比較粗糙。再加上螢幕跟眼睛之間還有鍵盤,一般觀看距離比紙張來得遠,字看起來就更小了。

這時,微軟想出了一個聰明 (?) 的方法來改善這問題:相對於 Apple 的 72 dpi,他們增加 1/3,在所有軟體中將解析度設定為 96 dpi. 短期內這有幾個效果:若需要 10 pt 的字,解析度是 72 dpi,就只能用 10 點來設計字型,看起來比較粗糙;而若解析度是 96 dpi,就有 13 點,設計上會更容易些。而在顯示時,由於當時螢幕一般都還在 72 dpi 的水準,96 dpi 會導致螢幕使用比所需更多的點數來顯示,讓字母高度變成原先的 4/3 倍,看起來比較清楚。顯而易見的缺點是,這背離了原本 DPI 與 pt 的關係,而隨著 Windows 3.1 大紅,到 Windows XP 長達十多年的統治,這也造成相當深遠的影響。在 Windows 7 之前,預設的 96 dpi 並不會隨著不同螢幕而改變,這也造成前面所提到的,高解析螢幕字比較小的印象。

為了解決這問題,後來微軟發展出 device independent pixel (DIP) 這單位,其定義就是每 DIP 為一寸的 1/96。沒錯,就是 96 dpi 這個魔術數字。舊的 Windows 應用程式,其基本假設就是畫 96 個點是一寸,那麼在高解析螢幕上,只要將其使用的「點」定義為 DIP,就可以保持這程式的界面仍然可用。這也是為何一些比較古早的應用程式,看起來有點糊糊的,因為 Windows 自動以 DIP 放大了原先界面的緣故。

讓這筆糊塗帳更加糊塗的,還有另一個當初看起來很有道理的設計:網頁的 CSS 規範。CSS 全名為 Cascade Style Sheet,就是一般網頁使用的排版格式,其內有個常見的長度單位,px, pixel unit. 以 1998 年公佈的 CSS level 2 來說,CSS 的長度單位分成兩種,絕對與相對。絕對單位包括了 in, cm, mm, pt, pc (pica) 等等,可注意到也有熟悉的 pt,而相對單位則有 em, ex, px,其中 em, ex 是相對於設定的字型大小,例如 1 em 就等於設定的字型大小,所以若設定字型大小為 12 px,那 1 em 就是 12 px. 而 px 則是相對於「顯示裝置的解析度」,也就是螢幕上的一點。由於各個螢幕一點的大小不見得一致,px 就成了相對單位。在 CSS 2 裡面,針對解析度不同以及觀看距離不同的情況,還建議了參考的改變方式,這容後再論。

在 199x 的年代,一般螢幕的解析度不是那麼高,設計上差了幾點,看起來就差很多。例如一條線寬度是一點或兩點,看起來會有相當明顯的差異。所以,設計上會講究 pixel perfect,也就是仔細控制網頁上各個元件長度是幾「點」,而不使用絕對單位。在指定字型時,往往是類似 font-size: 12px 這樣的形式,而其他諸如欄位寬度等等,也一律使用 px 來設計,以確保顯示出的結果符合預期。但這造成一個問題:網頁上的長度單位,包括字型,又再度隨著螢幕解析度而改變了。在 72 dpi 的螢幕上, 12 px 就是 12 pt,沒什麼問題,但螢幕的 dpi 一直在提昇,12 px 的字也就越變越小,只能創造出各式各樣觀念去修正。

在這裡就要提到,前面 CSS 2 針對不同解析度及不同觀看距離,所做的建議。其內容是,1 px 應等於在一般觀看距離,即平均手臂長度,定義為 28 寸,觀看 90 dpi 的螢幕,螢幕上 1 點的大小。也就是說,1 px 從「長度」變成了「角度」,約略等於 0.0227 度,投射出的距離,是會隨著觀看距離而改變的。底下這張圖,直接來自 CSS 2:

這裡顯示出,在 28 寸的距離,1 px 約等於 0.28 mm,而在 140 寸(例如投影情況),1 px 約等於 1.4 mm,是原先的 5 倍。複雜歸複雜,至少這裡對於 1 px 提出一個還不錯的標準,希望在不同的觀看條件下,都能得到一致的經驗,只是事與願違,後來大部分實作都還是採用 1 px 對應螢幕上一點的設計,且 96 dpi 隨著 Windows 四處普及,大家都把 96 px 當成實作上需要 1 寸的約略單位,不但應用程式與網頁如此,連螢幕也是,以避免使用者由於 dpi 差距過大而難以使用。在實作日漸偏離標準的情況下,CSS 2.1 這修正版裡,針對這部份有幾個修改,都相當有趣:

  1. 參考用的 px,從原先定義的 28 寸,90 dpi,改為 96 dpi。也就是說,W3C 肯認大部分螢幕都設計成接近 96 dpi,所以在預設的閱讀距離,也就是 28 寸時,參考用的 px 約略就等於螢幕上的一點。
  2. 將 px 從相對單位,改為絕對單位,長度是 0.75 pt. 如此一來,在 96 dpi 的裝置上,96 px = 72 pt = 1 in,就一致了。
  3. 讓 px 有雙重定義:在接近 96 dpi 的螢幕上,px 保持在 0.75 pt,也就是約略仍等於螢幕上的一點。而在其他情況,則採用角度的定義,而讓其他單位如 pt 等「相對於 px」定義出來。亦即,假設現有一 200 dpi 螢幕,在 28 寸位置,若採用角度定義,px 就不再表示螢幕上的一點,而是約略等於兩點,而 pt 由於相對於 px,就仍然可以約略等於 1/72 寸。而由於是角度,所以只有在 28 寸的觀看距離,pt 才會約略等於物理上的 pt 單位。若在不同距離,例如預設的觀看距離比較近的 iPad mini 與 iPhone 等,網頁上的 pt 與物理上的,就不會相等了。

繞了這麼一大圈,回到一開始的題目:新筆電的 DPI 設定。以下是設定前與設定後比較,這也可以看出,Apple 當時提倡 Retina 螢幕,打破 96 dpi 魔咒,還要維持各類程式、網站等仍然可用,實在是相當了不起的突破,也推動其他廠商跟進,最終造福使用者。

[1]: DPI / PPI 的問題,本文略過不表。

頁次 1 of 26612345678910...203040...最後一頁 »