Last modified: 2014-02-12 23:45:43 UTC

Wikimedia Bugzilla is closed!

Wikimedia migrated from Bugzilla to Phabricator. Bug reports are handled in Wikimedia Phabricator.
This static website is read-only and for historical purposes. It is not possible to log in and except for displaying bug reports and their history, links might be broken. See T55107, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 53107 - Tweak language of "You must be logged in to edit pages on mobile" message in MobileFrontend
Tweak language of "You must be logged in to edit pages on mobile" message in ...
Status: RESOLVED WONTFIX
Product: MobileFrontend
Classification: Unclassified
Feature requests (Other open bugs)
unspecified
All All
: Low enhancement
: ---
Assigned To: Nobody - You can work on this!
:
: 52442 (view as bug list)
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2013-08-20 18:28 UTC by Jon
Modified: 2014-02-12 23:45 UTC (History)
11 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments

Description Jon 2013-08-20 18:28:37 UTC
When a user is not logged in and clicks edit they receive the message "You must be logged in to edit pages on mobile". This is not true in that the desktop site allows you to edit anonymously.

One suggestion from MZ was to weaken the language so it states that this is currently not the case. Another would be to inform them that they can edit on the desktop site.

See bug 52442 for more background on the origin of this bug.
Comment 1 Jon 2013-08-20 18:29:56 UTC
*** Bug 52442 has been marked as a duplicate of this bug. ***
Comment 2 kenan wang 2013-08-23 18:52:48 UTC
Certainly anonymous editing is important to the community and to wikipedia, but as stated in bug 52442 we are making a choice currently to not allow anonymous editing on mobile. 

Adding copy to inform users about this is confusing for the majority of users who want to make a clear decision on whether or not to log in. 

"You must be logged in to edit pages on mobile" is the current copy. That seems to capture the critical information for the user namely that:

1) They currently are not logged in
2) In order to edit on mobile they need to log in

It is stated in copy that is active and positive, giving them clear information to make a decision on whether to log in or not. In this case we are purposefully presenting them with a simple binary decision.

Theoretically they could make the choice to not log in and make their edit on desktop but this is not a choice that we believe many users will make and thus it is not a choice that we want to highlight with important screen and attention real estate.

However, the topic of anonymous editing is an important one that will be revisited as mobile editing becomes more and more mature. In order to get to that point of maturity we need to first nail down the core workflows: in this case taking an editor through account login or account creation and making an edit.
Comment 3 MZMcBride 2013-08-26 21:54:23 UTC
(In reply to comment #2)
> Certainly anonymous editing is important to the community and to wikipedia,
> but as stated in bug 52442 we are making a choice currently to not allow
> anonymous editing on mobile. 

I'm not sure who "we" is or why they feel empowered to make this decision. Disabling anonymous editing is a temporary setting (cf. bug 53069).

> "You must be logged in to edit pages on mobile" is the current copy. That
> seems to capture the critical information for the user namely that:
> 
> 1) They currently are not logged in
> 2) In order to edit on mobile they need to log in

I agree. The current message certainly captures the two points you highlight, but we should probably (also) try to indicate that this message:

(a) isn't true right now (users can still edit anonymously via the desktop interface); and

(b) won't be true in the future (the decision to intentionally disable anonymous editing was made by a small team and it should be reversed, as soon as any blockers are resolved).

> However, the topic of anonymous editing is an important one that will be
> revisited as mobile editing becomes more and more mature. In order to get to
> that point of maturity we need to first nail down the core workflows: in this
> case taking an editor through account login or account creation and making an
> edit.

No disrespect intended, but before you can start effectively designing for Wikimedia, I think there has to be an acknowledgement and acceptance of Wikimedia's [[m:founding principles]]. I agree that this was an intentional design decision. My point is that this design decision is not sustainable.

As a temporary measure, we should consider tweaking the language of this message, given that it's misleading. In the longer term, we need to fix whatever issues are blocking users from being able to edit anonymously (bug 53069).

If you want to talk about "nailing down" workflow, I think we can safely say that being required to register pretty massively disrupts the quick edit workflow. Consider, of course, the "I just want to fix a typo" crowd. And even worse, this is an active regression in functionality: MediaWiki has supported anonymous editing since the dawn of time.

Re-opening this bug for further consideration.
Comment 4 Jon 2013-08-27 21:17:54 UTC
MZ, I'm not sure why you feel "this design decision is not sustainable".

As Kenan points out changing this message in anyway is more complicated then you make out. It's __not__ misleading in that it tells exactly what the current state of affairs is - it even uses the word 'mobile' from which if you really wanted to you might deduce that maybe you could edit on desktop.

Saying that 'editing will be available soon' or anything hinting at that is also misleading and opens up more questions then answers. For instance "when?", "why?", "where?" Should I check back tomorrow, a week, a year?

A big part of writing text for UI is making sure it's easy for users to absorb quickly and easily. One should identify the important information and express it concisely and display it in as few words as possible. The important message here is you must be logged in to edit. Is this confusing users? I'm yet to see that evidence.

If we enable anonymous editing (the bug you suggest - bug 53069) this problem goes away so I suggest focusing more on that.
Comment 5 Eran Roz 2013-08-27 21:33:02 UTC
If enabling anonymous editing is going to take few months or more than we should first focus on this bug. (high priority, low importance)

A big part of writing UI is making sure...that we don't display users options that they aren't allowed to use. If users aren't allowed to use editing - we shouldn't show it at all for them (as create article in enwiki for anonymous). But if we do, than it doesn't matter that the message isn't short as it is important that it should be informative...
Comment 6 MZMcBride 2013-08-28 01:31:19 UTC
(In reply to comment #4)
> Saying that 'editing will be available soon' or anything hinting at that is
> also misleading and opens up more questions then answers. For instance
> "when?", "why?", "where?" Should I check back tomorrow, a week, a year?

Keeping users in the dark isn't a good strategy. Knowledge is power. If users are asking "when?" and "what's the hold up?", this a wonderful feature, not a bug. Perhaps we should link them to this bug. It isn't unheard of for software to do this, particularly to focus energy on resolving the issue (all bugs are shallow with more eyeballs, or something like that).

> Is this confusing users? I'm yet to see that evidence.

I'm not sure what evidence you might need. At the moment, it's largely anecdotal, but I think myself, Nemo, and Eran Roz (who filed bug 52442) don't think the current language is ideal. And I've done my best to respond to the substance here by focusing on (design) principles of Wikimedia (cf. comment 3).

As Eran notes in comment 5, adjusting the language now is better than simply doing nothing, particularly if there's no timeline yet for re-enabling anonymous editing.

> If we enable anonymous editing (the bug you suggest - bug 53069) this problem
> goes away so I suggest focusing more on that.

Yes, I've been dealing with AFTv5 (somehow it's still alive... don't ask) and the upcoming CodeEditor deployment (which is happening this Thursday, so it takes priority). I'll get to bug 53069 when I have a minute. (Stopping to respond to wontfixes isn't helping me move more quickly. ;-)

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links