CSS Variable 即CSS變量，聊CSS變量之前，我想先來說說Sass和Less,還有Stylus，它們都是目前使用較為普遍的三款CSS預(yù)處理框架，我們?yōu)槭裁匆褂盟鼈兡兀驗樗鼈兌伎梢宰屇阍贑SS中方便的使用變量、簡單的程序邏輯、函數(shù)等在編程時使用的一些基本技巧，這些框架對于這種CSS預(yù)處理的技術(shù)已經(jīng)非常成熟，可以讓你的CSS代碼變的更加簡潔、便于維護、在編寫的時候也無需考慮代碼的兼容性。

Janilychen：以往做一些H5的運營項目，都是動畫設(shè)計師使用Animate cc（原來的Flash）先設(shè)計好動畫原型，然后交給我們UI開發(fā)來實現(xiàn)。做過動畫開發(fā)的童鞋都知道動畫開發(fā)都是比較耗費時間精力的，而且還要高質(zhì)量的還原動畫設(shè)計師設(shè)計好的動畫，來回溝通成本也非常高。

那有沒有一種的方法來改善這種流程，提高開發(fā)效率的同時還能完成高品質(zhì)的動畫呢？

經(jīng)過一段時間的摸索，發(fā)現(xiàn)AnimateCC（就是原來的Flash）可以導(dǎo)出canvas動畫，而且是基于createjs這個開發(fā)輕量級游戲的js庫的，非常適合用來做移動端的一些h5動畫。不僅縮短制作動畫所需要的時間。同時它也是一個可視化的IDE，不需要編寫代碼就可以完成高品質(zhì)的動畫效果；還可以通過Javascript，為動畫效果添加交互性。

用戶真的有通過電臺App來跑步的需求嗎？

這是我們在規(guī)劃這個產(chǎn)品功能時的第一個問題。即使在音樂類軟件都已經(jīng)上線了跑步相關(guān)功能的當(dāng)下，我們依然發(fā)問——真的有人，通過電臺App來跑步嗎？

如果僅僅是針對現(xiàn)在電臺類App，那需求一定是微乎其微，不同于音樂統(tǒng)一的內(nèi)容屬性，電臺類內(nèi)容屬性太豐富——音樂時間短，小說時間長；相聲很搞笑，新聞很嚴(yán)肅······這些內(nèi)容決定了他們天然就不能像音樂一樣隨機重組。

有時候我們需要退一步來思考需求。

2016年末，各路APP也紛紛展開一輪輪的數(shù)據(jù)廝殺，從不同的視角闡述過去一年的精彩故事。而坐擁龐大用戶數(shù)據(jù)的QQ空間，在這個既難忘又不舍的2016年，用戶的故事將會被如何演繹，在寒冬帶給用戶怎樣的溫暖回憶呢？

幾個星期前，CSS Variables ——CSS 變量草案發(fā)布在了W3C官方 ,更準(zhǔn)確的應(yīng)該叫CSS 自定義屬性，目前在Chrome Canary 版里面已經(jīng)支持，開啟該功能見附[1]

當(dāng)Chrome瀏覽器工程師Addy Osmani第一時間把這消息發(fā)布在twitter后，遭到了數(shù)萬人的否定、敵視和懷疑。于我而言，更多的感到是一個驚喜，因為這個功能實在讓人太興奮了。

快速的掃了一遍之后，發(fā)現(xiàn)99%人抱怨的無外乎這兩點：

• 語法太丑和不夠簡潔
• Sass 、Less早就有這些玩意了，不太care

雖然我承認(rèn)我也對這語法很反感，更重要的是理解語法不只是反復(fù)無常的在選擇。CSS工作組討論很久語法的長度，他們提取了一些點，考慮到CSS的語法兼容不會與未來增加的其他語言沖突。

下劃線 一般在文檔中常被用作增強注意，在過去打字機時代，下劃線成為了唯一的一種文字強調(diào)方式，具體的操作方法是在已經(jīng)打出來的文字上面退格，再在同樣的地方打出下劃線。

