最近看過我文章的都知道：我最近在負責一個微信小程序的項目，在其中遇到了很多有趣的事和一些“奇思妙想”。本文的背景就是某天早上我看著wxml文件中一堆wx:if/else和hidden突然很煩躁，先不說wx:if導致的性能問題，就是標簽上也是冗雜的。

接著上一篇文章【微信小程序自定義組件庫yPicker組件分析及省市區三級聯動實現】，在其中我分析了這么一個例子 —— 省市區三級聯動的自定義實現，在其中有詳細代碼這里就不多說，說說如何調用：

我當時是這么想的：一方面出于“不在JavaScript里寫太多東西”的考慮，另一方面，由于省、市、區我是分別用三個變量來實現的，所以JavaScript里就關注這三個變量，比如之間的空格或其它東西都拿到wxml文件里。就像這樣：

<view class="departments location" bindtap="fixedshow"> <view class="depart_title">所在位置</view> <view wx:if="{{provinces&&citys&&areas}}" class="placeholder depart_content">{{provinces}} {{citys}} {{areas}}</view> <view class="placeholder depart_content befselect" wx:else>請選擇當前位置</view> <view class="desc">如有變動請修改后再次提交</view> </view> 


    

        1
    

    

        2
    

    

        3
    

    

        4
    

    

        5
    

    

        6
    

（因為調用涉及到后來改動的只有在點擊彈窗里的“確認”按鈕時在事件中將那三個變量分別賦給這段代碼中出現的三個變量 —— 否則會只要改動不管是點取消還是確認已經發生改變了，這樣不妥！）

其布局是這樣的：

.departments{ width: 100%; height: 96rpx; display: flex; align-items: center; font-size: 36rpx; font-weight: 347; text-overflow: ellipsis; overflow: hidden; white-space: nowrap; } .location{ position: relative; border-bottom: 1rpx solid rgba(0,0,0,.009); display: flex; align-items: flex-start; padding-top: 20rpx; } .desc{ position: absolute; right: 19rpx; bottom: 4rpx; color: rgb(63,142,255); font-size: 23rpx; } .departments .depart_title{ width: 20%; } .departments .depart_content{ margin-left: 10%; text-overflow: ellipsis; overflow: hidden; white-space: nowrap; } .departments .placeholder{ width: 69%; text-overflow: ellipsis; overflow: hidden; white-space: nowrap; } 


    

        1
    

    

        2
    

    

        3
    

    

        4
    

    

        5
    

    

        6
    

    

        7
    

    

        8
    

    

        9
    

    

        10
    

    

        11
    

    

        12
    

    

        13
    

    

        14
    

    

        15
    

    

        16
    

    

        17
    

    

        18
    

    

        19
    

    

        20
    

    

        21
    

    

        22
    

    

        23
    

    

        24
    

    

        25
    

    

        26
    

    

        27
    

    

        28
    

    

        29
    

    

        30
    

    

        31
    

    

        32
    

    

        33
    

    

        34
    

    

        35
    

    

        36
    

    

        37
    

    

        38
    

    

        39
    

    

        40
    

    

        41
    

在決定了要替換這里的wx:if以后，你首先要想：用什么替換？
wx:if作用是判斷“是否存在”，如果不存在（條件不滿足）就切換到wx:else或是wx:elif的邏輯里！

OK，想到這里，你應該能想到一個css偽類：:empty ！它的作用和我們想要的效果一樣：判斷如果元素（內容）為空的話…
我迅速對代碼做了改動：

<view class="departments location" bindtap="fixedshow"> <view class="depart_title">所在位置</view> <view class="placeholder depart_content">{{provinces}} {{citys}} {{areas}}</view> <view class="desc">如有變動請修改后再次提交</view> </view> 


    

        1
    

    

        2
    

    

        3
    

    

        4
    

    

        5
    

然后在class - depart_content上加了這個偽類：

.placeholder:empty::before{ content: "請選擇當前位置"; color: rgba(0,0,0,.6); } 


    

        1
    

    

        2
    

    

        3
    

    

        4
    

