B端組件化思考:基本規範篇

2020-12-11 人人都是產品經理

設計B端項目,我們需要思考的是如何運用組件化的思維去維護後續的迭代和優化,以及如何進行團隊的協作。而團隊化的組件規範,是良好協作的基礎。antdesign作為一種B端設計語言,是目前開源化組件非常好的。所以,在KCL項目中,我們積極推動引入antdesign的設計規範,並結合我們自己的項目特色和本身的一些設計進行了融合。

在本篇中,主要簡單闡述,我們在學習和運用antdesign過程中的一些做法和經驗,或者說一些簡單的思考和大家分享。如有不合適的地方,歡迎大家留言交流。

目錄:

  1. 字體
  2. 顏色
  3. 排版
  4. 間距
  5. 布局
  6. 導航

一、字體

字體是體系化界面設計中最基本的構成之一。我們的用戶通過文本來理解內容和完成工作,科學的字體系統將大大提升用戶的閱讀體驗及工作效率。我們選取的字體方案,是基於『動態秩序』的設計原則,結合了自然對數以及音律的規則得出的。

(備註:動態秩序-一種面向未來的極簡化哲學,其意義在於為全人類提供一種基礎性的社會發展共識。此處應當理解為在字體選取時,保證字體極簡化的前提下,尋求一種排版上的秩序性。)

我們選取字體的原則,一是針對B端項目特點,以非襯線體為主;二是儘量避免版權字體侵權,選擇開源字體;三是如上述第一段提倡的動態秩序原則,字體之間避免無規律性以及差異過大。

1. 字體家族

優秀的字體系統首先是要選擇合適的字體家族。系統項目的字體家族中優先使用系統默認的界面字體,我們同時準備了一套利於屏顯的備用字體庫,來維護在不同平臺以及瀏覽器的顯示下,字體始終保持良好的易讀性和可讀性,體現了友好、穩定和專業的特性。

如下所示:

font-family: 「Chinese Quote」, -apple-system, BlinkMacSystemFont, 「Source Han Sans」, 「PingFang SC」, 「Hiragino Sans GB」, 「Microsoft YaHei」, 「Helvetica Neue」, Helvetica, Arial, sans-serif,」Apple Color Emoji」, 「Segoe UI Emoji」, 「Segoe UI Symbol」;

上述是antdesign的推薦字體家族,但是在考慮到我們項目的特點和團隊資源情況,我們只考慮了比較常用的:蘋方簡體、思源黑以及英文的helvetica和helvetica neue、arial字體。其他推薦字體,暫沒有採用。

因為一個項目中常用的,除了banner或者推廣位,不會超過三款字體。字體種類應用過多,也會顯得系統不嚴謹。其中微軟雅黑字體,我們僅在PC端項目界面中常規敘述或內容中,會作為備用字體使用。其他用途,例如:推廣、banner時,如需採用,恐需要授權,請謹慎採用哈。

  • 中文蘋方黑體簡-優先字體思源黑體簡-備用字體冬青黑體簡-備用字體
  • 英文Helvetica Neue-優先字體Helvetica-備用字體arial-備用字體

2. 主字號

基於電腦顯示器閱讀距離(50 cm)以及最佳閱讀角度(30度),保證在多數常用顯示器上的用戶閱讀效率最佳效果,確定正文的標準字號14px。

我們初期並非採用antdesign推薦的14px,而是之前傳統經驗中的12px,可是後續發現在12px字號情況下時,對於大段文字內容時,易讀性較差。特別是我們一些商戶反饋,總是看錯。同時,在mac系統下和pc端系統下同一內容界面上內容,易讀性和可讀性的確存在差異。所以,最終我們還是採用了antdesign的推薦正文標準字號14px。

3. 字階(字號)與行高

字階(字號)和行高決定著一套字體系統的動態與秩序之美。字階(字號)是指一系列有規律的不同尺寸的字體;行高可以理解為一個包裹在字體外面的無形的盒子。

行高此處我們定義為一般排版梯度字號的1.5倍,同時建議在一個系統設計中(展示型頁面除外),字階(字號)的選擇儘量控制在 3-5 種之間,保持克制的原則。多字號時,會顯得整個頁面比較凌亂。

