Using visual assets in issues

added gitlab-ce~2024184 label

added ~~874211 gitlab-ce~~14281 labels

Thoughts:

JIRA has integrated with InVision earlier this year (https://support.invisionapp.com/hc/en-us/articles/213306066-Integrating-InVision-and-JIRA). I think it makes sense for us to build these features natively into GitLab as a higher priority over integrations, because a complete platform is our strategy.
In merge requests, you have a single vertical discussion flow, and a separate diff area with discussions. But those diff discussions also are cross-linked back to the vertical discussion flow. I see that the design in this proposal is analogous. Instead of code diffs, you have image diffs. You comment on those image diffs, and those discussions are cross-linked back to the vertical discussion thread.
I'd need to see more detailed designs of how designers would attach mockups, comment on them, click through them to design repos, etc. to better understand the UX flows here and use cases. The model of a single issue pointing to another design repo seems weird. But I think it's definitely in the right direction, and I probably just need to meditate on it a bit more.
The proposal here captures the use cases of planning with rich content that is dynamic as the conversation evolves in an issue. Ultimately, the rich content becomes part of the spec, along with the text. This is in contrast to another use case, where you are already doing code construction within the context of a merge request, and the rich content there evolves in an image diff, i.e. https://gitlab.com/gitlab-org/gitlab-ee/issues/1768. They are two different use cases. But I wanted to make sure we were thinking and designing holistically as we ultimately want to support both use cases.
The vision of the product area of Discussion is a WIP here: https://gitlab.com/gitlab-com/www-gitlab-com/merge_requests/6046/diffs. This is a very relevant excerpt. So I'm excited we already have some early discussions/designs in this direction.

In addition to software engineers, there are product mangers, interaction and visual designers, projects managers, marketers, content creators, and salespeople.

GitLab is a tool that helps these additional roles collaborate and create digital content that may be an intermediary step in shipping software (e.g. design wireframes or mockups), or that may be part of the final product itself (e.g. published content on a marketing page that sells the software).

GitLab supports source control of rich digital content types used by these additional roles (e.g. images, video, design files, rich document files) elevating them into first-class citizen contributors.

Assets would be links to repo files. Could be a design in a different repo. That way there are revisions and we can track them.

Imo this idea should be explored further in a more detailed and longer design sprint.

As this brings up the question if these should actually be gitlab project repository files we refer to. This, as then we would refer to designs as being the endproduct, instead of a means to get to the final result. This may be the case, but mostly not (think gitlab, where designs are just a step in the process to mvp). Also this may decouple or slow down the process of updating a discussion with new designs... there can be things said for both sides...

What about a sub repository for each issue, so design files are managed per issue, rather than somebody has to create separate repository in order to be able to add assets

Also there needs to be more discussion on the usecase for supporting sketch files.. I don't want to present whole sketch files, i would want to present subsets of the sketch files. Design files in that sense are different than developer/discussion handoff documents. The only usecase I see is design file management for other designers (which is nice, don't get me wrong )

Assets could also be static images which we already store but there would not be revisions for those.

Why couldn't there be revisions for static images?

Clicking the thumbnail opens a modal which shows comments about that revision of the design.

I want to state here, that a modal alone will prob not be enough for large images. We will need a way to pan and zoom in to a design in order to properly inspect it.

Comments exist as regular comments in the issue. So a comment added to an asset also appears in the comments in the discussion below. With a special avatar.

This will imo be similar to a diff code discussion, resolvable sub discussions.

Comments that are added can be added to a specific x and y coordinate of a picture.

This is a requirement/goal we should aim for. Discussion and designs are decoupled at the moment, let's bring them together. This is vital for success.

In any case this idea should be explored further in a design sprint meeting with product managers, ux designers and developers (backend and frontend).

Soon the UX team will have meeting on how we can do better design sprints to speed up exploration on difficult subjects as these kinds of issues.. then I would love to set one up for this :)

@jschatz1 @smcgivern : I'm thinking a very small iteration that would require very little BE work, if at all, is just to have a section in the issue where you would "add assets", and you would simply link to a repo file. Maybe link to a specific file's commit, or maybe it's dynamic, so that the link always points to that file on the master branch of that repo. And so every time you load the issue, it just grabs the latest image and renders it. No commenting or even system notes in this first iteration.

A few things of concern from a design perspective.

Adding assets: I prefer not to have this UI in the existing web form edit mode. We are already moving away from that. I would prefer some type of UI that is similar to related issues, where you are just interacting with controls on the issue, and you add/remove image links, in an AJAX fashion.
Where would the live? Would it live in the description area of the issue? That is already getting really cluttered with related issues and related branches / merge requests, and the like. Do we need to start introducing tabs like merge requests? Are there any ideas we can take from https://gitlab.com/gitlab-org/gitlab-ce/issues/32411?

@victorwu in regards to

I'd need to see more detailed designs of how designers would attach mockups, comment on them, click through them to design repos, etc. to better understand the UX flows here and use cases.

and

