前往小程序,Get更优阅读体验!
立即前往
首页
学习
活动
专区
圈层
工具
发布
首页
学习
活动
专区
圈层
工具
MCP广场
社区首页 >专栏 >B端产品设计——批量导入

B端产品设计——批量导入

作者头像
物流IT圈
发布于 2020-08-10 04:01:41
发布于 2020-08-10 04:01:41
2.4K0
举报
文章被收录于专栏:物流IT圈物流IT圈

最近工作过程中,涉及到两次批量上传文件的设计,也存在一些异常情况等的困惑,参考了一切B端产品进行总结。

本次总结,参考了:钉钉、有赞、草料二维码、企业微信等产品和部分文章进行输出。

一、使用场景

    1. 一次性需填写的字段数量多,在excel中复制填写速度快;
    2. 数据多,重复提交浪费时间。

二、批量导入

1. 如何降低导入时错误概率?

1)提供下载模板

在列表页同时出现下载模板和批量上传按钮:

只出现批量上传按钮,在批量上传弹窗提供下载模板:

此处推荐第二种方式。第一种方式在点击批量上传时没有模板,需重新关闭点击下载模板。且下载模板的这一动作仅存在需批量导入时执行,一直置于列表页的话,本身操作就多的列表页又增加了一个按钮。

2)模板最好由产品/交互进行设计,重点要写清填写规则,避免规则不清晰导致用户填写错误

钉钉-批量导入:

企业微信-批量导入:

有赞-批量导入商品:

草料-批量导入:

模板设计要点:

  • 标明必填、选填
  • 对不可修改字段进行强调,避免用户随意输入
  • 时间格式的规范,2020-07-19,还是2020/07/19,还是2020.07.19,虽然后端可以几种格式都进行识别,但用户的输入可能远远不止三种,设计/后端无法对每种情况都进行排查,所以还是进行提示较好
  • 特殊符号的限制,例如中文和英文的逗号、括号在代码中不同的,如果没有进行双重识别,最好还是提示用户按什么语言输入
  • 在模板中根据标准,填写一行“较为真实”的数据,提供用户“抄写/模仿”

3)对于固定选项的字段,提供选择,而非输入(在模板设计时进行)

2. 上传情况有哪些?如何进行设计?

1)文件类型、大小

  1. 一般仅支持.xls 和 .xlxs 格式
  2. 文件大小看校验能力以及等待时长。为了节省服务器的空间和提高文件传输的速度,需要限制上传文件的大小。建议不要过大,目前我设置为2M的大小(这一点我不是很确定,与研发同事进行沟通,由于部分字段需进行校验判断,数据量大的时候会导致传输速度非常慢,因此2M是合理的范围)

2)部分成功、部分失败

对于部分成功、部分失败的数据而言,有两种方式。一为支持错误信息在平台上直接修改后保存,另一种为提供错误清单,重新上传。

前者开发较繁杂,一旦涉及数据量大时,修改起来比较耗时,且容易再次出错。

设计要点:

  • 提示成功上传n条,失败m条,提供<错误清单.xls>
  • 错误清单除了包括错误的数据,还需包括错误原因,例如:必填项漏填、填写错误、号码已存在、编号重复等。如果一条数据存在多处错误,通常程序只显示第一个错误原因,再次上传,再次提示另外的错误,直至正确为止。也可以一次性提示多个错误,开发同事拿着刀在等着而已。
  • 除了错误清单外,系统也可以直接在上传后显示错误的行数、信息。用户可以直接在原本的文件上进行修改,不需要进行下载<错误清单.xls>操作

3)列名与模板不一致/列的顺序不一致?

钉钉:钉钉是默认第几行是什么字段,与字段名无关。

例如第二行与第三行列名换了,但内容是对的,仍会上传失败。若手机号那一列写的是姓名,则会上传成功。

其它为识别列名,若列名错误,则提示错误。

无论哪一种都可以,但比较推荐识别列名。比较符合认知,及时列的顺序反了,仍能识别正确。

4)顶部填写须知去除后,是否支持上传成功?

  1. 钉钉:提示:文件列名不能被修改或删除,请重新导出模板
  2. 企业微信:上传成功

5)错误表单怎么设计?

提供每一条错误数据的错误原因。

6)数据重复,选择覆盖/跳过/上传失败?

根据不同场景,进行选择:

  • 若没有提供错误清单,则直接上传失败。避免用户得将表里面正确的数据去除,再修改错误的数据,不如一次性不上传;
  • 若是覆盖后不会造成影响,可以进行覆盖。例如员工的信息等;
  • 若是数据编号重复,会造成各种影响,或者直接不能编号重复的数据,则进行跳过,最后在错误清单中提示:编号错误即可。

例如,本次工作中,导入的数据会传到第三方的平台,数据一直都是不变的,正确即可上传第三方平台。那么就不存在去覆盖旧数据的可能。

