一、术语定义
我们在这个部分不仅介绍了我们的专有名词,还对于项目的整体架构做出了一个“名词性”的描述,方便设计和团队沟通。
概念以树的形式组织,提供中英文双名。这种组织形式要优于表格结构,因为对于不同概念进行了分类细化。使用 Xmind 工具进行记录,这种工具的好处是显然的(有一种说法是敏捷开发对于高效工具的需求是很强的)。
二、概念设计
2.1 Ficus 树(Ficus Tree)
文档内的组织结构。
将以行为最小单位的一段 md 代码转换成一种树形结构,用户可以浏览和编辑这棵树,并且对于 Ficus Tree 的编辑操作会映射到这段 md 代码上。
树的非叶子节点包括:
- 各级标题
- 列表虚拟节点(这是因为在 markdown 中没有像 latex 一样的
itemize
一样的总体结构)
树的叶子节点包括:
- 文本段
- 数学块
- 代码块
- 引用
- 列表
- 表格
需要注意的是,以下 md 实体并不是叶子节点:
- 加粗
- 斜体
- 下划线
- 链接
- 图片
对于 Ficus 树,需要为其生成虚拟根节点,使得树结构一定存在(而不是森林结构)。
对于如下 md 源码
# 一级标题 1
## 二级标题 1
```c
int main(){return 0;}
```
$$ 1 = 1 + 1 $$
### 三级标题 1
一段文字
> 一段引用
## 二级标题 2
- item1
- item2
- item3
# 一级标题 2
生成如下 Ficus 树
需要注意这是一颗有序树,也就是兄弟节点之间是有顺序的。
2.2 Ficus 森林(Ficus Forest)
多个文档构成的一种视图,将每个文档视为一个 Ficus 树,用户可以选择多个文档后进入 Forest。
对于如下两个 md 文档
doc1.md
# 一级标题 1
# 一级标题 2
## 二级标题 1
doc2.md
# 一级标题 1
## 二级标题 1
### 三级标题 1
选择 doc1.md 和 doc2.md 生成 Ficus Forest 的结构如下所示
森林中每棵树的根节点表示文档的路径和文件名信息。他们也可以被称为基座。与后文结合,基座持有 Ficus 的根和柱信息,但是不持有 Ficus 须信息,Ficus 须的信息由文本持有。
2.3 Ficus 图(Ficus Graph)
2.3.1 Ficus 根(Ficus Root)
由文件系统组织起来的 Ficus 关系。一个目录与他目录中的直接内容形成一个关系,与嵌套内容并不形成关系,对于如下目录结构
.
├── dir1
│ ├── doc2.md
│ └── doc3.md
└── doc1.md
应当生成如下结构
2.3.2 Ficus 柱(Ficus Prop)
由单层 tag 组织起来的 Ficus 关系,一个 md 文档可以具有多个 tag。一个 tag 对应一个节点,所有具有该 tag 的文档与这个 tag 节点间都有一条边。可以被看做一种以 tag 为中心的星形图。
在上文中的目录结构,tag 情况如下:
此时的 Ficus 柱(黑线)如图所示,这幅图上同时也展示了 Ficus 根:
2.3.3 Ficus 须(Ficus Aerial)
由拓展 md 语法 [[file_path]]
构建出的关系。这种关系是一种无向的关系,关系的两个端点分别是引用文档和被引用文档。
对于上文的示例,存在引用关系:
那么对应的 Ficus 须的结构如下所示(为图中的绿色线条):
三、典型用户
3.1 B 站知识区 UP 主
姓名 | Miss Wang |
---|---|
年龄 | 26 |
职业 | 英语 UP 主 |
专业 | 英语专业 |
工作生活 | 录制视频给学生讲解英语知识 |
需求 | 英语零碎的知识点不容易成体系,制作 PPT 太过麻烦 |
占比 | 30% |
3.2 高二生物竞赛生
姓名 | 张无雨 |
---|---|
年龄 | 17 |
职业 | 高中学生 |
专业 | 高中生物竞赛生 |
工作生活 | 整理生物笔记备考竞赛 |
需求 | 生物知识过于庞大,盘根错节,难以整理 |
占比 | 15% |
3.3 调研强迫症
姓名 | 秦斯 |
---|---|
年龄 | 22 |
职业 | 大学生 |
专业 | 考古学 |
工作生活 | 在实验室完成写论文综述的任务 |
需求 | 论文之间的联系不容易看出,很难梳理出一个学科的发展脉络 |
占比 | 30% |
3.4 知识博主
姓名 | 郭笑笑 |
---|---|
年龄 | 23 |
职业 | 自由职业 |
专业 | 计算机 |
工作生活 | 在博客上发表自己的知识博客 |
需求 | 博客内容的呈现形式需要反复地斟酌润色 |
占比 | 25% |