Forum:Introducing Flags: a new way of maintaining article notice boxes

From the RuneScape Wiki, the wiki for all things RuneScape
Jump to: navigation, search
Forums: Yew Grove > Introducing Flags: a new way of maintaining article notice boxes
This page or section is an archive.
Please do not edit the contents of this page.
This thread was archived on 8 September 2015 by Cqm.

Good morning RuneScape Wiki! Kirkburn from the Community team here.

As an excellent, leading community on Wikia, we wanted to take a moment to show off something we’ve been working on recently.

As part of our ongoing work to try and help ensure articles work well across kinds of devices, we’ve been hard at work on a new article feature to update the way ‘content notices’ work, which we’re calling Flags.

What we’re talking about are the kinds of notice templates you see at the top of articles with information like “this is a dangerous minigame” or “this article lacks references”. Essentially, they are metadata for an article - communicating the status of that article, rather than being article content itself.

What does it do?

With Flags, the notice templates that appear at the top of articles are separated out from the article content, and given their own management tool. They still use the exact same templates (and you can continue to update them, just as you do today) - but now users can browse, add and remove them without resorting to fairly specific knowledge of all the varied templates on the site.

Local admins can manage which flags are available across the community via a special page - [[Special:Flags]].

By adding a quick layer of data to these templates, communities will have more control over which notices appear to which people (e.g. a ‘dangerous minigame’ notice would be relevant to all readers, but a ‘references needed’ notice would only be relevant to logged-in contributors). The layer of data will also allow for custom reports via [[Special:Insights]] - for example, an Insight list of all pages that have a stub notice, ordered by pageviews. The content of these templates would no longer clutter Google and on-Wikia search results, and we’ll be able to display abbreviated versions of the notices on mobile phones.

Other potential ideas include mobile users being able to mark pages that need work (e.g. you notice a page is full of typos, and flag it for yourself or others to improve later), or even modifying how the page behaves based on the flags (e.g. hiding spoiler article text from on-Wikia search results). If you have more ideas around this, we’d love to hear them!

What would this mean for RSW? [[File:Wikia-Flags.png|thumb|Flags menu option]] [[File:Wikia-Flags2.png|thumb|Flag selection]]

We have been working on a simple version of the Flags tool, which is just about ready to go, and we’d love to hear if you’d be interested in trying it out on RuneScape Wiki.

After identifying which templates are content notices, we’ll automatically convert usages of them to the new type of code using a bot. (If it needs to be reversed, this is possible.)

Editors can then choose which flags will appear on an article via an option (called ‘Flags’) under the Edit menu or via a new tab in Monobook. Changes to flags appear in RecentChanges as a log item.

[[Special:Flags]] lists all the content notices that have been tagged as flags, with their associated data. We’ve filled it out with what we think could work as an initial setup for RSW. Although this is not actively customizable right now (coming in a future update!), we’re happy to tweak it manually until it is ready.

A __FLAGS__ magic word allows the flag location to be specified, if they aren’t the very top item on a page. Templates that aren’t in the first section of a page will not be touched.

Try before you buy!

You can see the current version of the tool live on right now - for example, check out!

We also have a copy of the RuneScape Wiki set up as a test community, at, which is only accessible by users with appropriate rights (in order to prevent confusion, and avoid it polluting search results). We are happy to give RSW admins rights on that community, so they can test it out - just ping us here if you’re interested!

Note that the tool is under heavy development right now - more abilities and options will be added as and when they are completed. At the time of writing, the main visible effects would just be the change to article wikitext, and that ‘contributor’ tagged flags would not show to anonymous visitors.

What now?

I know that may have been a lot to take in at once - but we hope you’ll be interested in trying out the new feature - and thanks in advance for any and all feedback you give us.

I know the Flags development team here at Wikia are eager to hear what you think about it - your thoughts will be invaluable, and will likely strongly influence future development!

Thanks! Kirkburn <staff /> (talk) 20:22, June 11, 2015 (UTC)

Discussion[edit source]

Comment - Sounds pretty exciting. I actually asked onei about something like this a while ago. I'm sort of curious how exactly it's going to function and whether or not it will be easy to mass update our thousands of pages.

I disagree with "(e.g. a ‘dangerous minigame’ notice would be relevant to all readers, but a ‘references needed’ notice would only be relevant to logged-in contributors)" particularly the latter part. Anons give us plenty of references for material.

I must say though, it's extremely disappointing I'm unable to test this myself. I don't want to just peek at how it looks on another wiki. I kinda need to test the nitty gritty myself and see how it functions. MolMan 20:26, June 11, 2015 (UTC)

