User talk:Inqvisitor

Hello, Inqvisitor! helpme}} on your talk page and ask your question there. Please remember to sign your name on talk pages by clicking or using four tildes (~~~~); this will automatically produce your username and the date. Finally, please do your best to always fill in the edit summary field. Below are some useful links to facilitate your involvement. Happy editing! — Scientizzle 23:12, 19 August 2008 (UTC)[reply ] Getting started Getting mentored How to: edit a page • upload and use images Getting help Frequently asked questions • Tips Where to ask questions or make comments Request administrator attention Policies and guidelines Neutral point of view • No original research Verifiability • Reliable sources • Citing sources What Wikipedia is not • Biographies of living persons Sock puppetry Copyrights • Policy for non-free content • Image use policy External links • Spam • Vandalism Deletion policy • Conflict of interest • Notability The community Build consensus • Resolve disputes Assume good faith • Civility • Etiquette No personal attacks • No legal threats Community Portal • Village pump IRC channels • Mailing lists Writing articles Be bold in editing • Develop an article The perfect article • Manual of style Stubs • Categories • Disambiguation Pages needing attention • Peer review Miscellaneous Talk pages Clean up: General - Spam - Vandalism Join a WikiProject • Translation User scripts

On 27 August, 2008, Did you know? was updated with a fact from the article Amethyst Initiative, which you created or substantially expanded. If you know of another interesting fact from a recently created article, then please suggest it on the Did you know? talk page .

Congrats! --Gatoclass (talk) 05:24, 27 August 2008 (UTC)[reply]

Clearly, that there is a Bond template for all the movies is a good reason to remove it. Alientraveller (talk) 11:17, 3 February 2009 (UTC)[reply]

It's a film series that already has the succeeding film in its infobox. Now this clearly does not apply to just the Bond series, but every film then. I'll open a discussion at

WT:FILM. Don't say I told you so if consensus is overwhelmingly in favour of removing it. Alientraveller (talk) 18:41, 3 February 2009 (UTC)[reply

]

Here you go. Alientraveller (talk) 18:47, 3 February 2009 (UTC)[reply

]

A Barnstar Award for You!

		The Tireless Contributor Barnstar
		Very nice job on your U.S. Presidential election maps. Keep up the amazing work! talk) 22:34, 30 March 2013 (UTC)[reply ]

1984 U.S. Presidential Election

Your initiation of an edit war, when you were clearly in the wrong, was shameful and tiresome behavior. Please make no further edits on the article. Thank you. --68.180.28.138 (talk) 05:20, 22 April 2013 (UTC)[reply]

If you try to push a one-sided POV on Wikipedia, you will be reverted every time. An encyclopedia article must strive to present a neutral point of view, not present the perspective of a particular political faction as fact. Inqvisitor (talk) 13:16, 22 April 2013 (UTC)[reply]

I'm having an issue with a number of SVG maps I put up in a gallery displaying the delegation by delegation vote for the Republican Presidential nomination at their 1920 National Convention; basically it appears squished together from the sides, while the text doesn't move with the vectors, or that is how I am interpreting it anyway. Not sure if you could offer me any advice on the matter. Any help trying to find a solution would be appreciated. --Ariostos (talk) 13:34, 5 May 2013 (UTC)[reply]

That seems to have done it, thanks! Though, apologize for having to ask, but how did you turn the text into paths? I'll work it into the other maps and the VP map when its down. On a side-note, I am wondering if there is a way to hide a gallery so that it can be pulled down. The reason I'm asking that is, while it isn't an issue for those convention's that have at most ten ballots, for the Democrats in that year which had about 45 or so you are talking about maybe eight lines of graphics. A pull-down would leave them within easy reach while also preventing any stretching of the article itself. --Ariostos (talk) 18:59, 6 May 2013 (UTC)[reply]

Alright, tried a number of things on my own, still no idea how you made the pathing work. I've turned the text into paths but they still suffer from the same issues; the only difference I see is that for some reason, on your map, everything is on a single layer, but the layer isn't recognized when I go to view the layers that are present. So, sorry, but totally lost as to whatever the solution was that you found. --Ariostos (talk) 21:07, 6 May 2013 (UTC)[reply]

Have no idea why, but that isn't working for me. Changing all the Text to Paths for whatever reason isn't doing anything to the image once it is uploaded, still leaving that squished look.  :/ --Ariostos (talk) 19:37, 7 May 2013 (UTC)[reply]

You were right, the issue being that it was just taking a long while to update with the new file. I've moved on and established a more finished structure in the 1876 Presidential Article, exclusively for the Republicans at the moment, to see how it looked. The gallery is in a pull-down tab so as not to crowd given some of these would be rather lengthy, and I've changed around some of the methods I used in making in the maps. I like the new versions better, but I would like a second pair of eyes to help determine that as well. --Ariostos (talk) 00:36, 9 May 2013 (UTC)[reply]

Hi. Thank you for your recent edits. Wikipedia appreciates your help. We noticed though that when you edited

.

It's OK to remove this message. Also, to stop receiving these messages, follow these opt-out instructions. Thanks, DPL bot (talk) 10:52, 27 July 2013 (UTC)[reply]

Thanks for creating

, Inqvisitor!

Wikipedia editor SPat just reviewed your page, and wrote this note for you:

thanks for creating the article!

To reply, leave a comment on SPat's talk page.