Where would the live? Would it live in the description area of the issue? Do we need to start introducing tabs like merge requests? Are there any ideas we can take from https://gitlab.com/gitlab-org/gitlab-ce/issues/32411?

I was already working on some quick sketches of how I envision this might be done. I looked back at https://gitlab.com/gitlab-org/gitlab-ce/issues/32411 and realized that it is very similar to what I was starting to put together. I think @dimitrieh is spot on with that design and it would fit nicely into this paradigm (always 5 steps ahead of us!).

I don't think we should put anything more into the description area. Breaking discussion into it's own tab and adding one for assets would be better. A modal just won't do the job, we need much more real estate. Managing assets from within the assets tab (adding, commenting, etc.) would be more manageable.

@dimitrieh in regards to

Soon the UX team will have meeting on how we can do better design sprints to speed up exploration on difficult subjects as these kinds of issues.. then I would love to set one up for this :)

I really appreciate your enthusiasm but please do not set up a meeting for this. I will handle that when the time comes.

Maybe link to a specific file's commit, or maybe it's dynamic, so that the link always points to that file on the master branch of that repo. And so every time you load the issue, it just grabs the latest image and renders it. No commenting or even system notes in this first iteration.

Both of those are already options, you can link to a commit or branch anyway

Do these files have to be in the same repo?
What do we do if a file does not exist at a revision, or isn't an image? If we only allow you to add pointers to images, what do we do if an image did exist at that path on master, but doesn't any more?
What if you don't have permissions to view the repo? Maybe the repo is disabled, or only visible to project members, or a different project that you don't have access to?

@smcgivern I was thinking they wouldn't have to be on the same repo if we have a way of querying that.

@jschatz1 we do have a way of querying that, but that implies a lot of access checks, like I said above

mentioned in merge request gitlab-com/www-gitlab-com!6345 (merged)

This article speaks to the larger problems we are looking to solve with this issue, thought it may interest you @jschatz1:

http://opensourcedesign.net/open-source/communities/collaboration/tools/design/2017/03/27/osd-needs-better-collaboration-tools.html

@sarrahvesselov I think at least a POC would be good. Let's give it a try.

Still on my radar! Trying to find some time to explore this over the next few weeks.

added gitlab-ce~2278740 label

changed milestone to gitlab-ce%29

added gitlab-ce~127616 label

added gitlab-ce~394693 label

Hello there.

i’m designer at the coko foundation where i work on the UX/UI of the tools we build for the publishing industries - you can have a look there: https://www.gitlab.coko.foundation for the tool we make.

I’ve been struggling with the question of how we can discuss about mockups or even prototype for a while. My small story, which should be the same as a lot of designers: coming from Adobe, jumped to sketch, tried affinity before going open source and linux (which is happening these days, as i use inskcape and try other tools because, what’s not to love in open source, you know? :D ).

Beside the fact that we need new tools to build UX and consistent UI designs in the land of the open source, we also need a better UI/UX design discussion system.

JIRA has integrated with InVision earlier this year (https://support.invisionapp.com/hc/en-us/articles/213306066-Integrating-InVision-and-JIRA). I think it makes sense for us to build these features natively into GitLab as a higher priority over integrations, because a complete platform is our strategy.

This is a good news. For the last couple of years, a lot of tools appeared showing graphic design features and prototyping inside the browser. One of them being figma but it goes along with gravit and vctr. What’s interesting here is how figma or invision bring the discussion about the design outside of the git discussions: all the talking about the design is made inside a design app. This is a interresting position. But it also has a downside: collaborations between dev and designers is spread between tools, and it’s pretty hard to get the whole history of a conversation, as it gets worse with added revisions. Integrating graphic discussion into gitlab would be a major break-through.

I use commenting system inside of design app (sketch notebook plugin for example) or, worse, I use arrows and text on top of the design, which bring noise to the mockup. What i’d love is to be able to upload my mockup, add the comment wherever i need and see the answers to those comments from the members of my team.

So what we need (well, what I need, as i can’t speak for all designer), is a place that let me introduce the conversation ON the design (as a layer on top of it), and where i can keep track of what is said about it and where the team can take a documented decision about it. Sort of a specific environment for commenting the design.

I think that could be used this way:

The designer upload his mockup into a specificly designed view, and add located comments where needed (x and y coordinates) . Each comment is turned into a gitlab issue.
The team (developers, shareholders, co-workers) answer and add new comment (gitlab issues).
Decision is taken inside the tool, or into the issue view, and as if it’s gitlab issues all the way, closing a conversation would close the issue.
The designer updates the canvas with all the comments adressed and, as developers implement the UI, they can come back to the view to ask questions to the team.

This would help the collaboration between designers & developers, and the whole team and I think that could be a good way to do development and design at the same time.

I’m thinking about the location of the repo for the design, as for me it would be part of the app/website/thing built so it would belong to that repo, but, at the same time, it would need its own as the issues raised are connected to the design. I dont have enough gitlab knowledge to answer that discussion —and i think the answer belongs to each team of users–, but i think there could be a way inbetween: design in its own kind of sub-repo or meta-repo, from which you can link files and comments.

Also, i think that it’s important that the previous revisions of the mockup appears in the issues, since comments are related to a specific revision. My team and I choose to go in a direction, based on previous iterations of the design. And we need to compare between previous version, and the up to date one, with the possibility to get back to what it was.

One last (important) thing: we’re still showing png and pdf files to show UI, but the fixed mockup is far from the final UX, right? We need to show animations and interactions: changes on :hover and :focus are the most common examples i can think of, but we can imagine all use cases for each of our svg colored icons for example) We need to be able to upload all those interaction-possible formats (html5 and svg are a good first step.), and not just image mockups.

