1 前言
转眼毕业工作一年零四个月了, 又是很久不更新博客了, 每次学到个新的东西或者在工作中做了个自己很满意的尝试, 就想着写篇博客总结分享下吧, 可是打开博客的那一刻却如同提笔忘字一样不知从何开始, 纠结过后就放弃了. 那这次又为何要写一篇呢? 那就要提到今天的主题了 --DocsM(Documents Management), 对就是文案管理, 一个帮助你如何解决静态文案管理的方案, 最近已经对外开源, 感兴趣的小伙伴可以去 GitHub
一探究竟. 那么接下来就要给大家来个深度剖析了, 看看我们到底是怎么做的.
2 背景
作为 FE, 我想大家都有一个共同的体验 "在代码功能上线后, 因为一两句文案或提示信息描述不准确需要修改, 修改后就要重新上线", 此时心里的感觉可以说是五味杂陈..., 我们都知道线上无小事, 上线并不是说打个包点击发布就可以了, 必须要经过: 本地测试, 测试环境测试, 预发环境测试, 线上环境测试, 每次上线操作这些流程都是必须要走的, 就因为一句文案的修改无形中浪费了半个小时的时间, 如果有个平台提供修改静态文案的功能, 就可以帮助前端开发者来解决这一痛点. 那么今天将向大家介绍, 为了解决这一痛点, 我们的 DocsM 向大家所提供的功能, 以及功能的设计实现.
3 DocsM 是什么
DocsM 是一个静态文案管理平台. 用于修改 web 页面的静态文案, 支持文案国际化, 并提供提示信息的 UI 展示. 它的目的是解决前端开发者频繁的静态文案修改问题, 避免因为简单的文案修改而发起复杂的上线流程.
4 DocsM 可以干什么
下面是一个简单的描述和演示, 展现了接入文案管理平台后你的系统可以通过如下的方式去修改页面上的文案信息.
4.1 提示文案修改
有权限的用户可以看到, 在页面的右下角有一个开关按钮, 打开按钮页面上会出现编辑的红色按钮, 点开按钮即可修改提示文案信息, 提交保存后刷新页面即可看到修改后的内容. 同时提示信息的容器 UI 展示也是平台提供.
提示修改
4.2 页面文案修改
页面内容文案的修改方式和提示信息修改一样, 但是不同的是多了一个发布的操作, 因为页面内容要比提示的要求更严格一些, 修改后会直接影响用户的直接观感. 所以这里我们对线上和线下环境做了区分, 未发布前只可以在线下环境看到, 去后台管理系统发布后线上即可同步.
页面内容文案修改
4.3 文案国际化
在演示中提供了中文和英文两个版本的语言, 点击按钮可以看到不同语言内容的切换.
文案国际化
5 DocsM 是怎么做的
看到上面的简单介绍, 或许你脑子里已经对这个功能有了自己的实现方案, 那下面就看下我们是否想的一样呢~
5.1 设计架构图
设计架构图
5.2 详细设计
5.2.1 模块划分
由架构图可以平台划分为四个模块:
SDK:SDK 作为平台和第三方平台连接的一个纽带, 将管理平台和第三方平台连接在一起, 以 JS 文件的形式嵌入第三方平台, 从 Web-Server 获取文案数据展示在第三方平台页面中, 并提供可视化界面供产品和开发可直接在自己平台页面中修改文案内容;
Web-Server:Web 接口层, 提供文案数据的增删改查接口;
Web-UI: 文案管理平台的管理界面, 要接入的第三方平台的管理人员在此可将自己平台的文案管理接入我们的平台中, 之后文案修改的操作可在此进行;
MongoDB: 对各个接入平台的文案信息进行存储;
5.2.2 各模块的详细介绍
SDK
产出形态: 该模块最终打包为 JS 文件, 嵌入在第三方接入平台系统中;
主要功能: 将文案管理平台和获取文案内容, 将内容显示在系统页面中, 并提供 UI 界面供产品和开发可直接在自己系统中对文案进行修改, 刷新页面后即可生效;
具体实现:
获取第三方平台传入接入时创建的系统的名称和当前登录的用户名, 获取文案和数据以及对应的用户的权限;
扫描页面中的 html 标签, 带有特殊属性的则根据当前系统的语言和数据的类型显示不同形态的文案: 鼠标悬浮提示, 气泡提示, 页面文案显示;
根据用户创建的权限, 判断用户是否有编辑修改权限;
对于有权限的用户显示开关, 打开打开可对文案内容进行修改, 保存后如果是提示信息即刻就生效, 页面直接显示的文案则发布后即可生效;
Web-Server
主要功能: 提供文案数据的增删改查接口;
模块划分:
服务管理: 第三方接入平台的信息管理;
文案信息管理: 第三方接入平台的页面文案管理;
Web-UI
主要功能: 提供管理端的各种可视化操作;
第三方平台信息的管理: 包括新增, 修改和权限管理;
文案信息的管理: 包括文案信息的新增, 修改, 以及屏蔽功能;
6 DocsM 的优点
上面讲了这么多关于如何实现的内容, 相信大家对于我们做的是什么已经有了一个整体的印象, 那么我们为什么要这么做呢?
如文章开头时讲的那个场景 "简单的文案修改, 直到上线发布 check 无误需要半个小时", 如果每天多做几次这样的事, 其他的事情应该就不用做了, 心里也是一万句... 如果这件事是谁提出来就让谁直接去修改岂不更好.
所以我们最大的优点就是:
节约时间成本: 省略审批发布流程, 秒级修复线上错误内容;
赋能: 让非技术同学 (运营或者产品, 法务等, 以下简称非技术同学) 可以通过可视界面快捷的修改页面内容, 而非之前的非技术同学提供文案, 然后同步技术同学之后再去修改, 这样沟通成本大大增加. 所以我们在降低沟通成本的同学和释放了技术同学的时间.
7 结语
目前平台已经在公司多个内部平台使用, 用于解决日常的文案修改, 后续我们也会持续更新维护. 如果看到这篇文章的你, 将 GitHub 上的 demo 跑起来了, 欢迎评论留言, 一起沟通交流.
GitHub:https://github.com/didi/docsm
欢迎 fork & star
来源: http://www.jianshu.com/p/1d4295f1ed68