Learn more about

.

Hi. Thank you for your recent edits. Wikipedia appreciates your help. We noticed though that you've added some links pointing to disambiguation pages. Such links are almost always unintended, since a disambiguation page is merely a list of "Did you mean..." article titles. Read the FAQ • Join us at the DPL WikiProject.

United States presidential election in Massachusetts, 1980 (check to confirm | fix with Dab solver

)

added a link pointing to Edward Clark

United States presidential election in New York, 1920 (check to confirm | fix with Dab solver

)

added a link pointing to James Cox

It's OK to remove this message. Also, to stop receiving these messages, follow these opt-out instructions. Thanks, DPL bot (talk) 22:58, 4 August 2013 (UTC)[reply]

Hey Inqvisitor. I'm contacting you because you're involved in the

in some way, either as a previous newsletter recipient or as an active user of the system. As you might have heard, a user recently anonymously disabled the feedback tool on 2,000 pages. We were unable to track or prevent this due to the lack of logging feature in AFT5. We're deeply sorry for this, as we know that quite a few users found the software very useful, and were using it on their articles.

We've now re-released the software, with the addition of a logging feature and restrictions on the ability to disable. Obviously, we're not going to automatically re-enable it on each article—we don't want to create a situation where it was enabled by users who have now moved on, and feedback would sit there unattended—but if you're interested in enabling it for your articles, it's pretty simple to do. Just go to the article you want to enable it on, click the "request feedback" link in the toolbox in the sidebar, and AFT5 will be enabled for that article.

Again, we're very sorry about this issue; hopefully it'll be smooth sailing after this :). If you have any questions, just

]

Disambiguation link notification for October 9

Hi. Thank you for your recent edits. Wikipedia appreciates your help. We noticed though that you've added some links pointing to disambiguation pages. Such links are almost always unintended, since a disambiguation page is merely a list of "Did you mean..." article titles. Read the FAQ • Join us at the DPL WikiProject.

United States presidential election in New York, 1884 (check to confirm | fix with Dab solver

)

added links pointing to Kings County and Queens County

United States presidential election in New York, 1888 (check to confirm | fix with Dab solver

)

added links pointing to Kings County and Queens County

United States presidential election in New York, 1892 (check to confirm | fix with Dab solver

)

added links pointing to Kings County and Queens County

It's OK to remove this message. Also, to stop receiving these messages, follow these opt-out instructions. Thanks, DPL bot (talk) 10:56, 9 October 2013 (UTC)[reply]

Hi. Thank you for your recent edits. Wikipedia appreciates your help. We noticed though that you've added some links pointing to disambiguation pages. Such links are almost always unintended, since a disambiguation page is merely a list of "Did you mean..." article titles. Read the FAQ • Join us at the DPL WikiProject.

United States presidential election in New York, 1872 (check to confirm | fix with Dab solver

)

added links pointing to Kings County and Queens County

United States presidential election in New York, 1876 (check to confirm | fix with Dab solver

)

added links pointing to Kings County and Queens County

United States presidential election in New York, 1880 (check to confirm | fix with Dab solver

)

added links pointing to Kings County and Queens County

It's OK to remove this message. Also, to stop receiving these messages, follow these opt-out instructions. Thanks, DPL bot (talk) 11:38, 16 October 2013 (UTC)[reply]

Hi Inqvisitor, we seem both to be currently working on the state presidential election results. Let's face it: your maps, (especially recent ones) are better than mine (though, I might add that mine are better than some out there). Any tips for map creation that I could use? -- or I would be happy to work with you on proliferating the good ones as I post. I'm about to add a lot to 1984, and I would like to add - very good work on New York. It would be nice to see interactive maps on the main election pages going back as far as these state ones are beginning to.

All the best.

7partparadigm ^talk -- 05:30, 15 November 2013 (UTC)[reply]

Hi, thanks for the response. The time issue is a big one with a project like this, considering that to properly archive these events would involve the creation of hundreds of pages, each unique somewhat. Very daunting task.

What I particularly like about the state results pages, is the ability to "click back" through time and see how your state has changed. What this project is also telling of is surprising local trends, like Democratic strongholds along the lower Mississippi River, across state boundaries, or the Republican Sierra Navadas. Websites, like the gold-standard David Leip's http://uselectionatlas.org/, show numbers, and a black and white map, but no pictures and include very little commentary about the election itself, nor the state's role in that process.

Anyway. Yes, the state maps have been cropped from your nationwide ones. I should have asked before doing that, I apologize. The main difference that I was referring to was the level of coastline detail that is evident

here

, or the previous version of New Jersey 1988, for that matter. In the absence of access to a good copy of photoshop, I devised a method of cropping which involves two programs (one online and one on my computer, which allows for proper rotation of the state) and screen-capping at the right moment, in order to crop the states for each year intelligibly. Unfortunately, the software that I have makes these maps look off when saves as an PNG, and I don't have the ability to save as SVG. I would be happy to incorporate your maps in new pages as I create them, instead of making them over again as JPEGs.

I also really have to encourage you to create interactive maps going back into the deep territorial days. If this is not possible, let me know how and I will try to create them instead.

So far, my strategy has been to create templates for years as opposed to states, which allows for "mass production" of 50 pages as needed for that year. Plug and play. I am going to start adding 1984 today. I'd love to coordinate our efforts. Let me know and I could post here a list of things that I think should be included in these pages, for discussion.

