it-swarm.cn

在行政申请中处理生效日期

在处理基于保险的信息时,我们经常需要在大多数数据上使用生效日期。我有很多原因,我不会涉及,不用说设计的一部分不能更改。

我经常遇到的问题是,当我需要为我们的业务用户创建此数据的管理界面时。通常,用户会在其所在屏幕的顶部选择一个生效日期。该生效日期将决定向其提供哪些数据以供编辑。 (即该数据在该时间段内有效)

现在,每当用户进行更改时,我们都会要求他们提供此更改的生效日期。然后,我们根据用户所做的更改数据库。

  • 如果他们删除了一条记录,我们实际上只是将记录的结束日期标记为
    更改的生效日期。

  • 如果他们更新了一条记录,我们将旧记录的日期截止,并创建一个新记录
    记录新的生效日期。

  • 如果他们添加了一条记录...那么我们添加一条记录。

这是我在使用良好的UI /用户体验时遇到的问题。

  1. 用户必须不断告诉我们更改的生效日期。这对于用户而言是麻烦且烦人的。

  2. 除非用户立即使更改生效,否则用户无法在屏幕上看到更改。这是由于在屏幕顶部选择了生效日期。此外,它们几乎永远不会使更改立即生效。

  3. 最后,由于我们实际上并没有做出他们期望的更改,因此我们不能仅以表格格式向他们显示数据,因为这对他们而言意义不大。他们会认为其中有一次数据,但是由于25次更改,他们会看到25次。

我希望我能对您对UI进行什么样的更改提供反馈,以帮助解决此类问题。我不确定这是否是人们必须经常处理的问题,但是在保险业中,我们必须经常处理。技术无关紧要,胖客户端,Web应用程序等。

编辑

要更清楚一点。

  1. 我所指的应用程序是处理后端数据修改的管理应用程序。实际的应用程序本身已经就位,并且正在使用所述后端数据运行。
  2. 指生效日期。当实际的应用程序请求数据时,它传递一个有效日期,以便找出该日期“有效”的记录。有一个相应的“结束日期”,该日期为null或已填充。在包含20个表的数据库中,可能至少有10个记录的有效日期。
  3. 当我说我们没有按照他们的期望去做的时候。我的意思是,他们说“删除此记录”,而我们实际上结束了日期。他们说“更新此记录”,我们实际上结束了它的日期,并创建了一个新记录。
  4. 每个条目都需要一个生效日期。如果是新记录,则应用程序仍需要知道它何时生效,其原因可能仅仅是因为那是企业想要它的时间,还是因为那是某条法律生效的时间。没有办法猜测。

的确,一旦操作完成,我可以简单地将确认/状态消息发布给用户,但是我一直试图做的是实现一个用户界面,使该过程对用户来说更加顺畅,信息量大并且更加直观。最终用户。因此,尽管他们可能不知道后端实际发生的每一个细节,但他们会对自己正在做的事情充满信心。

5
Jeff Sheldon

您能否创建一个垂直标签页界面,每个标签页都代表生效日期?单击选项卡以查看截至该生效日期的数据。 (想想苹果公司的时光机,没有精美的动画。)

要进行更改,用户将从输入生效日期开始。这将创建并选择一个新选项卡,该选项卡是该选项卡之前的选项卡的副本,并带有可编辑的字段。因此,很明显正在编辑哪个生效日期,还可以单击选项卡,并在其他时间点查看策略。

使用此处建议的模型,策略将永远不会“结束”(尽管数据库中仍有结束日期);它将在下一个生效日期之前被取代。

不幸的是,这意味着该政策永远不会在最后生效日期之后终止。您可以将最后一个选项卡标记为信号,以指示策略结束。因此,用户可以简单地更改结束标签的生效日期,而不是“删除”。 (您可能仍然有一个“删除”按钮-它将结束标签的生效日期更改为今天)。

4
Patrick McElhaney

很难避免要求用户提供每个更改的生效日期如果他们必须为每个更改提供特定的生效日期。虽然有一些机会。对人们如何使用您的软件进行一些研究,看看您是否可以找出一些模式。例如,也许用户正在管理帐户,并且帐户总是在每月的最后一天发生突变。如果是这种情况,您可以停止向用户询问这些突变的具体日期,而只需为他们填写(通过选择默认选项,或隐藏控件-用户测试以查看最有效的方法)。您还可以检查在全年或每个月中是否存在某些特定日期发生的定期日期,也许可以将其作为模板提供。例如,“性能检查日”或“每月最后一个星期五”。最终,您需要确定模式以了解如何优化工作流程并减少用户方面的投入。

编辑:取消删除并摆脱了大部分我不知道发生了什么的答案

3
Rahul