而在網(wǎng)頁中，可以鏈接的文字（超鏈接）下面一般都有下劃線。在制作頁面的時候，當(dāng)鏈接需要下劃線的時候，UI開發(fā)很自然的會想到使用text-decoration屬性來顯示，例如這樣：

以上顯示的是設(shè)計稿和瀏覽器渲染的實際效果，我們會發(fā)現(xiàn)瀏覽器渲染的效果和設(shè)計稿有出入，主要表現(xiàn)在下劃線的位置，這時候細(xì)心的設(shè)計師會要求你想辦法實現(xiàn)他們本來想要實現(xiàn)的效果。可惜的是，在這幾年的網(wǎng)頁排版技術(shù)發(fā)展中，并沒有更好的css屬性出現(xiàn)來支持下劃線的個性化設(shè)置，所以這個問題常常會被忽略。

這個一般在UI開發(fā)看來，可能覺得并沒有什么問題，難道說不應(yīng)該使用text-decoration這個屬性嗎？

以往拿到一份視覺稿要做頁面適配，通常都是針對不同分辨率尺寸做斷點寫 media
query，然后看效果再微調(diào)。開發(fā)過程中視覺稿要是做了修改，修改的地方就得再走一遍分辨率測試和微調(diào)，這時想屎的心都有了。而且這些適配都是建立在已
知的分辨率尺寸庫上，如果市面新出來一款分辨率尺寸機型，呵呵，又要奔跑在測試微調(diào)路上。是不是能有用一套代碼就適應(yīng)各種分辨率窗口，那么就不會再有上面
這些煩惱，且開發(fā)效率快和維護成本會降低很多。

如果您想訂閱本博客內(nèi)容，每天自動發(fā)到您的郵箱中， 請點這里

近期，我們對微云WEB端進行了一次“簡單”的改版。這篇文章簡要記錄了改版過程中的一些思考。

為什么要改版

微云WEB端與移動端體驗不一致。移動互聯(lián)網(wǎng)背景下，項目團隊把多數(shù)資源都分配給了移動端的研發(fā)，桌面端的功能和體驗得不到及時的跟進，導(dǎo)致用戶在兩個平臺上的體驗存在很大的落差。

微云WEB端的設(shè)計較為陳舊。蘋果iOS的快速發(fā)展使得整個UI設(shè)計行業(yè)日新月異，設(shè)計理念不斷進化向前，微云WEB端的設(shè)計已經(jīng)多年未更新，早已經(jīng)不起當(dāng)下設(shè)計原則的檢驗。

改版前的思考

兩端的體驗對齊需要解決很多矛盾。想要將WEB端的體驗與移動端統(tǒng)一，并沒有想象中的那么簡單。聽起來好像只要把交互框架和視覺風(fēng)格直接照搬過來就好了。但實際上要對齊的是兩種使用場景的體驗，這中間要調(diào)和的是小屏幕和大屏幕的矛盾，觸摸操作和鍵鼠操作的矛盾，兩種不同概念模式和心智模型的矛盾。

新的設(shè)計除了符合潮流，還要更具前瞻性 。想要做出可持續(xù)的設(shè)計，首先要明確設(shè)計潮流的走向，從擬物到扁平，從形式到內(nèi)容，從工具化到情感化，設(shè)計潮流的走向一直沒有變，在以人為中心的前提下，越來越注重用戶更深層的需求。

項目團隊在WEB端的資源投入注定了設(shè)計更新迭代的頻率會很低。想要改版后的設(shè)計能夠長久地支撐產(chǎn)品的發(fā)展，需要設(shè)計師把眼光放遠，通過了解產(chǎn)品未來發(fā)展方向，做出更有前瞻性的設(shè)計。

求同存異的兩端統(tǒng)一

品牌統(tǒng)一性

