GitLab Plan Stage, 1 Sep 2023

Previous Meeting

Next Meeting

⏯

youtube image

►

From YouTube: Walkthrough of design proposal for creating and editing work items

Description

Related issue: https://gitlab.com/gitlab-org/gitlab/-/issues/418133

A

Hi everyone, it's Emily, the product designer for plan, project management and today I'm going to be walking through the design proposal for creating and editing work items I'm going to Dive, Right In and start with the create process. So, depending on where you're creating a work item um in some places that you're creating a work item, the type is explicitly defined. For example, if you're on an issue and you're in the tasks, widget and you're, saying create a new task.

A

It's obvious what type of item you're creating, but for other areas like, for example, the issues list. It might not be as clear what type you want to create.

A

um So part of this proposal is when you're clicking the create button in those areas before you get to the create form, you're selecting what work item type you want to create and selecting that type prior to the create form allows us to show the correct attributes. So today, on the um creation form for an issue, you can select between issue and incident, and that does change the attributes. But um it's it can be a little confusing for users because they might be editing.

A

Some attributes and they're, like oh I, want to change the type and then some attributes disappear. It's kind of a weird experience so having the user select the type before they get to the creation flow or the creation page allows us to show the correct attributes based on that chosen type, um so the creation page will pop up in a contextual view. Currently our contextual view is a modal.

A

um There is some research being done right now on modal versus drawer and we may be going in the drawer Direction um right now, I'm using the modal, because that's what we have right now but uh suffice to say this would be the contextual view, whatever that happens to be um so one change that I am proposing here. That's a little different than how we do.

A

uh Creation today is um integrating the description template into the editor, um because choosing a description template directly affects the content within the editor I'm, proposing that we integrate the description, template selector directly into the editor experience um and actually I have a few different um design Explorations for how to do this. You know whether we add it up here, whether we uh add it as a separate line.

A

Etc um so I'll be exploring these a little further um I, just I put this one in the design for now, but this may not be the final. uh The final way to handle this but um The Proposal, is to integrate it in some way.

A

um Another item I wanted to call out is the confidentiality checkbox um so for an existing work item. Confidentiality is toggled via the utility menu um the three dots menu.

A

um Obviously this doesn't work for creation because that menu doesn't exist yet so for creation, we need to have a separate, a separate way for a user to toggle confidentiality, because it could be really important that, in a work item be confidential from the get-go additionally, um something another consideration is uh related work items, so there are a couple places that you can create a related work item today for issues from the three dots menu you can say create a related issue, we're also talking about in the related items, widget being able to create a new related item right from in there.

A

So if you have created a related item from one of those areas, then when you get to the creation uh modal here or you know- creation contextual view the checkbox for relates to the item you created it from would be right there um and then, once the work item has been created, uh we'll show the completed work item in the detail view in the contextual view. So if you want to close it and get back to like right where you started, you can close it or you can see the the detail.

A

View of the work item that you just created.

A

Additionally, something um a consideration for certain workflows is location so for certain workflows it doesn't really make sense to expose location, for example, if I'm creating an issue from the project issue list, it only really makes sense to just create an issue into the project issue list. It would be really weird if I started at the project issue list then selected a different location, then, when I closed it and saw the project issue list. Obviously the issue wouldn't show up um that's a little bit of a weird experience, but there are certain places.

A

For example, The Group Issue list where it might make sense to maybe default to creating the issue in the group, for example, but you could also select a subgroup or a project or something from within here. So this is something I have a couple.

A

Different options for um one option is to have a single location drop down, so you could pick either a group or a project from here for certain types, obviously like for an epic you'd only see groups for a task you'd only see projects, but for something like issues where we're going to assume be offering issues at both the group and the project level. You would be able to see both and you'd be able to select either from one selector. Another option is uh two separate selectors.

A

So, for example, it for an issue, a group would be required, but a project would be optional, so you could say I just wanted in a group or I want it in a project within a group. This might help users find their project a little easier because it would reduce the number of of uh results because we'd be scoping. The projects available in this drop down based on the group selected, um but the flip side of course, is like maybe it's a little less flexible in terms of you know.

A

If I select, the wrong group I might not understand why my project isn't showing up here and then, of course like for epics. You know, we'd only show the groups drop down and for something like tasks which are only available in projects then we'd make the project drop down required. So you'd have to pick both a group and a project within it.

A

So that is an area specifically that I would love y'all's feedback on in the issue. I'll be uploading these to the design tab. So please leave your feedback or thoughts about this particular area.

A

I'm gonna jump over here to the edit view. I see Mark I'm already going for six and a half minutes so I'm going to try to speed up here. um Work items can be edited in either the full page view or the contextual view.

A

Editing only impacts the title and description, and then we have the save changes and cancel button right below those two areas, because those are the areas that are being edited.

A

um One thing that used to be in the edit flow, but I've actually pulled out, is change type. um So for issues when you edit, you see the drop down just switch between issue and incident.

A

um This is a poor experience, because um changing the type changes, the attributes and it doesn't actually apply until you hit save um changing type- is something that really impacts the whole work item and so moving it into this utility actions really communicates that better and then it allows us to change the type change all the attributes at once before you know an editing action takes place. So um when you click change, type you'd be prompted to select what type. This is a really scalable pattern.

A

um Actually I have a prototype of this. I can show real fast.

A

Sorry, loading all right, so if I hit change type, then I'd be prompted to select which type and then, when I selected the type I don't have this prototype. um You know it would refresh the work item with the correct, um with the new type shown and the correct attributes.

A

um And then finally, I want to talk a little bit about move location, um so uh we talked a little bit about location selection within the create flow um within the edit flow. uh Obviously, within edit we're only editing the title and description, so we need a way to change the location so for that I'm proposing a very, very similar thing to um to changing type.

A

So having move issue here in the utility actions, because again, this is something that impacts the entire work item, so move issue, and then from here you could select a new location groups projects. What would be in here would possibly depend on the work item type. um You know for ethics, only groups for uh for tasks only projects for issues- probably both would depend you know and would be scalable to other workout types.

A

um All of the designs are located in the design section of the issue. um You can also jump into figma and give feedback um would love to hear your thoughts thanks. So much.