Page MenuHomePhabricator

MobileFrontend watchlist should default to a chronological rather than alphabetical listing
Closed, DuplicatePublic

Description

Please fix the MobileFrontend UI for Special:Watchlist that matches the functionality of the desktop UI. This sudden and unexplained redesign of the interface as seen on mobile devices is both jarring and poorly-implemented.

The mobile UI defaults on first load to an alphabetical view, meaning a wasted click and page load every time in order to get away from that. Then, for some reason, it shows multiple (just how many is unclear) edits to individual pages, instead of the most recent edit to each page. Maybe some people want that, fine; but please make it opt-in. I expect the form of the tool to have changed appropriately for the device, not the function - this completely breaks my expectations from 12 years of using a stable and predictable tool UI.


Version: unspecified
Severity: normal

Details

Reference
bz67526

Event Timeline

bzimport raised the priority of this task from to Low.Nov 22 2014, 3:34 AM
bzimport set Reference to bz67526.
bzimport added a subscriber: Unknown Object (MLST).
Scott created this task.Jul 4 2014, 9:35 AM
Scott added a comment.Jul 4 2014, 9:36 AM

s/that matches/to match/; # I wish Bugzilla had a preview comment button.

[On a meta level: Subjective and judging terms like "established expectations" and "poorly-implemented" are rather unhelpful in bug reports. Keeping it to the actual problem you are facing vs. your expectations is more effective.]

Scott added a comment.Jul 4 2014, 11:38 AM

I think it's fair to say that an application which has essentially seen no change to its core functionality and interface for over a decade can be said to have established expectations among its users. Regarding the other point, it's a surprising oversight that the growing sector of mobile device users, which I understand to be a key segment in the eyes of the WMF, are dumped into the wrong view when loading the tool. It's a perfect example of violating the principle of least astonishment - care needs to be taken to ensure a continuity of user experience across devices and platforms, which hasn't happened in this case. That's what I mean by poorly-implemented, and I'm surprised that I need to explain that. Thanks.

I don't know, Violation of expectations established by the desktop interface seems pretty objective to me (The extent expectations are violated is subjective, but there is a subjective aspect to how serious a bug is for all bugs). In a more formal form, Scott's complaint is

Underlying assumption:
*The purpose of a mobile site is to allow users used to the desktop site to be able to use the Wikipedia they know and love from a mobile device.
*Ensuring consistency and meeting common user expectations is a key part of good usability

Expected behaviour:
*Design/UI paradigms are consistent between the mobile site and the desktop site. Otherwise a user used to the desktop site will have trouble with the mobile site.

Actual behaviour:
*The watchlist UI in the mobile site default opens to an alphabetical list of articles [In MF's defense, I believe which one it opens to first is remembered]. This is a bookmarked-article-for-later-viewing paradigm. The watchlist in the desktop site gives a list of articles recently changed. The use case here is articles-I-care-about-deep-in-my-heart that I want to know when somebody changes. These two usecases mismatch, so its confusing to the user who expects the underlying purposes of various features to stay the same between desktop and mobile.
*Arguably one use case is more suited to an editor, the other to a reader. How serious this mismatch of expectations is, in light of the other option being available after a click, is probably open to debate.

Re: "Show only most recent change", I filed that as bug 56816, but it was duped to its tracking bug...

bingle-admin wrote:

Prioritization and scheduling of this bug is tracked on Trello card https://trello.com/c/gpDIK9VA

Scott added a comment.Jul 7 2014, 6:16 PM

That was super-cogent, Brian, thank you. I'll bear it in mind as a standard to aim for when filing future reports.

Kunal, that strikes me as having been a mistake. My initial bug could also reasonably be split out into the two constituent issues depending on how granular people like to be, but I do believe that keeping UI paradigms consistent across platforms is a singular goal in itself.

What you describe is expected behavior for power users of Wikipedia who have been editing for a number of years; that's not the bulk of the user base we're seeing on mobile web. See the breakdown of mobile active editors (aka, users who are making 5+ edits per month on mobile): https://commons.wikimedia.org/wiki/File:Monthly_active_editors.by_group.en_mobile.svg -- and compare with desktop, where the % of returning users (aka, those power users who've been editing for years) is much higher than new active editors: https://commons.wikimedia.org/wiki/File:Monthly_active_editors.by_group.enwiki.svg

Consistency is a good value to strive for, but it has to be applied sanely, with an eye toward the specific user we're building for on each platform.

^ that's specifically RE this: "Expected behaviour:
*Design/UI paradigms are consistent between the mobile site and the desktop site. Otherwise a user used to the desktop site will have trouble with the mobile site."

Your underlying assumption here is that most users of the mobile web will have already used desktop functionality, grown accustomed to it, and will want to see the same functionality on mobile; the data we have on mobile users does not support that. If the demographics shift and we see the majority of desktop power users migrate to mobile, changing the watchlist UI will certainly be something we consider. Until that happens, we're going to keep the behavior as is.

Scott added a comment.Jul 9 2014, 7:24 PM

(In reply to Maryana Pinchuk from comment #8)

What you describe is expected behavior for power users of Wikipedia who have
been editing for a number of years; that's not the bulk of the user base
we're seeing on mobile web.

You know why that is? Because the mobile experience is just not good enough for us to use. Perfect circular logic. We don't want to use your bad UX, you use that as justification for not fixing the UX for us.

Until that happens, we're going to keep the behavior as is.

In other words, the people who made and still make what Wikipedia what it is can go to hell. Thanks so much.

Ähm, is there any reason why you redirect the conversation in such way with these formulations and hostility? I think no, so please back to the normal conversation base we expect from each other :)

You know why that is? Because the mobile experience is just not good enough for us to use.

First i want to ask, who "we" is :) Like Maryana said, the decisions aren't made from only a feeling of some guy's sitting in black rooms and laugh about other people's annoyance. The decisions were made on base of analytics data from real Wikipedia users, editors and readers. And some (better. the most) of them use the Watchlist at it is, me too ;) So i'm very interested in to know who "we" is, maybe we overlook some user groups? This can only be clarified in conversation, not with reproach of some allegations.