一片空白！

經過查閱資料：:empty偽類表示如果標簽內容為空，那么內容區域如果帶有空格，也是不會被匹配到的！

在寫標簽時一定要注意這一點：標簽內是否有空格或換行！（換行常常被解析為一個空格）
遇到非單標簽一定注意閉合標簽！

最后解決辦法是：在js中將三個變量用空格相連接，再渲染到頁面上即可！

（其實這里是一個自定義的選擇器，而自動定位就是往高德地圖發送了請求獲取到省市區字段而已，代碼就不寫了。。。）

到這里我們會發現一個事：上面我們不僅用了empty偽類，還用了before偽元素！

其實這一點很平常 —— 畢竟只有empty是添加不了內容的（似乎縱觀css，只有before和after這樣偽元素可以向頁面中添加內容，不管是文字還是圖片之類的）

我認為更應該關注到的是兩個地方：

1. 偽元素中沒有用position定位！一般來說對一個（存在內容的）元素來說，為其設置“前置”（before）/“后置”（after）樣式都需要定位：規定其顯示的地方。不然大概率偽元素中的文字是顯示不出來的，通過本文的empty可以猜測：他被原本存在的內容覆蓋住了。
2. 從第一點可以得出：:before 和 :after 偽元素向標簽內插入內容、圖形，并不會影響empty偽類的匹配！

這個特性實用的一批。

由上，可見此偽類最大的用處就是“字段缺失提示”！這是非常實用的。而且把這項任務交給CSS也可以減輕許多“（布局）負擔”、體驗更好、維護起來也更方便！

比如：我在項目優化時就將所有有請求的字段都加上了統一類名：

.ym-empty:empty::before{ content: "暫無數據，請重試", display: block; text-align: center; color: rgba(0,0,0,.6); /** 其它定位、字體更改操作 */ }

作者：行舟客，轉載

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

接下來為大家介紹大屏可視化的UI設計。

 --大屏UI設計--

--大數據可視化ui設計賞析--

（圖片均來源于網絡）

點擊查看更多UI/UE設計案例??????

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

    更多精彩文章：

 大數據可視化設計賞析（一）

  大數據可視化設計賞析（二）

  大數據可視化設計賞析（三）

  大數據可視化設計賞析（四）

  大數據可視化設計賞析（五）

  大數據可視化設計賞析（六）

  大數據可視化設計賞析（七）

通過閱讀“地圖基礎知識及通用設計原則”，相信大家已經對地圖及其設計有了一定認知，本篇我們來了解下如何實踐。

Part 1. 上篇要點回顧

- 核心設計原則

• 符合制圖學和公眾認知

• 保證識別度

• 清晰有層次

• 細分地圖模式

• 具有品牌特性

- 元素分類

• 點元素：地名、POI等

• 線元素：道路、地鐵線、水系線、鐵路線、航線、邊界線等

• 面元素：陸地、草地、湖泊海洋、AOI等

*名詞解釋：POI, Point of Information的縮寫，即“信息點”。一個POI可以是一棟房子、一個商鋪

*名詞解釋：AOI, Area of Interest的縮寫，即“信息面”。指的是區域狀的地理實體，如醫院、小區等

Part 2. 設計背景

為了實現“讓出行更美好”的使命，今年乘客端新增了自駕導航。地圖貫穿了該產品的全流程，且首頁、路線規劃頁、導航中等場景用戶需求都不相同。然而已有的模式，從配色到信息展現，都不符合首頁地圖的場景需求，于是需要重新設計。

以下詳解設計過程。

Part 3. 設計落地

- 設計關鍵詞推導

根據自駕導航的目標，拆解出了首頁地圖的設計目標：

• 構建適合自駕場景的瀏覽地圖

• 提升地圖體驗與設計品質，提高用戶滿意度和好感度

• 打造具有滴滴品牌調性的地圖

用戶需求及習慣表明：在首頁主要是明確自身定位、查看其他位置信息，且視距基本是手持距離。那么“構建適合自駕場景的瀏覽地圖”關鍵點就在于識別度，更好的展示重點信息，保證用戶讀圖效率。

