Skip to content
Snippets Groups Projects
Closed Edit issues without leaving board
  • Edit issues without leaving board

    Closed Epic created by Victor Wu

    image

    Related Issues Being Tracked On Other Epics

    Edited by Gabe Weaver

    Child items
    0

  • View on a roadmap
  • No child items are currently assigned. Use child items to break down work into smaller parts.

    Linked items 0

  • Link items together to show that they're related or that one is blocking others.

    Activity

    • All activity
    • Comments only
    • History only
    • Newest first
    • Oldest first
    • Victor Wu changed title from Updating issues without leaving board to Edit issues without leaving board
    • Victor Wu added boards label
    • Victor Wu
      Author

      @dimitrieh @tauriedavis @cperessini : Wanted to invite you to this discussion since you folks have participated in the past on this topic. Feel free to participate as your time/interest allows. On the Plan side, for boards, @JobV has said we should now focus on cleaning up our existing functionality and get usability/features to a state where it is what users would expect, before getting to fancy with new features. So I think this is one area that meets that criteria. (And you can see the roadmap view here to get a sense of priorities for board improvements.)

      Pulling in @pedroms and @annabeldunstone too as ~Plan designers of course.

      My question is: What should a user be able to do within the issue board? You can already change many issue attributes, and it's rather straightforward (design-wise) to add additional things like confidentiality/lock status.

      There's two things that I think we should be able to do:

      • Updating the title: Which I think is super do-able within the sidebar canvas design-wise.
      • Updating the issue description: I think this is harder. But design-wise, I don't think we need anything radical.

      If we want to support anything further, like adding comments, does that mean we need to support a modal? Or maybe extend the slide-in UI to have a bigger canvas?

      These few comments starting from @tauriedavis 's is a good start for folks to re-read history: https://gitlab.com/gitlab-org/gitlab-ce/issues/23854#note_17496117.

      Edited by Victor Wu
    • Dimitrie Hoekstra

      @victorwu Imo cleaning up the experience is very much related to recuding friction and adhering to established patterns in UX. In other words doing a proper heuristic evaluation would yield a list of things to attend to which can be organised and prioritised. To give an initial few points:

      Cards

      • Inspecting card (issue) content should be fast and within context. A modal would be natural here as it omits a new page load. If need be we can start of with just the title and description and not load in any other data, of course informing the user they can view this content by clicking through to the issue page itself.
      • Editing of most edited fields/values from a planning perspective should be especially fast (think title as you said, also nice for when you are trying to jot down a lot of issues for a plan. However this could include more things like moving issues from project to project. Trello does this very nicely with a special hotkey editing function)
      • Making interaction indications more clear. Currently the grab cursor does not indicate you can actually open up the card (sidebar) in the current view. This would be even more important when we would introduce the modal functionality. Also I think the kanban layout already indicated the probability for being able to drag :upside_down:
      • Cards cannot be easily deselected once selected leaving the sidebar open when not wanted.

      Lists

      • Mass card editing functionality per list (closing/moving all issues in a list)
      • Adding/creating cards should be possible from where the user is most likely positioned (inside the list body)
      • Adding/creating lists should be possible from where the user is most likely want the new lists positioned (in between lists). We might be able to solve this with some good interaction UX
      • Removing lists from a board should not generate a confirmation dropdown as it is not a real deletion event
      • The dropdown for adding lists is not able to remove lists example gif
      • You are not able to adjust list label/milestone names or change them out for another label/milestone/assignee

      Boards

      • The searchbar should be adhering more closely to our documentation and design
      • Switching boards is currently not really accessible
      • Boards are currently not searchable or bulk managable
      • Boards are not real-time, meaning no progress or progression can be monitored live. This also hinders multi person usage
      • Board scope is very unaccesible. It is not possible to immediately see in order to know what you are looking at exactly. Also it is not easily adjustable without requiring a save, in order to compare a slight deviation of the current view.

      Some of these will most probably already have dedicated issues :)

    • Victor Wu
      Author

      Thanks @dimitrieh for the discussion. There’s a lot of good ideas there. If you could take a look at some of the existing epics/issues and put your comments there that would be great. Or create new ones. Here’s a good place to start:

      https://gitlab.com/groups/gitlab-org/-/epics?scope=all&utf8=✓&state=opened&label_name[]=boards

      In particular:

      &336 (closed)

      &382 (closed)

      &293 (closed)

      If you have any comments specific to editing an issue within a board, that would be great. In particular, I think we can edit everything we need (title, description, other attributes) in the sidebar. Do you think we need to edit other things like adding/editing comments?

    • Victor Wu changed the description
    • Victor Wu
      Author

      @pedroms : Let's use this space to detail out the interaction design. I really like your design concept in https://gitlab.com/gitlab-org/gitlab-ce/issues/36744#note_107836131, and I attached the image to the epic description here. Could you design how you would slide in the sidebar and the rest of the issue page? Would it be two separate toggles? And from your design, it looks like you pretty much want the entire issue page, except the breadcrumbs. Is that your concept?

    • Victor Wu
      Author

      @andr3 @smcgivern : Getting sidebar parity between issue pages and boards are good iterations if we don't have a good design yet. But if we agree that this is the design of the future, let's figure out the shortest and most responsible engineering path there.

    • Sean McGivern

      From a backend perspective, I think https://gitlab.com/gitlab-org/gitlab-ce/issues/44984 (which is in 11.6) would be a useful pre-requisite here - it's probably also needed for the frontend.

    • Victor Wu added product discovery [DEPRECATED] label
    • Pedro Moreira da Silva

      @victorwu not sure what are the technical constraints here, so I'm thinking about this as if we had green light for anything. Here's a rough mockup:

      Collapsed Expanded
      Actions like “Add a todo”, toggling notifications, and others are available at the top. The title is at the top, the description is after the attributes. I've removed all horizontal lines to be able to save vertical space and emphasize the difference between attributes and the description. The comment thread is after the description. You can expand to a larger view with the control at the top left of the sidebar. This is essentially the same as viewing the issue page. Here the horizontal lines of the sidebar have also been removed to save space. The width of this expanded panel is enough to display the column/list of the board where the selected issue is.
      image image
      Edited by Pedro Moreira da Silva
    Loading Loading Loading Loading Loading Loading Loading Loading Loading Loading