We've warred just a bit over colors, and going back, I have to agree with you. Putting red for all socialist parties (for example) is ugly, and minimizes their role in the election. Third party involvement is something that I would really like to highlight in these pages, as they are so often under-spoken. Please let me know if you have any ideas for finding suitable colors if none are listed on the party's talk page. I've just been "intelligently extrapolating" so far when picking colors when none are listed.

My goal is to get all states for all elections added by the 2016 presidential election, if not (hopefully) much much sooner. All the best. --7partparadigm ^talk 12:53, 16 November 2013 (UTC)[reply]

Hi. Thank you for your recent edits. Wikipedia appreciates your help. We noticed though that when you edited

.

It's OK to remove this message. Also, to stop receiving these messages, follow these opt-out instructions. Thanks, DPL bot (talk) 09:08, 16 November 2013 (UTC)[reply]

Hello, I'm

.

List of unpaired brackets remaining on the page(Click show ⇨)
| align=center| <1% {| class="navbox collapsible collapsed" style="text-align:left; border:0; margin-top:0.2em;" |total = 249,121 (24.28%

Thanks,

]

Disambiguation link notification for February 6

Hi. Thank you for your recent edits. Wikipedia appreciates your help. We noticed though that you've added some links pointing to disambiguation pages. Such links are almost always unintended, since a disambiguation page is merely a list of "Did you mean..." article titles. Read the FAQ • Join us at the DPL WikiProject.

United States presidential election in New Jersey, 1920 (check to confirm | fix with Dab solver

)

added a link pointing to James Cox

United States presidential election in New Jersey, 1924 (check to confirm | fix with Dab solver

)

added a link pointing to Robert M. La Follette

United States presidential election in New Jersey, 1928 (check to confirm | fix with Dab solver

)

added a link pointing to James Cox

It's OK to remove this message. Also, to stop receiving these messages, follow these opt-out instructions. Thanks, DPL bot (talk) 08:57, 6 February 2014 (UTC)[reply]

how are we going to fix this for the color blind? Frietjes (talk) 14:23, 10 February 2014 (UTC)[reply]

I'm afraid there's really no easy solution for that without making the whole article very messy and cumbersome. It's just such a universal standard to use red for Republicans and blue for Democrats, the colors are used on the main electoral college map, on the congressional district maps, on the county-level maps, the shading of the states by party on the state-by-state result table, and in indicating the state victory margins in the Close States section...and this color-based format is used in every single article in any way related to an American election. It's pretty much impossible to replicate all the data communicated by that color without really making a mess of the article, having to write out "Democratic" and "Republican" in every spot where blue or red is used. In some cases it would be pretty much impossible, because going through say a county map and putting a D or an R in each of 3000+ counties would be very tedious to make and not very useful since you'd have to zoom in very close to actually see the result.

I agree it's very unfortunate for colorblind users, I wonder if Wikipedia would consider possibly adding a Colorblind version of Wikipedia where all that information could be conveyed using exclusively non-color based methods, because it would be too messy and very difficult (in some cases impossible) to try to provide a colorblind solution on top of the color scheme system used in the main articles. If we can get a Colorblind version of Wiki, I would be happy to help contribute in making at least state-level maps and tables and communicate party data without relying on color. Inqvisitor (talk)

There is a discussion at Talk:List of United States congressional districts related to style of new district-level maps for the post-2013 United States congressional districts. Your input would be appreciated. Thank you. --7partparadigm ^talk 02:15, 11 February 2014 (UTC)[reply]

Hi. Thank you for your recent edits. Wikipedia appreciates your help. We noticed though that when you edited

.

It's OK to remove this message. Also, to stop receiving these messages, follow these opt-out instructions. Thanks, DPL bot (talk) 09:01, 13 February 2014 (UTC)[reply]

Hi Inq, I need help finishing updating several pages related to the US congress and ensuring that Wikipedia has current district maps represented. There is not too much left to do, but I could use a hand doing it. Details can be found here. I've seen your work, please let me know if you plan on doing a part of it and I will not touch it. Best --7partparadigm ^talk 18:24, 25 May 2014 (UTC)[reply]

Hi,
You appear to be eligible to vote in the current

]

Brad Verity

In response to your query:
Brad Verity
Appears to be an amateur genealogist/historian/blogger. Not a reliable source. --Kansas Bear (talk) 01:54, 11 May 2016 (UTC)[reply]

I agree the highest vote percentage should go on top (new york mayoral election for example), I however was just using the uniform legend unofficially established in all the 2016 presidential, senate, etc. elections. I'm not sure if this is the "standard", but it seems to be what everyone else has decided on. — Preceding

]

Hi, that is definitely NOT a uniform standard. It seems to be one rogue individuals's own recent major deviation who started going around changing from the 'standard' that was in place much longer for all sorts of elections at all levels of government going back over a century, the one-column standard still covering the majority of articles.

I know because I was the one in 2012 who started the process of replacing old low-res simple red-blue JPG state election result maps (or no map at all) with new SVG maps I made, shaded by percentage in each state's county & borough with the color scheme I chose that has now seemed to have been universally adopted. Then in 2013 I created previously non-existent NYC borough maps for all the existing articles back to 1993 & created new mayor election articles with maps going back so far to 1957. There was no standard, in fact there were no shaded maps, until I created a de facto standard to go with the new shaded maps.