“提升地圖體驗與設計品質，打造具有滴滴品牌調性的地圖”的目標，可以通過視覺手段實現。在瀏覽場景，用戶使用地圖的時間不固定，為避免長時間瀏覽產生疲憊感，地圖配色需要更舒適，對比度也要適中。這點也與自駕導航整體的設計關鍵詞“輕量”不謀而合，于是推導出了關鍵詞輕量化、品牌感。

- 設計地圖方案

明確設計關鍵詞后，開始著手設計。關鍵詞中的輕量化、品牌感基本上決定了這款地圖的調性，識別度則重點影響信息展現。上篇提到，設計時可以把地圖元素拆分成點、線、面三類，按照由大到小的順序設計，即先確定配色，再設計文字圖標等信息，以免元素過多互相干擾。

1、設計整體配色

輕量化：傳達輕量化的感受需要控制取色范圍，于是我們制定了顏色使用規則（下圖）。

• 色相：以冷色為主，醫院（紅色系）等具有公眾認知的顏色可除外；顏色從品牌色系中選取

• 明度：限定顏色的明度范圍，選取中間-略高的部分，平衡顏色對比度

• 飽和度：避免使用高飽和度的顏色，保證配色的舒適感

通過分析顏色，我們對傳達輕量化的感受有了大致的把握。那么品牌感如何體現呢？

品牌感：具有品牌調性的地圖能更好的融入產品設計風格，也能夠區別于競品，這在滴滴全流程的設計中都十分重要。在地圖上我們主要用顏色及圖標繪制表達品牌調性。

• 顏色：結合輕量化的用色規則，從品牌色系中選取，使地圖配色與其他組件更加融合

• 圖標繪制：沿用滴滴設計規范中的圖標繪制語言，如圓角、簡單形狀等，拉齊視覺感受

最終根據“輕量化”和“品牌感”這兩個關鍵詞，設計出了地圖配色的效果圖。

2、設計地圖信息

配色確定后，即可開啟POI圖標+文字、AOI文字、道路文字、以及各類行政區劃文字的設計。

識別度：設計地圖信息時，保證基本識別度的方式，可通過文字顏色、字號大小、圖標繪制等實現。但是要做到清晰有重點，就要關注信息間的層次感。

以POI信息為例。回顧下此時的用戶需求：了解自身定位、查看其他位置信息。從這點可以鎖定第一展示優先級應為POI——地圖上定位最精準的信息種類。而已有的圖標識別度較弱，無法滿足需求，于是我們進行了重繪。通過用色表達圖標類型、首選有公眾認知的載體作為表意、增強顏色飽和度及對比度，搭配文字顏色，從視覺上把POI信息提升至第一順位。

用同樣的方法，根據重要程度，通過設計拉開了信息的視覺層級：POI>道路名稱>AOI名稱>行政區劃信息。

3、整體調整

在完成了配色和信息設計后，我們需要整合所有元素統一調整。此時，通常會出現元素互相干擾的問題，我們可以回歸到場景需求中解決此類問題，按照信息的重要程度調整，最終形成完整方案。

Part 4. 設計驗證

地圖方案落地后，我們會關注設計品質的驗證。由于地圖的工具屬性，驗證其設計品質及用戶滿意度一直是行業內較困難的事情。地圖既是一種圖形語言，又承載了大量的信息，且需符合場景需求，要驗證的內容非常多。因此我們建立了地圖評測模型，從美觀度、識別度、讀圖效率等多維度進行評測，量化地圖設計品質。

通過對自駕導航首頁地圖的兩輪調研，我們回收了大量有效結論，如用戶對道路等級的關注程度、如何使用AOI信息等等。新版地圖在美觀度、識別度等方面均得到了用戶的認可。

了解用戶的聲音，能更好的幫助我們深耕地圖設計領域、全力推動地圖體驗優化。

Part 5. 未來形態暢想

