<address id="ttjl9"></address>

      <noframes id="ttjl9"><address id="ttjl9"><nobr id="ttjl9"></nobr></address>
      <form id="ttjl9"></form>
        <em id="ttjl9"><span id="ttjl9"></span></em>
        <address id="ttjl9"></address>

          <noframes id="ttjl9"><form id="ttjl9"></form>

          首頁

          認識 ESLint 和 Prettier

          seo達人

          ESLint

          先說是什么:ESLint 是一個檢查代碼質量與風格的工具,配置一套規則,他就能檢查出你代碼中不符合規則的地方,部分問題支持自動修復。


          使用這么一套規則有什么用呢?如果單人開發的話倒是沒什么了,但是一個團隊若是存在兩種風格,那格式化之后處理代碼沖突就真的要命了,統一的代碼風格真的很重要!


          (其實以前自己做一個項目的時候,公司電腦和家庭電腦的代碼風格配置不一樣,在家加班的時候也經常順手格式化了,這么循環了幾次不同的風格,導致 diff 極其混亂

          想提高設計轉化率,按鈕應該放在左邊還是右邊?

          資深UI設計者

          任何一名設計師應該都會接觸到運營活動頁,產品落地頁此類需求。而這些落地頁設計需求的業務目標衡量標準都相當明確——即轉化率。再進一步,與我們的設計輸出直接相關的就是首頁轉化率/點擊率。這些數據通過埋點能很輕易地獲得,一般情況下,產品經理會提前在需求文檔中標明需要埋點的地方(埋點簡單說就是測量某個位置或者交互節點的具體數據,例如發生了多少次點擊),獲得數據用于驗證產品最終是否符合預期,是否達到了理想的轉化效果。

          叮~ 講到這我們應該明確了一件事,整個落地的設計其實最終都是為那個關鍵數據服務,無論是點擊率還是轉化率,達到預期甚至超出預期,那你的設計就完美地完成了任務,這也是驗證設計有效性的主要方法,將設計與數據關聯,用可量化的數據指標來驗證偏感性的視覺工作。

          就這樣,設計與產品/運營的世紀大戰開始了。因為我們都有了一個共同的目標,因此在產品的最終收益、期望效果方面互相都很明確。但在實現手段上,我們很輕易地產生了分歧。主要分歧點就是「按鈕在左還是按鈕在右」這個問題上。我們需要理解,這不是一個簡單的交互問題,因為它其中摻雜了商業內容。如果這是一個交互問題,那我們很容易判斷,例如彈窗的主次按鈕應該主右副左,這既符合平臺規范,也符合用戶認知和操作習慣。

          然而作為一個強商業屬性的落地頁,按鈕在左或者按鈕在右都有其合理性。我選擇左,而運營同學代表他們團隊要求右。 于是我敗下陣來,當然,雖然表面上設計師輸了,但我們怎么能服輸,于是我想盡辦法來驗證左側放置按鈕才是更有利于轉化的形式。下面我們來看看不同的傾向對應的設計原理。

          左與右的矛盾

          產生左與右的爭執其實主要源于設計與需求方的兩個判斷方向。首先說一下我的判斷邏輯,按照已知經過驗證的理論,即 F 閱讀順序(尼爾森的用戶閱讀視線模型),用戶瀏覽落地頁的順序應當是從左往右自上而下,因此左上角的信息最早觸達用戶。在當前主流的首圖式落地頁樣式下,首圖 banner 中的內容應當置于左側,以使用戶更快地獲知產品的關鍵信息。

          在落地頁首圖的體驗文案本身就是一個設計的覆蓋范圍,因為它直接關系到首頁的視覺傳達效率,即用戶需要花費多長時間、多少精力才能理解你的產品。我們往往在首頁體驗文案中采用主標題加副標題的形式,著重解釋這個產品是個什么東西、用戶能從這獲得什么,往往通過主副文案搭配的形式,來完成整個大意的闡述。

          基于此,核心內容置于左側,用戶在快速掃視時能夠第一時間獲知產品信息,了解產品利益點,這與我們精心準備整個網站,以及精心準備誘導力文案的方法相契合。這是我做出內容置于左側的設計決策的主要思路??梢钥闯觯疫@里主要參考的是 F 閱讀模型這一理論,根據這個經驗我得到的結論是 重要的信息應當擺放在左側以使用戶立即觸達核心信息,這將有利于接下來的引導或者轉化。

          另一方面,運營同學又是基于什么考慮決定將核心內容放在右側的呢?答案是操作習慣,理論化的話可以用費茨定律概括,(目標距離用戶距離越短,用戶觸達的效率越高)??紤]到大部分用戶使用右手操作,鼠標也大都懸停在屏幕右側,因此,按鈕置于右側,用戶點擊的路徑變得更短,也就更容易觸達和轉化(純體驗角度或者說效率角度)。

          你仔細閱讀這部分內容,從分歧點到各自的理論支撐實際上都沒有太大的漏洞,為什么沒有漏洞?因為確實都沒有錯誤,也都存在其合理性。例如我們常用的購物 APP 會把按鈕置于右下角,用戶操作起來必然比左上角的按鈕更加容易。那么在這兩種分析都合理的背景下,我們要對比或爭論的其實不是哪個判斷是錯誤的,而是哪個判斷更有利,更合理,能夠帶來更多的數據轉化。因此,這個問題最終由對錯問題,轉化為一個優劣問題。

          左與右的妥協(一種結論)

          有些人很機智,這個時候肯定會想,既然左邊最容易觸達信息,右邊最容易觸達按鈕操作,那左邊放置內容,右側放置操作不就完美解決了嗎?哎呀,讀者真聰明。

          由于 F 閱讀的邏輯,將展示性質的「內容」放置于左側,使用戶更快觸達關鍵信息,由于費茨定律,以及多年來養成的用戶習慣(操作組件在右側,當然現在很多放在中間的情況)將需要執行的操作置于右側,使用戶快速交互并完成任務。有一定道理,甚至在實際落地產品中我們也能看到一些類似的設計,例如豆瓣。 這是一種左與右的妥協

          但需要注意的是,豆瓣產品的右側放置的是較為復雜的交互模塊,例如完整的登錄注冊模塊。在該場景下,用戶在交互路徑更短的右側區域執行交互效率要明顯高于左側區域。

          那么下面開始論述按鈕置于左側的觀點

          論點一:排版的限制

          豆瓣的形式對于落地頁產品,可能并不適用。主要有兩方面原因。我們都知道,產品落地頁首屏的組成為體驗文案,主 CTA,插畫配圖三部分。常規做法是插畫作為一組信息置于一側,文案加按鈕作為一組信息置于一側。因為,體驗文案與按鈕具有強關聯性,同時按鈕與文案作為一組信息,才能與另一側的插畫搭配構建平衡的布局,呈現比較優美的視覺效果。

          請登錄后查看原圖,因此,豆瓣那種妥協方式并不適用于商業類落地頁。因為內容和操作本身是一體的,這源于排版的規整性的限制,按鈕和文案只能同時存在于一側,如果刻意去追求左側內容,右側操作,效果就像下面這樣。一方面,只靠文案和按鈕無法撐起左右兩個區域,一方面文案和按鈕被割裂開,用戶的視線由文案轉到按鈕的路徑過長,體驗較差。(文案與按鈕成組后,用戶可以在閱讀內容產生動機后立即觸達交互按鈕并完成轉化)

          論點二:文案與配圖孰輕孰重

          如果你親自體驗這兩種區別的落地頁(左圖右文/左文右圖),你會發現有一個共同點,就是在某個區域的停留時長,沒錯就是內容區域。以下圖的頂部卡片區域為例,在閱讀時我的瀏覽情況是,大致地掃視左側的插畫,然后注視右側文字區,了解文章的具體內容,并在此區域停留較長時間,畢竟仔細閱讀需要花費時間。

          這就涉及到一個問題,插畫與內容哪個更重要?其實答案很明顯,我們只需要舍棄掉其中一項來測試下,看看哪個內容的缺失會對用戶理解設計傳達的語義產生較大影響。OK,我覺得沒必要測試了(虛晃一槍)。很明顯,刪除插畫后,我們仍然可以通過文章的標題來獲知文章概要等關鍵信息,就像落地頁首屏的體驗文案,即便沒有插畫我們也能通過首頁文案來獲知這個產品是什么,能夠為我帶來什么。

          然而如果去掉關鍵信息,去掉標題與按鈕,僅憑插畫我們無法分辨當前頁面到底在講述什么東西。設計本身就像是人與人的交流,產品就是我們,而用戶則是我們的交流對象,去掉核心的文案,相當于把我們自己變成了啞巴,而去掉插畫,最多相當于我們交流時面無表情罷了。

          因此,在商業落地頁中,我們以轉化為核心目標,而能夠更快地觸達最重要的信息顯然是明智之舉,因此我們希望將核心的文案內容置于左側。

          (另外,一圖勝千言的原理只適用于個別場景,例如數據可視化。設計人員通過將數值數據轉化為易于理解的柱狀圖扇形圖,來傳達數據結論。而視覺修飾性質的插畫則無法做到準確表意,我們通常在產品設計中見到的插畫更多的是在情感上和審美上給予我們一定的愉悅,但想要準確描述關鍵信息,還是需要文字作為核心角色)

          論點三:用戶會因為便于操作而產生動機?

          另一點同樣值得我們思考,即用戶真的會因為某個按鈕更容易點擊而被轉化嗎?或者我們換個形式問,假設你是一名男性,你會因為按鈕在鼠標附近而選擇點擊購買女士內衣嗎?你會在自己財務狀況較差的時候因為按鈕在鼠標附近而點擊購買品嗎?在大多數理性場景下,我相信你不會這樣做。

          所以這時候要引入福格模型,用來闡述產生轉化的整個路徑。福格模型簡單來講就是一個公式:B=MAT。B(behavior) 代表行為,M(motivation) 代表動機也就是用戶需求,A(ability) 代表用戶使用的門檻,T(trigger) 代表觸發。也就是用戶行為的產生需要用戶需求為基礎,需要保證產品的易用性,但是這還不夠,在這個基礎上我們還需要在產品中通過設計觸發用戶。完成轉化的三個關鍵要素是,動機、能力、觸發,缺一不可。

          福格模型幫助我們解決了這個疑問。用戶的購買或者轉化始于動機,就像我上面舉的例子,如果一個用戶根本對產品沒有需求(男性對女性內衣),那就不會產生動機,在沒有動機的情況下,后面兩項內容,能力或者觸發都沒有意義,無法發揮作用。整個轉化的流程可以參考下方的示意圖。

          實際上對于那些有強烈動機購買或使用產品的用戶,你的一切設計都沒有太大意義,因為用戶有強烈訴求的情況下,他會發揮主觀能動性去找到轉化的入口,主動完成轉化。同理,有些用戶是完全不會產生動機的,不是目標用戶群。

          設計策略主要針對的是有動機但不強烈(某種程度上有需求或者被吸引),以及暫時沒有動機的兩類用戶。通過我們的首屏及詳細內容,痛點利益點的介紹,來放大用戶動機,制造共鳴點,創造美好的想象空間,使用戶涌現強烈動機。然后轉化就自然而然的產生。

          因此,在首屏我們的核心要義是通過內容設計來觸發用戶動機,而不是想方設法觸發操作。走捷徑的誤觸方案設計能保證百分百的觸發率,但那種觸發沒有任何意義。到這里我們應該明確了,用戶會因為好的內容所觸發的動機而買單,但不會因為你把按鈕放在我手邊而產生購買沖動。

          因此,我的結論是,用戶更有可能因為左側展示的強洞察力的文案而產生動機,而動機是整個轉化的起始,也是最關鍵的一點,有了動機,觸發(按鈕位置)的效率即便低一點,但轉化仍然很有可能繼續(就像動機產生了慣性,有了強烈的動機會自發地去尋找觸發器,去尋找按鈕以自主完成轉化,但觸發器不會有慣性)

          這個觀點論述下來,主要涉及到 F 閱讀模型,費茨定律以及福格模型,算是很基本的設計原則,也順便幫大家重溫一下。最后,我們再拿一些其他實證來進一步論述,例如國內一線公司的落地頁設計。

          1. 一線公司落地頁布局

          2. 全球獨角獸企業落地頁

          文章來源:優設    作者:南山可

          B端系統,篩選控件總結

          ui設計分享達人

          寫在前面


          首先我們先從篩選本身講起吧~

           

          篩選可以說是我使用比較頻繁的一種交互形式,比如我點外賣,會選擇滿減優惠力度大,同時我也可以選擇在哪一個價格區間內的產品,這就會用到篩選,而到了B端產品上來,一個CRM系統當中,篩選的邏輯也會比移動端的復雜,伴隨著:且關系、或關系、大于、小于等等這樣復雜的邏輯,也為設計本身增加了很多難度。因此,今天我們就來討論討論篩選控件

           


          1、篩選存在的意義


          篩選存在的對于整個表單來說是非常重要的,它可以幫助用戶,在表單茫茫多的數據當中進行快速的定位;可以對表單進行快速劃分,縮短用戶對于數據的尋找時間;能夠滿足用戶在工作中,實際業務場景的篩選。

          對于實際B端場景來說,篩選是日常數據分類的一個重要途徑,我們先來看看實際場景到底有哪些?

           

          用幾個我們CRM用戶日常使用的場景來說:

           

          比如今天作為一個電話銷售人員,想要聯系最近注冊的用戶時,通常會通過篩選來選出最近幾天注冊過,同時又沒有銷售更進的客戶,進行一個優先級的排布;

           

          再比如說,在銷售周報當中,銷售主管可以通過篩選得到每個人這周完成的狀態,也可以通過篩選得出每個人對于線索的更進情況和對客戶的流失狀態等等,這些都可以通過各種各樣的篩選形式來滿足用戶對于特定情況下的使用



          篩選和搜索、導航的區別?

           

          篩選可以通過多個篩選條件進行多維度的尋找,而導航、搜索只能通過單一條件進行指定篩選。

          雖然在現在很多搜索都可以支持多維度用空格去進行多字段的關鍵詞搜索,但本質上區別不大

          所以在B端項目當中,如果你有表單,那你就需要篩選



          2、篩選的類型


          我們將篩選分為基礎篩選和高級篩選兩種,兩種篩選會根據業務場景不同,在不同的頁面去使用

           

          2.1、基礎篩選


          基礎篩選一般為系統預設好的篩選字段,具有很強的業務和場景的需求?;A篩選一般分為四個部分:


          篩選條件:是指用戶可以篩選的范圍

          篩選項:是指用戶可以選擇的篩選項目

          已選項:是指用戶已經選中的篩選項

          備選項:是指用戶還沒有選擇的篩選選項



          基礎篩選更多作為用戶快捷篩選的一種方式,因為一般使用場景當中用戶幾個篩選邏輯為“且”

          同時篩選的邏輯也為簡單篩選,所以在使用場景上只適合在對篩選要求不高的場景下使用。


          2.2、高級篩選


          高級篩選一般為篩選中含有運算符,同時篩選當中包含條件關系,比如且關系或者否關系。一般高級篩選包含以下幾類關鍵詞

           

          篩選關系:是指幾個篩選條件之間的關系,一般為 且、或關系,即 且 關系為幾個條件之間的并集;或 關系為幾個條件之間的聯集

          篩選字段:是指在篩選當中,所要的篩選項,一般為表單當中的所有可篩選的字段

          篩選操作:是指篩選字段和篩選值之間的關系,常見的篩選操作有:大于、小于、是、否、包含、不包含、為空、不為空等等。

          篩選值:你所需要篩選的數值



          高級篩選一般滿足更多的用戶場景,為用戶多條件多字段、多個篩選關系、多個篩選操作 提供有利保障。




          3、篩選的布局


          3.1、上下布局


          當在篩選器條件少于5個的情況下,最常使用的就是上下布局,這樣篩選能與網站保持統一的情況下,上下布局也更方便用戶進行閱讀

           

          當篩選器過多的情況下(一般在5-15個之間),篩選器過多,需要滾屏才能看到篩選結果,用戶使用起來會很別扭。所以在5-15個的情況下,一般會將篩選項進行收折,這樣保證篩選整體面積不會太大,同時將用戶常用的篩選放在前面,可以滿足用戶基本的業務需求和使用場景



          3.2、左右布局


          左右布局在PC端一般是以字段選擇進行篩選,通俗來講就是將用戶可以篩選的所有字段全部羅列出來,然后通過勾選選,擇出你需要篩選的字段,進行篩選器的使用

           

          左右布局的好處是能夠將篩選的所有條件都直接的展示出來,可以適應很多場景,在篩選器用15個以上時。通過左右布局的方式,能夠讓篩選條件進行滾動,在最大限度保持用戶使用體驗




          4、篩選的形式


          在日常的B端產品中,篩選的形式有哪些?篩選到底應該怎么設計?接下來為大家總結梳理一些在 B端產品 中的篩選玩法,希望為你開啟新大陸。


          4.1、平鋪型



          平鋪型一般為用戶搜索結果數據量過大,使用戶搜索出來的結果與其預期差距過大,用戶然后可以通過篩選對數據的再一次分類,使用戶能夠精準尋找其想要的結果。

          平鋪型一般為篩選條件少于6個,這樣能夠通過1行或者2行去展示篩選項的結果

           

          多用于信息量大的產品,比如電商、視頻網站等等。常見的淘寶、京東、騰訊視頻PC端 都采取用這樣的方式,將所有的篩選條件列出來。

           

          平鋪型的好處是將篩選項的結果全部或者部分放出,能夠幫助用戶快速理解篩選項以及快讀找到自己想要的結果。

          缺點也是很明顯,平鋪型的控件占比大,需要占據大量面積展示平鋪出的篩選結果。

           

          比如淘寶PC端,搜索一個產品后花去40%的面積去展示所有的篩選條件,其實就是想引導用戶,淘寶搜索過后spu的數量仍然過大,想通過進一步的篩選,讓用戶明確自己對想要東西。同時因為面積占比大,通常平鋪型都是以收折的狀態,只有在搜索觸發后才會完全展開


          4.2、收折型



          收折型篩選是一種簡單直接的篩選形式,將用戶常用的篩選形式通過下拉框的形式進行篩選。每一個篩選條件就是一個下拉框,這種形式看上去很簡單,但是在B端場景中,下拉框對于用戶來說認知成本低,操作性也較強,同時在用戶重度使用時,又能給用戶很好的使用體驗的一種方式

           

          優點:

          用戶可以直接對其常用的字段篩選進行一步操作,并且沒有復雜的篩選關系,全部都是“且”的篩選邏輯,能夠保證用戶進行快速的篩選選擇

           

          缺點:

          將所有信息全部平鋪展開,信息量過于冗雜繁多,同時在做通用性產品時,這種方式很難做到通用性


           

          4.3、單側篩選



          單側篩選是一種更通用的篩選形式,通過對于你想篩選的字段進行勾選,勾選完成后就會出現篩選條件,然后選擇篩選字段、篩選操作、篩選值,一般選擇完成所有篩選后,還需要點擊查詢,篩選操作才算完成。

           

          整個單側篩選,大量的篩選條件可以放置在表單的左側或者右側,通過表單縱向空間,去承載大量篩選條件。

           

          優點:

          節省空間、通用性強。因為在很多Saas系統、Paas系統當中,無法針對每一個客戶進行設計,就要考慮到系統通用型高,做一些大而全的功能。在每個表單也所需要定制化修改的地方很少,同時能容納的信息量可以很大。

           

          缺點:

          就是在后臺系統當中只有這一種篩選形式會面臨在我常用的幾種篩選的字段中,要通過不斷尋找,來滿足我的篩選需求,操作麻煩。

           

           

          我們產品在某一次改版就將篩選由收折式修改為單側式,因為我們用戶使用篩選的場景非常的多,用戶每次篩選都要多進行2、3步操作,導致用戶進行了大量的吐槽,后來進行修改,將篩選順序支持手動調整順序,用戶吐槽的次數才慢慢減少。



          4.4、表頭篩選

           


          表頭篩選是一種復雜篩選的形式,其最開始是來源于Excel的篩選形式。點擊表單的篩選按鈕,可以將表頭的篩選字段直接帶入,方便用戶。之后在后臺產品的發展中,得以借鑒過來。

           

          優點:

          可以通過表頭的點擊,使用戶更快捷進入到自己的篩選條件,在通常情況下,在表單越左的數據顯然是越重要的,也是使用篩選去篩頻率最高的,因此高頻的篩選場景基本還是得到滿足。


          缺點:

          用戶第一次進入系統很難理解這種交互形式,且在每個表頭都會有一個icon,影響用戶對于表頭的識別。

           

           

          4.5、彈窗式



          通過點擊篩選按鈕,展現出篩選彈窗,進行篩選。這種篩選適合在篩選功能在系統中不是很重要的層級。最常見的就是Tapd,在其中篩選不是很強的一個功能,同時也是系統中十分有必要的。

           

          優點:

          是能夠在節省面積的情況下,可以進行很復雜的篩選,同時可以支持復雜情況下的篩選

           

          缺點:

          彈窗會遮擋一部分表單數據,會影響篩選人的判斷,其次篩選條件的添加也相對更加繁瑣。

           

           


          5、選擇更合適的篩選

          在我們一系列篩選的調整過后,我們團隊也總結了對于我們來說更重要的條件和形式,來和大家分享探討一下。

           

          5.1、使用頻率

          我們認為影響篩選控件最重要的是用戶的使用頻率,因為用戶的使用頻率和使用方式,直接影響到我們篩選是用普通篩選or高級篩選,也會影響到篩選的形式。

           

          5.2、滿足實際業務所需

          篩選功能的做法,取決于我們產品未來是想往哪一個方向發展,如果想把功能做的強大,就得考慮到篩選的后續擴展性。因此滿足實際業務也是十分重要。

           

          5.3、用戶認知成本

          在B端系統當中,最可能遇見的就是你給用戶設計的路徑但是其實用戶根本沒有往你想的方向去操作。我們系統最開始給用戶設計好了很多功能點,但是用戶對于這個點的認知成本實在過低,也導致了后面系統功能點很多都被埋沒。因為在你設計好了一個功能點后,要適當引導用戶,解釋這個功能的使用場景才不會讓你設計的功能被淹沒。

           

           


          其實在B端產品中,易用本身就是難且長的過程,在每一個功能的設計都需要你去思考很多方面:用戶易用、信息層級、未來擴展,你都要做出取舍,而對于每個模塊都需要你思考、結合用戶場景,B端web的設計一直都是摸黑前進,我也只是將自己的一段時間的工作進行總結,說的不正確,歡迎大家指正。

           轉自:站酷-Cengg 


          Mac 視覺史 vol.1:從 Macintosh 到 Mac OS

          資深UI設計者

          2009 年,買不起 Macbook 的我在 PC 上裝上了黑蘋果。在此之前,我用虛擬機體驗了 Apple II 、Mac OS 8.1、Mac OS 9.2.2 、Mac OS X 10.6 ,在不斷的折騰過程中,我開始對蘋果、對GUI 的整個歷史發生了興趣。

          此后,我在Jeff Johnson 的《認知與設計》當中,在 Steve Krug 的《Don’t Make Me Think》當中,在一本又一本和UI、交互、體驗相關的經典書籍當中, 發現 Mac 系統的界面一直被作為范例來展示。

          Mac 確實是優秀設計的典范,是 GUI 設計史當中繞不過去的最重要的操作系統家族。所以,視覺史系列文章的第一篇,我決定從 Mac 系統下手。

          兩大系列,四個名字

          簡單來說,我們泛指的 Mac 系統,通常是分為2個大的系列的。

          1982 年隨 Macintosh 發布的系統,一直到 1999年發布的 Mac OS 9 為第一個系列,一般被統稱為「Classic Mac OS」。

          而 2001 年之后所誕生的 Mac OS X 系列的操作系統,包括現在所說的 macOS ,則被視作為第二個系列的 Mac 系統,其中 X 是羅馬數字 10 的意思。

          蘋果公司最初只有 Macintosh 電腦,系統并無名稱,直到第5個大版本的時候,操作系統才擁有 Macintosh 這個名字。而 Mac OS 這一系統名稱,則是在系統更新到第7個大版本的時候才被提出,而自此開始,Mac OS 的稱謂正式出現。

          而 macOS 則相當于是 Mac OS X 品牌的一次重啟。它始于 10.12 Sierra 這一版本,并且為了和 iOS、tvOS、watchOS 這幾個系統品牌保持一致,而從 Mac OS X 更名為 macOS。

          在很長一段時間,國外很多老用戶會將它簡稱為「OS8」、「OS9」,而在2001年之后直到今天,依然有很多人將它簡稱為「OSX」,這也是在了在討論 Mac 系統這個前提下所用到的、帶有版本的簡略稱謂。

          注釋:國內有不少人會將 Mac 稱為「OS系統」,但是 OS 本就是 Operation System 的縮寫,意為操作系統,Windows 是 OS,Linux 也是 OS,「OS系統」是一個錯誤且尷尬的表述。

          如果不深究細節的話,Macintosh,MacOS,Mac OS X , macOS 這四個都簡稱為 Mac 系統。

          圖形化界面:向施樂偷師

          Macintosh 并非最早的圖形化界面,但卻是真正推動圖形化界面操作系統發展的里程碑。

          Xerox Alto

          對于圖形化用戶界面的起源,一個相對統一的共識是,它來源于施樂的帕羅奧托研究中心,而最早使用圖形化界面的電腦,是當時正出于研發中的 Xerox Alto。在之前的文章當中,我曾經專門聊過最早圖形化界面的誕生和設計細節:

          比爾蓋茨曾經指責喬布斯從施樂這里「偷」走了圖形化界面(GUI)的設計,實際上,為了換得機會去施樂的帕羅奧托研究中心去觀摩學習研發中的Xerox Alto 和開發工具 Smalltalk,喬布斯是拿股權交換得來的。

          這是 Xerox Alto 當時所采用的圖形化界面。界面的確圖形化了,只不過,從今天的視角來看,整體的界面邏輯并不清晰。

          而在GUI的設計細節、實現方式上,Macintosh 則截然不同,可以說是后來居上。

          規避糾紛: Macintosh 的名字來源

          說回 Mac。

          回溯到 1979年,Jef Raskin 是Macintosh 電腦和操作系統項目的發起者和監督者,他想用自己最喜歡的一種蘋果(McIntosh)來給這個操作系統命名。

          這種名為 McIntosh 的蘋果不僅被譽為加拿大國家級蘋果,但是更重要的原因在于,當時紐約還有一家名為 McIntosh Laboratory 并且提供高端定制音響服務的公司,為了避免商業品牌上的沖突,Raskin 將系統的名稱改為 Macintosh,故意錯開了一個字母。當然隨后 Macintosh 的名字逐漸超過了前者,在世界范圍內,甚至慢慢超過了加拿大最著名的水果。

          當然,1984年,最初版本的 Macintosh 系統隨著同名的蘋果電腦的發布而面向大眾,這個并非最早的圖形化界面操作系統開始了它的歷程,如今它是最著名、最具有影響力的圖形化界面的操作系統之一。

          Macintosh 電腦的主板由 Burrell Smith 所設計,結合當時的硬件技術,讓最終上市的 Macintosh 電腦擁有了一塊分辨率為 512×342 的單色顯示屏。

          在這塊寸土寸金的單色屏幕上,Macintosh 系統需要將圖形化界面的價值盡可能發揮出來。

          Macintosh 系統:正式擁有姓名

          Macintosh 電腦開始出現在各大雜志媒體上,蜚聲世界,但是此刻,這一操作系統并沒有官方的名稱。 1.x系列的只有一個非正式的 System 1 的名字,而隨后的大版本也被稱為 System 2,System 3,等等。

          直到 System 5 的時候,這一操作系統才算是正式有了 Macintosh 的名稱,而它正式的完整名稱是 Macintosh System Software 。

          System 1 ~ System 5:功能迭代

          最早的 System 1 當中,開機之后有一個非常可愛的歡迎界面:

          菜單和窗口的概念清晰,比起 Xerox Alto 的設計更加成熟:

          左上角的蘋果圖標打開之后,本質上是一個程序列表:

          在 System 1 當中,文件夾是一個虛擬概念,在文件系統當中其實是根本不存在文件夾的,它是模擬現實文件夾的概念而存在的一個圖形化界面概念:

          在系統出錯之后,系統報錯界面中會使用炸彈圖標來進行提示:

          1984年的 Macintosh 的系統崩潰界面都比 2000 年之后的的 Windows 藍屏界面來得更加有趣:

          當然,用一個帶有圖形化界面的電腦玩游戲,難道不是一件天經地義的事情嗎:

          特別值得一提的是,Macintosh 自打一開始就為自己設計了一系列的字體:

          其中風格獨特的 San Francisco 在多年以后還擁有一個同名的字體,作為系統默認的字體而存在。

          隨后,在隨后的 System 3 當中,垃圾桶的 APP 圖標增加了「有垃圾文件」和「已清空」兩種狀態的區分,并且給系統新增了一個歡迎界面:

          文件夾也不再只是一個虛擬的概念了:

          同樣的,在 System 3 當中游戲的精美程度也有了一定程度的提升:

          當然,從 System 1 到 System 4,系統的功能在一代代地增加,但是受限于屏幕和基本的性能,其界面在整體觀感上差別并不大:

          不過在圖標和界面細節的處理上,越來越豐富,越來越細致,比如系統的控制面板,功能和細節比 System 1 時代豐富了許多:

          在 System 5 當中,Macintosh 還加入了多任務的功能,也就是 MultiFinder,使得用戶終于可以同時運行多個任務,不過因為性能限制,跑多任務的時候,會比單任務慢不少。

          System 6 :集大成的版本

          對于 Macintosh 系統而言, System 6 是一個階段性集大成的版本。系統的版本和軟件的版本在 System 6 當中進行了統一,并且功能也有了相當程度的完善。

          性能更強勁的 Macintosh SE/30 和 筆記本電腦 Macintosh Portable 也是在 System 6 更新期間發售的。

          Macintosh Portable

          Macintosh SE/30

          System 7:擁有色彩的新世代

          終于,黑白用戶界面的時代在 1991 年終結,Macintosh 系統從 System 7 開始擁有了彩色的用戶界面:

          色彩的加入,系統圖標的擬真度也再一次提升,比如垃圾桶的圖標,光影已經相當逼真了。

          而為了更好地利用彩色界面的功能,用戶可以根據自己的偏好進行全局色彩設置:

          軟件安裝的進度指示方式,比起同時代的系統乃至于后面的很多系統,都要清晰明確:

          關鍵信息的說明和引導上,Macintosh 系統在30年前就已經有明確的范式了,比如重要信息標紅強調:

          由于這個階段系統分辨率的限制,在按鈕的視覺層次構建上,陰影和按鈕凸起的效果,都做的比較簡單,但是總體上始終上是在模擬現實存在的元素,通過盡可能貼近現實的視覺設計,來減輕用戶的認知負荷,計算器和鍵盤的設計就非常的典型:

          System 7 當中,還內置了交互式的用戶幫助系統:

          在控制面板當中,圖標的統一性再一次得到了提升,風格上明顯有著當時的特征,只不過在信息的傳達上,還不夠優秀,如果沒有文本標簽,你很難判斷每個按鈕對應的功能是什么:

          值得一提的是,System 7 所處的階段,大量的兼容機和包括 Windows 在內的操作系統開始出現,激烈的市場競爭之下,蘋果也發布了一系列的新款的 Macintosh 電腦:

          為了應對激烈的競爭,蘋果還想出了新的策略,而這一策略也促成 Macintosh 系統后續逐漸成為一個獨立的品牌。

          Mac OS :第一次品牌重構

          1996年,喬布斯重回蘋果。同時在這個階段,Macintosh 系統也隨之進行了品牌重設計,Macintosh 系統更名為 Mac OS。

          為了應對激烈的市場競爭,這一階段的 Macintosh 電腦開始逐步切換到 PowerPC 架構的 CPU 芯片,同時,蘋果公司也開始授權一些第三方廠商,使用同樣架構的芯片和主板,并且安裝System 7 的系統。

          可以直接安裝 System 7 的 StarMax 兼容機

          這樣一來,就開始出現問題了:非蘋果產的電腦上,也會顯示 「Macintosh 」的字樣,那這個怎么和原廠的 Macintosh 電腦進行區分呢?

          很簡單,在原裝的 Macintosh 上,依然還是 Macintosh,但是在兼容機上,它就是「黑蘋果」——Mac OS:

          在當時,很多人認為這種區分,僅僅只是用來進行差異化的臨時解決方案。此時喬布斯即將重掌蘋果,并且打算把前 CEO 的系統第三方授權策略給干掉。將 Macintosh 更名為 Mac OS 就是解決方案,只不過這個解決方案并后面還有其他的深意。

          因為后面還有新系統。

          Mac OS 8:一石二鳥的更新

          Mac OS 8 是在 1997年7月26日發布的,同一個月另外一件大事,就是喬布斯正式任命為 CEO,執掌大權。

          其實,此處的 Mac OS 8 并非真正意義上的大版本更新——它原本應該是 Mac OS 7.7 。但是,前 CEO 同第三方廠商簽訂的系統授權協議,是基于Macintosh System 7 的,而直接發布 8.0 版本等同于是巧妙地利用命名,直接把后續的服務和協議一起給斷掉了,同時新的 Mac OS 系統從名字上也直接區分于原本的 Macintosh,可以說是釜底抽薪的一招絕殺。

          同時,新名字,新世代,也是開創新局面的好預兆,一舉多得。新的 Mac OS 8 系統在更加優秀的硬件基礎上,在顯示效果上也一下子進入了高清的時代。

          雖然 Mac OS 8 在底層上,依然繼承自 System 7 ,但是因為幾年前開始的 Copland 項目有不少遺產,身為繼承者的 Mac OS 8 在視覺和體驗上,提升了相當明顯:

          Mac OS 8 當中加入了主題選擇的功能,雖然比較簡單,但是也至少有著跟 Windows 95 相互匹敵:

          和同時代的很多操作系統一樣,在多媒體軟件上, Mac OS 8 有了頗為炫酷的視覺效果:

          界面左上角的 Apple LOGO 繼續作為程序列表的菜單按鈕而存在:

          類似 2.5 D 的圖標設計,是這個時代的用戶界面設計的流行風尚:

          而這種變化,在 Mac OS 8.5 這一版本上,有了更為明顯的提升——比如文本抗鋸齒效果,讓文本更加易于閱讀:

          更加柔和自然的的光影變化,更復雜的交互和界面元素,Mac OS 8.5 所呈現出來的視覺效果乃至于體驗,不會弱于同時代的任何系統:

          但是也僅僅只是不弱于對手而已。

          Mac OS 9:爭取時間的權宜之計

          Mac OS 9 是 Mac 系統第一個系列的最后一個大版本。

          和 Mac OS 8 類似,原本的 Mac OS 9 原本應該作為 Mac OS 8.7 來發布的。

          其實早在喬布斯回歸并發布 Mac OS 8 之后,Mac OS 9 的發展路徑和命運就已經注定了:為老硬件和老用戶更新,并且繼續為真正的新系統爭取時間。

          Mac OS 9 是在 1999 年 10 月 23 日發布的。這個面向新世紀而發布的操作系統,蘋果是以「有史以來網絡功能最好的操作系統」來進行宣傳。

          此時,喬布斯重組的設計團隊,已經為新的操作系統挑選好了新的設計語言,而此時發布的 Mac OS 9 當中,也適當地加入了一些為真正的下一代系統所準備的視覺元素,比如播放器軟件中的不銹鋼拉絲效果:

          窗口界面中的元素有著細膩微妙的光影起伏:

          搜索應用中的內陰影、高度擬物化的小圖標:

          特別要說的是,此時的 Mac OS 9 中已經可以找到很多貼合現代 UI 設計中的諸多原則了,比如富有邏輯的分組:

          容納多個并列分組的標簽頁交互:

          在諸如幫助頁面和安裝界面中,使用了層級豐富的排版視覺設計:

          也許現在你對于字體的這種投影深惡痛絕,但是在20年前,這樣的視覺效果是令人驚艷的:

          Mac 系統第一系列自此收官

          Mac 系統的第一個操作系統系列,在明面上有著相對清晰的脈絡:自家電腦,用自家系統。通過這一系列的界面設計,可以總結出下面的幾點:

          • 第一個系列的 Mac 系統在交互和整體框架上,保持了高度了延續性;
          • 模擬現實世界中元素的設計理念,從 Xerox Alto 一直延續下來沒變過;
          • 在已有屏幕分辨率基礎上,最大化地提供優質的視覺體驗,是它的宗旨;
          • Mac 系統確實在很早的階段,就已經開始注意體驗和「不言自明」的交互邏輯;

          Mac 的圖形化界面,始于施樂,成于喬布斯,在迭代中一步步完善。

          不過,從 System 7 開始,它的危機就已經出現了。從 1991 年到 1999 年這 8 年時間當中,暗地里發生了一系列的事情,這些事情是 Mac 系統視覺史當中,不可或缺的組成部分。

          下一篇,依然是 Mac 系統的視覺史,其中包括 WIndows、NeXTstep、BeOS,當然,還有 Mac OS X。

          參考:
          https://history-computer.com/ModernComputer/Personal/Macintosh.html
          https://en.wikipedia.org/wiki/Xerox_Alto
          https://web.archive.org/web/20001109004000/http://www.apple.com:80/macos/
          https://apple.fandom.com/wiki/Mac_OS_8.5
          https://en.wikipedia.org/wiki/System_7
          https://www.versionmuseum.com/history-of/classic-mac-os
          https://en.wikipedia.org/wiki/Macintosh_clone
          https://en.wikipedia.org/wiki/Classic_Mac_OS

          https://guidebookgallery.org/guis/macos/macos10


          文章來源:優設    作者:陳子木

          Mac 視覺史 vol.2:90年代失敗操作系統大賞

          資深UI設計者

          在第一篇 Mac 視覺史當中,我梳理過了整個 Mac 系統第一階段的明線,而這一篇,我們來聊一下它的「暗線」。

          這一章所涉及到的項目,幾乎可以組成一個 大型的「90年代失敗操作系統大賞」,在主要由成功者們所構成的故事、新聞乃至與傳說當中,這些失敗的故事和項目,被提及的次數很少。

          但是對于 Mac OS X 而言,這里的每一次作死和失敗都充滿了意義。

          對于絕大多數的用戶而言,Mac OS X 是21世紀初頂尖設計的范式,在今天,它是最優秀操作系統的當中的典型。

          但是仔細想想看:從 System 1.0 到 Mac OS 9.2.2,長達15年時間的擠牙膏漸進式升級的Classic Mac OS,怎么可能突然一下子就變成了充滿現代感的 Mac OS X?這種翻天覆地式的變化的確充滿了戲劇感,但那是在今天的視角之下。

          在這場「90年代失敗操作系統大賞」當中,無疾而終者多不勝數,你所看到的不僅有粉墨登場,還有各式各樣的粉末謝場。在 Mac 的視覺史當中,這一篇應該是一個大型的「處刑現場」。

          失敗的嘗試,同樣是 Mac 整個視覺演變史當中,繞不過去的部分——沒有這些失敗,就沒有今天我們所熟知的 macOS 的視覺風格,沒有后面 iOS 、iPadOS、watchOS 等等一系列交互界面和視覺。

          來自內部的壓力

          雖然我們此刻所談及的是操作系統的視覺史,但是操作系統背后最重要的始終是推動它的「人」。談 Windows 必然會涉及 比爾·蓋茨,而談到 Mac ,也不得不說喬布斯。

          和當年很多操作系統不一樣的地方在于,喬布斯一直堅持硬件和軟件(操作系統)理應是一體的。這也是為什么在很長的一段時間以內,Macintosh 指的既是硬件(電腦),也是軟件(操作系統),而因為這臺電腦是更容易被指代的對象,當用戶在指代系統的時候,使用的是諸如 System 1 ,System 2 這樣的詞匯。

          原本的 Maciontsh 是有內部競爭對手的——Lisa,這個以喬布斯女兒命名的電腦研發項目被奪走之后,喬布斯在 Macintosh 上投注了300% 的精力,親手操刀了不少設計。擁有大量資源傾斜的 Lisa 在當時那個階段,看起來也并不差:

          在這個 1983年的 UI 界面上,細節處理其實也算得上非常用心了,比如頂部菜單上的「陰影漸變效果」:

          當然,Lisa 的定位也非常明確,它就是一臺辦公電腦,所以它的系統名稱也非常簡單直接地使用了 Lisa Office System 這樣的名字:

          也正是在這樣的對比之下,有著豐富字體、多樣的媒體功能、能夠玩游戲的 Macintosh 在這場內部競賽中,得以勝出。

          當然,如同我們都知道的,喬布斯在發布 Macintosh 的 2年后被迫離開自己創立的公司。當然,更重要的是,硅谷的巨頭們更加清楚計算機的發展方向。這使得 Macintosh 面對的外部壓力驟增。

          激烈的外部競爭

          圖形化界面(GUI)的概念和交互模式——這個點子本身可能比實現技術來得更重要。

          在高手云集的硅谷,雖然絕大多數的企業和開發者都是后期入局者,但是他們只要投入足夠多的技術人員和時間,類似的圖形化交互界面總歸是能做出來的。

          比如 Visi Corp 給 IBM 提供了 Visi On 這樣的圖形化程序:

          微軟也在 1985 年為 IBM 的 PC 提供了 Windows 軟件:

          Commodore 的圖形化界面也差不多同期問世:

          而 GEOS 甚至為更老的 Apple ][ 提供了圖形化界面的操作系統:

          這些系統都是在 Macintosh 發布那一兩年內相繼問世的。

          從 System 6 開始新嘗試

          操作系統領域的競爭,刺激著蘋果尋求突破。

          多數企業都不會把雞蛋放在一個籃子里,這樣孤注一擲的決策確實有太大的風險。其他的商用操作系統,都開始擁有日漸完善的桌面端圖形界面,使得蘋果在差異性和獨特性上不足。除了在硬件性能和產品線上增加投入,他們也開始嘗試開發更優秀的圖形化界面和下一代操作系統。

          在上一篇當中,我提到過,在 80 年代末所發售的 System 6 是一個集大成的版本,在硬件性能和黑白顯示器之下,這個操作系統本身的核心功能已經頗為完善了。這個時候,蘋果開始有意識地進行一些探索性的項目。

          「Pink」和「Blue」項目

          某種意義上來說,「Blue」 和「Pink」 兩個項目幾乎是同時開始的。

          雖然 1988 年的時候,喬布斯早已離開,但是他所塑造的 Macintosh 是當之無愧的傳奇,那種「內部創業」和「改變世界」、「創造傳奇」的硅谷精神對于此刻的蘋果員工依然有著極大的影響。

          當時蘋果內部 5 名躁動不安的中層開發工程師想拜托日漸僵化的內部管理,想改變當時 System 6 表現欠佳的局面,想打造一個次世代的旗艦操作系統——某種意義上重現 1984 Macintosh 的傳奇。

          他們在這次私底下的會議上重新梳理并規劃未來的操作系統。他們將System 6 基礎上的可以增量更新的特性、可以很快實現的功能,寫在藍色的卡片上,將技術上更加先進、符合長期價值的功能(比如當時 Macintosh 所缺乏的搶先式多任務處理和組件化程序設計)寫在粉色的卡片上,將更加激進的特性寫在紅色的卡片上。

          這次會議基本上就塑造了后面的「Blue」和「Pink」兩個項目,而紅色卡片上的特性由于過于激進,僅僅只是備案而沒有成立項目。

          數百名工程師繼續在 System 6 的基礎上按部就班地更新功能、維護代碼庫,繼續「Blue」項目,而它的最終產物,就是后面我們看到的 System 7:

          而另外一邊的「Pink」項目,一開始并不是公開的。當時 Erich Ringewald 領導這發起這次會議的核心 5人組,想像 Macintosh 項目開始那樣,找一個隱秘的房間開始這次「內部創業」。

          他們看上了 位于 Bubb Road 的一間倉庫,當他們進去的時候,才發現這個倉庫已經被另外一個正在秘密進行 Newton 項目的團隊給占了。

          當然這款同樣極為傳奇的(失?。┱粕显O備我們回頭再說。

          一路膨脹的「Pink」項目

          「Pink 」項目開局的時候,有 6個人,但是考慮到要徹底放棄 System 6 的遺產,重新開始全新的操作系統,程序要是面向對象的,要有內存保護,要搶先式多任務處理,要支持多語言足夠國際化,還要有全新的圖形庫,這個團隊開始一路膨脹。

          先是蘋果的先進技術小組(ATG)加入團隊,人數變為11人。 2個月后,「Pink」項目增加到 25 人。7個月后,原始的5人組幾乎都因為「人員多到失控」而離開「Pink」項目。1年后,「Pink」項目的開發組多達100人。

          原本計劃在2年后發布的「Pink」操作系統在原計劃的2年之期到期之時,擁有了 150 人的超大規模,高級副總裁和市場營銷部門的首腦領導著這個龐大的開發團隊。

          「Pink 什么時候上市?答案永遠都是2年后?!?

          這是當時流傳的一個內部笑話。

          但是這個笑話只是剛剛開始。因為它才剛剛開始膨脹。

          系統開發需要時間,而隨著時間推移,市場變化需要「Pink」 更有競爭力,然后原本位于紅色卡片上的「激進功能」開始不斷的加入到「Pink」當中,然后項目就需要更多時間來開發——惡性循環開始了。

          在「Pink」上,蘋果投入了太多,放棄是不可能放棄了,唯一的辦法就是拉更多人入局。當時的 CEO John Sculley 對外宣稱「Pink」操作系統代碼已經多達 150 萬行,并去 IBM 做了內部演示。

          然后,這個看起來像是被移植到 PC 上的 System 7 成功地引起了 IBM 的注意。讓比爾·蓋茨最不想看到的事情發生了:蘋果、IBM 和 摩托羅拉成立 AIM 聯盟。

          從未發布的「Taligent」系統

          AIM 聯盟成立于 1991年10月2日,此時距離「Pink」項目開始已經過去了3年半。半年之后,蘋果和 IBM 正式組建了合資公司 Taligent .inc ,而其中蘋果占股較小。

          原本被拿來吹噓的「Pink」操作系統,此時也更名為 Taligent 。

          Taligent OS 的確有著很多超越 Macintosh 的功能,比如更的程序機制,3D功能等等等等。在整個 UI 界面上,Taligent OS 使用了繼承自「Pink」項目的一些設計:等軸測的圖標,偽3D風格的圖標,還有非矩形的窗口(注意看窗口的頂部菜單欄)。

          當然,Taligent OS 從「PInk」項目繼承過來的最大特性是:一直在開發,從未正式發布。

          1994年,HP 入局,加入 Taligent 公司并且持股 15%,Taligent OS 的一部分技術開始運用到 HP 家的 NewWave 桌面環境中了:

          與此同時,Windows 95 的關注度越來越高,而媒體吐槽蘋果久未發布的新系統,并嘲諷難產多年的 Taligent OS(還有 Pink),已經成了一件政治正確的事情。

          雖然 1994 年的時候,Taligent OS 在 SFA 展會上使用 Macintosh IIcI 展示了運行速度和崩潰速度同樣快的 3D 應用,但是它最終還是沒有發布。

          1995年,蘋果出售股權退出 Taligent 公司,「Pink」 項目的最終產品也并非 Taligent OS,而是 IBM 公司的 AIX 系統中的 Common Point 應用。

          「Pink」到此終結。失敗。

          最終迷航的「StarTrek」計劃

          在 Taligent OS 研發期間,蘋果將雞蛋還放到了另外一個籃子里面,這個項目的代號借用了著名的科幻電影《星際迷航》,項目的 Slogan 是「大膽地探索 Mac 之前從未去到過的地方」。

          這個地方就是使用英特爾芯片的 X86 架構的電腦上。

          「StarTret」項目中,蘋果是和當時的服務器供應商 Novell 共同構思的,這個項目最終因為內部斗爭、人事糾紛、市場問題而關閉。值得一提的是,同樣的嘗試在 1985年的時候就有過,不過那次嘗試很快就被中止了,以至于至今沒有一個正式的代號留下來。

          這算是2次失敗。

          「Copland」 操作系統

          作為 「Blue」項目產物的 System 7 最終并沒有徹底解決蘋果在操作系統上的困頓處境,系統依然問題很多,內存保護機制、搶先式多任務處理依然還沒有。而 1994年3月開始的「Copland」項目,就是為此做準備的,它的代號來源于美國作曲家 Aaron Copland 。

          除了在內存分配和多任務處理等核心功能上進行開發提升,它在 GUI 的視覺層面上的優化,也花費了相當多的心思。在視覺層面上,Copland 新設計的一套主題名為 Platinum ,所有的元素都有著頗為細膩的陰影,窗口元素則有著明顯的突起,原本「Pink」項目中的等軸測圖標也加入了進來。

          除了 Platinum 之外,Copland 還加入了面向兒童的主題P,以及更加具有未來派風格的主題Z。

          除了主題本身之外,Copland 還支持窗口最小化到底部為標簽,多用戶登錄(Windows 98 之后才有這個功能),這種功能類似于現在的家長管理——管理員帳號可以決定其他用戶可以使用哪些應用??梢哉f,非常超前了。

          當你在 Copland 中拖動文件到不同文件夾的時候,這些文件夾可以自動打開,這一功能在當時也是非常先進的。

          不過,Copland 極具前瞻性的另外一面,就是它本質上是一個「要你命3000」。各種新的功能和特性出于市場需求和項目需求毫無節制地被加入進來,所有的功能相互之間都存在沖突和影響,所有人都很清晰地知道,Copland 是不可能被作為正式產品所發布出來的。

          「它只是一個不同團隊開發產品的合集……并且期望它們能夠神奇地組合到一起?!?

          這是當時的 CEO Amelio 自己說的。

          當然,Copland 的陣亡不可避免,只不過它的界面管理器和 Platinum 主題最終留到了 Mac OS 8 當中,為蘋果公司的自救大業添磚加瓦。

          Copland 失敗了。自家開發團隊搞不定,只能從外部想辦法了。

          4個外部備選方案

          當時,CEO Amelio 個人比較傾向于 Windows NT,并且為此專門同蓋茨通了電話,而蓋茨也表示如果愿意使用 Windows,他可以組建團隊將蘋果的拳頭產品 QuickDraw 移植過來。此時,WIndows 95 已經發布一年了,而 Windows NT 也剛剛發布,市場反響極好,份額節節攀升。

          當然,蘋果和微軟的命運糾纏并不是此時才開始的。Windows 1.0 時代,圖形化界面的專利授權是蘋果授權給微軟的。

          而 Windows 2.0 繼續沿用 1.0 時代的設計,但是蘋果沒有給 2.0 授權,最終引起了糾紛,蓋茨借用不維護 Word 和 Excel 軟件和當時的 CEO 達成了庭外的和解。這些事情回頭有機會細說。

          和CEO的想法不同,當時蘋果的 CTO Ellen Hancock 其實是想選擇 Solaris 來著,不過它還沒有一套友好的用戶界面,贏面不大。

          最終擺在蘋果CEO 和董事會桌面上的,就剩下兩個備選了,一個是 BeOS,另一個是喬布斯的 NeXTSTEP。

          然而這毫無疑問是一次極具戲劇化的選擇,因為這兩個操作系統背后的兩個人,有著極深的糾葛。

          讓-路易·加西 和喬布斯的糾葛

          Be 公司的 CEO 是法國人 讓·路易·加西,他是 1981 年加入蘋果公司并負責當時歐洲業務。

          1985年,他在得知喬布斯計劃在陣亡將士紀念日罷免 CEO 約翰·斯卡利(John Sculley)的計劃后,搶先告知董事會,最終導致喬布斯從蘋果辭職。

          1987年,加西啟動了 「Skunkworks」項目,而這個項目的產物就是后來的掌上電腦 Newton MessagePad,而最終這條產品線也是喬布斯關停的。當年的「Pink 」五人組在倉庫里撞見的,就是加西的團隊。

          1990年,加西和CEO交惡,并且董事會對于他所推出的 Macintosh 產品不滿意,最終導致他離開了蘋果,并于次年創立了自己的 Be 公司。

          彼時正在艱難推進 NeXT 電腦業務的喬布斯,在媒體那邊的口碑并不好。而加西反而在這個時候,對 NeXT 不吝溢美之詞。

          當然,最終喬布斯的 NeXT 和 加西的 Be 最終還是擺在了同一張桌子上,被選擇。

          極具潛力的 BeOS

          BeOS 是一個在當時來看極為激進的操作系統。它并不是為當時更為流行的辦公場景而構建,而是一款旨在為多媒體處理而生的操作系統。

          它并沒有采用當時所流行的 Unix 的架構,有著一套相對更加獨特的系統邏輯和設計規則。

          它同樣延續了當時最為流行的等軸測圖標設計,在配色上更為鮮亮,在視覺化設計上,一點都不弱于同時期的任何操作系統,包括 Macintosh 和 NeXTSTEP。

          在交互邏輯上,BeOS 沿用了當時很多 Unix 操作系統的右側交互工具工具欄,正在運行的程序可以清晰地在此預覽,而右上角的 BeOS LOGO 則類似開始菜單,可以呼出程序列表:

          BeOS 的圖標設計在統一性和規范性上極高,即使在今天看來,很多設計都不落俗套:

          BeOS 能進入蘋果的備選,一個很重要原因是這套操作系統兼容當時 Macintosh 所用的 PowerPC 的架構。盡管它一直都未曾推進到 1.0 正式版,但是并不影響它在電腦領域收割一大波粉絲。

          但是作為一個操作系統而言,在消費市場上依然是一個失敗的產品。

          定位高端的 NeXTSTEP

          另外一邊,喬布斯 的 NeXT 電腦并沒有復制 Macintosh 消費市場上的成功。不過,NeXT 作為定位高端的工作站,倒是吸引了不少科學家和計算機領域的研究人員以及頂尖的數字創意從業者的注意。

          在接近被收購的當口,NeXTSTEP 系統已經推進到了4.0 的大版本。由于它本身在硬件性能上的突出表現,在操作系統的各種細節上,一點都不吝惜,竭盡全力地刻畫細節。而這其中,有很多概念和想法是從 Macintosh 時代繼承并發揚出來,并惠及后面的 MacOSX 乃至于 macOS。

          精巧的 3D 小插件,全彩高清大尺寸擬物化圖標,底部程序塢組件,以及可以購買軟件的軟件商店,甚至于著名的游戲 Doom 和 Quake 都是在 NeXTSTEP 上首發的。

          無論是內部的功能,還是外部的 UI 元素的細節控制,NeXTSTEP 都在當時條件允許的前提下,做到了盡善盡美。比如登錄和關閉窗口中的光影細節:

          (注:NeXTSTEP 是操作系統,而OpenStep 是一套 API。)

          當然,NeXT 本身并不算成功,被蘋果收購是最好的結局之一,這不僅是市場的選擇,也是蘋果的選擇,是喬布斯的選擇。

          結語:自此重啟

          終極對決發生在 1996年10月12日,地點是帕羅奧托的花園庭院酒店。

          CEO Amelio、CTO Hancock ,以及另外 的 6 位董事會成員是最終決策者。加西志得意滿,沒有作任何演示,而喬布斯不僅使用了他的天賦技能「現實扭曲力場」,而且如同魔術師一般演示了 NeXTSTEP 的各種功能和特性。

          蘋果公司,喬布斯,加西 三方的命運在此匯聚碰撞,然后再次扭轉。當然,這個扭轉的過程并非一帆風順,此時,距離蘋果的命運徹底改變,還有4年時間。

          在離開蘋果、創立 NeXT 的階段,喬布斯和蘋果曾數度交惡,其中所產生的糾紛與訴訟在此刻依然是障礙。

          NeXT公司同意了種種限制條款:其產品將作為高端智能終端直接銷售給高校,而且NeXT公司不能在1987年3月之前推出產品。蘋果公司還堅持,NeXT的機器「不能使用與Mac兼容的操作系統」。后來的情況表明,如果當時蘋果公司的要求剛好相反,會對自身更為有利。

          ——《史蒂夫·喬布斯傳》

          看完了這些失敗的產品的產品,我們終于要說一下成功的產品了。

          下一篇,我們將從「水」聊起。

          引用來源:

          https://en.wikipedia.org/wiki/Jean-Louis_Gass%C3%A9e
          https://guidebookgallery.org/articles/sortingoutfactfromfiction
          http://toastytech.com/guis/guitimeline2.html
          https://lowendmac.com/2005/apples-copland-project/
          https://en.wikipedia.org/wiki/Appearance_Manager
          https://en.wikipedia.org/wiki/Star_Trek_project
          https://dl.acm.org/doi/book/10.5555/582997
          https://en.wikipedia.org/wiki/System_7
          https://web.archive.org/web/20070120202050/http://robinnet.net/resume/Robin_portfolio_Taligent.htm
          https://web.archive.org/web/20070106224709/http://www.wildcrest.com/Potel/Portfolio/InsideTaligentTechnology/WW87.htm
          https://www.operating-system.org/betriebssystem/_english/bs-aix.htm

          https://www.wired.com/1993/02/taligent/


          文章來源:優設    作者:陳子木

          以動物為靈感的 LOGO 設計欣賞

          前端達人

              對于許多公司和品牌而言,使用帶有含義的動物logo,能非常準確的傳遞品牌信息!比如說豹子的敏捷,獅子的勇猛,長頸鹿的優雅,獨角獸的神秘等等!這種品牌意識在其徽標中使用動物象征來策劃。根據所選動物的類型,品牌是強大,快速,奢華,關懷,神秘和許多其他情感。

          1.jpg2.jpg3.jpg4.jpg5.jpg6.jpg7.jpg8.jpg9.jpg10.jpg11.jpg12.jpg13.jpg14.jpg15.jpg16.jpg17.jpg18.jpg19.jpg20.jpg21.jpg22.jpg23.jpg24.jpg25.jpg26.jpg27.jpg28.jpg29.jpg30.jpg31.jpg32.jpg33.jpg34.jpg35.jpg36.jpg37.jpg38.jpg39.jpg40.jpg41.jpg42.jpg43.jpg


          大數據可視化設計賞析(二)

          前端達人


              隨著大數據產業的發展,越來越多的公司開始實現數據資源的管理和應用,尤其是一些在日常生活中經常使用大屏幕的大中型企業。此時,用戶界面設計者需要呈現相應的視覺效果。接下來為大家介紹大屏可視化的UI設計。


          點擊查看原圖

           --大屏UI設計--


          3.jpg

           --大屏UI設計--


          4.jpg

           --大屏UI設計--


          5.jpg


           --大屏UI設計--





          7.jpg


           --大屏UI設計--



          8.jpg


           --大屏UI設計--



          9.jpg


           --大屏UI設計--



          點擊查看原圖

           --大屏UI設計--


          點擊查看原圖


           --大屏UI設計--




          點擊查看原圖


           --大屏UI設計--

          (圖片均來源于網絡)

            藍藍設計www.syprn.cn )是一家專注而深入的界面設計公司,為期望卓越的國內外企業提供卓越的UI界面設計、BS界面設計 、 cs界面設計 、 ipad界面設計 、 包裝設計 、 圖標定制 、 用戶體驗 、交互設計、 網站建設 、平面設計服


              更多精彩文章:

                 

           大數據可視化設計賞析(一)

            大數據可視化設計賞析(二)

            大數據可視化設計賞析(三)

            大數據可視化設計賞析(四)

            大數據可視化設計賞析(五)

            大數據可視化設計賞析(六)

            大數據可視化設計賞析(七)


          2020年最火的設計趨勢Neumorphism

          藍藍設計的小編

          藍藍注:我非常喜歡這個風格。


          日前,在網上流行起了一種叫 Neumorphism 的新風格,也有人稱為 Soft UI,這是一種類似于浮雕的效果。這種風格的出現,給目前流行的扁平化設計增加了一種新的設計形式,很多媒體甚至還將這個風格列為 2020 的設計趨勢,三星 Galaxy 系列的發布會宣傳海報也使用了這種風格,可見這個風格的火熱程度。那么一開始我們不討論這個風格好還是不好,先來了解一下這個新風格趨勢。

          什么是Neumorphism?

          最開始是一位來自烏克蘭的設計師 Alexander Plyuto 在各平臺發布了新的作品「Skeuomorph Mobile Banking」。這個作品自發布以來就獲得了數十萬瀏覽量,數千點贊數,熱度持續飆升并登上 Popular 榜首。

          作者是用 Skeuomorph 來命名這個作品風格,評論區就開始了這種風格的討論,有的人說這是新的擬物風格(New Skeuomorphism),也有人說這是擬物風格 2.0 版本(Skeuomorph 2.0),而后來就有設計師創出一個新的虛構名詞,把 New Skeuomorphism 兩個詞組合,Neo 諧音 New 就是 Neuomorphism。

          這個名字就這么火了。大家都開始用上了這個名詞出作品,成為了設計新趨勢。甚至連作者后面的作品,也使用了這個名稱。

          再后來國外知名設計師 Michal Malewicz 發布了一篇關于這個風格的文章,將 Neuomorphism,刪減了里面的字母「O」,改成了 Neumorphism。在大神的推動下大家又開始爭先恐后地使用這個名稱。

          目前有各種對名稱的說法,Neuomorphism,Neumorphism,Skeuomorphism,Soft UI,在沒有實際確定的情況下,其實怎樣叫都無所謂,重點是我們要知道這種設計風格趨勢,關注的不是名字,而是設計。

          還記得擬物風格嗎?

          既然 Neumorphism 只是一個虛構詞,也沒有任何官方認定,那就先不糾結應該叫什么,我們還是來說說它的前身吧,也就是 Skeuomorphism(擬物)。這是最早被 Apple 提出的設計概念,就是在界面中模仿現實物體紋理材質的設計,目的是讓人們在使用界面時習慣性地聯想到現實物體的使用方式。

          擬物寫實的設計風格曾經風靡全球,當時的 UI 設計師幾乎都對擬物作品著迷。

          而在 2013 年的 WWDC 大會中,蘋果公司發布的 iOS7 系統,系統 UI 使用更簡潔的設計風格。這場大會也使擬物風格逐漸過時,直到現在扁平風格的全面普及,擬物風格就再沒有被廣泛應用。

          從前幾年的設計趨勢可以看到,扁平風格作為更更簡潔的風格被設計師推崇,再加上蘋果系統 iOS 7 設計風格的面世和谷歌系統規范 Material Design 的普及,扁平風格在 UI 設計中一直占據重要位置。

          但設計的流行趨勢也一直在改變著,在蘋果公司發布的 iOS 13 系統中,就有出現輕擬物的設計手法,接著就有一大堆設計師猜測是不是擬物風格的回歸,但我看系統中大部分界面設計也還是扁平風格,并沒有把擬物風格作為主要設計風格,也許只是某種程度上解決了畫筆的視覺識別問題。

          擬物效果能否回歸,這個言之尚早,但是新的風格趨勢也許可以在扁平同質化的時候增添一點靈感與樂趣。

          能用在實際項目中嗎?

          1. 設計

          其實要做到這個效果并不難,了解一下這個風格的結構。

          主要有三個樣式組成,1 個背景+ 2 個投影。在這個基礎上,通過改變顏色和大小參數來達到不同效果。

          我嘗試著使用彩色去做這個效果,使用淺色背景時還是有效果的,但使用深一點的顏色時,問題就出現了,效果更像是外發光或者普通投影。這也可能是為什么大多數作品都采用比較素的顏色作為背景的原因。

          2. 瀏覽

          這個風格最大的問題就是缺少對比度。在色彩使用上比較克制,沒有大面積的平鋪顏色,僅在極少的位置進行色彩點綴,作用是吸引眼球。從眾多設計師的作品可以看出,整體視覺是比較平的,缺少層次。

          我拿其中兩張圖進行了 15% 強度的模糊處理,可以看到除了點綴的位置以外,界面是沒有重點的。

          3. 操作

          因為在界面中除了文字以外,幾乎所有元素都應用了這種效果,導致界面所有內容看起來都是按鈕的錯覺。界面中的主要操作按鈕也沒有被重點提亮。正常態和點擊態的對比度并沒有拉開,容易造成狀態混淆。點擊欲望比較低,不利于引導用戶進行下一步操作。

          4. 動畫

          跟擬物效果的動畫有同樣的問題,元素動畫效果很難做得輕快,更適合按鈕的使用。由于視覺層級跟背景沒有實際分離開,就像固定在了背景上一樣,所以動畫效果只要出現移動,就會讓人覺得不合理,容易給人一種蟲子在皮膚底下蠕動的感覺。

          5. 開發

          問題跟當年的擬物效果的實現類似,要實現這個風格,主要有兩個方式。

          切圖:對元素的每個狀態(Normal、Hover、Pressed),設計師都需要分別提供一張切圖,這個會導致資源庫增加大量的圖片。 代碼實現:這個風格的實現效果是對元素增加兩個不同方向的投影,通過代碼可以實現。但是需要開發對每個元素添加投影,樣式代碼增多,繁瑣的工作量,開發也不會樂意。

          附 CSS 實現新風格的網站:Neumorphism 的生成器

          綜合分析來看,這種設計風格目前在項目中推廣和實現中并不合適。

          總結

          這個風格的出現也確實給大家帶來了一個新的思考,這個風格會持續嗎?可用嗎?也許扁平風格的多年流行后,設計潮流開始往回走,但并不是直接回到擬物風格,而是在效率和視覺效果中找一個平衡點。不論這個風格的對錯,起碼引起了設計師的注意,也激發了很多設計師的靈感,就像當年擬物風格和扁平風格的討論一樣,不分對錯,設計師也不妨多留意一下這個風格,試著做一下效果圖,或許會有新的發現。

          JavaScript中的Event Loop(事件循環)機制

          seo達人

          事件循環

          JavaScript是單線程,非阻塞的

          瀏覽器的事件循環


          執行棧和事件隊列

          宏任務和微任務

          node環境下的事件循環


          和瀏覽器環境有何不同

          事件循環模型

          宏任務和微任務

          經典題目分析

          1. JavaScript是單線程,非阻塞的

          單線程:


          JavaScript的主要用途是與用戶互動,以及操作DOM。如果它是多線程的會有很多復雜的問題要處理,比如有兩個線程同時操作DOM,一個線程刪除了當前的DOM節點,一個線程是要操作當前的DOM階段,最后以哪個線程的操作為準?為了避免這種,所以JS是單線程的。即使H5提出了web worker標準,它有很多限制,受主線程控制,是主線程的子線程。


          非阻塞:通過 event loop 實現。


          2. 瀏覽器的事件循環

          執行棧和事件隊列

          為了更好地理解Event Loop,請看下圖(轉引自Philip Roberts的演講 《Help, I'm stuck in an event-loop》)

          Help, I'm stuck in an event-loop


          執行棧: 同步代碼的執行,按照順序添加到執行棧中


          function a() {

             b();

             console.log('a');

          }

          function b() {

             console.log('b')

          }

          a();

          我們可以通過使用 Loupe(Loupe是一種可視化工具,可以幫助您了解JavaScript的調用堆棧/事件循環/回調隊列如何相互影響)工具來了解上面代碼的執行情況。


          調用情況


          執行函數 a()先入棧

          a()中先執行函數 b() 函數b() 入棧

          執行函數b(), console.log('b') 入棧

          輸出 b, console.log('b')出棧

          函數b() 執行完成,出棧

          console.log('a') 入棧,執行,輸出 a, 出棧

          函數a 執行完成,出棧。

          事件隊列: 異步代碼的執行,遇到異步事件不會等待它返回結果,而是將這個事件掛起,繼續執行執行棧中的其他任務。當異步事件返回結果,將它放到事件隊列中,被放入事件隊列不會立刻執行起回調,而是等待當前執行棧中所有任務都執行完畢,主線程空閑狀態,主線程會去查找事件隊列中是否有任務,如果有,則取出排在第一位的事件,并把這個事件對應的回調放到執行棧中,然后執行其中的同步代碼。


          我們再上面代碼的基礎上添加異步事件,


          function a() {

             b();

             console.log('a');

          }

          function b() {

             console.log('b')

             setTimeout(function() {

                 console.log('c');

             }, 2000)

          }

          a();

          此時的執行過程如下

          img


          我們同時再加上點擊事件看一下運行的過程


          $.on('button', 'click', function onClick() {

             setTimeout(function timer() {

                 console.log('You clicked the button!');    

             }, 2000);

          });


          console.log("Hi!");


          setTimeout(function timeout() {

             console.log("Click the button!");

          }, 5000);


          console.log("Welcome to loupe.");

          img


          簡單用下面的圖進行一下總結


          執行棧和事件隊列


          宏任務和微任務

          為什么要引入微任務,只有一種類型的任務不行么?


          頁面渲染事件,各種IO的完成事件等隨時被添加到任務隊列中,一直會保持先進先出的原則執行,我們不能準確地控制這些事件被添加到任務隊列中的位置。但是這個時候突然有高優先級的任務需要盡快執行,那么一種類型的任務就不合適了,所以引入了微任務隊列。


          不同的異步任務被分為:宏任務和微任務

          宏任務:


          script(整體代碼)

          setTimeout()

          setInterval()

          postMessage

          I/O

          UI交互事件

          微任務:


          new Promise().then(回調)

          MutationObserver(html5 新特性)

          運行機制

          異步任務的返回結果會被放到一個任務隊列中,根據異步事件的類型,這個事件實際上會被放到對應的宏任務和微任務隊列中去。


          在當前執行棧為空時,主線程會查看微任務隊列是否有事件存在


          存在,依次執行隊列中的事件對應的回調,直到微任務隊列為空,然后去宏任務隊列中取出最前面的事件,把當前的回調加到當前指向棧。

          如果不存在,那么再去宏任務隊列中取出一個事件并把對應的回到加入當前執行棧;

          當前執行棧執行完畢后時會立刻處理所有微任務隊列中的事件,然后再去宏任務隊列中取出一個事件。同一次事件循環中,微任務永遠在宏任務之前執行。


          在事件循環中,每進行一次循環操作稱為 tick,每一次 tick 的任務處理模型是比較復雜的,但關鍵步驟如下:


          執行一個宏任務(棧中沒有就從事件隊列中獲取)

          執行過程中如果遇到微任務,就將它添加到微任務的任務隊列中

          宏任務執行完畢后,立即執行當前微任務隊列中的所有微任務(依次執行)

          當前宏任務執行完畢,開始檢查渲染,然后GUI線程接管渲染

          渲染完畢后,JS線程繼續接管,開始下一個宏任務(從事件隊列中獲?。?

          簡單總結一下執行的順序:

          執行宏任務,然后執行該宏任務產生的微任務,若微任務在執行過程中產生了新的微任務,則繼續執行微任務,微任務執行完畢后,再回到宏任務中進行下一輪循環。


          宏任務和微任務


          深入理解js事件循環機制(瀏覽器篇) 這邊文章中有個特別形象的動畫,大家可以看著理解一下。


          console.log('start')


          setTimeout(function() {

           console.log('setTimeout')

          }, 0)


          Promise.resolve().then(function() {

           console.log('promise1')

          }).then(function() {

           console.log('promise2')

          })


          console.log('end')

          瀏覽器事件循環


          全局代碼壓入執行棧執行,輸出 start

          setTimeout壓入 macrotask隊列,promise.then 回調放入 microtask隊列,最后執行 console.log('end'),輸出 end

          調用棧中的代碼執行完成(全局代碼屬于宏任務),接下來開始執行微任務隊列中的代碼,執行promise回調,輸出 promise1, promise回調函數默認返回 undefined, promise狀態變成 fulfilled ,觸發接下來的 then回調,繼續壓入 microtask隊列,此時產生了新的微任務,會接著把當前的微任務隊列執行完,此時執行第二個 promise.then回調,輸出 promise2

          此時,microtask隊列 已清空,接下來會會執行 UI渲染工作(如果有的話),然后開始下一輪 event loop, 執行 setTimeout的回調,輸出 setTimeout

          最后的執行結果如下


          start

          end

          promise1

          promise2

          setTimeout

          node環境下的事件循環

          和瀏覽器環境有何不同

          表現出的狀態與瀏覽器大致相同。不同的是 node 中有一套自己的模型。node 中事件循環的實現依賴 libuv 引擎。Node的事件循環存在幾個階段。


          如果是node10及其之前版本,microtask會在事件循環的各個階段之間執行,也就是一個階段執行完畢,就會去執行 microtask隊列中的任務。


          node版本更新到11之后,Event Loop運行原理發生了變化,一旦執行一個階段里的一個宏任務(setTimeout,setInterval和setImmediate)就立刻執行微任務隊列,跟瀏覽器趨于一致。下面例子中的代碼是按照的去進行分析的。


          事件循環模型

          ┌───────────────────────┐

          ┌─>│        timers         │

          │  └──────────┬────────────┘

          │  ┌──────────┴────────────┐

          │  │     I/O callbacks     │

          │  └──────────┬────────────┘

          │  ┌──────────┴────────────┐

          │  │     idle, prepare     │

          │  └──────────┬────────────┘      ┌───────────────┐

          │  ┌──────────┴────────────┐      │   incoming:   │

          │  │         poll          │<──connections───     │

          │  └──────────┬────────────┘      │   data, etc.  │

          │  ┌──────────┴────────────┐      └───────────────┘

          │  │        check          │

          │  └──────────┬────────────┘

          │  ┌──────────┴────────────┐

          └──┤    close callbacks    │

            └───────────────────────┘

          事件循環各階段詳解

          node中事件循環的順序


          外部輸入數據 --> 輪詢階段(poll) --> 檢查階段(check) --> 關閉事件回調階段(close callback) --> 定時器檢查階段(timer) --> I/O 事件回調階段(I/O callbacks) --> 閑置階段(idle, prepare) --> 輪詢階段...


          這些階段大致的功能如下:


          定時器檢測階段(timers): 這個階段執行定時器隊列中的回調如 setTimeout() 和 setInterval()。

          I/O事件回調階段(I/O callbacks): 這個階段執行幾乎所有的回調。但是不包括close事件,定時器和setImmediate()的回調。

          閑置階段(idle, prepare): 這個階段僅在內部使用,可以不必理會

          輪詢階段(poll): 等待新的I/O事件,node在一些特殊情況下會阻塞在這里。

          檢查階段(check): setImmediate()的回調會在這個階段執行。

          關閉事件回調階段(close callbacks): 例如socket.on('close', ...)這種close事件的回調

          poll:

          這個階段是輪詢時間,用于等待還未返回的 I/O 事件,比如服務器的回應、用戶移動鼠標等等。

          這個階段的時間會比較長。如果沒有其他異步任務要處理(比如到期的定時器),會一直停留在這個階段,等待 I/O 請求返回結果。

          check:

          該階段執行setImmediate()的回調函數。


          close:

          該階段執行關閉請求的回調函數,比如socket.on('close', ...)。


          timer階段:

          這個是定時器階段,處理setTimeout()和setInterval()的回調函數。進入這個階段后,主線程會檢查一下當前時間,是否滿足定時器的條件。如果滿足就執行回調函數,否則就離開這個階段。


          I/O callback階段:

          除了以下的回調函數,其他都在這個階段執行:


          setTimeout()和setInterval()的回調函數

          setImmediate()的回調函數

          用于關閉請求的回調函數,比如socket.on('close', ...)

          宏任務和微任務

          宏任務:


          setImmediate

          setTimeout

          setInterval

          script(整體代碼)

          I/O 操作等。

          微任務:


          process.nextTick

          new Promise().then(回調)

          Promise.nextTick, setTimeout, setImmediate的使用場景和區別

          Promise.nextTick

          process.nextTick 是一個獨立于 eventLoop 的任務隊列。

          在每一個 eventLoop 階段完成后會去檢查 nextTick 隊列,如果里面有任務,會讓這部分任務優先于微任務執行。

          是所有異步任務中最快執行的。


          setTimeout:

          setTimeout()方法是定義一個回調,并且希望這個回調在我們所指定的時間間隔后第一時間去執行。


          setImmediate:

          setImmediate()方法從意義上將是立刻執行的意思,但是實際上它卻是在一個固定的階段才會執行回調,即poll階段之后。


          經典題目分析

          一. 下面代碼輸出什么

          async function async1() {

             console.log('async1 start');

             await async2();

             console.log('async1 end');

          }

          async function async2() {

             console.log('async2');

          }

          console.log('script start');

          setTimeout(function() {

             console.log('setTimeout');

          }, 0)

          async1();

          new Promise(function(resolve) {

             console.log('promise1');

             resolve();

          }).then(function() {

             console.log('promise2');

          });

          console.log('script end');

          先執行宏任務(當前代碼塊也算是宏任務),然后執行當前宏任務產生的微任務,然后接著執行宏任務


          從上往下執行代碼,先執行同步代碼,輸出 script start

          遇到setTimeout,現把 setTimeout 的代碼放到宏任務隊列中

          執行 async1(),輸出 async1 start, 然后執行 async2(), 輸出 async2,把 async2() 后面的代碼 console.log('async1 end')放到微任務隊列中

          接著往下執行,輸出 promise1,把 .then()放到微任務隊列中;注意Promise本身是同步的立即執行函數,.then是異步執行函數

          接著往下執行, 輸出 script end。同步代碼(同時也是宏任務)執行完成,接下來開始執行剛才放到微任務中的代碼

          依次執行微任務中的代碼,依次輸出 async1 end、 promise2, 微任務中的代碼執行完成后,開始執行宏任務中的代碼,輸出 setTimeout

          最后的執行結果如下


          script start

          async1 start

          async2

          promise1

          script end

          async1 end

          promise2

          setTimeout

          二. 下面代碼輸出什么

          console.log('start');

          setTimeout(() => {

             console.log('children2');

             Promise.resolve().then(() => {

                 console.log('children3');

             })

          }, 0);


          new Promise(function(resolve, reject) {

             console.log('children4');

             setTimeout(function() {

                 console.log('children5');

                 resolve('children6')

             }, 0)

          }).then((res) => {

             console.log('children7');

             setTimeout(() => {

                 console.log(res);

             }, 0)

          })

          這道題跟上面題目不同之處在于,執行代碼會產生很多個宏任務,每個宏任務中又會產生微任務


          從上往下執行代碼,先執行同步代碼,輸出 start

          遇到setTimeout,先把 setTimeout 的代碼放到宏任務隊列①中

          接著往下執行,輸出 children4, 遇到setTimeout,先把 setTimeout 的代碼放到宏任務隊列②中,此時.then并不會被放到微任務隊列中,因為 resolve是放到 setTimeout中執行的

          代碼執行完成之后,會查找微任務隊列中的事件,發現并沒有,于是開始執行宏任務①,即第一個 setTimeout, 輸出 children2,此時,會把 Promise.resolve().then放到微任務隊列中。

          宏任務①中的代碼執行完成后,會查找微任務隊列,于是輸出 children3;然后開始執行宏任務②,即第二個 setTimeout,輸出 children5,此時將.then放到微任務隊列中。

          宏任務②中的代碼執行完成后,會查找微任務隊列,于是輸出 children7,遇到 setTimeout,放到宏任務隊列中。此時微任務執行完成,開始執行宏任務,輸出 children6;

          最后的執行結果如下


          start

          children4

          children2

          children3

          children5

          children7

          children6

          三. 下面代碼輸出什么

          const p = function() {

             return new Promise((resolve, reject) => {

                 const p1 = new Promise((resolve, reject) => {

                     setTimeout(() => {

                         resolve(1)

                     }, 0)

                     resolve(2)

                 })

                 p1.then((res) => {

                     console.log(res);

                 })

                 console.log(3);

                 resolve(4);

             })

          }



          p().then((res) => {

             console.log(res);

          })

          console.log('end');

          執行代碼,Promise本身是同步的立即執行函數,.then是異步執行函數。遇到setTimeout,先把其放入宏任務隊列中,遇到p1.then會先放到微任務隊列中,接著往下執行,輸出 3

          遇到 p().then 會先放到微任務隊列中,接著往下執行,輸出 end

          同步代碼塊執行完成后,開始執行微任務隊列中的任務,首先執行 p1.then,輸出 2, 接著執行p().then, 輸出 4

          微任務執行完成后,開始執行宏任務,setTimeout, resolve(1),但是此時 p1.then已經執行完成,此時 1不會輸出。

          最后的執行結果如下


          3

          end

          2

          4

          你可以將上述代碼中的 resolve(2)注釋掉, 此時 1才會輸出,輸出結果為 3 end 4 1。


          const p = function() {

             return new Promise((resolve, reject) => {

                 const p1 = new Promise((resolve, reject) => {

                     setTimeout(() => {

                         resolve(1)

                     }, 0)

                 })

                 p1.then((res) => {

                     console.log(res);

                 })

                 console.log(3);

                 resolve(4);

             })

          }



          p().then((res) => {

             console.log(res);

          })

          console.log('end');

          3

          end

          4

          1

          最后強烈推薦幾個非常好的講解 event loop 的視頻:


          What the heck is the event loop anyway? | Philip Roberts | JSConf EU

          Jake Archibald: In The Loop - JSConf.Asia

          大屏數據可視化設計指南

          ui設計分享達人

          可能是目前大屏數據可視化設計介紹最詳盡的一篇文章了,可以當做設計手冊使用的一篇經驗分享

          Image title


          一、基礎概念


          1、什么是數據可視化


          把相對復雜、抽象的數據通過可視的方式以人們更易理解的形式展示出來的一系列手段叫做數據可視化,數據可視化是為了更形象地表達數據內在的信息和規律,促進數據信息的傳播和應用。


          在當前新技術支持下,數據可視化除了“可視”,還可有可交流、可互動的特點。數據可視化的本質是數據空間到圖形空間的映射,是抽象數據的具象表達。

          Image title


          數據可視化作品《launchit》

          作者:Shane Mielke 

          作者寫了本書,地圖上顯示了世界各地讀者的分布情況及對應人數

          Image title


          數據可視化作品《world-drawn-by-travelers》

          作者:TripHappy

          國家之間相互連通的旅游路線,顏色越相近的國家,表明兩國家的人們互動越頻繁

          Image title


          2、什么是大屏數據可視化


          大屏數據可視化是以大屏為主要展示載體的數據可視化設計。

          “大面積、炫酷動效、豐富色彩”,大屏易在觀感上給人留下震撼印象,便于營造某些獨特氛圍、打造儀式感。電商雙11類大屏利用此特點打造了熱烈、狂歡的節日氛圍,原本看不見的數據可視化后,便能調動人的情緒、引發人的共鳴,傳遞企業文化和價值。

          Image title

          Image title


          利用面積大、可展示信息多的特點,通過關鍵信息大屏共享的方式可方便團隊討論、決策,故大屏也常用來做數據分析監測使用。大屏數據可視化目前主要有信息展示、數據分析及監控預警三大類。


          數據分析類

          圖片來源:必應;圖片作者:帆軟軟件有限公司

          Image title


          二、大屏數據可視化設計原則:設計服務需求、先總覽后細節


          設計服務需求


          大屏設計要避免為了展示而展示,排版布局、圖表選用等應服務于業務,所以大屏設計是在充分了解業務需求的基礎上進行的。那什么是業務需求呢?業務需求就是要解決的問題或達成的目標。設計師通過設計的手段幫助相關人員達成這個目標,是大屏數據可視化的價值所在。


          先總覽后細節


          大屏因為大,承載數據多,為了避免觀者迷失,大屏信息呈現要有焦點、有主次??梢酝ㄟ^對比,先把核心數據拋給用戶,待用戶理解大屏主要內容與展示邏輯后,再逐級瀏覽二三級內容。部分細節數據可暫時隱藏,用戶需要時可通過鼠標點擊等交互方式喚起。



          三、大屏可視化設計流程


          規范的流程是好結果的保證。找到一個可參考的流程,然后步步為營,就能避免很多不必要的返工,保證設計質量和項目進度。

          Image title


          1、根據業務場景抽取關鍵指標


          關鍵指標是一些概括性詞語,是對一組或者一系列數據的統稱。一般情況下,一個指標在大屏上獨占一塊區域,所以通過關鍵指標定義,我們就知道大屏上大概會顯示哪些內容以及大屏會被分為幾塊。以共享單車電子圍欄監控系統為例,這里的關鍵指標有:企業停車時長、企業違停量、熱點違停區域、車輛入欄率等。


          確定關鍵指標后,根據業務需求擬定各個指標展示的優先級(主、次、輔)。

          Image title



          2、確立指標分析維度


          “橫看成嶺側成峰”。同一個指標的數據,從不同維度分析就有不同結果。很多小伙伴做完可視化設計,發現可視化圖形并沒有準確表達自己的意圖,也沒能向觀者傳達出應有的信息,可視化圖形讓人困惑或看不懂。出現這種情況很大程度就是因為分析的維度沒有找準或定義的比較混亂。

          Image title

          上圖向大家展示了數據分析常用的4個維度,我們在選定指標后,就需要跟項目組其他小伙伴討論:我們的各個指標主要想給大家展示什么,更進一步的講,是我們想通過可視化表達什么樣的規律和信息。而上圖,可以引導我們從“聯系、分布、比較、構成”四個維度更有邏輯的思考這個問題。


          聯系:數據之間的相關性

          分布:指標里的數據主要集中在什么范圍、表現出怎樣的規律

          比較:數據之間存在何種差異、差異主要體現在哪些方面

          構成:指標里的數據都由哪幾部分組成、每部分占比如何


          當然,上圖例舉的示例圖表都比較傳統,在大屏數據可視化中常還有另一類地理信息(常以2/3D地圖、地球呈現)出現。上圖雖未包含這類圖形,但它提供給我們的確定數據分析維度的思路和方法是相通的,可借鑒。


          3、選定可視化圖表類型


          當確定好分析維度后,事實上我們所能選用的圖表類型也就基本確定了。接下來我們只需要從少數幾個圖表里篩選出最能體現我們設計意圖的那個就好了。


          選定圖表注意事項:易理解、可實現;


          易理解就是可視化設計要考慮大屏最終用戶,可視化結果應該是一看就懂,不需要思考和過度理解,因而選定圖表時要理性,避免為了視覺上的效果而選擇一些對用戶不太友好的圖形。

          Image title


          可實現


          1、我們需要了解現有數據的信息、規模、特征、聯系等,然后評估數據是否能夠支撐相應的可視化表現

          2、我們設計的圖形圖表,要開發能夠實現。實際工作中,一些可視化效果開發用代碼寫很容易實現,效果也不錯,但這些效果設計師用Ps/Ai/Ae這些工具模擬時會發現比較困難;同樣的,某些效果設計師用設計工具可以輕易實現,但開發要用代碼落地卻非常困難,所以大屏設計中跟開發常溝通非常重要,我們需要明確哪些地方設計師可以盡情發揮,哪些地方需要謹慎設計!一個項目總有周期與預算限制,不會無限期的修改迭代,所以設計師在這里需要抓住重點,有取舍,不鉆牛角尖、死磕不放。

          Image title


          4、了解物理大屏,確定設計稿尺寸

          多數情況下設計稿分辨率即被投大屏的信號源電腦屏幕的分辨率有多個信號源時,就會有多個設計稿,此時每個設計稿的尺寸即對應信號源電腦屏幕的分辨率

          Image title

          一般情況下設計稿的分辨率就是電腦的分辨率,當有多個信號源時,有時會通過顯卡自定義電腦屏幕分辨率,從而使電腦顯示分辨率不等于其物理分辨率,此時,對應設計稿的分辨率也就變成了設置后的分辨率;此外,當被投電腦分辨率長寬比與大屏物理長寬比不一致時(單信號源),也會對被投電腦屏幕分辨率做自定義調整,這種情況設計稿分辨率也會發生變化。所以設計開始前了解物理大屏長寬比很重要。



          5、頁面布局、劃分


          尺寸確立后,接下來要對設計稿進行布局和頁面的劃分。這里的劃分,主要根據我們之前定好的業務指標進行,核心業務指標安排在中間位置、占較大面積;其余的指標按優先級依次在核心指標周圍展開。一般把有關聯的指標讓其相鄰或靠近,把圖表類型相近的指標放一起,這樣能減少觀者認知上的負擔并提高信息傳遞的效率。

          Image title


          6、定義設計風格


          很多小伙伴也許沒接觸過大屏設計工作,但大多數人都應該有APP或者Web風格定義的經驗。我們在定義一款APP或者Web頁面設計風格時常用的方法是什么呢?情緒版!

          大屏雖酷炫,但實際上也是運行在瀏覽器里的Web頁面,所以大屏設計風格定義方法也同樣可以是用情緒版來做,這種方法也是目前比較科學的風格定義手段

          Image title

          上圖提供了情緒版應用的腦圖,具體操作細節不做介紹,不太了解的小伙伴可以自己找找資料哈。

          情緒版的一套流程下來,我們定義的風格基本是科學準確的,可以指導我們執行設計。如果是給甲方爸爸做大屏,這個流程也可以讓我們提出的方案更有說服力



          7、可視化設計


          根據定義好的設計風格與選定的圖表類型進行合理的可視化設計。目前來講大屏可視化主要有指標類信息點和地理類信息點兩大可視化數據。指標類信息點可視化效果相對簡單易實現,而地理類信息點一般可視化效果酷炫,但是開發相對困難,需要設計師跟開發多溝通的。地理類信息一般具有很強的空間感、豐富的粒子、流光等動效、高精度的模型和材質以及可交互實時演算等特點,所以對于被投電腦、大屏拼接器等硬件設備的性能會有要求,硬件配置不夠的情況下可能出現卡頓甚至崩潰的情況,所以這點也是需要提前溝通評估的。

          Image title


          8、樣圖溝通確認


          這里的溝通分三個層面:設計師對內溝通、設計師對外溝通、設計師與大屏的“溝通”。

          Image title

          樣圖溝通環節,最初的樣圖不需要十分精致,我們可以把它理解為一個“低保真”原型,然后通過不斷溝通修改,讓它逐步完善精致起來,也就是小步快跑,避免那種一下子走到終點,然后又大修大改的情況。


          因為我們在前幾步已經分別確定了頁面布局、圖表類型、頁面風格特點,所以這一步我們需要用盡可能簡單的方法 ,把之前幾步的成果在頁面上快速體現出來,然后根據樣圖效果嘗試確定五方面內容:

          1、之前確立的布局在放入設計內容后是否依然合適

          2、確立的圖表類型帶入數據后是否仍然客觀準確

          3、根據關鍵元素、色彩、結構、質感打造出的頁面風格是否基本傳達出了預期的氛圍和感受

          4、已有的樣式、數據內容、動效等在開發實現方面是否存在問題

          5、大屏是否存在色差、文字內容是否清晰可見、頁面是否存在變形拉伸等現象


          跟大屏“溝通”是比較重要也是個特殊的環節,這也是我覺得大屏設計跟其它設計不一樣的地方,大屏有它自己獨特的分辨率、屏幕組成、色彩顯示以及運行、展示環境,這里的很多問題只有設計稿投到大屏上才能夠被發現,所以這一步在樣圖溝通確認環節非常重要,有時候需要開發出demo,反復測試多次。



          9、頁面定稿、開發


          事實上頁面開發階段并不是到了這一步才進行,這里說的頁面開發僅指前端樣式的實現,實際上后臺數據準備工作在定義好分析指標后就已經開始進行了,而我們當前的工作是把數據接入到前端,然后用設計的樣式呈現出來。

          Image title

          切圖與標注

          由于大屏實際就是一個web頁面,所以開發階段的切圖與標注是少不了的。


          切圖:哪些元素需要切圖,怎么切?

          一般開發用代碼寫不出的樣式或動效,都需要設計師切圖作支持:比如數據容器的邊框、小的動效、頁面整體大背景、部分圖標等。切圖按正常網頁設計標準切就可以了。


          標注

          Web頁面用什么插件做標注這個大家都很熟悉,我就不多說了。需要注意的是,如果大屏頁面需要在不同比例的終端展示,那么此時的標注與開發可以使用rem作為基本單位來實現,這樣實現的大屏頁面在后期會有更好的擴展性與適應性。



          10、整體細節調優與測試


          這部分是指頁面開發完成后,將真實頁面投放到大屏進行的測試與優化。這里主要有兩部分工作。


          視覺方面的測試(有點像APP的UI走查):關鍵視覺元素、字體字號、頁面動效、圖形圖表等是否按預期顯示、有無變形、錯位等情況。


          性能與數據方面的測試:圖形圖表動畫是否流暢、數據加載、刷新有無異常;頁面長時間展示是否存在奔潰、卡死等情況;后臺控制系統能否正常切換前端頁面顯示。



          四、大屏設計的注意事項


          1、字體使用


          字體優先使用系統默認字體,需要嵌入字體時考慮字體的可識別性、與當前設計風格是否融合、是否可免費商用。

          Image title

          如果頁面是云端部署,需要嵌入字體包時,我們可以使用FontCreator這類的軟件把那些用不到的字符從字體包中刪掉,然后重新打包上傳,減小字體包大小,可以優化頁面加載體驗,避免在替換默認字體的過程中出現頁面文字跳動等現象。(一般來講一套字體文件包含了阿拉伯文、符號、拉丁文、日文、西里爾文、希臘文、拼音、注音符號等多種字符,對于大屏這個明確的場景,我們可以刪掉其它使用不到的字符,僅保留中文、拼音和數字)

          Image title

          關于字體版權獲取相關問題,公眾號回復“可視化”獲取



          2、顏色搭配


           1、色彩明度與飽和度差異顯著、對比鮮明, 盡量避免使用鄰近色配色

          Image title

          2、使用深色暗色背景:深色暗色背景可減少拼縫帶來的不適感。由于背景面積大,使用暗色背景還能夠減少屏幕色差對整體表現的影響;同時暗色背景更能聚焦視覺,也方便突出內容、做出一些流光、粒子等酷炫的效果,


          3、漸變色慎重使用:大屏普遍色域有偏差,顯示偏色,因而使用漸變色需要根據大屏反饋確定是否調整,純色最佳。



          3、頁面布局

          主次分明、條理清晰、注意留白,合理利用大屏上各小的顯示單元,并盡量避免關鍵數據被拼縫分割

          Image title



          五、Q&A


          1、設計稿投到大屏上顯示效果不佳怎么辦?

          大屏的分辨率、比例、使用環境、投射方式等均會對設計造成影響。理想情況下,我們應該在設計開始前,就能打開大屏系統做一些簡單測試。我們可以從網上收集不同設計師不同風格的大屏設計作品,然后投上去查看實際效果。因為大多數時候大屏都會存在色彩偏差,這時通過測試我們就能發現漸變色、鄰近色等不同類型的色彩搭配是否可以在目標大屏上良好呈現,如果不可以,那我們設計進行時就不要使用顯示效果不佳的色彩搭配。另一方面,樣圖溝通環節及時測試也很重要。



          2、大屏設計定稿后,切圖切幾倍圖?

          由于是將我們電腦屏幕投射到了大屏,大屏上的內容是運行在我們電腦瀏覽器上的頁面。所以切圖根據我們電腦的分辨率,正常切1倍圖就可以



          3、1920*1080的設計稿,投到9000*4320的屏幕上,文字圖片會發虛么?

          看情況,視大屏系統硬件規格與觀看距離來定。這塊有四個概念需要跟大家交流下。

          大屏邏輯分辨率(設計稿尺寸)——顯卡輸出分辨率——視頻矩陣切換器(DVI)支持分辨率——大屏實際物理分辨率。


          一般后兩個是沒問題的,大屏跟矩陣切換器是由大屏廠商提供,一般剛好配套大屏。容易問題的是顯卡輸出分辨率,我們電腦屏幕分辨率并不是最終顯卡傳遞到DVI接口的分辨率,傳遞到DVI接口的分辨率是電腦顯卡所能輸出的最大分辨率(部分電腦可設置或自定義輸出分辨率)。輸出分辨率等于DVI支持分辨率時顯示效果最佳。輸出分辨率低于DVI支持分辨率,DVI會將信號放大后傳遞到大屏,放大的過程中就有圖像信息丟失,雖然此過程中有各種算法支持去保證圖像盡可能清晰,但算法再好,跟真實圖形還是有差距的。此外,多信號源投射效果優于單個信號源投射。對于現場直播數據大屏,一般至少有兩個信號源,一個投屏,另一個也投屏但是處于備用狀態。


          離大屏的距離也影響觀感,一般離得近,顆粒感明顯,距離稍遠,會顯的較為清晰



          4、設計稿完成開發后,發現在大屏上頁面有被拉伸或者壓縮的情況,怎么補救?

          一般來講,開發只需要對設計圖做還原即可。但特殊情況下,比如顯示器擴展不正確導致頁面被拉伸或壓縮,這時就需做處理:我們可以先得到被拉伸/壓縮的比例,然后對整體視圖做壓縮/拉伸處理,再由其拉伸/壓縮,這樣被拉伸/壓縮的瑕疵就可以得到一定程度上的矯正。另外,了解被投電腦硬件特點,有的電腦可以通過自定義分辨率解決這部分問題。



          5、除自行開發可視化大屏外,還可以通過哪些第三方服務來快速實現?

          阿里云DataV、騰訊云圖、百度Sugar等



          6、數據可視化的圖表樣式可以在那些地方找到參考?

          圖表部分的二個庫是我們設計師可以打開瀏覽產看的,這里面所有的圖表樣式都是基于代碼實現的,可以作為我們設計圖表的參考,也可以讓開發拿代碼去用,或者在這些圖表的基礎修改

          工具類的需要有一定的代碼基礎,里面同樣有豐富的圖表,所以跟開發的溝通也很重要,因為他們可能會了解多一些更新的前沿的圖表形式是我們設計師不知道的,所以彼此多溝通交流是在太重要了

          Image title


          總結:數據可視化是一門龐大系統的科學,本文所有討論僅針對大屏數據可視化這一特定領域,管中窺豹,如有遺漏或不足之處歡迎大家討論交流

          轉自UI中國-BYMD


          日歷

          鏈接

          個人資料

          藍藍設計的小編 http://www.syprn.cn

          存檔

          亚洲va欧美va天堂v国产综合