在設(shè)計一款產(chǎn)品不同平臺客戶端的時候，首先要保證品牌的統(tǒng)一性。Logo、字體、品牌色、品牌調(diào)性甚至是文案的措辭規(guī)范都是需要嚴(yán)格保持一致的。保證品牌的統(tǒng)一性，有助于塑造品牌形象，增強用戶對產(chǎn)品的信任。

交互框架的對齊

我們先來對比一下移動端和WEB端的主界面，單純從視覺上，已經(jīng)很難看出這是同一款產(chǎn)品。雖然在頁面結(jié)構(gòu)上兩端并不一致，但各自也都符合所在平臺用戶的操作習(xí)慣。

舊版WEB端雖然在視覺風(fēng)格上是扁平的，但是在信息層級上卻并不扁平，僅僅頂部的信息就有三層，過度的結(jié)構(gòu)化使整體頁面看起來過于復(fù)雜，用戶很難將注意力集中到內(nèi)容上。我們對WEB端頂部元素重新歸類整合，主要功能入口的布局和移動端進行了統(tǒng)一，通過引入移動端的編輯態(tài)邏輯，常態(tài)下隱藏了所有的操作按鈕，將頂部區(qū)域的三層信息減少為一層，使其看起來更加清爽。

正如上面所說，雖然我們追求多端統(tǒng)一的用戶體驗，但手機和電腦的操作場景差別很大，用戶在不同的平臺已經(jīng)形成了不同的操作習(xí)慣。移動端的多級導(dǎo)航設(shè)計是針對小屏幕局限性做出的一種妥協(xié)。在空間足夠大的WEB端，所有的二級導(dǎo)航都可以平鋪出來，這樣可以減少一個層級，因此，我們保留了原有的左導(dǎo)航結(jié)構(gòu)。通過對導(dǎo)航項歸類的方式與移動端統(tǒng)一。

品牌調(diào)性和視覺風(fēng)格的對齊

在視覺風(fēng)格上，微云移動端最具代表性的就是藍色的品牌色和線型的圖標(biāo)， 在嘗試設(shè)計方案的過程中我們發(fā)現(xiàn)，由于WEB端尺寸比較大，大面積使用藍色會加重用戶的視覺負(fù)擔(dān)，分散用戶對內(nèi)容信息的注意力，因此，在色彩方案上最終選擇了純白淺灰作為主色，藍色作為局部點綴，以下是改版后的一些核心頁面。

秉承著簡潔、自然、易識別的原則，我們對所有的小圖標(biāo)進行了優(yōu)化。簡化了舊版本中的復(fù)雜表達，并對默認(rèn)態(tài)、hover態(tài)和選中態(tài)進行了規(guī)范。

文檔類型圖標(biāo)也和手機端進行了對齊，將文件格式進行分類整合，同類型的格式采用同一個圖標(biāo)，將格式后綴在文件名中顯示出來。在不影響識別的前提下大大降低了設(shè)計成本。

內(nèi)容至上的前瞻性設(shè)計

全新的縮略圖模式

內(nèi)容至上是當(dāng)今設(shè)計的發(fā)展趨勢之一，結(jié)合微云未來的重點方向——辦公體驗，我們進行了一些對內(nèi)容的深入思考。

在網(wǎng)盤的使用場景中，什么才是用戶關(guān)注的內(nèi)容？早期的文件管理產(chǎn)品把文件圖標(biāo)、文件名定義為內(nèi)容，文件被包裝成一個個方塊，或是一行行的列表，文件間的差異只靠文字來體現(xiàn)。面對這樣的界面，用戶對文件的識別是十分低效的。這也是為什么在如今的網(wǎng)盤場景中，圖片是最容易識別的，因為它做到了文件本身內(nèi)容的外顯。

在面對一個一個被包裝的文件時，用戶容易被觸發(fā)的行為局限于整理、刪除等基礎(chǔ)操作，只有在能夠看到文件本身內(nèi)容的時候，才更容易觸發(fā)編輯、分享、共享協(xié)作等更加沉浸式和更具社交性的操作。這就好比你走進一個倉庫看到貨架上的一個個箱子，你會想要把他們分類、擺放得更整齊。但是當(dāng)你走進一家商店，看到貨架上琳瑯滿目的商品時，你才會有挑選、對比和購買的沖動。

