Confusing how to get to the read-only site from the wiki site
Categories
(developer.mozilla.org Graveyard :: Design, enhancement, P1)
Tracking
(Not tracked)
People
(Reporter: sheppy, Assigned: espressive, NeedInfo)
References
Details
(Keywords: in-triage, Whiteboard: [point=2])
Attachments
(4 files)
It's inevitable that wiki.developer.mozilla.org links will accidentally be shared out when they're not meant to be, or that users will inadvertently wind up there while trying to research something. But wiki.devmo is meant for writers and other contributors, and we want to encourage readers to use the main site instead, since it's faster and so forth.
Since contributors will need to be logged in anyway in order to do anything, let's change wiki.devmo to always require a login before you use it. If you access a page on the wiki while not logged in, you get a login screen and then are sent on to the page you tried to access once you've logged in.
That login screen then serves a dual purpose: it gets contributors logged in promptly, and it can serve as a way to show readers that they've visited the wrong page, and to offer a quick way to reach what they wanted
We can also help people get to the place they meant to be by including a sentence along the lines of "If you reached the MDN Editor by mistake, click here to read this article instead." (with "click here" a link to the corresponding page on devmo). That URL correction should be easy enough to manage.
Comment 1•6 years ago
|
||
I'm generally in favor of this. I think we should start with a banner though.
I've seen that technique being very successful on staging server instances where you might accidentally share a URL that gets picked up and accidentally gives unsuspecting "victims" bad impressions. "What the heck is a 'lorem ipsum'?!"
A banner is also a great opportunity to present a link to the read-only version of the URL. I.e. <a href="https://developer.mozilla.com/{current_path}">
Then it at least becomes a little bit better and is dead-easy to implement.
Making all various Django views, that used to be unprotected, now protected is going to take some work but it might at least be easy if we start with the most basic wiki-page-document-viewing Django view.
Generally, if I'm given a URL and I click it and I'm confronted by a login prompt I'll most definitely react badly and more or less instantly close it.
A banner could not only present the read-only link but also a link to sign in.
Comment 2•6 years ago
|
||
let's go with a banner
Updated•6 years ago
|
Assignee | ||
Comment 3•6 years ago
|
||
Proposal for the wiki only banner. Let me know your thoughts.
Comment 4•6 years ago
|
||
Feedback...
- What's with the "W" logo? Never seen that logo before.
- I think its bright mustard yellow "stands out too much". It looks like a warning more than an info banner.
- I think it would be worth considering a much shorter banner that just says the second sentence (but slightly bigger font) only.
** Perhaps, if it's worth doing both sentences, rearrange them so the more "practical" line is first in a bigger font. - The copy-to-clipboard feels a bit excessive. The link being there should be enough.
- I think you should have the
https://
in the URL.
Comment 5•6 years ago
|
||
I've changed the summary of the bug. It kinda negates the 0th comment. (Sorry Sheppy)
The idea of password protecting the wiki isn't bad but it's more radical and might take longer to fulfill properly.
Let's make the solution part of this bug to be about a banner idea.
We can revisit the topic of password protecting all of the wiki later.
Comment 6•6 years ago
|
||
Schalk, does the banner appear only on document views? What about when you're in the {current_url}$edit
mode?
What about the home page?
Reporter | ||
Comment 7•6 years ago
•
|
||
My comments:
I'd like to see the banner text explicitly use the term "editable." For my part, at least, since historically "MDN" and "wiki" have been practically synonymous, the text as it stands does not immediately trigger any alarms in my head. The differentiation could take a significant amount of adjustment for long-time contributors like me.
Also, the clipboard icon after the link is weird. What does that signify? [Edit: I see, it's a copy-to-clipboard -- I like that, actually; it will help at least slightly with accidental sharing of the wrong URLs, though it won't eradicate the issue]
Assignee | ||
Comment 8•6 years ago
|
||
Thank you for the feedback everyone, here is a revised idea.
Assignee | ||
Comment 9•6 years ago
|
||
What's with the "W" logo? Never seen that logo before.
that's me messing around and trying to call even more attention to the idea of Wiki. As Sheppy mentioned though, the idea that MDN is a wiki is such a 1 to 1 in his mind that mentioning that you are on the wiki does not set off any alarms.
I have therefore stepped back off from that in the latest concept.
I think its bright mustard yellow "stands out too much". It looks like a warning more than an info banner.
Fair point. I wanted it to really be in your face but perhaps I went too far ;) The new one uses our dark blue as the main background color.
The copy-to-clipboard feels a bit excessive. The link being there should be enough.
This can be a progressive enhancement but, was honestly added to gauge people's response.
I think it would be worth considering a much shorter banner that just says the second sentence (but slightly bigger font) only.
** Perhaps, if it's worth doing both sentences, rearrange them so the more "practical" line is first in a bigger font.
I have slightly updated the copy to emphasize the "editable" portion.
I think you should have the https:// in the URL.
Added.
Assignee | ||
Updated•6 years ago
|
Assignee | ||
Comment 10•6 years ago
|
||
Schalk, does the banner appear only on document views? What about when you're in the {current_url}$edit mode?
What about the home page?
We will have to show the banner with JS, based on some rules such as
- not homepage
- not when $edit is in the URL
Reporter | ||
Comment 11•6 years ago
|
||
I like the improved version.
Comment 13•6 years ago
|
||
(In reply to Schalk Neethling [:espressive] from comment #10)
Schalk, does the banner appear only on document views? What about when you're in the {current_url}$edit mode?
What about the home page?We will have to show the banner with JS, based on some rules such as
- not homepage
- not when $edit is in the URL
Can't this just be added to the document template?
Comment 14•6 years ago
|
||
I'm wondering, if the banner isn't too "obnoxious" that it's best that it's always there.
For example, if you're in the middle of editing a wiki page, it might be nice to be able to easily (new tab) open the read-only reading of that page.
Also, by always being there it's a constant reminder that you're on the wiki site.
Assignee | ||
Comment 15•6 years ago
|
||
(In reply to Kadir Topal [:atopal] from comment #13)
(In reply to Schalk Neethling [:espressive] from comment #10)
Schalk, does the banner appear only on document views? What about when you're in the {current_url}$edit mode?
What about the home page?We will have to show the banner with JS, based on some rules such as
- not homepage
- not when $edit is in the URL
Can't this just be added to the document template?
Yes, except that we cannot merge it now if we only do that. We will need to make sure that it only shows when the URL is wiki.d.m.o or else it will also show on the current production as it uses the same base Jinja template.
Assignee | ||
Comment 16•6 years ago
|
||
(In reply to Peter Bengtsson [:peterbe] from comment #14)
I'm wondering, if the banner isn't too "obnoxious" that it's best that it's always there.
For example, if you're in the middle of editing a wiki page, it might be nice to be able to easily (new tab) open the read-only reading of that page.
Also, by always being there it's a constant reminder that you're on the wiki site.
Also, should we default to opening this in a new tab, or just open in the same tab?
Assignee | ||
Updated•6 years ago
|
Comment 17•6 years ago
|
||
(In reply to Schalk Neethling [:espressive] from comment #15)
(In reply to Kadir Topal [:atopal] from comment #13)
(In reply to Schalk Neethling [:espressive] from comment #10)
Schalk, does the banner appear only on document views? What about when you're in the {current_url}$edit mode?
What about the home page?We will have to show the banner with JS, based on some rules such as
- not homepage
- not when $edit is in the URL
Can't this just be added to the document template?
Yes, except that we cannot merge it now if we only do that. We will need to make sure that it only shows when the URL is wiki.d.m.o or else it will also show on the current production as it uses the same base Jinja template.
Excellent point!
We are going to have a piece of functionality that tells if you're in the wiki but right now that doesn't exist. Rather, what we have now is "Are you NOT on the Beta site".
Ryan has some grander ideas to refactor all of this so that developer.m.o because they default for React. So perhaps his tricks will change all of this :)
You know, you could just do something like this in the jinja code:
<body>
{% if request.get_host().startswith('wiki.') %}
{% include "wiki-banner.html" %}
{% endif %}
That way, it'll work for all of us doing testing with wiki.mdn.localhost:8000
and it'll immediately work when people start using wiki.developer.m.o.
Comment 18•6 years ago
|
||
Comment 19•6 years ago
|
||
Comment 21•6 years ago
|
||
This is in production now. E.g. https://wiki.developer.mozilla.org/en-US/docs/Web
Updated•5 years ago
|
Description
•