Last modified: 2014-07-30 02:40:32 UTC
Instead of clicking the [Search] button which isn't an obvious call to action on a page that doesn't look or act like search result, changes to the settings and options on Special:Contributions should update in realtime. for freeform input fields like Username or tag, content could update when the field loses focus or after a timeout of ~3 seconds
(In reply to comment #0) > Instead of clicking the [Search] button which isn't an obvious call to action > on a page that doesn't look or act like search result, changes to the > settings > and options on Special:Contributions should update in realtime. > > for freeform input fields like Username or tag, content could update when the > field loses focus or after a timeout of ~3 seconds That's somewhat ambigious - Do you want it to auto-update with ajax, or do you want the form to automatically be submitted when you change any of the controls?
I was envisioning someone more Ajaxy
I disagree; there's nothing more annoying than a page changing its contents while you're poking around some forms. Google does it and it drives me *mad* every damned time.
Normally users come to a user's contributions page from a user's user page, often looking for an overview of recent edits, and that's exactly what it shows by default. The common use case for someone to actually use that form is when they're searching for something in particular, so having a button to 'search' does make sense. And given that if they are searching for something they'll often be changing more than one field, Bartosz is spot on about how annoying it would be if it went and updated every time a part of it was poked, forcing the user to wait while the database is queried for something they don't even want.
@Isarra, The site is pretty fast, most searches i've done have returned results in a second or less. So if its a time concern a search will likely resolve faster than it would take a user to change a setting, and move their cursor to the search button.I'm not sure where the user would be "forced to wait" in this process, it would be easy enough to make sure the form could still be interacted with even if a query was running in the background. @Bartosz, You are probably the first (although i'm sure not the last) person I've heard complain about a site being responsive and removing extra steps, I'm not sure which particular interaction on Google you're referring to, a link might be helpful.
(In reply to comment #5) > @Bartosz, You are probably the first (although i'm sure not the last) person > I've heard complain about a site being responsive and removing extra steps, > I'm > not sure which particular interaction on Google you're referring to, a link > might be helpful. I guess it just depends on what your workflow is. If I'm looking at a user's contributions, I'm probably planning to block them and revert their edits, at which point doing live updates of the page isn't useful since I know they can't edit. Or I'm just using popups to scan the diffs, so real-time updates would get in the way. If I need/want an update, I just hit cmd+R to reload and it's there. Or if I wanted something in real time, I'd just use the IRC feed (which I do do).
(In reply to comment #5) > @Isarra, The site is pretty fast, most searches i've done have returned > results > in a second or less. This is only true if you have a decent internet connection. If you have to use internet that is 2-3KB/s, it can easily take 10-15 seconds for a page to load.
Thanks Kunal, I'll have the Analytics team look into whether we have analytics data about what percentage of users are on such connections. You see other sites that are smart about choosing experiences for users automatically based on system and connection performance so this seems like another easy thing to resolve
(In reply to comment #6) > (In reply to comment #5) > > @Bartosz, You are probably the first (although i'm sure not the last) person > > I've heard complain about a site being responsive and removing extra steps, > > I'm > > not sure which particular interaction on Google you're referring to, a link > > might be helpful. > > I guess it just depends on what your workflow is. I would agree with that, I've certainly seen sites where auto-updating things are super annoying, and others where it works well.
(In reply to comment #5) > @Isarra, The site is pretty fast, most searches i've done have returned > results in a second or less. So if its a time concern a search will likely > > resolve > faster than it would take a user to change a setting, and move their cursor > to > the search button.I'm not sure where the user would be "forced to wait" in > this > process, it would be easy enough to make sure the form could still be > interacted with even if a query was running in the background. Results take longer to load based on how many are loading, too. Many users will have it load 100, 500, or even 5000 entries at a time, and that makes a significant difference. Such a change would also affect third-party mediawiki installations, which may not be running on as fast of servers as the WMF happens to use. As hilarious as it would be to see all of the wikis that carlb hosts effectively stop having a searchable special:contributions at all, for instance, I don't think this is what we want. Point is, extra responsiveness is a nice idea, but it's not necessarily needed or practical here.
I checked with Ori, who feels like slow connections wouldn't have any real effect on this, as any new query could send a command to the server to stop or cancel any previous query.
While this bug is about Special:Contributions, my focus is Special:Search. Does anyone know if there's a tracking bug for the general concept of AJAX-y search results in MediaWiki? I can't find one off-hand.
