首頁

損失厭惡心理是如何影響我們的決策

資深UI設(shè)計者

損失厭惡心理在設(shè)計中的應(yīng)用以及是怎么影響我們的決策

前言:

前幾天在一篇文章中看到“損失厭惡”這個心理學(xué)現(xiàn)象,就上網(wǎng)查閱了一些相關(guān)資料,以及它在設(shè)計中是如何運(yùn)用,又是如何影響我們的決策,總結(jié)一點自己的觀點。


一、損失厭惡


對于損失厭惡,先來做幾個實驗,來幫助我們更好的理解。

如果我給你一個蘋果,你應(yīng)該會感到高興吧!現(xiàn)在換一下,我給你兩個蘋果,接著我向你拿回了一個。

請問,你更喜歡哪一個場景?我想多數(shù)人的答案是第一個,而不喜歡第二個場景。

這個實驗兩個場景的結(jié)果都是一樣的,都得到了一個蘋果,但是在第二個場景中,因為得而復(fù)失,損失了一個蘋果,這嚴(yán)重影響并拉低了獲得一個蘋果的幸福感。


丹尼爾·卡尼曼(Daniel Kahneman)曾經(jīng)設(shè)計了一個擲質(zhì)硬幣的實驗,硬幣是均質(zhì)的。如果是正面,你將得到150美元;如果是背面,你將輸?shù)?00美元。這個賭局對于參與者來說,長期下注的話,肯定是穩(wěn)賺不賠的,畢竟輸贏概率相同,贏的收益大于輸?shù)膿p失。

但是實驗結(jié)果卻是,大多數(shù)人仍然拒絕了這個賭局,因為對于多數(shù)人來說,損失100美元的痛苦遠(yuǎn)遠(yuǎn)大于得到150美元的快樂。最少收益多少,快樂才能彌補(bǔ)普通人是失去100美元的痛苦呢?答案是,200美元。


由上述實驗我們可以看出:


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


二、堅持中庸最好


我們在進(jìn)行網(wǎng)購的時候,比如看上一件很喜歡的衣服,追求高性價比的用戶會通過圖片在淘寶進(jìn)行搜索,進(jìn)行價格的對比,從而選擇一款銷量高、評價好、價格又合理的款式。

“損失厭惡心理”在其中發(fā)揮著它的作用,人們害怕價格太低,買到的商品沒有自己預(yù)期的好,質(zhì)量得不到保障,害怕價格太高,買到的商品不值這個價格。感覺自己會買虧,所以我們總是選擇規(guī)避這樣的風(fēng)險,去選擇一個中間價位的作為目標(biāo)購買, “堅持中庸最好”。   



三、電商中的應(yīng)用


每逢換季、過節(jié)時一些電商平臺經(jīng)常會搞一些促銷活動,比如

  1. 2件8折,3件7折,預(yù)計到手XX元;

  2. 現(xiàn)價99,倒計時x小時恢復(fù)199;

  3. 線下店面到期最后一天全場5折的海報(每次路過的時候都是最后一天)

商家都是為了營造現(xiàn)在不買就沒的“稀缺感”對你刺激消費(fèi),套路還是老套路,但是一直都很有用。如果我們真喜歡這件物品,即使湊單也要享受7折優(yōu)惠去購買,因為你會感覺便宜很多,省下了不少錢;


還有一年一次的店慶,淘寶的雙11,京東的618,也以用戶的“損失厭惡”心理為基座。

用戶從第一個角度想,能在這樣的狂歡節(jié)中買到如此實惠的產(chǎn)品,一定要抓住機(jī)會,熬夜也要買買買!

用戶從第二個角度想,一年一次,要是錯過這個機(jī)會,如此實惠的產(chǎn)品可只有明年才有了,越累越多的人有這種心理,所以淘寶雙十一的總額年年都在刷新記錄。


再就是拼團(tuán)功能的應(yīng)用,單買價格可能對你來說不貴,但拼團(tuán)會讓你感覺更劃算,能省則省,中國有14億人,有那么3 4億消費(fèi)者是不追求高質(zhì)量、高標(biāo)準(zhǔn)的,對于他們來說便宜就行,也正是因為這樣一撥人,才促使了拼多多的在短短的3 4年就可以做到上市的原因之一。



在二手平臺,有個估價的功能,當(dāng)我們輸入我們產(chǎn)品的各種信息后,會出現(xiàn)一個大概的市場價,下面會提示我們預(yù)計下周跌幅150元、一周后在降低200元等信息,這些細(xì)節(jié)設(shè)計的很到位,都是利用了人們的損失厭倦心理去促成交易。



四、股票市場中的應(yīng)用


“損失厭惡”心理往往深刻影響這人們的投資決策。例如,你手中有兩只股票,一只漲了100塊,另一只跌了100塊?,F(xiàn)在你因急事需要用錢,必須賣掉一只,那么你會賣掉哪一只?調(diào)查顯示,大多數(shù)人會選擇賣掉上漲的股票。因為股票上漲是收益,賺了白不賺,一定要先落袋為安,卻沒有考慮它繼續(xù)上漲的可能性。而股票下跌是損失,面臨損失大多數(shù)人是不可接受的,總希望它能漲回來避免損失,如果賣掉那損失就永遠(yuǎn)不可挽回了。事實上正確的操作應(yīng)該是賣掉跌的股票,及時止損,不然損失越來越大的概率要更高。


作者在支付寶里買了兩支基金,在探索階段,所以少買了一些在試水,第一支波動比較大,會有虧損,第二支,比較平穩(wěn)基本就是定期的會有收益,即使沒有,也幾乎沒有虧損的情況,而對我這種金融小白來說會賣掉虧損比較大的,用這些錢去買穩(wěn)定一些的產(chǎn)品。



五、不要被蠅頭小利蒙蔽


養(yǎng)孩子最貴的莫過于尿不濕和奶粉了當(dāng)然除了學(xué)費(fèi),對于一個追求高性價比的人來說,孩子的尿不濕我會在閑魚淘一些寶媽們轉(zhuǎn)賣的全新產(chǎn)品,從下面這個對話來看,我們兩個都會呈現(xiàn)出明顯的“損失厭惡心理”,賣家不愿意放棄自己眼里的利益,認(rèn)為自己可以減少損失,而我之前因為花了同樣的錢買了同樣數(shù)量的同樣的品牌,所以也不想做出讓步,最終也沒完成交易。



六、間斷造成的損失


一些app中的簽到、金幣購買皮膚等這些常見的功能就是利用了用戶的損失厭惡心理來增加用戶粘性,當(dāng)用戶連續(xù)簽到多少天才可以贏得紅包或禮品,中間只要一間斷不僅領(lǐng)不到獎勵還要重新開始簽到,所以一些用戶為了減少自己的損失,就會連續(xù)簽到,還有QQ退出時的提示語也是利用了用戶的這種心理,從而能很好的增加留存。



掌上生活app中的積分抽獎活動,1分、9分,一點點的花光都沒抽中你想要的,內(nèi)心的不服輸,又抱著僥幸的心理再來一次,可能你把積分花光了也不一定能中獎;

像這樣的情況,我們很容易被眼前的利益所蒙蔽,我們不愿意放棄對未來會有更大利益的收獲,所以不斷投入“沉沒成本”,令損失加倍。



七、在產(chǎn)品中的植入


最常見的就是“購物車”功能,我們女生都愛買買買,也常把購物車當(dāng)作收藏來使用,放進(jìn)購物車,就感覺這件商品自己的,過兩天在看,已經(jīng)下架就會感覺自己像失去了一件寶貝似的

還有就是VIP體驗功能,我們通過百度云盤上傳或者下載文件的時候,會有一個免費(fèi)體驗300秒的極速下載的功能,先讓你體驗了最為VIP的待遇,體驗過后,開始給你限速;


蘇寧易購APP中非會員用戶可以免費(fèi)享受一個月SUPER VIP,并購買商品時返現(xiàn)2%到個人賬戶中,讓用戶感覺我買東西的同時還可以剩下2%,像是自己賺到的一樣,體驗期過后,你會感覺自己買東西虧了很多;


這些產(chǎn)品都是先讓你免費(fèi)試用付費(fèi)的VIP,待你用習(xí)慣了,VIP也停了,大部分人都會乖乖付費(fèi),這也是損失厭惡的一種應(yīng)用。



八、不敢輕易嘗試


在生活中我們吃飯、逛街也是一樣,尤其是吃飯,我們通常會選擇口味、價格、服務(wù)、環(huán)境等都比較熟悉的地方吃飯,對一些不熟悉的飯館,會比較謹(jǐn)慎,這也是損失厭惡心理在“作祟”擔(dān)心陌生的餐館飯菜不好吃還貴;


生活中還有很多常見的損失厭惡心理作祟的例子:比如吃自助餐,雖然過食傷胃的道理大家都懂,人們依然覺得已經(jīng)花了這么多錢,就該敞開肚子吃才算有“賺到”;比如花30塊買了張電影票,但看了20分鐘后覺得無聊至極,但想著已經(jīng)花了30塊,不看完整場會很“虧”,選擇繼續(xù)呆在影院,即使電影帶來的效益為負(fù)……有些時候,哪怕是很小的損失。


總結(jié):


我們每個人都有損失厭惡心理,可以說是天性,也是本能,我們要盡可能去找到一些產(chǎn)生損失厭惡的邊界,讓自己坦然面對損失,規(guī)避“損失厭惡”。

點擊遮罩層的背景關(guān)閉遮罩層

seo達(dá)人

開發(fā)工具與關(guān)鍵技術(shù):Adobe Dreamweaver CC

作者:黃燦

撰寫時間:2019.1.16



在模仿華為官方網(wǎng)頁的練習(xí)當(dāng)中我發(fā)現(xiàn)華為官網(wǎng)中有一個遮罩層是隨便點擊遮罩層的背景也能關(guān)閉掉遮罩層,但唯獨(dú)點擊內(nèi)容區(qū)域不會關(guān)閉掉遮罩層。于是我開始模仿這個寫案例,連內(nèi)容也一模一樣(因為這個練習(xí)就是要寫出和華為關(guān)一樣的效果或則比它更好的效果),一開始我是這樣子寫的(圖1)



圖1



class=Select_Region_bj 我給了一個灰色半透明的背景樣式,后來在Javascript中寫onclick事件無論這么寫,點擊內(nèi)容區(qū)也是會關(guān)閉掉遮罩層。我百思不得其解到底怎么樣寫才能點擊內(nèi)容區(qū)不會關(guān)閉遮罩層,后來下課期間我看見我同學(xué)他寫的帶能點擊內(nèi)容區(qū)不會關(guān)閉遮罩層。我問他你是這么寫的,他告訴我:“把他們分離就可以的了?!蔽宜伎剂艘粫X補(bǔ):分離?怎么分離?補(bǔ)著補(bǔ)著補(bǔ)著就補(bǔ)出了背景和內(nèi)容區(qū)分離。分離寫(圖2)

圖2



把背景層和內(nèi)容區(qū)分開來寫,不要在背景層中包裹內(nèi)容,這樣子點擊內(nèi)容區(qū)就不會關(guān)閉掉遮罩層了!

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

深入理解vue中的slot與slot-scope

seo達(dá)人

寫在前面

vue中關(guān)于插槽的文檔說明很短,語言又寫的很凝練,再加上其和methods,data,computed等常用選項使用頻率、使用先后上的差別,這就有可能造成初次接觸插槽的開發(fā)者容易產(chǎn)生“算了吧,回頭再學(xué),反正已經(jīng)可以寫基礎(chǔ)組件了”,于是就關(guān)閉了vue說明文檔。

實際上,插槽的概念很簡單,下面通過分三部分來講。這個部分也是按照vue說明文檔的順序來寫的。

進(jìn)入三部分之前,先讓還沒接觸過插槽的同學(xué)對什么是插槽有一個簡單的概念:插槽,也就是slot,是組件的一塊HTML模板,這塊模板顯示不顯示、以及怎樣顯示由父組件來決定。 實際上,一個slot最核心的兩個問題這里就點出來了,是顯示不顯示怎樣顯示

由于插槽是一塊模板,所以,對于任何一個組件,從模板種類的角度來分,其實都可以分為非插槽模板插槽模板兩大類。
非插槽模板指的是html模板,指的是‘div、span、ul、table’這些,非插槽模板的顯示與隱藏以及怎樣顯示由插件自身控制;插槽模板是slot,它是一個空殼子,因為它顯示與隱藏以及最后用什么樣的html模板顯示由父組件控制。但是插槽顯示的位置確由子組件自身決定,slot寫在組件template的哪塊,父組件傳過來的模板將來就顯示在哪塊。

