Edit issue title and description UI
Design
-
Edit button moves to title/description area (we can perhaps looks towards using an icon for this.. similar to comments)moved to #37474 - Title and description edit areas are combined in one editor
- Save and cancel buttons remain the same
- Edit button is no longer visible
- Move project and confidentiality checkbox are removed
- In preview mode, you shouldn't be able to edit the title or change the template
neutral write mode:
write mode:
preview mode (title rendered as h1 tag):
Designs
Relates to
- #3747410.3
Activity
@sarrahvesselov @dimitrieh @smcgivern : By no means a final design. But wanted to get this into an issue as the next iteration. In particular, addresses the concerns here: https://gitlab.com/gitlab-org/gitlab-ce/issues/33873.
I made this EE since templates are in EE.
@victorwu I don't think we generally want a different design completely in CE and EE, do we? Remember that EE-without-a-license has to work the same as CE.
Also, EE only has the 'default' templates as distinct from CE. CE has templates from the repository: https://docs.gitlab.com/ce/user/project/description_templates.html
Thanks @smcgivern . Yep, wasn't suggesting the UI should be different. I thought templates was EE-only, so I put this in EE. That was a mistake.
I moved this to CE now since templates exist in both CE+EE, and in this design, the dropdown should only exist if a template has been configured.
So besides moving the buttons around (Save/Cancel), one of the bigger changes here is that the title field should be part of preview mode. So that if I wanted to put in an emoji, it would be rendered correctly. I think that makes for a more consistent experience that blends title+description more closely together.
@dimitrieh : Regarding the buttons, one big change is that Edit, Save, and Cancel are all in one general location. I think that's an improvement since the user always knows to go the same area in the page to do those related actions.
The downside I see here is that in the rest of GitLab, we always put the edit/save/cancel buttons below the text box. And so this would be inconsistent. I've seen web designs where the same controls (save/cancel/submit, etc.) are duplicated above and below a big UI element, such as a text box. I'm not sure if that's a bad design or not. It feels gross to me.
Would want to get your thoughts. (This one not high priority though yet.)
added frontend label
I am not in favor of duplication of buttons :). But I don't think we need it as well :). As the editor has gotten a small upgrade which limits the max height it can take up.
I feel having these buttons in a consistent place is a good thing actually, even if it's a little different from other places.
We can do quick edits, which improve the experience and solve the problems laid out by this issue and https://gitlab.com/gitlab-org/gitlab-ce/issues/33873 like:
-
editbutton is not needed when in edit mode.. thus can be changed intocancel -
new issuebutton is not needed, as you are already editing an issue... its better to replace it with asave changesbutton and make it primary to booth... this way it has more prominence vs the close button (which actually does make a little sense, as it changes the state of the current issue you are editing).
I do not agree with
Remove the word "Issue" from the header. It's extraneous.though. This as it's a quick descriptional way of indicating the current page... we do this for issues, merge requests, pipelines, commits and jobs from the top of my head.I can see why it may be, but I don't think the navigation UI is fully stable/crystallized enough yet for us to think this is completely extraneous.
I didn't get
The title field of the issue supports GFM. So it should be part of the preview... what does GFM mean?Design
-
Thanks @dimitrieh for the mockup.
- Let's not worry about removing the word "Issue" for this issue, then. That's a small change that we can discuss elsewhere.
- In your mockup, there's the close issue dropdown in between the cancel and save changes buttons. Isn't that weird looking? Also, in this case, the New issue button is no longer showing. I think that's fine in Edit mode. But since this design is about inline UI, I don't think it makes sense to remove the cancel button arbitrarily. For example, when you go into edit mode, you can still interact with the sidebar elements.
- Look at the mockup in the description. I differentiate issue-level controls (new issue, close issue) and title/description-level controls (save and cancel). I have them on separate rows. Wouldn't this be less confusing? In particular, the "Edit" button in the past is about "editing" an issue. Now, the "Edit" button means "Edit the issue title+description only". So that's why I think the UI should reflect that.
- GFM is markdown (https://docs.gitlab.com/ee/user/markdown.html). When you click on Preview currently, GitLab parses and renders the markdown in the Description. My point is that the title field in an issue already is GFM-compatible. (So you can include emoji, for example in an issue title.) So my proposal is to generalize that and the preview mode should include both the title and description. Again, see my mockup in the description. That's what I'm proposing.
-
In your mockup, there's the close issue drop down in between the cancel and save changes buttons. Isn't that weird looking?
I was thinking of it this way. This way you either have to manoeuvre to the beginning of line of the buttons or to the end.. not having to precisely be somewhere in between.
Also, this way the intenseness level of buttons is arranged from left to right: normal, secondary, primary button.
@sarrahvesselov for second opinion here.
Also, in this case, the New issue button is no longer showing. I think that's fine in Edit mode. But since this design is about inline UI, I don't think it makes sense to remove the cancel button arbitrarily. For example, when you go into edit mode, you can still interact with the sidebar elements.
The "cancel" button is not removed, rather it replaced the "edit" button, which has no use in "edit" mode and now sort of works like a toggle.
Look at the mockup in the description. I differentiate issue-level controls (new issue, close issue) and title/description-level controls (save and cancel). I have them on separate rows. Wouldn't this be less confusing? In particular, the "Edit" button in the past is about "editing" an issue. Now, the "Edit" button means "Edit the issue title+description only". So that's why I think the UI should reflect that.
I think that is wasting vertical space, also if you look at the current situation we would already be mixing those with the delete button: image. I don't think this is an issue.
GFM is markdown (https://docs.gitlab.com/ee/user/markdown.html). When you click on Preview currently, GitLab parses and renders the markdown in the Description. My point is that the title field in an issue already is GFM-compatible. (So you can include emoji, for example in an issue title.) So my proposal is to generalize that and the preview mode should include both the title and description. Again, see my mockup in the description. That's what I'm proposing.
Ahh now I see what you mean! I didn't think that was part of this issue, but if that is within scope of this I am happy to oblige!
Writing mode:
Preview mode:
Inline issue edit mode view
I think this same editor can be implemented for (but perhaps not in scope):
- New creation of issues view
- Legacy editing of issues view
- Creation and editing of merge requests view
Thanks @dimitrieh . Regarding the title field, ongoing discussion here of what the title supports: https://gitlab.com/gitlab-org/gitlab-ce/issues/36818.
Regarding the buttons, I think I misspoke. Let me try again.
Feature area 1: Editing title+description
There should be one set of buttons that deal with the title+description right?
- In view mode: There should be a button
Edit. - In edit mode: There should be two buttons,
Cancel, andSave changes.
These buttons should be located next to each other always right? Because they deal with the same functionality, i.e.. the title+description text areas.
Feature area 2: Issue states and abuse
Another feature area is doing:
- Close issue
- Delete issue
- Reporting abuse
I think these are related actions at the issue level. So I think this should all be in one dropdown.
Feature area 3: New issue
Finally, the last feature is New issue. This deserves it's own button.
If you look at my mockup, that's how I structured these three feature areas. Do you agree that that is the correct way to structure it? (I'm fine if the buttons are all in one line. But I maintain it looks weird if you interweave the buttons with each other that belong to different feature areas.)
- In view mode: There should be a button
-
@victorwu I can see your reasoning :) this would get the edit button out of the titlebar:
we could then still place the cancel and save buttons at the bottom:
Both solutions could work actually. One would save some more vertical space though.
wdyt?
@dimitrieh : Why can't we put the save and cancel buttons at the top right? I'd rather they be near the top. This way, when you click edit to go into edit mode, you can quickly cancel away. And usually when you've finished editing the title/description, you click preview, and then save is already nearby.
The Bold/Italic/Quote/Code/List control section is annoying. I just shoved it as shown below. This way you save an extra row.
Also, this way the intenseness level of buttons is arranged from left to right: normal, secondary, primary button.
This goes against our current pattern of having the negative action on the right and the positive action on the left. We should be consistent with our button placement. I prefer it the way you have proposed, with the positive action on the right, negative on the left but I do not believe we should be changing this arbitrarily. It is inconsistent.
In regards to @victorwu mock here https://gitlab.com/gitlab-org/gitlab-ce/issues/36069#note_38453104 - I think this layout makes sense @dimitrieh. Please just take into account my point above.
Edited by Sarrah Vesselov-
Got 3 proposal, 1 following the structure from https://gitlab.com/gitlab-org/gitlab-ce/issues/36069#note_38453104 which can work imo. But just in case I would like to show the option with the save button incoorporated at the bottom of the editor (but inside it this time).
Please state your preference.. and let's conclude this issue
1
2
3
Edited by Dimitrie Hoekstra -
Design discussion is continued at https://gitlab.com/gitlab-org/gitlab-ce/issues/36069#note_39283867
assigned to @dimitrieh
mentioned in issue #33873 (closed)
mentioned in commit gitlab-design@77d93797
mentioned in commit gitlab-design@b40b6913
@dimitrieh, can you please address the concerns I raised here https://gitlab.com/gitlab-org/gitlab-ce/issues/36069#note_38465279 regarding switching the placement of the cancel and save buttons. My main concern here is that we not introduce inconsistencies in our UI by arbitrarily switching button placement here.
In terms of moving the buttons to the top, I do not believe we should do so. When I am creating an issue, no matter how short the description, the buttons will be closer to my cursor in their current placement. Moving them would also make their placement inconsistent with every other editable area in GitLab. If we move them, I would argue that we would need to create additional issues to change them everywhere.
This way, when you click edit to go into edit mode, you can quickly cancel away. And usually, when you've finished editing the title/description, you click preview, and then save is already nearby.
Sorry @victorwu, I don't think this is a strong enough argument to change this.
Thoughts on these points @tauriedavis?
In terms of moving the buttons to the top, I do not believe we should do so. When I am creating an issue, no matter how short the description, the buttons will be closer to my cursor in their current placement. Moving them would also make their placement inconsistent with every other editable area in GitLab. If we move them, I would argue that we would need to create additional issues to change them everywhere.
Agree with this. I would think editing an issue inline can work the same as editing a comment inline. Edit button is on top right, with our normal save bar with save and cancel buttons on the bottom.
For now, we should keep the button order the same as we do everywhere. We have a separate issue to address the order and it is something that should be done all at once. https://gitlab.com/gitlab-org/gitlab-ce/issues/26248
@sarrahvesselov @tauriedavis : Regarding the buttons at the top versus bottom:
The only observation I had was that you typically click preview at the top, before clicking the submit at the bottom. Since it sounds like consistency across GitLab is important here (with what @tauriedavis illustrates in https://gitlab.com/gitlab-org/gitlab-ce/issues/36069#note_38940799, and that this change would be an additional change already on top of the already updated design, agree it should remain on the bottom for this issue.
-
Alright based on feedback this is the solution we are going with. Solution with not trying to be to smart and staying consistent with other UI throughout gitlab:
- Edit button moves to title/description area (we can perhaps looks towards using an icon for this.. similar to comments)
- Title and description edit areas are combined in one editor
- Save and cancel buttons remain the same
- Edit button is no longer visibile
- Move project and confidentiality checkbox are removed
Thanks @dimitrieh. Looks good.
@dimitrieh : Can you please explain/design how preview mode looks? I think preview mode should include the title right? How would that look? In preview mode, you shouldn't be able to edit the title?
@dimitrieh : After discussion with @jschatz1 , we want to just move the Edit button for 10.1, and then we can do the consolidated preview at a later time. So this one here is 10.1: https://gitlab.com/gitlab-org/gitlab-ce/issues/37474
changed milestone to %10.2
mentioned in issue #37474
-
Looks pretty good! One thing that bothers me is all the boxes within the edit mode. There are so many borders its kind of hard to look at. I realize the difference with this design and the comment design is that the title is included in the preview mode so there needs to be something that separates them. I wonder if there is a different way of doing it that still follows our pattern for inputs (no ideas from me currently).
Alternatively, is it really necessary to show the title in the preview? I think we are doing that because of emojis? Anything else? I'm not sure thats worth it. Is any markdown supported in the title? I don't think there is so Im not sure its necessary to include it in the preview. Correct me if Im wrong
mentioned in commit gitlab-design@41f0c062
-
I wonder if there is a different way of doing it that still follows our pattern for inputs (no ideas from me currently).
I tried to keep it pretty clean, as we need the separation and this encapsulates nicely. I think the current design is a clear improvement, but up for inputs here though
I think we are doing that because of emojis? Anything else? I'm not sure thats worth it
Emoji and refs to other objects like issues and mr's. This gives the user the confidence, that these things are actually working while editing it.
How will the issue look when there is a long issuable title that runs into the edit button?
@tauriedavis I think we can make the box containing the title never overlap with the button, additionally I was perhaps thinking of changing the button to be an icon, but perhaps that is a too subtly change for now.
Is it really necessary to drop that button down to its own line?
The idea there was to separate Issue level edit buttons (close/delete/new issue) from the "title/description" level edit button(s). And make it more in line with the comment editing experience.
A mockup of that would be
@tauriedavis wdyt? Let's move this discussion to https://gitlab.com/gitlab-org/gitlab-ce/issues/37474
-
Emoji and refs to other objects like issues and mr's. This gives the user the confidence, that these things are actually working while editing it.
Curious how common of a use case this, or if its even something useful that we should promote.
I tried to keep it pretty clean, as we need the separation and this encapsulates nicely. I think the current design is a clear improvement, but up for inputs here though
mentioned in issue #37454 (closed)
changed milestone to %10.3
marked this issue as related to #37474
What do you mean @dimitrieh : We can always delete issues? I don't think we've ever removed that ability. (Of course permissions matter.)
-
@victorwu oops! you are totally right, i was looking at an issue I didn't have permission for to delete
changed milestone to %10.4
