Activity in Designs should create System Notes on the Issue

changed milestone to %12.2

added Category:Design Management Deliverable GitLab Premium UX backend devopscreate frontend typefeature + 1 deleted label

marked this issue as related to #11851 (closed)

@jareko This is specific to system notes, but also related to the information we'll pull over in https://gitlab.com/gitlab-org/gitlab-ee/issues/11851

@phikai Sounds good, thanks!

assigned to @jareko

@phikai so this is for uploading/destroying/editing designs. And https://gitlab.com/gitlab-org/gitlab-ee/issues/11851 is for comments/annotations. Is this correct?

@andr3 Correct this is specific to activity type messages. I'd imagine we'd at least cover:

Upload
Destroy
Edit/Changed

@phikai Would activity-type messages also include comment activity?

i.e. John Smith @jsmith commented on mydesign.png

cc @andr3

No, I don't think that would make sense. It'd be more useful to have this: https://gitlab.com/gitlab-org/gitlab-ee/issues/11851 (which I still need to go read your comments on).

changed the description

mentioned in issue #11851 (closed)

changed the description

added Product Vision FY20 label

assigned to @ntepluhina

assigned to @alexkalderimis

mentioned in issue gitlab-org/frontend/release-kickoffs#5 (closed)

mentioned in merge request !14791 (merged)

added workflowin dev label

mentioned in commit gitlab-design@987050bb

mentioned in merge request gitlab-design!120 (merged)

changed the description

added 1 deleted label and removed UX label

Moved to ~"UX ready". Mockup and final spec previews are here.

It seems like we use the word changed for other actions, would that make more sense vs. modified in your mockup?

@jareko - what should the links target? For individual designs it is clear enough, but for things like added [three designs] what should the user see if they click on three designs?

@phikai Now that I'm looking at it, updated actually feels like the right word here. The word changed feels like something is being "exchanged" for another, like when you "change" a milestone from 12.2 to 12.3. @MattPennaThe3rd What do you think the most appropriate word here would be?

@alexkalderimis The links should target the design version associated with whatever was added/deleted/modified. So if the Version 2 is associated with added [three designs], then it should link to Version 2 of the designs. Does that make sense?

@jareko @MattPennaThe3rd updated probably is the correct word. I believe that's what we use when something changes in a diff from a new commit.

@phikai Ok sounds good. I'll go ahead and ~~change~~ update the mockups.

Ah, so 'updated' it is. I will also update my implementation

See the current notes representation:

One thing that immediately jumps out at me is how unhelpful it is. Lots of 'added 1 design', 'updated 1 design'. If there has been lots of activity here, it will quickly becoming uninteresting and users will learn to ignore it.

mentioned in commit gitlab-design@724739ab

changed the description

mentioned in merge request gitlab-design!122 (merged)

mentioned in commit gitlab-design@da1a7528

@phikai: am I correct that the current master has a version selector but it is not functional? I don't see any version route in the router. So for now I will link to the designs tab (which I can do), and then we will have another issue to link to the precise version

Current master should have a version selector, but it's all behind a feature flag due to some bugs.

@sming-gitlab and @.luke should be able to provide details on how that all works, but I was using it in some demos.

Looking at the URI when you select a version, the state is passed as ?version=<version id>. Note that <version id> is the id and not the sha of the version.

Thanks, I managed to work that one out, but I very much appreciate the tip.

I don't think the Vue router likes receiving the query parameter though. I have it being passed in the href, but then it disappears from the URI once clicked. @sming-gitlab, any tips?

I'll also ping @iamphill on this question too because there's a MR https://gitlab.com/gitlab-org/gitlab-ee/merge_requests/14741 he's working on that's to do with the Vue app routing.

It's possible we need to think about how the Vue app should handle routing in general, in order for us to link to parts of the design management page with the correct state (and let people share links amongst themselves).

@iamphill @sming-gitlab @ntepluhina excuse me if I'm stepping into the wrong area! But hopefully the following is useful and possible:

# showing all designs (latest version - i.e., current behaviour)
/designs

# showing all designs at the given version 
# (i.e., behaviour when ?version=<id> is passed currently)
/designs/<version-id>

# showing a single design at a given version 
# (i.e., when user clicks on a design to enlarge it)
/designs/<version-id>/my-screencap.png

