Wikipedia talk:Geonotice/Archive 1

Reader information on use of geonotice-driven messages
We need better information on the user-side experience of geonotice-driven messages. The current information strikes me as written more for folks who want to use the system to create messages rather than those who are going to see them, who outnumber the first group by perhaps 4-6 orders of magnitude. The technical information provided is not written for the larger audience, and doesn't address obvious questions they would have:


 * How do I turn on the messages again after hiding them? (That is, without editing personal CSS or JavaScript pages, which most readers shouldn't have to learn how to do.)
 * Does hiding one message prevent me from seeing any later ones? (Especially important because people who find some useful will find others not.)
 * Where do I go for more information? (Most people with this question won't know about this page, even if it's expanded to address these issues. Expecting message-creators to provide this link is prone to error, and won't help folks who will reflexively dismiss geo-messages if they contain no link to more information about the message system itself.)

I'd also suggest, for the sake of readers, a more prominent and less technical statement about why they should trust that this apparently invasive detection of their whereabouts should not be a concern. Even though I know Wikimedia's privacy policies, and I follow Gmaxwell's explanation at Wikipedia talk:Meetup/DC 2, I think we need something simpler and clearer for a general audience. As a user of many websites I'm not interested in studying in depth (like many of readers here are), I usually find any website that attempts to offer me localized information based on its unasked-for deductions of where I am to be far too Big-Brotherish. I think we need a clear, bold, succinct sentence or two on why people can feel less anxious about this honest effort to be relevant.

In short, if we're going to splash these things on tens of thousands of user talk pages, they need to include a link to basic, reassuring information on how to use, disable, or selectively filter this system to satisfy their individual interests and concerns. ~ Jeff Q (talk) 16:05, 1 August 2007 (UTC)


 * I'll answer your second message first: Right now turning off a message turns off ONLY that message. So if you turn off "NYC meeting on the 11th" thats all you've turned off. I think this mostly addresses your first question since you're not disabling all future messages I don't see a huge need to have an unhide button. If you can come up with one please let me know.
 * On my talk you asked about the next DC meetup. A date hasn't been set. Once one is set I'll talkpage ping everyone who listed themselves as interested in the last one. (And, do a geonotice as well). If you've listed yourself and you're active at all you wont miss it.
 * As far as the concerns about who will inform the readers, I'm afraid I'm not qualified to address this point because I don't really understand the underlying concern. The response I've had in person over the notice is overwhelmingly positive and I don't see how any additional statement is going to avoid causing a net decrease in comfort, something like WP:BEANS probably applies.
 * Right now every message has been written in a way which doesn't make it seem that the message is location targeted. This is very important because the targeting can be fairly imprecise (not inaccurate for the most part, just imprecise): "Hello resident of DC" would look pretty stupid to someone in New York. I think that writing the messages with this style will also have the side effect of not creating the "hey!hows it know where I am?". So you can of it as a system that avoids giving a message to people who won't care about it more than a system that targets specific people... that really is a more accurate representation of the behavior since while it's probably 100% effective at keeping the DC message from showing in AU or the UK, it can't keep it from showing up randomly on the east coast of the US. --Gmaxwell 18:54, 7 September 2007 (UTC)


 * A reason someone might want to have an unhide button is that they might hide the message accidentally, or they might read a message, hide it, then later on they may wish to refer back to the message and this may not be possible to do easily. Tra (Talk) 22:17, 7 September 2007 (UTC)


 * Tra brings up exactly the kind of unanticipated user expectations that I'm thinking about. I highly recommend reading The Design of Everyday Things by Donald A. Norman. Norman entertainingly describes the many ways fully competent designers will inevitably miss some logical uses (and abuses) of their designs. Frankly, I think it should be required reading for anyone doing or aspiring to any kind of engineering. &#9786; ~ Jeff Q (talk) 23:42, 7 September 2007 (UTC)

Defunct?
This is defunct, right? If so, we should just close it down, because people are still posting requests, and they're never going to be answered.--Pharos 19:40, 19 October 2007 (UTC)
 * Um huh, it's not defunct at all. I've run every request that I've been pointed to. But if no one brings my attention to them...--Gmaxwell 20:46, 24 October 2007 (UTC)
 * You mean you should be personally notified of every request? We should put that in the instructions then; I'm sure most people aren't even aware you designed this.--Pharos 16:39, 26 October 2007 (UTC)

I hate this
It totally freaked me out today when I was signed in and yet here was this advertising banner ad telling me to come to some SF Wiki meet-up thing. I thought if I was signed-in I wasn't being tracked/stalked. Also the only thing it linked to was a bunch of stuff about party planner companies and architectural firms. This should be opt in. It also seems like advertising and I always liked that the Wikipedia was not about advertising. I am not an architect nor a party planner. I do not need this kind of spam infiltrating the one spam-free place on the web. This is a crappy new development. This is what Facebook is for. 70.143.75.31 (talk) 08:07, 3 February 2008 (UTC)
 * See the replies at Village pump (policy), which clarify what this is about. Thanks.--Pharos (talk) 04:37, 5 February 2008 (UTC)

Merged, and simplified
I have merged Requests for geonotice here, and simplified the process as well, because I think its overcomplication was discouraging widespread use. You can find some old discussion at Wikipedia talk:Requests for geonotice.--Pharos (talk) 21:35, 19 February 2008 (UTC)

User control of location
I think if this is going to be used extensively, it would be great for a user account to be able to provide a list of geographic areas that user is interested in, and to allow the user to select whether that list is used in addition to or in place of the guess about where the IP address is located. In addition to the cases where the geolocation services get an IP address wrong, there are users who travel a lot to particular places who might want to attend a meetup if it happened to match their other travel plans, or might even want to adjust the dates of their travel plans. And a Boston resident who wanted to attend as many meetups as possible might very well want to attend all the meetups in New England. JNW2 (talk) 18:10, 16 March 2008 (UTC)
 * There was a bugzilla request filed some time ago for a user preference to represent user location. The request was rejected on the basis of wanting to avoid collecting additional private data about users which would need to be kept private. I've thought storing the data only locally in the user's browser, but that wouldn't address users traveling.--Gmaxwell (talk) 19:34, 16 March 2008 (UTC)

Disable Geonotice completely?
Hi,

First; the default skin (monobook?) links to geonotice.py on tools.wikimedia.de, which is apparently a redirect to toolserver.org. Changing the link to point directly at the real location would save some bandwidth.

Second; when the toolserver(s) are slow (which is not that uncommon an occurance in my experience), loading geonotice.py consistently times out (possibly they're on round-robin DNS and I've cached a node that's borked). When I asked about this on IRC on #wikimedia-toolserver, flyingparchment said “nudge greg to move it to stable”. Consider yourself nudged. :-)

Finally; I see no particular value in this feature (speaking entirely for myself here, don't get me wrong!), and right now it's making my Special:Watchlist take aaaages to load, so I'd like some way to completely disable it. I tried adding #WN_GEON { display: none; } to my monobook.css, but for whatever combination of factors this doesn't seem to be sufficient to persuade my browser to optimize away loading the script. Any other way to make sure geonotice.py gets completely disabled? --Xover (talk) 18:51, 23 July 2008 (UTC)
 * The JS is only invoked only after the page is completely loaded. So the only 'slow loading' side-effect should be that the 'still loading' spinner stays spinning in the worst case. What browser are you running? In any case. I don't care if you remove it. --Gmaxwell (talk) 17:47, 6 September 2008 (UTC)
 * I'm running Safari 3.1.2. When the Toolservers are slow the Watchlist takes ages to load, and the Network Timeline / Web Inspector points the finger at Geonotice. However, I was looking for a way to disable it completely on a per-user basis; it seems many people find the functionality very valuable so I wouldn't want to impose my own preference on everyone else in this regard.
 * Any chance the client-side code could be rewritten to be more AJAXy or something to alleviate this problem? Maybe even throw in a cookie check and a “Never show this again (on this computer)” widget of some sort? --Xover (talk) 18:16, 6 September 2008 (UTC)

Restoring geonotice functionality
The geonotice functionality was disabled half a year ago due to a short-term toolserver problem and never restored, probably because of its maintainer having become inactive.

A single maintainer in any community project is always a potential problem, and we could do better. Instead of having to request a specific someone to update the notices, we could have them updated by any Wikipedia admin. I have put up a similar tool as the previous one, using the same database: ~para/cgi-bin/geoip. The notices could be fetched client side based on the response of the server tool, or fetched and delivered server side by a toolserver program, possibly with cached notices. Though this might result in two http requests instead of the original single one, maintaining the notices would be much more flexible.

There are recurring questions around Wikipedia for geonotice type of notifications, and the Foundation is running a San Francisco related notification right now to all Wikipedia users regardless of their IP location. Granted, the free geoip database used isn't perfect (test with some IP), but I don't remember seeing many complaints on misdirected notices when the previous geonotices were active. Would there be interest in rebuilding this functionality? --Para (talk) 14:32, 11 March 2009 (UTC)
 * Yes, we found it very useful for an Auckland meetup, which got record numbers of people. If geonotices were working again, we'd want to use them for further meetups and perhaps a "Wiki takes New Zealand" coordinated photo event.- gadfium 19:27, 11 March 2009 (UTC)


 * God, yes. The revival of this tool would be greatly appreciated by Wikimedians in cities across the globe who have attempted to organize meetups and other real world local Wikimedia events. I also know New York, London, San Francisco, Phildelphia, DC, LA, Sydney and many many other cities could use this tool, and the folks who still stallwartly post requests are a testament to geonotice's continued usefulness.  I have been cajoling various technical people for the better part of a year to get geonotice back, and if help is is now coming on this front I feel it will be a tremendous boon to the growth of real world Wikimedia activities, and the chapters and their work with universities, libraries and museums.  It's really unfortunate we did not have this in time for Wikipedia Loves Art.--Pharos (talk) 20:23, 11 March 2009 (UTC)


 * Alright, I wrote some Javascript to use the information. See User:Para/geonotice.js, and test if you like. I also wrote a little tool to see all the listed requests on a map. The process I had in mind was that people submit requests as before, and then interested admins edit the top part of the script directly to add and remove notices. Would it be too complicated? A template solution might be nice, but it would need one more HTTP request and more parsing at the client or server end. I like this current implementation because the server end won't have to be changed and all modifications would be to the Javascript. I'm however not sure on how often browsers will try to reload the Javascript and refresh the notices, will see about that. --Para (talk) 20:02, 17 March 2009 (UTC)
 * A single server page (e.g. Python as before) would probably be more reliable. However, this is definitely simpler to maintain.  As far as a race condition, I would expect the addOnloadHook to avoid that.  So this seems like a good solution. Superm401 - Talk 06:36, 20 March 2009 (UTC)
 * Could you can the format so it complies with JSON/YAML? Also, for(var ... in ...) is not very well supported in some browsers.  I think this would be best as an optional gadget.  — Dispenser 02:11, 21 March 2009 (UTC)
 * A gadget that people have to turn on would rather defeat the purpose; the idea is to reach people who would be interested in real life events in their geographic area, but who simply have no idea that such events exist.--Pharos (talk) 17:31, 21 March 2009 (UTC)
 * Dispenser, it basically is valid JSON. The only qualifications are that the quoting isn't correct, and comments can not be part of JSON.  A version with completely valid JSON is at .  This should be backwards-compatible with the actual script (untested).   That said, I don't think this makes a difference to any major browser (as opposed to a strict JSON validator like http://www.jsonlint.com/).  I also agree that geonotice should be on by default.  Used properly, this will be far more relevant to many people than many site notices. Superm401 - Talk 04:12, 22 March 2009 (UTC)
 * Also, for..in is ECMA-compliant, and there is no reason not to use it here. Superm401 - Talk 04:24, 22 March 2009 (UTC)

(undent) — Dispenser 15:09, 23 March 2009 (UTC)
 * 1) No it is not valid JSON, valid JavaScript; they are not the same.  It should output without the   and the semicolon.  This allows your tool to be reused in other applications.  But this prevents AJAX cross-domain call to the tool.  The solution to that is to add in a callback parameter (such as &callback=geonotice) that would embed the JSON object as an argument in the in a function call (e.g. geonotice({"latitude":38, "longitude":-97})) which also eliminates the aforementioned race conditions.
 * 2) for in is buggy in IE 6 and 7  who compose roughly 50% of web users, which is why it is almost never is used in production environments.
 * 3) Loading remote scripts are of require me to trust the source.  I would like this to be opt-in rather than opt-out.
 * 4) HTML/CSS code could be optimized a little.
 * I'm well aware JSON and JS are not the same, and nowhere did I suggest they were. That's why I said a "version with completely valid JSON".  There is no need for JSON to be in a separate file to be JSON.  I wouldn't begrudge you modifying the code to have the JSON in a separate file, but it's not necessary either.
 * Something like:

 if (wgPageName == 'Special:Watchlist') {  importScriptURI('http://toolserver.org/~para/cgi-bin/geoip?ip=66.35.240.8'); addOnloadHook(function  {     importScriptURI('http://en.wikipedia.org/w/index.php?title=User:Para/geonotice.js&action=raw&ctype=text/javascript&maxage=3600');   }); }
 * is adequate.
 * Regarding for..in, I know for..in is not safe to use in all cases.  I said it was safe here, and it is.  And frankly, claiming YUI  and Prototype  aren't widely used in production is very misguided.  In this case, we don't have to worry about prototype chains or overriding built-in properties.
 * If you're using NoScript (like me), it's already opt-in. But for the typical user, this is far more useful than most scripts they will encounter daily.  Superm401 - Talk 19:45, 24 March 2009 (UTC)

I think Dispenser and Superm401 may be partly talking of different things here, one about toolserver output and the other about the geonotice Javascript on Wikipedia.
 * Opt-out: Most Wikipedia users probably haven't heard of geonotices, and the whole thing is unlikely to be useful at all if it requires user action to enable. The number of people involved in requesting geonotices outnumbers those who have complained about it, but it would be interesting to find how many user css files have hidden the notice. That said, opt-out isn't implemented in the Javascript yet, but something similar to the "#WN_GEON { display: none; }" method described on the geonotice page should do, unless we want to add a gadget for the disabling to make it easier.
 * Tool: The results could be passed in a callback, but I don't see much advantage to it. There's the reusability aspect, but what script couldn't import a passive variable, and would instead import an active function call? In my mind the possibility of a race condition when the geoip data has expired isn't much of an issue, but my habit of constantly reloading the watchlist when I'm online may be exceptional, I don't know. Superm401's suggestion of calling the tool without waiting for the document to load solves that in most cases anyway (and the page this would be put in, MediaWiki:Common.js/watchlist.js, won't need the pagename check as it's in Common.js already).
 * Tool trust: After a period of wide scale testing, we can set up a stable toolserver project for this with multiple "maintainers" if people would prefer that. It would then be more in the hands of the community, like the Javascript bits. The source code of the tool is visible at http://toolserver.org/~para/geoip.fcgi?source or http://toolserver.org/~para/cgi-bin/geoip?source (rewrites internally to fcgi).
 * Geonotice formatting in Javascript: Superm401's suggestion adds quotes to conform to standards, ok, but I don't much like the whitespace changes. The file becomes harder to edit as it's more sparse and harder to make the distinction between notices. If you look at the short history of the script, there was a mistake already with the formatting. Superm401's improved indentation may help with that, but this all makes me think if an admin editable Javascript approach will work for the long run. I would like to hope that it will, but it's not as simple as using templates and most people aren't familiar with Javascript formatting. Would a few must-read bullets for anyone updating the page be adequate? --Para (talk) 13:02, 25 March 2009 (UTC)

Spanish Wikipedia
Is this enabled in all Wikipedias or only English? How can this be enabled? emijrp (talk) 13:21, 23 August 2009 (UTC)


 * The code that does this here on the English Wikipedia is in these files: MediaWiki:Common.js loads MediaWiki:Common.js/watchlist.js, which in turn calls the toolserver script that figures out where in the world the user is and then calls MediaWiki:Geonotice.js that contains and displays the geonotices.
 * I see that you are not an admin at the Spanish Wikipedia, so you need to ask an admin to do something like the following steps (but really in backwards order, I just explain them in the easy to understand order):
 * 1: Add the below code to es:MediaWiki:Common.js:


 * 2: Then add this code to es:MediaWiki:Common.js/watchlist.js:


 * 3: Then copy the contents of MediaWiki:Geonotice.js to es:MediaWiki:Geonotice.js and edit it to fit the Spanish needs.
 * But I am not an expert on this, I just discovered this system today and took a look how it works. Note that the above code will only add the geonotices to the top of the users' watchlists, not on any other pages.
 * --David Göthberg (talk) 02:08, 5 February 2010 (UTC)