Page MenuHomePhabricator

[Spike] Investigate creating a modal or a new Special Page for displaying the block reason on mobile [2HRs]
Closed, ResolvedPublicAug 25 2020

Description

It is often impractical to display the block reason in the MobileFrontEnd block drawer, as discussed in T189717.

Investigate two alternative approaches for showing block reasons to mobile users:

  • Create a new Special Page for displaying the blocked reason. This page could exist at something like Speical:BlockReason/BLOCKID. Link to that page from the block drawer.
  • Send the parsed block reason so that MobileFrontEnd can display it in modal of some sort.

Details

Due Date
Aug 25 2020, 4:00 AM

Event Timeline

dbarratt created this task.Aug 5 2020, 8:55 PM

@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?

@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.

ARamirez_WMF renamed this task from Create a new Special Page for displaying the block reason to Investigate: Create a new Special Page for displaying the block reason [2HRs].Aug 12 2020, 4:33 PM
Niharika renamed this task from Investigate: Create a new Special Page for displaying the block reason [2HRs] to [Spike] Create a new Special Page for displaying the block reason [2HRs].Aug 12 2020, 4:44 PM
Niharika triaged this task as Medium priority.
Niharika added a project: Spike.
Restricted Application changed the subtype of this task from "Task" to "Spike". · View Herald TranscriptAug 12 2020, 4:45 PM
ARamirez_WMF set Due Date to Aug 25 2020, 4:00 AM.Aug 12 2020, 8:52 PM
ARamirez_WMF changed the subtype of this task from "Spike" to "Deadline".
Tchanders renamed this task from [Spike] Create a new Special Page for displaying the block reason [2HRs] to [Spike] Investigate creating a modal or a new Special Page for displaying the block reason on mobile [2HRs].Aug 13 2020, 12:22 PM
Tchanders updated the task description. (Show Details)

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?

Tchanders added a subscriber: Tchanders.EditedAug 19 2020, 5:17 PM

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
Jdlrobson added a comment.EditedAug 19 2020, 7:38 PM

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; }

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 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.

Prtksxna added a comment.EditedAug 24 2020, 3:20 AM

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.

Niharika closed this task as Resolved.Fri, Oct 2, 7:43 PM