## 流程图
一段流程图语法以 “``` 开头,以 “``` 结尾
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小时内与您取得联系。