2023年10张图详解“课程配置”模块

张图详解“课程配置”模块class="size-fullwp-image-5792187aligncenter"src="/wp-files/2023/03/AjI5FLL1kJfdOwMrEI4C.jpg"alt=""width="900"height="420"/>

互联网时代，越来越多的课程和培训从线下转移到了线上，线上课程较于线下课程的弊端在于无法依据学员的实际学习状况实时的调整课程的内容和讲授方式；而对比线下课程，线上课程确能为学员供应更敏捷的学习时间选择，也能让内容供应方无限扩大内容的影响范围从而获得更多收益。那么如何搭建一套在线课程管理系统呢？

今日我们来具体拆解一下课程管理模块如何设计。

一、基本规律梳理

1.从线下课程说起

在同学时代，我们会在学校学习语文、数学、英语等不同的学科；依据班级学习的侧重点，学校会支配每个学科每天实际的上课方案，直观来讲就是“课表”。

老师在实际讲课的过程中，又会依据老师自己的阅历有自己的一套教学环节，比如语文课上课前5分钟先读一遍新课文、或者数学老师在课堂最终10分钟支配随堂测试等；在学期结束时，每个学科还会支配期末测试，以检验学习效果；测试的试卷会由不同类型和分值的试题组成，比如选择题每题5分、填空每题10分、问答每题20分等等……

依据以上的场景，我们可以梳理出线下课程的基本结构如下图，为了将线下课程线上化，线上课程也同样需要能够支持这样的基本结构：

2.因地制宜的调研

课程管理模块用于对课程结构和内容进行配置，即教研人员会在这个模块配置供用户学习的课程，依据商业模式不同、学科不同、教学风格不同，每个公司需要的课程模块也不尽相同。

想要确定课程的结构体系，就需要先和教研团队确认课程的实际状况，即从校验团队的教学大纲中提炼课目、课程、各种类型和结构等需要在系统上实现的关键信息，这里笔者供应几个调研的角度：

3.梳理中要留意的点

虽然产品的基本要求是会画原型，但是笔者认为产品最大的工作量在于对需求的充分理解，只有从背景、干系人、业务场景、可能消失的特别等多方面对需求有了理解，才能做到“胸有成竹”的去将想法落实到原型文档上。因此在对教研系统背景的梳理中，除了根据教研大纲梳理课程结构以外，应当留意以下点：

需求背景：需求处于什么阶段？需要多久上线使用？MVP是什么？这关系到产品设计范围的掌握，假如需求特别紧急，可以接受灵敏的方式实现，则可以粗略设计系统的结构，而将部分必需功能精细设计；干系人：上文中，我们说明白课程相关的规律梳理，但是实际的使用场景中可能不是教研团队配置课程，谁来配置课程？课程是否有人审核？线上课程有问题的反馈给谁？这涉及到配置流程和角色权限的管理；业务场景：梳理的结果应当能够满意实际的业务场景，可以通过流程图反馈给干系人，在产品文档撰写之前确认好设计的基本方向。二、基本功能设计

通过调研和梳理，我们可以整理出一套基础的课目结构，并针对整理出的课程结构分析相应的落地实现方案，用英语课程的结构为例：

1.科目设计

假如我们的业务场景如上图一样，是确定数量的课目，那么课目就可以直接作为一个确定（不需要扩展）的类型去设计。

但是假如是一个简单的学问性平台（例如得到），平台内包含了多种多样的科目，那就需要对先对课目进行管理，将课目首先设计成一个可供扩展的类型。

科目详细是否需要进行管理，还有一个很重要的一个推断依据是：它是否会作为用户端的一个筛选类型，直观来讲就是科目是否作为课程类型供用户在APP或者网页上进行筛选，假如需要则需要对科目类型进行单独的配置管理，甚至要做多层关联性的配置管理，例：

2.课程设计

1）设计挨次

课程作为一个单独的学习内容组，是每日课程的一个综合体。对外，它需要承载向用户解释说明课程内容的作用；对内，它需要对下属的日课程进行配置和管理。

