Improve Layer Manipulation

[alcurrie]

As an AMP story author, I'd like an improved user experience for manipulating layers

• AC1: Refine the ability to move layers forward and back
  • AC2: Make the selected state for the layer more visible:
    • Expanded block navigation is expanded by default
    • User can select the layer in the Block Navigation
    • When selected the layer name is highlighted in the block navigation
    • In the Story page interface when a layer is selected blue keyline displays around the layer
    • Include the name of the layer as a label on the top right i.e Page > Thirds Layer
    • arrow interface shows overlaying the left side of the selector keyline.

- [x] _AC3:_ Ideally allow the author to move layers up and down by re-using the block reordering controls ~and also by dragging the block layer cards.~ - [x] _AC4:_ Within the Block navigation or in the AMP Story interface when the user selects the block, the arrows are persistent and display while the block is selected (not just on hover) and when the user clicks/taps on the up arrow the block moves forward (towards the top of the stack) and when the user clicks/taps on the down arrow the block moves back (towards the bottom of the stack ie. toward background layer) - [x] _AC5:_ Within the Block navigation or in the AMP Story interface when the user selects a layer or the story page, the up/down arrow icons display the arrows are persistent and display while the layer or story is selected (not just on hover) and when the user clicks/taps on the up arrow the block moves forward (towards the top of the stack) and when the user clicks/taps on the down arrow the block moves back (towards the bottom of the stack ie. toward background layer) - [x] _AC6:_ When the parent element moves all child elements move with it. So if a layer moves forward/back all child elements (block elements) within that layer move as well. Also, if a story page moves forward/back all child elements (layer and their block elements) within that story page move as well. - [x] _AC7:_ Hovering on the up arrow shows a tool tip ~'Bring forward' and hovering on the down arrow shows a tool tip 'Move back'~ - AC Update: per discussion here https://github.com//issues/1564#issuecomment-441026950 we are re-using the Gutenberg arrows, so the tool tips will retain the Gutenberg labelling.

Related to: #1531 #1532 #1541 #1559 #1560 #1562 #1563

[jwold]

This is not blocked by Gutenberg specifically, but we need to validate the complexity to do so.

AC 1: Look into it to see if it's clear how this happens or if we could make it simpler.
AC 2: If we replace block layer cards we wouldn't need this feature, If we end up removing the layer cards, this wouldn't be relevant.

[jwold]

Drag and drop elements may already be suggested in the Gutenberg repo, we should take a look.

[miina]

Note for dev: Development is blocked by UX/design.

[jwold]

So if this were implemented in Gutenberg, it would make navigating nested blocks much easier: WordPress/gutenberg#11408, especially if WordPress/gutenberg#11010 gets implemented.

[jwold]

@miina at the moment, if we go with the block navigator, as proposed here, then the only real change we're proposing is drag and drop capability on the block navigator items.

I could mock this up with an icon showing that they're draggable, or we could just leave them alone and let people discover this.

Welcome feedback on this!

cc @cathibosco and @alcurrie

[miina]

@jwold For me it does make sense that these could be dragged and dropped even without an icon, however, not sure if that's just because I want this to happen or because it's actually intuitive, ha!

[cathibosco]

@jwold Seems to me users will be delighted to discover they can be dragged and dropped through experience and trying it ut😀

[miina]

@cathibosco @jwold Actually there is one more thing from UX perspective -- the drag and drop is a possible change for the block navigator, however, we still have the default up/down arrows which are for changing the order of the layers.

We should probably figure out how to make more sense out of these -- for example maybe we should hide them for some layers. Or perhaps we should move these or somehow make it more clear which layer do the arrows belong to. Maybe if there's a way to make it visible and understandable that they belong to the selected block then these could be useful.

Ideally we'd make use of the up and down arrows since these are the default way. If there is a way. Do you think there is any way how to make use of those? Any thoughts on what we should do with these?

[jwold]

I'm a fan of holding off on drag and drop for now in place of having the up/down layer buttons. That's a more straightforward right now!