但是具體是將行高的排版梯度定義為字號的1.5倍,還是2倍。需要具體看項目的實際展示效果。不能一概而論。正如antdesign也說了,其一些標準只是推薦而非規定標準,是方向而不是限制。

4. 字體顏色

文本顏色如果和背景顏色太接近就會難以閱讀。考慮到無障礙設計的需求,我們參考了 WCAG 的標準,將正文文本、標題和背景色之間保持在了 7:1 以上的 AAA 級對比度。(備註:標準文字與背景對比色,色值可以按下表,也可靈活選取)

其實說真的,關於antdesign推薦的這個標準,你如果嚴格按這個來,自然也可以。不按這個,依靠體驗設計師的經驗判斷,應該也是沒有沒問題的。我們是兩個進行了一定的結合,因為對於字體的顏色,不同設計師對於其灰色的感知受限於經驗,同樣也受限於設備。所以,我們團隊在處理項目中字體顏色的時候,主要是通過這個網站來判斷大家對於顏色的把控的:https://webaim.org/resources/contrastchecker/ ,這個網站可以很明白的告知你當前字體顏色與背景之間的對比度是否達到AAA級標準。

5. 字體樣式尺寸規範

對主、次、輔助、標題、展示等類別的字體做統一的規劃,再落地到具體場景中進行微調,在視覺展現上能夠用儘量少的樣式去實現設計目的。切勿不同功能模塊的頁面同重要層級主次標題字體樣式不統一。

二、顏色

顏色在界面設計中的應用應同時具備品牌識別性以及界面設計功能性。顏色是相當感性的東西,設計中對顏色的運用首要應考慮到品牌層面的表達,此外很重要的一點是顏色的運用應達到:信息傳遞,動作指引,交互反饋,或是強化和凸現某一個元素的目的。任何顏色的選取和應用,應該是有意義的。

在中後臺系統設計中,可以將顏色分為:系統級顏色體系和產品級顏色體系。

系統級色彩體系主要定義了在中臺設計中的基礎色板、中性色板和數據可視化色板。產品級色彩體系則是在具體設計過程中,基於系統色彩進一步定義符合產品調性(橙黃)以及功能訴求的顏色(藍色、綠色、紅色)。

2.1 系統級顏色體系

基於『自然』(自然界中我們眼睛所看到的自然色)的設計價值觀,結合自然中的植物及色彩的變化,以及公司品牌標識色,選取了幾個顏色作為基色,同時加以提亮飽和度和亮度,antdesign確定的12個基礎色,我們覺得已經夠用了。

所以,我們只是依據我們公司自己的品牌調性確定了幾個我們可能會用到的顏色,確定並生成了KCL項目的基礎色。下圖所示為antdesign的推薦基色,我們只是調整了其飽和度和亮度。

2.1.1 基礎色板

(1)基礎色板生成算法:方案一

