馃帹 Work item due date design
Summary
Work items will have a "date range", consisting of both a start and end date. Users can set these dates manually AND view a synced date range based on the work item (and its children) relationship to timeboxes/date range and dependent work items. Both manually set date ranges and synced date ranges can be visible simultaneously.
Full details and iteration path: &8194
MVC 1: #365399 (closed)
Proposal
This design aims to provide a framework that can accommodate the end state of the widget. Not all features from later MVCs are included, as those features may not live in this widget (date information will also appear in child items, roadmaps, etc), but consideration was given to how those could be added here if relevant 鈥斅爐he approach can adapt to additional information.
This widget uses a tertiary button
as its base component, with a dropdown overlay providing input. This diverges from previous widgets (assignees, weight) which use an input as the base as due date contains multiple inputs and conditional information. An approach to this using a single row was explored but felt too cumbersome and lacked adaptability.
Start Date
Start date is not present by default and must be opted in. The expectation is that start date will be used less often, and defaulting users into that field could be jarring.
Start date cannot exceed due date and vice versa; show error if invalid entry is provided and discard input without prompt if dropdown is closed in invalid state.
Datepickers
In proposed MVC1, standard datepicker components are used.
Beyond MVC1, a persistent 2-month calendar is proposed (1-month at XS size). It's expected that dates will often cross months, and with start and end dates both applied visualizing the range will help users make selections and/or validate their input.
Syncing
Beyond MVC1, planned start and due dates will have the ability to sync to other items within the planning space. There is a rigid hierarchy that determines what the sync target is, in order of most to least priority:
Blocking work items > Assigned iteration > Assigned milestone > Parent dates
Users can enable or disable syncing on each work item (by default it will be on). Manually setting a date automatically disables syncing, however users can re-enable syncing which will replace the manually set dates with the sync date(s). Whenever syncing is enabled, and a sync-able item is present, show a sync icon in the default state and define the sync in the active state.
Example:
- User creates work item
- User assigns work item to milestone 5
- If milestone 5 has dates, work item due date becomes milestone 5 dates; if milestone does not have dates, the work item remains synced with an empty due date
- User changes the due date
- Due date set to user input; sync is automatically disabled and must be manually re-enabled
- Work item reassigned to milestone 6
- No change to due date
- Due date sync re-enabled
- Dates set to milestone 6 dates
Status warnings
Status warnings, such as Overdue, are shown as a badge outside of the button. Currently only Overdue is accounted for, but this pattern could be used for more descriptive information like "Starts in 1d" or "Due in 2d".
&8194. Very DRAFT: Date range logic
Just an Idea riffing on the MVCs outlined here --Parent:
- If Miletone and Iterationa are set directly on the work item, show the
min
date range in the "planned" - If neither, no default date range is set
- Manually setting the date range unsyncs the date range from any timebox.
- If Milestone or Iteration is directly set on the item and manually set date range exceeds Milestone or iteration date ranges, show warning indicator.
- If date ranges of all children exceed the date range on the parent, show a warning indicator.
Child:
- Milestone synced by default to parent, but can be manually changed.
- If manually changed and the date range of the milestone exceeds the date range of the parent, show a warning indicator
- Iteration synced by default to the parent, but can be manually changed. If manually changed and the date range of the directly set iteration exceeds the date range of the parent, show a warning indicator.
- If neither parent or child has milestone or iteration set, but parent has manually set a date range, then the date range for the child is synced to the parent, but can be manually set.
- If manually set date range exceeds that of the parent, show a warning indicator
Blocked:
- If the blocked by work item has an end date, the start date is synced to the end date + 1 day.
- If the blocked work item has milestone or iteration dates and those start dates are before the end date of the blocked by, show a warning.
- Decision Needed: This is where the importance of defining what type of dependency blocked/blocked by is -- is it Finish to Start (FS), Start to Start (SS), Finish to Finish (FF), or Start to Finish (SF)?
So the basic order of precedence would be:
- Directly set date range. always show
- Show warning when: 1) the date range exceeds the date range of iteration, milestone, or parent date range. 2) the date range overlaps a work item it is blocked by.
- Synced to the work item's
blocked by
work items.- Show warning when: See open questions about this behavior.
- Synced to the
min
time range of all child timeboxes/date ranges.- Show warning when: 1) the synced date range exceeds the date range of the directly set date range (if set).