1. Would children move with their parents? (I'm hoping so!)
2. Replicating functionality of Gutenberg should be fine for now, we might just need a bit more room, pushing the entire AMP Story over to the right a bit to make room for it. Would it be helpful to mock this up?

[miina]

Thanks for the thoughts!

1. Yes, the children already move with their parents in case of the default up/down moving arrows;
2. Not sure exactly what you mean by that so it would be helpful if you could mock it up.

Just for clarity -- I'm talking about the default Up/Down arrows that already exist in Gutenberg just that they might not be most clearly understandable in case of having nested blocks on top of each other. Also, these arrows appear only when hovering on the selected block so perhaps making them visible all the time and more noticeable would make a difference already. Not sure :) Here is how they look like now -- only when hovering:

Do you think we could make use of these? Thoughts?

[jwold]

2. Yes, this screenshot is exactly what I was talking about. Thank you! My thought was in fact to use the exact same up/down arrows in Gutenberg for the block navigation. Just add a little more margin-left to the block navigator so there's more room for the arrows.

[miina]

Sounds good!

I'm wondering if it would also make sense to add a border to the arrows. For example at this moment when a layer is selected, it has a dotted border (not visible very clearly right now though), however, a hovered layer has blue border (visible on the screenshot above). Do you think that perhaps having the same border system could make the arrows more clear? For example that the selected layer's Up/Down arrows would also have a dotted border (or any other border that would be decided within #1524) and the hovered block's Up/Down arrows would also have the blue border? I'm just wondering if there's a way how to make it more clear which Up/Down arrows belong to which block. As far as I remember it might get confusing with multiple layers / blocks. I'm not sure at all if this would look nice though or make a difference.

Thoughts?

[jwold]

@miina great thoughts! Are you blocked today if it takes a few days to figure this out?

@cathibosco maybe we could discuss this in our workshop today.

[miina]

@jwold Development is unblocked for many other tickets so there is no rush at all.

[alcurrie]

@jwold and @cathibosco - I don't think we have complete resolution on this, in particular we still are not 100% resolved on how to recommend that the 'up/down' for blocks and layers will look/work on the main story page interface but we did, I believe, agree that the 'arrow' navigation would be available within the Block navigation.

@miina and @mehigh - this still in discussion but this is current solution. Could you weigh in here and/or Cathi's working on updated mockups and I'm working on documenting updated AC, so it would be good to review/discuss internally so we can discuss/finalize for discussion Friday.

Within the block navigation this would be the proposed user flow :

Improve Layer Manipulation

1. Within the Block navigation the user selects the block and clicks/taps on the arrow to move a block up or down within a layer

Blocks move up or down within the layer they are in ie. Type new paragraph shows as 'selected' and up /down arrows display next to the selected element in the Block navigation (see question re. whether they should display within the 'story page' interface as well.)

2. Within the Block navigation if the user selects a layer, the layer can move up or down using the arrows within the story page. When the parent element moves all child elements move with it. So if a layer moves up or down all child elements (block elements) within that layer move as well. Also, if a story page moves up or down all child elements (layer and their block elements) within that story page move as well.
3. Within the Block navigation if the user selects a story page, the story page can move up or down using the arrows within the AMP story When the parent element moves all child elements move with it. So if a story page moves up or down all child elements (layers/blocks) move as well.

Some questions/notes:

1. Does the equivalent re-ordering of blocks and layers also have to exist in the story interface, or can 're-ordering' functionality only be available the Block navigation only to the left only? Is this an issue for accessibility?
2. Does the user need to be able to move a story page up or down or is that more difficult/complex? I think that could be possible, but if that's the case that the user can use the block navigation to reorder story pages, then, I think we are recommending that the 'story page' numbering should be removed.
3. Any re-ordering done using either the block navigation and/or the in story arrow interface must update instantly in both places.
4. We had a discussion about the 'visual stacking of the layers in the interface. Based on the existing interface the first layer (usually the background layer is added at the bottom and additional layers are added on top) in that case when a layer is selected any layers above it should not display by default. Based on the new interface recommendation, blocks and layers below the selected block will be 'blurred. Based on that moving a layer up or down will need to not only need to show the change in the block navigation, but also adjust visibility or blurring of layers above and below. This will need to be able to be done 'instantaneously' from a user perspective.

The display change needed is based on the 'existing' rule that layers above the active/selected layer are not shown, and the 'new/proposed' rule that the layers below the selected rule will be blurred.

[miina]

@alcurrie Thank you for the update.

1. Does the equivalent re-ordering of blocks and layers also have to exist in the story interface, or can 're-ordering' functionality only be available the Block navigation only to the left only? Is this an issue for accessibility?

Are you asking if we have to have the default navigation with arrows at all for stories? It would be ideal if we could reuse the existing default Gutenberg features. The arrows are the default way how to move the layers up and down so it would be great if we could reuse these.

On drag and drop: Note that originally the idea was to add the drag and drop to the custom Layer Cards (as written in the AC2) but we are not going to have the Layer cards anymore. For adding drag and drop to the block navigation we would need to create a custom block navigation instead of the default one -- it would again be using a custom navigation instead of reusing the existing features. It would be ideal if we could reuse the arrows for now, considering the time we have, and perhaps we could revisit the idea of replacing the default block navigation with a custom one for adding drag and drop in a future iteration of AMP Stories. Thoughts?

2. Does the user need to be able to move a story page up or down or is that more difficult/complex? I think that could be possible, but if that's the case that the user can use the block navigation to reorder story pages, then, I think we are recommending that the 'story page' numbering should be removed.

It is already possible to move a story page up / down with the default Up/Down Arrows.

cc @cathibosco @jwold

[cathibosco]

Posting as I make a few variations - feedback is welcome always.... :)

[cathibosco]

Ok here are 3 variations for us to review together

[cathibosco]

with 50% opacity and blur

[cathibosco]

Lower story moved...

[jwold]

Howdy! A few additional notes from our call today.

We can't do arrows on block navigator right now, so instead what we could do is make arrows persistent when you select a layer in block navigator. Maybe have the arrows show up and persists, with a blue outline around it.

Only blur items on other layers.

[cathibosco]

Uploading the last set for this round here now: Set of 5 mock ups...

[cathibosco]

CTA layer is not displaying so we can work on the Thirds layer which displays below the CTA layer in the story.

[alcurrie]

@miina @cathibosco I've updated the AC based on the discussion we had on Friday. Cathi, to illustrate to the updated AC, could you please update your mockup (I believe overall-scene-7d.png shown above is the most recent). I realize when documenting the AC updates from Friday's discussion that the mock should probably be updated as well if possible. See requested updates: https://cl.ly/eab00718802c

[alcurrie]

@miina - Here's the updated mockup for layer selected state. https://cl.ly/02a19d7c5026 I've also added mock up to the AC and updated - layer selected in the block navigation to only show highlighting the layer (ie. Thirds Layer) Note: labelling update for the hover on the arrows should match the AC above (Bring forward/Move back) not the mockup.

[miina]

@alcurrie Thanks for the update.

One note on labelling: the arrows we are reusing are the default arrows for moving blocks -- not sure that we can actually easily change these.

However, the Arrow labels (Up and Down) do match the movement in the Block Navigation -- the Arrow Up moves the block Up in the Navigator, and the arrow down moves the block down. I'm wondering if this is actually more clear this way -- to match the behavior in the Block Navigator so that the user will get used to this order of the blocks and block navigation?

cc @cathibosco

[mehigh]

The styling looks like this: http://cloud.urldocs.com/e1a46fd70c3e
It maintains the label looks which were normally added by Gutenberg while hovered.
The label disappears when the user selects an element inside of the layer and stays visible while the direct layer is selected.

[mehigh]

AC4 & AC5: when the user selects the block, the arrows are persistent - not handled

I want to add on the arrows which change the order of the blocks or layers - it's not easy to persist them as they get added to the page only on hover by the Gutenberg core. If the elements were dormant, it would've been fairly easy to show them while the block is selected, but it that was not the case.

[alcurrie]

Confirmed updates to layer manipulation and labelling. See Screen cast: https://cl.ly/1a5cb1890808