Page MenuHomePhabricator

Add pulsing dot to mentor dashboard link when modern vector is used
Closed, DeclinedPublic

Description

Per T289054#7339013, we want to point attention to the mentor dashboard link using a blue pulsing dot. Unfortunately, the approach used for that in current patch doesn't work for modern vector for two reasons:

  • The dot is mostly hidden by the following menu item
  • Even if the dot wasn't hidden, it would only be visible after the user opens the menu (is that an issue?)

For this reason, the pulsing dot is not included in modern vector in V1 of the mentor dashboard, as it's probably not worth delaying the first release by this issue (out of four pilot wikis, it only affects bnwiki). This task exists to not forget about the issue.

Event Timeline

Restricted Application added a subscriber: Aklapper. · View Herald Transcript
Urbanecm_WMF moved this task from Inbox to Upcoming Work on the Growth-Team board.

This should be worked on as the mentor dashboard moves forward, but it needs design input (how to make the dot fulfil its function when the personal tools menu is not immediately fully visible). Putting to Upcoming Work, but Needs Discussion also applies.

MShilova_WMF raised the priority of this task from Low to Medium.Apr 15 2022, 3:51 PM

This was discussed during 2022-09-06 mentorship meeting:

  • With the structured mentor list deployed, mentors will be directed to the dashboard in the sign up process(F35511110).
  • Assuming a mentor visits the dashboard using the link, the mentor might wonder "where the mentor dashboard is located", especially in new Vector (where it is not immediately visible on the screen). This can be resolved with a guided tour displayed to the mentor.
  • @KStoller-WMF will work on providing copies for the tour.
  • Once structured mentor list is deployed, we would be able to remove the dots, as the "Mentor dashboard exists" message will be included in the mentor sign up process.

Here are is (apparently) the one example of guided tours that is still used to introduce a new/changed feature.

Recent changes improvements

  1. Capture d’écran_2022-09-07_14-56-59.png (717×1 px, 173 KB)
  2. Capture d’écran_2022-09-07_14-57-08.png (667×1 px, 194 KB)

I explored the current flow and existing guided tours and have some suggestions for copy in this Figma file.

However, I wanted to ask a question before updating this task's description and adding final copy:
@Urbanecm_WMF When I have Vector 2022 enabled and I enroll as a mentor using the new structured mentor list process, I end up on an "Enroll as a mentor" confirmation page. At that point, when I expand the user menu, there isn't a Mentor Dashboard option. Is that expected, or a bug?

Screen Shot 2022-09-09 at 10.08.17 AM.png (1×3 px, 319 KB)

@KieranMcCann Will you take a look at the suggested copy in Figma file.
and see if you have any suggestions for improvement? Thank you!

I explored the current flow and existing guided tours and have some suggestions for copy in this Figma file.

Thanks! I added some comments there.

However, I wanted to ask a question before updating this task's description and adding final copy:
@Urbanecm_WMF When I have Vector 2022 enabled and I enroll as a mentor using the new structured mentor list process, I end up on an "Enroll as a mentor" confirmation page. At that point, when I expand the user menu, there isn't a Mentor Dashboard option. Is that expected, or a bug?

Screen Shot 2022-09-09 at 10.08.17 AM.png (1×3 px, 319 KB)

Kind of both :). The current behavior doesn't surprise me (it sometimes happen when something changes in the middle of a request). The issue here is that when MediaWiki starts processing the user request/form submission, the user is still not a mentor. During the processing, two things happens (among many others):

  • MediaWiki determines which links will be shown in the user tools menu.
  • MediaWiki determines that the current user should be added as a mentor, and adds them to the list of mentors.

Depending on the order of those two steps, the link to Mentor dashboard may or may not show in the menu.

This can be easily fixed by redirecting the user to a different page, rather than displaying an error message. Alternatively, we can try to switch the order in which the two steps happen (which likely will be tricky). CC @Tgr in case he knows about a different fix we can potentially think about.

How can the toolbar logic run before the submit handler? That sounds broken.
That said, Post/Redirect/Get is a fairly standard technique after successful submission (that prevents accidental re-submission, for example) and would be a good idea even apart from this issue.

How can the toolbar logic run before the submit handler? That sounds broken.

Not sure why, but that's the only plausible explanation I have for now. This is what happens/should happen (GE-specific logic) during the POST request:

  1. SpecialEnrollAsMentor::execute is called. As one of the very first things, it calls MentorProvider::isMentor. This calls WikiPageConfigLoader::load, which populates WikiPageConfigLoader::$inProcessCache.
  2. Any subsequent calls to MentorProvider don't actually check the wiki-page (until step 3).
  3. SpecialEnrollAsMentor::onSubmit is called. This calls WikiPageConfigWriter::save, which in turns calls WikiPageConfigLoader::invalidate, which destroys WikiPageConfigLoader::$inProcessCache.
  4. First subsequent call to MentorProvider will check the on-wiki page, and see the newly added mentor.

There are also calls to MentorProvider in onSkinTemplateNavigation__Universal and onBeforePageDisplay hooks.

If the onSkinTemplateNavigation__Universal is called after the 3rd step, the link has to be present (unless WikiPageConfigLoader::invalidate() is very badly broken). Since it isn't present, it has to be called at some point before.

For testing purposes, I temporarily replaced SpecialEnrollAsMentor::execute with parent::execute() and disabled onBeforePageDisplay hook. After I did that, I (successfully) reproduced this via mwdebug1001. According to XHGui, MentorProvider::isMentor was called only once, from MentorDashboardDiscoveryHooks::onSkinTemplateNavigation__Universal. This rules out in process cache polution, as there's no way how it can be populated.

That said, Post/Redirect/Get is a fairly standard technique after successful submission (that prevents accidental re-submission, for example) and would be a good idea even apart from this issue.

Re-submission would not be an issue (SpecialEnrollAsMentor early-aborts when the user is already enrolled), but I get why that would be nicer. As I said, it's likely the easiest solution here, but I'm still curious why it behaves the way it does.

We discussed this today, since Vector 2022 is being rolled out as the default skin to more wikis.

I'm suggesting we decline this task because I think we can address the underlying problem more holistically with these two tasks:

T318482 will need design before it's ready for development, but T322452 is ready for development and in the current sprint.