單個插槽 | 默認(rèn)插槽 | 匿名插槽

首先是單個插槽,單個插槽是vue的官方叫法,但是其實也可以叫它默認(rèn)插槽,或者與具名插槽相對,我們可以叫它匿名插槽。因為它不用設(shè)置name屬性。

單個插槽可以放置在組件的任意位置,但是就像它的名字一樣,一個組件中只能有一個該類插槽。相對應(yīng)的,具名插槽就可以有很多個,只要名字(name屬性)不同就可以了。

下面通過一個例子來展示。

父組件:


  1. <template>
  2. <div class="father">
  3. <h3>這里是父組件</h3>
  4. <child>
  5. <div class="tmpl">
  6. <span>菜單1</span>
  7. <span>菜單2</span>
  8. <span>菜單3</span>
  9. <span>菜單4</span>
  10. <span>菜單5</span>
  11. <span>菜單6</span>
  12. </div>
  13. </child>
  14. </div>
  15. </template>

子組件:


  1. <template>
  2. <div class="child">
  3. <h3>這里是子組件</h3>
  4. <slot></slot>
  5. </div>
  6. </template>

在這個例子里,因為父組件在<child></child>里面寫了html模板,那么子組件的匿名插槽這塊模板就是下面這樣。也就是說,子組件的匿名插槽被使用了,是被下面這塊模板使用了。


  1. <div class="tmpl">
  2. <span>菜單1</span>
  3. <span>菜單2</span>
  4. <span>菜單3</span>
  5. <span>菜單4</span>
  6. <span>菜單5</span>
  7. <span>菜單6</span>
  8. </div>

最終的渲染結(jié)果如圖所示:



  1. 注:所有demo都加了樣式,以方便觀察。其中,父組件以灰色背景填充,子組件都以淺藍(lán)色填充。

具名插槽

匿名插槽沒有name屬性,所以是匿名插槽,那么,插槽加了name屬性,就變成了具名插槽。具名插槽可以在一個組件中出現(xiàn)N次。出現(xiàn)在不同的位置。下面的例子,就是一個有兩個具名插槽單個插槽的組件,這三個插槽被父組件用同一套css樣式顯示了出來,不同的是內(nèi)容上略有區(qū)別。

父組件:


  1. <template>
  2. <div class="father">
  3. <h3>這里是父組件</h3>
  4. <child>
  5. <div class="tmpl" slot="up">
  6. <span>菜單1</span>
  7. <span>菜單2</span>
  8. <span>菜單3</span>
  9. <span>菜單4</span>
  10. <span>菜單5</span>
  11. <span>菜單6</span>
  12. </div>
  13. <div class="tmpl" slot="down">
  14. <span>菜單-1</span>
  15. <span>菜單-2</span>
  16. <span>菜單-3</span>
  17. <span>菜單-4</span>
  18. <span>菜單-5</span>
  19. <span>菜單-6</span>
  20. </div>
  21. <div class="tmpl">
  22. <span>菜單->1</span>
  23. <span>菜單->2</span>
  24. <span>菜單->3</span>
  25. <span>菜單->4</span>
  26. <span>菜單->5</span>
  27. <span>菜單->6</span>
  28. </div>
  29. </child>
  30. </div>
  31. </template>

子組件:


  1. <template>
  2. <div class="child">
  3. // 具名插槽
  4. <slot name="up"></slot>
  5. <h3>這里是子組件</h3>
  6. // 具名插槽
  7. <slot name="down"></slot>
  8. // 匿名插槽
  9. <slot></slot>
  10. </div>
  11. </template>

顯示結(jié)果如圖:


可以看到,父組件通過html模板上的slot屬性關(guān)聯(lián)具名插槽。沒有slot屬性的html模板默認(rèn)關(guān)聯(lián)匿名插槽。

作用域插槽 | 帶數(shù)據(jù)的插槽

最后,就是我們的作用域插槽。這個稍微難理解一點。官方叫它作用域插槽,實際上,對比前面兩種插槽,我們可以叫它帶數(shù)據(jù)的插槽。什么意思呢,就是前面兩種,都是在組件的template里面寫


  1. 匿名插槽
  2. <slot></slot>
  3. 具名插槽
  4. <slot name="up"></slot>

但是作用域插槽要求,在slot上面綁定數(shù)據(jù)。也就是你得寫成大概下面這個樣子。


  1. <slot name="up" :data="data"></slot>
  2. export default {
  3. data: function(){
  4. return {
  5. data: ['zhangsan','lisi','wanwu','zhaoliu','tianqi','xiaoba']
  6. }
  7. },
  8. }

我們前面說了,插槽最后顯示不顯示是看父組件有沒有在child下面寫模板,像下面那樣。


  1. <child>
  2. html模板
  3. </child>

寫了,插槽就總得在瀏覽器上顯示點東西,東西就是html該有的模樣,沒寫,插槽就是空殼子,啥都沒有。
OK,我們說有html模板的情況,就是父組件會往子組件插模板的情況,那到底插一套什么樣的樣式呢,這由父組件的html+css共同決定,但是這套樣式里面的內(nèi)容呢?

正因為作用域插槽綁定了一套數(shù)據(jù),父組件可以拿來用。于是,情況就變成了這樣:樣式父組件說了算,但內(nèi)容可以顯示子組件插槽綁定的。

我們再來對比,作用域插槽和單個插槽和具名插槽的區(qū)別,因為單個插槽和具名插槽不綁定數(shù)據(jù),所以父組件是提供的模板要既包括樣式由包括內(nèi)容的,上面的例子中,你看到的文字,“菜單1”,“菜單2”都是父組件自己提供的內(nèi)容;而作用域插槽,父組件只需要提供一套樣式(在確實用作用域插槽綁定的數(shù)據(jù)的前提下)。

下面的例子,你就能看到,父組件提供了三種樣式(分別是flex、ul、直接顯示),都沒有提供數(shù)據(jù),數(shù)據(jù)使用的都是子組件插槽自己綁定的那個人名數(shù)組。

父組件:


  1. <template>
  2. <div class="father">
  3. <h3>這里是父組件</h3>
  4. <!--第一次使用:用flex展示數(shù)據(jù)-->
  5. <child>
  6. <template slot-scope="user">
  7. <div class="tmpl">
  8. <span v-for="item in user.data">{{item}}</span>
  9. </div>
  10. </template>
  11. </child>
  12. <!--第二次使用:用列表展示數(shù)據(jù)-->
  13. <child>
  14. <template slot-scope="user">
  15. <ul>
  16. <li v-for="item in user.data">{{item}}</li>
  17. </ul>
  18. </template>
  19. </child>
  20. <!--第三次使用:直接顯示數(shù)據(jù)-->
  21. <child>
  22. <template slot-scope="user">
  23. {{user.data}}
  24. </template>
  25. </child>
  26. <!--第四次使用:不使用其提供的數(shù)據(jù), 作用域插槽退變成匿名插槽-->
  27. <child>
  28. 我就是模板
  29. </child>
  30. </div>
  31. </template>

子組件:


  1. <template>
  2. <div class="child">
  3. <h3>這里是子組件</h3>
  4. // 作用域插槽
  5. <slot :data="data"></slot>
  6. </div>
  7. </template>
  8. export default {
  9. data: function(){
  10. return {
  11. data: ['zhangsan','lisi','wanwu','zhaoliu','tianqi','xiaoba']
  12. }
  13. }
  14. }

結(jié)果如圖所示:

github

以上三個demo就放在GitHub了,有需要的可以去取。使用非常方便,是基于vue-cli搭建工程。

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

開發(fā)過程中積累的CSS樣式(持續(xù)更新)

seo達(dá)人

前言:平時寫頁面的時候有些樣式使用完發(fā)現(xiàn)沒過多久就忘記了,這篇文章主要是用來記錄開發(fā)過程中容易忘記的CSS樣式,與其總是去網(wǎng)上查,還不如一個一個記錄下來,雖然說之前的都沒有記錄,但是知識的累積不論什么時候開始做都不會晚的。



首先 記錄幾個好用的插件網(wǎng)站:



layDate日期與時間組件: https://www.layui.com/laydate/

Vant移動端插件庫: https://youzan.github.io/vant/#/zh-CN/intro

Element組件庫: https://element.eleme.cn/#/zh-CN/component/installation

Vue.js框架: https://cn.vuejs.org/v2/guide/

Bootstrap框架: https://v2.bootcss.com/index.html

菜鳥教程官網(wǎng): https://www.runoob.com/

w3school官網(wǎng): https://www.w3school.com.cn/

下面是遇到的一些想累積的css樣式:(內(nèi)容會隨時間累積的越來越多)



1、一個 div 中的內(nèi)容實現(xiàn)上下滑動效果(而不是超出body的高以后上下滑動):overflow:auto;

簡單的描述:body 中的一個 div 內(nèi),如果設(shè)置了固定的 height,而內(nèi)容的總 height 超出了 div 的高,則超出的部分就會被覆蓋,而想實現(xiàn)超出的部分變成滑動的效果而不被覆蓋,則用 overflow:auto; 實現(xiàn)。



2、修改 前端框架封裝好的css樣式: border-radius: 20px!important;(注意使用英文的 ! 嘆號)

簡單的描述:在開發(fā)過程中經(jīng)常使用一些前端框架(bootstrap,vue.js,laydate,Vant等等),在使用link導(dǎo)入css文件以后,發(fā)現(xiàn)有些css是在標(biāo)簽內(nèi)使用內(nèi)嵌的方式實現(xiàn)的,優(yōu)先級最高,那么我們怎么修改呢?

比如:css文件中的邊框弧度樣式為10px:border-radius: 10px;

我們想改成20px,則在后面加上 !important 即可:border-radius: 20px!important;



這篇文章主要是以后回頭復(fù)習(xí)或者忘記了的時候給我自己看的,但是如果恰好也幫助到了你,那是更加的有意義,在以后的開發(fā)過程中,該文章的內(nèi)容一定會累積的越來越多

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

產(chǎn)品設(shè)計核心三要素

資深UI設(shè)計者

先問一個問題:怎么樣衡量一個設(shè)計好與不好?工作中實踐越多次,越會發(fā)現(xiàn)華麗的設(shè)計稿并不是體現(xiàn)設(shè)計師專業(yè)能力的唯一標(biāo)準(zhǔn)。普通設(shè)計師和高級設(shè)計師區(qū)別在于,設(shè)計方案是否具備完整設(shè)計思路;設(shè)計對于業(yè)務(wù)有沒有真正的價值體現(xiàn);以及設(shè)計方案的推動落地的完整性到底有多少。設(shè)計越往后走,越考驗產(chǎn)品思維,設(shè)計思維,以及設(shè)計推動能力。這是產(chǎn)品設(shè)計師需要關(guān)注的核心三要素。


設(shè)計師在工作中接到設(shè)計需求會不自覺的第一時間想著如何去進(jìn)行視覺表達(dá),視覺表達(dá)確實非常重要,也是公司對于設(shè)計師的核心價值的定位之一,但視覺表達(dá)只是其中設(shè)計專業(yè)本職工作中的一個環(huán)節(jié)。設(shè)計師還要應(yīng)該能夠站在產(chǎn)品、設(shè)計、技術(shù)等不同維度去思考設(shè)計方案的可行性。產(chǎn)品打磨-視覺呈現(xiàn)-落地執(zhí)行,在這三個核心點里面設(shè)計師分別有不同的定位和價值所在。 


  一. 產(chǎn)品“雙標(biāo)”滿足   

產(chǎn)品打磨包含產(chǎn)品規(guī)劃,內(nèi)容組成,界面布局,交互梳理等等…所有環(huán)節(jié)的工作是為了符合產(chǎn)品最終的目標(biāo)。產(chǎn)品所有的能力會核心圍繞兩個點:1商業(yè)變現(xiàn) 2用戶需求滿足。這兩個目標(biāo)在產(chǎn)品執(zhí)行的環(huán)節(jié)有時候會有一些沖突,在產(chǎn)品打磨階段設(shè)計師通過怎樣的方式,做到既滿足產(chǎn)品商業(yè)目標(biāo)又滿足用戶體驗需求?可以按照以下幾個步驟進(jìn)行分析尋求切入點: 


Image title



這里用騰訊動漫付費(fèi)模塊舉例說明: 項目背景是騰訊動漫產(chǎn)品要做付費(fèi)體系升級設(shè)計,接到需求先有由產(chǎn)品源頭一步步深入,逐步展開設(shè)計方案的規(guī)劃。 


 01 產(chǎn)品目標(biāo)確認(rèn)  