秉承著這個理念，我們反觀圖片之外的其他文件類型，道理是相同的；因此，我們在改版中引入了全新的縮略圖模式，在新的縮略圖模式下，單個文件的可視區(qū)域被放大，用來承載文件本身的內(nèi)容。雖然一屏可以展示的文件數(shù)減少了，但展示出的有效信息是大大增加的，除了讓每個文件在視覺上有了獨特性，提高了檢索效率，也更容易觸發(fā)用戶更多的后續(xù)行為。這對于產(chǎn)品本身的價值相信大家都懂。

技術(shù)過渡時期的體驗補償

理想很豐滿，現(xiàn)實很骨感，讓更多的文件內(nèi)容外顯在技術(shù)上必然要走一段路。在技術(shù)問題解決的過程中需要設(shè)計對體驗進行一些彌補，在縮略圖的文檔圖標(biāo)的設(shè)計中，我們盡可能的把文件的內(nèi)容樣式圖形化；同時，為了保證識別性，那些圖標(biāo)比內(nèi)容形式更具特征的文件，保留了圖標(biāo)設(shè)計的形式。

寫在最后

微云一直致力于為用戶提供更更自然的使用體驗，無論在功能上還是在設(shè)計上，我們都秉承著以用戶為中心的原則，不斷打磨每個細(xì)節(jié)。WEB改版也是如此，這一期改版我們對WEB端的框架和方向進行了調(diào)整，在接下來的二期、三期.....我們會不斷深入到各個模塊，進一步提升WEB端的用戶體驗。在這個對于個人網(wǎng)盤來說最壞的時期，微云會長久的發(fā)展下去，我們不會停止前進的腳步，更多酷炫的新功能新體驗已經(jīng)在路上。

藍藍設(shè)計( www.skdbbs.com )是一家專注而深入的界面設(shè)計公司，為期望卓越的國內(nèi)外企業(yè)提供卓越的UI界面設(shè)計、BS界面設(shè)計 、 cs界面設(shè)計 、 ipad界面設(shè)計 、 包裝設(shè)計 、 圖標(biāo)定制 、 用戶體驗 、交互設(shè)計、 網(wǎng)站建設(shè) 、平面設(shè)計服務(wù)

一、有些事情難以回頭

開篇我先表明自己的立場：同時使用 .Net 和 JAVA，但更加偏愛.Net。原因很簡單：

• .Net語言更具開放性，從開源協(xié)議和規(guī)范可以看出;
• 語言更具優(yōu)勢嚴(yán)謹(jǐn);
• 開發(fā)工具 VS 更具生產(chǎn)力;

然而

• Java，C# 的職位比率在4:1，雖然這不是什么問題，因為求職競爭的比例更大(JAVA中更多的剛培訓(xùn)出來的)，但話說回來，對于C#求職而言，會面臨更加狹窄的企業(yè)選擇空間。
• Java同等職位，國內(nèi)的待遇比.Net稍高。這里為 .Net 說聲不平，.Net開源程度更好，架構(gòu)體系更成熟邏輯更嚴(yán)謹(jǐn)，開發(fā)效率更高，服務(wù)器同樣可以使用Linux。
• 

編程是一個不斷向前發(fā)展的行業(yè)。在某些時候，你可能會誠實地看看自己的技能，并得出結(jié)論，你已經(jīng)落在了曲線的后面。如果你是專業(yè)人士，那么這很容易做到，因為很多時候你沒有必要夜以繼日地推著自己前進。

但遲早，落后的趨勢會回過頭來咬你一口，讓你血流不止。在商業(yè)和就業(yè)市場上，你的競爭力會降低。那么你該如何再次成為游戲中的高手呢？