I know that this is full of holes and gaps, but i’d love to discuss it further with you to see if there is anything interesting in what i put here.

What’s interesting here is how figma or invision bring the discussion about the design outside of the git discussions: all the talking about the design is made inside a design app. This is a interresting position. But it also has a downside: collaborations between dev and designers is spread between tools, and it’s pretty hard to get the whole history of a conversation, as it gets worse with added revisions. Integrating graphic discussion into gitlab would be a major break-through.

I can't say YES to this loud enough. These are our thoughts exactly.

What i’d love is to be able to upload my mockup, add the comment wherever i need and see the answers to those comments from the members of my team.

This is very much what we are moving towards.

I’m thinking about the location of the repo for the design, as for me it would be part of the app/website/thing built so it would belong to that repo, but, at the same time, it would need its own as the issues raised are connected to the design.

Are you sure you aren't a spy? This sounds spookily familiar

I dont have enough gitlab knowledge to answer that discussion —and i think the answer belongs to each team of users–, but i think there could be a way inbetween: design in its own kind of sub-repo or meta-repo, from which you can link files and comments.

This is a possibility. There has been discussion of linking to a design repo with discussions being done on assets there. As we move toward group-level issues, this is doable. However, I still feel as though that keeps walls up between design and dev. Ultimately, I would like to see the assets discussion as part of the poject. Having it's own tab just as the repository does.

Also, i think that it’s important that the previous revisions of the mockup appears in the issues, since comments are related to a specific revision. My team and I choose to go in a direction, based on previous iterations of the design. And we need to compare between previous version, and the up to date one, with the possibility to get back to what it was.

Absolutely. We have a similar issue internally in that we update the description every time a new design is added. This is very problematic as we lose the history and understanding of why certain decisions were made.

We need to be able to upload all those interaction-possible formats (html5 and svg are a good first step.), and not just image mockups.

Agree

I know that this is full of holes and gaps, but i’d love to discuss it further with you to see if there is anything interesting in what i put here.

Lot's of interest. I would love to discuss this further. I will reach out and set up a time to chat.

Most of all, thank you for taking the time and interest to put your thoughts here. It validates for us that there is a need and an interest in this feature

changed milestone to gitlab-ce%44

@sarrahvesselov : If we do this in 9.6, we need a UX design that can add/link assets. We could use a UI similar to related issues. But for sure it should be separate from the "edit" mode of issues, since we don't have an edit mode anymore. And so it should be some inline UI. Thoughts on that?

@jschatz1 : For what would be in scope for 9.6, we would need to pick the simplest thing. I assume linking to an existing file in a repo somewhere in GitLab would be easiest? In any case, we have to resolve the discussion here first. Any thoughts? https://gitlab.com/gitlab-org/gitlab-ce/issues/33161#note_31265020

Definitely we would not be doing comments on a first iteration.

If we do this in 9.6, we need a UX design that can add/link assets. We could use a UI similar to related issues. But for sure it should be separate from the "edit" mode of issues, since we don't have an edit mode anymore. And so it should be some inline UI. Thoughts on that?

One of the end goals here is to reduce the noise on issues, take discussions on design out of the comments and place it in a focused area. If we were to make the smallest possible change, we could add an Assets section similar to related issues. However, this solution will add to the noise and could push the comments section further and further down as images are added (as you noted @victorwu https://gitlab.com/gitlab-org/gitlab-ce/issues/33161#note_31212313)

Ultimately (moonshot here), the idea is to have a separate area of the issue to facilitate and resolve discussions on design. I believe that it should be in a separate tab design as @dimitrieh proposed for MR in this issue https://gitlab.com/gitlab-org/gitlab-ce/issues/32411.

@jschatz1 : What do you think? Is there a huge rush to get this out? I like the idea of experimenting with a tabbed design. We can put plenty of things in tabs (related issues, etc.) But assets could be a great first start for this issue.

changed title from Improving The GitLab Visual Management Experience to Using visual assets in issues

changed the description

marked this issue as related to #3029 (closed)

@jschatz1 @sarrahvesselov @smcgivern : As per our discussion, I updated the description here, and this one needs more design work to identify the features we can use to take the visual assets repo and integrate them per issue.

changed milestone to %Next 2-3 months

added EE Premium label

mentioned in issue #3029 (closed)

changed the description

changed milestone to %Next 3-6 months

Using visual assets in issues

Problem

Design

Original description

Designs

Child items ...

Activity

Admin message

Admin message

Using visual assets in issues

Problem

Design

Original description

Relates to

Activity