@dbarratt This task lists two options - the special page or the expanded drawer. Do we know which one is technically easier to do?
Are there any other factors we should consider when choosing between the two?

In T259755#6378571, @Niharika wrote:

@dbarratt This task lists two options - the special page or the expanded drawer. Do we know which one is technically easier to do?
Are there any other factors we should consider when choosing between the two?

I don't think there is a huge difference between the two as far as level of effort. Each has pros and cons. The special page could be useful for transclusion or linking in other contexts, but might be a worse UX in general than having a modal (or some other display). In the engineering meeting, we deferred to @Prtksxna's judgement.

MobileFrontend has an Overlay (modal), but Drawer doesn't seem to support opening an overlay from a drawer. In my testing it doesn't produce an error, but it also doesn't show the overlay. It instead "partially" closes the drawer (the drawer disappears instantly, but the translucent overlay persists).

We could add support for this pattern to MobileFrontend or we could just open a (new special) page.

@Niharika & @Prtksxna Which would you prefer to do?

Summary from a team discussion:

• The special page is complicated by blocks where the reason is difficult to look up (e.g. global blocks, system blocks)
• Opening an overlay from a drawer is complicated, as described in T259755#6395313
• Instead, we can display the reason within the block drawer, but make it expandable since it might take up a lot of space

In theory it should be possible to open a drawer in an overlay provided you append to the drawer to the overlay itself.

Sample code:

 var D = mw.mobileFrontend.require( 'mobile.startup' ).Drawer;
var d = new D({})
d.$el.appendTo( '.overlay' )
d.show()

You'd need to however drop the following code which is probably fine (although may require some updates to existing drawers) - the code that creates drawers should be responsible for hiding itself now:

.overlay-enabled .drawer { display: none !important; }

You can certainly restrict this rule to elements outside overlays.
e.g.

.overlay-enabled  > drawer-container .drawer { display: none !important; }

In T259755#6397470, @Tchanders wrote:

Summary from a team discussion:

• Instead, we can display the reason within the block drawer, but make it expandable since it might take up a lot of space

This actually can work with a bit of modifying the styles to be something like this:

/* Changes the main viewport to be the thing that is fixed positioned.*/
#mw-mf-viewport {
  position: fixed;
  top: 0;
  right: 0;
  left: 0;
}

.drawer-container.view-border-box {
  margin-top: 300px /* This value will need to be calculated in JavaScript. It needs to be: height of viewport - height of block drawer before reason */
}

.drawer {
  position: static; /* Will also need to drop the `position-fixed` class */
}

/* Remove the float (we should probably do this regardless?) */
.block-message-info {
  /* float: left; */
  margin-left: 10%;
  margin-right: 10%;
}

Making this change puts the page in the fixed position, and the drawer in the scrollable (static) position. Then the block drawer could include a message like "See the reason for the block below" (with an upside down triangle?). The user would scroll the drawer upward revealing the block reason. They can scroll all the way to the top to "hide" it.

I didn't look into fixing the animation. I imagine we might have to animate on the margin (does that work?) and change it from something like 100% to the calculated value to get the nice "opening" animation. Also, I imagine we only want to make this change for the block reason drawer and not for all drawers?

I think this is the best solution so far. It provides the best UX, and isn't too much of a development hassle (from what I can tell). There are a few unknowns still, but I think this is worth giving a shot. What do you think @Tchanders?

In T259755#6398096, @Jdlrobson wrote:

In theory it should be possible to open a drawer in an overlay provided you append to the drawer to the overlay itself.

We actually want to do the opposite, open an overlay from within a drawer. Any ideas if that is possible? Or we could add it to the drawer itself and make the drawer (at least in this instance) scrollable. What do you think? Do you see any issues with doing that?

I think this is the best solution so far. It provides the best UX, and isn't too much of a development hassle (from what I can tell). There are a few unknowns still, but I think this is worth giving a shot. What do you think @Tchanders?

Thanks for looking into this. I'd be happy to try the scrolling drawer and/or the overlay, and iterate if we find problems while we're implementing. It sounds like there are also some design unknowns with either option, so I'd be happy to try whatever @Prtksxna is happy with.

In T259755#6401601, @dbarratt wrote:

Making this change puts the page in the fixed position, and the drawer in the scrollable (static) position. Then the block drawer could include a message like "See the reason for the block below" (with an upside down triangle?). The user would scroll the drawer upward revealing the block reason. They can scroll all the way to the top to "hide" it.

• Will we be able to ensure that the block reason isn't visible initially and is only visible on scroll?
• When they scroll all the way to the top, would it only hide the reason or the drawer too?

I didn't look into fixing the animation. I imagine we might have to animate on the margin (does that work?) and change it from something like 100% to the calculated value to get the nice "opening" animation. Also, I imagine we only want to make this change for the block reason drawer and not for all drawers?

I don't think I follow, where would the animation need to change because of this?

Yep, we should make any changes only to this drawer.

@dbarratt, @Prtksxna and I discussed this, and @Prtksxna will come up with some designs for the drawer, where:

• The reason is displayed at the bottom of the drawer, and scrolled out of view to begin with
• The user can scroll to see the reason (and the drawer will expand to the height of the screen if necessary)
• The actions at the bottom of the drawer are fixed so they're always available

Thanks everyone.