前言

生活有度，人生添壽。

Javascript從當(dāng)初的一個“彈窗語言”，一步步發(fā)展成為現(xiàn)在前后端通吃的龐然大物。javascript的受歡迎程度也是與日俱增，今年編程語言又是花落javascript，這實在是一個充滿了活力的語言。如今，隨隨便一個網(wǎng)頁javascript代碼量都不下數(shù)千行，要是node后端那更不止幾千行了。（WTF）代碼量的增加給編程帶來的首要的問題就是如何去編寫和維護(hù)如此龐大的代碼呢？答案就是模塊化思想，其實就是面向?qū)ο螅∣OP）編程，如今比較流行的三大前端框架（angular,react,vue）基本都實現(xiàn)了組件化編程，但組件化和我們所說的模塊化又有所不同，應(yīng)該可以這么理解，組件化是模塊化的升級版，模塊化是組件化的基礎(chǔ)。那么，問題來了，javascript怎么面向?qū)ο缶幊棠兀课蚁脒@很多老鳥也不定說的清楚吧，前端雜而活躍的各種社區(qū)，很多前端er一度依賴各種插件，根本不需要去了解這些深層的東西卻照樣能完成任務(wù)。但我想作為一個有追求的前端er還是很有必要去學(xué)習(xí)這些看似用不著的東西的，別的不說，就單單因為我們是前端er,只會用jquery一個稍微厲害的后端都能代替你。好吧，廢話不多說，到底如何面向?qū)ο骳oding呢…..

很不幸，es5中并沒有給出明確的定義‘類’的概念，所以傳統(tǒng)的面向?qū)ο缶幊趟坪跏切胁煌ǖ模敲从衷撃[么辦呢？值得慶幸的是，前輩們通過不斷探索總結(jié)，成功的用javascript模擬出了“類”。那么，javascript的類又該怎么定義呢？

在面向?qū)ο缶幊讨?，類（class）是對象（object）的模板，定義了同一組對象（又稱”實例”）共有的屬性和方法。

深挖產(chǎn)品設(shè)計背后的工作方式和工作流程，讓產(chǎn)品經(jīng)理受益匪淺。

Design Sprint Method （谷歌沖刺計劃）是由谷歌創(chuàng)投的 Jake Knapp 發(fā)明的一種產(chǎn)品設(shè)計工作法，是指由一支不超過 7 人的團(tuán)隊，在 5 天之內(nèi)，通過 5 個步驟，能夠快速解決產(chǎn)品難題的產(chǎn)品設(shè)計方法。其基礎(chǔ)概念來自于敏捷開發(fā)、設(shè)計思考和個性游戲法，先后被 100 多家創(chuàng)業(yè)公司實踐，打造了諸如 Slack、 Nest、Blue Bottle Coffee 和 23andMe 等多個成功的互聯(lián)網(wǎng)產(chǎn)品。

搜索功能無論在web端還是移動端，都是產(chǎn)品中十分重要的功能。文章主要從用戶體驗和產(chǎn)品功能、策略角度來分析，提出一些對應(yīng)的設(shè)計方法。

搜索能夠幫助用戶快速找到想要的結(jié)果，其中兩個重要目標(biāo)是提高搜索結(jié)果的相關(guān)性，降低結(jié)果觸達(dá)的延遲性。用戶使用搜索功能來滿足其信息獲取的需求，其搜索目的是在搜索結(jié)果中進(jìn)行內(nèi)容消費。搜索功能一般來說都是全局性質(zhì)的“模糊搜索”（用戶可以搜索到產(chǎn)品的主要內(nèi)容），有時也會出現(xiàn)在局部結(jié)構(gòu)中（如某個功能模塊下的“定向搜索”）。

@黃紅藝Designer ：對于交互設(shè)計師而言，一個項目的開始，是從接到產(chǎn)品經(jīng)理的需求文檔開始的。從需求的確認(rèn)到交互稿的確認(rèn)，再到產(chǎn)品開發(fā)效果的確認(rèn)，都考驗著交互設(shè)計師設(shè)計能力以外的技巧。在這個過程中，有一些要點需要你知道，來保證你的設(shè)計過程更加順暢。

第一點：確認(rèn)你所理解的需求是否正確