Helping bulk updates is definitely an idea we're interested in. Can you think of particular examples of what might useful there? (We certainly have ideas, but don't want to restrict free flow of thoughts by listing them out).
That's a fair point about the notices I picked out - it's great if you do get anons adding references :)
You can test this on Red Dead Wiki right now - as it's a live community, please don't go crazy of course, though. Kirkburn <staff/> (talk) 20:36, June 11, 2015 (UTC)
I mean, if you knew me. You'd know I kind of need to go crazy. If you check my edits, you'll see this is the kind of stuff I do literally the time. I need to make sure I can get crazy with it. MolMan 20:37, June 11, 2015 (UTC)
I literally the time. MolMan 21:10, June 11, 2015 (UTC)
Here's an example of a bulk update, can't remember the scale of that one but it was a few thousand iirc. cqm 20:55, 11 Jun 2015 (UTC) (UTC)
I use URL parameters with DPL to do bulk page moves. e.g.
[{{fullurl:Special:MovePage/Forum:Introducing Flags: a new way of maintaining article notice boxes|wpLeaveRedirect=0&wpNewTitle=Butts}} Move Kirk's forum to Butts!]
I'm not super keen on the popup interface that exists for it. If it were something like its own special page the way MovePage is (so [[Special:Flags/Forum:Introducing Flags: a new way of maintaining article notice boxes]] would edit the flags for this forum) with input that can be manipulated with URLs, I'd probably be pretty satisfied. MolMan 21:03, June 11, 2015 (UTC)
+1 for that. Would it be possible to document how to modify them with a bot too? cqm 21:08, 11 Jun 2015 (UTC) (UTC)
Bot modification isn't part of the current feature-set - but it's something we can look at. Roughly how would you normally approach bulk changes (with a bot)? Do you obtain a list of pages, then do a bulk edit to add/remove wikitext? Kirkburn <staff/> (talk) 15:04, June 12, 2015 (UTC)
That's in essence how any bot on every mediawiki site works :P
Grunny says the support is kind of there already as a by product of Nirvana, so a few docs are all that's needed :) cqm 15:41, 12 Jun 2015 (UTC) (UTC)

Comments - Thank you for informing us first instead of just going ahead and implementing it, as you seem to have done without prior notice (?) on [[w:c:reddead:Forum:Flags - a new way of dealing with content notices|Red Dead Wiki]]. Things:

  • There are notice templates that are not placed at the top with the others (Template:Stub, Template:Sectstub, etc). I assume __FLAGS__ won't work in two places – how do you deal with that?
  • We recently decided on a set of guidelines for the order of the lead section, including sequence of templates. Is it possible to set an order for the templates using their flag group, and maybe edit/add groups ourselves?
  • Something that allows users to sort through templates in the modal would be helpful – maybe this thing from Special:Search, except with groups instead of namespaces?
  • Could you make the modal close when "Esc" is pressed? The "Show changes" modal has this problem too.

--Iiii I I I 05:43, June 12, 2015 (UTC)

Generally, we ignore templates that are not in the first section on a page - so a stub template halfway down a page will not be affected.
Regarding the order - see a note a few comments down (v) :)
Thanks for the dialog feedback - I'll pass it along! Kirkburn <staff/>(talk) 15:04, June 12, 2015 (UTC)

Question - How does this interact with Special:UnusedTemplates? Are the templates still registered as used on the relevant pages or will they start showing up there? cqm 08:04, 12 Jun 2015 (UTC) (UTC)

I don't believe it is hooked up to WhatLinksHere-type functions at the moment - but that's something we can implement if felt important. (It might seem obvious, but we're trying to present code early, so we can make sure not to make too many assumptions about what is and isn't useful). Kirkburn <staff/>(talk) 15:04, June 12, 2015 (UTC)
It either needs to have it's usage 'faked' on pages where it's used or it needs a dedicated flags manager method where you create the flags you want. If you go for the latter, which is my preferred option as I think about it, you also want to be able to find uses of the flag, but it could also allow for simpler management too if you wanted to delete a flag and all it's uses.
I get that this is a proof of concept really, but I always get disappointed when wikia makes something good but barely more than a prototype and then goes no further to improve upon it (*cough* ParserSpeed). cqm 15:41, 12 Jun 2015 (UTC) (UTC)
It's fair to say we've had a bit of trouble with things feeling a little incomplete - we do want to change this. (I'll bring up the status of ParserSpeed with the team). Kirkburn <staff/> (talk) 16:57, June 15, 2015 (UTC)
We've played around with the way we inject Flags into the page and our new method will now correctly show Flags template transclusions on Special:Whatlinkshere. This was one of the features we hoped to get "for free" from MediaWiki thanks to the way we put Flags into the page. Turned out to be a bit tricker, but we got there. ;) The changes go live on Tuesday. --TOR (talk) 00:27, June 19, 2015 (UTC)

Comment - I like it, however I'm noticing a few issues. If you were to view the RDR Wiki's article in Wikiamobile, the "portable-flags" get shoved under the "Full site" link in the footer as well as being shown at the top of the article. Looking over at the flags on the test wiki, some don't transfer well if the field names are not set correctly. Whenever they are editable by administrators in the appropriate page, then that would be nice. I also would like to be able to change the order of how they appear on pages rather than being strictly alphabetical. Ryan PM 12:12, June 12, 2015 (UTC)

Thanks for spotting that issue on the mobile skin - I'll make the team aware! Do you have any specific examples of stuff that's set up wrong on RDW? We can get it fixed.
Regarding the order, one thought we have is that admins can choose a global order on Special:Flags, which is then followed on every article. How does that sound? Kirkburn <staff/> (talk) 15:04, June 12, 2015 (UTC)
What about the order of multiple uses of the same Flag/Template? Specifically, some articles here have multiple instances of {{Otheruses}}. Generally, the first of these includes a description of the current article, while the next ones have "def=no" as a second parameter. It would be important for the one that is currently first, to remain first. An example of such an article is: Spiny helmet. IP83.101.44.209 (talk) 15:27, June 12, 2015 (UTC)
That's an interesting case (multiple uses of one template at the top of the page) - I'll bring it up with the team. Thanks! Kirkburn <staff/> (talk) 15:33, June 12, 2015 (UTC)
The example I'm thinking of is this article which has a template (it's really only used on one page and just testing on that page since no Update Namespace articles were imported) but shows that the field "Author" in flags should be "Title". I'm also surprised that changing the content in the fields that flags sometimes use is not recorded on the page history or the log page for flags.
As for Wikiamobile, there are other shenanigans at play when you scroll down, at least in Chrome on iOS when the URL bar is present there is no border around the notices, but when it is not seen there is a border around the notices. Now what I think should be done for the mobile skins is to have what Wikipedia does to hide them unless tapped upon. Ryan PM 22:35, June 12, 2015 (UTC)
According to Template:DevDiary, the parameter is called 'Author'. Is the documentation wrong?
Regarding logging changes to flag inputs - I'll make sure to bring that up with the team. How significant do you feel the issues could be with that?
Thanks for the ideas on mobile presentation! Kirkburn <staff/> (talk) 16:57, June 15, 2015 (UTC)
The documentation does, unfortunately, appear to be wrong and as stated previously that the template is really only used on one article as nothing in the future could possibly make use of it since it's for an type of now discontinued article type/piece from Jagex. Ryan PM 21:33, June 15, 2015 (UTC)
Ah, thanks for the explanation. If/when we come to enable it here, we'll make sure you can make updates and tweaks to the Flags list before any switch. (Not a great deal of point doing so on the test community). Kirkburn <staff/> (talk) 22:15, June 15, 2015 (UTC)