通過對項目背景的解讀和產(chǎn)品方案的深入了解,以及總結(jié)當(dāng)前存在的一些問題,可以明確得到項目中產(chǎn)品核心目是什么。付費(fèi)升級核心原因是付費(fèi)轉(zhuǎn)化低,用戶付費(fèi)意愿不夠強(qiáng)烈。此次升級的核心目標(biāo)是促進(jìn)內(nèi)容消費(fèi),提升付費(fèi)率。 


Image title



 02 分析用戶路徑  

確認(rèn)目標(biāo)之后從哪個模塊兒開始進(jìn)行首要需要考慮的。對于現(xiàn)有現(xiàn)有功能的升級,建議核心從產(chǎn)品本身著手,可以根據(jù)用戶行為分析,獲取用戶常規(guī)使用路徑,找到用戶使用場景下的核心目的,從而去挖掘用戶在付費(fèi)路徑下的訴求點,根據(jù)訴求點找到付費(fèi)升級的觸點。這里我們羅列了用戶閱讀產(chǎn)品的路徑。 

Image title



 03 觀察用戶核心需求是否被滿足 

 用戶在每個場景下都會有“痛點”和“癢點”。比如在閱讀前,核心目是想快點看到漫畫內(nèi)容;閱讀過程中,想要及時宣泄對漫畫的故事情節(jié)的感受;閱讀后,希望找到更多相關(guān)內(nèi)容或者能夠和內(nèi)容有更多的互動。目前產(chǎn)品在這三個關(guān)鍵的路徑節(jié)點都存在一些問題,閱讀前對于付費(fèi)缺乏正向引導(dǎo),閱讀過程中互相行為較少,閱讀后沒有更多延展內(nèi)容可供消費(fèi)等。 


Image title



 04 洞察設(shè)計切入點  

根據(jù)用戶在閱讀 “前 中 后” 關(guān)鍵路徑的節(jié)點的不同情緒反饋,我們可以做出找到相應(yīng)情感滿足切入點,并且制定解決方案 


Image title



 05 制定設(shè)計方案  

將之前找到的設(shè)計情感切入點用交互和視覺的形式呈現(xiàn)出來,盡可能完整的表達(dá)清晰。下面展示是關(guān)于付費(fèi)升級優(yōu)化的完整視頻DEMO。整個方案采用趣味情感化形式為核心設(shè)計思路,逐步去引導(dǎo)用戶付費(fèi)。讓用戶在趣味互動中完成產(chǎn)品的商業(yè)轉(zhuǎn)化目標(biāo)。 


https://v.youku.com/v_show/id_XNDM0NDg1MzY2MA==.html


 二. 設(shè)計呈現(xiàn)的“差異化”   

視覺呈現(xiàn)是設(shè)計師們都比較擅長的工作,但不同專業(yè)高度要求下方案最終呈現(xiàn)出的效果是完全不一樣的。好的設(shè)計方案,需要在設(shè)計上做出明顯的“差異化”,這里的差異化是指要區(qū)別于常規(guī)輸出一般的水平。差異化的可以從多個點入手:


Image title



優(yōu)質(zhì)的設(shè)計美感

美感是作為設(shè)計師首先需要培養(yǎng)的技能之一,也是在后續(xù)職業(yè)生涯的一直需要用到的技能。設(shè)計師被神職化的很大一個原因就是因為設(shè)計師的美感比一般人要好,有懂得欣賞美、鑒別美、以及創(chuàng)造美的能力。單一從視覺層面,設(shè)計作品是合格品還是精品,最終取決于畫面的精美程度。項目不分大小,再小的一個項目都可以做出精致品質(zhì),這也是體現(xiàn)設(shè)計師專業(yè)度的核心衡量之一。


Image title



完整設(shè)計思路:

設(shè)計方案的完整性也能夠很好的設(shè)計師專業(yè)度的差異化,幾張圖的設(shè)計稿和一個有完整設(shè)計思路的設(shè)計方案在品質(zhì)上自然是明顯差別的。設(shè)計師不光需要將設(shè)計呈現(xiàn)出來,更需要有嚴(yán)謹(jǐn)?shù)脑O(shè)計思路并且表達(dá)出來讓受眾到你的設(shè)計想法。設(shè)計前期分析、中期執(zhí)行、后期落地以及迭代優(yōu)化,能夠讓設(shè)計師有意識的鍛煉和提升自己的設(shè)計思維,對于設(shè)計師能力提升有必然的幫助。 


Image title



獨(dú)特創(chuàng)意:

設(shè)計差異化呈現(xiàn)上,創(chuàng)意是一個非常好的切入點。行業(yè)大趨勢的前提下,現(xiàn)在同類產(chǎn)品越來越趨于同質(zhì)化,受眾使用產(chǎn)品的時候都會有一些常規(guī)認(rèn)知,關(guān)于功能的、交互操作的、內(nèi)容組成的等等,淘寶和京東、大眾和美團(tuán)、甚至QQ音樂和網(wǎng)易音樂在產(chǎn)品使用體驗上都有高度重合的地方,這些已經(jīng)在用戶心智中形成習(xí)以為常的認(rèn)知感受。如果能夠在用戶的常規(guī)認(rèn)知里,用創(chuàng)意手法呈現(xiàn)出超出他們預(yù)期的內(nèi)容使其驚喜,產(chǎn)品設(shè)計就會有明顯差異化體現(xiàn)。 


Image title



善用情感化:

具備美感的設(shè)計能讓作品看起來有高級感,但更為高級且有效的是能夠引起用戶情感共鳴的設(shè)計。設(shè)計是主觀的,對于設(shè)計每個人都有自己的想法,也正是因為主觀的設(shè)計感受,能讓設(shè)計在情感化打造方面可以有很多的嘗試方向。能夠引起受眾主觀情感上的共鳴和認(rèn)同的設(shè)計,會形成產(chǎn)品的核心記憶點之一。設(shè)計師對于情感化設(shè)計往往會有一些誤區(qū),認(rèn)為圖形可愛,色彩羨慕,動效流暢且能夠形成一套視覺體系,就能夠算情感設(shè)計。真正的情感設(shè)計是需要從用戶角度出發(fā),挖掘用戶的認(rèn)知領(lǐng)域和喜歡,從而去進(jìn)行符合用戶情感訴求的呈現(xiàn)。 


Image title


三. 方案推動的效能管理 

 

設(shè)計方案輸出只是整個產(chǎn)品生產(chǎn)流程中的一個核心環(huán)節(jié),產(chǎn)品上線后體驗如何最終取決于落地實現(xiàn)的程度。在方案落地支持過程中,效率協(xié)調(diào)和實現(xiàn)能力是保證設(shè)計方案貫徹一致執(zhí)行的關(guān)鍵因素:


 協(xié)作  

產(chǎn)品設(shè)計師工作協(xié)調(diào)分為內(nèi)部協(xié)作和外部協(xié)作。內(nèi)部協(xié)作即設(shè)計師之間的溝通協(xié)同,主要內(nèi)容是如何保持設(shè)計語言一致性,除了制定設(shè)計規(guī)范,還可以建立公共控件庫,線上調(diào)用。控件庫能夠使設(shè)計師協(xié)作無學(xué)習(xí)成本,設(shè)計師輸出設(shè)計稿效率也能夠大大提升,同時保一致性。


外部協(xié)作主要是和下游的技術(shù)同事直接的工作對接,設(shè)計方案的交接方式以及開發(fā)獲取信息的效率很關(guān)鍵。在開發(fā)接收設(shè)計方案的時候,盡能力降低獲取成本以及理解成本。比如設(shè)計稿的標(biāo)注,在標(biāo)注上設(shè)計師一般會花很長時間,開發(fā)也需要逐步查看,偶爾還會有標(biāo)注遺漏的地方。我們團(tuán)隊會直接采用插件,設(shè)計稿及時同步,并且開發(fā)可以自己隨時查看每個元素的標(biāo)注信息,便捷。


這里推薦兩款協(xié)調(diào)軟件:一款是InVision可以在sketch里進(jìn)行控件協(xié)同調(diào)用,所有想用的元素直接源文件調(diào)用,不需要再問同事要源文件!另一款是Zeplin技術(shù)同學(xué)可以直接查看元素屬性以及間距等,設(shè)計師解放雙手不再需要標(biāo)注!


Image title



官網(wǎng)鏈接: 

https://login.invisionapp.com/auth/sign-in   

https://zeplin.io/


實現(xiàn)能力   

專業(yè)技術(shù)之間的壁壘,也會成為設(shè)計方案實現(xiàn)的阻力。同樣的界面,設(shè)計人員用設(shè)計軟件實現(xiàn),技術(shù)人員用邏輯代碼實現(xiàn),實現(xiàn)的方式和成本存在很大的差異性,所以往往設(shè)計師認(rèn)為很簡單的需求在開發(fā)層面的確非常難實現(xiàn)。當(dāng)然,不是所有需求都是無解的,設(shè)計師在技術(shù)實現(xiàn)層面還是可以做一些事情:


01 方案前置溝通

設(shè)計一個新的功能的時候,如果有非常規(guī)的設(shè)計方案,可以提前和技術(shù)人員溝通實現(xiàn)的難易程度,讓技術(shù)人員有前期預(yù)判和預(yù)演的時間。并且,可以將設(shè)計做成簡易DEMO方便技術(shù)人員快速理解,避免雙方存在信息不對等的情況。


02 搭建開發(fā)控件庫

開發(fā)控件庫和設(shè)計規(guī)范一樣,是最基礎(chǔ)但應(yīng)用最為頻繁的模塊兒。開發(fā)控件庫可以將最基礎(chǔ)的元素形成固有規(guī)范,所有開發(fā)實現(xiàn)都用同一套規(guī)范,以確保實現(xiàn)的高度一致性,同時也能夠提升實現(xiàn)效率和設(shè)計還原。設(shè)計可以輔助開發(fā)一起制定開發(fā)控件庫,確??丶旌驮O(shè)計規(guī)格的一致性。


03 尋求技術(shù)語言共通性

盡量將設(shè)計方案轉(zhuǎn)化為技術(shù)能夠理解和復(fù)用的形式進(jìn)行對接。除了靜態(tài)設(shè)計稿的標(biāo)注,設(shè)計和技術(shù)實現(xiàn)最大的難點在于動態(tài)交互的實現(xiàn)上,對于動態(tài)設(shè)計,將設(shè)計方案轉(zhuǎn)換為代碼文件交付給技術(shù)實現(xiàn),這樣能確保功能的正常實現(xiàn)同時減少后期設(shè)計還原性的偏差。


以上初步總結(jié)的關(guān)于產(chǎn)品設(shè)計師在設(shè)計過程中從前期產(chǎn)品規(guī)劃到中期設(shè)計執(zhí)行再到后期開發(fā)落地應(yīng)該注意的一些核心點:

第一條,設(shè)計方案既要滿足產(chǎn)品目標(biāo)又同時要兼顧用戶體驗;

第二條,優(yōu)秀的設(shè)計師,會保持設(shè)計方案的“差異化”;

第三條,設(shè)計師職責(zé)除了確保設(shè)計方案完整性,更重要的是推動設(shè)計方案的完整落地。


在產(chǎn)品設(shè)計過程中,設(shè)計師需要關(guān)注還有很多關(guān)鍵點,這里也歡迎大家一起補(bǔ)充交流,正是這些關(guān)鍵點,將設(shè)計師的思維逐步打開,使其成為一個具有全鏈路思維的設(shè)計人才。 

文章來源:UI中國

JS--普通數(shù)字格式與會計金額格式之間的轉(zhuǎn)換

seo達(dá)人

普通數(shù)字轉(zhuǎn)會計金額格式(保留兩位小數(shù))

我們可以用數(shù)字的toLocaleString()方法將普通數(shù)字轉(zhuǎn)為會計金額格式,但是這種方式無法保留兩位小數(shù)(四舍五入),如果是整數(shù)或者小數(shù)長度只有一位的時候無法自動補(bǔ)0



例如:





思路:

利用toLocaleString()以及toFixed()先對數(shù)字進(jìn)行一個轉(zhuǎn)換得到最多保留了2位小數(shù)的金額,然后判斷數(shù)字是為整數(shù)還是帶有小數(shù),如果帶有小數(shù)則進(jìn)行切割,判斷小數(shù)長度為1時自動補(bǔ)0



