Last modified: 2013-01-23 00:32:07 UTC
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 2. https://www.mediawiki.org/wiki/Talk:Post-edit_feedback#Duration
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.
(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.
(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.
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.
(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.
(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.
(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.
