《教育产品组件化交互设计的实践与思考》由会员分享，可在线阅读，更多相关《教育产品组件化交互设计的实践与思考（13页珍藏版）》请在金锄头文库上搜索。
1、组件化规划，就是规划模块化，组件可复用。是以通用化的视角审视模块规划，依据事务方需求支撑多个产品的接入与运用。在线教育领域内，标题是线上线下教育场景内校验学习的一种根本办法，一起，标题可以存在于题库内，题库和组卷是承载标题的一般载体，而这两个载体在各产品教育体系内有共有的需求，由于需求重合度较高，又具有高度的通用性。所以，以组件的办法规划“题库”和“组卷”这两个模块，经过多种视点去衡量都是有其存在价值的。多方考虑后，由教育部门 EduOS 团队担任完结题型的重构、题库的创立与办理、组卷的办法等模块的组件化规划。 一起在考虑可行性和根底结构的根底上， 实现一个可在网易 100 分、我国大学 MO
2、OC 、云讲堂 C/B 端运用的题库及组卷。在资源共享的情况下，可以调用组件，可以复用代码，也可以考虑通用模块功用等。这篇文章首要是以抛出问题，经过 需求认同、一致 规划前期 项目问题及处理办法 了解与考虑 这 4 个部分进行逐条讲述在这个进程中的实践与考虑。对组件化的认同、一致是否认同组件化规划？可能有些交互规划师本能上是抵抗组件化规划的， 由于组件化的规划从某种视点上讲可能会扼杀规划师对产品规划的构思。从交互视角看组件化规划，首要需求认同组件化规划。这儿可以讨论两个问题。1. 组件化规划能给产品或事务方带来什么？组件化规划带来的是复用：规划的复用，开发的复用，用户体会的复用。复用可以进步功
3、率：在产品迭代的进程中进步功率， 在用户体会的运用上进步功率， 防止用户因产品同类功用的操作不一致而下降运用体会，并且后期组件可以同步迭代更新。2. 一般事务方应该会更注重产品内用户场景性体会规划，那组件化规划后会不会献身事务方产品的用户体会？在组件规划初期， 交互规划师也需求充分发掘当下产品事务方尽可能多的需求， 乃至未来潜在的事务需求，从需求的结构上笼统出组件模块规划。但这儿的组件规划并非仅做大局结构规划，组件的细节也是需求打磨的， 并且组件化规划要凌驾于必定的交互标准根底之上， 防止后期规划的“乱用”。别的，在打磨细节时，特别要注意体系的稳定性和可维护性，能确保后期体系经过若干迭代后还能
4、保持一个运作杰出的生态体系。什么样的需求或产品可以去做组件化规划？现在组件化现已趋于遍及，单一功用的组件更常见，比方查找组件、选择器组件，也有较完好的功用模块组件。 每一个组件都是一个完好的产品， 它们在事务产品内不断扮演着再组合更多产品的人物。但并不是一切的功用都合适去做组件，组件本身不存在影响产品的好与坏，最重要的是在驱动组件化规划及晋级之前，要以组件化思想的姿势，对项目现状有比较明晰的评价和认知，全面审视需求方向，考虑处理计划，提炼全功用组件。在衡量组件化规划这个问题上，也可以去测验探寻一些量化办法，当然也不局限于量化的数据，更重要的发掘产品方及用户的诉求。这就需求检测组件建议者对产品需
5、求的思想广度与深度。规划前期怎样快速接纳并消化组件化需求？拿到需求后怎样着手去消化并剖析需求， 也就是我们规划前期应该做好哪些作业？从确定建议做题库组卷模块的组件到项目落地，我几乎没有充裕的时刻去深入了解需求。简略剖析一下，首要组件化需求的特色是事务需求下沉，需求功用模块化，模块与模块关联性更强。组件化需求的终极方针是将需求实现成由 n 个 box 组合而成的功用，类似于乐高积木，尽管每个积木都是彼此独立的，但是可以灵敏，可以多样。相同，拼装起来的组件模块也是灵敏多样的，功用也是强壮的，所包括的逻辑性也就更强。所以，面对组件化需求，依据其需求特色，总结了以下几点快速接纳消化需求的办法：1. 需
6、求思想模块化，快速分化需求。组件与组件之间不应该存在环形依赖联系，所以大可以去快速分化需求。换种说法，就是将事务规划思想转化为通用规划思想。举个简略栗子：题库需求可能涉及到多种题型，比方单选题，多选题，填空题，组合题等。题型与题型之间会有相同特点和不同特点， 那就需求将一切特点抛开题型抽离出来， 对相同特点进行剖析，相同特点即可规划为同类组件，乃至也考虑可以运用同一组件。2. 尽可能完好地走查和收拾一切已有 & 潜在事务场景，并依据对需求稿的了解构建大局观，全链路考虑处理计划。3. 提升同理心，堆集刻画自己的常识体系，拓展自己的需求视界。项目问题与处理办法在实践的规划与项目发展中， 多多少少都
7、会遇到许多问题。 总结了以下几个比较典型的问题及处理办法。一起这几个问题也是做组件化需求特别要注意的问题。怎么确保组件规划的一致性？组件化交互规划最根本的一点是确保规划的一致性。 在准备将某个功用模块做成组件时， 我们一般要考虑所做的规划够不够通用，能不能满意接下来的需求？除了学习参阅 ios，andriod 和其他操作渠道的原生规划标准外，这儿共享两种简略的办法：1. 尊重用户习气。可以选择现在比较成功的同类竞品，将其产品结构结构及操作标准收拾一下，一般竞品成功的原因不外乎两个：一是给用户带来了运用价值，二是给产品方带来了商业价值。已然给用户带来了运用价值， 那这些产品的功用或操作体会在某种
8、意义上讲应该是根本契合用户心思预期的，这些成功竞品的功用或操作标准也是和用户的习气相得益彰的，是有学习意义的。2. 将需求终究呈现为交互结构时，可以测验自上而下对信息结构化归类。比方归类颗粒度为：操作特点，信息展现特点等等，而信息展现特点又可以向下归类为列表类，卡片类等等，这就可以回归到我们常说的交互组件库。比方下图所示，题库的办理与试卷库的办理。题库是对标题的办理，试卷库是对单份试卷的办理，尽管是两个不同的功用模块，但确有着极相似的操作特点与信息展现特点。怎么确保规划计划的可行性？在组件化交互规划上， 确保规划计划可行性也是非常重要的。 已然是整个功用或模块去做组件化规划，那它的逻辑性相对来
9、说也是较为杂乱的，由于它交融了更多事务方产品的需求。而我们的方针就是需求将这些杂乱的需求转化为更简略，更灵敏的功用，满意不同的需求。在交互规划上，为了确保规划计划的可行性，首要要考虑整个规划的环路，无论是应用层，结构层，逻辑层都要 一 一 剖析，但是真正在项目实践中，时刻很难答应我们去套用完好的研究办法论，只能靠经历或自己习气的规划办法快速产出终究方针。这儿引荐一种针对杂乱项目特别有用的规划剖析办法：经过基因分化，解构基因，再整合基因的办法，收拾结构、时刻线、基因之间的联系去安排新的信息结构、并设定方针使命流程。这儿的基因可以是需求，可以是模块，可以是场景，也可以详尽到项目流程中的每个环节。也
10、可以经过（人）人物原型，（事）要处理的需求，（物）所在的当下场景去剖析。剖析到位后再整合到整个规划进程中。以下经过 EduOS 所做的题库组卷事例简略剖析几个模块：1. 应用层。题库组卷作为教育体系模块，可以从教育后台和用户学习前台两个场景下收拾需求及流程。将每个场景下的时刻节点与操作节点收拾出来，并收拾两个场景下的流程关联联系。2.结构层。在组卷内，本来的组卷办法依据 4 种不同的组卷形状存在 4 种不同的设置办法，办法单一，不够灵敏。而题库组卷的需求是期望做更灵敏，更通用的组卷办法，而不局限于组卷的形状。所以明确了如下图所示的需求规划方向。别的， 此次组卷我们新增了主客观组合在一起的组合卷
11、。 所以需求剖析新的组合卷较以往的组卷办法，它们的差异以及各自的特点别离是什么。3. 逻辑层。再来别离剖析一下题库及组卷的事务流程及操作逻辑，结合其操作特点构建完好的规划环路，并将其转化为更直观的流程图。4. 整合。终究将终究剖析出来的有用基因进行整合，将整个环路收拾出来，在这根底上再来进行交互大结构的规划。别的，组件化需求一般是在已有功用的根底上被提议的，产品策划一般会对产品规划的办法定义为 3 种：复用，装备，定制。这 3 种办法相同影响到交互规划计划。在了解组件布景（需求大布景）、组件衍生需求场景、组件存在办法的时分，牢记不要急于规划计划，即便担任的是交互规划人物，最好也要了解组件怎么接
12、入产品、组件特性、事务方产品特性、接入影响范围等等，了解这些对组件化的规划也是有很大协助的。EduOS 项目从需求环节上就现已收拾出大部分逻辑层的内容，所以在规划进程中能比较快速的了解与剖析这些环路。一起，整个进程经过产品，规划，开发，测验一起的尽力下，经过屡次计划的优化与规划完结了终究产品底层结构的搭建和功用规划。怎么防止反常情况的遗漏？在组件化规划的进程中， 不乏逻辑过于杂乱导致需求调整或交互规划不全面的问题这儿引荐一种节点式的排除法，行将流程要害点收拾出来，经过这些要害点去处理反常情况。行将用户对应的操作时刻点和影响因子 一 一 列出，连线剖析可存在场景，并查看这些场景是否都 一 一 处
13、理。比方影响到学生答题中这个状态下的反常要素就有这几个：试卷发布，授权标题被撤销，教师修正标题内容或分值，教师从头判分，答题限时已到，提交截止时刻已到，URL 进入试卷等等。了解与考虑以下几点是在整个 EduOS 项目中对组件规划的几点考虑。灵敏高效 重易用性在组件通用的根底上，终极方针是灵敏高效协作。一起，在项目进行中，可以针对某一项通用功用在短时刻内测验多种规划计划， 尽量考虑多种场景， 简化操作流程， 重易用性。 好的组件规划，会给产品带来立异，带来更好的体会。关联性做产品的组件化规划，要注重关联性，包括功用与功用之间的关联性，一起也包括前后台用户之间的关联性。事务兼容，可扩展性做产品的
14、组件化规划，要兼容事务，一起关于扩展性要求很高，所以要求产品及规划可以在熟知事务的根底上，有笼统建模的才能，可以笼统出模块与模块之间的联系，有很好的产品前瞻性，这样确保后台产品架构上明晰灵敏，扩展性强。一起，对渠道载体和功能的约束也要考虑到，规划上也要考虑数据体系维护及规划的延展性。现在， 整个教育产品部门的发展规划形式上也会将部分需求笼统出一种公共才能， 即笼统出若干组件去做，并将组件更好的服务于各产品线。总归，做组件化交互规划，要做到：逻辑思路要明晰，交互规划要标准，产品结构要灵敏。有些人会简略的以为一个产品的后台就是对一个产品前台功用的装备， 在此根底上可以满意产品方和用户运用产品的需求。但产品后台正是表现了整个产品的运营思路和事务逻辑。一个完好的，良性运营的后台是对一个产品健康发展的重要保障。当然，关于某个模块的组件化规划，决计不是一篇千字不到的文章就可以将其整个生命周期论述清楚的，因而，这儿只跟我们沟通一下在组件化规划进程中总结出来的规划办法和对后台组件化规划的了解与考虑， 仅供我们沟通
