swalling wrote:

P.S. Congrats on launching the sign in/register/watchlist features to stable you guys. This is exciting to see!

... the question is this definition correct.

Reading lists have been a requested feature on our mobile apps for some time. Why can't they do both things?

Essentially the watchlist feature as designed for mobile helps you see what's happening on pages you are interested in, as well as remember pages you are interested in. The watchlist on desktop does not have an A-Z list - which essentially is a reading list.

swalling wrote:

(In reply to comment #2)

... the question is this definition correct.

Reading lists have been a requested feature on our mobile apps for some time.
Why can't they do both things?

Essentially the watchlist feature as designed for mobile helps you see what's
happening on pages you are interested in, as well as remember pages you are
interested in. The watchlist on desktop does not have an A-Z list - which
essentially is a reading list.

The answer is that the definition is correct. It's not your job to redefine what watchlists are.

Reading lists are a good idea. But the notion that one feature can serve two different products is prone to cause confusion in users, to say the least.

The reason the desktop watchlist does in fact have a list of everything on the watchlist, is to facilitate editing of your watchlist. Not to serve as a reading list.

massaf wrote:

(In reply to comment #0)

"You are not currently watching any pages
First, there is a full stop missing at the end of
the first sentence.

Agreed. We should add this in.

Second, calling watchlists a bookmarking service is
inaccurate. Watchlists are a list of changes to watched pages, and confusing
the concept with a bookmarking service is a disservice to users. The reason
we have the feature is not to keep a reading list.

While you are correct about the purpose of Watchlists (and the general principle that feature conflation is a bad thing), I disagree about the confusion. I think the confusion would go in the other direction.

Looking at the bigger picture, we use a star icon to denote Watchlist items, as well as adding to the Watchlist. This is a Favorites icon by web and mobile convention. We've always used it, meaning we've always broken an established pattern. I'd argue that it would be confusing to discourage this behavior since it's what people are used to in so many apps, as well as every web browser.

Secondly, the main thing differentiating a Watchlist from a Favorites list is a diff view. "Favorites" are a subset of Watchlists in terms of feature requirements, so it's unlikely this copy would produce any sort of cognitive dissonance among new users because they wouldn't be missing any features.

The main reason to change this copy, as far as I can see, is that experienced users may take issue with it not meshing with the way they use Watchlists. However, can we say with confidence that some experienced users don't also use Watchlists to save a page for later?

swalling wrote:

(In reply to comment #4)

(In reply to comment #0)

"You are not currently watching any pages
First, there is a full stop missing at the end of
the first sentence.

Agreed. We should add this in.

Second, calling watchlists a bookmarking service is
inaccurate. Watchlists are a list of changes to watched pages, and confusing
the concept with a bookmarking service is a disservice to users. The reason
we have the feature is not to keep a reading list.

While you are correct about the purpose of Watchlists (and the general
principle that feature conflation is a bad thing), I disagree about the
confusion. I think the confusion would go in the other direction.

Looking at the bigger picture, we use a star icon to denote Watchlist items,
as
well as adding to the Watchlist. This is a Favorites icon by web and mobile
convention. We've always used it, meaning we've always broken an established
pattern. I'd argue that it would be confusing to discourage this behavior
since
it's what people are used to in so many apps, as well as every web browser.

Secondly, the main thing differentiating a Watchlist from a Favorites list
is a
diff view. "Favorites" are a subset of Watchlists in terms of feature
requirements, so it's unlikely this copy would produce any sort of cognitive
dissonance among new users because they wouldn't be missing any features.

The main reason to change this copy, as far as I can see, is that experienced
users may take issue with it not meshing with the way they use Watchlists.
However, can we say with confidence that some experienced users don't also
use
Watchlists to save a page for later?

Take a step back. Who is a watchlist for? Since it was launched, a watchlist has always been for editors. It is not a reader feature, and has never been designed that way. The point of it is to help editors see changes to the subset of pages they care about, and review those changes.

I have seen previous iterations of real reading lists on mobile, particularly in our native apps. These work well, and obviously they're a feature that users want. But the whole idea of trying to cram two activities -- saving a reading list and watching changes to articles -- is what I'm rejecting. You shouldn't be trying to do that, because you're going to end up with a muddled user experience that works well for neither readers nor editors.

massaf wrote:

Take a step back. Who is a watchlist for? Since it was launched, a watchlist
has always been for editors. It is not a reader feature, and has never been
designed that way. The point of it is to help editors see changes to the
subset of pages they care about, and review those changes.

I know that it's an editor feature and I know how it's intended to be used. What I'm saying is that it doesn't matter to a new user. It has a star (favorites/bookmarks) icon, and it saves pages. That's it's function as far as an onlooker is concerned.

New users won't know and won't care what a feature is *intended* for.

But the whole idea of trying to cram two activities -- saving a reading
list and watching changes to articles -- is what I'm rejecting. You shouldn't
be trying to do that, because you're going to end up with a muddled user
experience that works well for neither readers nor editors.

Consider the alternative, then. Two interfaces for saving a list of pages. How would you present the differences between them in order to illustrate their purpose and intended use on a single glance? Can you think of a way to do that that doesn't introduce greater confusion?

swalling wrote:

(In reply to comment #6)

Take a step back. Who is a watchlist for? Since it was launched, a watchlist
has always been for editors. It is not a reader feature, and has never been
designed that way. The point of it is to help editors see changes to the
subset of pages they care about, and review those changes.

I know that it's an editor feature and I know how it's intended to be used.
What I'm saying is that it doesn't matter to a new user. It has a star
(favorites/bookmarks) icon, and it saves pages. That's it's function as far
as
an onlooker is concerned.

New users won't know and won't care what a feature is *intended* for.

But the whole idea of trying to cram two activities -- saving a reading
list and watching changes to articles -- is what I'm rejecting. You shouldn't
be trying to do that, because you're going to end up with a muddled user
experience that works well for neither readers nor editors.

Consider the alternative, then. Two interfaces for saving a list of pages.
How
would you present the differences between them in order to illustrate their
purpose and intended use on a single glance? Can you think of a way to do
that
that doesn't introduce greater confusion?

Not my problem to figure out. I filed the bug because the description of the watchlist is inaccurate.

Marking as an enhancement since currently not clear what new text should be and if/how we should solve this problem.

mgrover wrote:

Assigned Mingle Ticket https://mingle.corp.wikimedia.org/projects/mobile/cards/721

I fixed the full stop issue:
https://gerrit.wikimedia.org/r/67298

I'm not sure what to do about the rest of the bug. It seems to me the watchlist /can/ be used as reading list and it /can/ and /is/ used to keep track of edits.

Could this be as simple as changing the text:
"Watch a page you have found interesting by clicking the star icon at the top of the screen. This will allow you to bookmark pages of interest as well as see when they have changed."

To
"Watch a page you want to remember by clicking the star icon at the top of the screen. Doing so will provide a shortcut to these pages and any changes that occur to them."

This adds more ambiguity and avoids the use of the word bookmarking. Whether you are an editor or using this feature as a reading list you want to 'remember' these articles.

There's a big difference between the watchlist and a reading list, and it's that it emails you when an article changes. If you just want a list of items to read later, getting those emails would be most annoying. If you haven't read a page, you don't need to get notified when it changes.
Granted, you can disable those email in your preferences, and in big projects such as enwiki, it's not allowed due to the volume of email that would be needed. But those are ab abuse of the feature to do something similar, not a valid use.

Oh, and “We've always used a star” is incorrect. They were introduced in 2009 (r56924) into the vector skin (r51086), which is the only one which uses it. And there is in fact a switch to not use a star ($wgVectorUseIconWatch, introduced in r57030). Other icons such as an eye were also considered http://usability.wikimedia.org/wiki/Opinion_Watch

So IMHO we should resolve this bug explaining what *is* the watchlist: watching changes to a set of pages, and adding a reading list feature if desired.

swalling wrote:

(In reply to comment #10)

I fixed the full stop issue:
https://gerrit.wikimedia.org/r/67298

I'm not sure what to do about the rest of the bug. It seems to me the
watchlist
/can/ be used as reading list and it /can/ and /is/ used to keep track of
edits.

I'd recommend Maryana just make a call as the mobile Web PM, and then go ahead and resolve the bug as fixed either way. I still feel the same as I did before, and agree with what Platonides has added. But no need to let the bug linger and rot, even if it's a partial wontfix. ;)

We'll need to change this screen anyway with the rollout of the new article action bar (currently in beta), which moves the watchlist star from the chrome to the space below the title. I've added a story with updated text to our next iteration: https://mingle.corp.wikimedia.org/projects/mobile/cards/721

Removing design tag from this issue.

The above story is awaiting final code review so I think we can call this matter almost closed.