Back in 2013, I created dozens of presidential election state articles of the

:United States presidential election in California, 1996

sort for California, Vermont, New Hampshire, New York, Massachusetts, Connecticut, etc., going back in some cases to the 19th century. For all of them I used the consistent basic one column vertical legend like in that California 1996 article & like I originally included when I uploaded the NYC 2017 mayor map this morning. I don't have a problem with reconsidering & using two-columns side-by-side, but this is definitely not a settled standard, & the order from top-to-bottom has never been discussed, certainly not settled.

I note that ONE person named "Count Awesome" is responsible for changing the format for

United States presidential election in California, 2000

and only the recent post-2000 elections since then with this new lowest-on-top side-by-side legend- and only on August 14 2017. He is also responsible for making other recent selective map legend changes here & there for other states, mainly only to post-2000 election articles.

You'll note that from 1996 back to 1960 California pres election articles still have the one-column legend I used when I uploaded the maps years ago. If you look at state articles like

United States presidential election in New York, 1912

, the same for Vermont, New Hampshire, Massachusetts, etc. my 'original' one-column legend scheme is still largely in place, which was originally used for ALL such articles using those new SVG maps/color schemes. For NYC mayoral races, until you changed those few legends today, all of them going back to 1957 still use the original one-column vertical legend. Dozens & dozens of historical election articles use the one column vertical legend, if anything THAT is still the original & overwhelming majority standard; changing it has never been publicly discussed.

Switching to a two side-by-side columns legend may work as an idea, but its definitely not the standard that's been in place for years across all articles using these SVG maps/legends since being created back in 2012, the majority of which still maintain the one-column legend format. If anything it is breaking what was the uniform standard for ALL such articles for years. Side-by-side putting lowest percentage on top has definitely never been discussed nor settled as a standard even if one rogue individual began making those changes, so reversing it to top-down order wherever you encounter that is definitely not breaking any consistent standard. If using a two-column side-by-side legend, it definitely makes common sense to put each candidate's highest % earned on top & lowest % on the bottom of the scale. If someone tried to challenge that & the topic actually WERE discussed, I don't think it would be hard to secure a majority consensus for top-down order as standard for side-by-side legend columns. It doesn't make any sense for the legend % to get weaker/lighter rather than stronger/darker as you go up from the bottom to the top of the scale. Inqvisitor (talk) 23:43, 8 November 2017 (UTC)[reply]

To put it more succinctly, IF THERE IS ANY STANDARD, it is the one-column vertical legend which I used when I first uploaded this whole new breed of SVG maps with brand new shaded color scheme back in 2012-2013, which was the de facto universal standard used for ALL articles for 3-4 years, and which the overwhelming majority of articles, especially historical pre-2000 articles still have; only quite recently did a rogue individual change only some of the more recent post-2000 election articles to a two-column legend, lowest % on top, of his own accord, breaking with precedent & disrupting the consistency of Wiki's election map infobox legends. "Count Awesome" can't claim that his recent editing of old legends to replace them with two-column legends, lowest % on top, is any sort of precedential agreed-upon standard, he himself is breaking with what was the implicit universal standard since 2012. Inqvisitor (talk) 00:04, 9 November 2017 (UTC)[reply]

Thanks for the clarification. I'm somewhat new to wikipedia editing, and mostly I've focused my efforts on map-making and converting jpeg/png maps to svg format. While uploading maps to their appropriate article, I've come across several different variations in regard to legends; the one column method seemed to be the standard and most common type when working with older articles. Newly updates ones, however, almost exclusively had the side-to-side, lowest to highest format. I ended up converting those old, single column articles to the side-to-side format, assuming that was the decided standard (obviously, it appears that is not the case). How would you recommend I proceed with new election maps (as in, updating old election articles that currently have NO map to include a map, which would that requires a legend). Should I use the one column vertical legend, use the "new" post-2000 method, or should I try to get people to come to some sort of consensus?

talk) —Preceding undated comment added 14:28, 9 November 2017 (UTC)[reply

]

Ah well welcome to the club! Map-making & converting JPG/PNG maps to SVG is exactly central to what I set out to do following the 2012 elections, when I came on here & found Wikipedia's election coverage to be lacking, if not abysmal. Election articles by state did not exist for many states nor did those that did go back very far in history. And election articles either had no maps at all, or they had an inconsistent mix of various low-resolution low-quality JPG/PNG images using basic old bright-red/blue 2 color scheme by county winner with no shading variance to break down by % scale, no legend. One Wiki user named Kelvin13 uploaded shaded SVG maps for NY & CT using the modern uniform (well now, mostly uniform) format with a 1-column scale legend from most Dem to most GOP, which I adopted for creating, uploading, adding maps to the other 48 states for 2012, then doing all 50 states for 2008, 2004, 2000, then working on individual states creating articles & SVG maps with the goal of making them each back to 1912. Nationwide county maps on main presidential election articles were also a hodgepodge mess of different primitive low-res PNG/JPG, for 2012 there was no map at all, so I created the first nationwide shaded county map for 2012 in SVG format, found at

United_States_presidential_election,_2012#Maps, uploaded to Wikimedia at https://en.wikipedia.org/wiki/File:2012nationwidecountymapshadedbypercentagewon.svg