这里笔者建议先设计单节课程的配置页面，再进行课程列表页进行设计，由于列表页可以视作对课程统一信息的一个整体展现，即每个列表字段代表了一个课程的核心要素，这个要素应当是每个课程都包含的、典型的、重要的，而提炼这些字段需要对每种课程的要素进行抽象，那么先对单个课程的配置进行梳理，并在梳理中发觉每个字段的属性，就可以顺当的对列表的字段进行提炼。

2）单个课程

单个课程应当包含两个大的结构：基本信息、课程内的单个课程（每节课）。

基本信息会用于前端用户的展现策略：用户需要从图标、课程名、课程简介对课程有一个初步的了解；所属科目和课程标签还可用于前端的栏目管理或用户内容筛选的依据；估计课数用于让用户提前了解课程的数量状况，为用户供应学习选择的依据。

课程内的单个课程，即课程下属的实际课程，需要为系统供应实际上课时的元素，比如上课中用于讲解课程内容的视频、用户可以下载来自己预习复习的课件，以及学习完成后的课后测试等。由于课程是许多单个的课组成的，所以还需要支持对于下属课程的增删和挨次调整的功能。

3）课程列表

完成了单个课程配置的设计后，我们回过头来看课程列表的设计，课程列表中应当展现课程的基本信息：

作为唯一值的课程编号，课程编号在课程创建后就生成，有了它课程名称就不需要具有唯一性，即多个课程的课程名称可以重复，而用课程编号识别不同的课程；

课程名称和所属科目作为课程的基本属性，协作检索区域进行课程的快速查找；

应用策略支持对课程进行上下架管理，即是否让用户在前端看到课程，上下架的设计需要考虑到课程的实际关联场景，从用户接触到APP开头：下架后售卖此课程的商品有什么影响？下架后用户进入APP是否能看到这个课程？下架当时正在上课的用户如何处理？假如课程有学习记录，下架后相应的学习记录如何处理？等等一系列的问题，需要在【下架】这个按钮的设计说明里列清晰，请不要只写一个“这里加个【下架】按钮”，假如这里的策略产品无法定夺，要准时和业务方沟通方案。

列表中的操作是指的对单个课程可以做的操作，这里一般来讲会有查看和编辑的选择，编辑是为了修改已经创建完成的课程里的内容；查看则是为了通过权限管理实现部分不行以编辑但是又有“知情权”的系统使用人员去了解课程配置状况，复制课程是快捷的生成新的课程，同时代入已有课程的信息以便修改，用于创建相像度较高的课程。

列表之外，还应当支持创建新的课程，点击按钮进入到上文中讲到的单个课程的页面，进行一个新课程的创建。

三、抽象与解耦

至此，常规的系统功能已经具备，但是对于课程类型简单的平台，上述的配置还是过于细碎。我们在进行基础的页面设计的时候，除了思索与课程结构的符合以外，还应当考虑每个操作背后所关联的规律，比如上图中“课后测试”模块要怎么实现呢？

1.两种处理思路

我们观看到，其次种方式其实是一种概念的抽象，也就是将测试抽象成了一个单独的模块与课程结构进行了解耦，这种解耦有利于在简单场景中提升内容可复用度、提高简单内容的配置效率。

沿着这个思路，我们再来观看课程配置的图例，在实际的课程配置中，其实有些章节是不需要课后测试的，那么除了将课后测试变成“非必填”以外，还有什么方式来处理这种“同一个模块下不同组成部分的差异性”呢？答案就是：抽象与解耦。

2.功能抽象

我们试着将课程环节的组成抽象成一个模型，将环节类型作为一个单独的管理模块，与每节课的实际配置进行解耦，那么课程管理就会变成这样：

留意！页面中，我们增加了类型的选择，类型打算了对应章节中需要配置的内容类型，便利我们对课程的结构进行统一的管理，在章节类型的背后，需要有章节模型的管理，在对章节模型进行管理时，需要结合课程的特点去设计需要统一管理的模块，即细化到对模块规格的管理，示例：

抽象与解耦还有一个简单被忽视的优势，就是提升客户端的效率，将规范好的课程结构直接复用会比每个课程都推断一次结构效率要高，举个例子：买煎饼的时候，假如跟老板说“老样子”或者“套餐一”，会比说：不要葱花、少放香菜、加一袋辣条、两个鸡蛋、多放薄脆要来的便利快捷