// 普通數(shù)字轉(zhuǎn)會計金額格式 第一種

    function toThousandsFormates(num) {

        // 判斷傳進(jìn)來的數(shù)字是否為非空數(shù)字

       if (!isNaN(parseFloat(num))) {

            var reg = /./g

            var newNum = Number(Number(num).toFixed(2)).toLocaleString()

            // 判斷轉(zhuǎn)換后的數(shù)字是否帶有小數(shù)

            if (reg.test(newNum)) {

                var numArr = newNum.split('.')

                // 判斷小數(shù)點后數(shù)字長度為1,則自動補(bǔ)0

                numArr[1] = numArr[1].length === 1 ? numArr[1] + '0' : numArr[1]

                return numArr.join('.')

            } else {

                // 整數(shù)直接在后面補(bǔ)上0.00

                return newNum + '.00'

            }



        } else {

            return ''

        }

    }

    console.log(toThousandsFormates('0')); // 0.00

    console.log(toThousandsFormates('')); // ''

    console.log(toThousandsFormates(966)); // 966.00

    console.log(toThousandsFormates(966.3)); // 966.30

    console.log(toThousandsFormates(9669228.55)); // 9,669,228.55

    console.log(toThousandsFormates(96566.56954)); // 96,566.57



經(jīng)過查閱資料后,發(fā)現(xiàn)toLocaleString()它里面自帶屬性可以檢查到最少保留了幾位小數(shù),不夠自動補(bǔ)0,這樣我們上面的代碼其實可以更加簡單,如下:

// 普通數(shù)字轉(zhuǎn)會計金額格式 第二種

function toThousandsFormates2(num) {

    // 判斷傳進(jìn)來的數(shù)字是否為非空數(shù)字

    if (!isNaN(parseFloat(num))) {

        var newNum = Number(Number(num).toFixed(2)).toLocaleString('zh', { minimumFractionDigits: 2 })

        return newNum



    } else {

        return ''

    }

}



console.log(toThousandsFormates2('0')); // 0.00

console.log(toThousandsFormates2('')); // ''

console.log(toThousandsFormates2(966)); // 966.00

console.log(toThousandsFormates2(966.3)); // 966.30

console.log(toThousandsFormates2(9669228.55)); // 9,669,228.55

console.log(toThousandsFormates2(96566.56954)); // 96,566.57



// 結(jié)果一模一樣



會計金額格式轉(zhuǎn)普通數(shù)字(利用正則)

// 會計金額格式轉(zhuǎn)為普通數(shù)字

    function rMoney(num) {

        return parseFloat(num.replace(/[^\d\.-]/g, ''))

    }

    console.log(rMoney('96,566.57')); // 96566.57

    console.log(rMoney('966.30')); // 966.3

    console.log(rMoney('9,669,228.55')); // 9669228.55

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

交互手勢的容錯性和邏輯性

資深UI設(shè)計者

交互手勢是用戶操作的重要部分,交互手勢的設(shè)計好壞非常影響用戶體驗,那么,交互手勢的設(shè)計上對于容錯性和邏輯性需要注意什么?

隨著用戶體驗被愈發(fā)的重視,更多的 APP 偏向于使用多手勢優(yōu)化用戶的操作流程,降低使用阻力。

點擊某個確定的按鈕的手勢操作雖然被普遍使用并被用戶熟知,但是增加更快捷的手勢操作可以大大增大操作熱區(qū),提高操作效率,如下圖。

交互手勢的容錯性和邏輯性

然而,我們可以發(fā)現(xiàn)由于不同產(chǎn)品的設(shè)計師對于用戶體驗的理解不同、交互層面的思考不同,導(dǎo)致設(shè)計的交互手勢也不同。

有時同一種操作在不同的 APP 中交互手勢也是不統(tǒng)一的,這無疑增加了用戶的學(xué)習(xí)成本和記憶成本。

舉個例子,iOS 端的得到和有書的播放頁的打開和關(guān)閉方式。

得到有兩種方式打開和關(guān)閉頁面,用戶可以通過點擊控件或上滑控件打開播放頁,通過點擊收起按鈕或下拉頁面關(guān)閉播放頁。但是有書只有一種方式打開和關(guān)閉,用戶只能通過點擊控件打開播放頁,通過點擊返回圖標(biāo)關(guān)閉播放頁。

這讓習(xí)慣了使用得到的我去使用有書時,感覺非常別扭,每次都嘗試用得到的手勢去操作但是都失敗了,失敗后我下一次并沒有記住仍然用手勢去操作,如此反復(fù)令我相當(dāng)沮喪。

交互手勢的容錯性和邏輯性

容錯性

容錯性是一個很大的話題,今天我們僅僅在交互手勢層面上討論。

上面的例子中,有書并沒有設(shè)計滑動手勢去打開和關(guān)閉播放頁,那么我以我的經(jīng)驗去進(jìn)行的滑動滑操作在有書這個產(chǎn)品中就是錯誤的和不被產(chǎn)品識別的。但是這種手勢又廣泛存在于大量的音頻播放 APP 中,如喜馬拉雅、荔枝 FM 等。

一旦用戶從這些 APP 遷移到了有書,本來養(yǎng)成的操作習(xí)慣在有書就失效了,用戶就會感覺“這個 APP 很難用,用起來很不舒服”,進(jìn)而可能放棄有書轉(zhuǎn)而投向其他產(chǎn)品懷抱。

與手勢設(shè)計類似,這也是為什么現(xiàn)在的同種類型的 APP 的信息架構(gòu)設(shè)計越來越同質(zhì)化,當(dāng)我們打開淘寶、天貓、京東時我們有時感覺就像是同一個 APP ,本質(zhì)上也是為了降低用戶的遷移、記憶和學(xué)習(xí)成本。

如下圖所示,提高手勢的容錯性對用戶的意義。

交互手勢的容錯性和邏輯性

很多優(yōu)秀的產(chǎn)品考慮到了上述問題,設(shè)計了多手勢來優(yōu)化用戶體驗。

舉個例子,在 APP Store 的首頁點擊一個推薦卡片后進(jìn)入詳情頁,由于詳情頁是直接由卡片放大轉(zhuǎn)場的,不同于傳統(tǒng)的新頁面右側(cè)進(jìn)入和從底部彈出。

在用戶的使用習(xí)慣和認(rèn)知中新頁面如果從右側(cè)進(jìn)入就可以通過右滑返回,從底部彈出的話就可以下拉返回。因此,當(dāng)用戶面對卡片放大進(jìn)入新頁面這種全新交互時可能會疑惑如何返回,對此理解不同的用戶可能會嘗試右滑,也可能嘗試下拉。

APP Store 的設(shè)計在此就有很好的容錯性,用戶可以通過三種方式返回首頁,分別是、右滑返回、下拉返回和點擊叉號返回,這不但降低了用戶的記憶和學(xué)習(xí)成本,也便于不同習(xí)慣的用戶使用。

交互手勢的容錯性和邏輯性

針對不同的場景,手勢的使用也會有不同。

一個很好的案例是知乎的評論:知乎的評論的關(guān)閉方式有三種,分別是下拉、右滑和點擊叉號。

用戶觀看評論的場景有兩種,第一種是只想看一下精選評論然后關(guān)閉,第二種是被評論吸引后一直往下看。當(dāng)用戶單手操作不方便點擊叉號時,下拉對應(yīng)的是第一種用戶;右滑對應(yīng)的是第二種用戶,不管用戶看了多少屏的評論,隨時可以通過右滑關(guān)閉評論(因為用戶翻閱了很多屏評論后需要下拉到第一條評論時,下拉關(guān)閉評論手勢才會生效,所以第二種用戶一般不使用下拉去關(guān)閉評論)。

可能你會心生疑惑:“第一種用戶也可以使用右滑來關(guān)閉評論呀”,確實可以,但是對于人的操作習(xí)慣來說,上下滑動會比左右滑動更方便。

交互手勢的容錯性和邏輯性

還值得討論的是蘋果自 iPhone 6s 開始加入的新交互方式 3D Touch,它允許用戶通過更大力度的重按呼出情景菜單快捷地使用高頻功能而不用先打開 APP,對于追求效率的用戶來說簡直不要更方便,但是對于不支持 3D Touch 的機(jī)型則無法使用情景菜單。

因此,在生活中我發(fā)現(xiàn)這樣的現(xiàn)象,很多使用慣了3D Touch 的用戶換到無 3D Touch 的蘋果機(jī)型后很不習(xí)慣,總是嘗試去重按但是是無效的。

其實在很多安卓手機(jī)上也有情景菜單這一功能,它巧妙地將卸載也加到了情景菜單中,因此用戶只需要通過長按就可以獲得所有需要的功能,而不是像蘋果那樣長按是卸載而重按是情景菜單。

我猜測蘋果為了適配所有機(jī)型,提高容錯性,從今年的發(fā)布會的 iPhone 11 和iPhone 11 pro 開始,取消了 3D Touch,轉(zhuǎn)而使用 Haptic Touch (有震動反饋的長按)代替。當(dāng)你長按某個圖標(biāo)時,感受到震動后松開,即可呼出二級菜單;如果震動后仍不松開,則進(jìn)入到卸載 APP 時的抖動狀態(tài),使得之后的即使不支持 3D Touch的機(jī)型可以使用便捷的情景菜單了。

對于不支持 3D Touch 的老款機(jī)型會不會在 iOS 13 更新后也可以使用 Haptic Touch 呢?

如果一致統(tǒng)一的話,容錯性將大大提高,我們將拭目以待。

不僅僅是 iOS ,Android 的版本 Android 10經(jīng)歷了 6 個測試版迭代后正式發(fā)布,我們發(fā)現(xiàn)交互手勢是 Android 10 的一個巨大亮點。Android 10 在第三版內(nèi)測系統(tǒng)開始引入全局手勢操作,用戶啟用后,屏幕底部便不會再出現(xiàn)虛擬按鍵和導(dǎo)航欄,只會剩下一個指示條,上滑返回主屏、側(cè)滑返回上一層的操作邏輯也均和 iOS 保持一致。

這可能標(biāo)志著安卓手機(jī)一直以來在國內(nèi)各家廠商的各種創(chuàng)新手勢的割裂生態(tài)中即將重歸統(tǒng)一,并和 iOS 保持一致。

這種妥協(xié)將大大提高在用戶使用一款新安卓手機(jī)時的容錯性,同時降低了今后用戶在兩大系統(tǒng)之間的遷移成本。

邏輯性

再談?wù)勥壿嬓裕诮换ナ謩莸膶用嫔?,如果用戶能夠通過某個手勢進(jìn)行某個操作后,按照邏輯,用戶也可以通過反向的手勢或?qū)?yīng)的手勢進(jìn)行逆向操作。

比如,在微信首頁下拉調(diào)出小程序頁面,之后可以通過上拉返回首頁。點擊加號呼出更多操作,再次點擊加號收起更多操作。

如果違背了用戶的心理模型和邏輯性,用戶就會感覺到混亂和不適。

這里舉一個反例, Uki 的個人主頁可以通過點擊或下拉底部的固定底板收起更多信息,但是收起后只能通過點擊展開更多個人信息而不能上拉,不符合邏輯與用戶的心理模型。

交互手勢的容錯性和邏輯性

如下圖所示,邏輯性對用戶的意義。

交互手勢的容錯性和邏輯性

有的時候,我們會發(fā)現(xiàn)為了提高容錯性,我們會犧牲一部分邏輯性。

就像上文提到的知乎關(guān)閉評論彈出框,邏輯上它是從底部彈出的,但是不但能夠下拉關(guān)閉還可以右滑關(guān)閉。盡管右滑關(guān)閉有些違背用戶的心理模型,但是確實給用戶帶來了很多操作上的便捷。

如何設(shè)計

1. 是否需要加入多手勢操作的考慮因素

我們需要考慮的因素包括使用頻率、危險程度和特殊體驗。

  1. 使用頻率:當(dāng)一個功能的使用頻率足夠高時,我們加入多手勢操作去提高用戶操作效率才是有意義的。一個低頻的功能的特殊手勢操作很容易被用戶遺忘。
  2. 危險程度:如果一個操作不可撤銷且存在危險性質(zhì),我們最好不要加入多手勢操作。此時我們需要用戶更加專注,如果加入多手勢操作可能會增加誤操作的概率。
  3. 特殊體驗:當(dāng)我們需要加入特殊的模擬體驗時,此時我們可以加入多手勢操作。如探探左滑無感右滑喜歡,給用戶帶來的“翻牌子”感覺是點擊操作無法替代的。QQ 閱讀下拉擬物繩燈進(jìn)行日間和夜間模式切換,這種存在我們記憶中的交互方式能夠喚起我們的情感。

2. 評估所選手勢的考慮因素

1)考慮不同平臺的硬件系統(tǒng)和操作系統(tǒng)特性

由于硬件與操作系統(tǒng)差異,iOS 系統(tǒng)支持很多手勢,但是安卓系統(tǒng)在手勢支持方面就不如 iOS 豐富。

