This also affects users on slow/lossy connections: the space is reserved for the watchstar but it isn't visible.

@bmansurov: I'm not sure if this is an epic. I think this is something that you could do within the course of a sprint (!).

Regarding T141936#2517942, I guess what would make this an epic would be identifying and fixing other features like the watchstar that weren't progressively enhanced that should be.

Previously, one rationale for removal of menuing chrome, including the watchstar, was the relative difficulty of an unauthenticated-to-authenticated workflow that would carry state and make it obvious that a watched page was watched. In tackling this problem, in the ideal world for the <noscript>/grade C/compression proxy user she should have to do no more than this:

1. Tap the watchstar
2. Login
3. Be returned to the page (or the watchlist, although that's less than ideal because it requires an action to get back to the context of the original page) in a fashion such that it's obvious the page is now watched.

If the user has to re-tap the watchstar to get it to work or has to take further effort to understand the action was applied, that's really too much.

Note that it's likely we'll have concentrated efforts on getting UX for proxy browsers or their kin really well polished. It may make sense to bundle this in with that effort, which is presumably more in Q2 FY 2016-2017. Then again, maybe this is a good time to effectively provide the access and use this as a learning exercise for some of the complications (many of which we know) in developing for this sort of UA.

@Nirzar, is there anything else or different you'd suggest in this workflow?

Without the suggestion from @dr0ptp4kt, @jhobs and I estimated this task as a 3. @Nirzar what do you think about Adam's suggestion?

T142863 should probably be considered a blocking task if we decide to refactor the workflow as part of this task.

Working on it.

A few things to consider:

• This was originally removed by @bmansurov in Dec 2014. The motivation was the experience was bad (https://trello.com/c/0kKBcmoD/2-2-hide-login-sign-up-in-hamburger-menu-for-non-js-users).
• Our styling options of the non-JS fallback are limited. We should not introduce new technical debt in Mobilefrontend for this purpose:

https://en.m.wikipedia.org/w/index.php?title=Barack_Obama&action=watch

• Watchstar usage is incredibly low even for logged in usage
• We currently don't allow users who do not run JS to login. This would need to be reconsidered.

• There is anecdotal evidence that editors do not use the watchstar this way (items are added to watchlist automatically on edit).

FWIW I think there are more higher priority things we should spec out designs for than this. I don't see this as tech debt but a product decision that should be documented with rationale.

We should at least fix the UI. Here is how it looks now:

Notice the gap between the language and edit icons.

Definitely. Can you open a separate bug for that? That's a clear regression (we used to hide it)

In T141936#2542698, @Jdlrobson wrote:

Definitely. Can you open a separate bug for that? That's a clear regression (we used to hide it)

Seems already fixed by https://gerrit.wikimedia.org/r/#/c/304297/.

We discussed this in kick off.
We want to remove the need for an intermediate watch page and make the watch button work like a form to provide a consistent experience with JS users.
Task needs to be rewritten before pushing to triaged but future.

Looks like this was removed by you @bmansurov I43c6e849cadc9c0b43721e627a171c095fc64e69 although sadly I cannot see the context to why this happened. Do you recall?

Unfortunately, I don't recall either. My wild guess is that those things were not working correctly (or required two steps to perform and the design was not ready).

@Nirzar what do you think? Decline?

Clicking the watchstar without JS would take a user to this screen:
https://en.m.wikipedia.org/wiki/Barack_Obama?action=watch