首頁

交互設計師常用的設計理論與心理學

ui設計分享達人

掌握好常用的設計理論與心理學知識,能幫助我們對用戶的人性特征的拿捏,幫助我們較大的影響用戶底層決策,以產品實現(xiàn)業(yè)務目標。

一、尼爾森10大可用性原則


1、狀態(tài)可見原則

不局限于:用戶的當前狀態(tài)、知道當前任務要做什么、任務進度等。

2、環(huán)境貼切原則

設計要復合目標用戶的認知,符合用戶的心智模型,于是熟悉的事物越容易被用戶所接受。

3、撤銷重做原則

操作前可預知,操作中有反饋、操作后可撤銷。

4、一致性原則

不局限于:業(yè)內產品的一致性、產品內的一致性、版本迭代間的一致性

5、防錯原則

錯誤行動發(fā)生前,引導用戶向正確的方向前進;用戶觸碰到危險操作時給予提示;危險操作發(fā)生之后,提供撤回的入口。

6、易取原則

通過使用對象、動作和選項的可視化表達,最大限度地減輕用戶的記憶負擔。

記住用戶的操作記錄、一個流程對應一個操作目標、提供適量的信息、選擇而不是輸入。

7、靈活原則

好的產品需要同時兼顧新用戶和資深用戶的需求。對新用戶來說,需要功能明確、清晰,對于老用戶需要快捷使用高頻功能。不可迎合某一種用戶,把不必要的信息占據(jù)重要部分。

8、易掃(讀)原則

不要包含不相關或低頻次的信息/操作。頁面中的每個額外信息都會降低主要內容的相對可見性。

產品設計的四大基本原則:親密性、對齊、重復、對比。

9、容錯原則

錯誤信息應該用通俗易懂的語言表達,較準確地指出問題,并且提出解決方案。避免通過代碼等用戶難以理解的形式

即:提供解決方案、幫助用戶從錯誤中恢復

10、人性化幫助

如果系統(tǒng)能讓用戶不需要閱讀文檔就會使用那是最好的,但通常情況下還是需要幫助文檔的。任何信息應該容易被搜索,且專注于用戶的目標任務,并列出具體的步驟來告知用戶。


二、費茨定律

翻譯成人話就是:

1. 按鈕做大點(W大點)更易于點擊

2. 將按鈕放置在離開始點較近的地方

3. 相關按鈕之間距離近點(D小點)更易于點擊

4. 屏幕的四角與四邊是「無限可選中」位置(非移動端)

5. 通過費茨定律的反向使用,可以降低按鈕被點擊的可能


三、米勒定律


米勒定律預測人的工作記憶能夠記住的項為7(±2)個。1956年認知心理學家喬治·米勒發(fā)表了一篇論文,他討論了短期記憶和記憶跨度的極限。

不要亂用 “神奇的7” 為設計進行不必要的限制;

將內容整理為較小的單元,以便用戶輕松地處理、理解和記憶。


比如電話號碼的顯示方式、銀行卡的顯示方式等


四、接近法則


觀察者看到彼此鄰近(空間或時間)的物體時,會將它們視為一個整體。

在界面設計中,對信息的組織已經離不開這個法則了,他在界面中所體現(xiàn)的就是把相關的信息塊組合在一起,不太相關的分離開,增強與區(qū)分元素之間的關聯(lián)性,所強調的是空間和位置。

接近法則產生于群組,它可以減少信息設計的復雜性,對引導用戶的視覺流、便于用戶對界面的解讀起到至關重要的作用。


五、席克定律


??硕墒且环N心理物理學定律。用戶所面臨的選擇數(shù)量越多,做出選擇所花費的時間就越長,在人機交互的界面中選項越多,意味著用戶做出決策的時間越長。


六、泰斯勒定律(復雜性守恒定律)


泰斯勒定律又稱復雜性守恒定律,該定律認為每一個過程都有其固有的復雜性,這個復雜性存在一個臨界點,超過了這個點就不能再簡化了,你只能將固有的復雜性從一個地方移動到另外一個地方。


七、奧卡姆剃刀原理


奧卡姆剃刀原理的核心思想為:“切勿浪費較多東西去做用較少東西同樣可以做好的事——如無必要,勿增實體,即簡單有效原理”。


八、防錯原則


操作前有提示,操作中有反饋、操作后可撤銷。


九、損失厭惡


損失厭惡是指人們面對同樣數(shù)量的收益和損失時,認為損失更加令他們難以忍受。同量的損失帶來的負效用為同量收益的正效用的2.5倍。損失厭惡反映了人們的風險偏好并不是一致的,當涉及的是收益時,人們表現(xiàn)為風險厭惡;當涉及的是損失時,人們則表現(xiàn)為風險尋求。


十、安慰劑效應


“安慰劑效應”指的是,對于某種無效的療法或干預手段,僅僅是“相信它有效”,就能改善健康,并能改變認知


十一、多爾蒂門檻


研究結果表明,計算機的響應速度直接影響了使用者做出下一個決定所要花費的時間(這個時間被稱為用戶響應時間),換句話說,計算機相應的時間越長,用戶就要花費越多的時間來思考和決定下一步的操作。


合理的操作響應時長、方式有助于用戶保持專注和提率。

軟件操作的過度動畫時間不宜太短或太長,最常見于 400ms 左右。

如果無法避免操作中較長讀取、等待時間,那么就用其他更有趣的動畫、頁面來減少用戶的焦慮感。


十二、馬斯洛需求層次理論


馬斯洛需求層次理論是人本主義科學的理論之一,由美國心理學家亞伯拉罕?馬斯洛在1943年在《人類動機理論》論文中所提出。書中將人類需求像階梯一樣從低到高按層次分為五種,從低到高依次是:生理需求、安全需求、社交需求、尊重需求和自我實現(xiàn)需求。

但最終馬斯洛添加求知需求和審美需求,自此馬斯洛需求層次理論最終定型為8層。

十三、格式塔心理學


格式塔原則描述了當某些條款和條件被應用時,人類大腦如何感知視覺成分。它幫助大腦創(chuàng)造視覺的意象。因此,格式塔原則基于六個主要類別:

位置和位置;

接近;

對稱與秩序;

類似;

關閉;

連續(xù)性。


十四、自我參照效應


第一種是精細加工說:在記憶過程中,這些事物在頭腦中被進行了精細加工,與頭腦中的已有知識之間建立了更多的聯(lián)系,因此回憶時的提示線索更多,回憶效果更好。

第二種是組織加工說:于自我的知識是頭腦中存在的一種結構良好的組織體系,它對與自己相關的事物有更好的固著作用;同時,由于自我知識常常被激活,因此與之相關的信息也更容易被相應地激活起來,這樣回憶起來也就更容易。

第三種是雙過程說:即自我參照任務能提高記憶的機制既包括精細加工因素,也有組織作用的參與

廣告商會挖空心思的建立商品和你的關聯(lián),告知我們如果你購買了我的商品,你就會獲得怎樣的好處。而自媒體人則在標題上盡量簡明扼要的說明,我要說的事情和你密切相關,不看就虧了。所以,稍微有深度的文章在快餐式的自媒體平臺中反而閱讀量不高,這是因為文章標題所涵蓋的內容可能只和少部分人有關。


十五、上癮模型


1、觸發(fā):提醒人們采取下一步行動


觸發(fā)分為外部觸發(fā)與內部觸發(fā)

外部觸發(fā)又分為:

付費型觸發(fā)、回饋型觸發(fā)、人際型觸發(fā)、自主型觸發(fā)。

內部觸發(fā)

內部觸發(fā)通過用戶記憶存儲中的各種關聯(lián)來提醒他們采取下一步行動。

比如餓了的時候想起餓了么,想健身的時候想起keep


2、行動:人們在期待酬賞時的直接反應


福格行為模型可以用公式來呈現(xiàn),即B=MAT。B代表行為,M代表動機,A代表能力,T代表觸發(fā)。要想使人們完成特定的行為,動機、能力、觸發(fā)這三樣缺一不可。 否則,人們將無法跨過“行動線”,也就是說,不會實施某種行為。

比如說中午十一點你餓了想到餓了么訂餐但是由于你的手機沒電了定不了餐,中午要吃飯是動機,訂餐想到叫餓了么外賣是觸發(fā),能夠用手機訂餐是能力,但是因為手機沒有電 你就缺乏了相應的能力所以這個行為就沒法完成。(當然你也能用朋友的手機訂餐,這里只是舉個例子)


福格總結了簡潔性所包含的6個元素 ,即影響任務難易程度的6個要素,它們是:


  • 時間——完成這項活動所需的時間。

  • 金錢——從事這項活動所需的經濟投入。

  • 體力——完成這項活動所需消耗的體力。

  • 腦力——從事這項活動所需消耗的腦力。

  • 社會偏差——他人對該項活動的接受度。

  • 非常規(guī)性——按照福格的定義,“該項活動與常規(guī)活動之間的匹配程度或矛盾程度”。


四種非常規(guī)的效應刺激動機:


  • 稀缺效應:(限量1000件)

  • 環(huán)境效應:(同一款啤酒在便利店和高檔就把價格不一,但人們愿意為價格買單)

  • 錨定效應:(瑞幸咖啡定價24元的拿鐵對標星巴克的32元拿鐵)

  • 贈券效應:(利益進度吸引用戶動機)


3多變的酬賞:滿足用戶的需求,激發(fā)使用欲


多變性會使大腦中的伏隔核更加活躍,并且會提升神經傳遞素多巴胺的含量,促使我們對酬賞產生迫切的渴望。 研究測試表明,當賭博者贏了錢,或是異性戀男性看到美女的圖片時,大腦伏隔核中的多巴胺含量會上升。

多變的酬賞主要表現(xiàn)為三種形式:社交酬賞、獵物酬賞、自我酬賞。那些讓我們欲罷不能的習慣養(yǎng)成類產品或多或少都利用了這幾類酬賞。


社交酬賞

所謂社交酬賞,是指人們從產品中通過與他人的互動而獲取的人際獎勵。比如微信的點贊評論、站酷的推薦,用戶能夠獲得社交的認同。


獵物酬賞

獵物酬賞,是指人們從產品中獲得的具體資源或信息。


自我酬賞

所謂自我酬賞,是指人們從產品中體驗到的操控感、成就感和終結感。


4、投入:通過用戶對產品的投入,培養(yǎng)忠實用戶


要想讓用戶產生心理聯(lián)想并自動采取行動,首先必須讓他們對產品有所投入。


用戶對某件產品或某項服務投入的時間和精力越多,對該產品或服務就越重視。事實上,有充分證據(jù)表明,用戶投入的多寡與其熱愛某項事物的程度成正比。


1、文飾效應心理


(1)我們總是高估自己的勞動成果。

(2)我們總是盡力和過去保持行為一致。

(3)我們總是避免認知失調。


2、點滴投入


(1)儲存價值

(2)內容

(3)數(shù)據(jù)資料

(4)關注者

(5)信譽