I might as well ask - I'm not an admin here, but can I still request admin rights for that test wiki? Or staff or council; I just want to test the tool full on for myself. I can guarantee the level of prodding I'd like to do would probably annoy the people at reddead (or any other non-sandbox wiki). If that's not acceptable, can you point me to any other sandbox wiki that wouldn't find my 8,128 test edits disruptive? or enable the extension on another test wiki (preferably [[w:c:iiiiiii]])? MolMan 14:52, June 13, 2015 (UTC)

Certainly, someone with 130k edits is probably a good person to get feedback from - I've granted you admin rights so you can view it! Kirkburn <staff/> (talk) 16:57, June 15, 2015 (UTC)
Thanks! MolMan 17:48, June 15, 2015 (UTC)

Mol Man feedback[edit source]

Few suggestions

  • Adding a flag to the page counts as a transclusion of the page, which is a good thing. But... it will not be cached right away. I had to null edit pages to get them to show in WhatLinksHere. Anyway the page can be force null edited to get it a head start?
    • This also causes some problems with flags not displaying after page moves until the page is edited or the flags are resaved.
  • Allow substitution of templates, etc. Tons of things I use for mass editing. Anything as simple as {{subst:PAGENAME}} to {{subst:#replace:{{subst:#explode:{{subst:PAGENAME}}|(|0}}|But|But}}. I'd find it helpful if these were parsed and substituted.
  • Show flag changes in log (noticed Ryan said that after typing this). Currently only adding and removing creates a log action. You're opening us up to a ton of vandalism if people can change the text in flags to "Penis" without leaving any trace.
  • Can all flag additions done at once be one log action? Otherwise it might get kinda disruptive. I can easily create twice as many log actions as there are flags by having 2 copies of a page open. One with every flag checked and another with them all unchecked. LOL
  • With the above, I can understand the technical difficulties of doing so, but ability to revert such changes as well would be nice. Though it doesn't look like there's any sort of archive of flags since they're a log action (at least not currently). That's probably a big thing to put off the reverting thing.
  • Anyway to make certain flags dynamic? An example is that a solution to the above problem of multiple uses of the same template is that I could very easily migrate {{Otheruses}} over to Lua and subsequently give it the ability to handle an infinite number of parameters. I'm not sure how we'd be able to handle that.
  • Any particular reason why flags are visible when viewing and protecting a page?
  • Flags aren't saved when deleting a page. Probably intentional. Might be a few places where this would cause an annoying amount of extra work when pages are undeleted.
  • Anyway to prevent redirects from being flagged, at least by most templates (e.g. {{D}} might be an exception)?
  • Some notification both when editing the flags available (I know that's not a feature yet) and when adding flags to pages that a template exist. Example being {{Penguin locations}} somehow not being ported over to the test wiki, but still having a flag. It will currently just paste a redlink if the flag is selected.
  • The HTML and CSS classes are kinda weird... Everything has its own .flags-targeting-* parent. Wouldn't it make more sense to just have one .flags-targeting-readers to house all relevant children? And even if a custom order conflicts with that, I'd try to merge where possible.
  • Make parameters on some flags mandatory for the flag to be added. Example: {{Confuse}} is useless without a parameter.
  • __FLAGS__ doesn't work when transcluded. As far as I know, every other behavior switch does. It would be useful if this did as well. Though that could cause a problem or two; e.g. using __FLAGS__ as a parameter on a flag. But I think once worked around, it would be helpful. Mainly for those wikis who want to use a ghost template instead of the ugly behavior switch syntax. Also possible is customization of flags via template; see our {{ToC}}.

MolMan 17:48, June 15, 2015 (UTC)

I hope you don't mind, I've added a section header above this, to help split up the page a little. Thanks for the large volume of thoughts and suggestions!
  • We'll bring up the caching concerns with the team.
  • I'm not sure how subst-ing is relevant to Flags. Can you explain this further?
  • Flag input changelogs - indeed, we've asked the team to work on a quick solution for this. Beyond a more immediate solution, maintenance abilities (history, undo, etc.) we'd love more thoughts on.
  • Adding/removing multiple flags at once doesn't strike me as a common action, to be honest. Can you convince us otherwise? :)
  • There's no particular reason that you couldn't use Lua in a Flag template - it should be possible to make necessary tweaks right now. Have you reason to think otherwise?
  • "Any particular reason why flags are visible when viewing and protecting a page?" - I don't understand the question, to be honest. Could you explain what you mean in more detail?
  • Why would you want to avoid redirects having flags? Not sure what the concern is here.
  • The missing {{Penguin locations}} issue is something you'd deal with via [[Special:Flags]] - you'd just remove it from the list of flags.
  • Deleting and undeleting a page is an interesting case - we'll have to think on that.
  • Regarding CSS - this may change a lot as we continue to develop the feature. Ideally we want to design such that admins have no cause to want to use those classes.
  • Mandatory parameters - interesting, we'll look into that idea.
  • In an ideal world, no-one would want to use the FLAGS magic word - the default situation should match normality most of the time. In any case, we can look into the transclusion behaviour.
Thanks again! Kirkburn <staff/> (talk) 20:09, June 15, 2015 (UTC)
  • As an example for where substing is relevant, check this diff: on Blood rune (Runespan). To make that edit, I didn't type in Blood rune manually, I used something like
{{Otheruses|the [[Runespan]] version of this rune|other uses|{{subst:#replace:{{subst:PAGENAME}}|(Runespan)}}(disambiguation)}}
Not because I like being convoluted (though I do), but because I was doing the same thing on several pages. With flags, substing just pastes the subst literally, see [[w:c:runescape-test:Gas_mask]]
  • As for Lua, I didn't mean I have concerns about lua working in flags. I'm talking about using Lua to expand flags, specifically {{otheruses}} for getting around the multiple uses of a single flag problem, to work with an infinite number of parameters. So, for example I could have
{{Otheruses|the shark|the other shark|Shark 2|def2=no|the third shark|Shark 3}}
Instead of
{{Otheruses|the shark|the other shark|Shark 2}}
{{Otheruses|def=no|the third shark|Shark 3}}
While not totally necessary, having an infinite number of parameters can be useful in some cases. As a current example, the live version of {{Confuse}} can handle an infinite number of parameters. So I'm suggesting some way to handle that without putting 50,000 text fields for users to edit, 49,999 of which unused.
  • This is what I mean by seeing flags on protection/deletion pages. It's just kinda weird.
  • It appears flags also appear on the diff screens... That's just weird...
  • Our redirects tend to be bare, but not every wiki's I guess. But we are the best wiki. Just sayin'.
  • I was just using it as an example. But it might be helpful to have a message that says "This template doesn't exist". Example: Some admin is managing flags and accidentally makes a typo. I mean, I know it can be changed. But maybe an oopsies warning.
  • To give more weight to the transclusion thing. Let's say a couple pages have a whole ton of flags and it's disrupting the important content. We could use something like {{Flags|hide=yes}} to transclude a collapsible table with the flags inside it. An example appearance would be this one here (though this example isn't templated, obviously; but certainly we'd want something like this to be templated, especially to keep uniformity). MolMan 20:30, June 15, 2015 (UTC)
Thanks for the explanations!
  • I think I understand the subst concern now - I'll bring it up.
  • Infinite Lua parameters - agreed! We definitely won't want to end up with frustrating lists of parameters in the flags tool. We'll look into what we can do.
  • Yeah, the flags are showing wrong on some action/admin pages - fortunately, I believe a few of those cases should be fixed tomorrow.
  • I'll bring up the error cases to the team.
  • Regarding the final case with lots of flags - this is something we'd probably prefer to fix within the Flags feature itself, to be honest. Valid concern though.
Keep it coming! Kirkburn <staff/> (talk) 22:15, June 15, 2015 (UTC)
Flags are indeed fixed today on admin pages (and diffs). :) MolMan 12:59, June 16, 2015 (UTC)
Excellent - thanks for checking it. Kirkburn <staff/> (talk) 18:35, June 16, 2015 (UTC)

A proposal[edit source]

Hey, as a followup to the excellent feedback and discussions above (seriously, it's been great, and we really appreciate it!), we have a proposal to make: we'd like you to consider having this enabled next Tuesday (23 June).

In order to really understand how to make this feature better, we want to see how it performs in real-world contexts and we think RSW would be one of the best places for this - your community is active, smart and full of great ideas.

We want to stress that all the feedback you are giving us is going straight back to the team, and this isn't something we're going to stop working on once it is enabled. We're already working on expanding the Flags log to cover edits to flag inputs for a code release next week. More work is already planned beyond that date, including API access, editor preview support, and editing functionality for [[Special:Flags]].

With that in mind, what do you think? What would you need to make this possible? Kirkburn <staff/> (talk) 18:35, June 16, 2015 (UTC)

Morning! Any thoughts on this so far? Some tweaks and fixes went live today - the most visible being that hovering over existing flags now shows an 'Edit flags' link, a quick entry point to the flags dialog. Kirkburn <staff/> (talk) 17:23, June 18, 2015 (UTC)
As a rough estimate, how far away from being non-beta is this? I don't want to sacrifice a system that works for one that makes our lives harder irrespective of how good it might be percieved to be. This isn't something we can ignore and never have to deal with if it doesn't work out, we're stuck with it. Also, given that this was primarily designed to alleviate issues in mobile how are flags actually viewed in mobile? Are they the same as they are now or do they have something that improves the experience of a mobile viewer? cqm 22:41, 18 Jun 2015 (UTC) (UTC)
Wikiamobile no longer shows flags, so in some cases that might not be acceptable when some templates are shown to be quickly accessible as a safe or dangerous minigame. Though as we know the viewer base for this wiki on mobile devices is next to none. I don't think for the time being that we should take this on. If it is as you mention, irreversible, then I'd like to wait to see how it develops.
I'm adamant on the portion of Flags that it needs to obtain the feature that Wikipedia has here, except that it would not only show issues but also be context sensitive or user-input to describe the flags. Overall Wikiamobile has its' own share of issues and the skin overall is not a priority for us when we still can't edit the CSS or JS for that skin locally. Ryan PM 12:48, June 19, 2015 (UTC)
Hey Ryan, we have the missing flags on wikiamobile issue fixed, and will release as part of our Tuesday update. TOR (talk) 13:34, June 19, 2015 (UTC)
The best way to display flags on mobile is definitely a matter of active discussion - and the Wikipedia 'this page has issues' method has certainly come up. Any other thoughts on this are very welcome!
At the current stage in development I would say the most tangible benefits for users is making it easy to add and remove flags from pages, plus fewer irrelevant notices for anonymous readers - but more benefits will be coming. From our perspective, we really want to get early feedback on what does and doesn't work, and how to improve it. There's no set date for this not being 'beta', because that really depends on the feedback we get from further testing ;) If, after enabling it, it did cause problems for RSW, disabling it is certainly possible - we can run a script to get pages back their original state. We definitely wouldn't want to leave you stuck with a problematic extension. Kirkburn <staff/> (talk) 16:43, June 19, 2015 (UTC)
I'd like to hold off at least until we get the ability to edit Special:Flags --Iiii I I I 15:54, June 19, 2015 (UTC)
Customization abilities on Special:Flags is still a few weeks away - but we'd definitely be very happy to manually update it in the meantime, and should be able to do so fairly quickly (it wouldn't have to wait for weekly site updates or anything). With next Tuesday's release, Sp:Flags will also list out the various parameters we've identified for the templates, so you can check those over too. Kirkburn <staff/> (talk) 16:43, June 19, 2015 (UTC)

I would prefer not having this turned on here until it's in a less fragile state, and particularly until we can modify Special:Flags. Perhaps we can re-evaluate then. ʞooɔ 23:54, June 19, 2015 (UTC)

I've added a update below - we've got a lot of stabilization-related tweaks coming tomorrow (though no Sp:Flags editing just yet) :) Kirkburn <staff/> (talk) 21:26, June 22, 2015 (UTC)

I really would like customization available (even if I won't be able to use it; I'm assuming admin-only) before we test, too. But I mean if you're going to ask for preferences on what ones to have for testing, can we have the following removed?

Alphabetical header :4
Antique update :2
Attuned :3
Beta content :4
Confuse :3
DevBlog :2
DevDiary :2
Disambig :4
Dual wield :3
Epilepsy warning :4
Essay :2
Expand :4
Floor :3
Has calculator :3
Has dialogue :4
Has lore :4
Has money making guide :3/4
Has quick guide :3
Has strategy :3
Holiday NPC/4 July :2
Holiday NPC/Christmas :2
Holiday NPC/Easter :2
Holiday NPC/Halloween :2
Holiday NPC/Thanksgiving :2
JSCalculator :2
Lucky :3
Main :4
MMG page header :2
Nutshell :2
Official world :3
Other users - potion :3
Other uses :3
Penguin locations :2
Previous rfd :2
Quick Guide :3
Redirect :3
Redirect 3 :3
See also :3
Slang also :4
Static calculator :2
Superior or Inferior :3
Temporary update :2
Update :2

Most of it based on one of four things:

  1. Information is important
  2. Template is not used in the mainspace (or not used often (e.g. BXPW) or not used directly (e.g. Holiday NPC/*))
  3. Template doesn't take up a significant amount of space, no point in moving it.
  4. Template is not normally situated at the top

MolMan 23:56, June 19, 2015 (UTC)

Hey, that's quite a list! I would say I'm a little surprised by some of them - why would the importance of the information be a reason to remove it from Flags? As we mentioned, everyone sees the 'Reader' flags, just as they do today. Not taking up much space is an unusual reason too - what examples are you thinking of? Kirkburn <staff/> (talk) 21:26, June 22, 2015 (UTC)
I'm thinking big picture. If collapsible flags become a thing, there's certain ones we'd want to always be visible. I'd also really like to follow Wikipedia's standards (because they've had a thing like this for years). E.g. otheruses not being a flag. Maybe that wasn't the best way to word it because looking back, I think the only things falling under that category are the seealso class templates actually that seems the same as point 3. Whatever, I just think these otheruses things should remain outside of flags. In any case, I've put my reasoning after each template with :# matching to my thing above. MolMan 22:09, June 22, 2015 (UTC)
If Flag collapsing becomes a thing, the relative importance of a Flag would definitely be something we consider. It would be silly to hide a 'spoiler' notice from being seen, for example. Thanks for the numbering - I'll give that more of a review, so help understand your thinking. Kirkburn <staff/> (talk) 00:09, June 23, 2015 (UTC)

No thanks - I don't see how these are better than what we have already. They're kinda neat, I guess, but they're severely feature-lacking over what we have right now. I mean, really, we have to go through staff to edit flag setup? wtf? Even if it was a complete and mature extension-thing, I still don't see the benefits. Hiding the text from search results, maybe (though whatever class/id you're using to do this, presumably with JS or CSS, could equally be done to the templates directly - if it even works?). Might be useful for other wikis to see pageviews for pages with notices, but we can already do that; and hiding the templates which encourage editing sounds bad - we want to encourage anon editing, not pretend our articles are perfect. So, no thanks. Quest.png Gaz Lloyd 7:^]Events!99s 00:07, June 20, 2015 (UTC)

Thanks - we certainly appreciate the constructive criticism. It's fair to say that the feature is pretty simple at the moment - but that's largely because we want to hear this kind of discussion, to know what is needed to improve it. Indeed, that's why we want you to considering switching it on at this early stage, to give it a really thorough review. We do think the feature as it stands is in a pretty strong position, but I understand how it may not feel like a significant difference/improvement to the current default behaviour. It's a bit of a Catch-22 situation, in a way: we want feedback on active use to make improvements, you want improvements in order to make active use of it.
For you, what would make this feature appealing? Kirkburn <staff/> (talk) 21:26, June 22, 2015 (UTC)
A reason to use it. As I said, almost everything you mentioned we can already do, is of dubious use or is a big downgrade. Does Wikia have an end goal for this feature? What's in it for them and what's really in it for us? Will this be forced upon us in future anyway, like most 'upgrades'? Quest.png Gaz Lloyd 7:^]Events!99s 15:39, July 1, 2015 (UTC)
That's reasonable - we'll be working on more functionality for the tool (some directly influenced by the feedback here), which I think could help here. We'll let you know when updates are coming.
We do roughly hope for this to be used globally - but we want that to be because users all want to use it. A primary reason for creating this tool is to help pages work well across all devices, especially mobile devices - right now notice templates are a particular pain point. Since they are generally article meta data, we think it makes sense to try and approach them from that viewpoint - improve their 'portability' by dealing with them separately, while maintaining much of their traditional behaviour. Kirkburn <staff/> (talk) 21:30, July 1, 2015 (UTC)

Monday 22 June update: a range of tweaks and improvements will be coming with tomorrow's release - including simply mobile support, better logs, improved behaviour around updates, and being able to see parameter settings on [[Special:Flags]]. (Flag customization without going through staff is coming). Clearly the proposed date above will not be possible - but we would certainly like to keep forging ahead with these excellent discussions about how RSW could get on board with this feature in the near future. Kirkburn <staff/> (talk) 21:26, June 22, 2015 (UTC)

Is there any particular reason Wikia would like to see this here in particular? Is it just a case of it happened to be set up on runescape-test and you guys don't want the work to go to waste or has it been designed with a lot of our specific needs in mind? cqm 21:39, 22 Jun 2015 (UTC) (UTC)
Setting up the test community is not a lot of work in the grand scheme of things - we just think your community would be an excellent place for it to be tried out. Flags is something we want everyone to be able to take advantage of eventually, so it makes sense to go to communities who will have the most interesting needs and feedback first. Kirkburn <staff/> (talk) 22:05, June 22, 2015 (UTC)
It's weird that no default message was added yet for the parameter log entries. I created those myself, but... I wasn't able to produce any log actions. MolMan 22:37, June 22, 2015 (UTC)
Ah, that's because the code for the improved logs isn't live until tomorrow - I've deleted your interim messages, in case we make further tweaks (don't want to end up confusing matters). Kirkburn <staff/> (talk) 00:09, June 23, 2015 (UTC)
Then I'm confused as to how there were already logged messages. Also, your last edit was +666. spoopy MolMan 00:12, June 23, 2015 (UTC)
Ah - the improvement was adding logs for changes to parameters. Logs for adding and removing flags themselves was already active. Kirkburn <staff/> (talk) 18:23, June 23, 2015 (UTC)
I know. I saw the param changes in the logs yesterday. MolMan 18:33, June 23, 2015 (UTC)
Oh, I see! This would likely have been because they were testing pre-release code (we have useful tech that allows us to test upcoming release code on live sites). Kirkburn <staff/> (talk) 18:38, June 23, 2015 (UTC)
OMAN! I just got kirkBURNED. MolMan 18:42, June 23, 2015 (UTC)
I gave you that joke in IRC you dingus User talk:ThePsionic.png: RS3 Inventory image of User talk:ThePsionic ThePsionic Special:Contributions/ThePsionic.png: RS3 Inventory image of Special:Contributions/ThePsionic 18:43, June 23, 2015 (UTC)

Arbitrary break[edit source]

Hullo RSW. We've pushed a couple of rounds of new fixes since we last spoke, and some more feature updates will be coming soon. We'd definitely like to encourage more testing on the test community - [[w:c:runescape-test|]]! Anyone taken a look recently, and/or had any new thoughts on the feature?

I would also like to ask you quick a question - how different is 2007scape Wiki from RSW? Is it mainly in the contents of articles, or do the differences run deeper than that? Kirkburn <staff/> (talk) 16:31, July 6, 2015 (UTC)

A couple of minor thoughts:
  • The colour of the flags 'bars' in the modal is the same colour as the top and bottom bars, making it harder to distinguish between them. Would it be possible to alter the colour of either ever so slightly to make them more distinctive?
  • There's a spelling mistake in one of the parameters for "Other uses", sugested -> suggested. Not sure how you go about fixing it.cqm 22:50, 6 Jul 2015 (UTC) (UTC)
Additionally, the flags link in the edit dropdown doesn't reflect that it's technically editing the page when it's at the bottom of the list. Would it be possible to move higher, possibly below the (visual) edit link? cqm 07:14, 7 Jul 2015 (UTC) (UTC)
2007scape is different in the aspects of javascript, CSS, content and a bit of administration. The templates are mostly all imported from this wiki. — Jr Mime (talk) [VSTF] 23:01, July 6, 2015 (UTC)
More thoughts:
  • Two "Edit flags" buttons are unnecessary. The second seems to only appear after a certain number of flags are added, but there's never going to be so many flags that we can't see the button at the top
  • The placement of "Edit flags" is awkward. How about something like this? --Iiii I I I 23:06, July 6, 2015 (UTC)
  • @Cam: we'll fix the spelling mistake - fortunately, that'll be easy for communities to do once Special:Flags editing is available, which isn't far off. I'll pass on the thought about the flag dialog colouring - it does kinda merge together right now. Fair point about the positioning of the menu option, we'll give it some thought (the current position is mostly a reflection of this being a beta test).
  • @Iiii I I I: the second 'Edit flags' link shows up when there's three or more flags showing at once. With the size of notice templates on RSW, I can see how that feels a bit weird - it may make sense to make it 4+ instead. For the button positioning: generally we don't want to add too many calls to action visible at once; that's been a bit of a problem on Wikia as it is - buttons everywhere all acting differently. That's not to say the current version is perfect - but we want to avoid another permanently visible UI action.
Thanks! Kirkburn <staff/> (talk) 15:16, July 7, 2015 (UTC)
2007 wiki is pretty similar in most regards. After all, it's a content fork of this wiki, sharing several prolific editors. The big guy (read: Cook Me Plox of 07) to talk to would be User:Spineweilder. But I am also an admin there, and the best one at that. Just saying. MolMan 20:13, July 7, 2015 (UTC)
Also Kirk, looks like you confused my line with Iiiiiiii's lines lol. — Jr Mime (talk) [VSTF] 22:57, July 7, 2015 (UTC)
I think you're confusing Kirkburn's confusion with what he was actually confused about (your lines vs. Cam's second note, not your lines and mine) --Iiii I I I 03:20, July 8, 2015 (UTC)
I've edited my comment so it makes more sense :) (note to self: just ignore Jr Mime in future ;) ) Kirkburn <staff/> (talk) 22:13, July 8, 2015 (UTC)
Literally no reason to talk to him in the first place. MolMan 22:17, July 8, 2015 (UTC)
Another thought I had (I've not tested this to be sure), but do flags respect protection levels? For example, if the page is fully protected, only admins+ can edit the page content and therefore only admins+ should be able to edit flags. Flags are unlikely to be very contentious, but it's something that could be easily missed that could prove annoying in the future. cqm 07:27, 9 Jul 2015 (UTC) (UTC)
Yes, they'll match the article's protection level. :) Kirkburn <staff/> (talk) 16:15, July 9, 2015 (UTC)

Comment - As far as I can see, there's no compelling reason for us to switch to using flags right now, and it's doubtful that there will suddenly be a reason to use them in the future. With respect to supporting the notices across different platforms, it's no different to the current situation and given the sheer number of possible variations of notice templates across wikia I doubt they will ever be entirely supported everywhere especially if the plan is to do it via a single stylesheet applied to all wikis. If anyone genuinely believes a single stylesheet will suddenly make these look good on mobile for all wikis they're crazy as there's no way that's achievable without further modifications to the templates themselves to bring them in line with wikia 'standards'. I appreciate that this is a beta/prototype at the moment and more features are planned, but the closest goals aren't likely to exceed the feature set we have currently have available through templates and there's very little to be gained when they eventually do.

I vaguely recall there was some mention of trying to hide these notices from search engines, but from what I can tell google does that already (and oddly enough this brings up an issue with image descriptions being shown in search results too). If you're trying to hide them from the meta description used internally for searches, etc. they're already hidden as well.

We can keep providing feedback on this, but I'm not convinced it's ultimately going to go anywhere. cqm 07:27, 9 Jul 2015 (UTC) (UTC)

For mobile devices - the first step of improvement is hiding notices that mobile users can't do anything with (e.g. requests to merge a page). Those get in the way of actual article content, and increase the likelihood they will simply move on. Another step, which we're planning on looking at in the future, is perhaps collapsing the notices into an expandable list - kind of like Wikipedia's method.
Essentially, we want to make notices behave better than they do today, but not force everyone to recode them. While we are having some thoughts around how some notices themselves could look in future, 'standardizing' them just isn't our aim atm. We also don't really want to end up encouraging them to be used more, because they are roadblocks in the way of content. Useful roadblocks, but roadblocks nonetheless. If too many exist, they go from being a positive influence, to a negative one. So! Our aim is basically: existing flags, but better.
I believe whether search engines already hide flags is somewhat dependent on how the flags have been coded. While it might not make a difference for some communities, others could certainly benefit.
Definitely please do keep providing feedback - it's all a strong influence on our thoughts and plans! Kirkburn <staff/> (talk) 16:15, July 9, 2015 (UTC)
I'd suspect we can simply emulate the hiding of notices we don't want mobile users to see with CSS as I doubt you guys have a separate stylesheet for users and readers as it probably reduces performance.
The 'expandable' list wikipedia has seems to be largely based on having a template that wraps the notice type templates. That's a feature I'd like to have, but again it's not available thus we still lack a compelling reason to change. This wiki has never been persuaded to have something just because it's new and interesting, we need actual improvements on the old system, hence we've never adopted article comments, message walls, blogs, video, special:forum, etc. We know there's often drawbacks in wikia extensions that will give us a headache further down the line. All the feedback we've given will hopefully avoid any headache if we do elect to change, but for now I'm sceptical and I doubt it's just me. The aim to make anything better is always going to be a common goal, but so often it's not always better from every angle.
From a discussion I had recently with Cook, we came to the conclusion that google will always index flags regardless of what you try. It's possible altering the HTML structure might help (such as moving them to be outside an article tag), but we managed to make the notices show up on wikipedia. It would appear google just filters out any content automatically based on what it is. We had a problem a while back with exchange data (it looks like a csv file) showing up in search descriptions, allegedly due to it being in a p tag. By the time I figured out how to fix it, google had already removed it. I'm unconvinced it's actually possible to deliver the ability to hide flags from google, although if it is then we'd probably be able to emulate it anyway. cqm 16:34, 9 Jul 2015 (UTC) (UTC)

Comment - I haven't noticed Flags being rolled out here, but for some reason there's notices saying certain templates are now flags, e.g. Template:Disambig (which shouldn't be a flag anyway). It's nice to see [[Special:Flags]] has indeed been implemented, but I'm not sure why it's apparently enabled here without community approval. cqm 09:03, 18 Jul 2015 (UTC) (UTC)

Also, Special:Version uses the wrong message for the extension description, [1] [2] cqm 09:11, 18 Jul 2015 (UTC) (UTC)
Thanks for spotting that - I'm letting the team know! Kirkburn <staff/> (talk) 23:21, July 18, 2015 (UTC)

FYI: you may notice a box talking about infobox conversion on some template pages - this is related to a feature we're testing, to help convert infoboxes to some new code (which we can make appear really nice on mobile devices): [[Help:InfoboxMigration]]. We'll have more info for you very soon on this! (Note: it's appearing on some pages which aren't infoboxes - we're looking into this.) Kirkburn <staff/> (talk) 23:21, July 18, 2015 (UTC)

We've already seen the infobox thing and discussed it amongst ourselves multiple times. We don't like it one bit. MolMan 16:45, July 28, 2015 (UTC)

Comment - [[Special:Flags]] now supports editing, although apparently not custom groups as evidenced by the vast majority of our flags being in the "Other" category. Now this feature has been delivered is there any interest in pursuing this further? I'll ask Kirkburn for a list of known/potential future features as well in case that may swing the debate. cqm 15:19, 7 Aug 2015 (UTC) (UTC)

Hey - indeed, [[Special:Flags]] editing just launched yesterday! Please do feel free to test it out, and let us know if you spot any problems. It still shouldn't have any effect on your articles, as before. I think many of your flags are in 'Other' simply because we couldn't spend hours learning about the use cases of all of them :) Regarding that, do you think there's a category that many of them could go into, but which doesn't already exist?
Next up is [[Special:Insights]] lists based on flag usage - this is already being coded, and shouldn't be far off (which is why there's already links to it on the updated Special:Flags page). How they behave and display on the mobile skin is likely to come up as the next area to review. Kirkburn <staff/> (talk) 15:34, August 7, 2015 (UTC)

Closed - No discussion in a month. Despite high levels of feedback, I don't feel there's sufficient interest or consensus at this time to enable this feature. When the feature set improves in the coming weeks/months we can revisit this if necessary. cqm 15:48, 8 Sep 2015 (UTC) (UTC)