一千個人的眼中，就有一千個哈姆雷特。對于需求的理解也是一樣，我們拿到需求以后，要和產(chǎn)品經(jīng)理進(jìn)行溝通，將自己對需求的理解與簡單的頁面構(gòu)思，闡述給產(chǎn)品經(jīng)理，以確定自己的理解與設(shè)計方向是否準(zhǔn)確。切忌，拿到需求就開工去做，以為可以節(jié)省時間，卻不知錯誤的理解和方向，讓你付出更多。

不要認(rèn)為，產(chǎn)品經(jīng)理給的需求就像數(shù)學(xué)定理一樣可以深入理解，詳細(xì)解讀，沒有那么多的產(chǎn)品經(jīng)理有這個功夫和能力去做這個事情。因此，溝通才是保證你對需求的理解，對設(shè)計方向正確把握的基石。

那么，在需求交流之前你要準(zhǔn)備好什么呢？第一，認(rèn)真研究需求，理解需求；第二，是你在研究需求時，發(fā)現(xiàn)的問題，最好整理出來，以便在討論時提出，讓產(chǎn)品經(jīng)理為你解答，而不是自己”以為“；第三，如果時間充足，最好整理出界面的框架，或者用草圖來展示你的設(shè)計思路，看產(chǎn)品經(jīng)理是否認(rèn)可你的設(shè)計。

對于討論中形成的共識，最好以郵件的形式發(fā)出，一方面可以作為會議紀(jì)要，便于隨時解答疑惑，另一方面，是立字為證，防止需求的隨意變更。

永遠(yuǎn)不要虧欠來到我們身邊的任何人，只要有這個思維，堅決不虧欠。不管是什么原因都不虧欠別人，因為一旦虧欠就虧欠了我們的前途，所以寧愿吃虧也不虧欠。

UI設(shè)計的整個過程中，有很多需要衡量和把握的一些原則和規(guī)范，幫助設(shè)施和合理性就是其中經(jīng)常要審視和把握的兩點。那么幫助設(shè)施和合理性都有哪些細(xì)則呢？

幫助設(shè)施的細(xì)則主要包括：

在上一篇的分享文章中，我們分享了軟件界面設(shè)計中的易用性細(xì)則，今天我們來分享下軟件界面設(shè)計中的規(guī)范性細(xì)則。通常界面設(shè)計都按Windows界面的規(guī)范來設(shè)計，即包含“菜單條、工具欄、工具箱、狀態(tài)欄、滾動條、右鍵快捷菜單”的標(biāo)準(zhǔn)格式，可以說：界面遵循規(guī)范化的程度越高，則易用性相應(yīng)的就越好。那么，具體到規(guī)范性的一些細(xì)則都有哪些呢？

軟件界面設(shè)計在現(xiàn)在的互聯(lián)網(wǎng)時代越來越火，想必做設(shè)計的也都知道，它也是要遵循一定的設(shè)計守則，其中易用性就是軟件界面設(shè)計中的守則之一。但僅僅知道這一點還是不夠的，因為易用性的背后還有很多的一些小細(xì)則，今天我們就來對這些小的細(xì)則進(jìn)行統(tǒng)計分享。

問題提出

font-weight的屬性值有100、200、300、400、500、600、700、800、900和normal、bold、lighter、bolder，它們的區(qū)別是？
另外，在實際開發(fā)中，我們應(yīng)該使用數(shù)值表達(dá)還是文字表達(dá)呢？

認(rèn)識font-weight

根據(jù)W3C Fonts節(jié)章的規(guī)范標(biāo)準(zhǔn)，可知：

在UI設(shè)計中，文字內(nèi)容的表述也是需要設(shè)計師精心推敲，仔細(xì)設(shè)計的部分。清晰、準(zhǔn)確、簡潔的文案設(shè)計能夠讓界面擁有更好的可用性，同用戶建立信任。

文案設(shè)計上的技巧很多，應(yīng)當(dāng)規(guī)避的誤區(qū)也不少，今天為你總結(jié)16個常見的UI文案設(shè)計的誤區(qū)，幫助大家少走彎路。

1、盡量避免使用俗語和術(shù)語

未知的術(shù)語和俗語將會增加用戶的認(rèn)知負(fù)荷，所以應(yīng)當(dāng)盡量避免使用這類用戶無法識別的詞匯，使用常用和易于理解的詞匯能夠幫助用戶理解。

下面就是一個典型的反例：

很難說清這種錯誤提示信息是給系統(tǒng)管理員還是辦公室的文員看的。