(6)技能


3、加載下一個觸發(fā)


用戶投入的同時也可以通過加載下一個觸發(fā)的令自己重新開始上癮循環(huán),從而增加了進入上癮循環(huán)的可能性。


十六、雅各布定律


雅各布定律(簡稱雅各布互聯(lián)網用戶體驗法則),它指出如果用戶已將大部分時間花費在某個網站上,那么他們會希望你的網站可以與那些他們已熟悉的網站一樣擁有相似的使用模式。


我們在與新事物互動的過程中,用戶使用的是以往的經驗


對設計師來說,我們可以匹配用戶的心智模型來改善體驗。因此,用戶可以輕松地將已有經驗從一種產品或體驗轉移到另一種上,無需額外了解新系統(tǒng)的工作原理。

當設計師與用戶的心智模型一致時,良好的用戶體驗就得以實現(xiàn)。


十七、KANO模型


KANO模型大家可以看看這個童鞋的總結很詳細

https://www.zcool.com.cn/article/ZMTAyMjQ3Mg==.html


十八、古藤堡表圖表法


人們在瀏覽頁面或布局時視線趨于從左上角移動到右下角

古騰堡圖表法說明我們觀看頁面的視線并不是鏡面對稱的,我們需要在設計中避免出現(xiàn)此類錯誤但絕不是墨守成規(guī),將頁面的 Logo放置在左上角而主體向右下角延伸,左下和右上作為視覺的盲點可以添加輔助元素


十九、尼爾森F型視覺模型


尼爾森F型視覺模型由 Jakob Nielsen于2006年提出

他指出,我們在第一次觀看頁面時,視線會呈 F的形狀關注頁面。
1.先從頂部開始從左到右水平移動。
2.目光再下移開始從左到右觀察但是長度會相對短些。
3.以較短的長度向下掃視,形成一個 F形狀,此時我們的閱讀速度較慢,更為系統(tǒng)和條理性。


二十、序列效應


1.在列舉信息時,排在最前和最后的元素,比排在中間的更容易讓人記住。

2.對排在開頭的信息產生加強的回想效果,稱為:初始效應,人們有時候會把最前面的信息儲存在長期記憶中。排在結尾的信息產生加強的回想效果,稱為:時近效應。時近效應適用于聽覺刺激。初始效應適用于視覺刺激。

3.在列舉信息元素時,如果列舉信息屬于視覺性,那么把重要的信息放在最前面;如果是聽覺性,就放在最后面。如果是用戶必須做決定,并且是最后一項出現(xiàn)后馬上做決定,那么就將想要用戶做決定的信息放置最后,以便增加獲選概率,否則放在最前面。

4. 應用例子:比如在很多app產品設計時,個人賬戶與設置基本放在頁面的最前面和最后面,這體現(xiàn)著產品信息的序列關系,重要次序,所以在進行設計時,可以在信息排序上遵循序列效應。 當然還有一些產品想對用戶進行引導操作,也可以利用這個法則,將信息放置最前或最后。

轉自:站酷-YELLOW_J 

啥?你說我不懂如何設計消息中心?

ui設計分享達人

消息中心設計樣式的簡單匯總

作為APP標配的消息中心,我們無時無刻不在與其打交道,看似千篇一律的設計實際上其中也有許多值得我們深入探討的內容,今天我們一起從消息中心頁入口出發(fā),一層一層剝開它的秘密。


全文分為五個部分:

一、消息中心頁入口位置

二、消息中心頁常見的組成模塊

三、消息中心頁分類導航方式的選擇

四、消息列表的呈現(xiàn)形式

五、劃重點


一、消息中心頁入口位置


消息中心頁是應用內系統(tǒng)發(fā)送給用戶的各種信息的一個集合頁面,它的本質是與用戶互動溝通。也就是說,產品越是需要與用戶進行溝通,消息中心的重要程度也就越高。


一般情況下,不同類型的APP消息中心的重要程度為:社交通訊類>電商類>資訊類>工具類


而消息中心頁的入口位置正好側面反映了其在產品中的重要程度。


1.底部導航欄

消息中心頁入口位置放在底部導航欄,屬于一級導航,重要程度很高,常見于即時通訊、社交社群類產品,如下圖:

即時通訊類的QQ,核心業(yè)務就是通訊交流,消息頁入口不僅放在底部導航欄,且做為APP的首頁。而微博作為最早的社群內容類產品,社交溝通需求也很高,固將消息中心入口放置在底部導航欄。


當然也不是只有社交通訊類產品會選擇該位置作為消息中心的入口,如下圖淘寶和小紅書也將消息中心入口放置在底部導航欄。

淘寶本是電商類產品,消息入口放置在底部導航欄,結合官方號、內容號、小黑群等功能,我的理解是淘寶是想通過社交溝通促使用戶更多的購物。


小紅書主打生活內容分享,輔助電商購物,是現(xiàn)在比較常見的某個核心業(yè)務+社交的產品,這類產品可根據(jù)自身一級導航類別的多少決定是否將消息中心入口放置在底部導航欄。


2.頂部導航欄

消息中心頁入口放置在頂部導航欄,重要程度根據(jù)入口跟隨頁面的多少分成兩種情況:


1)幾乎每頁跟隨,重要程度較高

京東和豆瓣幾乎是每個一級頁面的頂部都有消息頁入口圖標,京東甚至在一些二級頁面也還保留了頂部消息入口,方便用戶隨時查看。


2)僅在動態(tài)頁、首頁或個人中心頂部有入口,重要程度較低

如上圖所示,愛奇藝的消息入口僅出現(xiàn)在泡泡頁面的頂部,KEEP的消息入口在個人中心頁的頂部,二者都只有一個入口。


3.個人中心頁

消息中心頁入口放置在個人中心頁除頂部外的區(qū)域,重要程度一般,某些APP會在個人中心消息入口直接對其分類展示,用戶能快速地到達想去的消息分類。

波洞的消息中心入口在個人中心頁就分好了類別,用戶點擊進入對應的類別,消息頁內部沒有做類別的劃分,相比放一個消息圖標入口在個人中心頂部,更加直觀。


入口不一定只有一個,三種情況混合使用也是可以的,重點是方便用戶,引導用戶。即便入口位置本身不顯眼,加上紅點數(shù)字后一樣會被用戶看到的。



二、消息中心頁常見的組成模塊


消息中心頁的主要組成模塊有:分類消息導航、消息列表;輔助組成模塊有:搜索區(qū)、全部已讀、消息設置、通訊錄等。


1.主要的組成模塊

消息中心的主要組成模塊中消息列表是必不可少的(有些在下一級界面中),分類消息導航根據(jù)消息類別的多少不一定都有。


前文對消息中心的定義說過:消息中心頁是應用內系統(tǒng)發(fā)送給用戶的各種信息的一個集合頁面。集合頁面意味著消息本身被劃分成了各種類型,這時候適合的分類消息導航能幫助用戶快速找到需要的信息。


消息列表引導用戶進入消息詳情頁,做為整個消息中心的核心,需要設計師根據(jù)產品需求盡可能多的考慮到囊括的信息類型,從而選擇合適的消息列表呈現(xiàn)形式。


在第三部分中會著重介紹4種不同的分類消息導航,第四部分介紹3種不同的消息內容呈現(xiàn)形式。


2.輔助組成模塊

所謂輔助的組成模塊,就是不一定所有消息中心都有的,要結合產品實際情況增減。主要包括搜索區(qū)、全部已讀、消息設置、通訊錄等。

上圖中微博的消息中心基本包括了所有的輔助組成模塊,用戶可以收發(fā)消息,設置消息,搜索消息,形成了針對消息功能的一個閉環(huán)。像微博這種消息功能重要,類別多,有社交屬性的產品加入這些輔助功能是合適的,但不適合所有產品。


1)搜索區(qū)

用來在消息中心頁搜索消息、聯(lián)系人、群聊等的,僅適合消息中心頁用戶之間互動頻繁的產品,如即時通訊類、聊天頻繁的社群類產品。搜索區(qū)是全局搜索的根據(jù)產品自身性能選擇加入。


2)全部已讀/一鍵清除

對于用戶體量不算大,消息溝通還不太頻繁的產品可以不加。但對于消息溝通頻繁的產品,不加的話,可能會逼死強迫癥......


3)消息設置

用來設置消息提醒方式或屏蔽消息推送,大部分產品會將此功能放入設置中避免用戶關閉消息推送,放在消息中心雖可增加用戶體驗,但也方便了用戶直接屏蔽消息。


4)通訊錄/發(fā)起聊天

常見在有好友通訊錄體系或關注粉絲體系的產品中。



三、消息中心頁分類導航方式的選擇


消息中心分類導航方式主要有四種:頂部固定圖標導航、頂部Tab導航、列表導航、頂部Tab混合導航,接下來通過分析它們各自的優(yōu)缺點幫助你選擇合適的消息中心分類導航方式。


1.頂部固定圖標導航

頂部固定展示重要的3~5個消息類別,消息列表按照發(fā)送的時間順序依次展示。

優(yōu)點:可以突出重點消息類別。


缺點:類別切換不方便,需要返回上一級重新進入;超過5個類別后,其他類別只能歸入消息列表中。


2.頂部Tab導航

頂部純文字標簽Tab導航,消息類別以標簽的形式出現(xiàn),可左右切換。

優(yōu)點:切換方便,類別可拓展性強,占據(jù)空間小,為消息列表留出更多的空間,純文字標簽設計所需時間成本小。


缺點:分類標簽不要超過9個,過多的標簽用戶切換到后面的成本較高,容易被忽略。


3.列表導航

消息中心列表導航有分類列表導航和混合列表導航兩種形式。


1)分類列表導航

分類列表導航將不同的消息類別按照icon+文字的形式從上至下展示,左側是消息類別,右側是消息未讀紅點提醒,每一個列表對應進入一種消息類別。

優(yōu)點:類別可拓展性強,分類清晰,設計簡潔明了,適合輕量、極簡風的消息中心頁。


缺點:到達具體消息內容的路徑較長,不適合復雜的消息中心頁。


2)混合列表導航

消息列表與消息類別混合,按照消息發(fā)布時間順序以列表形式展示,常見于重社交、即時通訊類產品。

優(yōu)點:可拓展性極強,能容納各種類別的消息。


缺點:消息內容太多后查找麻煩,需要配合搜索區(qū)使用,易產生閱讀疲勞。


4.頂部Tab混合導航

頂部Tab混合導航,進一步對消息類別細致劃分,一級Tab標簽一般會劃分為兩部分:通知及消息/私信,通知一般是產品發(fā)送的一些系統(tǒng)消息或推送,消息一般是用戶與用戶之間的互動消息(包括官方號的信息),私信主要是有關注粉絲體系的產品的分類。二級內容根據(jù)需要選擇進一步分類導航,如下圖:

優(yōu)點:將消息做了更細致的劃分


缺點:有二級分類的頁面占的空間大,消息列表展示空間少。