in January 2013. Especially for nationwide maps, the SVG format is vastly superior, being able to resize & zoom in as close as possible or zoom out as far as possible to see results without any loss to map quality/resolution. I had to choose a full-scale uniform color scheme for both major parties & potential third parties left & right from >90% down to <40%, which I used on that map, all the state maps I made, all the historical nationwide county maps which I made & replaced old PNG Wiki maps with thus far going back to 1872. After the 2013 NYC mayoral election, I was surprised to see the Wiki infoboxes had no maps at all, so then I added borough maps using the same scheme & format for the existing articles back to 1993 & went on to create new maps & articles for elections going back thus far to 1957. For a substantial period of time, I was the only person making & uploading all these SVG maps & creating new election articles, more recently I haven't had the time, but I banged out quite a massive load of maps & articles in 2012,2013,2014. In the past 2 years it appears the format I established caught on, and thankfully now there are a lot of editors who adopted the shaded color scheme SVG map format I started as the norm for election articles.

Up until recently, this included the 1-column scale legend. I don't know who started changing map legends or when exactly, though it must be (and appears to be based on article edits I've seen) very recently. Having reflected more upon the matter, I'm really not convinced editing to change to side-by-side columns is a good idea. First off, it breaks what was the uniform consistency of Wiki election map legends up until 2017. Inconsistency in infoboxes/maps from one article to another was one of the problems I set out to fix with Wiki election article coverage in 2012. The vast majority of historical maps have the original one-column format. I am quite inclined to simply undo the recent two-column edits done to some articles to restore uniform one-column consistency. It is not only easier to revert those recent rogue edits, but when creating new maps/article, it's simpler & faster to use the scale legend rather than having to mess around with Wiki's column templates. The 1-column vertical scale legend is what is used on the original uploaded Wikimedia File source pages themselves, as in the 2012 file link above, so it would also maintain consistency with the File's own page on Wikimedia, and takes less time & effort to copy-paste the same legend from the File's description into an article infobox rather than creating a whole new legend with columns. More complicated & time-consuming doesn't necessarily mean better. Even if side-by-side columns were somehow superior in even the slightest, which I don't believe they are, I think it is a waste of time & effort to go through & edit loads & loads of old articles to replace their scale legends with 2-column legends. There are still hundreds of articles & maps to be created, so many countless better things to spend time on to improve Wikipedia election coverage rather than going through & changing existing legends. As the old saying goes, if it ain't broke, don't fix it. I don't think there's anything broken about the old legends. When I went about replacing old JPG/PNG maps with shaded SVG maps, I was well-prepared to defend the obvious merits & superiority of the format to be established as a consistent standard, worth the time & effort to replace, if anyone were to take issue with replacing their old simple red-blue PNG maps with shaded scale SVG maps. I don't think changing already-created legends for already-created maps in already-created articles from scale legends to 2 columns improves them in any way, it just wastes time/effort & breaks consistency across articles.

And on the merits of the two-column format vs. the vertical scale, having spent a decent amount of time now comparing the two in practice...I'm really not convinced the wide 2-columns with candidate names on top, % shade boxes underneath each name going from lowest down to highest, is better at all. Aesthetically I find there is a beautiful simplicity to having one vertical scale from deep dark blue to deep dark red, as you move toward the center in either direction both colors getting lighter & lighter and closer & closer to each other in shade, with purple right in the middle for ties. In the overwhelming majority of U.S. elections, with a 2-party system, it is 2 parties directly converse to each other. With the 1 column vertical shaded scale, it's a reminder of this purplish reality; splitting into 2 columns I think hearkens back to old simple red-blue winner take-all-maps, which sort of defeats one of the points of replacing 2-tone red-blue maps with maps shaded by the winner's percentage. In fact it is a sliding scale between the two, if a county was won by a Democrat with say 49.5% shaded with light sky blue <50% of the vote, that means the result is very close to very light pink <50% with the Republican likely getting say 48.9%. Having one vertical scale communicates that the 2 parties' votes are inversely proportional from deepest darkest blue lightening to light blue, purple, then light pink to deepest darkest red. One party winning a county with 50-60% means the other party got 40-50%. A party winning with 70-80% means the other getting in the 20-30%. Since the U.S. has a two-party system, and results are often more purplish than solid red or blue, having one vertical sliding scale better illustrates & communicates that, just as the benefit of using a variant shaded color scheme is to illustrate that. A county did not just go 100% red or blue. The two parties are in relation to each other, and should be on scale, not treated as independent of each other with 2 columns. Maybe those rare cases where a third party wins counties, a second column should be created for the third party.

Which brings up the issue that the 2-column legend using column templates is more than twice the width than the simple vertical scale, in some cases it already needlessly widens the whole infobox in order to fit. It doesn't just put 2 columns side-by-side, it adds a LOT of useless grey space using up a LOT of screen real estate in between the two columns. If a third parties have to be added, then it becomes ridiculously wide to have 3 or more columns.

