Hi everyone,
In the "CSS fu" thread, we outlined a few problems with the positioning of the lock icon. This is particularly pronounced in Monobook, where the lock covers up the "[dismiss]" link on the notification for many of us (maybe everyone): http://flaggedrevs.labs.wikimedia.org/wiki/Backmasking?useskin=monobook
Aryeh chimed in:
On Sun, May 30, 2010 at 8:45 AM, Aryeh Gregor <Simetrical+wikilist@gmail.comSimetrical%2Bwikilist@gmail.com
wrote:
Try just putting [the pending changes lock icon] div right before the <h1 id="firstHeading"> or equivalent, and float: right it. You can put some margins or padding on the top and/or right to adjust it a bit if you like. Something like that should work. This will be much more reliable than trying to absolutely position it, because different skins will use different heights, and the heights won't be consistent at all in the face of things like site notices.
Everyone who has looked at it agrees we'd like to do it that way. The tricky part is that the other icons aren't being done that way, and the hooks aren't there (currently) to inject the HTML in the best spot.
So, here's the plan we'd like to pursue: 1. Short term: Adam is working out a CSS hack that puts the icon somewhere marginally sensible. 2. Longer term: we'd like to have a standard area in the skin for things like this lock, the "featured article" star, and so on. This is more complicated than it would seem on the surface, because some of those icons get placed there via template while others are placed there by something in the PHP.
We're heads down on the launch, but if there's any enterprising developers who would like to take on the challenge of solving this right, we'd love to help you do it. It may turn out that the CSS hack is more work than doing it right, so we're putting this out there in hopes that someone will be the hero and fix it right before we figure out how to do it the ugly way.
I filed this in Bugzilla so that we have a place to keep track of the feature request: https://bugzilla.wikimedia.org/show_bug.cgi?id=23796
Rob
On Fri, Jun 4, 2010 at 3:33 PM, Rob Lanphier robla@wikimedia.org wrote:
- Longer term: we'd like to have a standard area in the skin for things
like this lock, the "featured article" star, and so on. This is more complicated than it would seem on the surface, because some of those icons get placed there via template while others are placed there by something in the PHP.
This isn't necessarily hard. If there's a specific area in the HTML we can inject them, we could easily add a {{#icon}} parser function or similar that could affect these sorts of icons (and kill the need for CSS hacks to do these)
-Chad
On Fri, Jun 4, 2010 at 3:39 PM, Chad innocentkiller@gmail.com wrote:
This isn't necessarily hard. If there's a specific area in the HTML we can inject them, we could easily add a {{#icon}} parser function or similar that could affect these sorts of icons (and kill the need for CSS hacks to do these)
That sounds perfectly sensible. Probably easier than trying to get the CSS to work right, too.
Aryeh Gregor wrote:
On Fri, Jun 4, 2010 at 3:39 PM, Chad innocentkiller@gmail.com wrote:
This isn't necessarily hard. If there's a specific area in the HTML we can inject them, we could easily add a {{#icon}} parser function or similar that could affect these sorts of icons (and kill the need for CSS hacks to do these)
That sounds perfectly sensible. Probably easier than trying to get the CSS to work right, too.
+1
On Fri, Jun 4, 2010 at 6:14 PM, Platonides Platonides@gmail.com wrote:
Aryeh Gregor wrote:
On Fri, Jun 4, 2010 at 3:39 PM, Chad innocentkiller@gmail.com wrote:
This isn't necessarily hard. If there's a specific area in the HTML we can inject them, we could easily add a {{#icon}} parser function or similar that could affect these sorts of icons (and kill the need for CSS hacks to do these)
That sounds perfectly sensible. Probably easier than trying to get the CSS to work right, too.
+1
Updated bug with partial implementation.
https://bugzilla.wikimedia.org/show_bug.cgi?id=23796#c3
-Chad
On Fri, Jun 4, 2010 at 12:33 PM, Rob Lanphier robla@wikimedia.org wrote:
I filed this in Bugzilla so that we have a place to keep track of the feature request: https://bugzilla.wikimedia.org/show_bug.cgi?id=23796
Erik pointed me to some earlier thinking on this subject that's been floating around a while. Relevant bits of the thread are below:
Rob
---------- Forwarded message ---------- From: Erik Moeller erik@wikimedia.org Date: 2009/7/28 Subject: Fwd: OOB notices in articles
I saw the design mockups by Parul here:
http://usability.wikimedia.org/w/index.php?title=File:Messages.pdf&page=...
We discussed this issue a bit earlier this year - Brion wrote a blog post about the various kinds of "out of band" article notices here:
http://leuksman.com/log/2009/01/29/e-mail-scams-and-out-of-band-article-noti...
I responded with the suggestion below. This may well be beyond the scope of the current project, but if we're going to start thinking about this problem, it is a direction we may want to explore - basically, a simple syntax to program an intelligent article notification system that is reader-friendly.
---------- Forwarded message ---------- From: Erik Moeller erik@wikimedia.org Date: 2009/2/2 Subject: OOB notices in articles To: Brion Vibber bvibber@wikimedia.org
Thanks for the blog post re: OOB notices. I think it's an issue which we need to address soon, as it has implications for FlaggedRevs and many other quality-related initiatives.
I think we need a mechanism which I will call, for the moment, the Notification Box, or NoBo. The NoBo would accept, via MediaWiki code or templates, information that's relevant about the currently viewed page, and display it to the user in a customized fashion. The user could dismiss all of these notifications, some of them, or none of them.
So, the NoBo could capture the FlaggedRevs state of a given revision, some NPOV warning an editor added, and even additional metrics such as Luca's trust assessment ratings. It could also show editor-relevant information such as the protection status. And of course it could capture special warnings like the spam notice you mentioned. Ideally, the user would just click a simple "[X]" link to collapse a warning or information box, and the software would learn not to show warnings of that type in their expanded form again.
So, in simple ASCII-art, an example of a page that's labeled as "unpatrolled" by FlaggedRevs, and as "NPOV dispute" by an editor:
______________________ | (!) Unreviewed edits [x] | | (!) Neutrality disputed [x] | -------------------------------------
When one of them is collapsed, it could show as: ______________________ | (!) Unpatrolled changes [x] | ---------------____---------------
That is, there would need to be an indicator that further information is available.
When both of them are collapsed, it would simply show as: ___ | (!) | ----
Clicking the icon would show the expanded version.
The icons could have at least three levels: information, yellow warning sign, and red warning sign, used for different kinds of messages. We could set defaults for collapsed/expanded state depending on the seriousness level. When summarized to a single state, the most serious icon would be shown. The text ("Neutrality disputed") could be clickable for further information.
There would need to be a mechanism, possibly through the MediaWiki namespace, to define the various warnings in the different levels. Ideally, to avoid clutter, there would be limits on the text size for the displayed version. Cookies/JavaScript could be used to record reader preferences.
Cleaning ugly templates out of the article body in en.wp would be a nice side-effect. As an editor, I would add a function like {{#notify:npov}}, probably through a template, which would "feed" the NoBo. (This does not address the metadata-in-wikitext issue, though I think that's a separate and solvable problem.)
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Sat, Jun 5, 2010 at 3:33 AM, Rob Lanphier robla@wikimedia.org wrote:
Hi everyone,
In the "CSS fu" thread, we outlined a few problems with the positioning of the lock icon. This is particularly pronounced in Monobook, where the lock covers up the "[dismiss]" link on the notification for many of us (maybe everyone): http://flaggedrevs.labs.wikimedia.org/wiki/Backmasking?useskin=monobook
[...snip...]
So, here's the plan we'd like to pursue:
- Short term: Adam is working out a CSS hack that puts the icon somewhere
marginally sensible. 2. Longer term: we'd like to have a standard area in the skin for things like this lock, the "featured article" star, and so on. This is more complicated than it would seem on the surface, because some of those icons get placed there via template while others are placed there by something in the PHP.
FYI, on zhwiki we're using a script to arrange those icons. See the template [1] and the implemention in site js [2] (search for "topicon").
However I still like this function to be implemented in MediaWiki rather than in user space.
1. http://zh.wikipedia.org/wiki/Template:Topicon 2. http://zh.wikipedia.org/wiki/MediaWiki:Common.js
- -- Jimmy Xu
wikitech-l@lists.wikimedia.org