基礎色板是基於主色的基礎上,衍生而來。利用antdesign色板生成工具調色,選定主色(6號色)之後,根據色彩算法生成10中衍生色。( https://ant.design/docs/spec/colors-cn,色板生成工具)

(2)基礎色板生成算法:方案二

基礎色板是基於主色的基礎上,衍生而來。衍生規則先確定基礎色例如antdesign中的6號色,以6號色為基礎,在保持色相不變的基礎上,降低飽和度和亮度,但是這個降多少,主要是依據設計師經驗來調整。調整好一個深色,選取好一個基礎色,再選擇一個純白色。在Adobe illustrator中利用混合工具,使之形成色彩混合。最後擴展,去掉純白色,形成由淺色到深色的漸變色板。(個人經驗)

2.1.2 中性色板

中性色包含了黑、白、灰。在中後臺的網頁設計中大量使用,能夠令頁面信息具備良好的主次關係,助力閱讀體驗。下方的十個中性色,同樣可以運用上述方法設置。

2.1.3 數據可視化色板

數據可視化色彩體系是基於 Ant Design 色彩體系,並結合數據可視化特性而設計的。在數據可視化設計中,色彩的運用原則上應首先考慮準確性,先保證達到了信息傳遞、操作指引、交互反饋,或是強化、凸顯某一個信息的目的,其次再去考慮品牌識別性。下方連結是關於antdesign中關於數據可視化的,https://antv.gitee.io/zh/docs/specification/principles/visual,具體可以去antV查看相關運用。

因為我們項目中涉及的可視化圖表比較少,我們幾乎就是嚴格按照antV的原則規範進行的。後續限於資源配置,已經全部剔除數據化部分,改為另外一個項目只做可視化部分,所以,在本系統規範中,就不做過多數據可視化的規範介紹,後續有機會再來一片專門聊聊數據可視化規範的。

2.2 產品級顏色體系

2.2.1 品牌色應用

品牌色是體現產品特性和傳播理念最直觀的視覺元素之一。在色彩選取時,需要先明確品牌色在界面中的使用場景及範圍。在基礎色板中選擇主色,建議選擇色板從淺自深的第六個顏色作為主色。

KCL後臺項目選取的基色是基於antdesign推薦的顏色基礎上,進行了飽和度和亮度的調整,並運用防範一方法生成了一個主色的10個色號和輔助色兩個的10個色號。主色的應用場景包括:關鍵行動點,操作狀態、重要信息高亮,圖形化等場景。其他前端展示類業務場景不得偏離品牌基色,可以根據需求,重新選取輔助色,進行規範設計。

2.2.2 功能色應用

功能色代表了明確的信息以及狀態,比如成功、出錯、失敗、提醒、連結等。功能色的選取需要遵守用戶對色彩的基本認知。所謂用戶對色彩的基本認知,即用戶對色彩的情感心理,例如:紅色雖然從色彩心理上代表熱情、熱鬧,但同時也具有危險、提醒的含義。

2.2.3 中性色應用

中性色主要被大量的應用在界面的文字部分,以及背景、邊框、分割線、等場景中。產品中性色的定義需要考慮深色背景以及淺色背景的差異,同時需結合 WCAG 2.0 標準(4.5:1 最小對比度(AA 級))。所以,中性色在產品應用過程中以透明度的方式進行應用。(在人力或團隊無法顧及情況下,文字色彩可只選擇文字樣式中顏色應用,背景及線框等可以靈活選取合適的不超過三種色值。)

三、排版

良好的排版規範能大大提升用戶的視覺體驗。排版的基本原則,對齊、對比、重複。在後臺項目的設計過程中,做好設計頁面的排版已經相當於做好了一半了。所以,我們必須確定頁面的排版設計原則和細節。

3.1 行高和段落

考慮到閱讀的舒適度和節奏感,句子和段落間需要合適的間距。行高決定了段落中各行文字的垂直距離,我們通過字體本身默認A字號的1.5倍來控制行高。段落間距決定了段落上下的間距一般為字號的一倍寬。但是是否採取antdesign推薦的字號的一倍寬為段間距,1.5倍來顯示行高,需要結合具體的項目特點來做決定。最初我們採取的是一倍,但是後續經過對比發現一倍間距,並不合適。

3.2 標點和空格

  1. 使用全形中文標點;
  2. 遇到完整的英文整句、特殊名詞等內容時使用半角英文標點;
  3. 數字內容使用半角英文標點;
  4. 中文與英文之間使用空格間隔;
  5. 數字與單位之間使用空格間隔;
  6. 中文連結之間使用空格間隔。

3.3 基礎對齊

3.3.1 中文/英文居左對齊

中文和英文均採用左對齊的方式,因為現代閱讀的順序一般是自左向右,呈「Z「字形。

3.3.2 數字/小數點對齊

數字通常採用右對齊或小數點對齊,這樣便於對個十百千位上的數字進行對比。

3.3.3 冒號對齊

以冒號對齊的方式在表單中尤其常見,主要是為了區分標題和內容區塊,除了美觀簡潔外,還能讓用戶迅速看清標題減少出錯概率。

但是是否當有冒號的時候,一定要按照冒號對齊呢?

不一定的,正如antdesign所言,其推薦是引導,非標準。

我們在KCL項目中,就並沒有採用以冒號對齊。在上一篇推文中也有所闡述,以冒號對齊的時候,由於是雙列多行,所以,用戶在填寫的時候,感覺非常凌亂,不知道該先填寫什麼?考慮成本比較高。

3.4 表單排列

3.4.1 組合輸入框

當兩個輸入框關聯性很強時,可以前後拼接,減少頁面空間。

3.4.2 組合對齊

在頁面設計表單時,按鈕組必須和輸入框左對齊。

組合輸入框不僅僅是頁面內的,還有內容承載的彈窗也會有相關組合輸入框的輸入選擇。我們在考慮組合對齊時,當然也可以全部居中對齊,但是那種排版布局方式,局限性非常明顯,頁面的版率非常低。

3.5 對齊方式

無論左對齊、右對齊還是頂部對齊,都有其優缺點和應用場景。所以正確的解決方案取決於具體目標和制約因素,諸如:希望用戶加快或者降低填寫速度(有時設計者希望用戶深思熟慮每個輸入框內容)、屏幕顯示的限制、本地化考慮等多種因素。

3.5.1 右對齊-冒號對齊(推薦)

優點:節約垂直空間

缺點:降低可讀性,標籤長度和輸入框彈性小

場景:既要減少垂直空間,又要加快填寫速度

3.5.2 左對齊

優點:文字開頭按閱讀視線對齊,方便閱讀,節約垂直空間。

缺點:填寫速度慢,標籤長度和輸入框彈性小。

場景:希望用戶放慢速度,仔細思考表單中的每個輸入框。

antdesign設計中沒有推薦這種,推薦的是右對齊的方式。但是在KCL項目中,並沒有和antdesign一樣,我們採取的是左對齊方式。因為,我們設計時是以1920寬為設計標準的,所以在信息排列時,考慮的主要是兩列排版布局。如果採用右對齊的方式整個頁面看起來特別凌亂,極難讀取。右對齊方式,比較適合單列排版布局的方式。

3.5.3 頂對齊

優點:有最快的瀏覽和處理速度,標籤長度彈性大。

缺點:非常佔垂直空間。

場景:希望用戶快速填寫表單完成任務。

四、間距

間距的設置,一方面是為了規範頁面的布局;另一方面,也是為了在閱讀體驗上,呈現一定的韻律和節奏。最重要的是增加內容的易讀性和可讀性,避免文字內容識別性差。

4.1 橫向空間間距關係

橫向空間以柵格系統方法進行空間寬度的分割,同時結合橫向空間間距類型進行應用。在這三種規格不適用的情況下,可以通過加減『基礎間距』的倍數,或者增加元素來拉開信息層次。y=8+8*n。其中,n>=0,y 是縱向間距,8 是『基礎間距』。

4.2 縱向空間間距關係

縱向空間同樣以柵格系統方法進行空間寬度的分割,但以最小單元8px為最小分割單位,同時結合縱向空間間距類型進行應用。在這三種規格不適用的情況下,可以通過加減『基礎間距』的倍數,或者增加元素來拉開信息層次。y=8+8*n,其中,n>=0,y 是縱向間距,8 是『基礎間距』。

典型表單間距規範示例:

4.3 容器規範

容器組件,可以方便快速的搭建頁面的布局。為保持設計的一致性,應該為頁面設定了統一的容器範圍,讓信息能保持在固定的置,在頁面跳轉的時1不至於出現內容閃動。容器是用來收納盒組織對象的貯存器,理論上信息不應該超出容器範圍。

五、布局

空間布局是體系化視覺設計的起點,和傳統的平面設計的不同之處在於,UI界面的布局空間要基於『動態、體系化』的角度出發展開。受教於建築界大師柯布西耶的模度思想的啟發,基於『秩序之美』的原則,探索 UI 設計中的動態空間秩序,形成了界面的布局方式,為設計者構築具備「理性之美」的布局空間創造了條件。

關於布局結構是先確定,還是如本文目錄結構,先確定一些基礎規範細節之後,考慮布局方式,我的看法是都可以。其實還有個最重要的原因,有時候,團隊討論的布局結構,很有可能是無話語權的,特別是中小型團隊來說。所以,如果可能將比較重大的影響因素,推後到有話語權的人一起討論的時候,再確定。

5.1 上下布局

常被用於上下布局的設計方案中,做法是對兩邊留白區域進行最小值的定義,當留白區域到達限定值之後再對中間的主內容區域進行動態縮放。

5.2 左右布局

常被用於左右布局的設計方案中,常見的做法是將左邊的導航欄固定,對右邊的工作區域進行動態縮放。

5.3 柵格系統

antdesign設計語言中,後臺界面畫板推薦統一設定1440PX寬度,向下自適應1366PX,向上自適應1920PX。最低適配到1366PX,至於少部分1280PX,暫不做考慮。本系統界面採用24柵格體系,例如上下布局結構中,1440PX上下布局為例,將1168PX的內容區域 進行 24 柵格的劃分設置。我們為頁面中柵格的 Gutter 設定了定值,即瀏覽器在一定範圍擴大或縮小,柵格的 Column 寬度會隨之擴大或縮小,但 Gutter 的寬度值固定不變。

備註:

  1. 清晰的定義動態布局範圍;
  2. 儘量保持偶數思維;
  3. 關鍵數據的交付(Gutter、Column);
  4. 區塊的定義要從 column 開始到 column 結束。

5.5 UI模度

UI 模度是在大量的實踐中,提取出來可以用於UI布局空間決策的數組,他們都保持了 8 倍數的原則、具備動態的韻律感。經過驗證,可以在一定程度上幫助我們更快更好的實現布局空間上的設計決策。

上述模度數,只是一個參考,總的一個思想應該是8的倍數來的。和我們上述間距表述一致。其實8倍原則也是做界面設計的一個常用原則,原因在於與開發對接的時候好切圖和適配。

六、導航

在廣義上,任何告知用戶他在哪裡,他能去什麼地方以及如何到達那裡的方式,都可以稱之為導航。麵包屑導航、卡片式導航、標籤導航等。

6.1 導航菜單

導航菜單是將內容信息友好地展示給用戶的有效方式。在確定好網站的信息架構後,應當按需選取適當的導航菜單樣式。

6.1.1 頂部導航菜單

一二級導航都在頂部。頂部導航在頁面布局上採用的是上下的結構,一般主導航放置於頁面的頂端,從左自右依次為logo、一級導航項、輔助菜單、用戶、設置、通知等)。通常將內容放在固定尺寸(例如:1200Px)內。整個頁面排版穩定,不受用戶終端顯示器影響 ;上下級的結構符合用上下瀏覽的習慣,也是較為經l的網站導航模式。