當前科技發展迅速，近些年出現的HUD、AR等導航，用現實世界的畫面代替了地圖，不需要轉換思維、記憶地圖語言，讓人與世界的連接更輕松便捷。我們不妨順著這個趨勢大膽的暢想一番，在未來的某天，世界的數據會植入我們腦中，不再有陌生的地方，現有的地圖形態也許會消失，因為它就在我們腳下。

文章來源：站酷    作者：CDX創意設計中心

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

目前基于用戶畫像的標簽體系在各行各業開始得到應用，對于涉及范圍廣，專業知識深的互聯網招聘領域來說，建立標簽體系的難點是什么呢？應該如何建立標簽體系？怎么驗證標簽體系的準確性？文章對這三個問題展開了分析探討，與大家分享。

一、招聘領域建立標簽體系的難點

電商行業客觀來說屬于比較簡單的toC領域，知識網絡是比較容易理解的通用知識，可通過用戶的購買習慣、偏好、商品品類等建立標簽體系。醫療行業屬于專業性強的領域，建立標簽體系必須要懂醫療技術的專家團隊才可以，但是易于操作的是，只需要醫療一個領域專家就可以完成專業的標簽體系建設。

但對于招聘行業來說，行業、職位涉及范圍廣，且專業性強，因為各行各業的公司和求職者都會通過招聘平臺建立聯系，而且有很多高精專的職位和候選人，怎么評估B/C端之間專業技能、工種、行業之間的匹配度，確是一大難點，而且理論上來說需要集齊各個行業、各種職位的專家人員才能建立起招聘行業的標簽體系，但這在現實中要怎么操作呢？

那么機器是否可以自動完成招聘領域的標簽體系建設呢？用NLP抽取職位JD中的描述并將其聚類，比如抽取Java、spring、Unix、Visio、Excel等工具技能，原型設計、交互設計、需求分析等工作內容技能，用戶運營、產品運營、數據運營等工作方向技能，這是互聯網從業者最熟悉的開發、產品、運營的工作內容和技能，如果機器可以識別這些類別標簽就很完美了。

但現實卻是看似的完美與和諧，萬一Java是出現在了招聘專員的職位描述中呢？用戶寫的是“負責招聘Java工程師”，假如Visio出現在Java工程師的描述中呢？假如Excel出現在運營專員的職位描述中呢？這些技能還是不是這個崗位的核心能力？

首先，Java出現在招聘專員出其實是可以用硬規則過濾掉的，比如限制職位和技能的關系，也就是說不是所有技能都滿足所有職位，有的技能只適用于某些職位，在其他職位內就是無效信息。

其次，需求分析是不是產品經理的技能標簽呢？有的人說肯定是了，這個回答可以說對也可以說不對，對是因為需求分析確實是產品的必備能力和工作內容，不對是因為所有的產品經理都需要需求分析，那這個能力還是該產品經理區別于其他產品經理的能力嗎？

最后Excel會出現在運營專員內、也會出現在招聘專員內，也會出現在統計專員內，那么它還是個核心的技能標簽嗎？

通過以上分析可得到以下歸納性的總結：

1. 不是所有技能都適用于所有的職位，應該定義每個職位的核心技能標簽體系，因為非核心的技能有時候不僅無效還會起到反作用；
2. 不是所有該職位需要的技能或者做的工作內容都是該職位的技能標簽，因為它是該崗位的通用能力沒有區別度，技能標簽應該是該職位工種的核心技能且是可以區別不同職位或簡歷的。

所以通過以上分析可知，純NLP機器識別的方式不能完成招聘領域的標簽體系建設，因為機器沒辦法在一個崗位的眾多技能中篩選出哪些是重要的知識技能，哪些是不重要的知識技能。

二、如何建立招聘領域的標簽體系

1. 基于靜態信息的通用標準化標簽

招聘領域的標簽大家首先可以想到的就是學歷、工作年限、薪資范圍等比較通用的職位/簡歷端匹配維度，當然這些顯性通用的標簽早已被各招聘平臺做成了結構化的篩選項。