虽然在B端产品中处处可见导入导出,但细究起来,仍还有很多点没有涉及到。目前仅是针对工作内容进行的拓展学习,可能还有部分坑没有躺过,可以进行交流。

B端的其中一个价值为提高效率,让导入导出更好用,更人性化、智能,才能提高使用效率。

本文参与 腾讯云自媒体同步曝光计划,分享自微信公众号。
原始发表:2020-08-03,如有侵权请联系 cloudcommunity@tencent.com 删除

本文分享自 驼马精英 微信公众号,前往查看

如有侵权,请联系 cloudcommunity@tencent.com 删除。

本文参与 腾讯云自媒体同步曝光计划  ,欢迎热爱写作的你一起参与!

评论
登录后参与评论
暂无评论
推荐阅读
领域驱动系列三
领域模型是软件项目中的核心,模型是团队经过长时间的归纳总结形成的一个与项目有关的概念集合,他用术语和关系表达了领域的深层含义,这种关系和语义提供了模型语言的语义,模型语言是为领域独家定制的.十分的精确,并且他将开发过程和模型绑定到一起,并使代码和模型紧密的绑定.
郑小超.
2019/01/03
4070
DDD理论学习系列(1)-- 通用语言
1.引言 在开始之前,我想我们有必要先了解以下DDD的主要参与者。因为毕竟语言是人说的吗,就像我们面向对象编程一样,那通用语言面向的是? DDD的主要参与者:领域专家+开发人员 领域专家:精通业务的任何人。 开发人员:开发+测试。 领域专家擅长某个领域的知识,专注于交付的业务价值。 开发人员则注重于技术实现。 开发人员总是想着类、接口、方法、设计模式、架构等。以面向对象的编程思想进行思考,思考如何进行抽象、封装、继承、多态等。而领域专家对软件中的框架、持久化、数据库等没有概念,而这也就导致了他们
圣杰
2018/01/11
1.5K0
领域驱动设计学习之路—DDD的原则与实践
本文是我学习Scott Millett & Nick Tune编著的《领域驱动设计模式、原理与实践》一书的学习笔记,一共会分为4个部分如下,此文为第1部分:
Edison Zhou
2019/05/10
2.1K0
领域驱动设计学习之路—DDD的原则与实践
字节一面挂了,面试官问DDD,我却不知道
在介绍DDD(Domain-Driven Design:领域驱动设计)之前,我们先回顾一下,现阶段的产品迭代中常常出现的一些问题,以及这些问题会导致什么。通过对问题的总结和分析,再回头看一看,DDD能帮我们解决什么?
爪哇缪斯
2023/05/10
4840
字节一面挂了,面试官问DDD,我却不知道
谈一谈 DDD
最近 10 年的互联网发展,从电子商务到移动互联,再到“互联网+”与传统行业的互联网转型,是一个非常痛苦的转型过程。在这个过程中,一方面会给我们带来诸多的挑战,另一方面又会给我们带来无尽的机会,它会带来更多的新兴市场、新兴产业与全新业务,给我们带来全新的发展机遇。然而,在面对全新业务、全新增长点的时候,我们能不能把握住这样的机遇呢?
冬夜先生
2021/12/06
5110
[译文]Domain Driven Design Reference(二)—— 让模型起作用
  很多项目做建模工作最终没有获得太多的实际好处。DDD模式从项目中提炼成功的实践使得建模带来了巨大的好处。总的来说,他们提出了一个与先从细节再到高层次的视角【1,在DDD之前我们大部分都习惯于先进行数据表的设计】完全不同的建模和软件开发的方式。严格的建模惯例必须平衡好与非技术人员【2,一般这里指领域专家】合作进行的模型探索。战术和战略必须结合才能成功,DDD同时涉及战术和战略的设计。
