<address id="ttjl9"></address>

      <noframes id="ttjl9"><address id="ttjl9"><nobr id="ttjl9"></nobr></address>
      <form id="ttjl9"></form>
        <em id="ttjl9"><span id="ttjl9"></span></em>
        <address id="ttjl9"></address>

          <noframes id="ttjl9"><form id="ttjl9"></form>

          首頁

          文字動效原來這么簡單

          周周


                 文字,是最常見的動效對象之一。我們可以通過對透明度、位置或者角度的改變,制作出豐富的動態效果。但你可能不知道的是,AE內置了超多的文字預設,只需用鼠標點擊幾下,就可以完成復雜絲滑的文字動效。 

          AE文字動效預設使用方法 


                 在AE的窗口中打開“效果和預設”面板,所有和文字有關的效果都在動畫預設中的Text文件夾內,共十七種動效類型

          在AE的窗口中打開“效果和預設”面板,所有和文字有關的效果都在動畫預設中的Text文件夾內,共十七種動效類型。

                 將動效預設拖動到對象上,即可應用動效。

          17種動效預設預覽


                十七種類型分別為:3D文字動效、入場動效、離場動效、模糊動效、曲線動效、表達式動效、填充與描邊動效、圖形動效、亮度與透明度動效、機械化動效、多樣化動效、多行文案動效、擬態化動效、路徑動效、旋轉動效、縮放動效以及字間距動效。

          預設搭配組合


                    有些效果可以相互疊加組合,理論上我們能做出成百上千種不同的效果。 






          文章來源:UI中國       作者:設計師深海



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



          適老化設計怎么做?

          資深UI設計者

          前陣子回老家的時候,在老人家里看到這樣一個機器,這個機器的功能主要為家庭教育、視頻通話與監控等等。


          如果這幾個主要功能入口屏幕占比能更大些、界面中的菜單導航層級能再簡化些...也不至于連我自己想找到一個能跟親人通話的入口都比較困難,更別說老人了。



          當然了,這個機器最后只被家里的老人當成,一個只會定點報時的“擺設”。


          除了把字號放大,適老化設計還需要做什么?以下分享京東直播在適老化設計上的幾點探索。



          強化對比——看清信息


          直到近幾年才知道,家里的長輩喜歡發微信語音,其實是因為老花眼打字不方便。


          在適老化設計中,需要注意界面中的信息與背景的對比度,是否足以讓老年人清楚識別,這涉及到對色域跨度的調整。


          我們通過 H(色相)S(飽和度)B(明度)的數值來劃分色域。如下圖,在統一H值的情況下,規定了10個標準的S、B值,從而形成一個色帶。所以我們在前后景的顏色選擇上,需要滿足跨度至少為5 ,才能讓老齡用戶清晰地識別到前景信息。



          比如在京東直播的老年版界面中,不僅加深了原標準版中的淺灰色文字信息,同時對一些暗文設計也進行了調整,如搜索框暗文“點擊搜索主播名/商品”等內容,提升暗文明度以確保與其背景間的色域跨度大于5。


          所以在適老化設計中,需要讓界面中的信息與其背景間的色域跨度至少為5,才能足以讓老年人看清信息。



          傳達共識——看懂內容


          90前的人想要表示“打電話”,會用手比出6的姿勢貼在耳邊;而現在的00后,會用手掌當作手機的樣子貼在耳邊來表示…


          在讓老年人能夠看清界面中的信息之后,我們的設計還需要有更清晰的表意信息,讓他們能夠看懂。其中的關鍵在于,這些信息是否能夠“傳達共識”。


          無法傳達共識的設計,就像00后的小孩突然擺出用手掌貼在耳邊的姿勢,家里的老人看了可能也無法領會到,這表示的是“打電話”的意思。


          在設計中想要”傳達共識”,需要盡量避免圖形icon的單獨出現,用純文字或圖+文的形式表達。不過除了給圖標加上文字,其實我們在圖標本身的設計上也可以進行適當調整。



          比如同樣表達“話費充值”,是用手機還是座機,哪個更能讓那個年代的長輩理解?哪些事物是那個年代慣用的,哪些事物是在那之后才誕生的?哪些是我們日常生活中就存在的東西,哪些又是專屬于互聯網世界的產物呢?


          所以在適老化設計中,除了幫界面里的所有圖標加上文字以外,在圖標的設計上也可以結合年代、群體環境的因素,讓圖形表現的是老齡年代慣用的、日常生活中固有的內容,讓老年人也能輕松領會到,這表示的是什么。



          聯系認知——找到點擊區


          就算沒使用過手機的人,在生活中看到凸起的事物也會忍不住按一按;但如果他們看到的是一個圓圈,就不太可能有這種反應了。


          在適老化界面中,需要代入更多能夠聯系生活經驗的認知錨點,幫助老年人順利在界面中找到點擊區域。其實不妨回想一下,即使是現在熟練使用手機的我們,也是從當時iOS4的擬物化界面,開始慢慢地培養心智,才能到如今就算看到一個線框、甚至只有純文字,也能輕松分辨出哪里是可點擊的按鈕。


          而當下的老人,也正像當時一開始接觸智能手機的我們,需要在界面中找到與自己生活經驗的對照,才能利用熟悉的事物作為認知錨點,幫助自己理解聯系上一些陌生的概念。


          比如將界面中可點擊的區域強化投影或高光,幫助老人們聯系起生活中對凹凸的認知試著去點一點。除此之外,我們還需要把一些會對點擊認知產生干擾的內容進行弱化。



          比如在標準版的京東直播中,存在像紅包雨、獎券這種運營標簽,其樣式看起來與按鈕很像,但實際為不可點區域,所以在老年版界面中弱化了這些標簽,將他們與所在的列表內容作為一個整體背景,讓視覺重心聚焦在可點擊的按鈕上。


          所以在適老化設計中,除了需要對可點擊區域強化投影以聯系認知,也需要將一些不可點擊的干擾項進行弱化,保證視覺重心最終落在可點擊區域上。



          行為指引——完成點擊


          美國新澤西北部一家電影院做了一個潛意識實驗:在電影中每隔5秒就插入0.03秒的字幕,寫著“吃爆米花”和“喝可樂”,雖然人的肉眼無法捕捉到0.03秒出現的事物但它們可以堆積成潛意識,隨后當天影院的可樂銷量增加15%,而爆米花則增加了58%。


          在適老化設計中,我們還可以運用潛意識作為界面中的隱形向導,幫助老年人順利完成目標行為。


          比如在按鈕的文案中包含行為動作、結果去向的內容,像“點擊領券”中的“點擊”——對當下需要完成的動作描述,“領券”——動作完成后的結果去向,讓每個一眼晃過的引導效果堆積,成為界面中的隱形向導,幫助老年人了解如何完成操作。


          像在京東直播的老年版界面中,也同樣設計了這些隱形向導。比如在列表上加入“點擊進入直播間”的按鈕,引導老年人順利了解到“我當下可以進行點擊”以及“我點擊后可以進入直播間”的信息。



          除了對按鈕文案的調整,我們還可以為一些非明確的可點擊區域加上行為指引。比如在主播力薦中,每個商品圖片都可點擊看對應的主播講解,因此為每個商品加上帶明確行為意圖的點擊按鈕,避免讓人以為這只是一些展示圖而并不知道這其實都是可以點擊的。


          所以在適老化設計中,可以在按鈕文案中加入行為動作、結果去向的內容,同時對一些非明確的可點擊區域加上行為按鈕,發揮潛意識的隱形引導作用,幫助老年人順利地完成目標行為。



          以上僅展示階段性成果,設計方式、設計理念等,我們的探索遠沒有結束,期待下一次分享中與你們的交流。


          文章來源:站酷   作者:SDL藝術實驗室

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



          app,移動端界面賞析,--藍藍設計 UI設計資源分享

          前端達人

          移動互聯網的迅速崛起,讓移動網頁,移動客戶端越來越重要,客戶端的頁面設計也是一門很大的學問。科技迅速發展的今手機屏幕的尺寸越來越放大化,但卻始終 很有限,因此,在APP的界面設計中,精簡是一貫的準則。這里所說的精簡并不是內容上盡可能的少量,而是要注重重點的表達。在視覺上也要遵循用戶的視覺邏 輯,用戶看著順眼了,才會真正的喜歡。


          如果這幾個主要功能入口屏幕占比能更大些、界面中的菜單導航層級能再簡化些...也不至于連我自己想找到一個能跟親人通話的入口都比較困難,更別說老人了。



          接下來為大家分享精美的app UI設計案例:

          藍藍設計(北京蘭亭妙微科技有限公司)是一家專注而深入的UI設計公司,公司對UI設計的追求一向很高,致力于為卓越的國內外企業提供卓越的手機 ui設計、軟件界面設計、網站設計,用戶研究、交互設計等服務。

          jhk-1612348648854.pngjhk-1612348722692.pngjhk-1612348736834.pngjhk-1615795194929.png



          --手機appUI設計--

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


          如何設計好調查問卷?這篇總結全是干貨!

          周周

          調查問卷,是一個低成本快速收集資料的定量分析工具。這是個看起來簡單,產出的問卷也看似很簡單,但是在整體設計的過程卻是需要很多的思考和預備。

          關于調查問卷,會分成三個部分來解說,

          • 第一部分是關于「設計前的準備」
          • 第二部分是關于「如何設計問卷」
          • 第三部分是關于「數據清理和產出問卷報告」

          廢話不說,直接開干!

          著手設計問卷前,先問

          1. 為什么做問卷

          這個是問卷的目的,也直接影響后面問題的設計。

          2. 如何使用問卷的研究結果

          這是關于問卷解決方案的落地。不需要太過細致的落地計劃,但是至少要清楚,這份問卷的研究成果,可以獲得多少支持力度。不管問卷發現了多么偉大的問題,如果沒有落地,其實是沒有無意義。也切忌不要今年做的研究結果,明年來實施,那問卷的時效性和準確性就會大打折扣了,因為市場的瞬息萬變。

          問卷的目的

          這是做所有事前,都要問的問題,「為什么做 Why」。而這個問題為什么重要呢,因為這會關系到設計問卷的核心內容是什么,會影響問卷的構成,當然最后也會產出不同的結果。

          問卷的目的主要可以分為六個方面

          1. 收集用戶信息

          很多時候,我們或許知道理想目標用戶是誰,但是誰才是真正使用我們產品的用戶呢?了解真正使用的用戶,可以對用戶進行更針對性的分析和設計。

          2. 了解用戶使用習慣

          了解用戶在產品上是如何使用產品的,以及用戶的使用路徑是否按著我們期待的方式進行,這是很有必要,這也是一個驗證的過程。

          2. 滿意度

          了解用戶對產品的滿意程度,對于用戶不滿意的方面,可以進行歸納總結,并給出合理的解決方案

          3. 建議反饋、吐槽、好評

          從問卷中收集用戶的心聲,明白槽點是什么。同時也收集用戶的好評,這也是激勵團隊一個很好的方法,因為是直接來自用戶。

          4. 體驗優化

          對一個成功的產品來說,它要好用,它也要好看。產品有大改版前,可以用問卷來評估整體產品的體驗如何,以便在重新設計的方向上能更好聚焦。

          5. 需求驗證

          很多時候,需求可能沒那么明確,用戶和產品間始終存在著 gap, 所以我們有時對方案琢磨不定時,可能會試運行,后續看用戶反饋。通過合理設計問卷,我們也可以稍微窺探到用戶的想法

          但是對需求的驗證,單通過問卷還是比較難的,只能窺探到比較淺的一層,最好后續可以對用戶進行訪談來做后續跟蹤,以便了解事情的全面。

          這里要注意的是,問卷不適合探索用戶的新的需求,或者要驗證很精準的信息等比較復雜性的問題。

          如果你問用戶,近期會推出新功能,問他會不會用。大致上,你得到的回答都是肯定。很多時候,同意比拒絕更簡單。

          問卷問題的分類

          根據提問的方式,可以分為 「是什么」「怎么樣」「怎么辦」

          1. 是什么

          主要是用戶信息、使用習慣等問題。

          例如,年齡層、職業、使用產品目的、知道產品的渠道、使用頻率、使用競品軟件、整體滿意度等

          2. 怎么樣

          主要是詢問用戶原因,比如打這個分數的原因,某功能使用如何等

          3. 怎么辦

          主要是詢問用戶的建議、期待產品改進的地方

          設計問題需注意幾點

          問卷中并不是所有問題都適合問,有一些比較敏感的問題需要去避免,以免激起用戶的負面情緒

          1. 敏感性問題

          個人信息類的問題比較容易會有敏感信息存在,就像你問用戶工資區間,和在問卷最后告知用戶參與問卷都有獎品,需要填寫收貨地址。很明顯收貨地址的準確性會比工資更高。

          2. 措辭嚴謹

          • 無錯別字,文明用詞
          • 用詞不產生歧義,準確表達;比如平時,比較多、近期,每個人對此理解是不同的,要提供明確的時間節點
          • 一個問題,就只問一件事
          • 盡量用陳述語句,不使用反問句、疑問句、否定句,用戶可能無法準確明白,特別是否定句,用戶有可能看成肯定句。
          • 避免用語過于口語話,不中英文夾雜,除非名詞已完全普遍。根據目標群體的不同,會有差異性。比如 iOS 系統,不一定所有人都知道,這指的是蘋果的手機系統。
          • 標準用詞,盡可能或不使用縮寫,比如 h,hr, 直接寫小時,會更好。

          3. 問卷的順序

          先簡單后復雜,并注意整體邏輯性的表達。循序漸進,如果一開頭就是很難的問題,用戶很容易放棄答題

          4. 問題長度

          盡量保持所有問題在一個差不多的長度呢,保持一樣的節奏。避免時長時短

          5. 避免專業詞匯

          很多時候,我們會用一些所謂的“行話”來表達,但是在問卷當中,無法保證用戶同樣是理解的,而且也會讓用戶產生距離感,非必要情況下,不要使用專業詞匯

          6. 選擇題枚舉要窮盡

          題目數最好不多于 7 個,太多也會造成用戶選擇困難,最后記得加個其他并提供文本框輸入

          7. 避免互斥、重復、相似

          問題避免前后矛盾,造成用戶困擾,也不要重復或相似度極高的問題,除非這個問題是陷阱題,為了檢驗用戶是否認真答題。但是在數量有限的問題中,一般比較少使用陷阱題

          8. 保持開放性

          為所有選擇的選項,加入「其他——」「以上都不是」「不知道」,用戶可能會覺得問題或答案不匹配,而不知道選什么,這時需要給用戶一個出口,避免產生無效數據

          9. 避免詢問引導性的問題

          大部分用戶認為 XX 功能,很好用,你覺得呢?

          如果看到這樣問題,大概可以從中讀出兩個信息,1. 大家都覺得好用 2. 平臺希望我說好用。

          這個問題所傳達出來的隱藏含義會引導用戶做出不真實的反饋,這是沒有意義的問題

          10. 避免讓用戶選擇「 是/否」「真/假」「好/壞」

          強制選擇非黑即白,大部分情況下沒什么意思,因為用戶可能不確定。這個問題本身也沒有太大價值,也會錯過用戶一些比較有趣的回答。

          所以如果這個問題的目的,是一定要知道的,可以更改提問的方式。

          如何設計好調查問卷?這篇總結全是干貨!

          對于用戶的問題,答案要可以量化表達,來產生數據,才便于后續數據的分析

          11. 避免問用戶將來的事,或回憶許久前的事

          當人們將自己的行為投射到未來時,通常會過于簡單化和理想化,人們更擅于解釋當下進行的內容。

          所以,如果要知道特定環境下用戶的操作,則要配合合適的場景預設,并且是用戶熟悉的場景。或者可以直接問,今天你會如何如何

          如何設計好調查問卷?這篇總結全是干貨!

          所以可以通過詢問今天的行為來,確定將來會不會使用。當然這不是絕對的,畢竟未來存在太多變數。

          對于許久前的用戶的操作行為,也盡量不詢問,因為會忘記,而當強迫他去思考時,他可能自己腦補,產生不準確的記憶,進而對研究結果產生偏差。

          12. 其他

          問卷中存在多選題,必選題,選填題,記得預覽問卷時,注意問題平臺有無自動添加文字說明。

          不要用 checkbox, radio 來區別多選和單選,這是不能準確的傳達,也有可能用戶沒有注意到,或者就不清楚,而使用文字的表述會更清晰,不會產生歧義。

          必選題,選填題,如果問卷平臺,也只是用*號來表達必選時,建議在文字上也加上這樣的說明

          設定日程安排

          整體問卷的過程需要時間,所以也需要的具體的日程安排,以便整體問卷的進行是井然有序。

          日程安排中,要包括:

          • 確定問卷的目標人群、確定問卷目的
          • 問卷設計時間
          • 問卷評審時間
          • 問卷內測時間
          • 問卷投放時間、時間長度
          • 產出問卷報告

          如何設計好調查問卷?這篇總結全是干貨!

          最后的話

          調查問卷從準備到產出報告,需要一個過程,建議與其他設計師或 PD 來一起配搭工作,更高效的完成,一個人去做,總是會有一些盲點,并且會比較大的壓力。

          如果你在問卷方面是新手,也建議找個有經驗的設計師或 PD 來做你顧問,減少一些不必要的坑。


          文章來源:優設網       作者:箴鹽設計



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


          JS學習筆記

          前端達人

          JS學習筆記

          js和java的異同點

          變量聲明

          函數聲明

          js中的變量提升和函數提升

          為什么有變量提升

          總結

          js和java的異同點

          首先,js的語法和kottlin的語法有些相似。比如var,方法聲明用



            function 方法名稱 (參數名稱...){

            //方法內部邏輯

            }



          還有變量類型聲明 :



          數據類型 : 變量名=值



          區別:一:js的數據類型和java類似。只不過js中的數據類型number將java中的int,double,float整合了。

          二:js中可以不用聲明變量類型。變量不聲明數據類型的話,那么他的類型取決于當前的值是什么數據類型。舉例:



          var num=0;

          num-"lyyyyyyyyyyyyyy";

          num=[];

          num={};



          三:js中的類型判斷:



          判斷基本類型,返回一個字符串

          1

          console.log(typeof '');//string

          console.log(typeof []);//object

          console.log(typeof {});//object

          console.log(typeof 1);//number

          console.log(typeof null);//object

          console.log(typeof undefined);//undefined

          console.log(typeof true);//boolean

          console.log(typeof function(){});//function

          console.log(typeof /\d/);//object





          檢查某個對象屬于哪個構造函數,返回true/false

          1

          function A(){};

          function B(){};

          let a = new A();

          console.log(a instanceof A);

          console.log(a instanceof B);

          console.log([] instanceof Array);//true

          console.log({} instanceof Object);//true

          console.log(/\d/ instanceof RegExp);//true

          console.log(function(){} instanceof Object);//true

          console.log(function(){} instanceof Function);//true





          變量聲明

          js的變量聲明其實大體上可以分為三種:var聲明、let與const聲明和函數聲明。



          函數聲明

          doSomething();

           

          function doSomething() {

              console.log('doSomething');

          }

          var foodoSomething= 2;



          你覺得上面會輸出什么?TypeError嗎?其實輸出的結果是foo。這就引出了我們的問題了,當函數聲明與其他聲明一起出現的時候,是以誰為準呢?答案就是,函數聲明高于一切,畢竟函數是js的第一公民。



          那么,下面的例子呢?



          doSomething();

           

          function doSomething() {

              console.log('1');

          }

           

          function doSomething() {

              console.log('2');

          }



          當出現多個函數聲明,那怎么辦呢?以上代碼輸出結果為2。

          因為有多個函數聲明的時候,是由最后面的函數聲明來替代前面的。



          domeSomething();

           

          var domeSomething= function() {

              console.log('domeSomething');

          }



          var domeSomething = function() {}這種格式我們叫做函數表達式。



          它其實也是分為兩部分,一部分是var foo,而一部分是foo = function() {},參照例2,我們可以知道,這道題的結果應該是報了TypeError(因為foo聲明但未賦值,因此foo是undefined)。



          js中的變量提升和函數提升

          在js中對變量進行操作后打印值經常會出現undefined的現象。其實原因是因為js中有一個叫做變量提升的功能。舉例:

          1

          var data="lyyyyy";

          getData();

          function getData(){

          //第一次打印

          console.log("data值為: ", data);

          var data="yyyyyyy";

          //第二次打印

          console.log("data值為: ", data);

          }



          打印的值第一個為undefined,而第二個打印的值為yyyyy.



          原因:

          在執行getData()方法的時候會在函數內部首先將變量的聲明提升到第一步。

          然后再聲明函數內部的函數(如果函數內部有函數的話)。

          之后才會按照方法內部的邏輯先后順序執行代碼。前兩步只是聲明?。?!

          看到這里應該就已經知道為什么會有上面那樣的結果了。



          實際的方法內部代碼執行順序應該是這樣的:



          function getData(){

          //一。聲明變量

          var data;

          //二。聲明函數(如果函數內部有函數的話)



          //三。按照代碼的順序執行

          console.log("data值為: ", data);

          data="yyyyyyy";

          //第二次打印

          console.log("data值為: ", data);

          }



          看到拆分后的代碼執行順序對結果也就不迷茫了。



          為什么有變量提升

          那么為什么會出現變量提升這個現象呢?



          其實js和其他語言一樣,都要經歷編譯和執行階段。而js在編譯階段的時候,會搜集所有的變量聲明并且提前聲明變量,而其他的語句都不會改變他們的順序,因此,在編譯階段的時候,第一步就已經執行了,而第二步則是在執行階段執行到該語句的時候才執行。



          總結

          1.js會將變量的聲明提升到js頂部執行,因此對于這種語句:var a = 2;其實上js會將其分為var a;和a = 2;兩部分,并且將var a這一步提升到頂部執行。



          2.變量提升的本質其實是由于js引擎在編譯的時候,就將所有的變量聲明了,因此在執行的時候,所有的變量都已經完成聲明。

          3.當有多個同名變量聲明的時候,函數聲明會覆蓋其他的聲明。如果有多個函數聲明,則是由最后的一個函數聲明覆蓋之前所有的聲明。


          ————————————————
          版權聲明:本文為CSDN博主的原創文章,遵循CC 4.0 BY-SA版權協議,轉載請附上原文出處鏈接及本聲明。


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


          服務設計概述及國內外案例分析

          ui設計分享達人

          5分鐘帶你了解服務設計的原則、案例及常用方法!




          我們常說,現在是體驗至上的時代,用戶對產品的使用不再是單純的需求滿足,更要獲得滿意的體驗。服務設計的發展為我們改善用戶的體驗提供了新的思路,從本質出發,任何產品都是在提供某種服務,服務的質量從根本上決定了用戶的體驗。



          什么是服務設計


          服務設計一直在我們的生活中,我們無時無刻不在體驗著各式各樣的服務。荷蘭一家專業的服務設計機構31 Volts是這樣描述服務設計的:“如果有兩家緊挨著的咖啡店,出售同樣價格的咖啡時,服務設計是讓你走進其中一家而不是另一家的原因。”這個描述很生動,同時也說明了服務設計的作用。


          其實服務設計的定義還有很多,行業內不同的專家和學者都有自己的理解和解讀,不管定義如何,重要的是服務設計的思維方式,可以幫助我們從全局改善服務體驗。




          服務設計的原則及案例說明


          2010年在《This is Service Design Thinking》一書中,作者首次提出了5個服務設計基本原則,這些原則之后也被廣泛使用,但隨著服務設計的不斷發展,其中的一些原則也需要重新去審視和思考,因此在2017年作者將其更新修訂為6項。


          a.以人為中心(Human-centered)


          以人為中心的設計理念在產品設計、交互設計等領域已經得到了廣泛的應用,服務設計當然也沒有例外,以人為中心就是要站在用戶的角度上看待和思考問題,考慮所有被服務影響的人。


          在日本,農產品市場存在這樣一個問題,農產品批發商無法及時從種植者處了解農產品的相關狀況、收獲量等信息,因此他們也就無法與要購買農產品的人進行談判,這樣造成的結果可能是糧食的浪費。日本的一家軟件公司NJC(Nippon Jimuki Co. Ltd.)發現了這一問題,他們希望利用自身能力(軟件方面的優勢)去解決這一問題,因此將目標設定為:創建一個可以提供有用數據而又不給農民或農產品批發商帶來負擔的系統。


          最終的產出的結果是Fudoloop這個應用程序,通過Fudoloop,批發商可以提前一天從農民那里收到信息,進而協調買家的各種要求。Fudoloop的使用者分為兩種,一種是需要更新農產品信息的農民,一種是從Fudoloop上獲取農產品信息的批發商,Fudoloop分別為兩種用戶進行了設計。

          圖片來源:Fudoloop



          在設計Fudoloop時存在這樣一個問題,農產品市場中的相關從業人員普遍年齡較大、受教育程度低、軟件使用經驗很少,面對這樣的用戶,顯然通常的軟件設計并不符合他們的需求,因此Fudoloop的界面設計非常簡單且信息突出,從事農產品相關工作的人員可以輕松的使用Fudoloop完成農產品信息的更新,而不會因為學習產生很大的壓力。Fudoloop還在大型農業貿易展覽會邀請了一些行業內的人員和用戶參與到了產品的體驗中,并收集了他們反饋的建議,以改善產品。

          圖片來源:IDEO


          NJC在設計Fudoloop時充分堅持了以人為中心的原則,考慮到服務涉及的不同用戶,并根據用戶本身的特點和需求進行設計。NJC的CMO佐藤賢一是這樣評價Fudoloop的:“當簡單、以人為本的思想匯聚在一起時,創新就會發生”。



          b.協作(Collaborative)


          這條原則說的是,不同背景和職能的利益相關者應該參與到服務設計流程中,收集多方訴求,發現不同看待問題的角度,才會更好的解決問題。


          在美國舊金山,有一所學校和Revolution Foods這家餐飲公司合作,為學校內的人員提供豐富的、營養的午餐,但是實際來餐廳就餐的人數與預期相差很大,數據顯示,有72%可以承擔起午餐費用的人并沒有來到食堂吃午餐。經過調查發現其中的原因,很多學生等校內人員并不愿意排長隊或者匆忙的吃完午餐,因此他們選擇了去校外享受午餐的時間。


          為了改善這種情況,這所學校請來了全球頂尖的設計咨詢公司IDEO,他們與1300多名學生、父母、營養人員、董事會專員、校長、老師和社區團體等利益相關者一起工作,重新去設計了學校的午餐,并且制定了針對三種年齡的就餐體驗的建議,完成了飲食、就餐空間、新技術使用等多方面的優化和設計。

          圖片來源:IDEO


          最終,學校完美的改善了午餐服務的體驗,這其中包含了所有利益相關者的想法和工作,因此設計成果也被人們所接受,越來越多的校內人員會選擇學校的午餐,之后,這種設計模式也被舊金山的許多學校采納和推出。


          所以,服務中涉及到的利益相關者有很多,多收集他們的想法與建議,甚至讓他們參與到服務設計中去,問題會得到更好的解決。


          c.迭代(Iterative)


          迭代是一個不斷接受反饋不斷優化的過程,如此重復執行,讓產品變得越來越好。服務設計也需要迭代,不要避免犯錯誤,而是從錯誤中學習和改變,同時也要不斷的收集各方的反饋信息,這些信息是服務進行迭代的核心所在。隨著互聯網的發展,迭代的思維早已滲透到每一個互聯網產品,此處就不再過多解釋。


          d.有序(Sequential)


          服務設計應該是一系列相互關聯的活動,并且是按照順序進行的,精準的把控服務每一個環節的節奏,用戶才能獲得更愉悅的體驗。


          以外賣為例,用戶的使用過程包含訂外賣時的商家選擇到下單過程,下單后配送外賣,用戶收到外賣和用餐后這幾個過程,而服務的提供者主要包括商家、平臺和外賣小哥,為了保證用戶能夠獲得流暢的服務體驗,需要各個服務提供者在服務展開的不同環節推出優質的服務,如下圖。


          在訂外賣時,平臺會為用戶推出“超值優惠”“限時秒殺”等優惠活動,商家推薦、訂單歷史等商家選擇渠道,以及不同的篩選條件,以上的目的都在于幫助用戶快速找到自己期望的、合適的商家。在用戶選定商家后,進入到選擇商品并下單的過程,一方面,商家會推出優惠的活動、推薦菜品等,另一方面,平臺也會給出自己的優惠。


          下單后,用戶面臨的是一個配送過程中的等待時間,為了緩解用戶在等待過程中的焦慮情緒,平臺會及時更新和推送外賣小哥的狀態,如到達商家、取餐中、與用戶的距離等,同時會給出用戶預期的送達時間,若超過預期時間用戶還可進行催單,商家可以聯系用戶表達歉意,整個過程用戶對配送狀態是可視的。


          用戶收到外賣時首先會與外賣小哥接觸,包括與外賣小哥提前確定取餐的時間地點,取外賣時的短暫對話等,這些都會影響用戶對服務的印象,因此外賣小哥需要保證服務態度的禮貌和友好。收到外賣后,食品包裝首先給到了用戶對商家的第一印象,然后是餐品是否符合用戶預期,讓用戶滿意。


          在用戶就餐后,首先平臺要提供給用戶評價的功能,用戶可以分享自己就餐的感受,商家也可以通過平臺為用戶提供更多的優惠,引導用戶能夠再次回到商家訂餐。


          從外賣的案例中我們可以看到,服務是一個過程,是需要有序展開的,每一個環節的體驗都會影響到用戶對服務的印象,在恰當的環節提供恰當的優質服務,才能確保用戶的整體體驗。


          e.真實(Real)


          服務本質上是無形的,應該用“物理元素”來可視化,這樣可以用戶的服務記憶,增強用戶對他們所接受服務的感知。


          同樣以上述外賣為例,商家為用戶提供餐食,這部分是借助美團這個平臺和外賣小哥來完成的,用戶和商家的接觸僅僅是送達的餐食,因此無法通過像到店體驗一樣,讓用戶感知到商家提供的更多服務。


          為了讓服務變得更加“有形化”,商家就需要花費更多的心思,如圖,商家為了增強用戶對服務的感知,一般會在在包裝上花費很多功夫,精致的包裝讓商家的形象更好且更加值得信任,一些有趣的包裝還可能讓用戶的心情變得愉悅。另外,商家也可以通過一張便利貼的溫馨問候或者贈送小禮品等方式讓用戶更真實的感受到服務,通過這樣的手段,即使用戶并沒有真的接觸到商家,體驗也會變得很好,商家的形象也會提升很多。

          圖片來源:古田路9號


          f.整體(Holistic)


          整體就是要著眼于整個用戶旅程,考慮用戶與服務的每個觸點(觸點的概念后文會進行介紹),并兼顧多方利益相關者的需求。也就是所謂的全方位服務體驗,考慮服務環境的方方面面,沒有任何遺漏。這個原則實施起來并不是那么簡單,從整體角度思考問題會使問題變得復雜。不過在服務設計中,是有一些方法和工具是可以幫助我們完成整體思考的,比如服務藍圖。




          服務設計的常用方法-服務藍圖


          a.服務藍圖簡介


          服務藍圖是一張圖表,通過列出在每個階段發生的、不同角色執行的所有活動,顯示了服務的整個過程。如圖所示是一個服務藍圖的簡單示例,垂直方向上展示服務中的利益相關者,水平方向上為用戶的歷程,也就是用戶經歷的不同階段。在服務藍圖中有兩條線,一條是可見線(line of visibility),可見線上方為用戶可與之交互的服務,也可以稱之為“前臺”,可見線下方代表的是后臺進程,用戶無法看到但需要給用戶提供支持,后臺進程還可以存在內部交互線,用來表示內部人員的聯系。用戶與前臺服務之間存在另外一條交互線(line of interaction),用來表示用戶與服務之間的接觸。

          圖片來源:Service Design Tools


          明確了服務藍圖的大致框架之后,還需要注意服務藍圖中一個非常重要的概念——觸點。觸點就是在服務的各階段,用戶和產品、服務、后臺產生的接觸,每個觸點也是服務可以進行展開和優化的方向。


          b.Uber服務藍圖繪制


          為了明確服務藍圖的繪制和分析過程,下面將結合下圖所示的Uber服務藍圖進行說明。

          圖片來源:Medium


          (1) 明確用戶歷程


          用戶使用Uber打車服務主要可以簡單分為以下三個階段:注冊(下載APP - 新用戶注冊),乘車階段(下單 - 等待車輛到達 - 乘車 - 到達目的地)、乘車后(付款 - 評價)。


          (2) 明確利益相關者


          用戶與之產生互動的前臺服務人員為司機,而設計師、開發人員、項目經理等負責后臺的服務支持,以保證Uber按照預期的目標運作。


          (3) 明確前后臺活動


          一方面,需要明確和用戶接觸的前臺活動有哪些,Uber打車服務中和用戶產生接觸的主要為司機及車輛,因此需要確保司機是合格的、車輛內部的環境是干凈舒適的,同時司機在與用戶接觸的過程中需要提供禮貌的問候和交流,滿足用戶在乘車過程中的要求,完成乘車費用的收取,提醒用戶離開前帶好隨身物品,以及評價乘客等。


          另一方面,用戶對后臺的流程可能并不了解,但需要明確哪些后臺活動和支持會對用戶產生影響。比如在用戶下單時能夠自動獲取用戶定位,告知用戶預期的時間和價格,以及發送給用戶司機的狀態等。


          在明確前后臺活動時,我們可以以用戶歷程為線,分步驟進行分析,確保每個環節中涉及到的前后臺活動沒有被遺漏。


          (4)明確關鍵觸點


          在服務藍圖中我們可以標注用戶與服務的主要接觸點,針對觸點進行設計是提升服務體驗的一個重要和有效的手段。


          在Uber打車服務中還有一些需要注意的觸點,一是等待時間,這包括用戶發起乘車請求后、付款時以及評價司機時,等待時間是造成用戶體驗較差的一個原因,因此需要注意標注出這些觸點,并想辦法優化,在服務設計中需要注意相關環節的應盡量簡單,減少用戶的等待。另外需要注意的是會對體驗影響較大的觸點,如司機態度不友好、乘客下車時忘記帶隨身物品等,可能造成失敗的服務體驗的觸點應該精心地去設計,避免這樣的情況發生。


          通過以上過程我們完成了Uber服務藍圖的繪制,從中可以獲取到Uber打車服務的整體概貌及其相互關系。



          ///


          結語


          服務設計的思維能夠幫助我們從全局的角度去審視和思考,發現更多改善服務的可能性,從而為用戶提供更好的體驗。因此對于產品和設計等相關人員來說,不能僅僅把目光放在產品本身,而是要從服務的角度去正確看待產品和用戶的關系,以用戶為中心,找到用戶與產品的每一個接觸點來進行服務設計,這樣才能保證用戶在整個流程中都能得到好的體驗。



          文章來源:站酷   作者:百度MEUX

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




          如何建立價值思維?

          資深UI設計者

          用戶體驗設計就像是一場直面自我的修行,無論是從認知提升、工作能力等維度,都在時間和實踐中不斷去促進自我對事物的探索,在過程中不斷獲取對世界的感知和成就感。在學校里所接觸的關于交互設計的認知,大部分局限于產品領域與基礎交互,而后逐漸過渡到交互體驗與設計的結合并且作用于商業,成長過程中也會不斷思考,這次想聊聊設計價值,大概分為三點:價值思維、價值判斷、價值體現。

          建立價值思維

          我的設計能夠給用戶/產品產生什么價值?如何體現設計的價值?可能很多朋友也會和我一樣有這樣的疑惑,假如能夠在接觸需求后便思考該需求背后的價值,那對應的行動也會有很大差異性。

          1. 設計的困境

          可能對于大部分的設計師而言,作為主要的執行力,需要肩負起項目的責任,所以會把大部分時間都投身在項目需求和日常溝通來提升自身能力,很少有剩余時間去沉淀已做完的設計,只有在產品體驗會或者其他渠道的反饋中獲取最后的問題,久而久之就像是打補丁,既無法體現設計價值,自身能力也無法得到完整的提高。然而促使設計師進步的往往不是技能的熟練,而是對業務需求思考的廣度和深度。因此需要樹立起價值的概念,價值可以驅使行動產生改變。

          2. 價值驅使行動

          價值觀因人而異,而價值觀會影響一個人的行為引導其做出選擇,對價值的思考取決于思維上升空間有多大。因此需要有一個思維模型能夠幫助我們更好的建立起價值思維,可以幫到我們更加有邏輯的思考。相信許多朋友都聽過「Why-How-What」即黃金圈法則,個人認為可以從日常需求中幫助設計師建立起一套價值思維。黃金圈解析:

          • Why:為什么做一件事,基于什么樣的目標
          • How:怎么做,是實現目標的途徑
          • What:具體的行為

          設計師進階知識點:如何建立價值思維?

          △ 圖片來自網上

          3. 黃金圈法則實踐

          了解黃金法則后,我們看看如何把黃金圈的思維模型運用到工作中。

          假設我們接到一個「商城系統」的設計需求,可以嘗試這樣拆分:

          WHY:我為什么做

          • 商城是產品重要的盈利渠道,能夠為產品帶來核心收益
          • 設計賦能商業化,是設計的價值體現
          • 能夠幫助設計師更好理解產品的商業化結構

          關注點:站在產品角度,對產品真正的幫助和提升

          HOW:我要怎么做:

          • 梳理玩家的購物場景和細分需求
          • 整理同類競品的優缺點,挖掘機遇點
          • 明確設計目標,突出商品展示特點

          關注點:需求做的更好,超出玩家預期

          WHAT:需要做什么

          • 高效便捷的購買流程
          • 兼顧玩家的情感訴求(炫耀、儀式感)等細分場景設計

          關注點:讓玩家使用更加高效,滿足多種場景

          綜上所述,設計師處于不同的階段,所關注的價值層面對應的行動也會不同,不僅要求設計師在需求之外還需要全局思維的思考延伸,了解當前產品階段最需要的是什么,更多需要設計師自我審視,建立價值思維的思考模型,不僅僅停留在行動層的思考。

          (我為什么要做)價值觀——(我要怎么做)能力——(我要做什么)行動

          形成價值判斷

          「黃金圈」法則可以幫助我們建立起價值思維,然而每個設計師有各自的價值衡量,以下是我認為的一些價值維度:

          1. 層次與目標

          日常我們總會接受到大大小小的需求,簡單和復雜會摻雜混合,從工作角度而言需求是都要做的,但是從設計價值的角度而言,需求是有輕重緩急之分。那如何進行價值判斷呢,一般的設計需求從目標上可分為三個層次:

          • 基礎目標:滿足「可用性」
          • 體驗目標:滿足「易用性」
          • 驚喜目標:滿足前兩者基礎,讓用戶感受「愉悅感」并且超出預期

          設計師進階知識點:如何建立價值思維?

          2. 二八法則分配

          當有了一個基礎劃分后,就可以對需求進行合理評估,考慮到現實情況下通常會面臨這些情況:

          時間緊迫:日常需要大量的時間進行協作溝通和跟進

          精力有限:任務重加班多,無法長時間保持高效的工作狀態

          所以可嘗試根據二八法則對時間精力進行分配,對于一些價值較低的需求,可以和需求方充分溝通,過濾無效信息后快速處理;對于價值較高的需求,投入大量時間與精力設計與打磨。對于初中級的設計師來說,滿足「可用性」和「易用性」是仍需要多加錘煉的基礎能力,對于高級以上的設計師來說,有了一定的經驗下達成前兩者較為容易,可以把更多的時間精力投入在「愉悅感」的設計上。

          體現設計價值

          前面講了價值與判斷,但設計無論是賦能或者是驅動,還是需要明確最終目標是什么,我的理解是最終服務于產品解決問題。那如何體現設計價值就顯得尤為重要,以下簡單拋出兩點:

          1. 提升體驗和口碑

          雖然不能直接為產品帶來實際收益,但是帶來體驗提升,而口碑的增長相當于為長線運營打下基礎,也為后續進入的產品矩陣留下增長空間,例如最近大火的《天地劫》,相信后續的出品也會讓玩家更加期待。

          像這類的例子有許多,例如《王者榮耀》的公眾號還有專門的 UI 迭代日記,即便是運營多年的產品仍然在不斷的打磨和提升體驗,為產品帶來正面影響。

          設計師進階知識點:如何建立價值思維?

          △ 圖片來自王者榮耀公眾號

          2. 帶來商業利潤,促進社交、消費增長

          這類體現通常是商業化/社交相關,《陰陽師》眾所周知的抽卡系統和「畫符咒」的交互方式也帶來了大量的社交互動和用戶增長,還有《Pokémon GO》捕捉寶可夢和「投擲精靈球」,促進了玩家大量的線下的互動場景,我認為這些都是設計價值的體現。

          設計師進階知識點:如何建立價值思維?

          這些設計相對于大部分玩家是一種「隱形」的存在,不像角色、場景設計等容易被感知,對于設計的價值體現一定不只是給產品錦上添花,是能夠通過對用戶/玩家群體的理解去塑造和滿足需求。

          文章來源:優設   作者:阿澤與設計

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

          流量分發與產品設計

          ui設計分享達人

          先看目錄!


          • 1.什么是流量分發

          • 2.為什么要做流量分發

          • 3.首頁中流量分發的類型

          • 4.流量轉化模型

          • 5.流量如何分配的

          • 6.設計案例與流量分發

          • 7.如何衡量流量的效果



          1.什么是流量分發


          相信大家對流量并不陌生,我們在運營的口中經常會聽到這個詞:流量。運營通過各種手段和策略吸引用戶來接觸、使用我們的產品,從而吸引到了許多的流量,流量越多機會也就越多,比如一家奶茶店門店選址要考慮的最關鍵因素就是人流量。


          流量分發的本質其實就是用戶需求分發,我們設計師的價值就在于如何讓這些流量發揮出更大的價值,讓流量價值和用戶價值相匹配。流量就像是一片海,海水通過不同的分支流入大陸形成了江、河,如果沒有這些分支,那么這些水永遠無法被利用,發揮出它們的價值。流量分發我們最常見的方式有:搜索分發、算法分發、社交分發、人工分發、付費分發



          undefined




          舉一個比較典型的例子:海底撈在進行流量轉化之前,并不是單純的在店門口給用戶一排座位讓用戶去等待,因為這部分用戶就像沒有被分流的海水是死的,這時候的用戶其實也有自己的目標,就是消磨時間,那么海底撈就提供了一系列服務讓這部分用戶活動起來,比如給零食、玩具、做指甲等等,于是這部分用戶其實就相當于進入了就餐流程的分支,提前享受服務和餐廳提供的福利,除了提升用戶體驗以外,也消化了大部分的流量。試想一下如果一下來了許多客戶,但你只有十幾張椅子讓用戶等待,勢必造成更多的損失。


          流量是無序混亂的,只有到它應該去的地方,它才會有價值。產品與用戶雙方都需要有清晰的目標,產品提供解決方案和導流不同的場景,用戶負責完成目標給業務帶來價值。



          2.為什么做流量分發


          2.1.減少成本


          流量分發最典型的就是電商產品,因為業務目標非常明確,就是實現gmv的提升,但同時其用戶的需求場景也是相對來說很復雜的。那么一個好的流量分發策略,可以大大的減少用戶完成目標的時間和精力,也讓產品可以準確的掌握用戶的需求流向。





          2.2.價值最大化


          流量不分發或者錯誤分發就會造成更多的消耗,什么意思呢?我們舉個例子,譬如下方的??觓pp首頁,首頁中雖然提供了搜索、分類和標簽欄不同模塊,但是核心的內容顯示區域則只有一張預售產品的大圖。我們知道用戶類型非常多,這樣的布局對于小白和第一次用此款產品的小白來說會十分迷茫,因為最顯眼的內容中并沒有他們想要獲取的信息。我們不求滿足所有用戶,但至少需要覆蓋大部分用戶和核心用戶,此外,這樣的形式就像一個漏斗,只靠一個出口漏水,效率自然不高。





          同時為了達到最大化,流量的分發并不是單向的,而是并行、串聯的。比如你可以在通過搜索找到某件商品,參與活動、運營板塊、商品分類、網紅直播等等區域都可以發現這個商品,同理,你想要購買視頻app的會員,不僅僅可以去個人中心,你還可以去詳情。所以流量就像一個大網格,單純的給漏斗戳幾個洞還不夠,甚至要把這些洞用很多根管子串起來。



          2.3.滿足業務需求


          流量分發可以幫助盤活新業務以及尋找新的價值,例如我們之前的電商產品在前期是以時間軸為核心的消化方式,商品以單品列表平鋪的形式展示,在產品發展過程中形態會發生變化,單純以這樣的形態承載用戶需求肯定是不夠的,所以更多運營板塊和推薦可以分擔這部分“舊”流量。



          3.首頁常見的分發類型


          我們在移動端的首頁可以??匆姷念愋陀校核阉?、宮格型板塊、信息流、banner、fab等。


          3.1.搜索


          搜索給有明確需求的用戶提供了入口,同時在搜索這個顯性場景中我們也可以細化出更多的場景給流量提供更有效的支持


          例如搜索場景下除了熱門搜索、搜素歷史以外還可以提供不同的分類內容推薦。






          3.2.Banner


          逐漸走下神壇的banner,曾經可是在UI界叱咤風云,在當時由于他是首頁占比一哥,很多產品在首頁規劃中都認為banner會承載大部分的流量,尤其是像淘寶等電商產品,banner不僅僅可以靠圖片吸引用戶,在做一些大促活動時候還可以變成氛圍擔當,和導航欄上下呼應。我們說首頁是寸土寸金的,但是大家發現沒有,banner的流量和他本身的價值可能不相匹配。也就是說雖然他面積很大,但是用戶點擊率相比于其他板塊并沒有什么優勢,甚至還低。所以淘寶目前的首頁已經看不到banner了,這個區域可以放下更多的運營區塊和流量入口,當需要它的時候再配置起來就可以了。



          undefined



          3.3.宮格板塊


          這個板塊除了業務分類的“金剛區”以外還有運營活動的配置區域,我們先來說以業務劃來劃分的流量入口,以這樣的形式來分配流量是常規的手段,當然他也是有利弊的,有利的地方在于幾乎每個業務板塊雨露均沾,至少是在同一屏幕中呈現,還可以左右滑動切換更多。弊端的話就是層級深,并且用戶瀏覽效率低不聚焦,對于那些泛瀏覽型的用戶并不友好,因為你進入一個業務板塊后發現內容自己 不感興趣需要就需要再返回。所以這樣的分流更適合深度使用產品的用戶





          那有沒有另外一種形式可以分配流量給不同業務板塊呢?當然是有的,比如tab標簽,有了tab標簽,泛瀏覽的型的用戶會更喜歡,他們能更快的找到自己喜歡的內容,比如bilibili、騰訊視頻的首頁,這個當然也和產品目標有關,他們希望讓用戶看到更多的內容,讓產品更扁平化。


          那么你即想扁平又想讓用戶直觀的看到業務板塊分類怎么辦呢,你可以這么做,就像大眾點評一樣上邊是宮格,下面是tab標簽



          3.4.fab懸浮按鈕/掛件


          Fab和cta可以說是比較另類的存在了,幾乎就是你想讓用戶去點,那你就放,所以這樣的入口流量路徑就比較單一,無法沉淀和升級流量,是短期目標的形態。fab的這樣的懸浮入口會一直在首頁顯示,通常產品為了吸引用戶會將其設計的比較吸引人,比如添加動效等,但是fab也會干擾用戶正常瀏覽界面,所以一般可以用透明、伸縮的方式解決,不過伸縮要考慮用戶實際操作,避免頻繁的伸縮造成的更多干擾。



          3.5.feed/信息流


          大部分產品對于泛瀏覽用戶的匹配場景都是提供信息流,但是單純的給信息流依然無法讓用戶深入沉淀,所以需要在信息流中穿插一些分流入口,譬如品牌、話題、活動、排行等,讓用戶有更深入的瀏覽,這樣才能促成轉化。





          4.流量轉化模型


          流量獲取很容易,但是我們的目標并不是讓用戶進來逛一圈就走,所以流量的轉化我把他以這樣的模型展示,也就是說流量從獲取到沉淀再到最后的進化過程。


          新流量


          獲取新流量的方式很多,例如社交分發、線下活動引流等等,內部流量也可以通過打通多個板塊進行流量互換。但是這些流量是表面的,不做進一步整合也就沒有實際價值,所以我們需要將其沉淀下來。



          undefined



          流量沉淀


          流量就像過江之鯽,如果你想讓這條江里有更多魚,你首先需要有個兜來留住這些用戶,為了不讓這些魚繼續游走,你可以給更多豐富的食物、創造更好的環境。如何讓魚更好的在這里生存呢,要讓他們熟悉你的一切,要讓這些魚在其中發展、繁衍,所以當我們用內容吸引住用戶后,要讓用戶留下來成為深度用戶,這個前提就是讓用戶更長時間的使用產品,如何提升產品使用時長呢?譬如通過智能算法在很多斷流的板塊提供偏好推薦、幫助用戶預判場景、社交互動、讓用戶有成就感、積分體系、個人成長系統、個人品牌塑造等。



          流量進化


          之前兩步依然是在存量市場里盤流量,這是對的,從十四五國家發展規劃來看,我們能看到一個關鍵的變化,就是從“速度”到“質量”的變化,如果你的流量已經完成沉淀,那么可以不著急找增量,而是找進化的方法。當然以下是我個人的一些思考,僅供參考。從淺層到深入,從深入到高效,從高效到創造,所以當你的流量已經比較成熟的時候,可能更多需要讓這些用戶再創造新的內容,他們可以利用你提供的產品創造自己的玩法,即便你不提供任何的幫助也可以形成生態,甚至還可以幫你引入增量市場。


          譬如玩社群的都知道,引流簡單,但是要維持社群的熱度和培養超級粉絲是很難的,但是一旦你做到了,那么這些人就是幫你創造更多的價值,所以你需要一個龐大且智能的基建,還有更好的服務。




          5.流量的分配


          5.1流量分配與產品目標


          判斷流量分配是否合理的標準不在于多和廣,而在于核心價值與目標是否達成。譬如內容型電商(抖音、快手)和傳統型電商(淘寶、京東),內容型電商的流量是依靠內容帶動電商去轉化,更多的是依靠內容的質量,而傳統型電商依靠的是商品,那么在這兩個產品中,前者的流量更多還是要流向內容而非商品。


          再舉個例子,在首頁的板塊中,我們默認流量從大到小是板塊越靠上的越多,越靠下的越少是嗎?也不是,板塊的分配是需要結合用戶需求的,比如你規劃的板塊視覺上很明顯但是從數據上看流量很低,那么這個板塊就是有問題的,或者板塊不明顯但流量很高,這些都不是正常表現。


          所以流量分發之前就要確定好,分發的目的和希望達成的目標。是能夠讓新用戶更快了解產品,還是讓成熟用戶在使用時更高效,或者大力宣傳新業務等等,不是一股腦兒隨大流的把蛋糕切成幾塊。



          5.2.流量分配的權重


          不知道有沒有在做抖音的小伙伴,抖音的流量分發讓很多人搞不明白,其實抖音屬于一個強運營平臺,當用戶制作一個視頻發布后,他的流量并不是全部來自于已經關注你的粉絲,一部分是通過判斷你的視頻內容和質量分發給相應標簽、可能會喜歡的用戶。但是快手和抖音不同,快手的社交分發策略更重,用戶發布的視頻,已經關注的粉絲分發到的比例會更高,這樣用戶的互動也會更強。



          undefined



          6.流量分發效率與設計


          通過一些設計案例我們來看看設計在流量分發中起到的作用。


          1.提高分發效率


          流量與曝光是有關系的,為了爭取更多的曝光我們可以采用這樣的方式進行設計,通常我們可以看到橫向滾動結束后進入下一級界面需要點擊更多,但點擊的成本就高于滑動,所以在這里可以讓用戶直接通過滑動進入下一級界面,增加曝光。同時滑動是承接上一步手勢操作,很連貫,相比點擊的效率也會越高。



          undefined



          2.讓流量扁平化


          我們經常在用產品的時候能看到同一個界面可以從多個不同的入口進來,比如像小鹿茶app點擊下單跳轉到商品列表,也可以直接點擊底部第二個tab切換過來。比如你可以在夜宵板塊和品牌板塊都能找到kfc,讓一個區域的流量不僅僅從單獨的方向流入,這樣可以滿足更多用戶的場景需求。像淘寶的商品流量來自多個不同的層級





          還有我們可以將更深層級的業務板塊提到上一層級,提高子業務板塊的點擊率和曝光,譬如貝殼在下方的tab板塊中除了信息流內容外還嵌入了精選、人氣、熱門三個分類。還有類似像德邦app這樣的工具型首頁其實版面利用率太低,本身產品功能不多其實不需要劃分出這么多板塊,讓每個板塊流量這么分散,可以直接在首頁中加入查單號的功能,并且將寄件收件歷史平鋪在首頁。





          3.讓流量沉淀


          淘寶商品詳情中會有店鋪和店鋪推薦內容,方便用戶查看更多偏好商品,提高客單價。具有電商屬性的社交產品在用戶圖文中可以添加商品鏈接、標簽、話題等等。還有淘寶在首頁的feed流中點擊商品會進入另一個feed流,這里的商品又進行了算法權重的加持,會更加準確與多樣,由于本身處于逛場景的用戶,在這一步再次幫助用戶進行準確選擇,可以提高轉化,當然了,這樣中心化的分流方式對于商家而言不太友好。



          7.如何衡量效果


          7.1點擊率


          衡量流量分發的效果,我們可以查看板塊的點擊率(UV/PV)和預期。比如在某個周期中,有100個人進入這個界面,而這個界面中的banner最終點擊量為1000次,那么這個banner的點擊率為1000/100=10,平均每人點擊了10次。點擊率越高,該入口的流量自然更大。



          undefined



          7.2活躍度


          每個產品對于活躍的標準不同,比如一個商場衡量活躍用戶數會算那些進來蹭空調的大伯大媽嗎?還是衡量那些有消費行為的顧客,同理一個產品計算活躍不是單純看每天有多少人登錄瀏覽就算活躍的。


          那么觀察活躍度有什么用呢?比如我們之前做一個大促活動,每個板塊都有活動,但是大促結束后,只有童裝類板塊的日活流量在持續下降,于是我們通過相關調研,發現是因為童裝類的品類太少,用戶沒有逛和再次購買的興趣。



          7.3頁面停留時長


          一波流量進入后,我們不僅要看他們去了哪里,還要查看這波流量在這里做了什么,于是我們通過查看頁面停留時長可以判斷一些問題,比如


          1. 如果用戶在本該停留時長長的頁面反而停留時間短可能是當前內容不感興趣、看不懂、閃退、臨時有事等等


          2.反之,在本該停留時間短但是用戶停留時間長,說明可能文案排版或者解釋的不清楚、用戶可能在思考、臨時有事等等



          7.4跳失率


          一波流量進入后,可能進入更深級界面也可能停留原地,那么還有一部分可能就直接離開了,查看流量的流失可以幫助我們判斷以下問題


          1.如果用戶在進行某個多步驟任務,當我們發現其在即將完成時退出了,或者在中間步驟退出了,那說明可能出現了某些問題讓用戶進行不下去


          2.用戶可能對當前流程沒有預期,也可能覺得有風險也可能是對某個地方產生不滿



          7.5頁面訪問路徑


          流量就像是一群被標記過的小白鼠,從哪里來到哪里去,中間做了什么,都被我們記錄了下來,那么頁面訪問路徑也是我們查看這些流量去向的關鍵指標,例如cctalk在冷啟動后默認打開發現頁面,我們進行了一些用戶的調研,發現90%以上的同學在進入后都會切換到上課這個界面,這里可以思考的是作為產品我們發現用戶有這樣的行為,需不需要對產品進行優化,產品這樣的設計是否考慮到的是新用戶和培養用戶習慣讓更多課程有曝光。其實這里可以做一些判斷,如果用戶近期有購課、上課的記錄和行為,默認打開上課板塊。若新用戶或者長期沒有上課行為的用戶則默認打開發現界面。這樣就可以起到更精準的分流。





          8.總結

          流量誠可貴,流失就白費。


          今天分享就到這里,你學廢了嗎? 

          文章來源:站酷   作者:應駿

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


          postMessage跨域、跨iframe窗口消息傳遞

          前端達人

          文章目錄

          1. 作用
          2. 語法
          3. 使用
          4. 兼容性
          5. 應用場景

            說起postMessage 可能平時大家也不遇到,但是如果遇到問題了,又想不起它,這里記錄下防止后面忘記它。




          6. 作用

            window.postMessage()方法可以安全地實現Window對象之間的跨域通信。例如,在一個頁面和它生成的彈出窗口之間,或者是頁面和嵌入其中的iframe之間。



            通常情況下,受瀏覽器“同源策略”的限制跨域問題一直是個問題,window.postMessage()提供了一個受控的機制來安全地規避這個限制(如果使用得當的話)。


          7. 語法

            一般來說,一個窗口可以獲得對另一個窗口的引用(例如,通過targetWindow=window.opener),然后使用targetWindow.postMessage()在其上派發MessageEvent。接收窗口隨后可根據需要自行處理此事件,傳遞給window.postMessage()的參數通過事件對象暴露給接收窗口。



            基本語法:



            targetWindow.postMessage(message, targetOrigin, [transfer]);

            1

            targetWindow

            targetWindow就是接收消息的窗口的引用。 獲得該引用的方法包括:



            Window.open

            Window.opener

            HTMLIFrameElement.contentWindow

            Window.parent

            Window.frames +索引值

            message

            要發送到目標窗口的消息。 數據使用結構化克隆算法進行序列化。 這意味著我們可以將各種各樣的數據對象安全地傳遞到目標窗口,而無需自己對其進行序列化。



            targetOrigin

            定目標窗口的來源,必須與消息發送目標相一致,可以是字符串或URI。 表示任何目標窗口都可接收,為安全起見,請一定要明確提定接收方的URI。如果為"*"則都可以接收。



            transfer

            可選屬性。是一串和message同時傳遞的Transferable對象,這些對象的所有權將被轉移給消息的接收方,而發送一方將不再保有所有權。


          8. 使用

            postMessage程序



            var receiver = document.getElementById('receiver').contentWindow;

            var btn = document.getElementById('send');

            btn.addEventListener('click', function (e) {

                e.preventDefault();

                var val = document.getElementById('text').value;

                receiver.postMessage("Hello "+val+"!", "http://www.xxx.com");

            }); 



            接收端



            window.addEventListener("message", receiveMessage, false);

            function receiveMessage(event){

              if (event.origin !== "http://www.xxx.com")

                return;

            }



            event對象有三個屬性,分別是origin,data和source。event.data表示接收到的消息;event.origin表示postMessage的發送來源,包括協議,域名和端口;event.source表示發送消息的窗口對象的引用; 我們可以用這個引用來建立兩個不同來源的窗口之間的雙向通信。


          9. 兼容性



            總體兼容性還是很好的!




          10. 應用場景

            跨域通信(包括GET請求和POST請求)

            WebWorker

            vue項目中使用到了iframe并且需要傳遞參數



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

            版權聲明:本文為CSDN博主「zy1281539626」的原創文章,遵循CC 4.0 BY-SA版權協議,轉載請附上原文出處鏈接及本聲明。

            原文鏈接:https://blog.csdn.net/zy1281539626/article/details/114934551


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


          SpringBoot與Web開發

          前端達人

          SpringBoot與Web開發(超詳細)

          一、簡介

          二、SpringBoot對靜態資源的映射規則

          1、所有 /webjars/ ,都去 classpath:/META-INF/resources/webjars/ 找資源

          2、"/
          " 訪問當前項目的任何資源,都去靜態資源的文件夾找映射

          3、歡迎頁: 靜態資源文件夾下的所有index.html頁面,被"/"映射

          三、模板引擎

          1、引入Thymeleaf

          2、Thymeleaf的使用

          1、導入thymeleaf的名稱空間

          2、使用thymeleaf語法

          3、Thymeleaf的語法規則

          四、SpringMVC自動配置

          1、Spring MVC auto-configuration

          2、擴展SpringMVC

          原理

          3、全面接管SpringMVC

          原理

          五、如何修改SpringBoot的默認配置

          一、簡介

          使用SpringBoot的步驟:



          1、創建SpringBoot應用,選中我們需要的模塊。

          2、SpringBoot已經默認將這些場景配置好了,只需要在配置文件中指定少量配置就可以運行起來。

          3、自己編寫業務代碼。



          自動配置原理:



          xxxxAutoConfiguration:幫我們給容器中自動配置組件

          xxxxProperties:配置類來封裝配置文件的內容

          1

          2

          二、SpringBoot對靜態資源的映射規則

          @ConfigurationProperties(prefix = "spring.resources", ignoreUnknownFields = false)

          public class ResourceProperties implements ResourceLoaderAware {

            //可以設置和靜態資源有關的參數,緩存時間等

          1

          2

          3

          WebMvcAuotConfiguration:

          @Override

          public void addResourceHandlers(ResourceHandlerRegistry registry) {

          if (!this.resourceProperties.isAddMappings()) {

          logger.debug("Default resource handling disabled");

          return;

          }

          Integer cachePeriod = this.resourceProperties.getCachePeriod();

          if (!registry.hasMappingForPattern("/webjars/
          ")) {

          customizeResourceHandlerRegistration(

          registry.addResourceHandler("/webjars/**")

          .addResourceLocations(

          "classpath:/META-INF/resources/webjars/")

          .setCachePeriod(cachePeriod));

          }

          String staticPathPattern = this.mvcProperties.getStaticPathPattern();

                    //靜態資源文件夾映射

          if (!registry.hasMappingForPattern(staticPathPattern)) {

          customizeResourceHandlerRegistration(

          registry.addResourceHandler(staticPathPattern)

          .addResourceLocations(

          this.resourceProperties.getStaticLocations())

          .setCachePeriod(cachePeriod));

          }

          }



                 //配置歡迎頁映射

          @Bean

          public WelcomePageHandlerMapping welcomePageHandlerMapping(

          ResourceProperties resourceProperties) {

          return new WelcomePageHandlerMapping(resourceProperties.getWelcomePage(),

          this.mvcProperties.getStaticPathPattern());

          }



                //配置喜歡的圖標

          @Configuration

          @ConditionalOnProperty(value = "spring.mvc.favicon.enabled", matchIfMissing = true)

          public static class FaviconConfiguration {



          private final ResourceProperties resourceProperties;



          public FaviconConfiguration(ResourceProperties resourceProperties) {

          this.resourceProperties = resourceProperties;

          }



          @Bean

          public SimpleUrlHandlerMapping faviconHandlerMapping() {

          SimpleUrlHandlerMapping mapping = new SimpleUrlHandlerMapping();

          mapping.setOrder(Ordered.HIGHEST_PRECEDENCE + 1);

                        //所有  /favicon.ico 

          mapping.setUrlMap(Collections.singletonMap("
          /favicon.ico",

          faviconRequestHandler()));

          return mapping;

          }



          @Bean

          public ResourceHttpRequestHandler faviconRequestHandler() {

          ResourceHttpRequestHandler requestHandler = new ResourceHttpRequestHandler();

          requestHandler

          .setLocations(this.resourceProperties.getFaviconLocations());

          return requestHandler;

          }



          }





          1、所有 /webjars/ ,都去 classpath:/META-INF/resources/webjars/ 找資源

          webjars:以jar包的方式引入靜態資源。WebJars



          訪問localhost:8080/webjars/jquery/3.3.1/jquery.js的結果:





          2、"/
          " 訪問當前項目的任何資源,都去靜態資源的文件夾找映射

          "classpath:/META-INF/resources/", 

          "classpath:/resources/",

          "classpath:/static/", 

          "classpath:/public/" 

          "/":當前項目的根路徑



          例子:訪問localhost:8080/abc 就是去靜態資源文件夾里面找abc



          例如我們訪問js文件夾下的Chart.min.js:



          訪問結果:





          3、歡迎頁: 靜態資源文件夾下的所有index.html頁面,被"/"映射

          編寫index.html文件。



          訪問結果:





          三、模板引擎

          常見的模板引擎:JSP、Velocity、Freemarker、Thymeleaf(springboot推薦,語法更簡單,功能更強大)





          1、引入Thymeleaf

          Thymeleaf官網



          在pom.xml中添加以下依賴:



           <dependency>

             <groupId>org.springframework.boot</groupId>

               <artifactId>spring-boot-starter-thymeleaf</artifactId>

           </dependency>



          2、Thymeleaf的使用

          @ConfigurationProperties(prefix = "spring.thymeleaf")

          public class ThymeleafProperties {



          private static final Charset DEFAULT_ENCODING = Charset.forName("UTF-8");



          private static final MimeType DEFAULT_CONTENT_TYPE = MimeType.valueOf("text/html");



          public static final String DEFAULT_PREFIX = "classpath:/templates/";



          public static final String DEFAULT_SUFFIX = ".html";



          1

          只要我們把HTML頁面放在classpath:/templates/,thymeleaf就能自動渲染。



          success.html:



          HelloController:



          package com.keafmd.springboot.controller;



          import org.springframework.stereotype.Controller;

          import org.springframework.web.bind.annotation.RequestMapping;

          import org.springframework.web.bind.annotation.ResponseBody;



          /


            Keafmd

           


            @ClassName: HelloController

           
          @Description:

            @author: 牛哄哄的柯南

           
          @date: 2021-03-04 19:54

           */



          @Controller

          public class HelloController {



              @ResponseBody

              @RequestMapping("/hello")

              public String hello(){

                  return "Hello World";

              }



              @RequestMapping("/success")

              public String success() {

                  return "success";

              }

          }



          訪問success的結果:





          1、導入thymeleaf的名稱空間

          <html lang="en" xmlns:th=";

          1

          2、使用thymeleaf語法

          HelloController:



          package com.keafmd.springboot.controller;



          import org.springframework.stereotype.Controller;

          import org.springframework.web.bind.annotation.RequestMapping;

          import org.springframework.web.bind.annotation.ResponseBody;



          import java.util.Map;



          /*

           
          Keafmd

           

           
          @ClassName: HelloController

            @Description:

           
          @author: 牛哄哄的柯南

            @date: 2021-03-04 19:54

           
          /



          @Controller

          public class HelloController {



              @ResponseBody

              @RequestMapping("/hello")

              public String hello(){

                  return "Hello World";

              }



              /*

               
          查出一些數據在頁面顯示

                @param map

               
          @return

               */

              @RequestMapping("/success")

              public String success(Map<String,Object> map) {

                  map.put("hello","你好");

                  return "success";

              }

          }



          success.html:



          <!DOCTYPE html>

          <html lang="en" xmlns:th="
          ;

          <head>

              <meta charset="UTF-8">

              <title>Title</title>

          </head>

          <body>

              <h1>成功</h1>

              <!--th:text 將div里面的文本內容設置為-->

              <div th:text="${hello}"></div>

          </body>

          </html>



          運行結果:





          3、Thymeleaf的語法規則

          1、th:任意html屬性,來替換原生屬性的值



          th:text — 改變當前元素里面的文本內容

          更多參考下圖:



          2、表達式



          Simple expressions:(表達式語法)

              Variable Expressions: ${...}:獲取變量值;OGNL;

              1)、獲取對象的屬性、調用方法

              2)、使用內置的基本對象:

              #ctx : the context object.

              #vars: the context variables.

                          #locale : the context locale.

                          #request : (only in Web Contexts) the HttpServletRequest object.

                          #response : (only in Web Contexts) the HttpServletResponse object.

                          #session : (only in Web Contexts) the HttpSession object.

                          #servletContext : (only in Web Contexts) the ServletContext object.

                          

                          ${session.foo}

                      3)、內置的一些工具對象:

          execInfo : information about the template being processed.

          messages : methods for obtaining externalized messages inside variables expressions, in the same way as they would be obtained using #{…} syntax.

          uris : methods for escaping parts of URLs/URIs

          conversions : methods for executing the configured conversion service (if any).

          dates : methods for java.util.Date objects: formatting, component extraction, etc.

          calendars : analogous to #dates , but for java.util.Calendar objects.

          numbers : methods for formatting numeric objects.

          strings : methods for String objects: contains, startsWith, prepending/appending, etc.

          objects : methods for objects in general.

          bools : methods for boolean evaluation.

          arrays : methods for arrays.

          lists : methods for lists.

          sets : methods for sets.

          maps : methods for maps.

          aggregates : methods for creating aggregates on arrays or collections.

          ids : methods for dealing with id attributes that might be repeated (for example, as a result of an iteration).



              Selection Variable Expressions: {...}:選擇表達式:和${}在功能上是一樣;

              補充:配合 th:object="${session.user}:

             <div th:object="${session.user}">

              <p>Name: <span th:text="
          {firstName}">Sebastian</span>.</p>

              <p>Surname: <span th:text="{lastName}">Pepper</span>.</p>

              <p>Nationality: <span th:text="
          {nationality}">Saturn</span>.</p>

              </div>

              

              Message Expressions: #{...}:獲取國際化內容

              Link URL Expressions: @{...}:定義URL;

              @{/order/process(execId=${execId},execType='FAST')}

              Fragment Expressions: ~{...}:片段引用表達式

              <div th:insert="~{commons :: main}">...</div>

             

          Literals(字面量)

                Text literals: 'one text' , 'Another one!' ,…

                Number literals: 0 , 34 , 3.0 , 12.3 ,…

                Boolean literals: true , false

                Null literal: null

                Literal tokens: one , sometext , main ,…

          Text operations:(文本操作)

              String concatenation: +

              Literal substitutions: |The name is ${name}|

          Arithmetic operations:(數學運算)

              Binary operators: + , - , * , / , %

              Minus sign (unary operator): -

          Boolean operations:(布爾運算)

              Binary operators: and , or

              Boolean negation (unary operator): ! , not

          Comparisons and equality:(比較運算)

              Comparators: > , < , >= , <= ( gt , lt , ge , le )

              Equality operators: == , != ( eq , ne )

          Conditional operators:條件運算(三元運算符)

              If-then: (if) ? (then)

              If-then-else: (if) ? (then) : (else)

              Default: (value) ?: (defaultvalue)

          Special tokens:

              No-Operation: _ 



          注意:內容過多,詳細內容參考官方文檔。



          示例:↓



          HelloController:



          package com.keafmd.springboot.controller;



          import org.springframework.stereotype.Controller;

          import org.springframework.web.bind.annotation.RequestMapping;

          import org.springframework.web.bind.annotation.ResponseBody;



          import java.util.Arrays;

          import java.util.Map;



          /*

           
          Keafmd

           

           
          @ClassName: HelloController

            @Description:

           
          @author: 牛哄哄的柯南

            @date: 2021-03-04 19:54

           
          /



          @Controller

          public class HelloController {



              @ResponseBody

              @RequestMapping("/hello")

              public String hello(){

                  return "Hello World";

              }



              /*

               
          查出一些數據在頁面顯示

                @param map

               
          @return

               */

              @RequestMapping("/success")

              public String success(Map<String,Object> map) {

                  map.put("hello","你好");

                  map.put("hello1","<h1>你好</h1>");

                  map.put("users", Arrays.asList("柯南","小蘭","基德"));

                  return "success";

              }

          }



          success.html:



          <!DOCTYPE html>

          <html lang="en" xmlns:th="
          ;

          <head>

              <meta charset="UTF-8">

              <title>Title</title>

          </head>

          <body>

              <h1>成功</h1>

              <!--th:text 將div里面的文本內容設置為-->

              <div id="div01" class="myDiv" th:id="${hello}" th:class="${hello}" th:text="${hello}">這里的內容被覆蓋</div>



              <hr/>

              <div th:text="${hello1}"></div>

              <div th:utext="${hello1}"></div>

              <hr/>

              <!--th:each 每次遍歷都會生成當前這個標簽-->

              <h4 th:text="${user}" th:each="user:${users}"></h4>

              <hr/>

              <h4>

                  <span th:each="user:${users}"> [[${user}]] </span>

              </h4>

          </body>

          </html>



          效果:







          四、SpringMVC自動配置

          1、Spring MVC auto-configuration

          參考官方文檔:點這里



          Spring Boot 自動配置好了SpringMVC



          以下是SpringBoot對SpringMVC的默認配置:(WebMvcAutoConfiguration)



          Inclusion of ContentNegotiatingViewResolver and BeanNameViewResolver beans.



          自動配置了ViewResolver(視圖解析器:根據方法的返回值得到視圖對象(View),視圖對象決定如何渲染(轉發?重定向?))

          ContentNegotiatingViewResolver:組合所有的視圖解析器的。

          如何定制:我們可以自己給容器中添加一個視圖解析器;自動的將其組合進來。

          Support for serving static resources, including support for WebJars (see below).靜態資源文件夾路徑,webjars



          Static index.html support. 靜態首頁訪問



          Custom Favicon support (see below). favicon.ico



          自動注冊了 of Converter, GenericConverter, Formatter beans.



          Converter:轉換器; public String hello(User user):類型轉換使用Converter

          Formatter :格式化器; 2017.12.17===Date

          @Bean

          @ConditionalOnProperty(prefix = "spring.mvc", name = "date-format")//在文件中配置日期格式化的規則

          public Formatter<Date> dateFormatter() {

              return new DateFormatter(this.mvcProperties.getDateFormat());//日期格式化組件

          }

          1

          2

          3

          4

          5

          自己添加的格式化器轉換器,我們只需要放在容器中即可



          Support for HttpMessageConverters (see below).



          HttpMessageConverter:SpringMVC用來轉換Http請求和響應的;User—Json



          HttpMessageConverters 是從容器中確定;獲取所有的HttpMessageConverter



          自己給容器中添加HttpMessageConverter,只需要將自己的組件注冊容器中(@Bean,@Component)



          Automatic registration of MessageCodesResolver (see below):定義錯誤代碼生成規則



          Automatic use of a ConfigurableWebBindingInitializer bean (see below).



          我們可以配置一個ConfigurableWebBindingInitializer來替換默認的(添加到容器)



          初始化WebDataBinder

          請求數據=====JavaBean

          1

          2

          org.springframework.boot.autoconfigure.web:web的所有自動場景



          If you want to keep Spring Boot MVC features, and you just want to add additional MVC configuration (interceptors, formatters, view controllers etc.) you can add your own @Configuration class of type WebMvcConfigurerAdapter, but without @EnableWebMvc. If you wish to provide custom instances of RequestMappingHandlerMapping, RequestMappingHandlerAdapter or ExceptionHandlerExceptionResolver you can declare a WebMvcRegistrationsAdapter instance providing such components.



          如果你想保持Spring Boot MVC 功能,你只是想添加額外的(MVC配置)(
          https://docs.spring.io/spring/docs/4.3.14.RELEASE/spring-framework-reference/htmlsingle MVC)(攔截器,格式器,視圖控制器等)您可以添加自己的@ configuration類WebMvcConfigurerAdapter類型,但沒有@EnableWebMvc。如果你想提供RequestMappingHandlerMapping, RequestMappingHandlerAdapter或ExceptionHandlerExceptionResolver的自定義實例,你可以聲明一個WebMvcRegistrationsAdapter實例來提供這樣的組件。



          If you want to take complete control of Spring MVC, you can add your own @Configuration annotated with @EnableWebMvc.



          如果你想完全控制Spring MVC,你可以添加你自己的@Configuration注解@EnableWebMvc。



          2、擴展SpringMVC

          實現如下功能:



          <mvc:view-controller path="/hello" view-name="success"></mvc:view-controller>



          <mvc:interceptors>

              <mvc:interceptor>

                  <mvc:mapping path="/hello"/>

                  <bean></bean>

              </mvc:interceptor>

          </mvc:interceptors>



          做法:編寫一個配置類(@Configuration),是WebMvcConfigurerAdapter類型;不能標注@EnableWebMvc



          特點:既保留了所有的自動配置,也能用我們擴展的配置。



          在config包下創建個MyMvcConfig。



          代碼實現:



          package com.keafmd.springboot.config;



          import org.springframework.context.annotation.Configuration;

          import org.springframework.web.servlet.config.annotation.ViewControllerRegistry;

          import org.springframework.web.servlet.config.annotation.WebMvcConfigurer;





          /*

           
          Keafmd

           

           
          @ClassName: MyMvcConfig

            @Description:

           
          @author: 牛哄哄的柯南

            @date: 2021-03-17 20:26

           
          /

          @Configuration

          public class MyMvcConfig implements WebMvcConfigurer {

              @Override

              public void addViewControllers(ViewControllerRegistry registry) {

                  //瀏覽器發送 /keafmd 請求 來到success頁面

                  registry.addViewController("/keafmd").setViewName("success");

              }

          }



          原理

          1、WebMvcAutoConfiguration是SpringMVC的自動配置類。

          2、在做其他自動配置時會導入,@Import(EnableWebMvcConfiguration.class)。



             @Configuration

          public static class EnableWebMvcConfiguration extends DelegatingWebMvcConfiguration {

               private final WebMvcConfigurerComposite configurers = new WebMvcConfigurerComposite();



               //從容器中獲取所有的WebMvcConfigurer

               @Autowired(required = false)

               public void setConfigurers(List<WebMvcConfigurer> configurers) {

                   if (!CollectionUtils.isEmpty(configurers)) {

                       this.configurers.addWebMvcConfigurers(configurers);

                      //一個參考實現;將所有的WebMvcConfigurer相關配置都來一起調用;  

                      @Override

                      // public void addViewControllers(ViewControllerRegistry registry) {

                       //    for (WebMvcConfigurer delegate : this.delegates) {

                        //       delegate.addViewControllers(registry);

                        //   }

                       }

                   }

          }



          3、容器中所有的WebMvcConfigurer都會一起起作用。

          4、我們的配置類也會被調用。



          效果:SpringMVC的自動配置和我們的擴展配置都會起作用。



          3、全面接管SpringMVC

          SpringBoot對SpringMVC的自動配置不需要了,所有都是我們自己配置,所有的SpringMVC的自動配置都失效了。



          做法:我們需要在配置類中添加@EnableWebMvc即可。



          @EnableWebMvc

          @Configuration

          public class MyMvcConfig implements WebMvcConfigurer {

              @Override

              public void addViewControllers(ViewControllerRegistry registry) {

                  //瀏覽器發送 /keafmd 請求 來到success頁面

                  registry.addViewController("/keafmd").setViewName("success");

              }

          }





          全面接管后,靜態資源失效。

          不推薦這樣全面接管。





          原理

          加了@EnableWebMvc自動配置就失效了。



          1、@EnableWebMvc的核心:



          @Import({DelegatingWebMvcConfiguration.class})

          public @interface EnableWebMvc {



          2、DelegatingWebMvcConfiguration



          @Configuration(

              proxyBeanMethods = false

          )

          public class DelegatingWebMvcConfiguration extends WebMvcConfigurationSupport {



          3、WebMvcAutoConfiguration



          @Configuration(

              proxyBeanMethods = false

          )

          @ConditionalOnWebApplication(

              type = Type.SERVLET

          )

          @ConditionalOnClass({Servlet.class, DispatcherServlet.class, WebMvcConfigurer.class})

          //容器中沒有這個組件的時候,這個自動配置類才生效

          @ConditionalOnMissingBean({WebMvcConfigurationSupport.class})

          @AutoConfigureOrder(-2147483638)

          @AutoConfigureAfter({DispatcherServletAutoConfiguration.class, TaskExecutionAutoConfiguration.class, ValidationAutoConfiguration.class})

          public class WebMvcAutoConfiguration {



          4、@EnableWebMvc將WebMvcConfigurationSupport組件導入進來,自動配置類失效了。



          5、導入的WebMvcConfigurationSupport只是SpringMVC最基本的功能。



          五、如何修改SpringBoot的默認配置

          1、SpringBoot在自動配置很多組件的時候,先看容器中有沒有用戶自己配置的(@Bean、@Component)如果有就用用戶配置的,如果沒有,才自動配置;如果有些組件可以有多個(ViewResolver)將用戶配置的和自己默認的組合起來。

          2、在SpringBoot中會有非常多的xxxConfigurer幫助我們進行擴展配置。

          3、在SpringBoot中會有很多的xxxCustomizer幫助我們進行定制配置。



          以上就是SpringBoot與Web開發(超詳細)篇一的全部內容。

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

          版權聲明:本文為CSDN博主「牛哄哄的柯南」的原創文章,遵循CC 4.0 BY-SA版權協議,轉載請附上原文出處鏈接及本聲明。

          原文鏈接:https://blog.csdn.net/weixin_43883917/article/details/114375472


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


          日歷

          鏈接

          個人資料

          藍藍設計的小編 http://www.syprn.cn

          存檔

          亚洲va欧美va天堂v国产综合