That last URI would always link to the enlarged image at a specific version. If we'd also want to provide a different URI when viewing the enlarged image of the latest version that will always reflect the latest version when shared, we'd need a route to it that doesn't contain a version id/sha in it.

At this point, I might have to leave it up to people who know more about Vue routing to decide how that would fit in the above scheme, but as an idea:

# If it's easy/sensible for the router to determine
# what's a version id and what's a filename:
/designs/my-screencap.png

# Or, if we should be explicit, we could have a special token
# to signal the latest version, perhaps:
/designs/HEAD/my-screencap.png

Some sort of fix for the issue that @alexkalderimis is experiencing is obviously more important than any of these extra routes. So I imagine if we did decide to do this extra work it'd be follow up issues separate from a fix for @alexkalderimis.

I'm not sure if we could have /designs/my-screencap.png and /designs/VERSION_ID/my-screencap.png However, doing something like /designs/HEAD/my-screencap.png would be much easier.

We will need a GraphQL entity exposing so that we can get a specific design for a specific version, I don't think the way we currently do it is the best (we just get it based on the data that we already have on the frontend)

@iamphill: is there a way to actually link to a state using the query parameter? When I activate this with a href, it is removed (I assume by Vue).

@alexkalderimis I wonder if that is a bug in master I tried with the changes from https://gitlab.com/gitlab-org/gitlab-ee/merge_requests/14741 and I can link to versions like http://localhost:3001/gitlab-org/gitlab-shell/issues/10/designs?version=53

Yes, it looks like https://gitlab.com/gitlab-org/gitlab-ee/merge_requests/14741 does fix the bug @alexkalderimis has! That MR is currently in review.

@iamphill

We will need a GraphQL entity exposing so that we can get a specific design for a specific version

I see. GraphQL can currently return all the designs back at a version, but not a specific version.

So we may need to allow GraphQL to take a design id argument somewhere.

Either a new design field on IssueType:

project {
  issue(iid: <issue-iid>) {
    design(id: <design-id>, atVersion: <version-id>) {
      image
...

And/or the existing designs field:

project {
  issue(iid: <issue-iid>) {
    designs(ids: [<design-id>], atVersion: <version-id>) {
      edges {
        node {
          image
...

Either way, this isn't something that is needed immediately, is that right? This would only be for when we want to allow the permalinking of a large image version? @iamphill @alexkalderimis

@.luke: correct, right now what I need is permalinking of the set of designs at a given version.

Linking to a specific design (at a specific version) is not needed immediately.

@.luke @alexkalderimis Just to be clear, from a system notes perspective it's probably unlikely we'll need specific design at a specific version.

However, It is very likely that a user would link to a specific design at a specific version inside of an issue or just by sharing a link.

mentioned in merge request !14741 (merged)

https://gitlab.com/gitlab-org/gitlab-ee/issues/12528#note_195523982

@alexkalderimis are you referring to this scenario > select a version from dropdown and once go to a different route the query parameter is gone and it reverts back selecting the latest design?

Yes, I did that intentionally. I was thinking when someone navigate away from the page, it should be cleared. But now that I'm thinking about it again, maybe that's not the right way to do it. Now that I'm reviewing how our MR diffs work, the version always stay puts, so the design version dropdown should operate the same

Should I create another ticket to change the implementation?

@sming-gitlab My scenario is related to the system notes (the little automatic notes you see on the issues page). When we add a design, we will be adding one that says, for examples "Joe Bloggs added [5 designs]", where [five designs] links to the version at which Joe performed this action.

So for this, we need stable links we can load which take the user to the view of the set of designs at a given version.

I think you are right to be concerned about showing the user stale information though! Perhaps whenever we are not showing the current version, we should add a warning/informational box that tells them this, e.g.:

You are not viewing the current version of these designs.

To see the current version, click [here](#/designs)

Thoughts?

@alexkalderimis I mis-read the question, I was thinking of the incorrect ticket reference Thanks for clarifying! I like that idea you mentioned. But I'm going to leave that for the designer

mentioned in issue create-stage#28 (closed)

Since there doesn't seem to be any FE work here, I'll be unassigning @ntepluhina but please, if anything comes up re: FE, feel free to ping me @alexkalderimis. Thanks!