Which relates to the final & really most significant point. The whole point of the legend is to help viewers quickly & easily identify a county's precise result based on its color shading. With the one-column vertical scale, the candidate's name and % range right next to each box, it takes a split-second glance to look down and match a color with candidate & percentage. The vertical scale also quickly tells you the highest % the Democrat got & the highest % the Republican got. When I look down at the new two-column legend, I see a confusing mess that needlessly wastes a few seconds to decipher. Each candidate's name is listed only once, awkwardly on top with an unnecessary amount of wasteful grey space between the candidate's small name & where the scale even begins below it, the candidates' names look like they're lost in between the map & the legend. The boxes of the legend have no names, only percentages, especially if it's a longer column going down more than 1 or 2 boxes, you can't instantly at a glance connect a map result with a candidate's legend result. Your eyes have to waste time diverting between one column or another, look down at one column or another, first play spot the candidate's tiny name, if you get the wrong candidate, then look to the side to try to spot the other candidate's name, then once you have the right one then slide your eyes or finger down to try to match the right box shading % with the right candidate with a result you see on the map. With the one-column vertical scale, all of the results are within one eyeshot glance. The 2-column template wastes lots of grey space in between making it more than twice the width for absolutely no benefit, all that empty space with only the percentage listed next to each box... while the 1-line vertical scale using up less than half the width provides both the candidate's name & percent right next to each box, an instant easy glance connection with precision. Finally there's the issue of the order of the % ranges lined up. As I said earlier, I think it's especially silly & confusing to have the lowest % on top going down to the highest % on the bottom, which is what I see on all the articles that have had been changed to the 2-column legend doing. But in either order it goes, the side-by-side format makes things messy & confusing. Since not every color on the scale is needed, but only the ones that actually occurred on one particular election result map or another, the 2-columns nearly always end up an ugly confusing mess with columns that don't actually match up with each other horizontally. E.g. if you have a state result where Republicans won virtually all of the counties with 40, 50, 60, 70%, 80%, while Democrats won 3 urban counties with 70, 80%, and 90%....then with the scale on the Republican side you would have light pink 40% lining up horizontally, slide your eyes or finger across to match up on Democratic side with...dark 70% blue. 50% GOP pink would match up with dark 80% Dem blue, 60% GOP pink would would line up deep deep dark 90% Dem blue. Then the GOP scale would keep going down to 70% & 80% with no equivalents on the Dem side, it looks like Republicans earned the highest % of the vote by two % grades going down to 80%, when in the fact the 90% Dem result was the highest result, but the Dem scale doesn't go down as far, the 90% blue box is confusingly matched up with the 60% red box, then the Dem scale stops. Nota Bene: That's just an example, a map result need not be anything so specific as that for this to be a problem. If you have even just 2 counties in a state, one 80% GOP, one 50% Dem, the side-by-side columns are screwed up & don't match, further confusing the whole mess of a legend. Recall I edited your edit of NYC 2017 two-column legend to go from highest to lowest, so by luck the 70%s happened to match up on top. But that is the very rare exception, not the rule. And if we went by the standard 2-column format you initially used & used everywhere else with lowest % on top, then the legend would be needlessly screwed up & confused with de Blasio 60% lining up with Malliotakis 70%. In 2013 NYC mayor, the 2-column legend format equates 80% De Blasio with 50% Lhota. Since states have WAY many more than 5 counties & often have a broad random assortment of % results on the map for each candidate, VERY RARELY both sides matching each other with the exact same number of results AND the exact same % categories of results to line up with each other, so it further confuses an already needlessly confusing mess when you're mind is trying to just quickly identify map results using the legend.

I've sometimes sounded like I'm talking in the theoretical here, but as you and I both know, there is a significant minority of articles that have been edited to the 2-column template legend format; all of the problems I have with it are observable. When I use page history to look at the before & after of election results in New York, California, Texas, et al., not only do I not see any problem with the original format in need of fixing, I see a lot of problems with this alternate 2-column format. I see the one-column vertical red-purple-blue D-R converse proportion scale with candidate's name & percent next to each box, fitting neatly within one eye-shot, the largest % each candidate got instantly identifiable in converse to each other while getting lighter & closer to each other while approaching the purple centre...in its simplicity is most effective at communicating as quickly as possible any precise result a map viewer is looking for in 1 rapid glance. The 2-columns next to each other (really across from each other) just add lots of useless grey space, the width means you can't look at the full legend in one eye-shot, you have to look back & forth between the columns- and the % boxes are virtually always mismatched with each other sliding back & forth horizontally, making things further confusing, you have to make messy criss-cross lines to match up the misleading % boxes of one column with the other. The 1-line vertical scale allows one to quickly & easily view the full list of results in one glance, easily view up & down the scale between the darkest blue % category & darkest red % category, with candidate name and % range both specified for each box, not having the candidate's name written just once in tiny letters in the grey ether in between the map & the top of each column scale. The 1-column converse scale better communicates the point of having variant shaded % counties instead of the old simple red-blue 'winner take all' JPG/PNG maps I replaced 4 years ago. Regardless of which candidate/party won a majority/plurality in a county, the results are often much closer to purple, the D/blue and R/red result are converse to each other, the vertical scale conveys the fact that a lower Dem % is closer to a higher GOP %, and vice versa. Red & blue get lighter & lighter & closer in color the closer they get to each other in %, purple used in the middle for ties to complete the spectrum. They are not independent variables the way the 2-column format presents them- again, unlike the vertical D-R converse scale, with 2 columns the location of a blue box in relation to a red box is not conveying any useful information, just the opposite, it further just confuses things when you have e.g. 50% GOP red horizontally lined up with 80% Dem blue, 70% GOP red lined up with 90% Dem blue, 80% & 90% GOP red going down further by themselves lined up with nothing on the blue side. Or Dems could have 4 blue boxes 40, 50, 60, 70, while GOP has 2 red at 80 & 90, 40 blue lined up with 80 red, 50 blue with 90 red, then 60 blue & 70 blue lined up with nothing on the red side going down further, it misleadingly looks like Dems reached the highest result going all the way down to 70, when in fact GOP reached 80 & 90- they're just ridiculously lined up at the top with 40 & 50 Dem. On the rare occasions where a 3rd party actually wins counties away from the 2-party D-R system, in those cases a separate column side-by-side from the D-R spectrum line may actually be useful. But if 2 columns is the standard for all regular D-R races, then having to add more columns for third parties would require even more insane amount of needless grey width to accomodate, while the 2-column legends already are needlessly wide, spread out, wasting screen & article real estate with useless grey space. Seriously, this alternate 2-column format uses up more than twice the width of the 1-column standard, and in exchange for what? With the vertical spectrum the candidate's name is easily listed next to each box along with %, the 2-column form more than doubles the actual width the legend takes up while removing the candidate's name from each box, all that extra width is needed to fit LESS information? Way too much useless grey space, even between the candidate's tiny name awkwardly positioned above the column below it is too much grey.