安卓硬件設(shè)備的差異比較大,不同安卓手機(jī)廠商會在安卓系統(tǒng)的基礎(chǔ)上自定義系統(tǒng)的手勢操作,因此對于手勢的支持也有較大的差異。對于這種情況我們需要熟悉相應(yīng)平臺的規(guī)范,做到心中有數(shù)。

2)考慮所選的手勢的學(xué)習(xí)成本和記憶成本,用戶是否已經(jīng)被教育

如下圖所示,盡管設(shè)備支持的手勢數(shù)量多不勝數(shù),但是日常使用 APP 時,大部分用戶習(xí)慣使用的手勢很少,比如單擊、雙擊、滑動、上拉、下拉、雙指擴(kuò)張和收縮等。除此之外的手勢教育成本和學(xué)習(xí)成本很高。

一般比較通用的功能是沒有必要在此處創(chuàng)新的,但是如果一些特殊的操作確實需要加入時,我們就需要考慮下面的問題。

交互手勢的容錯性和邏輯性

a. 如果沒有教育成熟,考慮加入教學(xué)或搭配簡易的操作方式

對于我們需要加入的手勢操作當(dāng)前用戶并未被教育成熟時,我們需要考慮加入手勢教學(xué),具體的手勢教學(xué)類型下一部分會詳細(xì)討論。

然而,大部分情況下用戶的記憶是短期的,教學(xué)內(nèi)容可能會被快速遺忘,下次用戶使用 APP 時仍然不會使用特殊手勢。此時我們應(yīng)該將一些比較難以記憶的手勢操作搭配一個簡單的手勢操作。

比如 QQ 閱讀的下拉擬物繩燈切換夜間模式的手勢操作設(shè)計,其考慮到了有些用戶在現(xiàn)實生活中并未見過擬物繩燈,并不知道是要進(jìn)行下拉才能觸發(fā)操作。因此,QQ 閱讀貼心地搭配了一個簡單的點擊操作,用戶通過點擊繩燈也可以切換夜間模式,如下圖。

交互手勢的容錯性和邏輯性

b. 考慮所選手勢是否可能導(dǎo)致沖突和誤操作,如果導(dǎo)致了,考慮如何避免和折中

最常見的手勢沖突情況就是 APP 的手勢與操作系統(tǒng)的全局手勢沖突。

解決方案有兩個,一是避免設(shè)計與全局手勢一致的手勢操作,例如 iOS 的在屏幕邊緣右滑返回、全面屏機(jī)型的底部上滑退出應(yīng)用等全局手勢操作;二是仍然設(shè)計與全局手勢沖突的操作,但是將全局手勢部分禁用或以其他的方式區(qū)分開。

如下圖有書播放頁的案例,由于進(jìn)度條滑動控件過于靠左,導(dǎo)致使用 iOS 全局右滑返回手勢時有時會產(chǎn)生誤操作,即本來想要右滑返回卻不小心滑動了進(jìn)度條。

這種情況下我們可以標(biāo)注一個右滑手勢禁用區(qū)域給開發(fā)工程師說明情況,將此情況避免掉即可。

交互手勢的容錯性和邏輯性

誤操作指的是,我們設(shè)計的手勢操作與 APP 內(nèi)的其他操作或系統(tǒng)全局手勢操作接近導(dǎo)致用戶觸發(fā)了非預(yù)期的操作。比如 iOS 端的知乎被吐槽的一個右滑返回手勢操作,經(jīng)過研究發(fā)現(xiàn),由于 iOS 端的知乎在瀏覽回答的頁面設(shè)計的右滑返回的熱區(qū)過大,導(dǎo)致用戶上滑瀏覽的時候如果手指的滑動角度變化幅度過大一不小心就觸發(fā)了右滑返回,再次進(jìn)入回答后又需要翻頁很久才能找到之前離開的地方,很影響體驗。

我覺得知乎可以減少熱區(qū),將熱區(qū)調(diào)整為 iOS 全局的右滑返回區(qū)域即可,如下圖所示。

當(dāng)然,產(chǎn)品設(shè)計需要平衡與取舍,如果減少了熱區(qū)是否會影響其他用戶的體驗還需要考慮和調(diào)研,兩者并無絕對的對錯

交互手勢的容錯性和邏輯性

3. 讓用戶了解并使用新手勢

當(dāng)新手勢無法直接讓用戶感知時,我們需要加入一些手勢教學(xué)幫助用戶快速上手使用。

1)手勢教學(xué)方式

a. 浮層和動畫引導(dǎo)使用靜態(tài)或動態(tài)的手勢圖片或氣泡示例告訴用戶使用哪種手勢進(jìn)行操作

相比于靜態(tài),動態(tài)比靜態(tài)更為直觀和易學(xué)。

交互手勢的容錯性和邏輯性

b. 內(nèi)容隱喻通過微妙的視覺線索暗示用戶此處可以通過某種手勢進(jìn)行操作

由于教學(xué)內(nèi)容難免具有干擾性,對于高級用戶來說是不必要的,但是對于初級用戶又是必要的,因此以這種內(nèi)容暗示的方式使教學(xué)極為輕量化,在低干擾的情況下使得用戶學(xué)習(xí)了手勢操作。

如下圖,嗶哩嗶哩在打開第一篇文章時會平移顯示下一篇文章的框架,暗示用戶可以通過左右滑動切換文章。

再比如陌陌在打開點點功能時,會在用戶進(jìn)入頁面的時候播放一個動畫,暗示有很多卡片疊加在了一起,用戶可以通過滑動切換卡片。

交互手勢的容錯性和邏輯性

2)教學(xué)的出現(xiàn)時機(jī)

a. 操作前當(dāng)產(chǎn)品中設(shè)計了不容易感知的新手勢,在用戶操作前,通過教學(xué)讓用戶了解和學(xué)習(xí)新的手勢。

b. 錯誤操作后對于一些與用戶的心理模型和習(xí)慣不一致的手勢,提前預(yù)測用戶可能輸入的錯誤手勢,在用戶錯誤操作后進(jìn)行提示,規(guī)范用戶的操作方式。

如下圖,由于知乎舊版本是通過左右滑動切換回答的,新版本調(diào)整為上下滑動后,需要糾正用戶使用習(xí)慣。因此,當(dāng)用戶仍然使用左右滑動時,會出現(xiàn)浮層提示用戶正確的手勢進(jìn)行教學(xué)。

交互手勢的容錯性和邏輯性

結(jié)語

以上是日常思考和總結(jié),有不恰當(dāng)之處歡迎指出。希望本文在大家進(jìn)行手勢設(shè)計的過程中能夠幫助做出合理的決策。

文章來源:人人都是產(chǎn)品經(jīng)理 

nginx配置rewrite的用法詳解

seo達(dá)人

文章目錄

rewrite在if中的用法

rewrite中break和last的用法

1.break和last在location{}外部時

2.break和last在location{}內(nèi)部時

3.break和last用法總結(jié)

return的用法

rewrite的語法規(guī)則

rewrite應(yīng)用實例

1.域名跳轉(zhuǎn)(域名重定向)

2.http跳轉(zhuǎn)https

3.跳轉(zhuǎn)二級目錄

4.動靜態(tài)請求分離

5.防盜鏈配置

6.偽靜態(tài)(將靜態(tài)頁面重寫為動態(tài))

7.多個if并用

rewrite在if中的用法

格式:if (條件判斷) { 具體的rewrite規(guī)則 }



if條件判斷語句由Nginx內(nèi)置變量、邏輯判斷符號和目標(biāo)字符串三部分組成。

其中,內(nèi)置變量是Nginx固定的非自定義的變量,如,$request_method, $request_uri等。

邏輯判斷符號,有=, !=, ~, ~, !~, !~

!表示相反的意思,~為匹配符號,它右側(cè)為正則表達(dá)式,區(qū)分大小寫,而~為不區(qū)分大小寫匹配。

目標(biāo)字符串可以是正則表達(dá)式,通常不用加引號,但表達(dá)式中有特殊符號時,比如空格、花括號、分號等,需要用單引號引起來。

1

2

3

4

5

示例1:當(dāng)http請求方法為post時,返回403狀態(tài)碼



if ($request_method = POST)

{

    return 403; 

}

1

2

3

4

示例2:通過瀏覽器標(biāo)識匹配關(guān)鍵字,禁止IE瀏覽器訪問



if ($http_user_agent ~
MSIE) 

{

    return 403;

}

1

2

3

4

限制多個瀏覽器:



if ($http_user_agent ~ "MSIE|firefox|Chrome")

{

    return 403;

}

1

2

3

4

示例3:當(dāng)請求的文件不存在時,進(jìn)行重定向或return狀態(tài)碼等處理操作



if(!-f $request_filename)

{

    rewrite 語句;

}

1

2

3

4

示例4:判斷uri中某個參數(shù)的內(nèi)容



if($request_uri ~
'gid=\d{6,8}/') 

{

    rewrite 語句;

}

1

2

3

4

\d表示數(shù)字,{6,8}表示數(shù)字出現(xiàn)的次數(shù)是6到8次,當(dāng)uri中g(shù)id參數(shù)的值包含6-8個數(shù)字那么執(zhí)行rewrite語句



rewrite中break和last的用法

兩個指令用法相同,但含義不同,需要放到rewrite規(guī)則的末尾,用來控制重寫后的鏈接是否繼續(xù)被nginx配置執(zhí)行(主要是rewrite、return指令)。



1.break和last在location{}外部時

測試示例:



server{

    listen 80; 

    server_name test.com;

    root /data/wwwroot/test.com;



    rewrite /1.html /2.html;

    rewrite /2.html /3.html;

}

1

2

3

4

5

6

7

8

請求1.html文件時,會被重定向到2.html,然后被重定向到3.html,最后返回的文件為3.html



示例1:在rewrite 指令后面添加break



server{

    listen 80; 

    server_name test.com;

    root /data/wwwroot/test.com;



    rewrite /1.html /2.html break;

    rewrite /2.html /3.html;

}

1

2

3

4

5

6

7

8

請求1.html文件時,會被重定向到2.html,然后直接返回2.html,break在此處的作用就是當(dāng)匹配第一個rewrite指令成功時,不執(zhí)行后面的rewrite指令



示例2:當(dāng)break后面還有l(wèi)ocation{}的情況



server{

    listen 80; 

    server_name test.com;

    root /data/wwwroot/test.com;



    rewrite /1.html /2.html break;

    rewrite /2.html /3.html;

    location /2.html {

        return 403;

    }

}

1

2

3

4

5

6

7

8

9

10

11

請求1.html文件時,會返回403狀態(tài)碼,當(dāng)1.html被重定向到2.html時,break不會匹配后面的rewrite規(guī)則,但條件2.html匹配location{}定義的文件2.html,所以會執(zhí)行return 403


以上兩個示例中,將break換成last效果一樣



2.break和last在location{}內(nèi)部時

測試示例:



server{

    listen 80; 

    server_name test.com;

    root /data/wwwroot/test.com;

    

    location / {

        rewrite /1.html /2.html;

        rewrite /2.html /3.html;

    }

    location /2.html

    {

        rewrite /2.html /a.html;

    }

    location /3.html

    {

        rewrite /3.html /b.html;

    }

}

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

請求1.html,會經(jīng)過兩次重定向到3.html,3.html又剛好匹配location /3.html{},所以返回b.html,當(dāng)請求2.html時,會直接返回a.html,因為location /2.html {} 更精準(zhǔn),優(yōu)先匹配



示例1:在rewrite后面添加break



server{

    listen 80; 

    server_name test.com;

    root /data/wwwroot/test.com;

    

    location / {

        rewrite /1.html /2.html break;

        rewrite /2.html /3.html;

    }

    location /2.html

    {

        rewrite /2.html /a.html;

    }

    location /3.html

    {

        rewrite /3.html /b.html;

    }

}

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

請求1.html,會返回2.html,不會返回a.html,當(dāng)break再location {} 內(nèi)部時,遇到break后,當(dāng)前l(fā)ocation{} 以及后面的location{} 的指令都不再執(zhí)行



示例2:在rewrite后面添加last



server{

    listen 80; 

    server_name test.com;

    root /data/wwwroot/test.com;

    

    location / {

        rewrite /1.html /2.html last;

        rewrite /2.html /3.html;

    }

    location /2.html

    {

        rewrite /2.html /a.html;

    }

    location /3.html

    {

        rewrite /3.html /b.html;

    }

}

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

請求1.html時,會返回a.html,在location {} 內(nèi)部遇到last,當(dāng)前l(fā)ocation {}中剩下的指令不會再執(zhí)行,但被重定向的url會重新匹配一遍location {}



3.break和last用法總結(jié)