you use that as justification for not fixing the UX for us.

I think no! But, please consider and think about: If the data say, that many people use the UX like it is, what is, when we change it into a complete other way from today to tomorrow? That will generate a lot of frustration, that's not our score. But that doesn't mean this:

In other words, the people who made and still make what Wikipedia what it is can go to hell. Thanks so much.

Completly no! no no no :) I'm not long here, but one thing i learned (that not only in mobile team, thats's stands for all developers working at MediaWiki and the great extensions available for): All decisions and implementations must be for users, that includes readers and editors as well. If there is a voice of users say, that this and this must be changed or added as a new function or a change of a function, it will be changed or added, trust me :)

So, the right way, before we can do anything, is: find the right way :D And for now, the analytics data, Maryana provided above, are that what we know from the big amount of users. So, if you have other voices, feel free, no: please!! give us this feedback :)

(I'm "only" a volunteer, so it's my own opinion)

Scott added a comment.Jul 9 2014, 8:17 PM

(In reply to Florian from comment #11)

First i want to ask, who "we" is :)

The group Maryana described as "power users" in the comment that I was replying to, who have been using this tool in its base form for years and years and years.

I think no! But, please consider and think about: If the data say, that many
people use the UX like it is, what is, when we change it into a complete
other way from today to tomorrow? That will generate a lot of frustration,
that's not our score.

That's funny, because that's exactly what the mobile UX already did for experienced editors.

(In reply to Maryana Pinchuk from comment #9)

^ that's specifically RE this: "Expected behaviour:
*Design/UI paradigms are consistent between the mobile site and the desktop
site. Otherwise a user used to the desktop site will have trouble with the
mobile site."
Your underlying assumption here is that most users of the mobile web will
have already used desktop functionality, grown accustomed to it, and will
want to see the same functionality on mobile; the data we have on mobile
users does not support that. If the demographics shift and we see the
majority of desktop power users migrate to mobile, changing the watchlist UI
will certainly be something we consider. Until that happens, we're going to
keep the behavior as is.

I can see where you're coming from with this, and yes - its important to keep goals like consistency balanced with other concerns. One thing I wonder though, is if this a self-fulfiling prophecy. Perhaps the reason we don't see established contributors on mobile is because we're designing for the non established contributor base, and as a result the mobile site might not meet the needs/expectations of established contributors thus driving them away. [After writing this, I realize I've basically just rephrased comment 10 more politely]

Scott added a comment.Jul 9 2014, 8:27 PM

I wrote:

that's exactly what the mobile UX already did for experienced editors.

That should have read:

that's exactly what the mobile UX already did for me as an experienced editor.


Brian, maybe I should hire you as a translator. I will freely admit to being taken aback by Maryana's decision to instantly WONTFIX this.

As a daily user of the mobile watchlist and a "established contributor" in desktop, I think the current mobile watchlist is useful and has a good foundation. I also think that it has room for improvement incorporating some features and characteristics of the full-fledged desktop watchlist that both new and established contributors would enjoy.

Just like it happens with wiki pages, we are more likely to obtain tangible improvements by working on specific and incremental improvements together, rather than neglecting the work already done and demanding a total rewrite.

For instance, this part of the original request is sensible:

(In reply to Scott Martin (http://enwp.org/User:Scott) from comment #0)

The mobile UI defaults on first load to an alphabetical view, meaning a
wasted click and page load every time in order to get away from that.

I personally agree, and I wonder why new users would not prefer the chronological view by default, just like we have in the desktop watchlist. No revamp is needed to discuss and eventually agree on this point in a specific bug report.

(In reply to Kunal Mehta (Legoktm) from comment #5)

Re: "Show only most recent change", I filed that as bug 56816, but it was
duped to its tracking bug...

I saw that back in the day and wasn't convinced about the resolution. I have proposed to revert those DUPLICATEs at bug 56817 comment 7.

If you have more specific improvements please file bug reports for them. Thank you.

I've re-opened this bug with a tighter bug summary.

Is there a tracking bug about consistency between mobile and desktop? If so, this bug should be associated with such a tracking bug.

I believe a complementary bug to this bug would be allowing an alphabetical watchlist listing on desktop.

Restricted Application added a project: Readers-Web-Backlog. · View Herald TranscriptApr 8 2015, 7:02 AM
Jhernandez set Security to None.
Restricted Application added a subscriber: Aklapper. · View Herald TranscriptAug 17 2015, 12:15 PM