其次還有一些比較小眾的維度要求，比如有的職位要求海外經歷、黨員、國企工作經歷、籍貫、年齡等，有些平臺也把其中的某些維度做成了平臺上的結構化標簽。

不過這些不是我們研究的重點，我們主要研究的是每個職位專業的知識方向的技能。

2. 基于靜態信息的專業知識精細化標簽

建立專業知識標簽體系的重點就是建立專業的崗位研究專家團隊，想要做某個崗位的專業知識標簽研究，肯定需要熟悉該崗位的人員，是選擇從事該崗位工作的人員呢，還是對這類崗位有所了解的HR人員呢？

因此就這兩類人員進行了調研與分析，最終發現從事該崗位的人雖然對所從事的崗位了解比較深入，但對其他相關的崗位未必了解，也不太了解招聘過程中用戶的感知與思維；

HR人員雖然在專業深度上對崗位的了解不是很深入，但所了解的崗位范圍廣，只要從事過某個行業的HR工作，基本都熟悉該行業所有的崗位與關注的重點技能，且HR經常使用招聘平臺，有用戶感知，對用戶行為與邏輯都非常了解，所以HR更適合做崗位專業知識研究，而且該專家團隊最好是來自各個不同行業的HR人員。

團隊建好了，大概的研究思路也有了，接下來就可以好好研究標簽體系具體的生產流程與規則了，對此進行了如下圖的總結：

體系建立的目的肯定是運用在算法的推薦與搜索中，初期可以通過離線的漏斗數據轉化對比（命中標簽與未命中標簽的轉化對比）來驗證該標簽體系的離線匹配效果，再者可通過灰度實驗，小流量上線實驗來驗證實際線上的匹配效果。

專業知識標簽關注的只是匹配度的準，最終線上使用肯定還要考慮用戶是否活躍，B端HR是否著急要人，C端求職者是否在找工作，如何平衡專業知識的準與用戶行為的活之間的權重也一大難點，要找到那個準與活平衡的比例區間，在這個區間內線上能實現最大的用戶達成，這方面在此不多做分析，需要算法同學多次調整模型才能達成。

3. 基于動態信息的用戶行為標簽

基于用戶行為的用戶畫像標簽體系在電商領域中運用廣泛，在招聘領域此類標簽體系同樣適用，只不過電商領域中的“查看-聯系賣家-購買”行為在招聘領域變成了“查看-開聊-達成約面”行為。

電商平臺中的協同過濾理論在招聘平臺也同樣適用，只是變成了基于相似職位的過濾和基于相似候選人的過濾。有的企業以往達成的多數是名校候選人，那么我們就知道該企業偏好有名校教育經歷的；有的企業招聘銷售崗更傾向于在專業知識體系中的有軟件銷售經驗的候選人，那么我們就知道該企業偏好軟件行業的銷售候選人。

通過用戶畫像體系我們可以評估用戶的偏好，以期在該用戶以后的推薦中使用其偏好，達到更好的效果。

三、招聘領域靜動態標簽體系的綜合運用

靜態通用標簽是所有職類共用的標簽特征，屬于大批量標準化的生產與運營，通用標簽生產完善了，可以實現粗礦式大步快跑節奏的匹配達成；

而專業知識標簽是每類職位專業的標簽特征，是小批量精細化的生產與運營，在前面大步快跑達到一定匹配度之后，再結合精細化的小步快跑方式，逐步將每個職類的顆粒度劃分為更精細化的顆粒度，達到更高匹配程度；

在前面標準化、精細化兩輪分類之后數據已經被分成了一個個小類，但卻沒有衡量單個用戶偏好的特征標簽，而動態的用戶行為標簽就是單個用戶個性化的偏好特征標簽，用戶的偏好有可能是通用的學歷、年限特征，也可能是專業知識中某個技術框架、某種產品品類特征。

最終，靜態標準化通用標簽、專業知識精細化標簽、動態行為個性化偏好標簽，三者相互作用、相輔相成，提升招聘領域線上效果的匹配準確度。

文章來源：人人都是產品經理    作者：艷杰

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