Ultimately all this two-column format does is waste a lot of grey space, while making the legend WAY LESS effective at quickly communicating useful & precise information to viewers. I tried to sum things up briefly last paragraph & ended up going on too long again with the list of problems with the 2-column alternate form map legend. "If it ain't broke don't fix it", well just a tiny handful of editors chose to break what was wasn't broken by replacing the simple effective one-column D-R converse proportion spectrum, which takes less than a split second glance to interpret & match with map results, to a sprawling confusing misleading mess that requires needless wasted time to decipher each & every time you look at a map, and fails to communicate entirely the point of using a shaded map to more precisely reflect the spectrum of purple America, instead of simple binary red-blue treated as independent variables from each other. Further looking at the bigger picture, editing a minority of articles to this 2-column legend has broken the consistent standard across Wiki election articles. Only a tiny handful of editors seem to be responsible for recently changing the legends without explanation in 2016/2017, in a minority of election articles, all of them that I could see only post-2000 elections. The overwhelming majority of historical election articles/maps, many of which I created myself, thankfully retain the old & in my opinion superior legend format.

Therefore in order to maintain a consistent, superior legend standard across Wiki election articles, I decided that I am going to restore the historical standard to all election maps, including post-2000 articles, as I encounter them. Having started this SVG map format/color scheme standard & created hundreds of SVG election maps at the national, state, & city levels beginning in 2012, using the simple one-column legend which has worked perfectly fine for years & still does on the majority of historical election articles...if there is anyone with prerogative to assert a 'standard' it would be me asserting the simple & effective one-line legend that is easier to make & easier to use than messing around with columns. Instead of wasting time & effort "fixing" what isn't broken on perfectly fine existing election articles/maps, I would invite & suggest to Wiki editors interested in U.S. elections to instead help fill in the still MASSIVE gaps in election coverage, there are countless historical state maps yet to be made for election articles, and even more countless articles still waiting to be created to cover historical elections in detail at the state level for every state.

A tiny handful of people over the last few months or so unilaterally decided to edit a relatively small # of recent election articles away from the pre-existing long-precedential standard one-column vertical spectrum, to the more complicated, messy, confusing 2-column look, without apparent explanation. Unless those editors can come up with convincing rebuttals to all of the flaws & problems with this new 2-column legend described in quite thorough detail above, and further provide compelling arguments as to why the long-existing vertical legend standard is so broken & fatally flawed that it needs replacing (in which case for consistency's sake every "broken" legend should be fixed), and how & why this new legend actually represents a genuine improvement over the old standard in doing the job a legend is supposed to do...

...ergo any new election articles, along with the minority of election articles that have been edited to this 2-column format should be reverted to the standard 1 vertical column legend which is not only just the long-existing standard that's not broken nor in need of fixing, but is on a multitude of counts vastly superior on its merits, for reasons described in thorough detail above. Simpler & more elegant, fits in one eye glance, more informative, reflects the purplish D-R inverse divide easily going up & down the spectrum, more effective, easier to create, easier to read & interpret, requires just a split second glance to match map results to the legend; that cannot be said for the messy two-column form which requires time to spot the candidate's tiny name written once amidst all the useless grey space, forced to look back & forth at both columns separated by all that useless space, inaccurately & uninformatively treats the D-R spectrum results as independent variables of each other in 2 party races, while too wide to accommodate rare 3rd parties; don't get confused by how the blue & red misleadingly line up with each other horizontally on each row, confusing, misleading, more complicated waste of time to create with column templates, more complicated waste of time to decipher every time you look at a map & try to match & interpret results. Okay I've said way more than enough to explain why I am going to continue to use the long-established one vertical column spectrum scale standard for any new articles, and will restore it to articles where it has been unjustifiably removed in favor of this inferior confusing legend, to maintain a consistent universal standard across Wikpedia's U.S. election articles. .......There has been no explanation nor discussion, never mind consensus, on any need to replace the long-standing existing standard, nor adopt this inferior "new standard" with its many apparent flaws & problems discussed in detail above, which I humbly submit on record as justification for restoring the old map legends, to anyone who might wish to assert this "new standard", in order to hopefully prevent the emergence of any potential edit warriors who would try to force the new standard without adequate explanation addressing the plethora of issues I raised in favor of restoring consistent use of the old standard.

