[go: up one dir, main page]
Skip to content

[UX] Create flow for planning objects

Problem

  • We're trying to avoid a separate "create" form for work items.
  • When creating a work item, we must know the type to populate the appropriate widgets.
  • There are lots of different pathways to creating issues and epics today. Many of these load a separate "create" form.
  • The creation flow for different work item types varies across the product. We need to standardize the creation flow to provide consistency for Issues, Epics, Incidents, Tickets, Requirements, Test Cases, Objectives, and Key Results

Considerations

  • It would be wise to future proof the creation flows in the event there is work item parity between group and project.
  • You should be able to select a target location for creating the work item. It should default to your current context (group/project).
  • We'll need to figure out a way to handle template selection.
  • ...

Current creation pathways

  • Project > issue list > New Issue > Create Form
  • Global Nav > + > New Issue > Create Form
  • Group > issue list > Select Project > New Issue Form
  • Group > epic list > New Epic > New Epic Form
  • Epic > hierarchy widget > Add New Issue > Inline creation
  • Epic Board > New Epic > Inline creation
  • Group > Issue Board > New Issue > Inline creation
  • Project > Issue Board > New Issue > Inline Creation
  • Vulnerability > Create New Issue
  • Project > Incident > Create New Incident
  • Issue/Incident > Create Related Issue/Incident > New Item Form
  • Email Client > Project Email Address > Auto Creates Issue From Email
  • Slack > New Issue
  • Merge Request > Comment > Create Follow Up > New Issue Form
  • Issue > [Checklist item] > Convert to task

Design

Contextual view and post-save

The create form should always appear in a modal, as shown in the designs. While the contextual view when opening a work item is moving to a drawer, the modal works better for the Create context as it gives more focus to the creation workflow (you're just creating, not browsing a list) and makes the contextual view more reusable, as it will be less important what content is "under" the modal.

Once saved, the modal should close and a toast appear with the text " created." and an action "View details".

  • The open action by default opens the canonical link to the work item in a full page view.

Modal vs Drawer

  1. Content underlying the component matters less with the modal. With the drawer we'd have to worry about what this was opening on top of — what if there's already a drawer? With global create we have limited control, and the modal is a bit more friendly to any context.
  2. This creates intentional separation between the creation form and the final object. The draft item is similar but not yet a work item, and lacks things like commenting. This helps users orient that they're in a draft form, not a complete item. This also keeps the drawer connected as a mechanism of lists/boards rather than an arbitrary way to open work items, which is intentional.
Edited by Nick Leonard