🎨 Design: Work item applications framework

Background

Within Work Items, it's expected that certain types of widgets will exist that are more complex than attributes. This complexity could be a result of containing more than 1 type of data, requiring interaction beyond selecting values, or having data that can't easily be displayed in a small space.

#368944 (closed) details which widgets might be considered Apps, and includes time tracking, timelines (incidents), metrics (incidents), as well as things like the design manager, and even description or activity. While attributes should have a generally consistent layout and appearance, applications as defined may require more flexibility.

Goals

This issue seeks to define a common framework that be used for most "application widgets".

The ideal solution is flexible to accommodate different content while recognizing that complex application content may not always be needed when viewing a work item — it should be flexible both in what it can contain, and how much content is shown by default.

Tasks

  1. Anyone: Review and leave feedback on the proposed concepts
  2. @nickleonard: Consolidate around a single concept, re-concepting if needed, and review with engineering
  3. @nickleonard: Define and document the solution and any constraints as part of the Work Item object in Pajamas
  4. Engineering/@nickleonard: Define and document any implementation considerations as part of the Work Item docs (blueprint)

Feedback suggestions

Each concept is in a single design, which can be commented on directly. Comment in the issue for general feedback or alternate ideas.

All concepts are shown with 7 applications present. While it's possible there could be more, this seems like a realistic "worst case" for a single work item type. In most cases you'd likely see a smaller number at once, but the ideal solution should hold up to a reasonable worst case as well as the more common cases.

Open questions

  1. Should all currently-defined applications widgets utilize the common framework?
  2. If NO to 2, should non-attribute widgets that don't utilize the common framework be classified differently?

    1. "Non-attribute" differentiates widgets which hold typically 1 value, and whose interaction is centered around updating that one value (attribute), from those which can hold many values and/or interactions (non-attribute).


      Examples of "non-attribute" widgets could be relationships (in current issues, tasks, linked issues, related MRs, etc.), incident timeline, incident metrics, and time tracking.

Edited by Nick Leonard