属性键值
结构化信息挂在节点上
属性与标签承载结构化信息,条件样式按规则自动套用
结构化信息挂在节点上
跨分支汇总同一类
按规则自动换样式
按条件只看相关节点
一份评估清单里每个节点挂着状态属性,条件样式按状态分色,周五开会不用逐个问进度,看颜色就够。
条件样式与过滤器是一对:一个决定怎么显示,一个决定显示哪些。
属性写规则了,才谈得上按规则自动套样式与筛选。
给节点挂键值属性,记来源、负责人、截止时间、参考链接。这些信息不必挤在正文里,需要时展开看,需要统计时按属性取值,比在一堆文字里找关键字可靠。
同一类内容散在不同分支下时,给它们打同一个标签,按标签把节点聚成一份清单。标签与属性分工:属性记这一项的事实,标签记它属于哪一类。
按节点文字、属性取值或图标设定样式规则,命中就自动套用。截止日期过了的节点自己变红,负责人是自己那一支换个底色,不必每周人工过一遍。
按条件筛出相关节点,其余暂时隐去,开完会再取消筛选回到全貌。筛选只影响显示,不会真的删掉东西。
调好的一套节点样式可以另存,套到别的导图上。团队统一观感时,把这份样式文件发出去导入一次,各人交上来的图打开就是一个样子。
内置编辑器用 Groovy 写脚本,批量改名、按规则打标签、汇总统计这类活交给它跑一遍。脚本存在配置目录里,可以反复用,也可以给同事。
样式、标签与条件三样配套用。
| 数据手段 | 记录什么 | 用来做什么 |
|---|---|---|
| 属性 | 来源、负责人、时间 | 按取值统计与筛选 |
| 标签 | 内容所属类别 | 跨分支汇总清单 |
| 条件样式 | 显示规则 | 状态自动呈现 |
| 过滤器 | 查看条件 | 只看相关节点 |
| 样式文件 | 观感定义 | 团队统一交付 |
| 脚本 | 批量处理逻辑 | 重复整理自动化 |
出图、共享、退场各自有先后。
键值对在侧栏直接编辑,不必开对话框。
标签按类别归拢,检索更快。
条件可叠加,命中优先级可调。
编辑器内置,改完直接跑。
节点、样式与脚本三部分构成日常使用:节点承载内容,样式决定观感,脚本处理重复动作;三者叠起来才是知识管理而不是画一张图。同一台机器上并存两套办公软件是常见做法,文件关联可以按文件逐个选择,确认稳定后再改默认。
树形与自由布局可以混着用,按表达需要选。
给节点挂来源、负责人与时间,信息与内容放在一起不分散。
同一类节点跨分支打同一个标签,按标签汇总成清单。
按属性或文字内容自动换样式,过期与异常自己跳出来。
按条件筛出相关节点,只看这一批,其余暂时隐去。
上述场合在实操中常有交叉,按手头这件事选对应的做法即可。
两种安装形态各有用处,按本机条件选。
节点带数据,样式按规则走
键名定下来之后不要随手改,改一次所有依赖它的规则都得跟着改。
只补真正要用的那几项,属性堆太多,维护成本比收益高。
先从最实用的一条开始:过期变红、本人负责的换底色。
两者都在配置目录里,换机器时一起拷走。
如果界面提示补全某项设置,按引导填一次即可,后续使用不再打断。
取包、安装、建图、存盘按顺序做。
属性记这一项的具体事实,比如谁负责、什么时候截止;标签记它属于哪一类,比如「待评审」「外部依赖」。需要按值统计与判断的用属性,需要归类与汇总的用标签。
常见原因是规则顺序:靠前的规则先命中,后面同类规则不再生效。把条件最具体的放前面,宽泛的放后面。另一处容易忽略的是键名拼写与大小写,差一个字符就匹配不上。
跑之前先另存一份,脚本本身不需要联网也不需要额外环境。第一次跑建议只选中一个分支试,确认结果对了再放开范围。改坏了从备份退回去即可。
属性是随文件保存的,正常打开都在。看不到多半是因为属性面板没有展开,或者对方用的是别的同类软件,导入时未识别自定义字段。