頁面上下切分的方式提高了主工作區域的信息展示效率,但在縱向空間上會有一些犧牲。此外,由於導航欄水平空間的限制,不適合那些一級導航項很多的信息結構。

6.1.2 麵包屑導航

麵包屑導航的作用是告訴用戶當前頁面在系統層級結構中的位置以及父子級頁面間的關係。(注意事項:1. 層級過深時,建議做隱藏處理,頁面顯示保持在三級以內,最多不宜超過五級;2. 儘可能不使用麵包屑,尤其是當前頁面的導航能清晰的告訴用戶他在哪裡時。)

6.1.3 側邊導航菜單

一級導航菜單在側邊欄。側邊導航在頁面布局上採用的是左右的結構,一般主導航放置於頁面的左側固定位置,輔助菜單放置於工作區頂部。內容根據瀏覽器終端進行自適應,能提高橫向空間的使用率,但是整個頁面排版不穩定。

側邊導航的模式層級擴展性強,一、二、三級導航項目可以更為順暢且具關聯性的被展示,同時側邊導航可以固定,使得用戶在操作和瀏覽中可以快速的定位和切換當前位置,有很高的操作效率。但這類導航橫向頁面內容的空間會被犧牲一部分,側邊導航的級別最多三層,最終路徑導航,均採用側滑窗口的形式展示,內容呈現在主體內容區域之上,側滑窗寬度固定240PX。