四、消息列表的呈現(xiàn)形式


消息列表是消息中心的核心,我們需要根據(jù)內容類型的不同選擇合適的呈現(xiàn)形式,便于用戶理解。主要的呈現(xiàn)形式有3種,分別是:icon/頭像+縮略內容列表、圖文列表、純文字列表。


1.icon/頭像+縮略內容列表

最常見的一種消息列表,以icon或頭像+縮略內容的形式展示,符合從左到右的瀏覽習慣,能承載多種類型的消息,包括對話聊天類、訂閱號、官方活動、系統(tǒng)通知等等,需要引入下一級頁面展示消息詳情。適合大部分的產品。


2.圖文列表

消息列表采用圖文形式,對用戶更具吸引力,一般用在消息類別比較單一的消息中心。常見的有上圖下文卡片(大圖)和左圖右文的展現(xiàn)形式。需要注意的是上圖下文(大圖)的展現(xiàn)形式對圖片質量要求較高。常用在活動消息、資訊消息。


3.純文字列表

消息列表以純文字形式展示,形式較單一,能展示較多的文字信息,常見于通知消息。



五、劃重點


本文主要通過消息入口位置、消息中心頁組成、消息中心頁分類導航選擇、消息列表呈現(xiàn)形式介紹了消息中心頁的設計。


消息中心頁入口:底部導航欄、頂部導航欄、個人中心頁


消息中心頁組成模塊:分類消息導航、消息列表;、搜索區(qū)、全部已讀、消息設置、通訊錄。


消息中心頁分類導航:頂部固定圖標導航、頂部Tab導航、列表導航、頂部Tab混合導航。


消息列表的呈現(xiàn)形成:icon/頭像+縮略內容列表、圖文列表、純文字列表。

轉自:站酷-人類君 

小程序入門到精通:了解小程序開發(fā)4個重要文件

前端達人

點擊查看原圖


1. 小程序沒有DOM對象,一切基于組件化

2. 小程序的四個重要的文件

  • *.js —> view邏輯 —> javascript
  • *.wxml —> view結構 ----> html
  • *.wxss —> view樣式 -----> css
  • *. json ----> view 數(shù)據(jù) -----> json文件

注意:為了方便開發(fā)者減少配置項,描述頁面的四個文件必須具有相同的路徑與文件名。

2.1 WXML

WXML(WeiXin Markup Language)是框架設計的一套標簽語言,結合基礎組件事件系統(tǒng),可以構建出頁面的結構。WXML 充當?shù)木褪穷愃?nbsp;HTML 的角色
要完整了解 WXML 語法,請參考WXML 語法參考。

2.2 WXSS

WXSS (WeiXin Style Sheets)是一套樣式語言,用于描述 WXML 的組件樣式。

WXSS 用來決定 WXML 的組件應該怎么顯示。

為了適應廣大的前端開發(fā)者,WXSS 具有 CSS 大部分特性。同時為了更適合開發(fā)微信小程序,WXSS 對 CSS 進行了擴充以及修改。

與 CSS 相比,WXSS 擴展的特性有:



尺寸單位

樣式導入

2.3 json

JSON 是一種數(shù)據(jù)格式,并不是編程語言,在小程序中,JSON扮演的靜態(tài)配置的角色。



全局配置

小程序根目錄下的 app.json 文件用來對微信小程序進行全局配置,決定頁面文件的路徑、窗口表現(xiàn)、設置網絡超時時間、設置多 tab 等。



頁面配置

每一個小程序頁面也可以使用同名 .json 文件來對本頁面的窗口表現(xiàn)進行配置,頁面中配置項會覆蓋 app.json 的 window 中相同的配置項。



工具配置 project.config.json

通常大家在使用一個工具的時候,都會針對各自喜好做一些個性化配置,例如界面顏色、編譯配置等等,當你換了另外一臺電腦重新安裝工具的時候,你還要重新配置。

考慮到這點,小程序開發(fā)者工具在每個項目的根目錄都會生成一個 project.config.json,你在工具上做的任何配置都會寫入到這個文件,當你重新安裝工具或者換電腦工作時,你只要載入同一個項目的代碼包,開發(fā)者工具就自動

注意:

JSON文件都是被包裹在一個大括號中 {},通過key-value的方式來表達數(shù)據(jù)。JSON的Key必須包裹在一個雙引號中,在實踐中,編寫 JSON 的時候,忘了給 Key 值加雙引號或者是把雙引號寫成單引號是常見錯誤。

JSON的值只能是以下幾種數(shù)據(jù)格式,其他任何格式都會觸發(fā)報錯,例如 JavaScript 中的 undefined。



數(shù)字,包含浮點數(shù)和整數(shù)

字符串,需要包裹在雙引號中

Bool值,true 或者 false

數(shù)組,需要包裹在方括號中 []

對象,需要包裹在大括號中 {}

Null

還需要注意的是 JSON 文件中無法使用注釋,試圖添加注釋將會引發(fā)報錯。


2.4 js

一個服務僅僅只有界面展示是不夠的,還需要和用戶做交互:響應用戶的點擊、獲取用戶的位置等等。在小程序里邊,我們就通過編寫 JS 腳本文件來處理用戶的操作。


注冊頁面

對于小程序中的每個頁面,都需要在頁面對應的 js 文件中進行注冊,指定頁面的初始數(shù)據(jù)、生命周期回調、事件處理函數(shù)等



使用 Page 構造器注冊頁面

簡單的頁面可以使用 Page() 進行構造。



使用 Component 構造器構造頁面

Page 構造器適用于簡單的頁面。但對于復雜的頁面, Page 構造器可能并不好用。

此時,可以使用 Component 構造器來構造頁面。 Component 構造器的主要區(qū)別是:方法需要放在 methods: { } 里面。

————————————————

版權聲明:本文為CSDN博主「前端嵐楓」的原創(chuàng)文章,遵循CC 4.0 BY-SA版權協(xié)議,轉載請附上原文出處鏈接及本聲明。

原文鏈接:https://blog.csdn.net/yilanyoumeng3/java/article/details/106292742





2020年,令人驚嘆的Echarts!

前端達人

點擊查看原圖


1.可視化面板介紹

應對現(xiàn)在數(shù)據(jù)可視化的趨勢,越來越多企業(yè)需要在很多場景(營銷數(shù)據(jù),生產數(shù)據(jù),用戶數(shù)據(jù))下使用,可視化圖表來展示體現(xiàn)數(shù)據(jù),讓數(shù)據(jù)更加直觀,數(shù)據(jù)特點更加突出。

01-技術要點

  1. div + css 布局
  2. flex 布局
  3. Less
  4. 原生js + jquery 使用
  5. rem適配
  6. echarts基礎

02-案例適配方案

  1. 設計稿是1920px
  2. flexible.js 把屏幕分為 24 等份
  3. cssrem 插件的基準值是 80px
    插件-配置按鈕—配置擴展設置–Root Font Size 里面 設置。
    但是別忘記重啟vscode軟件保證生效


03-頁面主體布局

  1. header布局
  2. mainbox布局
  3. 公共面板模塊 panel
  4. 柱形圖 bar
因為我們今天的主題是echarts部分所以前面的這些,我就為大家寫好框架,里面的布局相信以大家的能力都是分分鐘解決的事情。


2.Echarts(重點)

echarts介紹

常見的數(shù)據(jù)可視化庫:

D3.js 目前 Web 端評價最高的 Javascript 可視化工具庫(入手難)
ECharts.js 百度出品的一個開源 Javascript 數(shù)據(jù)可視化庫
Highcharts.js 國外的前端數(shù)據(jù)可視化庫,非商用免費,被許多國外大公司所使用
AntV 螞蟻金服全新一代數(shù)據(jù)可視化解決方案 等等
Highcharts 和 Echarts 就像是 Office 和 WPS 的關系

ECharts,一個使用 JavaScript 實現(xiàn)的開源可視化庫,可以流暢的運行在 PC 和移動設備上,兼容當前絕大部分瀏覽器(IE8/9/10/11,Chrome,F(xiàn)irefox,Safari等),底層依賴矢量圖形庫 ZRender,提供直觀,交互豐富,可高度個性化定制的數(shù)據(jù)可視化圖表。

官網地址:https://www.echartsjs.com/zh/index.html

echarts體驗
下載echarts https://github.com/apache/incubator-echarts/tree/4.5.0

使用步驟(5大步驟):
1.引入echarts 插件文件到html頁面中
2.準備一個具備大小的DOM容器

<div id="main" style="width: 600px;height:400px;"></div>

3.初始化echarts實例對象

var myChart = echarts.init(document.getElementById('main'));

4.指定配置項和數(shù)據(jù)(option)

var option = {
    xAxis: {
        type: 'category',
        data: ['Mon', 'Tue', 'Wed', 'Thu', 'Fri', 'Sat', 'Sun']
    },
    yAxis: {
        type: 'value'
    },
    series: [{
        data: [820, 932, 901, 934, 1290, 1330, 1320],
        type: 'line'
    }]
};

5.將配置項設置給echarts實例對象


myChart.setOption(option);  


echarts基礎配置

這是要求同學們知道以下配置每個模塊的主要作用干什么的就可以了

series

系列列表。每個系列通過 type 決定自己的圖表類型

大白話:圖標數(shù)據(jù),指定什么類型的圖標,可以多個圖表重疊。

xAxis:直角坐標系 grid 中的 x 軸

boundaryGap: 坐標軸兩邊留白策略 true,這時候刻度只是作為分隔線,標簽和數(shù)據(jù)點都會在兩個刻度之間的帶(band)中間。

yAxis:直角坐標系 grid 中的 y 軸

grid:直角坐標系內繪圖網格。

title:標題組件

tooltip:提示框組件

legend:圖例組件

color:調色盤顏色列表

數(shù)據(jù)堆疊,同個類目軸上系列配置相同的stack值后 后一個系列的值會在前一個系列的值上相加。



option = {

    // color設置我們線條的顏色 注意后面是個數(shù)組

    color: ['pink', 'red', 'green', 'skyblue'],

    // 設置圖表的標題

    title: {

        text: '折線圖堆疊123'

    },

    // 圖表的提示框組件 

    tooltip: {

        // 觸發(fā)方式

        trigger: 'axis'

    },

    // 圖例組件

    legend: {

       // series里面有了 name值則 legend里面的data可以刪掉

    },

    // 網格配置  grid可以控制線形圖 柱狀圖 圖表大小

    grid: {

        left: '3%',

        right: '4%',

        bottom: '3%',

        // 是否顯示刻度標簽 如果是true 就顯示 否則反之

        containLabel: true

    },

    // 工具箱組件  可以另存為圖片等功能

    toolbox: {

        feature: {

            saveAsImage: {}

        }

    },

    // 設置x軸的相關配置

    xAxis: {

        type: 'category',

        // 是否讓我們的線條和坐標軸有縫隙

        boundaryGap: false,

        data: ['星期一', '周二', '周三', '周四', '周五', '周六', '周日']

    },

     // 設置y軸的相關配置

    yAxis: {

        type: 'value'

    },

    // 系列圖表配置 它決定著顯示那種類型的圖表

    series: [

        {

            name: '郵件營銷',

            type: 'line',

           

            data: [120, 132, 101, 134, 90, 230, 210]

        },

        {

            name: '聯(lián)盟廣告',

            type: 'line',



            data: [220, 182, 191, 234, 290, 330, 310]

        },

        {

            name: '視頻廣告',

            type: 'line',

          

            data: [150, 232, 201, 154, 190, 330, 410]

        },

        {

            name: '直接訪問',

            type: 'line',

          

            data: [320, 332, 301, 334, 390, 330, 320]

        }

    ]

};