1.當(dāng)rewrite規(guī)則在location{}外,break和last作用一樣,遇到break或last后,其后續(xù)的rewrite/return語句不再執(zhí)行。但后續(xù)有l(wèi)ocation{}的話,還會近一步執(zhí)行l(wèi)ocation{}里面的語句,前提是請求能匹配該location

2.當(dāng)rewrite規(guī)則在location{}里,遇到break后,本location{}與其他location{}的所有rewrite/return規(guī)則都不再執(zhí)行

3.當(dāng)rewrite規(guī)則在location{}里,遇到last后,本location{}里后續(xù)rewrite/return規(guī)則不執(zhí)行,但重寫后的url再次從頭匹配所有l(wèi)ocation



return的用法

該指令一般用于對請求的客戶端直接返回響應(yīng)狀態(tài)碼。在該作用域內(nèi)return后面的所有nginx配置都是無效的,可以使用在server、location以及if配置中,除了支持跟狀態(tài)碼,還可以跟字符串或者url鏈接。



示例1:直接返回狀態(tài)碼



server{

    listen 80;

    server_name www.test.com;

    return 403;

    rewrite www.test.net;  

}

1

2

3

4

5

6

訪問時,直接返回403狀態(tài)碼,return返回內(nèi)容后,后面的配置rewrite不會執(zhí)行



示例2:當(dāng)return在if 判斷中時



server {

.....



if ($request_uri ~ ".password|.bak")

{

    return 404;

    rewrite /(.*) /index.html;  

}

.....

}

1

2

3

4

5

6

7

8

9

10

請求的文件包含.password或.bak時,直接返回404,rewrite不會執(zhí)行,但if {}外的配置會繼續(xù)執(zhí)行,return只在當(dāng)前作用域中生效



示例3:返回字符串



server{

    listen 80;

    server_name www.test.com;

    return 200 "hello";

}

1

2

3

4

5

返回字符串必須加上狀態(tài)碼,否則會報錯



示例4:返回nginx變量



location /1.html {

    return 200 "$host $request_uri";

}

1

2

3

示例5:返回url



server{

    listen 80;

    server_name www.test.com;

    return http://www.test.com/index2.html;

}

1

2

3

4

5

返回url時,必須以http://或https://開頭



示例6:返回html代碼



if ($http_referer ~ 'baidu.com') 

{

    return 200 "<html><script>window.location.href='//$host$request_uri';</script></html>";

}

1

2

3

4

當(dāng)網(wǎng)站被黑了的時候,從百度點進(jìn)網(wǎng)站是鏈接都會跳轉(zhuǎn)到其他網(wǎng)站,可以使用該方法暫時處理

注意:return http://$host$request_uri; 在瀏覽器中會提示"重定向的次數(shù)過多"



rewrite的語法規(guī)則

格式:rewrite regex replacement [flag]



rewrite 配置可以在server、location以及if配置段內(nèi)生效



regex 是用于匹配URI的正則表達(dá)式,其不會匹配到$host(域名)



replacement 是目標(biāo)跳轉(zhuǎn)的URI,可以以http://或者h(yuǎn)ttps://開頭,也可以省略掉$host,直接寫$request_uri部分



flag 用來設(shè)置rewrite對URI的處理行為,其中有break、last、rediect、permanent,其中break和last在前面已經(jīng)介紹過,rediect和permanent的區(qū)別在于,前者為臨時重定向(302),而后者是永久重定向(301),對于用戶通過瀏覽器訪問,這兩者的效果是一致的。

但是,對于搜索引擎爬蟲來說就有區(qū)別了,使用301更有利于SEO。所以,建議replacemnet是以http://或者h(yuǎn)ttps://開頭的,flag使用permanent。



示例1:域名跳轉(zhuǎn)



location / {

    rewrite /(.*) http://www.test.com/$1 permanent;

}

1

2

3

.*為正則表達(dá)式,表示uri,用()括起來,在后面的uri中可以調(diào)用它,第一次出現(xiàn)的()用$1調(diào)用,第二次出現(xiàn)的()用$2調(diào)用,以此類推。



示例2:域名跳轉(zhuǎn)的第二種寫法



location / {

    rewrite /. http://www.test.com$request_uri permanent;

}

1

2

3

示例3:文件跳轉(zhuǎn)



server{

    listen 80;

    server_name www.test.com;

    root /data/wwwroot/test.com;

    index index.html;

    if ($request_uri !~ '^/web/')

    {

        rewrite /(.
) /web/$1 redirect;

    }

}

1

2

3

4

5

6

7

8

9

10

將uri請求的文件重定向到web/目錄中去尋找



錯誤寫法1:



server{

    listen 80;

    server_name www.test.com;

    root /data/wwwroot/test.com;

    index index.html;

    rewrite /(.*) /web/$1 redirect;

}

1

2

3

4

5

6

7

這樣寫會反復(fù)循環(huán),直到瀏覽器最大循環(huán)限制次數(shù),哪怕uri包含web/目錄了,也會繼續(xù)重定向/web/web/$1



錯誤寫法2:



server{

    listen 80;

    server_name www.test.com;

    root /data/wwwroot/test.com;

    index index.html;

    rewrite /(.*) /web/$1 break;

}

1

2

3

4

5

6

7

添加break后不會導(dǎo)致循環(huán),但如果uri中包含web/目錄的情況下也會被重定向一次,重定向后的uri就是web/web/$1



rewrite應(yīng)用實例

1.域名跳轉(zhuǎn)(域名重定向)

單個域名的情況:



server{

    listen 80;

    server_name www.test.com;

    rewrite /(.) http://www.test.net/$1 permanent;    

}

1

2

3

4

5

多個域名的情況:



server{

    listen 80;

    server_name www.test.com www.test.net;

    if ($host != 'www.test.net')

    {

        rewrite /(.
) http://www.test.net/$1 permanent;

    }

}

1

2

3

4

5

6

7

8

2.http跳轉(zhuǎn)https

server{

    listen 80;

    server_name www.test.com;

    rewrite /(.) https://www.test.com/$1 permanent;

}

1

2

3

4

5

3.跳轉(zhuǎn)二級目錄

server{

    listen 80;

    server_name bbs.test.com;

    rewrite /(.
) http://www.test.com/bbs/$1 last;

}

1

2

3

4

5

4.動靜態(tài)請求分離

server{

    listen 80;

    server_name www.test.com;

    location ~ ..(jpg|jpeg|gif|css|png|js)$

    {

        rewrite /(.*) http://img.test.com/$1 permanent;

    }

}

1

2

3

4

5

6

7

8

假設(shè)www.test.com的服務(wù)器在國外,訪問速度較慢,img.test.com的服務(wù)器在國內(nèi),訪問速度正常,可以將訪問www.test.com靜態(tài)文件的請求重定向到img.test.com,提高文件返回速度



第二種寫法:



server{

    listen 80;

    server_name www.test.com;

    if ( $uri ~ 'jpg|jpeg|gif|css|png|js$')

    {

        rewrite /(.
) http://img.test.com/$1 permanent;

    }

}

1

2

3

4

5

6

7

8

5.防盜鏈配置

server{

    listen 80;

    server_name www.test.com;

    location ~ ^.+.(jpg|jpeg|gif|css|png|js|rar|zip|flv)$

    {

        valid_referers none blocked server_names
.test.com

        if ($invalid_referer)

        {

            return 403;

        }

    }

}

1

2

3

4

5

6

7

8

9

10

11

12

配置防盜鏈避免別的網(wǎng)站引用www.test.com不想被引用的圖片等文件



http_referer表示從哪兒點擊進(jìn)網(wǎng)站的,比如從百度搜索引擎訪問的

valid_referers:白名單

invalid_referer:無效的(未在白名單中定義的)

none:允許referer為空(也就是允許直接訪問,未從其他站點跳轉(zhuǎn)的請求)

blocked:允許來源地址不含http/https



6.偽靜態(tài)(將靜態(tài)頁面重寫為動態(tài))

location /  {

    rewrite ^([^.])/topic-(.+).html$ $1/portal.php?mod=topic&topic=$2 last;

    rewrite ^([^.]
)/forum-(\w+)-([0-9]+).html$ $1/forum.php?mod=forumdisplay&fid=$2&page=$3 last;

    rewrite ^([^.])/thread-([0-9]+)-([0-9]+)-([0-9]+).html$ $1/forum.php?mod=viewthread&tid=$2&extra=page%3D$4&page=$3 last;

    rewrite ^([^.]
)/group-([0-9]+)-([0-9]+).html$ $1/forum.php?mod=group&fid=$2&page=$3 last;

    rewrite ^([^.])/space-(username|uid)-(.+).html$ $1/home.php?mod=space&$2=$3 last;

    rewrite ^([^.]
)/(fid|tid)-([0-9]+).html$ $1/index.php?action=$2&value=$3 last;

}

1

2

3

4

5

6

7

8

示例為discuz的偽靜態(tài)配置



7.多個if并用

location /{

    set $a 0;

    if ($document_uri !~ '^/abc')

    {

        set $a "${a}1"; #uri不以/abc開頭時,$a的值變?yōu)?1

    }

    if ($http_user_agent ~ 'ie6|firefox')

    {

       set $a "${a}2"; #瀏覽器標(biāo)識包含ie6或者Firefox時,$a的值變?yōu)?12

    }

    if ($a = "012") #當(dāng)滿足前兩個if判斷時,重寫url

    {

        rewrite /(.
) /abc/$1 redirect;

    }

}

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

nginx配置文件語法不支持if嵌套,需要通過多個if并用判斷時,使用標(biāo)識變量值的方式處理



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

中臺是什么?聽聽大咖的看法

資深UI設(shè)計者

歷史上的每一次變革,都是從一小部分人的率先覺醒開始的?;ヂ?lián)網(wǎng)時代的變革日新月異,更需要時刻洞察局勢,未雨綢繆。


我們籌辦了【藍(lán)湖做東】的線下活動,邀請行業(yè)大咖們齊聚論道,碰撞智慧的花火,追尋潮流的軌跡。

本期嘉賓


(按發(fā)言順序)



此外,感謝不愿透露姓名的神秘大咖們蒞臨現(xiàn)場!


話題背景


阿里巴巴集團(tuán)在 2015 年首次提出“大中臺、小前臺”的戰(zhàn)略,此后,騰訊、百度、京東、美團(tuán)、滴滴等互聯(lián)網(wǎng)巨頭紛紛效仿,一時間“中臺”引發(fā)互聯(lián)網(wǎng)行業(yè)的刷屏熱潮。


說到中臺,不得不提到芬蘭的游戲公司 Supercell ,僅有 300 名員工,卻接連推出爆款游戲,成為當(dāng)時全球最會賺錢的明星游戲公司,馬云帶隊參觀這家公司半年之后,阿里集團(tuán)開始組建 " 大中臺,小前臺 " 的組織和業(yè)務(wù)體制。


2015 年年中,馬云帶領(lǐng)阿里巴巴集團(tuán)高管,拜訪了位于芬蘭赫爾辛基的移動游戲公司 Supercell。


Supercell 當(dāng)時號稱是世界上最成功的移動游戲公司,Supercell 由 6 名資深游戲開發(fā)者在 2010 年創(chuàng)立,旗下?lián)碛小恫柯錄_突》、《皇室戰(zhàn)爭》、《海島奇兵》和《卡通農(nóng)場》這四款超級現(xiàn)象級產(chǎn)品。Supercell 是一家典型的以小團(tuán)隊模式進(jìn)行游戲開發(fā)的公司,以 2 到 5 個員工、最多不超過 7 個員工組成獨(dú)立的開發(fā)團(tuán)隊,稱之為 Cell ( 細(xì)胞 ) ,這也是公司名字 Supercell (超級細(xì)胞)的由來。


團(tuán)隊自己決定做什么樣的產(chǎn)品,然后最快時間推出產(chǎn)品公測版,看看游戲是否受用戶歡迎。如果用戶不歡迎,迅速放棄這個產(chǎn)品,再進(jìn)行新的嘗試,期間幾乎沒有管理角色的介入。團(tuán)隊研發(fā)的產(chǎn)品失敗后,不但不會受到懲罰,甚至還會舉辦慶祝儀式,以慶祝他們從失敗中學(xué)到了東西。


這種模式讓 Supercell 公司成為了年稅前利潤 15 億美金的游戲公司,2016 年 6 月,騰訊以 86 億美元收購了員工數(shù)不超過 200 人的 Supercell 公司 84.3% 的股權(quán),每一名員工人均貢獻(xiàn)的估值超過 3.54 億人民幣。


Supercell 的成功很大原因就在于其的 " 部落 " 組織策略。在 supercell 僅有的 100 多人中,被分成若干個小前臺組織,每個小組雖然人不多,但都包含了做一款游戲需要的所有人才。