6.1.3.1 側邊導航可收起菜單+多窗口

該版本導航組合是KCL初版採用方式,之所以不適合當前項目,主要原因在於KCL項目菜單並不複雜,且無多開窗口的需求,其實質是側邊導航的另外一種交互方式。

6.1.5 頂部一級二級導航+側邊三級導航(三級仍然從屬於二級導航,另外一種是直接在下拉二級旁邊顯示三級導航)

改版的一方案就是6.1.5頂部一級+側邊二級布局方式(一級導航無下拉選項,點擊一級導航之後側邊欄顯示二級導航,一級導航相當於標籤功能),但是這種方式並沒有提升用戶的使用效率,反而增加了使用成本和負擔。主要是當時將一級所從屬的二級導航直接割裂到了左側導航欄,而原本的一級導航欄變成了切換標籤的功能。

所以,為了便於全部展示,採取的是側邊導航布局即6.1.3布局方式,具體原因如上所述。還有一個原因是我們在後臺項目中同樣嘗試運用設計風格以及承載的內容數據不複雜,對於橫向空間需求不是特別高。

其中部分內容出於職業經驗,如有不妥,歡迎留言交流。

 

作者:PGDWORKS;公眾號:PGDWORKS

本文由 @PGDWORKS 原創發布於人人都是產品經理,未經許可,禁止轉載