Inqvisitor (talk) 00:25, 13 November 2017 (UTC)[reply]

Hello Inqvisitor, I was just about to message you on the MediaWiki Commons, but figured this would be a more suitable place to do so. How did you get the data, even when some precincts cross "county-equivalent" border lines, and apparently only election day votes are reported by State House district (see this, and others too) while early votes, absentee ballots, the disputed count, etc. are only tallied statewide, at least publicly? You can message me back here on my talk page whenever you have the time. Thank you very much for discussing the sources. Cheers! A Red Cherry (talk) 00:57, 15 August 2018 (UTC)[reply]

2019 Arbitration Committee elections is now open until 23:59 on Monday, 2 December 2019. All eligible users are allowed to vote. Users with alternate accounts may only vote once. The topic bans, editing restrictions, and other measures needed to maintain our editing environment. The arbitration policy describes the Committee's roles and responsibilities in greater detail. If you wish to participate in the 2019 election, please review NoACEMM}} to your user talk page. MediaWiki message delivery (talk) 00:07, 19 November 2019 (UTC)[reply ]

Your recent editing history at Byzantine Empire shows that you are currently engaged in an edit war; that means that you are repeatedly changing content back to how you think it should be, when you have seen that other editors disagree. To resolve the content dispute, please do not revert or change the edits of others when you are reverted. Instead of reverting, please use the talk page to work toward making a version that represents consensus among editors. The best practice at this stage is to discuss, not edit-war. See the bold, revert, discuss cycle for how this is done. If discussions reach an impasse, you can then post a request for help at a relevant noticeboard or seek dispute resolution. In some cases, you may wish to request temporary page protection.

Being involved in an edit war can result in you being blocked from editing—especially if you violate the three-revert rule, which states that an editor must not perform more than three reverts on a single page within a 24-hour period. Undoing another editor's work—whether in whole or in part, whether involving the same or different material each time—counts as a revert. Also keep in mind that while violating the three-revert rule often leads to a block, you can still be blocked for edit warring—even if you don't violate the three-revert rule—should your behavior indicate that you intend to continue reverting repeatedly. Fut.Perf. ☼ 16:45, 31 January 2020 (UTC)[reply]

Hi. Thank you for your recent edits. An automated process has detected that when you recently edited

.)

It's OK to remove this message. Also, to stop receiving these messages, follow these opt-out instructions. Thanks, DPL bot (talk) 06:04, 8 November 2020 (UTC)[reply]

2020 Arbitration Committee elections is now open until 23:59 (UTC) on Monday, 7 December 2020. All eligible users are allowed to vote. Users with alternate accounts may only vote once. The topic bans, editing restrictions, and other measures needed to maintain our editing environment. The arbitration policy describes the Committee's roles and responsibilities in greater detail. If you wish to participate in the 2020 election, please review NoACEMM}} to your user talk page. MediaWiki message delivery (talk) 01:28, 24 November 2020 (UTC)[reply ]

An automated process has detected that when you recently edited Eric, you added a link pointing to the disambiguation page Erki.

(Opt-out instructions.) --DPL bot (talk) 06:20, 20 January 2021 (UTC)[reply]

2021 Arbitration Committee elections is now open until 23:59 (UTC) on Monday, 6 December 2021. All eligible users are allowed to vote. Users with alternate accounts may only vote once. The topic bans, editing restrictions, and other measures needed to maintain our editing environment. The arbitration policy describes the Committee's roles and responsibilities in greater detail. If you wish to participate in the 2021 election, please review NoACEMM}} to your user talk page. MediaWiki message delivery (talk) 00:16, 23 November 2021 (UTC)[reply ]

Template:Party shading/purple has been nominated for deletion. You are invited to comment on the discussion at the entry on the Templates for discussion page. – Jonesey95 (talk) 07:53, 10 January 2022 (UTC)[reply]

Mellk (talk) 04:13, 14 April 2022 (UTC)[reply]

Disambiguation link notification for November 7

An automated process has detected that when you recently edited English Americans, you added a link pointing to the disambiguation page Anglia.

(Opt-out instructions.) --DPL bot (talk) 06:02, 7 November 2022 (UTC)[reply]

Disambiguation link notification for November 14

An automated process has detected that when you recently edited British Americans, you added a link pointing to the disambiguation page Anglia.

(Opt-out instructions.) --DPL bot (talk) 06:03, 14 November 2022 (UTC)[reply]

ArbCom 2022 Elections voter message

Notice

You have recently made edits related to Eastern Europe or the Balkans. This is a standard message to inform you that Eastern Europe or the Balkans is a designated contentious topic. This message does not imply that there are any issues with your editing. Contentious topics are the successor to the former discretionary sanctions system, which you may be aware of. For more information about the contentious topics system, please see

]

ArbCom 2023 Elections voter message

Disambiguation link notification for December 16

An automated process has detected that when you recently edited Roderick, you added a link pointing to the disambiguation page Rhydderch.

(Opt-out instructions.) --DPL bot (talk) 06:03, 16 December 2023 (UTC)[reply]

A tag has been placed on

.

If you think this page should not be deleted for this reason you may contest the nomination by visiting the page and removing the speedy deletion tag. Liz ^{Read! Talk!} 23:13, 4 April 2024 (UTC)[reply]