本來就不大的公司被分成若干個小組,這樣做的好處是可以快速決策,快速研發(fā),快速把產(chǎn)品推向市場,而游戲引擎、服務(wù)器等后臺基礎(chǔ)則不需要操心。


Supercell 的模式給參加此次拜訪的阿里高管們很大的震撼,在大家反復(fù)的心得交流和討論中,一個非常重要的問題引起了很多人的反思:信息時代的公司架構(gòu)到底應(yīng)該是怎樣的?


正是有了這次拜訪才真正讓阿里巴巴的領(lǐng)導(dǎo)層有了足夠的決心要將組織架構(gòu)進(jìn)行調(diào)整,在此次拜訪的半年后,阿里集團(tuán) CEO 逍遙子發(fā)出內(nèi)部郵件,組織架構(gòu)全面升級,建設(shè)整合阿里產(chǎn)品技術(shù)和數(shù)據(jù)能力的強(qiáng)大中臺,組建 " 大中臺,小前臺 " 的組織和業(yè)務(wù)體制。


阿里中臺
所謂的 " 中臺 ",并不是阿里巴巴首先提出的詞語,從字面意思上理解,中臺是基于前臺和后臺之間。阿里通過多年不懈的努力,在業(yè)務(wù)的不斷催化滋養(yǎng)下,將自己的技術(shù)和業(yè)務(wù)能力沉淀出一套綜合能力平臺,具備了對于前臺業(yè)務(wù)變化及創(chuàng)新的快速響應(yīng)能力。阿里人將 " 中臺戰(zhàn)略 " 形象地比喻成陸??杖娏Ⅲw化協(xié)同作戰(zhàn)。


海陸空協(xié)同作戰(zhàn)
他們將中臺分為六類,分別對應(yīng)不同兵種:

業(yè)務(wù)中臺,提供重用服務(wù),例如用戶中心、訂單中心之類的開箱即用可重用能力,為戰(zhàn)場提供了空軍支援能力,隨叫隨到,威力強(qiáng)大;
數(shù)據(jù)中臺,提供數(shù)據(jù)分析能力,幫助從數(shù)據(jù)中學(xué)習(xí)改進(jìn),調(diào)整方向,為戰(zhàn)場提供了海軍支援能力;
算法中臺,提供算法能力,幫助提供更加個性化的服務(wù),增強(qiáng)用戶體驗,為戰(zhàn)場提供了陸軍支援能力,隨機(jī)應(yīng)變,所向披靡;
技術(shù)中臺,提供自建系統(tǒng)部分的技術(shù)支撐能力,幫助解決基礎(chǔ)設(shè)施,分布式數(shù)據(jù)庫等底層技術(shù)問題,為前臺特種兵提供了精良的武器裝備;
研發(fā)中臺,提供自建系統(tǒng)部分的管理和技術(shù)實踐支撐能力,幫助快速搭建項目、管理進(jìn)度、測試、持續(xù)集成、持續(xù)交付,是前臺特種兵的訓(xùn)練基地;
組織中臺,為項目提供投資管理、風(fēng)險管理、資源調(diào)度等,是戰(zhàn)場的指揮部,戰(zhàn)爭的大腦,指揮前線,調(diào)度后方。
2018 年雙 11,阿里又一次實現(xiàn)了一次壯舉,在 2135 億的背后,在令人驕傲的戰(zhàn)績背后,缺少不了阿里中臺鐵軍發(fā)揮的巨大力量。
(資料來源于 ZAKER)


活動現(xiàn)場

北京的院子馳名中外,坐落在北京孔廟旁邊的一處小院尤其別致,相對封閉的院子中,坐落著透明的玻璃房子。四面圍合卻有開闊的視野,兼具隱秘性與舒適感?!舅{(lán)湖做東】首期聚會在這里悄然開始。


特邀嘉賓們紛至沓來,不約而同地坐到了向陽的落地窗前,伴隨著初秋的清風(fēng)和暖陽,一場以中臺為主題的討論,徐徐展開。


影響著行業(yè)的大咖們,是如何被中臺影響的呢?讓我們拭目以待。


服務(wù)過阿里大文娛的高級交互設(shè)計專家朱斌,離中臺最近,他率先發(fā)言。


在阿里大文娛,我注意到整個內(nèi)容行業(yè)的資源非常依賴于導(dǎo)演和演員。


如果沒有流量明星或知名導(dǎo)演,那這個作品票房十有八
九都不好,所以可以看到中國的電影宣傳幾乎都是明星臉。而國外就截然不同,國外更加依賴于編輯和 IP。并且以一套極為成熟和的生產(chǎn)模式批量化創(chuàng)造出大量優(yōu)質(zhì)的影視作品。像流水線一樣生產(chǎn)出不同風(fēng)格的流量大片。


當(dāng)內(nèi)容成為商品的時候,如何判斷一個內(nèi)容的傳播價值,就成為問題。


我們?yōu)榇私⒘艘粋€團(tuán)隊,專門來研究注意力管理,讓不同層次的用戶第一時間看到內(nèi)容就能進(jìn)行一系列快速判斷,而且這個判斷還要符合人類的思維結(jié)構(gòu)。


簡單來說我們想用體驗的方式去把復(fù)雜的內(nèi)容和故事進(jìn)行具象化,在第一時間讓用戶看到、看懂,并激發(fā)出觀看的興趣。


這個構(gòu)思在運(yùn)作的過程中面臨很多問題。


比如,設(shè)計師們?nèi)绾慰焖購挠耙曌髌分刑崛∮行畔?,如果有個片子 50 集,要判斷它的價值,要看完 50 集嗎?影視作品體量那么大,沒有那么多設(shè)計師把所有內(nèi)容都過一遍。


最終,我們提出了“中臺”這個設(shè)想,我們試圖找到一種即又符合邏輯,同時符合用戶體驗的方式。把內(nèi)容進(jìn)行體驗層面的歸類和細(xì)分,提取共有特性,預(yù)判用戶在不同類別中的興趣和喜好。進(jìn)而提升內(nèi)容平臺的商業(yè)價值和分發(fā)效率。


商業(yè)行為的本質(zhì)就是榨取剩余價值。


榨取剩余價值的基本條件,就是降本增效——用更少的時間、更少的人力成本,做出一樣多的事情。我們使用藍(lán)湖這樣的工具就是為了提效,這也是各大企業(yè)爭相構(gòu)建中臺的原因之一。


設(shè)計行業(yè)比較偏向創(chuàng)意,和其他行業(yè)的中臺有所不同,在座各位都是各行各業(yè)的大咖,我想借此機(jī)會聽聽大家對中臺的理解和運(yùn)用,大家就自己所面臨的問題找找解決方案。


聚美優(yōu)品也正在構(gòu)建“電商中臺”,蘇星就此闡述了自己的觀點:


大家都認(rèn)為聚美優(yōu)品是一個電商企業(yè),其實內(nèi)部已經(jīng)逐步轉(zhuǎn)變成了一個類投行的企業(yè),不僅收購一些頗具潛力的項目,也孵化內(nèi)部的一些項目。


中臺與每個公司的業(yè)務(wù)形態(tài)相關(guān),如果公司是產(chǎn)品驅(qū)動的,它的中臺搭建就會側(cè)重于更的提供各種功能性服務(wù);如果產(chǎn)品比較單一、功能比較單一、市場比較下沉、類目比較垂直的話,那中臺的概念可能是一個偽命題。


聚美優(yōu)品近年來致力于尋找新的經(jīng)濟(jì)增長點,這是老牌上市公司必然經(jīng)歷的一個階段。所以,公司對具有創(chuàng)造力的崗位或團(tuán)隊給予很多的支持,但很多創(chuàng)意都是天馬行空想出來的,當(dāng)一個產(chǎn)品或項目到設(shè)計部門的時候,我們需要判斷其成功的路徑是什么。我理解的,這就是一個中臺。如果是設(shè)計中臺的話,它需要完成一個任務(wù),保證效果。


中臺可能是一個宏觀的狀態(tài)概念和一個微觀的具體操作層面的重合,我所說的設(shè)計中臺,更偏向于設(shè)計管理上的中臺思維,它是一個驅(qū)動力,可以靈活地組建很多模塊,然后不斷去自由匹配,從而支持一些功能。




阿里大文娛的朱斌接過話題,補(bǔ)充了一些看法:



產(chǎn)品設(shè)計行業(yè)具有特殊性,如何把產(chǎn)品設(shè)計理念和產(chǎn)品設(shè)計原則,通過數(shù)據(jù)整合,與設(shè)計需求靠近,是個難題,也是阿里的中臺一直在努力解決的問題。


關(guān)于中臺,我想提出兩個點:中臺的特性,中臺對產(chǎn)品設(shè)計行業(yè)是好是壞。


朱斌曾服務(wù)過的華為提出“讓聽得見炮火的人呼喚炮火”,這就是個人與中臺之間配合的關(guān)系。這里“呼喚炮火”的人,就是產(chǎn)品設(shè)計師,他們奮戰(zhàn)在一線,接觸不同維度、不同領(lǐng)域的人,有特別強(qiáng)的洞察力,而提供“炮火”的就是中臺能力。


阿里現(xiàn)在在做兩件事,其一就是強(qiáng)大的設(shè)計格局,其二就是把所有設(shè)計職能進(jìn)行了升級,把之前的視覺設(shè)計師、交互設(shè)計師和各種子類的設(shè)計師都統(tǒng)一成了三種類型:體驗設(shè)計師、創(chuàng)意設(shè)計師、用戶研究設(shè)計師。其中體驗設(shè)計師大概占 60-70%,創(chuàng)意設(shè)計師占 20%,用戶研究設(shè)計師大約 10%.


阿里的零售板塊非常穩(wěn)定,服務(wù)的幾千萬中小企業(yè)每天都會有海量的店鋪、商品設(shè)計需求。所以體驗設(shè)計團(tuán)隊制定了詳盡的規(guī)范,而這些規(guī)范就是中臺,設(shè)計師按照規(guī)范進(jìn)行輸出即可,甚至開了鹿班系統(tǒng)自動生產(chǎn),這就相當(dāng)于炮兵,指哪打哪,火力兇猛。


同時,我們會拓展第二曲線,通過創(chuàng)意設(shè)計師找方向。創(chuàng)意設(shè)計師的工作不一定能立即帶來商業(yè)價值,但可以通過嘗試,獲取用戶反饋的數(shù)據(jù),由此做一些校準(zhǔn)和拓展業(yè)務(wù)邊界的工作。


所以中臺能解決的問題,一定是穩(wěn)定的,而創(chuàng)意相關(guān)的東西一定是變化的。所以,阿里提出“大中臺、小前臺”的戰(zhàn)略。用中臺去做效率實現(xiàn)盈利,用前臺去做變化生成新的規(guī)范。


以我開篇提到的內(nèi)容行業(yè)舉例,時下流行的明星是隨時變動的,但這些變化會產(chǎn)生一些規(guī)律,比如這些明星都有哪些共同特點,中臺就能總結(jié)出這些變動的規(guī)律,整合出一套審美規(guī)范,當(dāng)知道受眾需要什么的時候,就可以根據(jù)中臺提供的規(guī)范,由前臺去尋找符合受眾需求的內(nèi)容。


這是一個相輔相成的過程,通過前臺不斷刺激用戶去看新內(nèi)容,后臺可以通過反饋收集整合更多規(guī)范,再由這些規(guī)范支持前臺更產(chǎn)出符合用戶需求的內(nèi)容。


阿里的設(shè)計中臺大家都知道,就是鹿班智能設(shè)計平臺,它是設(shè)計中臺最有代表性的一個產(chǎn)品。鹿班誕生的背景,是由于電商平臺得通過 Banner 做宣傳,淘寶量級越做越大,設(shè)計師支撐不住巨大的需求,加上同類 Banner 轉(zhuǎn)化率差別不大。


這就體現(xiàn)了需要做設(shè)計中臺的幾個前提:


其一,需求量特別大,不是靠人力能夠解決的,或者靠人力解決的話,成本會特別高。


其二,設(shè)計質(zhì)量要求不高,所要輸出到的信息量較為固定。


其三,存在的生命周期特別短。像淘寶的推廣,你每次打開都是不一樣的東西。


有了這三個前提,就可以考慮做設(shè)計中臺。


就此,又產(chǎn)生一個疑問,以前的那么多設(shè)計師是不是就沒活干了?


并不是這樣的。


阿里提出“重新定義設(shè)計”,設(shè)計師是構(gòu)造一種秩序,這種秩序是機(jī)器沒有辦法自動獲得的,它一定來自于設(shè)計師的經(jīng)驗、對用戶的洞察、對品類的把控。最終,建立、優(yōu)化中臺的任務(wù)是由設(shè)計師來做的。