題圖來自 Unsplash,基於 CC0 協議

相關焦點

  • 設計規範 | Web端設計組件篇-反饋類
    設計規範中最重要的部分就是組件規範了,制定組件的規範有哪些好處呢?高效簡單:熟悉了解組件的用法之後,在做界面設計時,只需要合理運用組件就可以快速搭建web端界面,高效無差錯。由於有成套的組件規範,所以在互動設計和視覺設計過程中無需每次都重複勞動。
  • B端交互界面基礎組件——表格
    編輯導語:在我們的日常工作中經常會用到表格,表格的功能可以讓我們很清晰快捷的了解當前情況,設計一個好的表格也能大大的提升我們的工作效率;本文作者分享了關於B端交互界面基礎組件表格的設計,我們一起來看一下。
  • B端交互組件之:表單篇
    表單也是最常用的信息錄入的工具,隨著網際網路興起,特別是最近幾年B端的興起,表單的重要性越來越突出。那麼我們應該如何設置表單,才能提高效率呢?引言:交互主要指人機互動,說的是人與機器之間的互動,而這個機器又特指計算機;人對機器發出指令,然後機器做出反應,並通過顯示器反饋給人。
  • B端體驗設計中關於篩選的一點思考
    最近一段時間 ,一直在接觸B端類項目的體驗設計。經過幾個不同的項目,發現設師幾乎都是直接用組件,很少有個性定製的模塊。因為有些模塊就屬於換湯不換藥。是否可以考慮換一種設計方式,考慮有沒有其他的形式會更適合?仔細分析之後,其實沒有必要。
  • B端UI界面交互基礎組件:會話框
    導語:在前一篇文章《B端UI界面交互基礎組件-表單》中,一起學習了B端「表單」組件UI設計規範,其中包括「基礎表單」、「全頁表單」;並從表單組件的需求場景、內容布局以及交互方式等方面對以上組件進行了詳盡的規範描述;今天我們繼續介紹了B端「會話框」組件的交互規範。一、基礎會話框1.
  • 2020年5個最佳Vue移動端組件庫|UI框架
    小夥伴們平時開發vue,react或是angular項目,都喜歡使用的什麼UI組件庫呢?今天,就來盤點下,幾個熱門優質的Vue.js移動端UI組件庫。1、Mint UI餓了麼開源的移動端UI組件庫,基於vue.js的移動端UI框架,包含豐富的 CSS 和 JS 組件,能夠滿足日常的移動端開發需求。
  • Android徹底組件化方案實踐
    而實際上組件化的目標之一就是降低整體(app)與器官(組件)的依賴關係,缺少任何一個器官app都是可以存在並正常運行的。頭和胳膊可以單獨存在嗎?左圖也沒有說明白,其實答案應該是肯定的。每個器官(組件)可以在補足一些基本功能之後都是可以獨立存活的。這個是組件化的第二個目標:組件可以單獨運行。組件化和插件化可以都用右圖來表示嗎?
  • IM開發乾貨分享:有贊移動端IM的組件化SDK架構設計實踐
    本文由有贊技術團隊原創分享,原題「有贊 APP IM SDK 組件架構設計」,即時通訊網收錄時有修訂和改動,感謝原作者的無私分享。1、引言本文主要以Android客戶端為例,記錄了有贊旗下 App 中使用自研 IM,並將IM提煉成組件化SDK的設計思路。
  • 【第2065期】做B端後臺產品很複雜?一份完整的設計流程和規範!
    正文從這開始~~畢業兩年來一直都做著 B 端產品的 UI 設計工作,參與過的後臺產品設計面對的主要客戶有公司內部、各大企業以及政府機構。工作和學習的過程中走過不少彎路,也在不同的項目中不斷反思和總結。今天把自己的一些想法和經驗分享出來,總結自己工作中遇到的問題和解決的方法,記錄自己思考和理解的過程,也希望對即將或正在從事 B 端後臺產品設計的你有一點點啟發或幫助。
  • 設計規範 | Web端設計組件篇-文本與選擇器
    使用場景:1.用戶需要輸入字符時2.通過滑鼠鍵盤輸入內容3.輸入的文本通常置於輸入框例如網易考拉優惠券兌換的表單填寫,就是短文本輸入組件,前面是標題,後面是文本輸入框。 input短文本組件的展示形式可以分為三類。第1類是標題和輸入框左右排列;第二類是標題和輸入框上下排列;第三列不需要標題的排列。
  • Android徹底組件化(二)-Demo發布
    有感於此,我覺得很有必要設計一套完整的組件化方案,經過幾周的思考,反覆的推倒重建,終於形成了一個完整的思路,整理在我的第一篇文章中Android徹底組件化方案實踐。這兩個月以來,得到的Android團隊按照這個方案開始了組件化的拆分,經過兩期的努力,目前已經拆分兩個大的業務組件以及數個底層lib庫,並對之前的方案進行了一些完善。
  • C端&B端產品的差異及設計思考
    文章針對B端產品和C端產品的差異展開分享,並分享了在做這兩類產品時的一些設計思考。畢竟C端產品面向的人群更廣泛,受眾面更大。而當下的設計師也多是從C端流動轉向去做B端產品的,所以今天,我想和大家聊一聊B端產品和C端產品的差異,以及在做這兩類產品時的一些設計思考。先做個名詞解釋:C有釋義為:Consumer、Client;本文中取「Consumer」,意為消費者、個人用戶或終端用戶,使用的是客戶端。
  • 專家訪談:亟待規範——從應用角度談組件尺寸及版型設計標準化
    毋庸置疑,矽片和組件尺寸加大,有利於降低矽片、電池和組件企業的製造成本;多數情況下,也可以提高應用端單位土地面積的能量密度,進而降低 BOSS成本。另外,針對組件運輸條件限制,企業也可以通過版型設計加以解決。
  • B端產品C端化戰略探索(二):如何具體落地?
    在上一篇文章中,主要從「策略級體系復用、功能級架構搭建、交互級習慣培養」三個方面闡述了B端產品C端化探索路徑。本文則從產品決策、產品形態、用戶體驗三點,探索B端產品C端化思維可落地到具體工作中的實操演練。
  • Android徹底組件化方案實踐,附Demo
    而實際上組件化的目標之一就是降低整體(app)與器官(組件)的依賴關係,缺少任何一個器官app都是可以存在並正常運行的。頭和胳膊可以單獨存在嗎?左圖也沒有說明白,其實答案應該是肯定的。每個器官(組件)可以在補足一些基本功能之後都是可以獨立存活的。這個是組件化的第二個目標:組件可以單獨運行。
  • Android組件化和插件化的概念
    一、什麼是組件化和插件化 組件化: 就是將一個app分成多個模塊,每個模塊都是一個組件(Module),開發的過程中我們可以讓這些組件相互依賴或者單獨調試部分組件等,但是最終發布的時候是將這些組件合併成一個apk,這就是組件化開發。
  • 利用Symbol 建立一套設計規範組件庫?
    「 解構 」通用類設計規範包含:基礎規範、圖標規範、組件規範,第一步,將這三類規範一一解構。例:基礎規範解構為文字規範、顏色規範、布局規範…「 拆分 」將解構後的規範拆分為最基本的元素 Symbol,基礎規範與圖標規範到這一步就完成了。
  • AlloyTeam:致我們終將組件化的 Web (多圖)
    Custom Element 對外提供組件的標籤,實現自定義標籤4. import解決組件結合和依賴加載組件化實踐方案官方的標準看完了,我們思考一下。一份真正成熟可靠的組件化方案,需要具備的能力。>接口規範化」—— 組件接口有統一規範,或者是生命周期的管理個人認為,模板能力是基礎能力,跟是否組件化沒有強聯繫,所以沒有提出一個大點。
  • B端設計|全方位講解下字體設計規範
    第二篇,我們就要回到 UI 整個類目裡最麻煩,也是最重要的規範類型——字體。
  • B端設計指南 - 選擇錄入 01
    在前兩篇文章中,我們主要講到 B 端產品最為重要的信息展示組件