3.Echarts快速使用

1.官網實例

點擊查看原圖



官網默認為我們提供了大量的案例,我們需要使用那一種只需要直接點擊打開后復制他們的相關配置,然后按照我上面說的5大步驟進行使用即可。

2.社區(qū)Gallery

點擊查看原圖



官方自帶的圖例,可能在很多時候并不能滿足我們的需要,在社區(qū)這里可以找到一些基于echart的高度定制好的圖表,相當于基于jquery開發(fā)的插件,這里是基于echarts開發(fā)的第三方的圖表。

本案例中使用了地圖模擬飛行的案例就是從社區(qū)中進行引用的,
參考社區(qū)的例子:https://gallery.echartsjs.com/editor.html?c=x0-ExSkZDM (模擬飛機航線)
實現(xiàn)步驟:

第一需要下載china.js提供中國地圖的js文件
第二個因為里面代碼比較多,我們新建一個新的js文件 myMap.js 引入
使用社區(qū)提供的配置即可。
代碼已經上傳至我的碼云如有需要的小伙伴可自行下載:
https://gitee.com/jiuyueqi/echarts

ps:最后呢,如果大家看完樓主的文章覺得對echarts的學習和了解有所幫助,麻煩大家路過點個贊點個關注唄!樓主后續(xù)還會繼續(xù)更新有關前端方面的面試題資料或者其他方面的知識。
————————————————
版權聲明:本文為CSDN博主「程序猿玖月柒」的原創(chuàng)文章,遵循CC 4.0 BY-SA版權協(xié)議,轉載請附上原文出處鏈接及本聲明。
原文鏈接:https://blog.csdn.net/weixin_45257157/java/article/details/106300587

關于JavaScript獲取時間函數(shù)及實現(xiàn)倒計時

前端達人

JavaScript數(shù)組對象的迭代方法詳解

上一篇博客講到了數(shù)組的方法,當然里邊比較復雜的就是數(shù)組的迭代方法,因為涉及到了回調函數(shù),所以這篇博客我們來詳細講解一下js數(shù)組迭代方法的使用。


1.forEach(funcrion(value,index,arr){}):對數(shù)組的每一項運行給定函數(shù),這個方法不進行返回,所以一般用于讓數(shù)組循環(huán)執(zhí)行某方法。

  var arr=[1,2,3,4,5,6];

    arr.forEach(function(val,index,arr){

        console.log(val,index,arr);

    })

    // 其中:

    // value:每一個數(shù)組項的值 必填項

    // index:每一個數(shù)組項對應的索引

    // arr:當前的數(shù)組


注意:forEach()方法不返回值,所以回調函數(shù)中使用return會打印出來undefined。

2.map(funcrion(value,index,arr){}):對數(shù)組的每一項運行給定函數(shù),它將返回執(zhí)行函數(shù)后的結果組成的新數(shù)組。

 var aNum2 = [1.2, 1.8, 2.0, 4.3];

    console.log(aNum2.map(Math.floor()));// [1,1,2,4]

    

    var arr=[1,2,3];

    console.log(arr.map(function(val,index){

        return val*3

    }));// 3 6 9

    // 其中:

    // value:每一個數(shù)組項的值 必填項

    // index:每一個數(shù)組項對應的索引

    // arr:當前的數(shù)組

注意:map()方法有返回值,返回值為新的數(shù)組,所以可以直接再回調函數(shù)中return

3.every(funcrion(value,index,arr){}):對數(shù)組的每一項都運行給定函數(shù),進項判斷,若對于每項執(zhí)行函數(shù)都返回了true,則其結果為true。

 var arr=[10,20,30];

    console.log(arr.every(function(val){

        return val>20;

    }));// false

    

    console.log(arr.every(function(val){

        return val>0;

    }));// true

    

    // 其中:

    // value:每一個數(shù)組項的值 必填項

    // index:每一個數(shù)組項對應的索引

    // arr:當前的數(shù)組



注意:every()方法所有的數(shù)組項都符合判斷時返回true,否則返回false。

4.some(funcrion(value,index,arr){}):對數(shù)組的每一項都運行給定函數(shù),進行判斷,若存在一項符合條件的數(shù)組項,則其結果為true。

    var arr=[10,20,30];

    console.log(arr.some(function(val){

        return val>20;

    }));// true

    

    console.log(arr.some(function(val){

        return val>0;

    }));// true

    

    console.log(arr.some(function(val){

        return val<0;

    }));// false

    

    arr.some(function(val){

        console.log(val<0);

    });//fasle false false

    // 其中:

    // value:每一個數(shù)組項的值 必填項

    // index:每一個數(shù)組項對應的索引

    // arr:當前的數(shù)組


注意:some()方法如果回調函數(shù)執(zhí)行完會根據(jù)結果返回true或false,但是回調函數(shù)中打印判斷是,只會作為判斷條件的返回值,則會打印多遍。

5.fliter(funcrion(value,index,arr){}):對數(shù)組的每一項都運行給定函數(shù),進行過濾,將符合條件的數(shù)組項添加到新的數(shù)組中,并返回新的數(shù)組。

   var aNum=[1,2,3,4];
    console.log(aNum.filter(function (num) {
        return num > 1;
    }));//[2,3,4,]
    aNum.filter(function (num) {
        console.log(num > 1);//true true true
    })

注意:filter()方法對數(shù)組項進行過濾,然后將符合條件的數(shù)組項添加到一個新的數(shù)組并返回,但是如果直接打印這個判斷條件,相當于打印的判斷條件的結果,只會返回true或者false。

6.ES6中新增的迭代方法

1.find():返回第一個符合傳入測試(函數(shù))條件的數(shù)組元素。


  var aNum=[10,20,30,40];

    console.log(aNum.find(function (num) {

        return num > 19;

    }));//1

    console.log(aNum.find(function (num) {

        return num < 0;

    }));//undefined



2.findIndex():返回符合傳入測試(函數(shù))條件的數(shù)組元素索引。


console.log(aNum.findIndex(function (num) { return num > 19; }));//3


3.includes():判斷一個數(shù)組是否包含一個指定的值。

總結:

forEach()與map()是一對,用于數(shù)組遍歷執(zhí)行指定函數(shù),前者不返回數(shù)組,后者返回 處理過的新數(shù)組。
every()與some()是一對,分別適用于檢測數(shù)組是否全部滿足某條件或者存在滿足的數(shù)組項,返回true或false。
filter()則是相當于過濾器的存在,過濾掉數(shù)組中不符合條件的數(shù)據(jù),將符合條件的數(shù)組項添加到新數(shù)組,并返回。
————————————————
版權聲明:本文為CSDN博主「Mr_Han119」的原創(chuàng)文章,遵循CC 4.0 BY-SA版權協(xié)議,轉載請附上原文出處鏈接及本聲明。
原文鏈接:https://blog.csdn.net/qq_39155611/java/article/details/106294417


了不起的 tsconfig.json 指南

seo達人

在 TypeScript 開發(fā)中,tsconfig.json 是個不可或缺的配置文件,它是我們在 TS 項目中最常見的配置文件,那么你真的了解這個文件嗎?它里面都有哪些優(yōu)秀配置?如何配置一個合理的 tsconfig.json 文件?本文將全面帶大家一起詳細了解 tsconfig.json 的各項配置。



本文將從以下幾個方面全面介紹 tsconfig.json 文件:

了不起的 tsconfig.json 指南.png




水平有限,歡迎各位大佬指點~~


一、tsconfig.json 簡介


1. 什么是 tsconfig.json

TypeScript 使用 tsconfig.json 文件作為其配置文件,當一個目錄中存在 tsconfig.json 文件,則認為該目錄為 TypeScript 項目的根目錄。

通常 tsconfig.json 文件主要包含兩部分內容:指定待編譯文件和定義編譯選項。



從《TypeScript編譯器的配置文件的JSON模式》可知,目前 tsconfig.json 文件有以下幾個頂層屬性:


compileOnSave

compilerOptions

exclude

extends

files

include

references

typeAcquisition


文章后面會詳細介紹一些常用屬性配置。



2. 為什么使用 tsconfig.json

通常我們可以使用 tsc 命令來編譯少量 TypeScript 文件:


/*

 參數(shù)介紹:

 --outFile // 編譯后生成的文件名稱

 --target  // 指定ECMAScript目標版本

 --module  // 指定生成哪個模塊系統(tǒng)代碼

 index.ts  // 源文件

*/

$ tsc --outFile leo.js --target es3 --module amd index.ts

但如果實際開發(fā)的項目,很少是只有單個文件,當我們需要編譯整個項目時,就可以使用 tsconfig.json 文件,將需要使用到的配置都寫進 tsconfig.json 文件,這樣就不用每次編譯都手動輸入配置,另外也方便團隊協(xié)作開發(fā)。



二、使用 tsconfig.json

目前使用 tsconfig.json 有2種操作:


1. 初始化 tsconfig.json

在初始化操作,也有 2 種方式:


手動在項目根目錄(或其他)創(chuàng)建 tsconfig.json 文件并填寫配置;

通過 tsc --init 初始化 tsconfig.json 文件。


2. 指定需要編譯的目錄

在不指定輸入文件的情況下執(zhí)行 tsc 命令,默認從當前目錄開始編譯,編譯所有 .ts 文件,并且從當前目錄開始查找 tsconfig.json 文件,并逐級向上級目錄搜索。


$ tsc

另外也可以為 tsc 命令指定參數(shù) --project 或 -p 指定需要編譯的目錄,該目錄需要包含一個 tsconfig.json 文件,如:


/*

 文件目錄:

 ├─src/

 │  ├─index.ts

 │  └─tsconfig.json

 ├─package.json

*/

$ tsc --project src

注意,tsc 的命令行選項具有優(yōu)先級,會覆蓋 tsconfig.json 中的同名選項。



更多 tsc 編譯選項,可查看《編譯選項》章節(jié)。



三、使用示例

這個章節(jié),我們將通過本地一個小項目 learnTsconfig 來學著實現(xiàn)一個簡單配置。

當前開發(fā)環(huán)境:windows / node 10.15.1 / TypeScript3.9



1. 初始化 learnTsconfig 項目

執(zhí)行下面命令:


$ mkdir learnTsconfig

$ cd .\learnTsconfig\

$ mkdir src

