Page MenuHomePhabricator

Increase time on screen from two seconds to three
Closed, ResolvedPublic

Description

Author: swalling

Description:
For the initial deployment we wanted to minimize the presence of the notification, to reduce annoyance during the period which it was brand new.

However, editors have correctly pointed out that two seconds is probably too fast to be most helpful,[1][2] and we originally tested the feature at three seconds on screen.

Let's bump the time on screen up from two seconds to three, please. :)

  1. "I like this a lot. However two seconds seems a bit fast; you could easily miss it, especially if you were looking at somewhere else on the screen (where the save button was?) and then looked up." https://en.wikipedia.org/wiki/Wikipedia:VPT#Small_new_feature_coming_on_Thursday
  1. https://www.mediawiki.org/wiki/Talk:Post-edit_feedback#Duration

Version: unspecified
Severity: enhancement

Details

Reference
bz41512

Event Timeline

bzimport raised the priority of this task from to Normal.
bzimport set Reference to bz41512.

mr.heat wrote:

Please fix bug 41231 and bug 41323 first.

If the time is longer it becomes more important to not block mouse events on the "version history" tab, "my talk page" and so on for three seconds.

If the time is longer it becomes more important to be able dismiss the popup easily within the three seconds.

ori added a comment.Jan 22 2013, 8:44 PM

(In reply to comment #1)

Please fix bug 41231 and bug 41323 first.

With both dependencies resolved, this change is now unblocked.

However, PostEdit has been deployed for a while now, so people might have gotten acclimatized to two seconds. I suggest incrementing the delay from 2 to 2.5 seconds and checking to see how people like it before incrementing it any further.

I have a patch in Gerrit making this change: https://gerrit.wikimedia.org/r/45185

Thoughts?

(In reply to comment #2)

(In reply to comment #1)

Please fix bug 41231 and bug 41323 first.

With both dependencies resolved, this change is now unblocked.

I'm adding bug 41240.

However, PostEdit has been deployed for a while now, so people might have
gotten acclimatized to two seconds. I suggest incrementing the delay from 2
to 2.5 seconds and checking to see how people like it before incrementing it
any further.

I'm not convinced by comment 0 that a longer period of time is needed.

Though perhaps a one-size-fits-all approach here doesn't make sense. For a brand-new user, you might want the notice to stay up for five seconds. For a user with 10,000 edits, two seconds (or less...) probably makes sense. We're not operating blind: we know how many edits a user has, how long they've been registered, etc. I think it probably makes sense to use this information to our advantage.

ori added a comment.Jan 22 2013, 10:19 PM

(In reply to comment #3)

Though perhaps a one-size-fits-all approach here doesn't make sense. For a
brand-new user, you might want the notice to stay up for five seconds. For a
user with 10,000 edits, two seconds (or less...) probably makes sense. We're
not operating blind: we know how many edits a user has, how long they've been
registered, etc. I think it probably makes sense to use this information to
our advantage.

We don't know these things in client-side code unless we explicitly pack them into the response (usually using a MakeGlobalVariablesScript handler), which I'd rather not do.

swalling wrote:

The other argument, in addition to anecdotal feedback, is that we A/B tested using three seconds. It was a poor decision on my part to ask for the implementation change like that after testing was over and we moved to make the feature permanent. You can consider the user feedback telling us that the change to two seconds was a stupid one, based on my fear of negative community reaction to the feature.

(In reply to comment #4)

(In reply to comment #3)

Though perhaps a one-size-fits-all approach here doesn't make sense. For a
brand-new user, you might want the notice to stay up for five seconds. For a
user with 10,000 edits, two seconds (or less...) probably makes sense. We're
not operating blind: we know how many edits a user has, how long they've been
registered, etc. I think it probably makes sense to use this information to
our advantage.

We don't know these things in client-side code unless we explicitly pack them
into the response (usually using a MakeGlobalVariablesScript handler), which
I'd rather not do.

In the page source of https://en.wikipedia.org/wiki/Main_Page while logged in, I currently see...

"wgEditCount":"164291"
"wgUserId":212624
{"registration":"20050531222515","editcount":164272,"pastyearseditcount":91337}

We know these things both client-side and server-side.

mr.heat wrote:

(In reply to comment #2)

I suggest incrementing the delay from 2 to 2.5 seconds

I think this is a good idea. The current 2 seconds are indeed very short. I'm afraid the popup goes away so fast, it might be confusing for new editors.

Increasing to 2.5 seconds fixes this problem in my opinion.

Increasing to 3 seconds is not necessary. It would be more annoying for experienced editors but not better for new editors.

swalling wrote:

(In reply to comment #7)

(In reply to comment #2)
> I suggest incrementing the delay from 2 to 2.5 seconds

I think this is a good idea. The current 2 seconds are indeed very short. I'm
afraid the popup goes away so fast, it might be confusing for new editors.

Increasing to 2.5 seconds fixes this problem in my opinion.

Increasing to 3 seconds is not necessary. It would be more annoying for
experienced editors but not better for new editors.

We're going to go ahead with three, since that is the duration we A/B tested with and should have stuck to in the beginning. T

he caveat is that I am going to post to some of the relevant Village Pumps (English, German, others perhaps?) notifying folks of all the changes and soliciting feedback. We shouldn't assume that people who've seen this feature for several months are actually going to notice a 1 second increase in duration, but we should be prepared to roll back if there is a wave of negative reactions.

ori added a comment.Jan 23 2013, 12:32 AM

(In reply to comment #8)

(In reply to comment #7)
> (In reply to comment #2)
> > I suggest incrementing the delay from 2 to 2.5 seconds
>
> I think this is a good idea. The current 2 seconds are indeed very short. I'm
> afraid the popup goes away so fast, it might be confusing for new editors.
>
> Increasing to 2.5 seconds fixes this problem in my opinion.
>
> Increasing to 3 seconds is not necessary. It would be more annoying for
> experienced editors but not better for new editors.

We're going to go ahead with three, since that is the duration we A/B tested
with and should have stuck to in the beginning. T

he caveat is that I am going to post to some of the relevant Village Pumps
(English, German, others perhaps?) notifying folks of all the changes and
soliciting feedback. We shouldn't assume that people who've seen this feature
for several months are actually going to notice a 1 second increase in
duration, but we should be prepared to roll back if there is a wave of
negative
reactions.

I amended the patch and recapitulated Steven's point in my commit message:

I had some misgivings about bumping the value up by a full second, but
Steven Walling noted that our tests used a 3-second duration. Since
that's the case, if we're serious about relying on data rather than
intuition to make decisions, we should go with what we tested. This does
not, of course, entail shutting off our ears if users find the new
duration obnoxious.

Please re-open if 3 seconds is intolerable.