Page MenuHomePhabricator

Empty state shown briefly when posting a new topic
Closed, ResolvedPublic

Description

Behavior

  1. Visit a talk page that has not yet been created (e.g. https://en.wikipedia.beta.wmflabs.org/w/index.php?title=Talk:Duke_University&action=edit&redlink=1)
    • Note: it should not matter what namespace this talk page exists in.
  2. Click the Start a discussion button within the new empty state design
  3. Enter some text into the New Discussion Tool's Title and Description fields
  4. Click the Add topic button

Actual

  1. ❗️Notice the empty state you saw in "Step 2." appears briefly before you see the topic you drafted in "Step 3." published successfully to the page: https://youtu.be/cZ2rdE9EB4g

Expected

  1. ✅ Notice the topic you drafted in "Step 3." is published successfully to the page

Done

  • Expected behavior is implemented

Event Timeline

ppelberg updated the task description. (Show Details)
ppelberg added a subscriber: LZaman.

So, the reason for this is that when we post a topic that creates a page, we're refreshing the entire page. (Because there's a lot of things on the page that need to be updated to reflect that it's a real page now, and that's difficult to update.)

However, the precise spot where we're refreshing it is after the widget has been cleaned up, which thus reveals the empty-state briefly. I'll look at what's involved in moving the redirect so it doesn't allow the cleanup...

(Amusingly, the thing that I know would be trivial is allowing the page contents to be replaced with the newly posted section and then doing a refresh.)

Change 710385 had a related patch set uploaded (by DLynch; author: DLynch):

[mediawiki/extensions/DiscussionTools@master] Show a momentary \"loading...\" rather than the empty state after posting

https://gerrit.wikimedia.org/r/710385

This is probably the most-trivial approach: https://youtu.be/aUCPBHUUCfs

The awkward bit is that the teardown does some necessary things -- it cleans up the storage for autosave, most importantly. Could refactor the widget so that this is done elsewhere and separately-callable, of course.

This is probably the most-trivial approach: https://youtu.be/aUCPBHUUCfs

This looks like an improvement to me. Let's go with it for now.

The awkward bit is that the teardown does some necessary things -- it cleans up the storage for autosave, most importantly. Could refactor the widget so that this is done elsewhere and separately-callable, of course.

I see. Let's consider improvements to what you've implemented above in this newly-created ticket: T288320.

(Amusingly, the thing that I know would be trivial is allowing the page contents to be replaced with the newly posted section and then doing a refresh.)

Hmm, can we do this? It'd be a little inefficient, but it would look nicer.

Hmm, can we do this? It'd be a little inefficient, but it would look nicer.

I think the only objection would be that there's a chance the user would start interacting with the new contents and then lose that interaction as the page reloads.

Actually, I noticed one more objection, which is that it makes the "you replied" toast appear, disappear, then appear again. (Because it appears for however long it takes the reload to happen, disappears until the page is loaded enough to show it, then times out naturally.)

I've updated the patch to be the more-expansive "don't teardown, but do clean up the reply widget" variant. There's no flash of empty state, though there's a moment of the widget having emptied itself out.

https://youtu.be/qkUsjm12SG8

I've updated the patch to be the more-expansive "don't teardown, but do clean up the reply widget" variant. There's no flash of empty state, though there's a moment of the widget having emptied itself out.

https://youtu.be/qkUsjm12SG8

@DLynch, of the two approaches you've now shared, this one [i] still seems like the biggest improvement over the experience that's live right now.

Thinking: it's important that people be confident they did the "right thing" to publish what they've drafted. And I think showing an "empty" form, even briefly [ii], could cause people to worry whether the content they wrote was somehow lost and potentially, motivate them to interrupt the publishing process.


Fine, fine, fine, it's now updated to work without even that flicker of the widget changing: https://youtu.be/5r4B_D-VKa8

Fine, fine, fine, it's now updated to work without even that flicker of the widget changing: https://youtu.be/5r4B_D-VKa8

This looks good to me. Nice.

Resulting question: would it be accurate for me to think the time between someone pressing Add topic and said topic being posted to the page will be significantly faster on production? Also: by implementing what you have here, are we taking on the performance hit Bartosz mentioned in T288314#7267159?

Note: I ask the above thinking, "Huh, it looks a bit slow."

Test wiki created on Patch Demo by PPelberg (WMF) using patch(es) linked to this task:

https://patchdemo.wmflabs.org/wikis/2889ede3b7/w/

would it be accurate for me to think the time between someone pressing Add topic and said topic being posted to the page will be significantly faster on production?

You mean compared to what's shown in the video there? That was taken locally in a docker container on my laptop. I'd generally expect production to be a bit quicker, though it's complicated. (Much more powerful servers, but serving more traffic at once, and with more room for your internet connection between you and the server to be slow. 🤷🏻)

Also: by implementing what you have here, are we taking on the performance hit Bartosz mentioned in T288314#7267159?

Not really. Bartosz was talking about the inefficiency of completely rerendering the page and then redirecting. This approach is still aborting before that initial rerender. It is technically slower than just doing the rerender without a redirect... but that'd leave us in a state with the page-chrome not being correct for an actually-created page.

would it be accurate for me to think the time between someone pressing Add topic and said topic being posted to the page will be significantly faster on production?

You mean compared to what's shown in the video there?

Yep

That was taken locally in a docker container on my laptop. I'd generally expect production to be a bit quicker, though it's complicated. (Much more powerful servers, but serving more traffic at once, and with more room for your internet connection between you and the server to be slow. 🤷🏻)

Ah, okay. This context is helpful.

Also: by implementing what you have here, are we taking on the performance hit Bartosz mentioned in T288314#7267159?

Not really. Bartosz was talking about the inefficiency of completely rerendering the page and then redirecting. This approach is still aborting before that initial rerender. It is technically slower than just doing the rerender without a redirect... but that'd leave us in a state with the page-chrome not being correct for an actually-created page.

I see. IMO, the latest iteration looks good.

Change 710385 merged by jenkins-bot:

[mediawiki/extensions/DiscussionTools@master] Don't detach the reply widget when posting to an empty page

https://gerrit.wikimedia.org/r/710385

ppelberg edited projects, added Skipped QA; removed Editing QA.