$ new-item index.ts

并且我們?yōu)?index.ts 文件寫一些簡單代碼:


// 返回當前版本號

function getVersion(version:string = "1.0.0"): string{

   return version;

}


console.log(getVersion("1.0.1"))

我們將獲得這么一個目錄結構:


 └─src/

    └─index.ts


2. 初始化 tsconfig.json 文件

在 learnTsconfig 根目錄執(zhí)行:


$ tsc --init


3. 修改 tsconfig.json 文件

我們設置幾個常見配置項:


{

 "compilerOptions": {

   "target": "ES5",             // 目標語言的版本

   "module": "commonjs",        // 指定生成代碼的模板標準

   "noImplicitAny": true,       // 不允許隱式的 any 類型

   "removeComments": true,      // 刪除注釋

   "preserveConstEnums": true,  // 保留 const 和 enum 聲明

   "sourceMap": true            // 生成目標文件的sourceMap文件

 },

 "files": [   // 指定待編譯文件

   "./src/index.ts"  

 ]

}

其中需要注意一點:

files 配置項值是一個數(shù)組,用來指定了待編譯文件,即入口文件。

當入口文件依賴其他文件時,不需要將被依賴文件也指定到 files 中,因為編譯器會自動將所有的依賴文件歸納為編譯對象,即 index.ts 依賴 user.ts 時,不需要在 files 中指定 user.ts , user.ts 會自動納入待編譯文件。



4. 執(zhí)行編譯

配置完成后,我們可以在命令行執(zhí)行 tsc 命令,執(zhí)行編譯完成后,我們可以得到一個 index.js 文件和一個 index.js.map 文件,證明我們編譯成功,其中 index.js 文件內容如下:


function getVersion(version) {

   if (version === void 0) { version = "1.0.0"; }

   return version;

}

console.log(getVersion("1.0.1"));

//# sourceMappingURL=index.js.map

可以看出,tsconfig.json 中的 removeComments 配置生效了,將我們添加的注釋代碼移除了。



到這一步,就完成了這個簡單的示例,接下來會基于這個示例代碼,講解《七、常見配置示例》。



四、tsconfig.json 文件結構介紹


1. 按頂層屬性分類

在 tsconfig.json 文件中按照頂層屬性,分為以下幾類:

tsconfig.json 文件結構(頂層屬性).png


了不起的 tsconfig.json 指南.png



2. 按功能分類

tsconfig.json 文件結構(功能).png




五、tsconfig.json 配置介紹


1. compileOnSave

compileOnSave 屬性作用是設置保存文件的時候自動編譯,但需要編譯器支持。


{

   // ...

 "compileOnSave": false,

}


2. compilerOptions

compilerOptions 屬性作用是配置編譯選項。

若 compilerOptions 屬性被忽略,則編譯器會使用默認值,可以查看《官方完整的編譯選項列表》。

編譯選項配置非常繁雜,有很多配置,這里只列出常用的配置。


{

 // ...

 "compilerOptions": {

   "incremental": true, // TS編譯器在第一次編譯之后會生成一個存儲編譯信息的文件,第二次編譯會在第一次的基礎上進行增量編譯,可以提高編譯的速度

   "tsBuildInfoFile": "./buildFile", // 增量編譯文件的存儲位置

   "diagnostics": true, // 打印診斷信息

   "target": "ES5", // 目標語言的版本

   "module": "CommonJS", // 生成代碼的模板標準

   "outFile": "./app.js", // 將多個相互依賴的文件生成一個文件,可以用在AMD模塊中,即開啟時應設置"module": "AMD",

   "lib": ["DOM", "ES2015", "ScriptHost", "ES2019.Array"], // TS需要引用的庫,即聲明文件,es5 默認引用dom、es5、scripthost,如需要使用es的高級版本特性,通常都需要配置,如es8的數(shù)組新特性需要引入"ES2019.Array",

   "allowJS": true, // 允許編譯器編譯JS,JSX文件

   "checkJs": true, // 允許在JS文件中報錯,通常與allowJS一起使用

   "outDir": "./dist", // 指定輸出目錄

   "rootDir": "./", // 指定輸出文件目錄(用于輸出),用于控制輸出目錄結構

   "declaration": true, // 生成聲明文件,開啟后會自動生成聲明文件

   "declarationDir": "./file", // 指定生成聲明文件存放目錄

   "emitDeclarationOnly": true, // 只生成聲明文件,而不會生成js文件

   "sourceMap": true, // 生成目標文件的sourceMap文件

   "inlineSourceMap": true, // 生成目標文件的inline SourceMap,inline SourceMap會包含在生成的js文件中

   "declarationMap": true, // 為聲明文件生成sourceMap

   "typeRoots": [], // 聲明文件目錄,默認時node_modules/@types

   "types": [], // 加載的聲明文件包

   "removeComments":true, // 刪除注釋

   "noEmit": true, // 不輸出文件,即編譯后不會生成任何js文件

   "noEmitOnError": true, // 發(fā)送錯誤時不輸出任何文件

   "noEmitHelpers": true, // 不生成helper函數(shù),減小體積,需要額外安裝,常配合importHelpers一起使用

   "importHelpers": true, // 通過tslib引入helper函數(shù),文件必須是模塊

   "downlevelIteration": true, // 降級遍歷器實現(xiàn),如果目標源是es3/5,那么遍歷器會有降級的實現(xiàn)

   "strict": true, // 開啟所有嚴格的類型檢查

   "alwaysStrict": true, // 在代碼中注入'use strict'

   "noImplicitAny": true, // 不允許隱式的any類型

   "strictNullChecks": true, // 不允許把null、undefined賦值給其他類型的變量

   "strictFunctionTypes": true, // 不允許函數(shù)參數(shù)雙向協(xié)變

   "strictPropertyInitialization": true, // 類的實例屬性必須初始化

   "strictBindCallApply": true, // 嚴格的bind/call/apply檢查

   "noImplicitThis": true, // 不允許this有隱式的any類型

   "noUnusedLocals": true, // 檢查只聲明、未使用的局部變量(只提示不報錯)

   "noUnusedParameters": true, // 檢查未使用的函數(shù)參數(shù)(只提示不報錯)

   "noFallthroughCasesInSwitch": true, // 防止switch語句貫穿(即如果沒有break語句后面不會執(zhí)行)

   "noImplicitReturns": true, //每個分支都會有返回值

   "esModuleInterop": true, // 允許export=導出,由import from 導入

   "allowUmdGlobalAccess": true, // 允許在模塊中全局變量的方式訪問umd模塊

   "moduleResolution": "node", // 模塊解析策略,ts默認用node的解析策略,即相對的方式導入

   "baseUrl": "./", // 解析非相對模塊的基地址,默認是當前目錄

   "paths": { // 路徑映射,相對于baseUrl

     // 如使用jq時不想使用默認版本,而需要手動指定版本,可進行如下配置

     "jquery": ["node_modules/jquery/dist/jquery.min.js"]

   },

   "rootDirs": ["src","out"], // 將多個目錄放在一個虛擬目錄下,用于運行時,即編譯后引入文件的位置可能發(fā)生變化,這也設置可以虛擬src和out在同一個目錄下,不用再去改變路徑也不會報錯

   "listEmittedFiles": true, // 打印輸出文件

   "listFiles": true// 打印編譯的文件(包括引用的聲明文件)

 }

}


3. exclude

exclude 屬性作用是指定編譯器需要排除的文件或文件夾。

默認排除 node_modules 文件夾下文件。


{

   // ...

 "exclude": [

   "src/lib" // 排除src目錄下的lib文件夾下的文件不會編譯

 ]

}

和 include 屬性一樣,支持 glob 通配符:


* 匹配0或多個字符(不包括目錄分隔符)

? 匹配一個任意字符(不包括目錄分隔符)

**/ 遞歸匹配任意子目錄


4. extends

extends 屬性作用是引入其他配置文件,繼承配置。

默認包含當前目錄和子目錄下所有 TypeScript 文件。


{

   // ...

 // 把基礎配置抽離成tsconfig.base.json文件,然后引入

   "extends": "./tsconfig.base.json"

}


5. files

files 屬性作用是指定需要編譯的單個文件列表。

默認包含當前目錄和子目錄下所有 TypeScript 文件。


{

   // ...

 "files": [

   // 指定編譯文件是src目錄下的leo.ts文件

   "scr/leo.ts"

 ]

}


6. include

include 屬性作用是指定編譯需要編譯的文件或目錄。


{

   // ...

 "include": [

   // "scr" // 會編譯src目錄下的所有文件,包括子目錄

   // "scr/*" // 只會編譯scr一級目錄下的文件

   "scr/*/*" // 只會編譯scr二級目錄下的文件

 ]

}


7. references

references 屬性作用是指定工程引用依賴。

在項目開發(fā)中,有時候我們?yōu)榱朔奖銓⑶岸隧椖亢秃蠖薾ode項目放在同一個目錄下開發(fā),兩個項目依賴同一個配置文件和通用文件,但我們希望前后端項目進行靈活的分別打包,那么我們可以進行如下配置:


{

   // ...

 "references": [ // 指定依賴的工程

    {"path": "./common"}

 ]

}


8. typeAcquisition

typeAcquisition 屬性作用是設置自動引入庫類型定義文件(.d.ts)相關。

包含 3 個子屬性:


enable  : 布爾類型,是否開啟自動引入庫類型定義文件(.d.ts),默認為 false;

include  : 數(shù)組類型,允許自動引入的庫名,如:["jquery", "lodash"];

exculde  : 數(shù)組類型,排除的庫名。

{

   // ...

 "typeAcquisition": {

   "enable": false,

   "exclude": ["jquery"],

   "include": ["jest"]

 }

}


六、常見配置示例

本部分內容中,我們找了幾個實際開發(fā)中比較常見的配置,當然,還有很多配置需要自己摸索喲~~



1. 移除代碼中注釋

tsconfig.json:


{

 "compilerOptions": {

   "removeComments": true,

 }

}

編譯前:


// 返回當前版本號

function getVersion(version:string = "1.0.0"): string{

   return version;

}

console.log(getVersion("1.0.1"))

編譯結果:


function getVersion(version) {

   if (version === void 0) { version = "1.0.0"; }

   return version;

}

console.log(getVersion("1.0.1"));


2. 開啟null、undefined檢測

tsconfig.json:


{

   "compilerOptions": {

       "strictNullChecks": true

   },

}

修改 index.ts 文件內容:


const leo;

leo = new Pingan('leo','hello');


這時候編輯器也會提示錯誤信息,執(zhí)行 tsc 后,控制臺報錯:


src/index.ts:9:11 - error TS2304: Cannot find name 'Pingan'.


9 leo = new Pingan('leo','hello');


Found 1 error.


3. 配置復用

通過 extends 屬性實現(xiàn)配置復用,即一個配置文件可以繼承另一個文件的配置屬性。

比如,建立一個基礎的配置文件 configs/base.json :