第三章 基本概念

3.1 語法

3.1.1 區分大小寫

1. 變量名test和Test完全不同

3.1.2 標識符：變量、函數、屬性的名字，或者函數的參數

1. 命名規則
   • 第一個字符必須是一個字母、下劃線、或者美元符號$
   • 其他字符可以是字母、下劃線、美元符號、數字
2. 采用駝峰大小寫格式：第一個字母小寫，剩下每個單詞首字母大寫。
   • for example：myName、herAge。
   • 駝峰式命名雖不是強制要求，但可以視為一種最佳實踐。

3.1.3 注釋

包括單行注釋和塊級注釋。

1. 單行注釋：以兩個斜杠開頭。如下所示：

// alert(“HelloWorld!”) 


    

        1
    

2. 塊級注釋：以一個斜杠和一個星號（/*）開頭，以一個星號和一個斜杠結尾。如下所示：

/*
這是一個
多行的
塊級注釋
*/ 


    

        1
    

    

        2
    

    

        3
    

    

        4
    

    

        5
    

3.1.4 嚴格模式

1. 定義：為JavaScript定義的一種不同的解析與執行模型。
2. 使用方法：
   • 在整個腳本中啟用嚴格模式，可以在頂部添加代碼“use strict”;。
   • 也可以在函數內部的上方包含這條編譯指示。
3. 使用效果：嚴格模式下，ECMAScript3中的一些不確定行為會得到處理，而且對某些不安全的操作也會拋出錯誤。嚴格模式下，js的執行效果會有很大不同。

3.1.5 語句

• ECMAScript中的語句以一個分號結尾，但非必需。
• 若省略分號，則由解析器確定語句的結尾。
• 建議不要省略分號，因為寫上解析器就不必要再花時間推測應該在哪里插入分號了。

3.2 關鍵字和保留字

ECMA-262描述了一組具有特定用途的關鍵字和一組不能用做標識符的保留字。

1. 關鍵字：可以用于表示控制語句的開始或結束、或用于執行特定操作等。
2. 保留字：保留字雖然在這門語言中還沒有特定的用途，但他們有可能在將來被用作關鍵字。

3.3 變量

• ECMAScript的變量是松散類型，即可以用來保存任何類型的數據。
• 定義變量時要用var操作符，后跟變量名，例如var message，當然了，也可以直接在定義的時候對變量做一個初始化，例如var message = ‘hi’ ;
• 這段的意思是變量message中保存了一個字符串“hi”。像這樣初始化變量并不會把它標記為字符串類型，初始化的過程就只是給變量賦了一個值。
• 因此，劃重點，可以在修改變量的同時修改值的類型。例如：

var message = ‘hi’ ;
message = 100 ;   //有效，但不推薦
//這個例子代表變量message一開始保存了一個字符串“hi”，然后該值又被一個數字值100取代了。 


    

        1
    

    

        2
    

    

        3
    

• 有一點需要注意，用var操作符定義的變量將成為該變量的作用域中的局部變量。也就是說如果在函數中使用var定義一個變量，那么這個變量在函數退出后就會被銷毀。例如：

function test(){
    var  message = ‘hi’ ; //局部變量
} ;
test();
alert(message); //錯誤

//為什么是錯誤？
//這里，變量message是在函數里用var定義的，當函數被調用時，就會創建該變量并為其賦值。而在此之后，這個變量會立即被銷毀。所以在執行alerat()那行代碼的時候message已經被銷毀了，因此報錯。 


    

        1
    

    

        2
    

    

        3
    

    

        4
    

    

        5
    

    

        6
    

    

        7
    

    

        8
    

那么，該怎么解決呢？

• 在函數內部省略掉var操作符，就可以創建一個全局變量，例子：

function test(){
    message = ‘hi’ ; //局部變量
} ;
test();
alert(message); // hi
//在函數內部不用var會創建全局變量。
//但我們并不提倡這種做法，因為局部作用域中定義的全局變量很難去維護。
//所以我們應該選擇在開始就定義好所有的變量。