用我們的設(shè)計團(tuán)隊舉例,中高級 UX 設(shè)計師在迅速增加,設(shè)計師的絕對數(shù)量沒有大的增長??梢钥闯稣麄€企業(yè)設(shè)計團(tuán)隊的能力是在提升的,對業(yè)務(wù)的支撐也會更有效,不必像以前需要上百上千個初級設(shè)計甚至外包團(tuán)隊來做這件事。這就是中臺在規(guī)?;皖l繁迭代上的優(yōu)勢和效益。


廣聯(lián)達(dá)印雋講到什么性質(zhì)的中臺解決什么問題,以及中臺的本質(zhì)是什么:


阿里的鹿班,在內(nèi)部和其他系統(tǒng)高度耦合,一張推廣圖從制作到分發(fā),到上架到驗證,系統(tǒng)和系統(tǒng)之間并無太多斷層。


從使用者的角度來說,鹿班系統(tǒng)的最大收益方并不是設(shè)計師,而是商戶,本質(zhì)上是為了提高生產(chǎn)效率,用 AI 來淘汰量產(chǎn)擼圖的低端設(shè)計師,但還是可以視做設(shè)計中臺,畢竟這是一套“會做設(shè)計”,并且由設(shè)計師來提供機(jī)訓(xùn)內(nèi)容的系統(tǒng)。


所以我們談中臺之前,還是先把中臺的邊界劃清楚。


不能把技術(shù)中臺、業(yè)務(wù)中臺、數(shù)據(jù)中臺、設(shè)計中臺混為一談。


中臺概念在支付領(lǐng)域出現(xiàn)的比較早,以支付系統(tǒng)為例,資金管理、財務(wù)、風(fēng)控,屬于后臺,即技術(shù)視角的底層服務(wù)。


渠道接入、交易、賬戶、收單網(wǎng)關(guān)等等,屬于中臺。


中臺承擔(dān)的是業(yè)務(wù)聚合和泛用,中臺不能獨(dú)立存在,脫離后臺來談中臺是沒有意義的。



(例圖摘自網(wǎng)絡(luò))


對于設(shè)計師來說,切忌盲目跟風(fēng),中臺概念的確很火,但僅針對一線大型團(tuán)隊。團(tuán)隊和產(chǎn)品體量沒達(dá)到一定規(guī)模,底層系統(tǒng)都還沒打磨清楚的團(tuán)隊,談中臺也為時過早。且設(shè)計團(tuán)隊如果還以界面和功能交互設(shè)計的執(zhí)行工作為主,并沒有足夠深入業(yè)務(wù)和技術(shù)的話,也沒有資格談中后臺設(shè)計。


至于設(shè)計中臺,還是得先看企業(yè)業(yè)務(wù)是否已經(jīng)處于良性發(fā)展期,且技術(shù)和業(yè)務(wù)也已經(jīng)到了可以有中臺的階段,不然,脫離業(yè)務(wù)來談設(shè)計中臺,又是一紙空文。


所以,從這個視角來看,行業(yè)內(nèi)真正可以算得上是設(shè)計中臺的,除了阿里鹿班這個量級的系統(tǒng)之外,少之極少。


但是,除此之外,就沒有別的形式的設(shè)計中臺了呢?


我們其實可以換個視角看一下,比如,一個已經(jīng)達(dá)到一定量級的設(shè)計團(tuán)隊,是否有意識的在管理自己的數(shù)字和數(shù)據(jù)資產(chǎn)呢?在什么系統(tǒng)里管理?這樣的系統(tǒng),是否可以視為設(shè)計視角中臺?或只是一個工具?
設(shè)計部門需要基于系統(tǒng)的數(shù)字資產(chǎn)管理。大部分設(shè)計團(tuán)隊,并沒有從系統(tǒng)視角,把一個設(shè)計體系運(yùn)作所需要的對象管理起來。小到一個圖標(biāo),一個文檔,大到你的規(guī)范和原則和設(shè)計語言,都散落在各個零碎的內(nèi)、外部系統(tǒng)中,甚至于設(shè)計師個人的硬盤里。


一個 Design DAM( Digital Asset Management 設(shè)計數(shù)字資產(chǎn)管理) 系統(tǒng)或許可以成為一個企業(yè)的設(shè)計中臺的一部分,而且這個中臺是可以獨(dú)立于部分業(yè)務(wù)而存在的,他能有效累積整個企業(yè)在生產(chǎn)過程中的所有客觀過程,包括數(shù)據(jù)。


一個優(yōu)秀的設(shè)計團(tuán)隊,需要具備數(shù)據(jù)驗證和數(shù)據(jù)驅(qū)動能力,而用于分析和驗證的數(shù)據(jù),也應(yīng)該是設(shè)計的數(shù)字資產(chǎn)的一部分。如果設(shè)計團(tuán)隊自己有能力的話,應(yīng)該作為設(shè)計數(shù)字資產(chǎn)的一部分。那么這個數(shù)字資產(chǎn)可以是一個設(shè)計中臺。換言之,數(shù)字資產(chǎn)是建立設(shè)計中臺的一個重要核心。


藍(lán)湖或許就像是一個 Design DAM 系統(tǒng)的雛形,當(dāng)然,還有很長的路要走。


團(tuán)隊的方法論和知識庫也需要一個系統(tǒng)性的沉淀。


企業(yè)需要的是依葫蘆畫瓢式的流程,還是化整為零的方法論庫,根據(jù)實際項目情況合理的自由的組合運(yùn)用。從管理視角來看,我們更希望看到的是系統(tǒng)性的管理,而不是完全依賴于人肉的主觀。需要很清楚這些方法論的組合是以何種靈活的狀態(tài)去支撐項目,以及輸出的標(biāo)準(zhǔn)在哪里。


路漫漫,其修遠(yuǎn)兮。


自如網(wǎng)的賈洪濤對印雋的發(fā)言很贊同,但是關(guān)于“炮火”,他卻有不同的見解:


關(guān)于任總“聽見炮火的聲音”來做決策,我的個人體會不一樣,離炮火最近的人被炸死了,或者被炸殘了,聽得見炮聲的人,也許不是第一線,而是第二線的人,他們才是最適合做決策的人。


我想做的是中臺其中的一種,對內(nèi)部的數(shù)據(jù)可視化。企業(yè)的相關(guān)數(shù)據(jù)能展現(xiàn)在所有員工面前,像淘寶雙十一那樣,一是激勵團(tuán)隊,一是告訴團(tuán)隊產(chǎn)品的現(xiàn)狀。


我們要做的第一步就是先用現(xiàn)有的數(shù)據(jù),足夠好、足夠多的數(shù)據(jù),展現(xiàn)給員工眼前,但同時也要考慮到,這些數(shù)據(jù)放出來,外部客戶看到后會不會產(chǎn)生負(fù)面影響。


另外一個,項目的數(shù)據(jù),如果讓設(shè)計做清單是沒有意義的,如果為了做得漂亮虛造數(shù)據(jù),就更加沒有意義,不是我想做的初衷。


提到數(shù)據(jù),服務(wù)過阿里的朱斌補(bǔ)充了自己的看法:


我這兒有兩個故事。


第一個故事是回應(yīng)賈總的想法。我有一個學(xué)妹,正在阿里做一個項目,叫做“數(shù)據(jù)之美”,就是做雙十一的大屏和各種數(shù)據(jù)的可視化呈現(xiàn)。比如會通過各種設(shè)計的變化來展示數(shù)據(jù)增長的速度感、體量感。目前做的非常成功,今年也晉升到了更高的職位,足以說明數(shù)據(jù)可視化的重要性。


第二個是另一個維度的故事。有時候團(tuán)隊內(nèi)考核 Review 時,每個細(xì)分的 KPI 都完成了,而且看描述都是超額完成,所有的數(shù)據(jù)都很好。但實際上公司的整體競爭狀態(tài)卻在下滑。


這兩個故事告訴我,數(shù)據(jù)其實就是一個任人打扮的小姑娘,好的打扮會讓數(shù)據(jù)更易讀易懂,壞的打扮會讓數(shù)據(jù)具有欺騙性。當(dāng)講到數(shù)據(jù)的時候一定需要非常嚴(yán)謹(jǐn)?shù)乃惴?,每一個沖鋒陷陣的人都似乎贏了,但最后戰(zhàn)爭卻是輸?shù)?,這就需要全面的數(shù)據(jù)分析,只抓單個的數(shù)據(jù),其實特別危險。


廣聯(lián)達(dá)印雋說得很對,數(shù)字資產(chǎn)管理看的是長線、看得是全局,而產(chǎn)品經(jīng)理往往看的是當(dāng)下,是短線。由此,我認(rèn)為直接把數(shù)據(jù)動態(tài)跟設(shè)計動態(tài)捆綁在一起,是危險的,或者不能叫做中臺。我們的解決方法就是求助于數(shù)據(jù)分析團(tuán)隊,一方面通過專家解讀保證正確理解,另一方面我們也自建數(shù)據(jù)理解的能力,招募了數(shù)據(jù)方面的專家增加了一條體驗數(shù)據(jù)支線。


很多人說數(shù)據(jù)像毒藥,我認(rèn)為,數(shù)據(jù)是解藥。那些認(rèn)為數(shù)據(jù)有毒的人,大約是沒有真正分清楚哪些才是有效的數(shù)據(jù)。Netflix、字節(jié)跳動等很多新興企業(yè)的成功告訴我們,通過數(shù)據(jù)的分析,做出的決策更有利于目標(biāo)的達(dá)成,而基于平臺層面的數(shù)據(jù)收集、分析、管理,也就是數(shù)字資產(chǎn)管理,正是中臺能力構(gòu)建的基石。


文章來源:UI中國

使用docbox定制API文檔

seo達(dá)人

使用docbox定制API文檔

什么是docbox

docbox的安裝

克隆項目

部署方式

docbox的編寫

定制logo及UI

更換代碼背景色

插入自己的logo

三列改為雙列

其他定制UI



在公司實習(xí)了一個月,由于業(yè)務(wù)需要,我花了大概一周時間對docbox的安裝,編寫,定制化等進(jìn)行了詳細(xì)的研究,下面給大家分享一下我的總結(jié)

什么是docbox

Docbox是一個開源的REST API文檔系統(tǒng)。它采用結(jié)構(gòu)化的Markdown文件,并生成帶有導(dǎo)航,固定鏈接的兩列布局。下面是官方example圖片:









docbox的安裝

克隆項目

直接去官網(wǎng)https://github.com/tmcw/docbox,然后克隆即可。



部署方式

在使用npm命令前需要下載Node.js,npm會根據(jù)package.json配置文件中的依賴配置下載安裝



接著,在/content下放入.md文件,并使用 npm run build 命令,生成一個包含所需要的js代碼的bundle.js文件,同時創(chuàng)建一個新的index.html文件



重要的就是index.html、bundle.js、/css這三個文件和文件夾



docbox的編寫

在/content下放入.md文件(markdown語法俺就不說了哈……)

對/src/custom/content.js中添加需要引入的.md文件位置和以及標(biāo)題





注意: /src/custom/content.js中放入的是一級標(biāo)題、二級和三級標(biāo)題需要在.md文件中編寫。





定制logo及UI

修改/src/custom/index.js文件

修改對應(yīng)標(biāo)簽的屬性即可,定制時修改生成的index.html是沒有用的,因為index.html里的標(biāo)簽是被動態(tài)寫死的。

更換代碼背景色

<div class='round-left pad0y pad1x fill-green code small endpoint-method'>

1





<div class='endpoint dark fill-blue round '>

1





插入自己的logo





修改/src/components/app.js文件



三列改為雙列

docbox默認(rèn)情況下是顯示三列布局,但我們可以在app.js下進(jìn)行修改使之默認(rèn)為雙列布局。將下圖的1改為2即可切換雙列模式







其他定制UI

像下圖一樣,我們可以修改并填寫代碼得到自己想要的頁面樣式,比如說我在最上方加了一個固定位置的區(qū)域,然后可以在這個區(qū)域添加相應(yīng)的超鏈接等。







app.js里可以找到圖中對應(yīng)的標(biāo)簽和js代碼,docbox支持多種語言切換,我們在需要的地方加入我們想要加入的標(biāo)簽,并在/css文件夾中對相應(yīng)的css文件添加樣式就可以定制我們想要的UI啦!!!



下面給大家列出一些用docbox定制API文檔的網(wǎng)站



Mapbox API文檔

Mapillary的API文檔和Tiles文檔

HYCON 8th

Wall

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

日歷

鏈接

個人資料

存檔