{

 "compilerOptions": {

   "noImplicitAny": true,

   "strictNullChecks": true

 }

}

在tsconfig.json 就可以引用這個文件的配置了:


{

 "extends": "./configs/base",

 "files": [

   "main.ts",

   "supplemental.ts"

 ]

}


4. 生成枚舉的映射代碼

在默認情況下,使用 const 修飾符后,枚舉不會生成映射代碼。

如下,我們可以看出:使用 const 修飾符后,編譯器不會生成任何 RequestMethod 枚舉的任何映射代碼,在其他地方使用時,內聯(lián)每個成員的值,節(jié)省很大開銷。


const enum RequestMethod {

 Get,

 Post,

 Put,

 Delete

}


let methods = [

 RequestMethod.Get,

 RequestMethod.Post

]

編譯結果:


"use strict";

let methods = [

   0 /* Get */,

   1 /* Post */

];

當然,我們希望生成映射代碼時,也可以設置 tsconfig.json 中的配置,設置 preserveConstEnums 編譯器選項為 true :


{

 "compilerOptions": {

   "target": "es5",

   "preserveConstEnums": true

 }

}


最后編譯結果變成:


"use strict";

var RequestMethod;

(function (RequestMethod) {

   RequestMethod[RequestMethod["Get"] = 0] = "Get";

   RequestMethod[RequestMethod["Post"] = 1] = "Post";

   RequestMethod[RequestMethod["Put"] = 2] = "Put";

   RequestMethod[RequestMethod["Delete"] = 3] = "Delete";

})(RequestMethod || (RequestMethod = {}));

let methods = [

   0 /* Get */,

   1 /* Post */

];


5. 關閉 this 類型注解提示

通過下面代碼編譯后會報錯:


const button = document.querySelector("button");

button?.addEventListener("click", handleClick);

function handleClick(this) {

console.log("Clicked!");

this.removeEventListener("click", handleClick);

}


報錯內容:


src/index.ts:10:22 - error TS7006: Parameter 'this' implicitly has an 'any' type.

