整合營銷服務(wù)商
電腦端+手機(jī)端+微信端=數(shù)據(jù)同步管理
免費(fèi)咨詢熱線：
電腦端+手機(jī)端+微信端=數(shù)據(jù)同步管理
免費(fèi)咨詢熱線：
本文為2022摹客RP原型工具測評(píng)大賽一等獎(jiǎng)作品
原型設(shè)計(jì)工具是很多交互設(shè)計(jì)師以及產(chǎn)品經(jīng)理都會(huì)使用到的，國產(chǎn)原型工具越來越多，給了用戶許多選擇，而真正滿足用戶需求的原型設(shè)計(jì)軟件，才是為大家所選擇的。作者就摹客RP進(jìn)行評(píng)測，結(jié)合實(shí)際工作案例，將蘇寧智慧屏OS系統(tǒng)中的“自定義頻道”功能作為測試案例，從交互設(shè)計(jì)的角度對(duì)產(chǎn)品進(jìn)行體驗(yàn)測評(píng)。
原型設(shè)計(jì)軟件是設(shè)計(jì)師、產(chǎn)品經(jīng)理使用頻率很高的工具，最早期的軟件是Axure，它因?yàn)檩p量化，功能豐富的特點(diǎn)也一直很受大家追捧，但作為一款國外開發(fā)的軟件，卻也有很多局限性，比如使用者權(quán)限，團(tuán)隊(duì)協(xié)作、購買價(jià)格等，正是由于這些因素，讓國內(nèi)很多公司看到了這塊市場，紛紛入局，開發(fā)相關(guān)的軟件去競標(biāo)Axure；從早期的藍(lán)湖到現(xiàn)如今的各大品牌的原型設(shè)計(jì)軟件，給了項(xiàng)目設(shè)計(jì)人員更多的選擇，大大提高的團(tuán)隊(duì)協(xié)作效率。
目前我們公司設(shè)計(jì)團(tuán)隊(duì)使用的原型設(shè)計(jì)工具就是Axure，在實(shí)際項(xiàng)目中，團(tuán)隊(duì)交互原型的呈現(xiàn)效果很差，統(tǒng)一性不強(qiáng)，組件的復(fù)用、新增、修改等同步的效率很低。原型設(shè)計(jì)樣式和規(guī)范五花八門，給閱讀的人員造成很多不便，盡管團(tuán)隊(duì)在每個(gè)版本結(jié)束之后都會(huì)對(duì)原型設(shè)計(jì)的規(guī)范進(jìn)行匯總和要求，但是設(shè)計(jì)師在進(jìn)行原型設(shè)計(jì)時(shí)，都習(xí)慣了一遍做原型，一遍去比對(duì)熟悉規(guī)范，都是獨(dú)自去審查，大大影響了原型設(shè)計(jì)的統(tǒng)一性；
項(xiàng)目組的設(shè)計(jì)人員負(fù)責(zé)的模塊都比較獨(dú)立，繪制原型頁面過程中，無法實(shí)時(shí)同步去協(xié)作，繪制結(jié)束后還需要保存源文件或者導(dǎo)出html分享給項(xiàng)目組人員，導(dǎo)致Axure的共享協(xié)作成本變得非常高。
項(xiàng)目團(tuán)隊(duì)想通過引入國內(nèi)原型設(shè)計(jì)工具來替代Axure，幫助團(tuán)隊(duì)更加高效地進(jìn)行項(xiàng)目項(xiàng)協(xié)作，剛好應(yīng)邀參加「摹客與人人都是產(chǎn)品經(jīng)理」聯(lián)合舉辦的關(guān)于“摹客RP評(píng)測文章”的比賽。
所以就想著通過評(píng)測這款產(chǎn)品是否在團(tuán)隊(duì)中使用和推廣，以及通過使用體驗(yàn)提出一些建議，希望自己的拙見和思考能夠?qū)δ】蚏P的產(chǎn)品設(shè)計(jì)能有一些幫助。本篇文章通過實(shí)際工作中的項(xiàng)目，蘇寧智慧屏OS系統(tǒng)中的“自定義頻道”功能作為測試案例，從交互設(shè)計(jì)的角度對(duì)產(chǎn)品進(jìn)行體驗(yàn)測評(píng)。
測試設(shè)備：Macbook pro 2019
測試產(chǎn)品：摹客RP網(wǎng)頁端、客戶端
測試形式：以實(shí)際工作項(xiàng)目為例，對(duì)摹客RP的產(chǎn)品功能使用和交互操作進(jìn)行體驗(yàn)評(píng)測
測試用時(shí)：四周
測試主要從以下三方面進(jìn)行：產(chǎn)品的設(shè)計(jì)框架、產(chǎn)品使用的操作流程、產(chǎn)品的設(shè)計(jì)組件；框架是產(chǎn)品最底層的基礎(chǔ)部分，好的框架會(huì)讓用戶一目了然，比如他的功能是有哪些，功能信息怎么去布局的，信息的層次感有沒很有分明，這些都能有效率的讓用戶閱讀和使用產(chǎn)品；操作交互是能讓用戶對(duì)產(chǎn)品體驗(yàn)更直觀，如在某一功能的使用流程中，用起來方不方便，交互方式的操作是否順暢，設(shè)計(jì)和組件設(shè)計(jì)決定和產(chǎn)品的“顏值”，設(shè)計(jì)原則、模式和合理的組件使用能提升產(chǎn)品的價(jià)值和表現(xiàn)力，所以本次的測試大綱如下：
第一個(gè)角度主要是從設(shè)計(jì)框架來進(jìn)行體驗(yàn)，主要包括產(chǎn)品的功能結(jié)構(gòu)、布局的信息層次；兩端主頁面的框架設(shè)計(jì)基本是保持一致的，均是左右結(jié)構(gòu)，但還是有很多差異化的細(xì)節(jié)設(shè)計(jì)；
網(wǎng)頁端拆解圖：
客戶端拆解圖：
（1）左邊區(qū)域?qū)Ρ?/strong>
對(duì)比可以看出網(wǎng)頁端的側(cè)邊欄信息更多，有l(wèi)ogo，有相關(guān)聯(lián)的工具鏈接，導(dǎo)航菜單類別多達(dá)7個(gè)，而客戶端側(cè)邊欄功能比較簡化，只有用戶信息和導(dǎo)航菜單，且導(dǎo)航菜單只有5個(gè)。
（2）右邊區(qū)域?qū)Ρ?/strong>
在內(nèi)容區(qū)上，網(wǎng)頁端和客戶端的框架是保持一致的，都是頂-中-底三層：
原型設(shè)計(jì)頁面和Axure的頁面相似度很高，大致可以拆分成四大部分：標(biāo)題和工具欄，左邊功能區(qū)分上下兩層，可以上下收縮拉伸，中間是原型設(shè)計(jì)區(qū)域，右邊設(shè)置面板區(qū)主要屬性、交互、備注三個(gè)主要功能。頁面的布局符合設(shè)計(jì)師使用習(xí)慣，理解成本很低；網(wǎng)頁端和客戶端的也是統(tǒng)一的。
整體來說，兩端的控制臺(tái)主頁面滿足了設(shè)計(jì)師基本的使用需求，布局中規(guī)中矩，但兩端細(xì)節(jié)差異還是有很多的，雖然是不影響用戶正常使用，但在實(shí)際操作中，設(shè)計(jì)師需要花很多時(shí)間來適應(yīng)兩端頁面和操作的差異，所以在產(chǎn)品評(píng)測過程中一直疑慮：同一套信息和內(nèi)容，為什么要做兩套控制臺(tái)頁面樣式來增加設(shè)計(jì)師的學(xué)習(xí)和使用成本呢？信息內(nèi)容布局的差異化會(huì)影響設(shè)計(jì)師能否快速熟悉功能，操作的差異化會(huì)影響設(shè)計(jì)師的體驗(yàn)感。
為了驗(yàn)證統(tǒng)一性的重要性，我找了市面上主流的設(shè)計(jì)工具做了對(duì)比，如下圖，在多端統(tǒng)一性上（忽略極小的差異化細(xì)節(jié)），他們的共有率達(dá)到了100%，所以足以證明這些產(chǎn)品對(duì)統(tǒng)一性的重視程度。
關(guān)于操作臺(tái)頁面統(tǒng)一性的優(yōu)化方案如下所示：
優(yōu)化點(diǎn)1：兩端的主頁面?zhèn)冗厵诘男畔⒖蚣芸梢员３忠恢拢紫仁莑ogo、用戶賬號(hào)信息的位置；其次是導(dǎo)航菜單的數(shù)量，可以讓用戶在兩端之間切換使用時(shí)，通過統(tǒng)一性加強(qiáng)用戶對(duì)界面的理解
優(yōu)化點(diǎn)2：兩端的右邊操作區(qū)域針對(duì)項(xiàng)目和項(xiàng)目集的管理和篩選，展示方式的多樣性應(yīng)該保持同步，包括配置篩選條件也可以同步；
優(yōu)化點(diǎn)3：兩端關(guān)于全部菜單的功能框架的設(shè)計(jì)，可以在多級(jí)菜單（全部>項(xiàng)目集1>項(xiàng)目集2）和一級(jí)菜單（全部）中二選一，復(fù)用一種設(shè)計(jì)樣式，降低開發(fā)成本；
優(yōu)化點(diǎn)4：兩端關(guān)于“設(shè)計(jì)團(tuán)隊(duì)的切換”的設(shè)計(jì)，網(wǎng)頁端點(diǎn)擊團(tuán)隊(duì)名稱出下拉菜單，進(jìn)行團(tuán)隊(duì)切換，客戶端點(diǎn)擊側(cè)邊欄的用戶名，出現(xiàn)次聯(lián)菜單，再找到團(tuán)隊(duì)切換列表，兩端可以在組件使用和入口方式的設(shè)計(jì)上統(tǒng)一，保證信息內(nèi)容、位置的統(tǒng)一性的前提下，使用可復(fù)用的設(shè)計(jì)樣式，降低開發(fā)成本。
原型設(shè)計(jì)頁面，功能很全面，使用起來很便捷，整理了如下優(yōu)缺點(diǎn)：
爽點(diǎn)1：如文字元素的屬性設(shè)置點(diǎn)非常多，英文大小寫，首航縮進(jìn)等，可設(shè)置的參數(shù)很多；
爽點(diǎn)2：支持畫板響應(yīng)式布局，選中畫板作為對(duì)象時(shí)，可以在屬性面板中進(jìn)行刪除；
爽點(diǎn)3：可以創(chuàng)建項(xiàng)目資源庫，包括顏色、文本、組件等設(shè)計(jì)資源，設(shè)計(jì)更加高效；
問題點(diǎn)1：相對(duì)應(yīng)的屬性列表展開顯示后，模塊空間的沒有充分利用；如圓角這個(gè)參數(shù)可以選擇百分比的樣式，就需要另起一行；
優(yōu)化方案1：屬性面板可以保留比較常用的屬性參數(shù)，新增加的參數(shù)設(shè)計(jì)如果不常用會(huì)占據(jù)空間，且在黑色色彩模式下，信息的閱讀效率會(huì)收到影響
問題點(diǎn)2：右邊整塊屬性面板不支持自適應(yīng)拉伸，位置是固定的，如元素透明度這個(gè)參數(shù)為100%時(shí)，數(shù)字也不能夠顯示全。
優(yōu)化方案2：屬性面板增加自適應(yīng)收縮，會(huì)讓頁面空間更加靈活。
第二個(gè)角度主要是從相關(guān)功能的操作使用流程作為切入點(diǎn)去體驗(yàn)，主要7大核心流程和14個(gè)操作小任務(wù)。
任務(wù)1：在控制臺(tái)頁面找到功能的入口，新建一個(gè)名為“自定義頻道”的項(xiàng)目和兩個(gè)名為“Biuos1.0”、“蘇寧智能終端”的項(xiàng)目集
客戶端操作示例：在首頁菜單，有個(gè)單獨(dú)項(xiàng)目編輯區(qū)域，可以直接點(diǎn)擊進(jìn)行命名和選擇尺寸。在其他菜單下，如果有創(chuàng)建按鈕，均可以點(diǎn)擊，頁面中間會(huì)跳出彈窗，直接對(duì)項(xiàng)目和項(xiàng)目集進(jìn)行創(chuàng)建編輯。
網(wǎng)頁端操作示例：在相關(guān)的菜單中，只要有創(chuàng)鍵按鈕，就可以進(jìn)行創(chuàng)建編輯，僅支持點(diǎn)擊按鈕-跳出彈窗的途徑。
設(shè)計(jì)爽點(diǎn)1：在客戶端，有個(gè)很大的項(xiàng)目創(chuàng)建區(qū)域，用戶可以命名，選擇尺寸，很直觀，增加了項(xiàng)目創(chuàng)建的入口；
設(shè)計(jì)爽點(diǎn)2：網(wǎng)頁端可以創(chuàng)建項(xiàng)目和項(xiàng)目集，客戶端只能創(chuàng)建項(xiàng)目，雖然沒有統(tǒng)一，但是從使用習(xí)慣的角度思考，這個(gè)設(shè)計(jì)還是非常好的，項(xiàng)目集是比項(xiàng)目要大的，根據(jù)設(shè)計(jì)師使用習(xí)慣，考慮到網(wǎng)頁端的網(wǎng)絡(luò)鏈接，大多數(shù)用戶都會(huì)下載客戶端去操作，并且當(dāng)項(xiàng)目責(zé)任人建立好項(xiàng)目集，負(fù)責(zé)相關(guān)模塊的設(shè)計(jì)師就可以專注在項(xiàng)目上，避免了亂建項(xiàng)目集，造成混亂；
體驗(yàn)問題1：兩端的很多基礎(chǔ)導(dǎo)航菜基本都有新建項(xiàng)目或新建項(xiàng)目集按鈕，考慮到用戶在切換不同菜單時(shí)，都能提供這個(gè)入口，雖然能方便用戶操作，但有一些過度引導(dǎo)；
優(yōu)化方案1：減少過度設(shè)計(jì)，菜單應(yīng)匹配相對(duì)應(yīng)的信息需求。例如用戶切到我的收藏菜單，需求就是去查看收藏項(xiàng)目，新建項(xiàng)目就是非必要的選擇，加上就會(huì)變的強(qiáng)行引導(dǎo)；
體驗(yàn)問題2：在創(chuàng)建項(xiàng)目時(shí)，通過彈窗的方式去進(jìn)行創(chuàng)建編輯，這樣會(huì)讓操作流程變得復(fù)雜，而且彈窗中的信息優(yōu)先級(jí)不高，創(chuàng)建結(jié)束后也都可以修改；
優(yōu)化方案2：模態(tài)彈窗對(duì)用戶的干擾程度很高，創(chuàng)建項(xiàng)目應(yīng)該是比較簡單的操作，不需要強(qiáng)干擾的組件去提示用戶，建議可以直接過度到原型設(shè)計(jì)界面。
任務(wù)2：在控制臺(tái)頁面，把項(xiàng)目“自定義頻道”移動(dòng)歸類到“Biuos1.0”的項(xiàng)目集
客戶端操作示例：項(xiàng)目和項(xiàng)目集僅有列表的展示方式，將項(xiàng)目“自定義頻道”移動(dòng)至項(xiàng)目集“Biuos1.0”時(shí)，需要點(diǎn)擊項(xiàng)目中的操作按鈕，彈出操作列表，選擇移動(dòng)，跳出彈窗，選擇項(xiàng)目集確認(rèn)，無二次彈窗確認(rèn)。
網(wǎng)頁端操作示例：項(xiàng)目和項(xiàng)目集有列表和宮格兩種展示方式，將項(xiàng)目“自定義頻道”移動(dòng)至項(xiàng)目集“Biuos1.0”時(shí)，需要點(diǎn)擊項(xiàng)目中的操作按鈕，彈出操作列表，選擇移動(dòng)，跳出彈窗，選擇項(xiàng)目集確認(rèn)，再彈出彈窗二次確認(rèn)。
體驗(yàn)問題1：網(wǎng)頁端和客戶端移動(dòng)項(xiàng)目的過程中，第一次都需要有彈窗，選擇項(xiàng)目集分類，但下一步的操作，網(wǎng)頁端使用模態(tài)彈窗讓用戶二次確認(rèn)，確認(rèn)移動(dòng)成功后有提示。客戶端成功移動(dòng)成功后，沒有提示。
優(yōu)化方案1：結(jié)合兩端的優(yōu)缺點(diǎn)，首先網(wǎng)頁端避免使用確認(rèn)移動(dòng)的二次彈窗，減少操作流程，客戶端移動(dòng)成功后，增加操作提示，提升交互感知。
體驗(yàn)問題2：項(xiàng)目或項(xiàng)目集不可以直接拖拽進(jìn)行移動(dòng)管理操作，只能通過按鈕點(diǎn)擊選擇移動(dòng)選項(xiàng)才能操作，操作比較遲緩。
優(yōu)化方案2：為移動(dòng)操作增加鼠標(biāo)拖拽功能，更加快速的進(jìn)行項(xiàng)目歸類，效率高。
任務(wù)4：選中原型設(shè)計(jì)頁面的左邊功能區(qū)的【頁面】tab，為“自定義頻道”功能創(chuàng)建若干個(gè)頁面，隨機(jī)對(duì)頁面進(jìn)行設(shè)置操作（創(chuàng)建、重命名、移動(dòng)、復(fù)制、刪除、撤銷刪除）
操作示例：點(diǎn)擊「添加」按鈕，可以進(jìn)行頁面創(chuàng)建，選中任一頁面，右擊出現(xiàn)彈框，進(jìn)行選擇重命名、移動(dòng)、復(fù)制、刪除等操作；雙擊頁面標(biāo)題都可以進(jìn)行頁面名修改，拖拽頁面可以進(jìn)行運(yùn)動(dòng)歸類，選中頁面點(diǎn)擊設(shè)備刪除鍵，出現(xiàn)彈窗提示是否刪除。刪除后，設(shè)備無快捷鍵撤銷刪功能。
新建和復(fù)制新頁面后，新頁面變?yōu)楫?dāng)前頁面，且有背景底色，但無法使用設(shè)備刪除鍵直接進(jìn)行刪除操作，需再次點(diǎn)擊選中新頁面，讓文字變?yōu)榧儼咨趴梢詣h除文件。
體驗(yàn)問題1：頁面刪除后沒有進(jìn)行刪除撤銷的快捷鍵“command+z”操作，“撤銷”快捷鍵是設(shè)計(jì)師最常用且依賴度很高的操作。
優(yōu)化方案1：增加“撤銷”快捷鍵的使用。
任務(wù)5：選中原型設(shè)計(jì)頁面的左邊功能區(qū)的【頁面】tab，使用回收站功能、將“某一頁面”刪除再從找回
操作示例：選中某一頁面，進(jìn)行刪除操作確認(rèn)，點(diǎn)擊回收站按鈕，開始回收模式，找到分頁面，鼠標(biāo)懸停在頁面上，顯示恢復(fù)和刪除按鈕，點(diǎn)擊恢復(fù)按鈕，再彈窗確認(rèn)，頁面恢復(fù)。退出回收站模式，才能顯示當(dāng)前所有頁面。
設(shè)計(jì)爽點(diǎn)1：增加“回收站“模式，用戶可以找回頁面，擴(kuò)大了容錯(cuò)范圍；
體驗(yàn)問題1：回收站模式退出的按鈕樣式和工具欄的撤銷重合度高，易混淆；其次這里的回收站模式需要開始和關(guān)閉兩種狀態(tài)，整個(gè)過程中需要2次點(diǎn)擊操作。
優(yōu)化方案1：回收站對(duì)應(yīng)的是頁面，單獨(dú)再加一個(gè)tab對(duì)于信息內(nèi)容切換會(huì)更便捷，省去“回收站”，模式開啟和關(guān)閉的流程。
任務(wù)6：選中原型設(shè)計(jì)頁面的左邊功能區(qū)的【頁面】tab，選擇“自定義標(biāo)簽”頁面，切換到【圖層】tab，對(duì)頁面中的“默認(rèn)狀態(tài)”畫板中的圖層進(jìn)行順序調(diào)整
操作示例：選中畫板其中一個(gè)圖層，然后移動(dòng)到另一個(gè)圖層的上方或下方，調(diào)整圖層順序，但不能進(jìn)行拖拽移動(dòng)，只有置于頂層和底層的按鈕操作。
體驗(yàn)問題1：設(shè)計(jì)師在制作原型圖時(shí)，需要調(diào)整畫板中的圖層順序，置頂或置底的操作不能解決使用者調(diào)整圖層順序的效率問題，移動(dòng)拖拽能靈活快速的給圖層排序。
優(yōu)化方案1：增加鼠標(biāo)拖拽移動(dòng)功能，讓圖層位置的移動(dòng)更加方便。
任務(wù)7：在“自定義標(biāo)簽”頁面編輯區(qū)進(jìn)行畫板的創(chuàng)建、設(shè)備和尺寸選擇、復(fù)制、命名、屬性設(shè)置
操作示例：工具欄中使用“添加輔助畫板”或者快捷鍵A創(chuàng)建畫板，在原型編輯區(qū)域左下角可以進(jìn)行進(jìn)行設(shè)備和尺寸選擇、使用快捷鍵command+c/v、直接雙擊畫板標(biāo)題可以進(jìn)行重命名、選中畫板后，在右側(cè)功能區(qū)域調(diào)整參數(shù)進(jìn)行屬性設(shè)置。
設(shè)計(jì)爽點(diǎn)1：可直接在視圖中雙擊畫板名稱文字，直接選中進(jìn)行修改，不用在圖層頁面找對(duì)應(yīng)頁面進(jìn)行名稱修改，圖層的空間有限，當(dāng)畫板數(shù)量超過之后，就需要上下移動(dòng)來回審查，所以這個(gè)設(shè)計(jì)細(xì)節(jié)讓操作更加聚焦，對(duì)于大批量的畫板名稱修改，很節(jié)省時(shí)間。
體驗(yàn)問題1：畫板設(shè)備和尺寸選擇的優(yōu)先級(jí)高于畫板快捷創(chuàng)建，通過鼠標(biāo)懸停的操作方式呼出多級(jí)菜單分類，交互的可控性比較差。
優(yōu)化方案1：類比市面上其他產(chǎn)品，基本都是快捷鍵A調(diào)出設(shè)備尺寸選擇，而且大多是在屬性面板使用列表下拉的方式展示。快捷鍵“A”的使用對(duì)象可以重新定義，加強(qiáng)快捷創(chuàng)建畫板的優(yōu)先級(jí)，重新設(shè)計(jì)畫板設(shè)備和尺寸選擇的位置和交互出現(xiàn)方式。
體驗(yàn)問題2：在復(fù)制畫板時(shí)，不支持選中畫板后，使用“option+鼠標(biāo)鍵”快捷操作進(jìn)行復(fù)制拖拽，新畫板不能任意的拖拽到自己想要的位置。
優(yōu)化方案2：增加快捷鍵的使用。
任務(wù)8：在“自定義標(biāo)簽”頁面的畫板中利用工具繪制低保真設(shè)計(jì)稿，設(shè)置元素屬性
操作示例：選中自定義頁面，在默認(rèn)狀態(tài)的畫板中對(duì)元素文字、形狀、顏色等屬性參數(shù)進(jìn)行設(shè)置。
例1：在畫板中縮放矩形，設(shè)置面板中的寬高參數(shù)沒有變化；
例2：在屬性中將初始矩形外邊框?qū)挾戎祻摹?”變?yōu)椤?”，但頁面中元素沒有變化，仍然是1，只能在點(diǎn)擊非寬度的參數(shù)任意區(qū)域后，寬度數(shù)值的變化在頁面中才能響應(yīng)；
操作示例：將圖片拖入某畫板內(nèi)，圖片位置在畫版的頂部位置，當(dāng)將畫板拖去來，在左邊功能區(qū)的圖層tab中，圖片還在原來畫板頂部顯示，拖動(dòng)畫版，圖片在畫版外和畫板一起移動(dòng)。
體驗(yàn)問題1：兩個(gè)例子都是屬性面板和畫板聯(lián)動(dòng)無響應(yīng)的問題，不管是畫板中的元素聯(lián)動(dòng)屬性面板的參數(shù)，還是屬性參數(shù)聯(lián)動(dòng)畫板中的元素，都沒有實(shí)時(shí)響應(yīng)。尤其是外邊框的寬度值無法實(shí)時(shí)顯示，這就對(duì)設(shè)計(jì)的效果很難把控。
體驗(yàn)問題2：圖片拖進(jìn)和拖出畫板時(shí)，圖片圖層的歸屬不清晰。
優(yōu)化方案：這兩個(gè)槽點(diǎn)屬于產(chǎn)品的性能問題，可針對(duì)性能這個(gè)點(diǎn)，加強(qiáng)優(yōu)化。
任務(wù)9：在“自定義標(biāo)簽”頁面的畫板中查看元素與元素，元素與畫板，畫板與畫板的距離，進(jìn)行元素和畫板的距離調(diào)整
使用鼠標(biāo)和鍵盤鍵可以查看“默認(rèn)狀態(tài)”畫板中元素的間隔、與相鄰畫板的間隔，在懸停展示間距的同時(shí)去調(diào)整位置距離。
體驗(yàn)問題1：只能查看同一個(gè)畫板中元素之間的距離，無法查看畫板之間的距離，且同畫板中不能在顯示距離間隔的狀態(tài)下，對(duì)元素位置進(jìn)行調(diào)節(jié)。
優(yōu)化方案1：增加設(shè)計(jì)優(yōu)化，完善距離相關(guān)的測量和位置移動(dòng)的操作問題，提升設(shè)計(jì)體驗(yàn)和用戶的原型設(shè)計(jì)效率
任務(wù)10：在“流程圖”頁面中使用流程模式，為“自定義頻道”功能繪制邏輯流程圖
操作示例：在「流程圖」頁面，在工具欄中打開流程圖模式，為“自定義標(biāo)簽”功能畫一個(gè)簡單的邏輯流程圖，梳理業(yè)務(wù)流轉(zhuǎn)的邏輯關(guān)系。
設(shè)計(jì)爽點(diǎn)1：產(chǎn)品內(nèi)置了很多流程圖組件，當(dāng)鼠標(biāo)獲取矩形元素的連接線端點(diǎn)后，開始移動(dòng)至松開鼠標(biāo)結(jié)束，流程組件庫彈窗會(huì)自動(dòng)出現(xiàn)，可以選擇對(duì)應(yīng)的矩形組件。并且制作好摹客RP源文件可以和自帶的PRD文檔工具相關(guān)聯(lián)，選擇帶有流程圖內(nèi)容的畫板，直接轉(zhuǎn)化成圖片導(dǎo)入到文檔中，這個(gè)聯(lián)動(dòng)做的相當(dāng)給力。
任務(wù)11：對(duì)“自定義頻道”功能的原型項(xiàng)目進(jìn)行保存
操作示例：當(dāng)設(shè)計(jì)結(jié)束或中斷時(shí)進(jìn)行項(xiàng)目保存時(shí)，可以使用保存按鈕或者快捷鍵“command+s”對(duì)項(xiàng)目進(jìn)行保存。
體驗(yàn)問題1：當(dāng)用戶保存后，頁面并無明顯的關(guān)于“項(xiàng)目已經(jīng)被保存或者可以實(shí)時(shí)進(jìn)行保存項(xiàng)目”的提示；
優(yōu)化方案1：首先用戶不知道的項(xiàng)目保存的時(shí)效性，可以使用“Toast”提示用戶。
任務(wù)12：為“自定義頻道”功能頁面的跳轉(zhuǎn)和設(shè)置保存創(chuàng)建頁面交互事件
操作示例：在當(dāng)前頻道有內(nèi)容的場景下，開啟調(diào)整模式，移動(dòng)頻道順序，再次確認(rèn)頻道，移動(dòng)跳到頻道顯示或隱藏功能區(qū)域，為頻道自定義設(shè)置創(chuàng)建交互事件，最后使用彈窗對(duì)頻道順序調(diào)整、顯示、隱藏這些操作進(jìn)行數(shù)據(jù)保存；在右邊功能區(qū)的選擇“交互”菜單點(diǎn)擊「添加交互」按鈕，對(duì)事件屬性參數(shù)進(jìn)行設(shè)置。
設(shè)計(jì)爽點(diǎn)1：在使用Axure原型工具時(shí)，通常一個(gè)頁面我們會(huì)使用文字描述主要信息和交互操作；例如，在自定義頻道設(shè)計(jì)的頁面主要就是標(biāo)題、頻道名稱以及狀態(tài)圖標(biāo)，這是顯性化的信息。
對(duì)應(yīng)保存的的操作還有各種隱性信息和操作，比如設(shè)置保存的彈窗，不可操作的提示、網(wǎng)絡(luò)異常的提示等；我們會(huì)使用很多靜態(tài)頁面去描述隱形信息和操作。但摹客RP的原型工具支持的主輔畫板的模式，可直接設(shè)計(jì)交互轉(zhuǎn)場、提示等隱形操作，更直觀的呈現(xiàn)原型設(shè)計(jì)效果。
任務(wù)13：使用播放功能或進(jìn)入摹客協(xié)作模式預(yù)覽“自定義頻道”原型設(shè)計(jì)和交互效果
操作示例：在工具欄點(diǎn)擊播放按鈕，預(yù)覽“自定義頻道”功能的原型設(shè)計(jì)和交互點(diǎn)擊效果；點(diǎn)擊發(fā)布，進(jìn)行項(xiàng)目分類，進(jìn)入慕客協(xié)作網(wǎng)頁端查看所有頁面和畫板以及交互效果。
體驗(yàn)問題1：單獨(dú)演示預(yù)覽時(shí)，視圖窗口只展示頁面，不展示頁面內(nèi)的畫板；在慕客協(xié)作網(wǎng)頁端可以進(jìn)行查看所有內(nèi)容，當(dāng)使用網(wǎng)頁端查看畫板內(nèi)容的過程中，有多次無法快速找到「畫板」入口的場景，查看畫板的入口不是很容易被注意到。
優(yōu)化方案1：演示預(yù)覽狀態(tài)下，增加“查看畫板”的入口，在慕客協(xié)作的網(wǎng)頁端強(qiáng)化“查看畫板”的入口
任務(wù)14：發(fā)送項(xiàng)目或項(xiàng)目集鏈接邀請(qǐng)協(xié)作人，協(xié)作者點(diǎn)開鏈接進(jìn)入原型設(shè)計(jì)頁面
操作實(shí)例：在操控臺(tái)找到“自定義標(biāo)簽”的項(xiàng)目，點(diǎn)擊按鈕找到「成員管理」，跳出彈窗，復(fù)制鏈接，發(fā)給協(xié)作人，協(xié)作者點(diǎn)開鏈接進(jìn)入頁面協(xié)作
體驗(yàn)問題1：項(xiàng)目管理人分享項(xiàng)目鏈接給協(xié)作者，協(xié)作者點(diǎn)擊鏈接直接進(jìn)入原型設(shè)計(jì)頁面進(jìn)行操作編輯，在網(wǎng)頁端從原型設(shè)計(jì)頁面返回到操作臺(tái)頁面后，再點(diǎn)擊項(xiàng)目，無法進(jìn)入原型設(shè)計(jì)頁面；客戶端可以正常操作。
優(yōu)化方案1：打開網(wǎng)頁端重新進(jìn)入頁面的權(quán)限，讓用戶能夠自由進(jìn)入或退出頁面。
這部分通過最常用的7個(gè)交互操作，建立以目標(biāo)為中心的體驗(yàn)流程，再細(xì)分出了14個(gè)操作任務(wù)對(duì)產(chǎn)品進(jìn)行體驗(yàn)說明。操作體驗(yàn)主要聚焦在統(tǒng)一性、功能設(shè)計(jì)、交互操作效率、細(xì)節(jié)設(shè)計(jì)。首先在任務(wù)流程中體驗(yàn)到的爽點(diǎn)設(shè)計(jì)，體驗(yàn)是非常不錯(cuò)的，其次是針對(duì)相關(guān)的一些設(shè)計(jì)問題也有描述并提出自己的優(yōu)化建議。
第三個(gè)角度主要是從設(shè)計(jì)組件來進(jìn)行體驗(yàn)，這部分內(nèi)容主要有如下6個(gè)體驗(yàn)點(diǎn)組成。
網(wǎng)頁端和客戶端對(duì)于導(dǎo)航菜單（“全部”）組件的結(jié)構(gòu)不一致，網(wǎng)頁端的全部菜單下會(huì)展示二級(jí)菜單，客戶端沒有；兩端菜單數(shù)量都不相同；
優(yōu)化建議：導(dǎo)航菜單組件結(jié)構(gòu)和數(shù)量統(tǒng)一。
優(yōu)化建議：兩端的頁面相同圖標(biāo)需要保持一致，包括類型，樣式，統(tǒng)一性，減少差異化，關(guān)于圖標(biāo)設(shè)計(jì)表意要傳達(dá)精準(zhǔn)一點(diǎn)。
新建項(xiàng)目和新建項(xiàng)目集是產(chǎn)品的兩個(gè)重要功能，從功能重要程度來說應(yīng)該是要保持一致的，目前設(shè)計(jì)明顯是新建項(xiàng)目的優(yōu)先級(jí)高于新建項(xiàng)目集，雖然都是用“圖標(biāo)+文字”的按鈕樣式，但圖標(biāo)的樣式過于簡單，且新建文件使用強(qiáng)提示的高亮底色，更能吸引注意力。
競品中，如藍(lán)湖、即時(shí)設(shè)計(jì)、Figma、Pisxo的功能和摹客RP一樣都有新建文件（項(xiàng)目）和新建文件夾（項(xiàng)目集）功能，競品基本都保持相同的設(shè)計(jì)樣式，保證功能優(yōu)先級(jí)是一樣的，僅有mastergo雖然按鈕和摹客RP一樣使用強(qiáng)提示按鈕，但它的功能框架設(shè)計(jì)和摹客RP不一樣。
它創(chuàng)建文件夾的功能放在左邊菜單的創(chuàng)建團(tuán)隊(duì)中，新建文件的按鈕和文件導(dǎo)入是獨(dú)立的，雖然設(shè)計(jì)樣式不一樣，新建按鈕也相對(duì)突出了，文件導(dǎo)入的按鈕還有動(dòng)畫效果。
優(yōu)化建議：可借鑒主流的原型工具類的設(shè)計(jì)方案，平衡功能的優(yōu)先級(jí)，在圖標(biāo)設(shè)計(jì)樣式上讓功能更加形象。
（1）彈窗樣式設(shè)計(jì)的統(tǒng)一性，如新建和刪除項(xiàng)目或項(xiàng)目集時(shí)的彈窗按鈕，它并不是特殊使用場景，都僅需要“確認(rèn)”和“取消”簡單操作，但是鼠標(biāo)懸停文字按鈕上的樣式是不一樣的。一種是加淺灰底色，文字沒變化，另一種是改變字體的透明度。
（2）多次彈窗增加了操作流程，如網(wǎng)頁端項(xiàng)目移動(dòng)時(shí)，會(huì)有二次彈窗確認(rèn)。
優(yōu)化建議：彈窗的按鈕設(shè)計(jì)樣式上可以保持一致，對(duì)于產(chǎn)品中的個(gè)別功能的操作，建議少用或慎用彈窗組件，縮短操作流程。
（1）文件界面的左邊功能區(qū)的“圖層”菜單中包含畫板和圖層信息，這個(gè)標(biāo)題名稱和內(nèi)容不對(duì)應(yīng)，表述不精準(zhǔn)。
（2）頁面刪除的彈窗提示文案沒有給出完整且能防錯(cuò)的的提示，彈窗只提示是否刪除當(dāng)前頁面，并沒有提示用戶如何找回和被刪除文件的去向。
如下例子為操控臺(tái)項(xiàng)目刪除和原型設(shè)計(jì)的頁面刪除：項(xiàng)目刪除的文案：“確定將此次項(xiàng)目加入回收站”，頁面刪除的文案：“確定要?jiǎng)h除當(dāng)前頁面嗎？”
（3）新建項(xiàng)目和新建項(xiàng)目集兩個(gè)按鈕的文案表意不精準(zhǔn)，改為“文件和文件夾”，這樣的表述更簡單明了。
（4）導(dǎo)航收藏菜單名稱不一致，網(wǎng)頁端用“收藏”，客戶端用“我的收藏”，可以統(tǒng)一為“我的收藏”。
優(yōu)化建議：關(guān)于文案部分，主要包括菜單欄、圖標(biāo)、按鈕、彈窗提示文字等應(yīng)用場景，進(jìn)行修改完善。
產(chǎn)品的主色調(diào)很深，沒有淺色色彩模式可以切換，同類的主流產(chǎn)品基本都是默認(rèn)淺色，如即時(shí)設(shè)計(jì)、Masetrgo、Pisxo等都以默認(rèn)淺色界面，F(xiàn)igma更是支持淺色深色切換；
優(yōu)化建議：因?yàn)橛脩魧?duì)顏色的接受和敏感度都不一樣，提供深淺色兩種顏色模式進(jìn)行切換，可以在界面色彩運(yùn)用上滿足不同使用者的需求，若不提供，建議淺色模式，白色在感官上更加干凈、整潔。
設(shè)計(jì)和組件主題包括6個(gè)部分，這些在產(chǎn)品評(píng)測，是很容易被注意的設(shè)計(jì)點(diǎn)，也是產(chǎn)品最基礎(chǔ)的組成元素；它的設(shè)計(jì)呈現(xiàn)決定了用戶的好感度，好的設(shè)計(jì)是需要通過這些元素來表達(dá)它的設(shè)計(jì)原則和理念；組件的設(shè)計(jì)和使用也是要合理和克制的；例如導(dǎo)航菜單和圖標(biāo)設(shè)計(jì)應(yīng)該在網(wǎng)頁端和客戶端保持一致；文案表述的應(yīng)該精準(zhǔn)、簡單、明了；按鈕和彈窗設(shè)計(jì)也可以再克制一點(diǎn)，色彩模式需要干凈簡潔，最大程度的減少對(duì)用戶的干擾，提升用戶的粘性。
以上就是四周產(chǎn)品測試總結(jié)分享了，這篇測評(píng)文章主要是從交互的三個(gè)角度：頁面框架、頁面操作流程、頁面組件設(shè)計(jì)，通過深度使用和體驗(yàn)這款產(chǎn)品，從中提煉出一些想法和建議，這里就個(gè)人使用體驗(yàn)做出以下終結(jié)。
摹客RP這款原型設(shè)計(jì)工具與視覺、產(chǎn)品的關(guān)聯(lián)性方面設(shè)計(jì)的很好：作為一款原型設(shè)計(jì)軟件，它的功能很豐富，覆蓋了設(shè)計(jì)師做原型設(shè)計(jì)的大部分場景，能利用視覺思維發(fā)揮產(chǎn)品優(yōu)勢，在項(xiàng)目協(xié)作，橫向和產(chǎn)品相關(guān)的工作內(nèi)容進(jìn)行關(guān)聯(lián)。
這一點(diǎn)在產(chǎn)品體驗(yàn)中感覺是十分明顯的，設(shè)計(jì)工具軟件，基本都有網(wǎng)頁端和客戶端的，控制臺(tái)頁面都不會(huì)進(jìn)行差異化設(shè)計(jì)，所以當(dāng)?shù)谝淮卧诓煌舜蜷_摹客RP控制臺(tái)頁面時(shí)，呈現(xiàn)出的是不一樣的內(nèi)容，我的第一印象是：有這么多不一樣的地方啊，我要花點(diǎn)時(shí)間再看看對(duì)比下？我剛才的那些操作入口在哪里啊？
在交互操作上產(chǎn)品要有暢通感，即操作起來夠舒服，能夠給予操作有效提示，能夠在進(jìn)行任務(wù)操作時(shí)有效率；
在摹客RP體驗(yàn)過程中，注意到很多設(shè)計(jì)細(xì)節(jié)，有很多不錯(cuò)的地方，也有很多需要優(yōu)化完善的設(shè)計(jì)點(diǎn)，如下所述；
第二點(diǎn)產(chǎn)品性能問題，很多交互操作過度不自然，轉(zhuǎn)場太快，無狀態(tài)結(jié)果的反饋，操作生硬；還有原型設(shè)計(jì)畫板、元素和屬性面板參數(shù)的聯(lián)動(dòng)很差；第三點(diǎn)是項(xiàng)目原型設(shè)計(jì)中的關(guān)于元素相關(guān)的設(shè)計(jì)點(diǎn)，包括圖片的圖層歸屬問題，距離的測量等。
總的來說摹客RP是一款比較專業(yè)且實(shí)用性很強(qiáng)的的設(shè)計(jì)協(xié)作軟件，他基本兼容了原型設(shè)計(jì)軟件“Axure”的大部分功能，也適合團(tuán)隊(duì)協(xié)作中進(jìn)行使用和推廣，但隨著市面上的競品越來越多，后續(xù)的競爭推廣也會(huì)越演越烈，所以個(gè)人認(rèn)為產(chǎn)品應(yīng)該做好以下兩點(diǎn)，會(huì)增加自己產(chǎn)品的優(yōu)勢；首先工具可以輕量化，注重常用功能的用戶體驗(yàn)和產(chǎn)品的性能優(yōu)化。
其次作為一款設(shè)計(jì)協(xié)作軟件，面向的是廣大設(shè)計(jì)師，產(chǎn)品細(xì)節(jié)方面的問題特別容易被設(shè)計(jì)師捕捉。所以需要著重把控這兩點(diǎn)，進(jìn)行積極的推廣助力，才好抓住設(shè)計(jì)的心！這里也祝摹客系產(chǎn)品能越做越好！
本文為2022摹客RP原型工具測評(píng)大賽的測評(píng)文章，如對(duì)摹客RP感興趣可點(diǎn)擊體驗(yàn)鏈接：https://www.mockplus.cn/rp-event/?hmsr=woshipmqianwei
本文由 @Q什伍 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理，未經(jīng)作者許可，禁止轉(zhuǎn)載。
題圖來自 Unsplash，基于CC0協(xié)議。
該文觀點(diǎn)僅代表作者本人，人人都是產(chǎn)品經(jīng)理平臺(tái)僅提供信息存儲(chǔ)空間服務(wù)。
輯導(dǎo)語：對(duì)于團(tuán)隊(duì)產(chǎn)品知識(shí)庫產(chǎn)品，想必大家都不陌生，但是很少有人能夠系統(tǒng)地去管理自己的知識(shí)。因此，作者思考了關(guān)于團(tuán)隊(duì)知識(shí)管理的四個(gè)問題，并對(duì)市場上的知識(shí)庫產(chǎn)品進(jìn)行了比對(duì)，與大家分享，希望對(duì)大家有所幫助。
知識(shí)管理相信大家并不陌生，但我在身邊簡單調(diào)研一圈之后發(fā)現(xiàn)，大部分人沒有系統(tǒng)的去管理自己的知識(shí)。在工作之余的閱讀過程中，我接觸到盧曼的卡片筆記法，接觸到obsidian、Notion，并且嘗試構(gòu)建自己的知識(shí)外腦。
個(gè)人知識(shí)管理我們后面可以單獨(dú)有一篇文章詳細(xì)闡述。今天想聊一下團(tuán)隊(duì)知識(shí)管理，在經(jīng)歷了很多次找歷史資料找不到的痛苦之后，我決心要打造一個(gè)團(tuán)隊(duì)共有的知識(shí)庫系統(tǒng)。一方面提升團(tuán)隊(duì)效率，一方面避免重復(fù)工作。
為此，我主要思考了四個(gè)問題，并且比對(duì)了市場上知識(shí)庫產(chǎn)品，和大家分享一下，供大家參考。
團(tuán)隊(duì)知識(shí)管理這一概念很少單獨(dú)拎出來說，目前團(tuán)隊(duì)知識(shí)管理經(jīng)常和文檔管理產(chǎn)品、協(xié)同辦公產(chǎn)品耦合在一起。由于很難找到純粹知識(shí)管理的行業(yè)報(bào)告，我們可以看一下市場上的文檔管理賽道的玩家。
文檔管理產(chǎn)品圖譜，圖源：甲子光年
這份甲子的報(bào)告里并不完全全面。除了上面列舉的部分文檔管理產(chǎn)品可以劃在知識(shí)管理產(chǎn)品范圍內(nèi)，還有包括一些新晉的知名玩家，比如釘釘文檔的團(tuán)隊(duì)空間、飛書文檔的知識(shí)庫、海外的知名產(chǎn)品Notion、Confluence等。
知識(shí)庫產(chǎn)品百度指數(shù)
我們可以看一下百度指數(shù)，知識(shí)庫這個(gè)概念非常少有人索引，而在知識(shí)庫產(chǎn)品里，石墨文檔相對(duì)熱度最高。
我們可以粗略的統(tǒng)計(jì)一下知識(shí)管理的市場。根據(jù)艾瑞咨詢的研究報(bào)告，2020年國內(nèi)協(xié)同辦公市場是440億元，一直以來爆火的短視頻去年國內(nèi)市場規(guī)模是1300億左右，這樣對(duì)比大家可以感受一下協(xié)同辦公的市場具體有多大。
而協(xié)同辦公產(chǎn)品包含：文檔協(xié)同、企業(yè)網(wǎng)盤、項(xiàng)目協(xié)同、會(huì)議系統(tǒng)、OA協(xié)同平臺(tái)等等。知識(shí)管理只是協(xié)同辦公的非常小一部分的市場。這樣我們能進(jìn)一步感受到知識(shí)管理的市場規(guī)模其實(shí)真的不大。
客戶通常都知道知識(shí)管理很重要，但只有在他們遇到：明知道某個(gè)歷史檔案能解決他們眼前問題，但就是找不到這個(gè)資料的時(shí)候。他們才會(huì)對(duì)整理團(tuán)隊(duì)知識(shí)有更感性的認(rèn)識(shí)，或者說更痛的領(lǐng)悟。
我看下來管理知識(shí)困難主要有幾點(diǎn)原因：
首先，知識(shí)的創(chuàng)造困難。
創(chuàng)造知識(shí)的過程是反人性的，這是不能看到即時(shí)反饋的一件事。大部分團(tuán)隊(duì)成員不愛寫總結(jié)文檔，工作也許可以干的很漂亮，但留下的東西非常的少。因?yàn)閺墓ぷ鞯慕嵌龋?xiàng)目交付完了，客戶或者用戶滿意了，在團(tuán)隊(duì)成員心里就算了事了，文檔整理工作在他們心里屬于分外之事。
其次，知識(shí)的維護(hù)困難。
維護(hù)團(tuán)隊(duì)資料的過程是對(duì)抗熵增的過程。熵增指的是：在一個(gè)封閉空間內(nèi)，事物會(huì)走向混亂和無序，并且不可逆。就比如一個(gè)倉庫如果沒有人管理，一定會(huì)越來越亂。
團(tuán)隊(duì)知識(shí)庫也是一樣。傳統(tǒng)的文檔管理流于表面，企業(yè)也許會(huì)有自己的資料庫，但很可能“XX項(xiàng)目文檔”文件夾下完全就是空的。按項(xiàng)目管理知識(shí)里的說法，就是沒有維護(hù)好組織過程資產(chǎn)。
知乎上經(jīng)典好文里經(jīng)常出現(xiàn)這樣一句評(píng)論：躺在我的收藏夾里吃灰去吧。大家看到好東西，第一反應(yīng)會(huì)把他們收集起來，但維護(hù)和利用就非常少了。
最后，知識(shí)的快速查找和調(diào)用困難。
當(dāng)知識(shí)庫內(nèi)容不全，陳舊無效，搜索的結(jié)果不精準(zhǔn)，無法導(dǎo)出轉(zhuǎn)發(fā)，這些都會(huì)極大打擊我們使用知識(shí)庫的熱情。我們發(fā)現(xiàn)知識(shí)庫存在但無法提升我們的工作效率時(shí)，這個(gè)知識(shí)庫基本就算失敗了。
市場上的知識(shí)庫產(chǎn)品，能不能幫助團(tuán)隊(duì)管理好知識(shí)呢？
我選擇幾種知識(shí)庫產(chǎn)品，從6個(gè)功能維度去對(duì)比市場上的知識(shí)庫產(chǎn)品。我認(rèn)為好的知識(shí)庫產(chǎn)品這六方面都需要相對(duì)出色：工具、模板、協(xié)同、安全、搜索、導(dǎo)出。
我們前面說了，創(chuàng)造知識(shí)困難。作為團(tuán)隊(duì)知識(shí)庫，首先要解決的是內(nèi)容的輸入。內(nèi)容的來源有兩種：即時(shí)創(chuàng)造和外部遷移。
即時(shí)創(chuàng)造面向的是新知識(shí)。主要考量的是知識(shí)庫產(chǎn)品編輯器能力。如果能讓用戶更簡單便捷的編輯文字，編輯器工具屬性能讓用戶感覺到爽的話，無疑是會(huì)提升用戶的創(chuàng)造意愿的。
外部遷移指的是陳舊知識(shí)或者歷史資料。主要是能支持歷史數(shù)據(jù)的遷移進(jìn)入知識(shí)庫。
我們先看各家即時(shí)創(chuàng)造的能力，也就是產(chǎn)品編輯器能力。
（1）頁面布局
釘釘?shù)木庉嬈骱蛡鹘y(tǒng)的word編輯器布局類似，功能區(qū)出現(xiàn)在編輯器上方，由于大部分人都長期使用微軟的Word，這種布局符合用戶習(xí)慣。
圖中綠色部分可以看到釘釘?shù)奈臋n支持部分的塊狀編輯。塊狀編輯最大的好處是結(jié)構(gòu)的靈活，便于用戶調(diào)整文檔前后文結(jié)構(gòu)。
釘釘可能是為了滿足不同用戶編輯體驗(yàn)，在功能欄右側(cè)設(shè)計(jì)了縮進(jìn)按鈕，縮進(jìn)之后保留核心功能在功能欄，這樣可以營造更簡潔的頁面。
釘釘文檔
如果說簡潔畫風(fēng)，石墨文檔可以單獨(dú)拿出來。石墨的整體頁面簡約直接，按鈕加了陰影，整體是灰色系的性冷淡風(fēng)。支持創(chuàng)建傳統(tǒng)文檔和文檔。石墨文檔頁面看下來讓人覺得舒適，中間的功能欄沒有影響到整體的整潔簡約的體驗(yàn)。
石墨文檔
而飛書、Notion、Confluence的布局就脫離了微軟系的畫風(fēng)。特別是作為口碑非常好的Notion，幾乎是一個(gè)全新的編輯界面。Notion是非常明顯的塊狀編輯，所有的板塊依托塊狀組件化呈現(xiàn)，同時(shí)頁面風(fēng)格靈動(dòng)，和目前大部分文檔產(chǎn)品截然不同。
Notion
飛書和Notion一樣完全支持塊狀編輯，而Confluence并未使用塊狀編輯。頁面布局的創(chuàng)新可以給用戶帶來新鮮感，但對(duì)于習(xí)慣了微軟Word的用戶來說，也許會(huì)反而有一些阻礙。
百度俞軍說過，產(chǎn)品價(jià)值=（新體驗(yàn) – 舊體驗(yàn)） – 替換成本。編輯器頁面作為最直觀的窗口，這部分的顛覆一定會(huì)帶來較高的替換成本。
Confluence
飛書輸入方式石墨文檔和釘釘將整個(gè)功能區(qū)列在主屏上方，無疑是能讓用戶所見即所得的處理文檔。
我們一系列常用的標(biāo)題、對(duì)齊、插入、字體選擇等功能可以一鍵觸達(dá)，同時(shí)也支持Markdown編輯輸入。他們的做法是，同時(shí)支持傳統(tǒng)文檔和新式文檔。傳統(tǒng)文檔的輸入和微軟Word的輸入方式保持一致，新式文檔的輸入則是塊狀編輯加上支持Markdown輸入。
而對(duì)于Notion、Confluence、飛書這幾款產(chǎn)品，編輯頁面會(huì)做更簡潔，但非常依賴Markdown編輯，這就需要用戶去熟悉Markdown的編輯語法。
對(duì)于程序員群體來說，相信這是一個(gè)他們非常熱愛的輸入方式，但是對(duì)于大部分用戶來說，相信這還是一個(gè)相對(duì)新的概念。
Markdown輸入最大的好處就在于，你在碼字編輯文檔的時(shí)候，不需要移開右手去點(diǎn)擊鼠標(biāo)。毫無疑問這可以提升輸入效率，但是提高了準(zhǔn)入門檻。
插入功能插入這個(gè)功能，同樣是每個(gè)產(chǎn)品都引入的。我們可以非常直觀的對(duì)比各家的優(yōu)劣。
通常我們?cè)趙ord編輯器里常用的是插入圖片、表格。新一代的知識(shí)管理產(chǎn)品在插入功能上做的都很好，比如釘釘除了支持常規(guī)的圖片、表格，還支持腦圖、原型圖、代碼塊等等。
（2）外部文件導(dǎo)入
在知識(shí)庫管理的過程中，我們一定會(huì)存在一些老文檔需要入庫。
Notion目前支持12種類型文件，其中包括競爭對(duì)手印象筆記和Confluence。
石墨文檔和飛書支持本地文件夾上傳，簡單粗暴，看起來很好用，但本質(zhì)是起到網(wǎng)盤的作用，并不利于用戶管理。
而釘釘目前僅支持word和excel的導(dǎo)入，以及文件夾打包上傳，Confluence只支持word和google文檔。對(duì)于工具部分，我們用一個(gè)表格總結(jié)一下。
單從產(chǎn)品編輯的能力上看，目前釘釘?shù)奈臋n編輯能力頁面最接近office用戶的使用習(xí)慣，基本能滿足圖片、原型圖、設(shè)計(jì)稿、腦圖、表格等常用功能的插入，同時(shí)也兼顧Markdown的編輯方式。
但從外部導(dǎo)入文件的能力依然需要繼續(xù)提升，目前支持Word和Excel文件導(dǎo)入，以及支持文件夾打包上傳。
飛書走的路線是依賴Markdown編輯方式，這對(duì)于從Office用戶引流可能會(huì)有一些困難，并且對(duì)外部導(dǎo)入文件的能力也需要提升，飛書支持的是文件和文件夾上傳，這種方式非常便捷。
但從知識(shí)管理的角度看只完成了其中的收集功能，知識(shí)管理除了收集應(yīng)該還有科學(xué)命名，文件篩選入庫等等功能需要設(shè)計(jì)。
石墨文檔和Confluence的編輯體驗(yàn)和閱讀體驗(yàn)很好，基礎(chǔ)的編輯功能很完善，但在功能創(chuàng)新方面還略顯不足，同時(shí)在文件導(dǎo)入方面都需要進(jìn)行提升。
Notion在產(chǎn)品編輯能力這一項(xiàng)上綜合看相對(duì)完善，無論是編輯能力還是遷移導(dǎo)入的能力都很優(yōu)秀，對(duì)于習(xí)慣使用塊狀編輯和Markdown輸入的用戶，Notion可以說領(lǐng)先其他產(chǎn)品半個(gè)身位。
為了幫助用戶更好的創(chuàng)造知識(shí)，除了有滿足用戶體驗(yàn)的設(shè)計(jì)器產(chǎn)品，我期待的是還需要有加速用戶創(chuàng)作的文檔模板，并且模板質(zhì)量要高。目前模板功能也是各家都有的，我們對(duì)比來看。
飛書和釘釘?shù)漠a(chǎn)品模板分為兩部分：知識(shí)庫模板和文檔模板。
釘釘模板
兩個(gè)產(chǎn)品支持創(chuàng)建不同屬性的團(tuán)隊(duì)空間或者知識(shí)庫，并且團(tuán)隊(duì)空間里為用戶整理好了對(duì)應(yīng)模板，除此之外，二者支持新建文檔時(shí)候以模板的形式創(chuàng)建。
值得一提的是，飛書的模板能支持類似Airtable的多維表格，這和他的塊狀編輯能力密不可分，這樣一來飛書模板的靈活性會(huì)更大。石墨文檔、Notion和Confluence只支持文檔模板創(chuàng)建。
Confluence模板
Notion模板
在模板這一層面，各家產(chǎn)品看下來基本都能滿足用戶需求。
飛書和釘釘?shù)闹R(shí)庫空間模板的預(yù)整理能讓用戶更好的上手。而Notion和Confluence在模板的處理上會(huì)有更多的靈活度。特別是Notion對(duì)Airtable的集成，能讓用戶在一個(gè)文檔上玩出很多花樣。
到了協(xié)同層面，我們考慮的是團(tuán)隊(duì)成員如何更好的維護(hù)知識(shí)庫，這一點(diǎn)上協(xié)同辦公平臺(tái)具有天然優(yōu)勢。
協(xié)同主要分為兩步：
第一步是組建知識(shí)庫團(tuán)隊(duì)。
在第一步，釘釘和飛書就憑借辦公產(chǎn)品的屬性跑在前面，這兩者可以直接打通內(nèi)部團(tuán)隊(duì)通訊錄，簡單便捷的把知識(shí)庫團(tuán)隊(duì)成員組建好。而Notion、Confluence、石墨則是需要通過郵件邀請(qǐng)其他人加入團(tuán)隊(duì)。
第二步是知識(shí)庫團(tuán)隊(duì)共同維護(hù)知識(shí)庫。
比如，知識(shí)庫內(nèi)容的刪改都被記錄，支持評(píng)論互動(dòng)等。這樣能更好的讓大家參與到知識(shí)庫的建設(shè)中。
釘釘支持知識(shí)庫內(nèi)@團(tuán)隊(duì)成員，支持段落和劃線評(píng)論，同時(shí)能夠把釘釘內(nèi)部群聊鏈接導(dǎo)入到知識(shí)庫文檔里。這在一部分飛書和釘釘二者的功能類似。
關(guān)于這部分功能，目前二者都只是加了群鏈接的跳轉(zhuǎn)。而我相信更有沉淀價(jià)值的可能是群聊里的某段聊天記錄。目前二者在這處理的都有點(diǎn)粗糙。
釘釘額外考慮到的是，在團(tuán)隊(duì)空間里能夠插入項(xiàng)目進(jìn)度，這可以及時(shí)和項(xiàng)目保持協(xié)同聯(lián)動(dòng)。而飛書在協(xié)同的部分，考慮的是支持插入日程和投票。
Notion、Confluence、石墨文檔三者承載的OA功能比較少，基本只能在知識(shí)庫空間范圍內(nèi)和隊(duì)友互動(dòng)。
但是不代表這些產(chǎn)品沒有考慮協(xié)同的問題，Notion和Confluence能夠進(jìn)入Slack生態(tài)，Slack是目前和微軟Teams競爭的辦公產(chǎn)品，在全球有非常不錯(cuò)的用戶基礎(chǔ)。Notion和Confluence能夠依托Slack彌補(bǔ)協(xié)同的短板。
石墨文檔同樣集成在釘釘生態(tài)，能夠從釘釘生態(tài)直接訪問，也也加強(qiáng)了石墨文檔的協(xié)同能力。
但總體來說飛書和釘釘，依托用戶數(shù)和OA系統(tǒng)，形成相對(duì)完善的產(chǎn)品矩陣，能夠更大價(jià)值的發(fā)揮協(xié)同作用。而Notion、石墨文檔、Confluence在知識(shí)庫的特性上更純粹，協(xié)同能力會(huì)稍弱一些。
對(duì)于文檔安全方面，我考慮的是知識(shí)庫內(nèi)容的創(chuàng)建、查閱、轉(zhuǎn)發(fā)需要有權(quán)限系統(tǒng)進(jìn)行約束。一方面能保證團(tuán)隊(duì)信息安全，一方面能更好的保證知識(shí)庫內(nèi)容的質(zhì)量。
Notion和Confluence的安全模塊作為付費(fèi)內(nèi)容沒有辦法體驗(yàn)，可以看到產(chǎn)品設(shè)計(jì)也是考慮了文檔安全因素的。而石墨文檔在知識(shí)安全上考慮并不是很完全，僅支持空間權(quán)限設(shè)置，這也是石墨文檔需要提升的。
釘釘和飛書同為協(xié)同辦公產(chǎn)品，在安全能力上是優(yōu)于純知識(shí)庫產(chǎn)品的。目前飛書限制導(dǎo)出、打印、創(chuàng)建副本和復(fù)制。釘釘支持訪客水印、限制復(fù)制、私密文檔、權(quán)限繼承等。二者都在文檔安全上有自己的思考。
關(guān)于安全這部分，Notion、Confluence和石墨文檔都需要再深入思考一下。
對(duì)搜索部分的期待主要就是搜的準(zhǔn)，支持自定義的搜索。毫無疑問搜索能夠幫助用戶更好的使用知識(shí)庫。
這里我們就要說一下為什么不要用PC本地做知識(shí)管理，因?yàn)槲臋n內(nèi)部的內(nèi)容是完全無法檢索到的，這樣的檢索能力相對(duì)就弱很多了。而目前知識(shí)庫產(chǎn)品大部分是可以同時(shí)檢索標(biāo)題和內(nèi)容的。
飛書搜索
釘釘搜索
石墨文檔搜索
Notion搜索
Confluence搜索
可以看到知識(shí)庫產(chǎn)品對(duì)于空間內(nèi)文檔搜索能力不錯(cuò)。而且搜索精度也能滿足使用需求。
在搜索的篩選規(guī)則上，石墨文檔、飛書、Noiton、Confluence都支持更為細(xì)節(jié)的篩選，比如根據(jù)創(chuàng)建時(shí)間、文檔類型、修改時(shí)間等進(jìn)行搜索。
目前釘釘團(tuán)隊(duì)空間的搜索準(zhǔn)確度很高，篩選規(guī)則的功能設(shè)計(jì)偏少。而讓人感覺不一樣的地方是，針對(duì)文檔索引，釘釘采用了其他產(chǎn)品沒有的首頁輔助腦圖架構(gòu)的方式管理文檔，以便用戶更快索引和知識(shí)記憶。
在新建知識(shí)庫的過程中，知識(shí)庫會(huì)自動(dòng)生成知識(shí)庫首頁，知識(shí)庫文件的標(biāo)題名會(huì)自動(dòng)生成思維導(dǎo)圖出現(xiàn)在首頁里。同時(shí)給腦圖加了跳轉(zhuǎn)鏈接，這個(gè)設(shè)計(jì)很獨(dú)特。
釘釘團(tuán)隊(duì)空間首頁
最后一個(gè)環(huán)節(jié)，導(dǎo)出。知識(shí)庫的文檔經(jīng)常會(huì)碰到需要導(dǎo)出轉(zhuǎn)發(fā)的場景，比如導(dǎo)出一份合同去簽署，如果導(dǎo)出的類型受限，導(dǎo)出的格式混亂的話，這肯定是不能接受的。
從導(dǎo)出這一功能看，能夠?qū)С鯬DF和Word這兩類常見文件，產(chǎn)品基本就合格了。目前知識(shí)庫產(chǎn)品都能基本滿足需求。
我們?cè)诟骷耶a(chǎn)品綜合能力上做一個(gè)總結(jié)。
釘釘?shù)膱F(tuán)隊(duì)空間產(chǎn)品形態(tài)兼顧創(chuàng)新和兼容，更符合微軟Office用戶的編輯習(xí)慣，這樣帶來的好處是能夠更平滑的將用戶從微軟Office引流。
其次，釘釘?shù)霓k公工具屬性可以與知識(shí)管理更好地融合，以文檔為核心天然形成知識(shí)庫，釘釘?shù)膱F(tuán)隊(duì)空間能減小協(xié)同的障礙，日常聊天記錄里的工作文檔，可以快速的轉(zhuǎn)入團(tuán)隊(duì)空間進(jìn)行管理。
并且釘釘團(tuán)隊(duì)空間對(duì)知識(shí)庫內(nèi)知識(shí)安全考慮的更為細(xì)致，能夠讓人放心的保證團(tuán)隊(duì)知識(shí)的私密性。作為目前在線組織數(shù)最多的辦公產(chǎn)品，可以感受得到釘釘在協(xié)同辦公上的深厚積累，對(duì)知識(shí)庫建設(shè)來說是強(qiáng)大助力，對(duì)于其他產(chǎn)品來說也是不小的壓力。
Notion是可玩性非常高的產(chǎn)品，all-in-one的理念也圈粉不少用戶。Notion的塊狀編輯和豐富的插入組件儼然是很多同類產(chǎn)品模仿的對(duì)象，可拖拽的塊狀編輯讓頁面非常的靈動(dòng)，支持Airtable式的表格插入更是為產(chǎn)品拓展了表格能力。
但是用好Notion是需要一定極客精神的，Notion更像是少數(shù)派的效率工具，而不是普適的文檔管理工具。純粹地把Notion當(dāng)成Word用會(huì)讓人覺得非常浪費(fèi)這個(gè)產(chǎn)品。
而Notion非常依賴Slack補(bǔ)充他的協(xié)同能力，這就需要Notion和Slack同時(shí)非常優(yōu)秀，才有更大的競爭力。
目前Notion只支持英文和韓文，網(wǎng)上有一些非官方漢化方式，在一些語言細(xì)節(jié)處理上還有一些問題。Notion如果完全漢化，并且做好教程，綁定協(xié)同辦公平臺(tái)的話，對(duì)本土的文檔、知識(shí)庫產(chǎn)品一定會(huì)帶來較大沖擊。
飛書的知識(shí)庫在編輯上依賴Markdown編輯，并且有一些塊狀設(shè)計(jì)和Notion是趨同的，可以看到產(chǎn)品設(shè)計(jì)的過程是想要改變用戶輸入習(xí)慣的。
出身于辦公系統(tǒng)的飛書知識(shí)庫，在安全性上做了一定的考慮，而在知識(shí)庫搜索功能上，飛書看起來考慮的也很深入。對(duì)于釘釘和飛書這兩個(gè)協(xié)同辦公產(chǎn)品來說，自成生態(tài)的建設(shè)知識(shí)庫一定是最簡單高效的。
Confluence可以說是純知識(shí)庫產(chǎn)品的代表，編輯頁面簡潔，功能相對(duì)豐富。知識(shí)庫生態(tài)組件完善。
然而，和Notion一樣，全英文模板絕對(duì)會(huì)把一大部分人擋在門外。然后網(wǎng)頁打開時(shí)間較長，這也是一個(gè)不利因素。
石墨文檔的頁面風(fēng)格是讓人蠻喜歡的，當(dāng)然這個(gè)相對(duì)主觀，也不保證會(huì)不會(huì)時(shí)間長看了覺得略微單調(diào)。
從產(chǎn)品實(shí)用性來說，石墨文檔一直穩(wěn)扎穩(wěn)打有著比較好的應(yīng)用基礎(chǔ)。對(duì)于視頻、地圖的直接集成可以極大的提升閱讀體驗(yàn)，讓人驚喜的一鍵回溯功能可以做好版本管理，不得不說石墨文檔在產(chǎn)品細(xì)節(jié)上是花了心思的，百度指數(shù)相對(duì)最高也說明了石墨文檔產(chǎn)品口碑。但插入的組件類型不足，會(huì)讓人稍感缺憾。
創(chuàng)建團(tuán)隊(duì)空間，管理團(tuán)隊(duì)知識(shí)庫在我眼里是很重要的一件事，也是一件難而正確的事。我們要怎么才能在內(nèi)部用好知識(shí)庫產(chǎn)品。
我們?cè)谇懊娼榻B了各家產(chǎn)品能力，如果團(tuán)隊(duì)成員都很Geek，對(duì)新鮮事物有探索的好奇心，可以考慮使用Notion。
如果團(tuán)隊(duì)成員更穩(wěn)健一些，并且已經(jīng)在公司內(nèi)部使用了釘釘、飛書這類產(chǎn)品，毫無疑問，用釘釘?shù)膱F(tuán)隊(duì)空間和飛書的知識(shí)庫更合適。
如果對(duì)知識(shí)管理和協(xié)同辦公的交集很小的話，石墨文檔和confluence作為非常專業(yè)的知識(shí)庫產(chǎn)品也是很好的選擇。
Notion和Confluence是海外的產(chǎn)品，使用這二者的話需要考慮語言差異的問題。
同時(shí)，在選擇的時(shí)候也需要考慮產(chǎn)品費(fèi)用，目前notion、石墨文檔、Cofluence對(duì)于一定人數(shù)規(guī)模的團(tuán)隊(duì)是會(huì)收費(fèi)的。而釘釘和飛書的使用成本更低一些。
我們都知道，讓員工在工作之余進(jìn)行文檔總結(jié)，創(chuàng)造整理是一件非常反人性的事情，是對(duì)抗熵增這一自然規(guī)律的事情。那么打破熵增的辦法是什么？那就是打破封閉空間。引入外部激勵(lì)。
我們可以建立一套機(jī)制，鼓勵(lì)團(tuán)隊(duì)成員維護(hù)知識(shí)庫。比如建立一套積分機(jī)制，新建一篇文章獲取一定積分，為其他人文章評(píng)論、點(diǎn)贊、舉報(bào)獲取一定積分，文章閱讀量、點(diǎn)贊量達(dá)到一定數(shù)值獲取一定積分。最后用積分作為考核標(biāo)準(zhǔn)，獲得額外的獎(jiǎng)勵(lì)。這個(gè)獎(jiǎng)勵(lì)最好不要和工資掛鉤，很容易被噴卷。
這里只是一個(gè)建議，所有的機(jī)制都應(yīng)該是為了讓團(tuán)隊(duì)成員注重知識(shí)管理，培養(yǎng)知識(shí)管理的習(xí)慣。
團(tuán)隊(duì)管理在團(tuán)隊(duì)初期是一件附加值很低的事情，很多團(tuán)隊(duì)選擇不關(guān)心。這就很像團(tuán)隊(duì)文化一樣，一家企業(yè)在創(chuàng)業(yè)初期都是野蠻生長，基本沒人會(huì)關(guān)心企業(yè)文化，也不會(huì)關(guān)心團(tuán)隊(duì)知識(shí)沉淀。而當(dāng)公司快速發(fā)展具備一定規(guī)模時(shí)，還能凝聚大家在一起往前走的，一定是企業(yè)文化。
我們會(huì)說阿里人、華為人、騰訊人，這個(gè)標(biāo)簽貼完，你會(huì)自然對(duì)這個(gè)群體有一種固化的認(rèn)知，這就是梁寧說的集體人格，背后本質(zhì)是企業(yè)文化的引導(dǎo)。同樣，團(tuán)隊(duì)發(fā)展到一定規(guī)模，沒有誰會(huì)繼續(xù)無視團(tuán)隊(duì)知識(shí)管理。
而無論協(xié)同辦公產(chǎn)品釘釘、飛書，還是面向未來的工具Notion，亦或是專業(yè)的知識(shí)庫Confluence。在知識(shí)管理上只能做到“術(shù)”的幫助，而真正管理好知識(shí)更需要“道”和“法”的引導(dǎo)和規(guī)范。
希望這邊文章對(duì)你有幫助，下一次我們?cè)倭囊幌聜€(gè)人知識(shí)管理，也聊一聊知識(shí)管理的“道”和“法”。
忙里偷賢，公眾號(hào)：忙里偷賢，人人都是產(chǎn)品經(jīng)理專欄作家。B端產(chǎn)品，低代碼玩家，工具類產(chǎn)品思考者。熱愛分享，務(wù)實(shí)的理想主義者。
本文原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理，未經(jīng)許可，禁止轉(zhuǎn)載。
題圖來自 Pexels，基于CC0協(xié)議
ython 風(fēng)格規(guī)范(Google)
本項(xiàng)目并非 Google 官方項(xiàng)目, 而是由國內(nèi)程序員憑熱情創(chuàng)建和維護(hù)。
如果你關(guān)注的是 Google 官方英文版, 請(qǐng)移步 Google Style Guide
以下代碼中 Yes 表示推薦，No 表示不推薦。
分號(hào)
不要在行尾加分號(hào), 也不要用分號(hào)將兩條命令放在同一行。
行長度
每行不超過80個(gè)字符
以下情況除外：
不要使用反斜杠連接行。
Python會(huì)將 圓括號(hào), 中括號(hào)和花括號(hào)中的行隱式的連接起來 , 你可以利用這個(gè)特點(diǎn). 如果需要, 你可以在表達(dá)式外圍增加一對(duì)額外的圓括號(hào)。
推薦: foo_bar(self, width, height, color='black', design=None, x='foo', emphasis=None, highlight=0) if (width==0 and height==0 and color=='red' and emphasis=='strong'):
如果一個(gè)文本字符串在一行放不下, 可以使用圓括號(hào)來實(shí)現(xiàn)隱式行連接:
x=('這是一個(gè)非常長非常長非常長非常長 '
'非常長非常長非常長非常長非常長非常長的字符串')
在注釋中，如果必要，將長的URL放在一行上。
Yes: # See details at # http://www.example.com/us/developer/documentation/api/content/v2.0/csv_file_name_extension_full_specification.html No: # See details at # http://www.example.com/us/developer/documentation/api/content/\ # v2.0/csv_file_name_extension_full_specification.html
注意上面例子中的元素縮進(jìn); 你可以在本文的 :ref:`縮進(jìn) <indentation>`部分找到解釋.
括號(hào)
寧缺毋濫的使用括號(hào)
除非是用于實(shí)現(xiàn)行連接, 否則不要在返回語句或條件語句中使用括號(hào). 不過在元組兩邊使用括號(hào)是可以的.
Yes: if foo: bar() while x: x=bar() if x and y: bar() if not x: bar() return foo for (x, y) in dict.items(): ... No: if (x): bar() if not(x): bar() return (foo)
縮進(jìn)
用4個(gè)空格來縮進(jìn)代碼
絕對(duì)不要用tab, 也不要tab和空格混用. 對(duì)于行連接的情況, 你應(yīng)該要么垂直對(duì)齊換行的元素(見 :ref:`行長度 <line_length>` 部分的示例), 或者使用4空格的懸掛式縮進(jìn)(這時(shí)第一行不應(yīng)該有參數(shù)):
Yes: # 與起始變量對(duì)齊
foo=long_function_name(var_one, var_two,
var_three, var_four)
# 字典中與起始值對(duì)齊
foo={
long_dictionary_key: value1 +
value2,
...
}
# 4 個(gè)空格縮進(jìn)，第一行不需要
foo=long_function_name(
var_one, var_two, var_three,
var_four)
# 字典中 4 個(gè)空格縮進(jìn)
foo={
long_dictionary_key:
long_dictionary_value,
...
}
No: # 第一行有空格是禁止的
foo=long_function_name(var_one, var_two,
var_three, var_four)
# 2 個(gè)空格是禁止的
foo=long_function_name(
var_one, var_two, var_three,
var_four)
# 字典中沒有處理縮進(jìn)
foo={
long_dictionary_key:
long_dictionary_value,
...
}
空行
頂級(jí)定義之間空兩行, 方法定義之間空一行
頂級(jí)定義之間空兩行, 比如函數(shù)或者類定義. 方法定義, 類定義與第一個(gè)方法之間, 都應(yīng)該空一行. 函數(shù)或方法中, 某些地方要是你覺得合適, 就空一行.
空格
按照標(biāo)準(zhǔn)的排版規(guī)范來使用標(biāo)點(diǎn)兩邊的空格
括號(hào)內(nèi)不要有空格.
按照標(biāo)準(zhǔn)的排版規(guī)范來使用標(biāo)點(diǎn)兩邊的空格
Yes: spam(ham[1], {eggs: 2}, [])
No: spam( ham[ 1 ], { eggs: 2 }, [ ] )
不要在逗號(hào), 分號(hào), 冒號(hào)前面加空格, 但應(yīng)該在它們后面加(除了在行尾).
Yes: if x==4: print x, y x, y=y, x No: if x==4 : print x , y x , y=y , x
參數(shù)列表, 索引或切片的左括號(hào)前不應(yīng)加空格.
Yes: spam(1) no: spam (1) Yes: dict['key']=list[index] No: dict ['key']=list [index]
在二元操作符兩邊都加上一個(gè)空格, 比如賦值(=), 比較(==, <, >, !=, <>, <=, >=, in, not in, is, is not), 布爾(and, or, not). 至于算術(shù)操作符兩邊的空格該如何使用, 需要你自己好好判斷. 不過兩側(cè)務(wù)必要保持一致.
Yes: x==1 No: x<1
當(dāng)'='用于指示關(guān)鍵字參數(shù)或默認(rèn)參數(shù)值時(shí), 不要在其兩側(cè)使用空格.
Yes: def complex(real, imag=0.0): return magic(r=real, i=imag) No: def complex(real, imag=0.0): return magic(r=real, i=imag)
不要用空格來垂直對(duì)齊多行間的標(biāo)記, 因?yàn)檫@會(huì)成為維護(hù)的負(fù)擔(dān)(適用于:, #,=等):
Yes:
foo=1000 # 注釋
long_name=2 # 注釋不需要對(duì)齊
dictionary={
"foo": 1,
"long_name": 2,
}
No:
foo=1000 # 注釋
long_name=2 # 注釋不需要對(duì)齊
dictionary={
"foo" : 1,
"long_name": 2,
}
Shebang
大部分.py文件不必以#!作為文件的開始. 根據(jù) PEP-394 , 程序的main文件應(yīng)該以 #!/usr/bin/python2或者 #!/usr/bin/python3開始.
(譯者注: 在計(jì)算機(jī)科學(xué)中, Shebang (也稱為Hashbang)是一個(gè)由井號(hào)和嘆號(hào)構(gòu)成的字符串行(#!), 其出現(xiàn)在文本文件的第一行的前兩個(gè)字符. 在文件中存在Shebang的情況下, 類Unix操作系統(tǒng)的程序載入器會(huì)分析Shebang后的內(nèi)容, 將這些內(nèi)容作為解釋器指令, 并調(diào)用該指令, 并將載有Shebang的文件路徑作為該解釋器的參數(shù). 例如, 以指令#!/bin/sh開頭的文件在執(zhí)行時(shí)會(huì)實(shí)際調(diào)用/bin/sh程序.)
#!先用于幫助內(nèi)核找到Python解釋器, 但是在導(dǎo)入模塊時(shí), 將會(huì)被忽略. 因此只有被直接執(zhí)行的文件中才有必要加入#!.
注釋
確保對(duì)模塊, 函數(shù), 方法和行內(nèi)注釋使用正確的風(fēng)格
文檔字符串
Python有一種獨(dú)一無二的的注釋方式: 使用文檔字符串. 文檔字符串是包, 模塊, 類或函數(shù)里的第一個(gè)語句. 這些字符串可以通過對(duì)象的__doc__成員被自動(dòng)提取, 并且被pydoc所用. (你可以在你的模塊上運(yùn)行pydoc試一把, 看看它長什么樣). 我們對(duì)文檔字符串的慣例是使用三重雙引號(hào)"""( PEP-257 ). 一個(gè)文檔字符串應(yīng)該這樣組織: 首先是一行以句號(hào), 問號(hào)或驚嘆號(hào)結(jié)尾的概述(或者該文檔字符串單純只有一行). 接著是一個(gè)空行. 接著是文檔字符串剩下的部分, 它應(yīng)該與文檔字符串的第一行的第一個(gè)引號(hào)對(duì)齊. 下面有更多文檔字符串的格式化規(guī)范.
模塊
每個(gè)文件應(yīng)該包含一個(gè)許可樣板. 根據(jù)項(xiàng)目使用的許可(例如, Apache 2.0, BSD, LGPL, GPL), 選擇合適的樣板.
函數(shù)和方法
下文所指的函數(shù),包括函數(shù), 方法, 以及生成器.
一個(gè)函數(shù)必須要有文檔字符串, 除非它滿足以下條件:
文檔字符串應(yīng)該包含函數(shù)做什么, 以及輸入和輸出的詳細(xì)描述. 通常, 不應(yīng)該描述"怎么做", 除非是一些復(fù)雜的算法. 文檔字符串應(yīng)該提供足夠的信息, 當(dāng)別人編寫代碼調(diào)用該函數(shù)時(shí), 他不需要看一行代碼, 只要看文檔字符串就可以了. 對(duì)于復(fù)雜的代碼, 在代碼旁邊加注釋會(huì)比使用文檔字符串更有意義.
關(guān)于函數(shù)的幾個(gè)方面應(yīng)該在特定的小節(jié)中進(jìn)行描述記錄， 這幾個(gè)方面如下文所述. 每節(jié)應(yīng)該以一個(gè)標(biāo)題行開始. 標(biāo)題行以冒號(hào)結(jié)尾. 除標(biāo)題行外, 節(jié)的其他內(nèi)容應(yīng)被縮進(jìn)2個(gè)空格.
Args:
列出每個(gè)參數(shù)的名字, 并在名字后使用一個(gè)冒號(hào)和一個(gè)空格, 分隔對(duì)該參數(shù)的描述.如果描述太長超過了單行80字符,使用2或者4個(gè)空格的懸掛縮進(jìn)(與文件其他部分保持一致). 描述應(yīng)該包括所需的類型和含義. 如果一個(gè)函數(shù)接受*foo(可變長度參數(shù)列表)或者**bar (任意關(guān)鍵字參數(shù)), 應(yīng)該詳細(xì)列出*foo和**bar.
Returns: (或者 Yields: 用于生成器)
描述返回值的類型和語義. 如果函數(shù)返回None, 這一部分可以省略.
Raises:
列出與接口有關(guān)的所有異常.
def fetch_bigtable_rows(big_table, keys, other_silly_variable=None):
"""Fetches rows from a Bigtable.
Retrieves rows pertaining to the given keys from the Table instance
represented by big_table. Silly things may happen if
other_silly_variable is not None.
Args:
big_table: An open Bigtable Table instance.
keys: A sequence of strings representing the key of each table row
to fetch.
other_silly_variable: Another optional variable, that has a much
longer name than the other args, and which does nothing.
Returns:
A dict mapping keys to the corresponding table row data
fetched. Each row is represented as a tuple of strings. For
example:
{'Serak': ('Rigel VII', 'Preparer'),
'Zim': ('Irk', 'Invader'),
'Lrrr': ('Omicron Persei 8', 'Emperor')}
If a key from the keys argument is missing from the dictionary,
then that row was not found in the table.
Raises:
IOError: An error occurred accessing the bigtable.Table object.
"""
pass
類
類應(yīng)該在其定義下有一個(gè)用于描述該類的文檔字符串. 如果你的類有公共屬性(Attributes), 那么文檔中應(yīng)該有一個(gè)屬性(Attributes)段. 并且應(yīng)該遵守和函數(shù)參數(shù)相同的格式.
class SampleClass(object): """Summary of class here. Longer class information.... Longer class information.... Attributes: likes_spam: A boolean indicating if we like SPAM or not. eggs: An integer count of the eggs we have laid. """ def __init__(self, likes_spam=False): """Inits SampleClass with blah.""" self.likes_spam=likes_spam self.eggs=0 def public_method(self): """Performs operation blah."""
塊注釋和行注釋
最需要寫注釋的是代碼中那些技巧性的部分. 如果你在下次 代碼審查 的時(shí)候必須解釋一下, 那么你應(yīng)該現(xiàn)在就給它寫注釋. 對(duì)于復(fù)雜的操作, 應(yīng)該在其操作開始前寫上若干行注釋. 對(duì)于不是一目了然的代碼, 應(yīng)在其行尾添加注釋.
# We use a weighted dictionary search to find out where i is in # the array. We extrapolate position based on the largest num # in the array and the array size and then do binary search to # get the exact number. if i & (i-1)==0: # true iff i is a power of 2
為了提高可讀性, 注釋應(yīng)該至少離開代碼2個(gè)空格.
另一方面, 絕不要描述代碼. 假設(shè)閱讀代碼的人比你更懂Python, 他只是不知道你的代碼要做什么.
# BAD COMMENT: Now go through the b array and make sure whenever i occurs # the next element is i+1
類
如果一個(gè)類不繼承自其它類, 就顯式的從object繼承. 嵌套類也一樣.
Yes: class SampleClass(object): pass class OuterClass(object): class InnerClass(object): pass class ChildClass(ParentClass): """Explicitly inherits from another class already.""" No: class SampleClass: pass class OuterClass: class InnerClass: pass
繼承自 object 是為了使屬性(properties)正常工作, 并且這樣可以保護(hù)你的代碼, 使其不受Python 3000的一個(gè)特殊的潛在不兼容性影響. 這樣做也定義了一些特殊的方法, 這些方法實(shí)現(xiàn)了對(duì)象的默認(rèn)語義, 包括 __new__, __init__, __delattr__, __getattribute__, __setattr__, __hash__, __repr__, and __str__ .
字符串
Yes: x=a + b
x='%s, %s!' % (imperative, expletive)
x='{}, {}!'.format(imperative, expletive)
x='name: %s; score: %d' % (name, n)
x='name: {}; score: {}'.format(name, n)
No: x='%s%s' % (a, b) # use + in this case
x='{}{}'.format(a, b) # use + in this case
x=imperative + ', ' + expletive + '!'
x='name: ' + name + '; score: ' + str(n)
避免在循環(huán)中用+和+=操作符來累加字符串. 由于字符串是不可變的, 這樣做會(huì)創(chuàng)建不必要的臨時(shí)對(duì)象, 并且導(dǎo)致二次方而不是線性的運(yùn)行時(shí)間. 作為替代方案, 你可以將每個(gè)子串加入列表, 然后在循環(huán)結(jié)束后用 .join 連接列表. (也可以將每個(gè)子串寫入一個(gè) cStringIO.StringIO 緩存中.)
Yes: items=['<table>']
for last_name, first_name in employee_list:
items.append('<tr><td>%s, %s</td></tr>' % (last_name, first_name))
items.append('</table>')
employee_table=''.join(items)
No: employee_table='<table>'
for last_name, first_name in employee_list:
employee_table +='<tr><td>%s, %s</td></tr>' % (last_name, first_name)
employee_table +='</table>'
在同一個(gè)文件中, 保持使用字符串引號(hào)的一致性. 使用單引號(hào)'或者雙引號(hào)"之一用以引用字符串, 并在同一文件中沿用. 在字符串內(nèi)可以使用另外一種引號(hào), 以避免在字符串中使用. PyLint已經(jīng)加入了這一檢查.
Yes:
Python('Why are you hiding your eyes?')
Gollum("I'm scared of lint errors.")
Narrator('"Good!" thought a happy Python reviewer.')
No:
Python("Why are you hiding your eyes?")
Gollum('The lint. It burns. It burns us.')
Gollum("Always the great lint. Watching. Watching.")
為多行字符串使用三重雙引號(hào)"""而非三重單引號(hào)'''. 當(dāng)且僅當(dāng)項(xiàng)目中使用單引號(hào)'來引用字符串時(shí), 才可能會(huì)使用三重'''為非文檔字符串的多行字符串來標(biāo)識(shí)引用. 文檔字符串必須使用三重雙引號(hào)""". 不過要注意, 通常用隱式行連接更清晰, 因?yàn)槎嘈凶址c程序其他部分的縮進(jìn)方式不一致.
Yes:
print ("This is much nicer.\n"
"Do it this way.\n")
No:
print """This is pretty ugly.
Don't do this.
"""
文件和sockets
在文件和sockets結(jié)束時(shí), 顯式的關(guān)閉它.
除文件外, sockets或其他類似文件的對(duì)象在沒有必要的情況下打開, 會(huì)有許多副作用, 例如:
而且, 幻想當(dāng)文件對(duì)象析構(gòu)時(shí), 文件和sockets會(huì)自動(dòng)關(guān)閉, 試圖將文件對(duì)象的生命周期和文件的狀態(tài)綁定在一起的想法, 都是不現(xiàn)實(shí)的. 因?yàn)橛腥缦略?
推薦使用 "with"語句 以管理文件:
with open("hello.txt") as hello_file:
for line in hello_file:
print line
對(duì)于不支持使用"with"語句的類似文件的對(duì)象,使用 contextlib.closing():
import contextlib
with contextlib.closing(urllib.urlopen("http://www.python.org/")) as front_page:
for line in front_page:
print line
Legacy AppEngine 中Python 2.5的代碼如使用"with"語句, 需要添加 "from __future__ import with_statement".
TODO注釋
為臨時(shí)代碼使用TODO注釋, 它是一種短期解決方案. 不算完美, 但夠好了.
TODO注釋應(yīng)該在所有開頭處包含"TODO"字符串, 緊跟著是用括號(hào)括起來的你的名字, email地址或其它標(biāo)識(shí)符. 然后是一個(gè)可選的冒號(hào). 接著必須有一行注釋, 解釋要做什么. 主要目的是為了有一個(gè)統(tǒng)一的TODO格式, 這樣添加注釋的人就可以搜索到(并可以按需提供更多細(xì)節(jié)). 寫了TODO注釋并不保證寫的人會(huì)親自解決問題. 當(dāng)你寫了一個(gè)TODO, 請(qǐng)注上你的名字.
# TODO(kl@gmail.com): Use a "*" here for string repetition. # TODO(Zeke) Change this to use relations.
如果你的TODO是"將來做某事"的形式, 那么請(qǐng)確保你包含了一個(gè)指定的日期("2009年11月解決")或者一個(gè)特定的事件("等到所有的客戶都可以處理XML請(qǐng)求就移除這些代碼").
導(dǎo)入格式
每個(gè)導(dǎo)入應(yīng)該獨(dú)占一行
Yes: import os import sys No: import os, sys
導(dǎo)入總應(yīng)該放在文件頂部, 位于模塊注釋和文檔字符串之后, 模塊全局變量和常量之前. 導(dǎo)入應(yīng)該按照從最通用到最不通用的順序分組:
每種分組中, 應(yīng)該根據(jù)每個(gè)模塊的完整包路徑按字典序排序, 忽略大小寫.
import foo from foo import bar from foo.bar import baz from foo.bar import Quux from Foob import ar
語句
通常每個(gè)語句應(yīng)該獨(dú)占一行
不過, 如果測試結(jié)果與測試語句在一行放得下, 你也可以將它們放在同一行. 如果是if語句, 只有在沒有else時(shí)才能這樣做. 特別地, 絕不要對(duì) try/except 這樣做, 因?yàn)閠ry和except不能放在同一行.
Yes: if foo: bar(foo) No: if foo: bar(foo) else: baz(foo) try: bar(foo) except ValueError: baz(foo) try: bar(foo) except ValueError: baz(foo)
訪問控制
在Python中, 對(duì)于瑣碎又不太重要的訪問函數(shù), 你應(yīng)該直接使用公有變量來取代它們, 這樣可以避免額外的函數(shù)調(diào)用開銷. 當(dāng)添加更多功能時(shí), 你可以用屬性(property)來保持語法的一致性.
(譯者注: 重視封裝的面向?qū)ο蟪绦騿T看到這個(gè)可能會(huì)很反感, 因?yàn)樗麄円恢北唤逃? 所有成員變量都必須是私有的! 其實(shí), 那真的是有點(diǎn)麻煩啊. 試著去接受Pythonic哲學(xué)吧)
另一方面, 如果訪問更復(fù)雜, 或者變量的訪問開銷很顯著, 那么你應(yīng)該使用像 get_foo() 和 set_foo() 這樣的函數(shù)調(diào)用. 如果之前的代碼行為允許通過屬性(property)訪問 , 那么就不要將新的訪問函數(shù)與屬性綁定. 這樣, 任何試圖通過老方法訪問變量的代碼就沒法運(yùn)行, 使用者也就會(huì)意識(shí)到復(fù)雜性發(fā)生了變化.
命名
module_name, package_name, ClassName, method_name, ExceptionName, function_name, GLOBAL_VAR_NAME, instance_var_name, function_parameter_name, local_var_name.
應(yīng)該避免的名稱
命名約定
Python之父Guido推薦的規(guī)范
TypePublicInternalModuleslower_with_under_lower_with_underPackageslower_with_under ClassesCapWords_CapWordsExceptionsCapWords Functionslower_with_under()_lower_with_under()Global/Class ConstantsCAPS_WITH_UNDER_CAPS_WITH_UNDERGlobal/Class Variableslower_with_under_lower_with_underInstance Variableslower_with_under_lower_with_under (protected) or __lower_with_under (private)Method Nameslower_with_under()_lower_with_under() (protected) or __lower_with_under() (private)Function/Method Parameterslower_with_under Local Variableslower_with_under
Main
即使是一個(gè)打算被用作腳本的文件, 也應(yīng)該是可導(dǎo)入的. 并且簡單的導(dǎo)入不應(yīng)該導(dǎo)致這個(gè)腳本的主功能(main functionality)被執(zhí)行, 這是一種副作用. 主功能應(yīng)該放在一個(gè)main()函數(shù)中.
在Python中, pydoc以及單元測試要求模塊必須是可導(dǎo)入的. 你的代碼應(yīng)該在執(zhí)行主程序前總是檢查 if __name__=='__main__' , 這樣當(dāng)模塊被導(dǎo)入時(shí)主程序就不會(huì)被執(zhí)行.
def main(): ... if __name__=='__main__': main()
所有的頂級(jí)代碼在模塊導(dǎo)入時(shí)都會(huì)被執(zhí)行. 要小心不要去調(diào)用函數(shù), 創(chuàng)建對(duì)象, 或者執(zhí)行那些不應(yīng)該在使用pydoc時(shí)執(zhí)行的操作.
*請(qǐng)認(rèn)真填寫需求信息，我們會(huì)在24小時(shí)內(nèi)與您取得聯(lián)系。
