Uploaded image for project: 'ERM Platform'
  1. ERM Platform
  2. ERM-1648

Dashboard: Simple Search - improve the date filter comparator UX for "on or after"

    XMLWordPrintable

    Details

    • Template:
    • Sprint:
      ERM Sprint 118, ERM Sprint 119, ERM Sprint 120, ERM Sprint 121, ERM Sprint 122, ERM Sprint 123
    • Development Team:
      ERM
    • Release:
      R3 2021

      Description

      When editing a Simple Search dashboard widget, a number of date filters can be applied. For each date filter it is possible to set the date as: a fixed date, the variable "today" or for "today" with an offset, for example +10 days. Feedback from the ERM user group has shown that the current UX is confusing. Some alternative options have been discussed and a new UX pattern designed, as shown in the mockup.

      Mockup

      Scenarios

      Given the Edit pane for a simple search widget with a date filter, e.g. "Cancellation date"
      And the date comparator is either "on or after", "on or before", "is", "is not", "after" or "before"
      Then there is a set of three radio buttons as shown in the mockup
      And "Today" is selected by default.

      Given the group of fields: number, time and when
      When displayed on screen the fields have no visible labels
      When rendered in a screen reader
      Then the field labels "Number", "Time unit" and "When" are read aloud. // revised: ERM-1840

      Given the date selector fields
      When displayed on screen the field has no visible label
      When rendered in a screen reader
      Then the field label "Fixed date" is read aloud.

      Given the radio button option "Today"
      When not selected
      Then the text "Today" appears active (it is not greyed out).

       

      Dev task breakdown

      This component is getting slightly unwieldy.

      • It may be better to reimagine this as "SimpleSearchDatePicker"
        • a single field
        • internal controls for translating between tokens and dates
        • dealing with initialValues in a smarter way.

      This is more work, but will be a nicer component.

      • Similar approach may be wanted for the Internal Contact UUID filter
      • (replaces the current approach of hidden fields to track relative vs absolute)
      • Changes needed to initialValues functions etc

        TestRail: Results

          Attachments

            Issue Links

            There are no Sub-Tasks for this issue.

              Activity

                People

                Assignee:
                ostephens Owen Stephens
                Reporter:
                gosguthorpe Gill Osguthorpe
                UX Lead:
                Gill Osguthorpe Gill Osguthorpe
                Votes:
                0 Vote for this issue
                Watchers:
                3 Start watching this issue

                  Dates

                  Created:
                  Updated:
                  Resolved:

                    TestRail: Runs

                      TestRail: Cases