Zachary_ZF
2018/09/10
3480
软件方法(下)第8章分析之分析类图—知识篇Part05(202205更新)领域专家和通用语言
一个领域之所以能作为“领域”为人认知,必定会在发展过程中沉淀出一套日益完善和精确的术语体系。每个术语有其独特的、其他术语不能替代的含义。
用户6288414
2022/05/27
4020
软件方法(下)第8章分析之分析类图—知识篇Part05(202205更新)领域专家和通用语言
领域驱动设计
关于领域驱动设计 这篇文章参考了Eric Evans《领域驱动设计》一书以及Jimmy Nilsson《以C# .NET为例运用领域驱动设计和模式》,二者详细描述了领域驱动设计的核心概念、技术和模式。在某些情况下,直接使用这些书的措辞是有意义的,并且我认为Eric Evans和Jimmy Nilsson也允许我们这么做。 尽管将方法本身呈现出来是很有用的,但是仅仅对方法进行描述,DDD的许多微妙之处就会消失。这些方法应该是你的工具,而不是你束缚你的规则。它们是为设计而生的语言,在团队内沟通创意和模型十分有益
程序猿DD
2018/03/21
1K0
领域驱动设计
DDD开篇总结
对于DDD的启蒙,不管是国内还是国外思维逻辑都是一样的。或者说如果你想写本关于DDD的书,大纲似乎是一样的
码农戏码
2021/03/23
5230
限界上下文是什么鬼?DDD 最抽象的概念详解
- 什么是通用语言 - 通用语言, 最主要的目的就是减少交流中信息丢失, 在实际开发中, 可能关联很多人, 例如有业务层面的业务细节制定者、领域专家、产品经理、项目经理 、架构师、开发
玄姐谈AGI
2021/07/29
6.3K0
DDD领域驱动实战 - 限界上下文(bounded context)
限界上下文定义领域边界,以确保每个上下文含义在它特定的边界内都具有唯一的含义,领域模型则存在于这个边界之内。
JavaEdge
2020/10/02
4.3K0
DDD领域驱动实战 - 限界上下文(bounded context)
[译文]Domain Driven Design Reference(五)—— 为战略设计的上下文映射
  两个组之间的关系是“上游”小组的行为影响“下游”小组的项目成功。但下游的行为并不会显著影响上游项目。(例如,如果两个城市沿着同一条河流,上游城市的污染主要影响下游城市。)
Zachary_ZF
2018/09/10
3580
真下饭!字节技术官DDD(领域驱动设计)手册,拆解业务代码首选
至少20年前,一些顶尖的软件设计人员就已经认识到领域建模和设计的重要性,但令人惊讶的是,这么长时间以来几乎没有人写出点儿什么,告诉大家应该做哪些工作或如何去做。尽管这些工作还没有被清楚地表述出来,但一种新的思潮已经形成,它像一股暗流一样在对象社区中涌动,我把这种思潮称为领域驱动设计(domain-driven design)。
愿天堂没有BUG
2022/10/28
5510
真下饭!字节技术官DDD(领域驱动设计)手册,拆解业务代码首选
领域驱动设计(DDD)部分核心概念
点击上方“芋道源码”,选择“设为星标” 管她前浪,还是后浪? 能浪的浪,才是好浪! 每天 10:33 更新文章,每天掉亿点点头发... 源码精品专栏 原创 | Java 2021 超神之路,很肝~ 中文详细注释的开源项目 RPC 框架 Dubbo 源码解析 网络应用框架 Netty 源码解析 消息中间件 RocketMQ 源码解析 数据库中间件 Sharding-JDBC 和 MyCAT 源码解析 作业调度中间件 Elastic-Job 源码解析 分布式事务中间件 TCC-Transaction
芋道源码
2022/03/30
4110
领域驱动模型(DDD)
2004年Eric Evans 发表《领域驱动设计——软件核心复杂性应对之道》(Domain-Driven Design –Tackling Complexity in the Heart of Software),简称Evans DDD,领域驱动设计思想进入软件开发者的视野。领域驱动设计分为两个阶段:
高广超
2018/12/12
3.9K0
走近DDD
点击上方“芋道源码”,选择“设为星标” 管她前浪,还是后浪? 能浪的浪,才是好浪! 每天 10:33 更新文章,每天掉亿点点头发... 源码精品专栏 原创 | Java 2021 超神之路,很肝~ 中文详细注释的开源项目 RPC 框架 Dubbo 源码解析 网络应用框架 Netty 源码解析 消息中间件 RocketMQ 源码解析 数据库中间件 Sharding-JDBC 和 MyCAT 源码解析 作业调度中间件 Elastic-Job 源码解析 分布式事务中间件 TCC-Transaction
芋道源码
2022/03/04
4070
重读领域驱动设计——如何说好一门通用语言
在 DDD 中,通用语言是以限界上下文为边界的。如果一个产品或者项目有多个限界上下文,我们就需要为每个限界上下文定义通用语言。
ThoughtWorks
2019/05/05
6740
重读领域驱动设计——如何说好一门通用语言
混合开发:TDD、DDD和BDD交集的值
测试驱动开发(TDD)是一种开发软件的过程,其中在编写代码之前先编写测试。一旦完成,开发人员将努力编写足够的代码以通过测试,然后开始重构。
程序猿玄微子
2020/12/05
2K0
混合开发:TDD、DDD和BDD交集的值
DDD“通用语言”背后的倒退-《软件方法》节选
DDD(领域驱动设计)话语中有“通用语言(Ubiquitous Language)”的用语,这是一个伪创新。
用户6288414
2022/10/31
5020
DDD“通用语言”背后的倒退-《软件方法》节选
领域驱动设计模式的收益与挑战
《软件学报》在2021年第32卷第9期刊登了一篇论文:《领域驱动设计模式的收益与挑战:系统综述》[1]。这篇论文是学术界在这一领域开山之作。
码农戏码
2021/11/18
1.3K0
领域驱动设计模式的收益与挑战
推荐阅读
相关推荐
领域驱动系列三
更多 >
领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档