10 function handleClick(this) {

Found 1 error.


這是因為 this 隱式具有 any 類型,如果沒有指定類型注解,編譯器會提示“"this" 隱式具有類型 "any",因為它沒有類型注釋?!薄?



解決方法有2種:


指定 this 類型,如本代碼中為 HTMLElement 類型:

HTMLElement 接口表示所有的 HTML 元素。一些HTML元素直接實現(xiàn)了 HTMLElement 接口,其它的間接實現(xiàn)HTMLElement接口。

關于 HTMLElement 可查看詳細。


使用 --noImplicitThis 配置項:


在 TS2.0 還增加一個新的編譯選項: --noImplicitThis,表示當 this 表達式值為 any 類型時生成一個錯誤信息。我們設置為 true 后就能正常編譯。


{

 "compilerOptions": {

   "noImplicitThis": true

 }

}


七、Webpack/React 中使用示例


1. 配置編譯 ES6 代碼,JSX 文件

創(chuàng)建測試項目 webpack-demo,結構如下:


webpack-demo/

 |- package.json

 |- tsconfig.json

 |- webpack.config.js

 |- /dist

   |- bundle.js

   |- index.html

 |- /src

   |- index.js

   |- index.ts

 |- /node_modules

安裝 TypeScript 和 ts-loader:


$ npm install --save-dev typescript ts-loader

配置 tsconfig.json,支持 JSX,并將 TypeScript 編譯為 ES5:


{

 "compilerOptions": {

   "outDir": "./dist/",

   "noImplicitAny": true,

+   "module": "es6",

+   "target": "es5",

+   "jsx": "react",

   "allowJs": true

 }

}

還需要配置 webpack.config.js,使其能夠處理 TypeScript 代碼,這里主要在 rules 中添加 ts-loader :


const path = require('path');


module.exports = {

 entry: './src/index.ts',

 module: {

   rules: [

     {

       test: /\.tsx?$/,

       use: 'ts-loader',

       exclude: /node_modules/

     }

   ]

 },

 resolve: {

   extensions: [ '.tsx', '.ts', '.js' ]

 },

 output: {

   filename: 'bundle.js',

   path: path.resolve(__dirname, 'dist')

 }

};


2. 配置 source map

想要啟用 source map,我們必須配置 TypeScript,以將內聯(lián)的 source map 輸出到編譯后的 JavaScript 文件中。

只需要在 tsconfig.json 中配置 sourceMap 屬性:


 {

   "compilerOptions": {

     "outDir": "./dist/",

+     "sourceMap": true,

     "noImplicitAny": true,

     "module": "commonjs",

     "target": "es5",

     "jsx": "react",

     "allowJs": true

   }

 }

然后配置 webpack.config.js 文件,讓 webpack 提取 source map,并內聯(lián)到最終的 bundle 中:


 const path = require('path');


 module.exports = {

   entry: './src/index.ts',

+   devtool: 'inline-source-map',

   module: {

     rules: [

       {

         test: /\.tsx?$/,

         use: 'ts-loader',

         exclude: /node_modules/

       }

     ]

   },

   resolve: {

     extensions: [ '.tsx', '.ts', '.js' ]

   },

   output: {

     filename: 'bundle.js',

     path: path.resolve(__dirname, 'dist')

   }

 };


八、總結

本文較全面介紹了 tsconfig.json 文件的知識,從“什么是 tsconfig.js 文件”開始,一步步帶領大家全面認識 tsconfig.json 文件。

文中通過一個簡單 learnTsconfig 項目,讓大家知道項目中如何使用 tsconfig.json 文件。在后續(xù)文章中,我們將這么多的配置項進行分類學習。最后通過幾個常見配置示例,解決我們開發(fā)中遇到的幾個常見問題。

vue.js路由與vuex數(shù)據(jù)模型設計

seo達人

路由設計

本則路由考慮驗證進入登錄頁面,完成登錄操作進入首頁。


import Vue from "vue";

import Router from "vue-router";

Vue.use(Router);


import store from "@/store/store";


// (延遲加載)

const Login = () => import("@/views/login");

const Home = () => import("@/views/home");


const HomeRoute = {

 path: "/",

 name: "首頁",

 component: Home

};


export { HomeRoute };


const router = new Router({

 base: process.env.BASE_URL,

 routes: [

   {

     path: "/login",

     name: "登錄",

     component: Login

   },

   HomeRoute

 ]

});


router.beforeEach((to, from, next) => {

 let loginName = store.state.user.loginName;

 if (to.path === "/" && loginName == "") {

   next("/login");

 } else {

   next();

 }

});


export default router;

數(shù)據(jù)模型

const state = {

 loginName: ""

};

const mutations = {

 SET_LOGINNAME(state, loginName) {

   state.loginName = loginName;

 }

};

const actions = {

 login({ commit }, userInfo) {

   return new Promise((res, ret) => {

     commit("SET_LOGINNAME", userInfo);

     res();

   });

 },

 logout({ commit }) {

   return new Promise((res, ret) => {

     commit("SET_LOGINNAME", "");

     res();

   });

 }

};

export default {

 namespaced: true,

 state,

 mutations,

 actions

};

import Vue from "vue";

import Vuex from "vuex";

Vue.use(Vuex);


import user from "./modules/user";


const store = new Vuex.Store({

 modules: {

   user

 }

});


export default store;

組件

<div class="modify">

 <input

   type="text"

   @keydown.enter.prevent="handleKeydown"

   v-model="currentVal"

   placeholder="使用enter鍵切換頻道"

 />

 <button @click="reset" style="margin-left:5px;outline:none;cursor:pointer;">復位</button>

</div>

import { mapState, mapMutations, mapActions } from "vuex";

export default {

 name: "login",

 data() {

   return {

     currentVal: "",

     list: ["咨詢服務", "音悅臺", "體育臺", "財經頻道", "時尚資訊"],

     index: 0

   };

 },

 computed: {

   ...mapState({

     loginName: state => state.user.loginName

   })

 },

 methods: {

   ...mapActions({

     login: "user/login"

   }),

   handleToHome() {

     let userInfo = "user";

     this.login(userInfo);

     this.$router.push({

       path: "/"

     });

   },

RN和React路由詳解及對比

seo達人

前言

在平時H5或者RN開發(fā)時,我們業(yè)務場景中大部分都不是單頁面的需求,那這時我們就能使用路由在進行多頁面的切換。下面會對比一下react路由和RN路由的本質區(qū)別和使用方法。


路由(routing)是指分組從源到目的地時,決定端到端路徑的網絡范圍的進程

React路由

簡介

使用React構建的單頁面應用,要想實現(xiàn)頁面間的跳轉,首先想到的就是使用路由。在React中,常用的有兩個包可以實現(xiàn)這個需求,那就是react-router和react-router-dom。本文主要針對react-router-dom進行說明


在根組件上配置路由,引用react-router-dom結構{ HashRouter as Router, Route ,Link ,Redirect ,Switch },HashRouter組件是路由的根組件,定義屬性和方法傳遞給子組件。Router組件進行路由,指定每個路由跳轉到相應的組件。Link組件指定跳轉鏈接。Redirect組件路由重定向,不管什么情況下,都會跳轉當前指定的路徑,和switch組件聯(lián)合起來一起調用,當路徑匹配到路由,不在往下匹配


兩類路由

HashRouter:利用監(jiān)聽hash變化(有一個事件hashchange)實現(xiàn)路由切換,它是路由容器,

渲染子組件,并向下層子組件傳遞(Context上下文傳遞)loaction,history等路由信息


BrowserHistory:利用H5Api實現(xiàn)路由切換,是路由容器,渲染子組件,

并向子組件傳遞loaction,history等路由信息

路由配置

image-20200601110809995


路由實現(xiàn)原理

HashRouter只是一個容器,本身并沒有DOM結構

它渲染的就是它的子組件,并向下層傳遞location

組件掛載完成之后根據(jù)hash改變pathname的值,如果沒有hash值就默認展示根組件

需要跳轉路由頁面時我們使用link或者push去賦值hash的pathname 如this.props.history.push({ pathname: preview, param: { pic, index } });

當hash值發(fā)生變化的時候會通過hashchange捕獲變化,并給pathname重新賦值

拿到上下文中傳過來的location,然后取出pathname。再對它的子組件進行遍歷,如果子組件的path屬性和當前上下文中傳過來的pathname屬性相匹配就進行渲染,若不匹配就返回null。

總結

React路由是實質就是,根據(jù)遍歷識別路由的pathname,來切換router路由容器中component組件的加載渲染。每次更改pathname就都是組件的重新渲染流程,頁面也都會呈現(xiàn)出刷新的效果。


RN路由

簡介

RN把導航和路由都集中到了react-navigation庫里面

組件使用堆棧式的頁面導航來實現(xiàn)各個頁面跳轉

構造函數(shù):StackNavigator(RouteConfigs, StackNavigatorConfig)

RouteConfigs:頁面路由配置

StackNavigatorConfig:路由參數(shù)配置

路由配置

image-20200601111333107


參數(shù)詳解

navigationOptions:配置StackNavigator的一些屬性。


   title:標題,如果設置了這個導航欄和標簽欄的title就會變成一樣的,不推薦使用

   header:可以設置一些導航的屬性,如果隱藏頂部導航欄只要將這個屬性設置為null

   headerTitle:設置導航欄標題,推薦

   headerBackTitle:設置跳轉頁面左側返回箭頭后面的文字,默認是上一個頁面的標題??梢宰远x,也可以設置為null

   headerTruncatedBackTitle:設置當上個頁面標題不符合返回箭頭后的文字時,默認改成"返回"

   headerRight:設置導航條右側。可以是按鈕或者其他視圖控件

   headerLeft:設置導航條左側。可以是按鈕或者其他視圖控件

   headerStyle:設置導航條的樣式。背景色,寬高等

   headerTitleStyle:設置導航欄文字樣式

   headerBackTitleStyle:設置導航欄‘返回’文字樣式

   headerTintColor:設置導航欄顏色

   headerPressColorAndroid:安卓獨有的設置顏色紋理,需要安卓版本大于5.0

   gesturesEnabled:是否支持滑動返回手勢,iOS默認支持,安卓默認關閉



screen:對應界面名稱,需要填入import之后的頁面


mode:定義跳轉風格


  card:使用iOS和安卓默認的風格


  modal:iOS獨有的使屏幕從底部畫出。類似iOS的present效果


headerMode:返回上級頁面時動畫效果


  float:iOS默認的效果


  screen:滑動過程中,整個頁面都會返回


  none:無動畫


cardStyle:自定義設置跳轉效果


  transitionConfig: 自定義設置滑動返回的配置


  onTransitionStart:當轉換動畫即將開始時被調用的功能


  onTransitionEnd:當轉換動畫完成,將被調用的功能


path:路由中設置的路徑的覆蓋映射配置


initialRouteName:設置默認的頁面組件,必須是上面已注冊的頁面組件


initialRouteParams:初始路由參數(shù)

路由首頁

react:


image-20200601111638902


在react中初始化時沒有指定hash值,route會匹配路由表里面的根組件”/”


RN:


image-20200601111722749


RN 需要在StackNavigatorConfig里面指定首頁


RN路由使用

image-20200601112012191


在入口路由列表注冊完成之后 在導航器中的每一個頁面,都有 navigation 屬性 通過提供的navigate方法來提供跳轉


navigation

在導航器中每一個頁面都有navigation屬性,該屬性有以下幾個屬性/方法

navigate 跳轉到其他頁面 常用參數(shù)如下

routeName 導航器中配置的路由名稱

params 傳遞到下一個頁面的參數(shù)

state:state 里面包含有傳遞過來的參數(shù) params 、 key 、路由名稱 routeName

setParams 更改當前頁面路由參數(shù)(后面詳細介紹)

goBack: 回退可穿參數(shù)

navigate



setParams




循環(huán)設計,用戶體驗如何呼喚時代變革

ui設計分享達人

關于循環(huán)設計,可持續(xù)發(fā)展是商業(yè)領域非常關注的話題,作為UX需提前轉變思維,給企業(yè)帶來更多價值,一線大廠已在運用這種思維



本文共 3589 字,預計閱讀 10 分鐘

譯者推薦|本文從“可持續(xù)”和“設計”的兩點談起,來論述從線性經濟向可持續(xù)經濟的轉變,以及“可持續(xù)設計”的四個主要階段:理解、定義、制造、發(fā)布。

“循環(huán)設計”不是為了追求時髦或者抬升設計地位,而是將這個已經日益庸俗化的“設計”冠為自己的定語,是設計本身發(fā)展所趨,以及可持續(xù)發(fā)展所需,設計界需要對自己的責任有所承擔,形成一個全局觀、系統(tǒng)性看待設計問題的方式。讓回收利用和可持續(xù)發(fā)展成為一種規(guī)范,從而做到一勞永逸。

我們生活在一個呼喚變革的世界。在過去的50年中,現(xiàn)代社會所依賴的漫不經心和無休止的消費是不可持續(xù)的。我們從小就不關心自己的事情。如果有什么東西壞了,我們也就不修了。產品被設計成用完直接丟棄,而不是去修復。數(shù)字產品也不例外。然而,為了解決這些問題,出現(xiàn)了一種新的思維方式:循環(huán)設計(可持續(xù)設計)①。(益達說:其實這個理念和風格已經存在了很長的時間,大多應用在不為大眾所知的能源、材料再生流程之中,然而隨著時代的發(fā)展,循環(huán)設計可以變得更加普世。)

①注:循環(huán)設計是20世紀80-90年代產生的一種設計風格,他又稱回收設計,是指實現(xiàn)廣義收回和利用的方法,即在進行產品設計時,充分考慮產品零部件及材料回收的可能性,回收價值的大致方法,回收處理結構工藝性等于與回收有關的一系列問題,以達到零部件及材料資源和能源的再利用。它旨在通過設計來節(jié)約能源和材料,減少對環(huán)境的污染,使人類的設計物能多次反復利用,形成產品設計和使用的良性循環(huán)。

那么,循環(huán)設計方法意味著什么?在數(shù)字產品上要如何使用?在回答這些問題之前,首先,我們需要仔細觀察我們是如何構建我們的世界,為什么這個世界已經不可持續(xù)了,并且要理解環(huán)保世界的需求是如何改變我們的思維方式,促使我們渴望從線性設計模型轉變?yōu)檠h(huán)設計模型。


向循環(huán)轉變


我們的經濟主要基于“按需配置”流程之上。在此線性系統(tǒng)中,我們構建了會在一段時間后淘汰的產品,并且將其組件視為垃圾。與此相反,循環(huán)設計方法將產品的生命周期視為一個閉環(huán),其中資源不斷地被重新利用。


在“經典”線性模型中,產品經歷了生產、消費和破壞的各個階段,最終以浪費告終。在設計一款循環(huán)產品過程中,我們使用的方法包含四大階段,這四個階段形成了一個閉環(huán),并形成了一個恒定的循環(huán),在這個循環(huán)中,不僅僅只有閃閃發(fā)亮的、新的,未使用過的材料才被受歡迎。

 

循環(huán)設計方法的四個階段是:

理解 / 定義 / 制造 / 發(fā)布



當我們同時看線性設計和循環(huán)設計模型方法時,有一點吸引人的是,開始設計東西的時候,方法的差異。從只是生產某種東西,到對我們將要生產的產品做出深思熟慮的決定,以及在實施過程中付出的努力和關心,這是一個大轉變。


看看我們現(xiàn)在的立場


為什么做出這種轉變如此的重要?我確信每個看新聞的人都聽說過氣候變化。NASA 致力于解決環(huán)境問題,因此我們都可以非常詳細地了解人類行為和無限增長對我們生態(tài)系統(tǒng)的影響。


但好消息是我們不必繼續(xù)這樣做,因為我們可以很容易從數(shù)字世界中“產生”方式中學習事物的產生。電力廢棄物已成為現(xiàn)代世界的主要廢棄物來源之一。大量的手機和電腦被扔掉,隨之經濟是建立在每年都有新東西的基礎上的。


當您的手機屏幕意外碎裂時,我們該怎么辦?我們知道如何處理它嗎?我們知道如何修理嗎?我們并不知道……但是幸運的是,有些設計師對此問題提出了解決方案。Fairphone② 是一種合乎情理,模塊化的智能手機,其組件數(shù)量很少,可以輕松更換和回收。大公司也應朝這個方向邁出一步,讓回收利用和可持續(xù)發(fā)展成為一種時尚和規(guī)范,一勞永逸。

② Fairphone:這家公司生產的手機希望實現(xiàn)全球手機供應鏈的公平貿易,具體而言就是不使用“沖突礦物”并且確保生產手機的工人沒有被奴役和壓榨,目前仍然堅持在非洲貧困和戰(zhàn)亂的國家進口材料,已經在剛果和盧旺達境內找到了一些礦山,用更好的商業(yè)實踐推動當?shù)亟洕】档匕l(fā)展。


設計和設計師的重要性


設計師,比任何其他專業(yè)人士,都更有可能在一轉變中產生巨大的影響的人。我還敢說,我們有責任采用可持續(xù)設計的方式行動和思考。因為是我們創(chuàng)造了那些最終出現(xiàn)在傳送帶上的東西。我們也有責任教育我們的用戶。幸運的是,越來越多的人重視具有可持續(xù)發(fā)展目標的產品或品牌,或者重視起在產品背后有意義的故事。同樣,可持續(xù)發(fā)展不僅成為流行語,而且成為一種價值觀,被越來越多的人意識到基于有限資源的無限增長是無法實現(xiàn)的目標。但是,要從線性經濟向可持續(xù)經濟轉變,我們需要學習不同的思維方式。幸運的是,智能設備和數(shù)字產品的時代帶來了一種復雜的設計思維方法,可以作為物理世界中生產鏈的范例。


用戶體驗必須提供什么


地球上有一個地方,您不能隨便丟東西:互聯(lián)網。這是一個對已有產品進行再構思的地方,您只能去完善它,不能丟棄它,因為如果您一夜之間說:“我不喜歡我的網站,明天我將推出一個全新的網站”,那您便會失去用戶。

如果我們看一下可持續(xù)發(fā)展設計方法的四個主要階段,就會發(fā)現(xiàn)我們在用戶體驗設計中使用的方法與此很相似。

讓我們再次看一下四個階段,然后將其更詳細地分解:

理解

當我們談論與循環(huán)設計相關的理解時,我們談論的是在開始設計一個未來的產品之前就了解它的用戶和環(huán)境。研究一直是數(shù)字產品設計的基礎。與數(shù)字產品的連接比與實體產品的連接要更多的涉及到人類的心理。因此不可避免地要開發(fā)出新的研究方法,以幫助我們洞察用戶在使用某種產品時的想法、感受和行為。但這不僅與用戶有關, 研究還必須深入到經濟領域,并研究未來產品的組成部分,同時牢記它們必須可被再次利用。


定義

在此階段,將定義(商業(yè))目標,并構建一個商業(yè)模型畫布作為生產過程的計劃。用戶體驗使用這種方法已有一段時間了,讓涉眾參與其中,并在設計過程中更多地激活它們。為我們設計的產品設定一個目標是至關重要的,因為有了它,我們可以為用戶創(chuàng)造額外的價值。因此,無論是制作商業(yè)模型畫布還是舉辦精彩的價值主張研討會,在生產方式中實施這些方法都會對當前的生產流程產生巨大的影響。


制造

這是關鍵部分。現(xiàn)在我們正在做的事情就好像沒有明天一樣。隨著每種無法回收的產品的出現(xiàn),我們產生的廢料越來越多。但是循環(huán)方法是為產品創(chuàng)建一個原型,并定義將需要使用那些材料反映在產品原型上,并在定義階段概述的商業(yè)模型上定義材料。原型設計和構思是用戶體驗設計過程中的關鍵要素,這也是為什么需要制作原型。


發(fā)布 

根據(jù)循環(huán)設計模型,隨著產品的發(fā)布,生產周期進入了第四階段,然同時理解階段又重新開始了。對于數(shù)字產品來說,這是自然發(fā)生的事前:你發(fā)布一個產品,基于該版本收集反饋,然后構思它,周而復始,這個循環(huán)再次產生。


但是,觀察這個循環(huán)并建立這些連接僅僅是冰山一角。在數(shù)字時代發(fā)展起來的設計思維給世界帶來了許多反思。


變革中的大佬


幸運的是,已經有許多大品牌意識到轉變的必要性,并采取和提出了數(shù)字設計思維方法來支持轉變,并建立循環(huán)設計的時代。根據(jù)《循環(huán)設計指南》,“我們應該把我們設計的所有東西都看作軟件產品和服務——這些產品和服務可以基于我們通過反饋得到的數(shù)據(jù)而不斷的發(fā)?!?


用戶體驗研究和用戶體驗設計一直是在做的一件事是:基于全面的研究和真實的用戶需求來構建產品。上面的設計指南是非常復雜的工具,具有許多可能的方法。它強調了從產品到服務流程轉變的重要性,并展示如何使用敏捷流程并將其實施到構建產品的方法之中。


IDEO(全球頂尖的設計咨詢公司)與 Ellen Macarthur Foundation(艾倫·麥克阿瑟基金會)合作,試圖“試圖通過設計構建一個具有恢復性和再生性的經濟框架”。在這里,您可以找到幾乎每個生產方面和領域——例如食品、時裝、經濟和設計——并在每個領域中提出解決方案,以打破線性生產系統(tǒng)。


耐克還宣布了其基于循環(huán)設計模型生產高品質運動鞋的新方法原則。正如您已經看到的那樣,無論您身處哪個經濟領域,都可以為循環(huán)生產過程的蓬勃發(fā)展做貢獻,并成為一支主導力量。


重要的結論


我認為,作為設計師,我們始終要為變革而努力,并始終努力與客戶、產品或服務保持緊密的關系,并通過構思使其不斷完善,以實現(xiàn)這一目標。這是因為偉大的事情只有通過時間和不斷的反思才能實現(xiàn)。在離線世界中,數(shù)字設計過程也有很多東西可以貢獻。希望通過教育,能有更多的大公司意識到用戶真正想要的產品是具有更多功能并可持續(xù)使用的,而不僅僅是將它們當作一次性產品,一旦它們不像最初那樣光鮮就把她扔掉。

轉自:站酷-大猴兒er



用戶初次打開軟件,如何給TA 留下好印象?(組件篇)

資深UI設計者


(Onboarding 是指用戶第一次使用產品時認識、熟悉產品的過程)

往期回顧:

對設計系統(tǒng)有所認識的話應該會知道原子設計(Atomic Design)的重要性,我們也能將同樣的概念應用在 onboarding 上,其構成從宏觀到微觀分成體驗流程、控件形式與界面元素三個層級。

體驗流程是一個有時序性的旅程,可以由數(shù)個不同的載具表現(xiàn)組合而成;控件則是承載信息而存在的平面,可以放上不同的元素;而界面元素是無法再行分割的對象。

我在每個階段都舉了幾個常見的例子,搭配市面上產品的應用方法。

體驗流程

1. 分流 Branching

一個產品通常不會只有一種用戶——使用健身 app 可能是為了減肥,也可能是為了增重;使用協(xié)作產品可能是為了記錄工作成果,也可能是為了管理團隊。如果能夠在 onboarding 階段了解用戶的主要意圖、在適量的搜集信息后將用戶分流(記得上篇的避免過度吸收法則嗎?),就能夠打造更切身的體驗。

除了用戶分流之外,還有一些概括性的分流如下:

真正新的使用者 vs. 回流使用者

某些使用者只是因為一些外部因素(手機掉了、手滑刪掉 app、忘記密碼)而重新登錄/下載產品,他們已經接觸過產品的核心價值了,并不需要再次學習,這就是為什么跳過(skip)功能很重要。

邀請人 vs. 受邀人

如果邀請人已經設定好群組,受邀人應該自動被加入,某些信息也該自動填入,而非讓用戶再填一次,從而導致出錯。

新手 vs. 老手

與專業(yè)領域高度相關的產品(例如 Adobe 系列、CAD 系列等)還可以將用戶區(qū)分為已經很熟悉作業(yè)流程的老手與初學者等級的新手。老手最重視的是定制化以符合他們習慣的作業(yè)流程、作業(yè)效率高不高,并且跟其他競品做比較。新手則不然,初次使用產品時的他們也是初次進入這個領域,如果能幫助他們更加了解這個領域的大致流程的話會很加分。

△ Photoshop 的豐富資源指引(Rich Tooltips)對于新手來說是一大神助

2. 展示 Showcase

特別點出幾個重點 features,簡單地告知用戶最重要的功能為何、組件在哪里,用戶在登錄產品之后只要知道這幾個主要動作就可以打遍天下無敵手。

△ Slack 指出 channel 和對話框如何使用

當產品較為復雜,難以指出特定 feature 時,也常以影片或圖片來展現(xiàn)產品價值——也就是畫一張大餅給用戶,讓他們想象未來的生活在用了這個產品后會有多便利,或是讓自我感覺提升。

3. 實際演練 Do to Learn

相對于展示,實際演練更著重用戶要親自執(zhí)行。許多研究都證實從做中學習的成效,就算只是訓練肌肉記憶(muscle memory),也能讓用戶對界面的物理空間更有概念,像是「噢對剛才有做過,我記得按鍵在右上角」。

我們也可以設計一套 demo 版的試用,像是將 scenario 抓一個出來讓用戶試跑,跑過一個假想的故事情節(jié)后印象會更為深刻。

4. 演化成資源庫 Resource

在初次展示后將用戶引導的數(shù)據(jù)回收再利用,變成每當用戶有問題時都隨時可用的資源庫。

載具形式

1. 導覽 Guided Tour

可能是影片,也可能是滑動式 slideshow,但總之是向用戶介紹產品的主要功能或是傳達產品價值,通常是為了展示的體驗流程所設置。

2. 指引 Tooltip / Coachmark

用極小的空間指向目標物,既可以集中用戶注意力,又不會遮蓋住大部分的使用空間,用戶可以一邊進行正規(guī)作業(yè),一邊通過指引了解不懂的內容。

△ Dropbox Paper 用詼諧的語氣鼓勵你開始打字

有一陣子很多產品會將所有指引放在同一張圖上,但其實使用不當很容易造成信息過載、注意力分散、之后會很難全數(shù)記住的情況,我的建議是一次一個比較好。

3. 秀給我看 Show Me

通常只會出現(xiàn)在教程中,強迫用戶一定要親自去按到按鍵或執(zhí)行關鍵動作,切實練習用戶的肌肉記憶。

界面元素

1. 空白狀態(tài)的行動呼吁 Empty State CTA

擅用空白狀態(tài)是 onboarding 重要的一環(huán),畢竟許多產品在用戶動作之前可能都沒有太多料,這時候就要運用行動呼吁。

例如 Tumblr 在指導使用者選擇有興趣的領域之后就指出如何 po 內容,因為其用戶生成平臺(UGC,User-generated content)的本質就是要鼓勵用戶多交流、多產出,平臺才有價值。

2. 進度列 Progress Bar

提供進度可視化,讓用戶有掌控時間的感覺,而不是不知道自己還要再走幾個步驟而感到不耐煩。

Basecamp 將進度列擺在上端,讓使用者知道已經快做完這些設置了

3. 待辦事項 Checklist

人類天生喜歡將事情「全部做完」,欲罷不能:科技如何讓我們上癮?可以協(xié)助我們「引誘」用戶更愿意完成 onboarding 程序。

Bluma Zeigarnik 讓受試者完成某些任務,但在他們完成另一些任務前打斷他們,強迫他們開始進行其他的任務。這些受試者會非常不情愿地停下手上正在做的事,有些人會強烈抗議,有些人甚至會生氣,這顯示出 Zeigarnik 的打斷為他們帶來多么大的壓力。到實驗的最后,受試者清楚記得那些未完成的任務。如果是打斷后一陣子又讓他們完成的話,就沒有這種效應。(摘自 欲罷不能)

4. 跳過 Skip

每次有 onboarding 都會選擇跳過的人舉手!

我喜歡把這稱為不喜歡看桌游規(guī)則的人們,所以在使用中遇到困難時給予提示,對他們來說才是最實用而且最愉悅的,而不是在使用前的紙上談兵。

△ Tumblr 在使用者第一次發(fā)文時才提示如何裝飾文字

設計 onboarding 時并不是只能選擇一種方法,我們可以靈活運用各種元素。將 onboarding 視為一個旅程,而不是單一元素的無限重復。我看過大部分最棒的例子都是綜合使用上述多種元素,以下以新興生產力工具 Coda 為例,來看看集上述大成的 onboarding 作品。

在第一次進入產品使用引導時,可以自行選擇偏好的學習方式——影片或是交互式教學。

Coda 并沒有強制用戶立刻進入 onboarding 模式,而是在呈現(xiàn)主畫面之余,讓我們看到右側的待辦事項,令人產生「想將之完成」的欲望。

點入后,先有個 setup 內容,任務情境是為了項目經理所設計,但隨著使用教程的進行,用戶也能夠聯(lián)想到自己生活中的其他任務,例如安排家庭旅游、寫系列文案、追蹤買家信息等。

正式進入學習階段后,進度條就出現(xiàn)了。

單純根據(jù)文字敘述,用戶仍然可能混淆,這時候 Show Me 功能可以減少不必要的誤解。

同上,當用專有名詞(此處的 section )介紹某個界面元素時,將其他無關緊要的區(qū)域遮蓋住,聚焦在重點區(qū)域,用戶更容易將專有名詞跟界面鏈接在一起。否則單說 section 誰知道是哪一個 section?

結束時記得給辛苦學習的用戶一些獎勵,并且貼心附上下一步,當然還是要留給使用者最終決定權。

完成一項后,Coda 會幫用戶將完成的項目劃除,于是得到立即的回饋。

完成所有步驟之后,原先是教程列的右側區(qū)域轉變成資源列,每當使用上遇到困難時就可以尋求各種協(xié)助。

題外話與小結

Onboarding 并不是只會出現(xiàn)一次,推出多年的產品也仍會時常進行。

onboarding 的程序,例如推出新 feature 或有重新設計(redesign)的時候,目的仍然是讓用戶快速熟悉產品,所以這是身為產品設計師不可忽視的一環(huán)。

另外,除了 UI/UX 設計之外,文案寫作也極其重要——如何跟用戶訴說一個吸引人的故事、描繪出他們想象中的自己,也是成功 onboarding 必要元素。

文章來源:優(yōu)設    作者:

日歷

鏈接

個人資料

藍藍設計的小編 http://sillybuy.com

存檔