## 流程圖
一段流程圖語法以 “``` 開頭,以 “``` 結尾
graph XX(XX表示流程圖類型),分橫向和豎向兩大類
``` graph LR 節點1(節點1名稱)-->節點2(節2點名稱) 節點1(節點1哈哈) ```
如上其中:
> graph表示這是一個流程圖
> LR表示流程圖類型
> 節點1和節點2表示流程圖中的節點Id,每個節點Id唯一的且對應各自的對外顯示的名稱,如果不顯式指定節點名稱默認顯示節點Id。同一節點Id的多個定義為最后一行定義的生效
``` graph LR 節點1(節點1名稱1)-->節點2(節2點名稱) 節點1(節點1名稱2) 節點1{節點1名稱3} ```
> -->表示節點的流程線
#### 流程圖類型
> 豎向分位上(graph TB)和下(graph BT)
``` graph TB 節點1-->節點2 ``` ``` graph BT 節點1-->節點2 ```
> 橫向分位左(graph RL)和右(graph LR)
``` graph LR 節點1-->節點2 ``` ``` graph RL 節點1-->節點2 ```
TB - top bottom(自上而下)
BT - bottom top(自下而上)
RL - right left(從右到左)
LR - left right(從左到右)
TD - 與TB相同(自上而下)
``` graph TD 節點1-->節點2 ```
#### 流程圖框線
> []:直角四邊形,處理框
``` graph LR 節點1[處理1]-->節點2[處理2] ```
> ():圓角四邊形,起止框
``` graph LR 節點1(開始)-->節點2(結束) ```
> (()):圓形,連接點
``` graph LR 節點1((連接1))-->節點2((連接2)) ```
> {}:棱形,判斷框
``` graph LR 節點1{判斷1}-->節點2{判斷2} ```
> >]:折角
``` graph LR 節點1>描述1]-->節點2>描述2] ```
#### 流程線
> ---:無流向實線和-.-:虛線
``` graph LR 節點1---節點2 節點1-.-節點2 ```
> ==>:無流向粗線
``` graph LR 節點1===節點2 節點1===|流程|節點2 節點1==流程===節點2 ```
> ---||或 -- ---:無流向實線添加文本
> -.->||或 -. -.->:無流向虛線添加文本
``` graph LR 節點1---|流程1|節點2 節點1--流程2---節點2 節點1-.-|流程3|節點2 節點1-.流程4-.-節點2 ```
> -->:流向實線和-.->:流向虛線
``` graph LR 節點1-->節點2 節點1-.->節點2 ```
> ===:流向粗線
``` graph LR 節點1==>節點2 節點1==流程==>節點2 節點1==>|流程|節點2 ```
> -->||或 -- --?:流向實線添加文本
> -.->||或 -. -.->:流向虛線添加文本
``` graph LR 節點1-->|流程1|節點2 節點1--流程2-->節點2 節點1-.->|流程3|節點2 節點1-.流程4-.->節點2 ```
> 如果文本中包含特殊字符,需要使用雙引號
``` graph LR 節點1["節點1 名稱"]-->節點2["節點2 名稱"] 節點1["節點1 名稱"]-->節點3["這是 (節點3)#9829;"] ```
#### 子圖
``` graph LR 子圖1節點1[A1]-->子圖2節點2[子圖2節點2] 子圖3節點1[A1]-->子圖1節點2[子圖2節點2] subgraph 子圖1 子圖1節點1[子圖1節點1]-->子圖1節點2[子圖1節點2] end subgraph 子圖2 子圖2節點1[子圖2節點1]-->子圖2節點2[子圖2節點2] end subgraph 子圖3 子圖3節點1[子圖3節點1]-->子圖3節點2[子圖3節點2] end ```
### 交互功能
增加事件
> click nodeId callback
``` graph LR 節點1-->節點2 click 節點1 callback "提示框" click 節點2 "http://www.github.com" "github地址" ```
增加樣式
``` graph LR 節點1(開始)-->節點2(結束) style 節點1 fill:#f9f,stroke:#333,stroke-width:4px style 節點2 fill:#ccf,stroke:#f66,stroke-width:2px,stroke-dasharray: 5, 5 ```
云筆記中更詳細的流程圖語法,是參考(有些特性并沒有支持):https://mermaidjs.github.io/flowchart.html。
s2flowchart 是一個可視化庫,可將任何JavaScript代碼轉換為漂亮的SVG流程圖。你可以輕松地利用它學習其他代碼、設計你的代碼、重構代碼、解釋代碼。這樣一個強大的神器,真的值得你擁有,看下面截圖就知道了,有沒有很強大。
安裝
yarn add js2flowchart
使用
index.html
index.js
我們直接在文本域中輸入自己的代碼,如下,左邊會直接生成流程圖,這只是一個簡單的示例:
js2flowchart獲取您的JS代碼并返回SVG流程圖,適用于客戶端/服務器,支持ES6。
主要特點:
定義抽象級別以僅渲染導入/導出,類/函數名稱,函數依賴性以逐步學習/解釋代碼。
自定義抽象級別支持創建自己的抽象級別
表示生成器,以生成不同抽象級別的SVG列表
定義流樹修改器以映射眾所周知的API,例如 .map,。forEach, .filter到方案上的循環結構等。
銷毀修飾符,用于在方案上用一個形狀替換代碼塊
自定義流樹修改器支持創建自己的流修改器
流樹忽略過濾器完全省略一些代碼節點,如日志行
聚焦節點或整個代碼邏輯分支突出顯示方案的重要部分
模糊節點或整個代碼邏輯分支以隱藏不太重要的東西
定義的樣式主題支持選擇您喜歡的樣式
自定義主題支持創建自己的主題,更好地適合您的上下文顏色
自定義顏色和樣式支持提供方便的API來更改特定樣式而無需樣板
用例場景:
通過流程圖解釋/記錄您的代碼
通過視覺理解學習其他代碼
為有效JS語法簡單描述的任何進程創建流程圖
以上所有功能可以直接到github上詳細了解,用法太多,這里就不在介紹了!
這么強大的東西,有人肯定說如果在開發的時候實時看到流程圖有助于理解代碼,官網提供了插件(我在最新版中測試失效了,不知道是否是我使用的有問題還是插件本身的問題),如果感興趣的可以到擴展商店搜索code-flowchart。如果測試成功,歡迎到評論區分享。以下是我vscode版本和官網的插件使用截圖。
如果利用好這個插件,可以開發出Chrome插件,以及其他JavaScript編輯器或者IDEA的插件,由于官方github已經幾個月沒更新了,所以還不知道未來會不會支持!
來都來了,走啥走,留個言唄~
IT大咖說 | 關于版權
由“IT大咖說(ID:itdakashuo)”原創的文章,轉載時請注明作者、出處及微信公眾號。投稿、約稿、轉載請加微信:ITDKS10(備注:投稿),茉莉小姐姐會及時與您聯系!
感謝您對IT大咖說的熱心支持!
相關推薦
推薦文章
據說這份高考卷,只有程序員能得滿分!
干貨分享:一次Java內存泄漏排查實戰
這個程序員實在是太帥了
最近活動
融云微課堂
線下活動 | Apache Flink 1.9 版本即將發布,新版本有哪些新特性?
線下活動 | 阿里云實時計算專場沙龍,與你探討大數據實時計算的解決方案
點擊【閱讀原文】更多IT技術圈干貨等你挖掘
閱讀原文
人人都是產品經理【起點學院】,BAT實戰派產品總監手把手系統帶你學產品、學運營。
距離上次發發帖已經有一個多月了,本來想早點發新帖的但是各種瑣碎的事干擾,一直沒能寫帖子。對“眾云行”不了解朋友的附帶產品BRD連接(原文:http://www.woshipm.com/pd/321497.html)。
說起產品經理的日常工作有一個很重要的點就是梳理產品流程。最開始接觸流程設計的時候一直搞不清楚什么是業務流程,操作流程,頁面流程以及這三者的關系。經過系統研究后得出些心得,和小伙伴們分享下,如有哪里錯誤還請指出,感謝糾正!!!
業務流程:
也有人叫“功能流程”,作為梳理產品功能框架的依據:其實就是你要做一件事的時候一共分為幾步走,這幾步的先后順序就是業務流程。簡單舉個例子:說把大象放進冰箱里分幾步,第一步打開冰箱門,第二步把大象放進去,第三步關上冰箱門。轉換成流程圖如下:
操作流程:
就是你完成過每一步需要做的事情和具體怎么做,以大象放進冰箱里的例子中的第一步打開冰箱門,為例:
動作包括:手握住冰箱門——拉動/推動冰箱門
判定條件:
限制條件:
橫開門必須橫向拉動,平開必須水平拉動。
(關于限制條件,有的人覺得在流程圖階段不用考慮,但是我覺得在整個梳理流程的過程中最好能將考慮的細節條件都進行標注,這樣能夠幫助梳理頁面流程圖和整理產品的信息架構,深化交互設計。)
結果條件:將門打開至足以放入大象的開口大小,未達到條件則無法進入下一步。
轉為操作流程圖如下:
頁面流程:
就是用戶完成前兩道流程需要處于的頁面環境,在環境1中觸及到哪一個點換滿足哪些條件后,到達下一環境。還是以大象放進冰箱的任務舉例說明:冰箱關閉,大象在冰箱外的環境:出現一個冰箱,單擊冰箱門打開按鈕,打開冰箱門——進入冰箱門打開,大象在冰箱外的環境,冰箱內部分格場景進入眼簾,選擇合適的分格空間,把大象放進去,——進入冰箱門打開,大象在冰箱里的環境場景:然后單擊關閉冰箱門的按鈕,進入大象放入冰箱后,冰箱門關閉的場景,即完成任務的場景。轉為頁面流程圖如下:
這個時候就會發現先前有一些流程是我們沒有考慮進來的,例如當冰箱內部空間不足的時候,是需要調整冰箱內的物品以騰出足夠的空間,還是需要調換冰箱。以及一些交互過程中需要出示的小提示頁面等(例如,冰箱空間不足提示)
繪制頁面流程圖,也是對前面操作流程和業務流程的檢驗,細化和豐富。
總結:
綜上所訴,業務流程,操作流程,是一種前后推導關系,業務流程作為推到操作流程的前提,操作流程作為深入細化和檢驗業務流程的工具。
頁面流程是業務流程和操作流程具體的場景體現,頁面流程體現了滿足業務流程所體現的功能點和信息點,以及通過操作流程所體現的各功能之間的關系和具體的操作方法。同時頁面流程也在不斷檢驗前兩個流程,幫助優化流程。
在這里有一點需要提到的是,無論是業務流程圖,操作流程圖,頁面流程圖,在繪制的過程中都盡可能的表示出到達某一流程的輸入輸出條件,這樣既可以幫助后期的交互設計,也可以幫助梳理和豐富該環節的流程內容,以及產品的功能架構和信息架構。
這里以眾云行的流程為例,解釋三個流程具體的推倒思路。
通常情況下我們在編寫BRD的時候,會設計出產品大致的業務模式(初級業務流程)和涉及到的大的功能點(初級功能框架)。如圖:
(眾云行BRD中的業務模式部分)
(眾云行BRD中的功能規劃部分,現在看來寫的有點過了)
進入流程設計階段(也可以說是輸出MRD文檔前的準備階段)我們最先要做的是兩件事。
1. 梳理用戶,產品,后臺三個端口的主要功能大框和功能關系,如圖:
我將功能分為用戶端,產品端,后臺端三部分。用戶端:用戶在使用產品時需要主動獲取或操作的功能。產品端:產品自身需要為用戶呈現的功能。用戶端:組織支援前兩大端口功能,滿足后端運營和監管的輔助功能。
2. 細化業務流程。這部分沒什么說的,這里需要注意的是側重點應放在用戶完成任務需要經過的環節,注意環節之間的邏輯和連續關系,切勿把中心放在某個具體的操作動作上。如圖:
首先是拆分業務流程,按環節特點或順序階段先后等條件,將業務流程拆分成若干個小環節。然后針對每一個小環節進行操作流程的梳理。
個人認為這里需要注意的是兩點:
如圖:(以用戶發布調研任務環節為例)
上文提到每一個頁面就是一個小的用戶場景,我們要設想用戶完成任務的過程中需要經過哪些頁面,使用哪些功能,獲得哪些信息內容。體現到頁面流程圖上 就是每一個頁面需要呈現哪些信息,哪些功能點,在打擊哪些按鍵時進入的下一個頁面是什么。
這里需要注意的就是:
以上兩點一方面可以幫助梳理前面的業務流程,操作流程,也可以為原型設計打好交互基礎。所以本人覺得在交互設計環節時考慮的交互問題,可以盡量在這一環節考慮,具體的好處有哪些有,過設計經驗或項目管理經驗的人應該都會有體會。廢話不多說直接上圖:(眾云行主框架的頁面流程關系)
總結:
個人覺得流程圖部分鍛煉著產品經理的邏輯思維和大腦的活躍度,想提高這部分能力可以多整理些經典產品的流程部分。整理的越細致越能幫助產品經理更好的完成這部分工作。
本文由 @于海洋 原創發布于人人都是產品經理。未經許可,禁止轉載。
*請認真填寫需求信息,我們會在24小時內與您取得聯系。