This is an archive of past discussions. Do not edit the contents of this page. If you wish to start a new discussion or revive an old one, please do so on the
current talk page.
I think so. Could you give me a link to the soon-to-be-obsolete version of what you want and your proposed name (URL) that you want me to create it under.
YBG (
talk)
23:14, 23 August 2017 (UTC)
I think I understand. You want me to fix the micro PT in your draft rewrite so that the colors show the new categorization. Is that right?
YBG (
talk)
23:30, 23 August 2017 (UTC)
Done It turned out to be fairly easy. I created alternate User:YBG/<t-name> versions of two templates, {{periodic table (micro)}} and {{periodic table (32 columns, micro)}}. These should be viewed as VERY tentative due to the fact that I've continued to use the current category names and simply changed H and N from "diatomic" to "polyatomic". But it does show the changed colors.
YBG (
talk)
06:10, 24 August 2017 (UTC)
Yesterday, an article I wrote,
history of aluminium, was promoted to the GA status. That made it eligible for being featured in DYK, and I
nominated it. Would you review the nomination? The information you may need can be found
here (directly on this page; a beginner's guide is linked there). This can be done by any user.
I want to get DYK off of my mind sooner because during the GA I was motivated to get this article featured and essentially, content-wise, I think we're there already. This could be done quickly. This is why I am hurrying the process by asking you. I'll be glad to return the favor in wharever way you want whenever you ask.--
R8R (
talk)
09:50, 27 November 2017 (UTC)
Oh well, this article made it through the waiting line faster than I had anticipated. Sorry for bothering then :) --
R8R (
talk)
22:26, 27 November 2017 (UTC)
@
R8R: Never a bother. I did briefly look at the review criteria, and quickly realized I needed to study the criteria and process more than I was able to devote right then, and before I got back to it, your 2nd message appeared. Congratulations!
YBG (
talk)
06:51, 28 November 2017 (UTC)
Thank you. Turns out there's another waiting line from there, and even after making it through, you'll still be in another preparation zone, so we'll have to wait for some time to have the article featured. Now, however, we're no longer in a hurry and I can edit at my leisure :) --
R8R (
talk)
14:58, 28 November 2017 (UTC)
Wikibreak
I have returned from my wikibreak, but expect my wiki presence to be less than it has been in the past. I have cleared my watchlist and am undecided what to do with it in the long run. 14:29, 19 April 2017 (UTC)
Providentially, I attempted my first post-wikibreak edit during the April 2017 cutover to the secondary servers and so the above edit was not saved and has been reconstructed with a hard-coded UTC time.
YBG (
talk)
14:34, 19 April 2017 (UTC)
Re nonmetals
Thank you for keeping our new vending room clean!
Please remember:
Personal items and dishware will be discarded if left in the vending room unattended.
The Microwave and Toaster Oven must be attended when in use.
No non metal items on top of the hot Toaster Oven
Enjoy!
The kitchenette at my place of work includes this sign. The third bullet regarding "non metal items" is most interesting with regard to
WP:ELEMENTS. I note that lithium, sodium or potassium are not prohibited atop the toaster oven; that of course would be much preferable to having them in the sink!
YBG (
talk)
18:00, 4 May 2017 (UTC)
Actually,
disposing small pieces of Li in cool wateris a perfectly legitimate procedure. ^_^ It is only inadvisable for Na, K, Rb, and Cs; for that you need to use the more reactive
isopropanol (and why dispose of the expensive Rb and Cs in the first place if you're not going to have fun with it?). I would still be slightly unhappy with the sink, but that is not so much about its structural integrity and more about the fact that you're pouring
lithium hydroxide down it. It is probably not going to be concentrated enough to do much, though.
Double sharp (
talk)
04:27, 13 July 2017 (UTC)
I don't really remember which ones they are, I just (vaguely) remember that I noticed some polyhedral with your name attached to them. At least I think so. I thought it included my favorite, the
26-hedron, either
with or
without metallic vertices and edges, but I see someone else did those.
YBG (
talk)
00:12, 13 September 2017 (UTC)
Thank you! By the way, I should note that the two pictures you linked of the 26-hedron are not actually the same polyhedron. One of them has squares opposite squares around the "equator" (the true
rhombicuboctahedron), while the other has squares opposite triangles (the
pseudorhombicuboctahedron). It's also possible to warp the vertices in just the right way for those faces to twist through each other while still being regular,
which I also illustrated. ^_^
Double sharp (
talk)
06:29, 13 September 2017 (UTC)
I was aware that those two "allotropes" existed, but wasn't looking closely enough to notice that the pics I linked to were not identical. Had I noticed, I would have snubbed the "pseudo" one. I "true", but both are really nice in that they have the same number of faces as there are letters in the English alphabet.
YBG (
talk)
08:39, 13 September 2017 (UTC)
There's an easy way to get the figure of 26 out, BTW: in the second picture you linked, the red faces line up nicely with the 6 faces of a cube, the yellow ones with the 8 vertices, and the blue ones with the 12 edges. You can explain all the Archimedeans this way as various "avatars" of the Platonic solids. ^_^ The situation with the uniform stars and the Kepler-Poinsots is a little more complicated but not essentially different, and as a bonus it goes up into higher dimensions in just the same fashion. ^_^
Double sharp (
talk)
08:54, 13 September 2017 (UTC)
In
User:YBG/PT groups, you use {{Periodic table (32 columns, micro)}} (18 times). Since that template took up too much processing time (exceeding parser limits) in one of the element articles (can remember which one; which had a dozen or so); they were commented out.
To reduce that template load size, I removed the option |mark=3 to mark group 3 elements. The marking now should be done by |mark=Sc,Y,La,Ac.
Because of this change, your subpage (using group numbers) does not show any markings any more. At the moment I don have time to take care of that, hope it does not disturb too much. -
DePiep (
talk)
15:58, 28 November 2017 (UTC)
Sorry, I meant to tell you that was the article. Is there any chance it could be restored? Would it help if there were a micro PT without the links?
YBG (
talk)
05:01, 30 November 2017 (UTC)
Discussion was
here at VPT. There were twenty micro PT's. I and others have tried to reduce load size a bit (eg rm this mark=groupnumber thing). Still it could be too large for twenty. Iḿ afraid it was caused by me when I changed the click-function per cell from a transparent image into full <div> controlled clicking (I thought more modern, but apparently also costlier).
We could re-add three PTs for main: metals/metalloids/nonmetals (should check for exceeding limits still). The other sevemnteen: research going back to the image-trick, or use other means like image-based PT. -
DePiep (
talk)
12:18, 30 November 2017 (UTC)
What about using a clickable pushpin-style map where the pushpins are shaped like boxes and the inputs are symbols or what-not instead of lat/long coordinates? Just a thought.
YBG (
talk)
16:06, 30 November 2017 (UTC)
@
Double sharp: re
special:diff/813191759, I have looked at it, and it looks interesting. But that page is trying to solve a different problem, to infer the correct pronunciation from the spelling of English words. That problem is, IMHO, much easier than the problem of trying to infer the correct spelling from the pronunciation of English words. But both are much much harder than the problem required by a respelling key, which is to figure out a way to spell all English syllables (or in our case, to spell all syllables in the element names) in a way that conforms to natural English spelling.
YBG (
talk)
05:13, 4 December 2017 (UTC)
Actually he tackles that near the end, under the heading "Spelling reform by regularization", including Ozymandias with his proposed spelling reform applied as a sample. But it does strike me that many of the element names are relatively unambiguously spelled already, and if you don't know those inference rules a respelling is not going to help. (As R8R mentions, lead is a major ambiguity; but that's vowel digraphs, which is really the problem in English spelling.) The ones that need help are truly a minority.
I just ran through them in my head, and the first metal that I think is really indefensibly spelt is technetium (which should really be spelt technecium to give the right English pronunciation; same with lutecium). (I guess niobium might also cause some confusion on which vowels are meant to be long; compare biology, which has the same stress pattern.) I think Noah Webster had it right for cesium; caesium obfuscates the softening of the c. Even praseodymium isn't hard once you work out where the stress goes. Indeed I think it might be harder to say it then to figure out how to say it.
The bulk of the problem seems to be with the ancient metals and the less regular nonmetals. Iron and lead you surely know about already. The halogen ending -ine is a tricky one. It looks like it should have a long i, like serpentine. But then again we also have latrine with a short i. I think it's just the alternating stress; I want to say fluorine, chlorine, and bromine with a short i and iodine, astatine, and tennessine with a long i. The reduction of final -on is also a bit unpredictable: for me, boron and carbon do not rhyme. I usually pronounce neon, argon, krypton, xenon, radon, and oganesson like boron, but silicon like carbon. I am not very sure how to signal this unexpected lack of reduction in the spelling.
The synthetic elements are problematic, but this is mostly because of borrowing. Berkelium has a weird short second e, and seaborgium inherits the ambiguity of English ea (the morpheme boundary should adequately signal the non-softening of the g), but the real problem comes with things like einsteinium (which needs a German interpretation of ei), dubnium (in my dialect u only takes this value in native English words after a labial, viz. pull vs. dull), bohrium (which is R8R's problem with gohld as a respelling), meitnerium (German ei again), darmstadtium (for which you need to read Darmstadt as German), and roentgenium (where the oe is trying to be an o-umlaut, and g is not softened).
Actually I am not sure if these borrowings are completely English; I pronounce roentgen as a German word anyway. And I do the same in music for Haydn, Mozart, Beethoven and all those composer names, as well as terms like Lied and Singspiel (for me, their plurals are Lieder and Singspiele). But somehow English suffixes are productive here: I don't find anything odd about Mozartian and Beethovenian! Or indeed Bachian, even though English does not have the ach-Laut, outside Scotland! So I think that some of these element names, taking Einstein, Meitner, and Röntgen as their eponyms, are rather including a bit of German into English, and need to be judged by German rather than English spelling conventions; but then why doesn't Einstein have /ʃ/?
To all my talk-page-watchers and other assorted geeky WP friends, here's a seasonally themed puzzle: In the song
the 12 days of Christmas, the singer's true love gives:
On the 1st day, a partridge in a pear tree (considered as one gift)
On the 2nd day, 2 turtle doves and a partridge in a pear tree (making 3 gifts that day, for a total of 4)
On the 3rd day, 3 French hens, 2 doves and 1 bird in a tree (making 6 gifts that day, for a total of 10)
In all 12 days, how many gifts are given? (click "show" to get multiple choice)
No, that's the number of delivery trucks, assuming the 12th day gifts all fit into a single vehicle.
(c) 78
Click "show" to see if this is the correct answer
No, that's the total number of gifts received on the 12th day: 1+2+3+4+5+6+7+8+9+10+11+12.
(d) 364
Click "show" to see if this is the correct answer
Yes, that's right. Enough gifts for every day except December 25th (and February 29th).
(c)1365
Click "show" to see if this is the correct answer
No, that's how many there would be in 12 years of Christmases, assuming there was just 1 day of Christmas in the 1st year, 2 days of Christmas in the 2nd year, 3 days of Christmas in the 3rd year, and so on until 12 days of Christmas in the 12th year.
If you don't have plans to fix them in the near future, perhaps you wouldn't mind doing something to disable whatever is causing the errors, or I could do that. Thanks.
Johnuniq (
talk)
09:12, 16 May 2018 (UTC)
This discussion was copied here from
User talk:YBG/sandbox so that I can archive it in my regular talk page archives. The headings levels were increased so that it all comes under this one header.
YBG (
talk)
04:18, 27 October 2018 (UTC)
tests
The number of presidents alive at each moment in United States history
00Numbers in boxes indicate the order of presidential service and are linked to the article about the president.
Changes are indicated by icons for increases due to inaugurations and icons for decreases due to deaths.
00Numbers in boxes indicate the order of presidential service and are linked to the article about the president.
To consider/done
Wait wait. So every From line is an exact repetition of the previous To-line. That is not good. And of course the event dates are repeated. Nice puzzle. -
DePiep (
talk)
18:52, 24 February 2017 (UTC)
Done: Show explanatory rows (using table !, |-, and |). Add class=unsort for bottom row (added row), shows it does not sort. Some text changes, visible. Unbold From and To. A try: last column to sort on 1st name mentioned, not date (or: name of sitting pres?). Added: collapsible (which has no effect in mobile view ever, keep in mind)
Is the nowrap really necessary, and everywhere? You are forcing the table to be wider than the page (hor scrolling needed, even on my regular desktop screen).
Changed: somehow I turned it off. Now the dates are breaking -- looks less good.
I have set font-size overall to 90%, which is acceptable in a table or infobox (because has more structured layout compared with text lines).
.... but: we cannot stack font-size % (they multiply), so I removed "font-size:85%;"
Todo: check mobile view (for example, see very last link at bottom of this page).
Using {{unbulleted list}} in From/To-column, instead of <br>.
{{unbulleted list|1=From:...|2=To:...}}. Should be full cell content (no text outside this list).
This is nearly invisible, but it gives better HTML code: a true list (something with <ul>). Whitespace changes, but this is as the WP design is for lists. Bonus: check the effect in mobile view: linebreaking was wrong there (it had overlapping texts with me).
Added text in [[File|+, - |12px|Number increased/decreased]] (tooltip aka image title)
Replace 'Washington 01' with 'Washington 1' or simply '... 1'? Has bad sort effects?
Formally, a number box only should be linked once (at first appearance; inauguration?). 43. Unfortunately, Rbox does not have this option?{{Rbox}} can. See doc, about param 1 and 2.
About the number-colours
We need at least 7 distinct colors (max VP number). To check: maybe nos 1 and 8 can overlap (live together), while numbers in between are gone! I'd say 9. (but too much would reduce their main function of distinction (recognition). Current Pres list has 10.
checked. See VPs Jan 20, 1993: list spanning 9 numbers, so we need 9 colors minimum.
Current colours are too strong. They are only background colors! They require switching from black to white fonts, which indicates possibly bad contrast (
WP:ACCESS, risk of bad visibility; that could be checked by a calculation -- not now). Sad! I'll restart from scratch.
We need lighter tones. That can be set (calculated) by
HSV color space: H=hue number (we choose, 9x); and use the same S-V values for each (the color is now defined), and convert HSV to #RGB triplet. So a color would be defined as: H=90°-S=15%-V=95%.
Approach: we pick 9 hues (what we call 'colors', irrespective of their brightness and tone etc.). They are have a number from 0-360 (degrees).
These are 9 hues
From the rainbow. From that table, we use the third column (Hue + Saturation 15% + Brightness 95%, these HSV values are already converted into #RGB).
The new colors above have this issue: neighbors look too much alike. That's because it nicely follows the color circle. But we prefer more alternating neighboring colors. (not: red-orange-yellow, but: red-blue-orange-purple). We do so by reordering the color list. After each color, the 'most opposing color' (hue) follows, by H=+160deg. So: 1=0, 2=160, 3=320, 4=480 (=120) etc.
(Note to YBG: here I finally found this solution for our -todo- periodic table categories-coloring!!! 'most opposing color'. And: it is even circular too, so OK when going over 360 deg! that is: across noble gasses, like in Janet's left step :-) ) -
DePiep (
talk)
11:19, 24 February 2017 (UTC)
Considerations
For now, I suggest using these colors. #RGB number is in code. But minor improvement might be possible (see below).
I don't think Wikipedia explodes if you use your original colorful tables right away, and later replace them with new colros so you have time to edit. No problem
Main achievements
The
WP:ACCESS color contrast is OK (font-on-background readability). This is such a huge issue Wiki-wide (that's WMF), that this failing alone could invalidate a whole table.
The page is more at rest for the eye. No strong background colors any more (grabbing attention for no reason), no extra switches like font-white & font-black, all background colors in one tone and all fonts are in black.
color still supports the number, and has no individual meaning (good design).
issue/to look at
The {{Rbox}}does allow for unlinked text yet (param 2 blank, see doc). todo, not overlinking.
Colors are not that "bright" any more. For the author (editor) that could be a drawback, but understand that for the Reader it is an improvement.
Font is black, not wikilink-blue. Acceptable imo.
Looked at mobile view. No issues seen.
Well, going from 10 to 9 makes search-and-replace not that useful... I say: it's worth it.
Tweaking possible: the colors could be a bit more bright (more reddish, say)? For that, we'd have to pick a new ...-S-V setting that does that, while still keeping the contrast ok (w3c rules). That's a tough exercise.
This is the problem with the table structure. It is a timeline, with events (moments, day 20 Jan 1924) and periods (intervals, 7 years). These should not be in one row, but (ideally) below each other. I'll try to come up with an improvement. -
DePiep (
talk)
19:07, 24 February 2017 (UTC)
Here we are.
Table setup
Events numbered 1-3-5-..., Periods numbered 2-4-6-...
event (2 cols)
period (2 cols)
Event
E x
Period
P z
E1
E1x
P0 (blank, start filler)
P2
P2z
E3
E3x
P4
P4x
E5
E5x
P99 (blank, end filler)
Changes wrt current table:
Events go left: date, reason (inauguration, death).
Periods go right: timnespan 'yrs', number of press
One can split the events (as is done now: date and +/- columns are not next together). I do advise not to want that.
Yes it would be a big and difficult and precise move of data (for 100 main rows Pres+VP). Pls think about if & how to proceed. If you like this (for now), I have time.
Here's YBG's attempt to catalog and respond to DePiep's ideas, indicating which have been incorporated in the table I've just revised. If I've missed any, let me know. If you want to discuss any of these points, it might be best to start a new section rather than trying to start a threaded discussion in this table.
The list below began single hierarchical bulleted list, but it has been reformatted into sub-sections for ease of editing. Unmarked items below are generally YBG's initial comments. Responses are indicated by icon: Comment. by DePiep and Note: by YBG.
YBG (
talk) 16:
56:42, 2 February 2017 (UTC)
General table format
Table headers and footers
Done - Legend: Change from |+ to colspan=all and trim verbage. — I also combined the two legend lines
Done - Footer: Add table footer — I used ! instead of sortbottom and also added column labels
Comment. Maybe no bottom repetition? Its not that complicated a legend, so readers can remember. I just wanted to illustrate how to don't-sort-this-row. -
DePiep (
talk)
10:43, 25 February 2017 (UTC)
Formatting of table as a whole
Done - Font: Reduce font size
Done - Collapse: Make table collapsible
Later - table markup: One-line-per-cell instead of one-line-per-row
One line per cell interferes with my workflow - storing the wikimarkup in a 29-column sortable MS-Word table with a hidden sort field so I can sort and edit the data and paste it directly into WP. My latest version doesn't strip the tabs &c so you can see what I mean. This facilitates rapid reorganization. But I expect to use one line per cell when moving to article space.
Comment. Not needed. Just easier when I was doing manual editing, keeping overview. Maybe the final version could be made more eye-friendly.
Formatting of specific elements
Comments about changes affecting a single type of visual item
Doing... - Icons: Tooltips in the +/- icons
Question: Tooltips in every row or just the legend rows? Is it really needed with my even terser legend?
Comment. I'd say: with every image. Helpful when a reader is halfway the list and hoovering. Also good for non-image viewers (text readers, as used by blind people).
Comment. ? I don't understand. Not a textual "+" (keep using the files), but a title with the File. That title shows for example when you hoover a mouse over it, and for example when someone does not have the image (so they get the title text instead). Much better than seeing the filename. Must say, there is no need to have them 'stand out'. They are not the main info. -
DePiep (
talk)
23:55, 25 February 2017 (UTC)
I see you use {{abbr}} now but that is bad. Abbr is for - well, abbreviations only, not for helptexts or so. How seductive it is. (W3C, and WP follows, is very strong about good semantics). So: use those +/- files, add titletext (in the [[File:..|12px|title]] as I showed) everywhere, drop the {{abbr}}. -
DePiep (
talk)
23:55, 25 February 2017 (UTC)
Note: OK, I'll go back to the graphical +/- and see about a better solution for their ugliness in mobile view.
YBG (
talk)
00:23, 26 February 2017 (UTC)
Note: Will do. Turns out it seems to be a subtle bug in the mobile view, which I have documented and reported
here. And have a look at the version numbers. I'm really quite fast when I put my mind to it.
YBG (
talk)
01:59, 26 February 2017 (UTC)
Done - Initial zeros: Eliminate them — Planned to do this but forgot. {{0}} is very helpful
Done - Redundant pipelinks: Change X|X to X — Maybe undo some to condense names, e.g., J. Q. Adams instead of John Quincy Adams.
Done - List: use {{ubl}} instead of <br> — I also used {{ubl}} for dates, to save some horizontal real estate.
Done - From/To/and: No bold/italic
Question: Is the vertical alignment using {{0}} an improvement?
Comment. I see nothing wrong, nor can I remember the previous situation. Today each cell has good vert alignment (vertically centered). Date positions great too, esp when there are three facts. Whitespace per cell may be an issue (as said, very much ws in mobile view. cellspacing=0? cellpadding=0?). If you mean the positioning of the single digit 1-9 numbers (their hor positioning then): go as you like. Right-aligned and center-aligned both OK.
Comment. no, always a bad habit to do layout with space-counting like in {{nbsp|19}}and: (Tyler, #10). (Same as <br> for listmaking). Does simple ":" (colon at newline) work? (I see {{Indent}} works with spaces too; best be would some <span style="..."> setting. But that's tooo perfect for this). Next: as it is now, with 19! spaces, it looks extremely irregular, and therefor ugly. I'd start with 1 or 2 spaces, just an indent below the "To:" is enough for the eye. (Ideally, one would vert align the visible colon...). -
DePiep (
talk)
00:09, 26 February 2017 (UTC)
Note: Agree, it is pretty ugly and space counting is also. But if the alignment problem is fixed, what do you think about putting the date before the link-to-the-event?
YBG (
talk)
00:28, 26 February 2017 (UTC)
Comment. That order is very good. I personally would go for separate columns (without a border between), so that the events (ianaug links) align nicely. Also helps/solves the and:-indenting. Maybe even, how would it look: 1. +/- col, 2. date col, 3. event col? Just out of the box. Very minor from here btw.
DePiep (
talk)
01:06, 26 February 2017 (UTC)
Done - DAB: TR’s and LBJ’s presidential inaugurations
Question: Do any other inaugurations need an added ordinal?
Comment. No more DAB links present. (With me, links to a DAB page are orange - a Preference set). OTOH, the ordinal 1st with George Washington has no follow-up with his 2nd. Logically sound, but I had to think about that when reading (it caught my eye).
Declined - Linking: Reduce overlinking in table
The
MOSallows overlinking in tables. IMHO it desireable in tables, especially sortable ones. In this case, the link maps the number to the officeholder, serving as a legend, which is especially important when the table is sorted.
Comment. Nihil obstat.
Comment.Mobile views: Nothing broken. Looks good in general. The 3-line cells (dates) work out well.
I looked at both fullscreen (by bottom-of-page link), and smallscreen view (a tab option I have set; in a smartphone-image). Notes:
In the legends top and bottom: the + and - images align left not next to their text. Maybe all three texts to left-align?
Should work for the whole table (all cells) at once. Dunno if it is kept in mobile view. Don't know how else to do, or one should style each cell individually (like padding:0 border:1px). Probably that {{unbulleted list}} adds extra outer whitespace. You know what padding/border/margin are/do btw? -
DePiep (
talk)
00:18, 26 February 2017 (UTC)
Note: As I view the mobile view, it seems to be adding extra whitespace between the list items. I am familiar with padding/border/margin ... but have to look them up every time I use them and then figure out how to translate w3 documentation into wiki markup.
YBG (
talk)
00:37, 26 February 2017 (UTC)
Comment. In general: well done, picked up nicely from my single pile of changes. I just made notes & suggestions so far (one-way; for use or discard), not issues to be discussed. -
DePiep (
talk)
10:43, 25 February 2017 (UTC)
More complex issues
These are changes that by their nature may require research and/or discussion.
Declined - Periods/events
The repetition bothers me also. The version in article space avoids this by having no event column and wikilinking the dates. An earlier version showed only the starting event. But both events are needed for context when the table is sorted. I'd already played around with period/event staggering and gave up on it because it gets ugly when the table is sorted. Bottom line: if the table is unsorted, I would stagger periods and events as you suggest. But I'm not willing to give up sorting. Maybe there would be a fancy way to use collapsing to give the reader an option of a sortable table with repeated events or an unsortable one with staggering that avoids repetition.
Comment. Do not spend time on any 'smart collapse' route. Collapse does not exist in mobile view, so there is no solution in there. Agree sorting must be kept, but
my demo (sorting added) does make a sensible show. When sorted, it nicely replicates each split row (so any From-date becomes a second, To-date cell etc.). Not looking very elegant (now), but is is correct. I state that the full repetition as it is now is ugly and bad. (And making the table ~twice as long). An improvement is needed in this.
Note: Consider the 'dumb collapse' idea to be
DOA. For now, I'll go with sorting-repetition-unstaggered. But if you figure out a clever way to have both staggering and sorting, I'd be very interested.
YBG (
talk)
17:55, 25 February 2017 (UTC)
My reordering is different from the one you suggested with staggering events and periods. I kept the event column immediately to the right of the list column so that the event column can function as a legend for the list column, at least when the table is sorted chronologically: just scan up to the inauguration or down to the death. I have further considered moving the date column to be between From/To and the event link, so it reads (e.g.) -[02] From: Jul 4, 1826
Death of John Adams. Reorganizing columns like this is very easy with my offline storage of wikimarkup.
Question: Which do you think would be best: the original column order (Dates-Span-Lists-Events), the current order (Lists-Events-Dates-Span) or a revised version which inserts the dates between From/To and the event link?
Comment. Yes, great column ordering. More natural flow left-to-right. Merging the date into one cell looks fine. But you'll miss the option to sort by date or by pres name (can have only one in a column). BTW now too because of the shared columnheader. Did you consider to somehow sort by pres name?
Answer: I prefer current order, keep separate column for the dates (for sort reasons, so separate header cell, could be empty why not). The +/- column best sorts by pres name. Yes swapping columns +/- and date (date as 2nd col) is even better, for reading logic & expectation IMO. -
DePiep (
talk)
11:16, 25 February 2017 (UTC)
Note: I've moved the dates into the event column and gave up trying to align the colons. Could still do it with {{0}} if it has merit.
YBG (
talk)
18:52, 25 February 2017 (UTC)
Comment. This is my note below. My guide would be: how does a Reader read/glance a table? (really, glancing is half the reading, it's not that superfluous as it sounds. That's why we do layout & structure). That is: top-down, left-to right. So e.g. a row should show interest-logic like: main fact - background - cause (or so). -
DePiep (
talk)
02:49, 26 February 2017 (UTC)
This is one of DePiep's suggestions I forgot to include in my initial listing (are there others?). I don't think sorting by presidents is very helpful. I
once tried to implement a scheme with not only sorting-by-person (actually, by order-of-service) but also sorting-by-event-type. Which person is best associated with a row: the beginning-event-person or the ending-event person? And what to do about the eight instances of mid-term succession when there are two presidents associated with an event? (This wasn't an issue with sort-by-order-of-service.) At any event (pun intended), other wiser heads prevailed in the collaboration and convinced me simpler is better, so I abandoned the idea of sorting by person.
YBG (
talk)
17:55, 25 February 2017 (UTC)
Comment. I'd say: the core events column ("inaug of X") could sort on sitting pres name. That's all. Isn't that something one expects to find? How else would one discover that there were two Clintons already? -
DePiep (
talk)
02:34, 26 February 2017 (UTC)
Note: To find common last names, that info, you'd look at one of the other, simpler list of the Presidents or VPs. The main table isn't sortable, so you'd have to look at another one from {{Lists of US Presidents and Vice Presidents}}, say the first one,
List of presidents of the United States by age. But even that wouldn't help you because the older Clinton was a VP, not a President. Here's a list of the shared last names: Adams (V+P father, P son); Bush (V+P father, P son); Clinton (V, P, no relation); Harrison (P grandfather, P grandson); Johnson (V, V+P, V+P, all no relation); Roosevelt(V+P, P, cousins); Wilson (V, P, no relation). Almost certainly not a notable stand-alone list. And while we're talking about non-notable trivia, the most interesting factoid I've come upon recently is that in 1961, Richard Nixon, the 36th vice president, was succeeded by Lyndon Johnson as the 37th vice president. Upon Kennedy's death, Johnson had became the 36th president, and in 1969 Nixon returned the favor by following Johnson as the 37th president.
YBG (
talk)
03:55, 26 February 2017 (UTC)
Later - Colors
As you probably guessed, my choice of 10 colorings was driven by the ease of grepping the change. But a bigger reason (IMO) why the alternating 360/(2n+1) doesn't work well is that the lists frequently include non-consecutive numbers. There are 81 deltas of two, 23 of three, 10 of four, and even 1 each of five (Presidents 13 & 8, Filmore & Van Buren), six (VPs 28 & 22, Marshall & Hamlin) and seven (VPs 22 & 15, Morton & Hamlin). Also notice how close VPs 36 and 46 (Nixon and Cheney) are in the VP event column - there is only one cell between them! Separation here is important so that the event column can function as a legend for the list column. For these reasons, I don't think the 360/(2n+1) system will work well here - but I believe it holds promise for the periodic table.
Additional information neededYour further thoughts re color given these concerns would be much appreciated.
Comment. We could look for 10 colors not 9. But more colors absolutely implies that they are closer together (36 deg instead of 40 deg): less discernable, bad for their legend function. More so since I want to go to the softer backgrounds: less bright colors means less outspoken 'red' etc. (Also, I'd have to calculate #RGB from the 36 deg steps, while the 40's were available. For now, I am not pondering making your grep s&r easier ;-) ).
I note that the alternating order is just an improvement once a color set is chosen. It is a free improvement: it does not reduce degrees of freedom in color picking! I agree that the numbers do not always happen in their perfect sequence, so the alternating trick does not come out always. But still, the colors must be distinct enough to do their function anyway, even when neighbours neighbour (two near similar colors nearby each other). If this is not working ok, in whichever color order, the color set itself is bad (it fails).
Let's keep in mind: the current strong colors are not a good design (I hope you can agree). Also, the colors are just supportive: the number itself is the ID. The table could do without colors without losing information! And the flip side is: any reasonable color set could be OK, there is some leeway.
So, we must find colors as much apart as possible (9 is better than 10), try to improve brightness without breaking contrast rules (todo), and shuffle them anyway to help distinction for free.
Note: No argument from me as far as brightness goes. It was when I was unsuccessfully messing with RBG values that I thought to
call in the DePiep cavalry. Having decided to do that, I just grabbed a convenient set of HTML color names and called it good-for-now. But I turned 5 or 6 hues into 10 combos by using a second dimension, text-color plus brightness/darkness. What about using font color or the presence/absence of a black border to turn five hues into ten combos? This is an option we don't have in the PT where the border is already used to indicate natural occurrence and the font color for state of matter.
YBG (
talk)
17:55, 25 February 2017 (UTC)
Comment. End of the day: of course these two tables are fit for mainspace (take care they won't be AfD'ed...). I have not checked other comments elsewhere. Any remaining topics (big: do not repeat lines, not those flashing colors, ideal column setup), all can be solved/improved
I have added two sets from
http://colorbrewer2.org,
CB1 and
CB2. CB2a is the same as CB2 but with the darker gray from CB1, which looks like it will work better with the wikitable background. I may not get to it for a few days, but I hope to implement CB2a and see what the resulting table looks like.
YBG (
talk)
04:29, 27 February 2017 (UTC)
Replies. When unclear, ask. I often check at
[1], the w3c css (style) definition. You can skip the red notice. I can check two screens for mobile view (smartphone upright and desktop).
Styles & white/spaces
styles: trivial, fyi: nowrap in tablestyle is equal to style="white-space:nowrap;" in css.
Nowrap in mobile view (smartphone): the events (inaug, death) wrap lines, so the table is extra long. Undesired imo. Some recent change (has todo with change width:100%;? nowrap does not work?).
Desktop view: whitespace between From and To-lines disappeared (two numberboxes glued together). Too tight? (A: Yes. The 2nd box is overlapping the 1st box always, the colors show).
What is does "line-height:1.6;"? It's legal, but I don't exactly know what value is set. Sometimes I try using em size, like: "line-height:1.5em;". However, with this other effects can have an effect.
In the multi-line cells, try: 'style="padding:0 2px 0 2px;'. (padding=surrounding whitespace in the cell, between text and border. The 4 numbers are for -top, -right, -bottom, -left respectively. (So this reduces top/bottom ws). And/or: the {{ubl}} could have a 'style="margin:0.2em;"' (margin=outside ws outside of the box; here it overlaps/isaddedto the cell padding). Effect setting it to 0?
In general, you are squeezing to much in the wrong places. (Once you have chosen to keep the repetition of To-lines, you'll have to accept some consequences such as extra ws).
Colors
The new colors are great, and what I was looking for (well, thinking of). CB is great. Later on I might as which CB-options you have used. One question: did CD really add a grey, #9? It is a bit out of the line. (and #7 brown?)
You could allow a manual change: the CB-2a #6 yellow is light, could be CB-1a #2 yellow? (because yellow is so light by itself somehow, I would take designers freedom to tweak it after the CB outcome).
I have not checked the colors in detail. I'd like to learn (from CB?) eg like whether #7 brown is acceptable (is not a rainbow color...). And why no two greens are acceptable.
VP36-VP45: trick: from VP45 to VP48 (end) skip color #9 grey! (so sequence is: VP43=cb7, VP44=cb8, VP45=cb9 cb1!, VP46=cb2, .... -
DePiep (
talk)
09:10, 1 March 2017 (UTC)
line-height:1.6 was just an effort to unto the table-wide application of line-height:1.2 which is what made the from/to boxes overlap. Probably should use "em". And the "1.2" should maybe be bigger.
I've included direct colorbrewer links above so you can see for yourself what the brew meister produced. CB1, CB1a and CB2 are direct from Colorbrewer. CB2a has a hand-modified darker gray.
Regarding 8 years 0 days, that's what the template produces. I'll check if there's an option, but I'd prefer to avoid hard coding it.
re '8 years, 0 days': see
this, the reply by Jimp: he wants the zero kept b/c of precision noting. A good point, more so because this topic returns often at {{
convert}} (
talk), and usually Jimp is one of the stabilising editors in there. -
DePiep (
talk)
09:33, 2 March 2017 (UTC)
you: Note: As I view the mobile view, it seems to be adding extra whitespace between the list items. I am familiar with padding/border/margin ... but have to look them up every time I use them and then figure out how to translate w3 documentation into wiki markup.
My re now: very strange! Maybe: 'adding extra whitespace between the list items' - set by line-height in {{ubl}}, separately? Or do they interact (if they do, research is very difficult, better leave it). -
DePiep (
talk)
09:22, 1 March 2017 (UTC)
More Q&A
Just an idea: write "Gerald Ford inaugurated", "Richard Nixon dies/d" (linked). Could save five letters per line! Plus: helps the reader who will be name-searching foremost, if anything. -
DePiep (
talk)
11:12, 1 March 2017 (UTC)
To show that we are not amateurs: there is a rationale for making color#6 yellow darker than cb-calculated/advised at first. That is: the colors must also stand out against the background (a very light grey). I don't know about a w3c contrast rule for this (as exists about font-bg contrast). btw, each new color column is an improvement, so the rightmost is best, imo. -
DePiep (
talk)
10:00, 3 March 2017 (UTC)
Allow me to repeat the "VP36-VP45" note by me above, for your attention. Could be useful, you might have missed it (you usually respond). -
DePiep (
talk)
10:07, 3 March 2017 (UTC)
Very late, but please consider. About the order of columns. When thinking about natural reading order in a row, I'd expect this order:
1. start+end events, 2. time span, 3. living presidents.
That is, the order shows "what happened, and what is the result". (Technically, only column #1 moves to position #3). -
DePiep (
talk)
10:13, 3 March 2017 (UTC)
Thanks for being more clear. I took your comment into consideration in my most recent rearrangement, but I didn't completely understand what you were aiming at. I'm strongly inclined to keep the list relatively close to the colorboxes in the event column, but having said that, I will give it some more thought. As that rearrangement is relatively easy for me to accomplish in my off-line source file, I don't mind taking some time to think about it. One other reason for putting that column first is that it is the subject of the table. This may have contributed to the AfD comment "the time period in which a former president is living has not been discussed in RS" since with the time period first it seems like the time period is the subject of the table, when in fact the number of living Presidents is the subject. This probably isn't a real good reason, because in fact most tables begin with
key (database) columns.
YBG (
talk)
21:27, 3 March 2017 (UTC)
re for being more clear - you c/should have asked ;-) ;-)
re ... it is the subject of the table -- not exactly. It is the subject of the article. The table is just to illustrate/explain/prove the article. And also, the last column is not behind the other side of the moon.
re 'database key first' -- in our world yes, but not for the Reader!
re AFD: no comment.
re: pres name search & sort: later more. (I still don't get why you think name-search is irrelevant. Must reread your posts here).
Re being more clear - the problem was that I thought I completely understood, but in fact I did not. Sigh.
YBG (
talk)
02:07, 4 March 2017 (UTC)
Re name search - the problem is which name to use? The one whose event started the period? Or the one whose event ended the period? And keep in mind that some periods begin and end with inaugurations and some begin and end with deaths and some begin with one and end with the other. So we can't go with sorting by the name of the president inaugurated. Sorting by incumbent's name would seem weird to me without a column that gives that President's name (and all we need is another column). It would line up the colored boxes that begin each line, but I still think it would be far from obvious what is going on.
YBG (
talk)
02:07, 4 March 2017 (UTC)
First, this sorting is not essential here (date is, and sitting pres by numberbox is; already covered). It would need its own columnheader (column to split). Then, an event could sort informatively by the family name of the From-event. It would group the career events by name. That's all, but it is something. -
DePiep (
talk)
14:27, 4 March 2017 (UTC)
On the subject of the AfD, there are a number of reasons why this list doesn't have anything equivalent to the UK's interregnums or regencies. If you are interested, let me know and I'll be happy do discuss it here or on one of our talk pages.
YBG (
talk)
21:27, 3 March 2017 (UTC)
Here's what I see needs to be done, in rough to-do order.
Get the spacing right on the multi-row cells
Figure out how to insert line breaks into the wiki markup in the appropriate places so it is actually possible for someone other than me to do some editing
We do freeze color development. Good. Stop spending time. It's OK.
Put them live asap. They are better that today's. Comments are welcome.
You look at VP36/45 color solution. Solve or note an issue.
Column order: you choose smartly & we'll stick to it.
So by now the tables are live. (Did you consider transcluding them, once, from template space? Want advice ;-) ?).
Only this. You mention whitespace (ws) issues, which I did not spend much time on so far. I'll take a further look, also in mobile views. For now: ws not deadly, so you can put them live. -
DePiep (
talk)
22:23, 3 March 2017 (UTC)
re 'ease of maintenance by editors', vs your offline spreadsheet: maybe create a subtemplate that formats a complete row (parameters suggestion -very rough-: eventTo, eventTo2, eventFrom, eventFrom2, date1, date2, event1, ewvent2, event3, pres-alive-list). For
this table template I added
this subtemplate/row-formatter. -
DePiep (
talk)
22:41, 3 March 2017 (UTC)
Let me think on these things. One of the reasons I'm not being very bold is that my previous effort with this article was premature and got shot down my a number of other editors. So I'm trying to be a bit slower now.
YBG (
talk)
02:07, 4 March 2017 (UTC)
Column order. I started with your Events-Span-List and tweaked it a bit, including the order of the event subcolumns. The result, Event(Date/Event/Change)-List-Span, keeps the two columns with boxes proximate to each other.
Line spacing. Turns out that "em" is understood when there is no modifier. I did increase it from 1.3 to 1.4, so now there is a small gap between the boxes.
Re line spacing: with me, regular desktop at 100%: no vert whitespace between two number boxes in event column. There could be a tiny overlap even (1px?). When at 110%, there is ws OK.
Found a typo in the header, probably not in the spreadsheet (see diff).
Tried: ubl|item_style=text-align:right|Apr 21, 1789|Mar 4, 1797 for dates (done in first row in VP table). To right-align the years. Not sure if that's much better. -
DePiep (
talk)
10:05, 4 March 2017 (UTC)
I've removed the line-height. I mistakenly thought it was fixing the ws problem in mobile view. Spacing is acceptable in desktop, but I would like to fix it in mobile. IIRC, an earlier version had fixed (or at least improved) mobile spacing by inserting a style int each and every {{ubl}}. The line-heights in the table header and was an attempt to do the same thing with fewer chars, but it didn't work. I'll go back to putting it in the ubl.
YBG (
talk)
13:50, 4 March 2017 (UTC)
Excessive ws in mobile. One cause found: the column "+/- numberbox" is split over into two rows. Cure: use {{nowrap}} in the widest situation (#48 Pence)
[2]. (The nowrap with #1 is useless). Result: no split lines there any more (with me). -
DePiep (
talk)
14:19, 4 March 2017 (UTC)
Next: the line with 7 VP numbers breaks. Add a nowrap there too?
You'll see the same: cell.style is nice in mobile, but bad in desktop. Best are 1.35em (and 1.3em). But you'll have seen that already. -
DePiep (
talk)
14:53, 4 March 2017 (UTC)
Yea, I'd seen that in desktop - and thought it might be best in mobile, but didn't actually check until after reading your comment. I'd still like to reduce the vertical ws in mobile view. Any ideas?
YBG (
talk)
15:01, 4 March 2017 (UTC)
The 1.35 setting has been implemented. Now if we can figure a way to reduce the mobile spacing, I think we're good to go. By "good to go", I mean ready to post an announcement on the article's talk page and then wait couple of days and then move to article space.
YBG (
talk)
16:15, 4 March 2017 (UTC)
The 1.35em setting looks a bit border-penduling. In desktop, sometimes I see no ws, sometimes 1px ws (in
#Further refinement below: leftmost col, between #1-#2: 1px, between #2-#3: 0 ws). Also, in the VP and Pres tables I see no ws at all (color number boxes glued together, or even 1px overlap). Maybe 1.4em to be sure? (1.4em this also alters randomly by a 1px, but at least there is ws always).
{{ubl}} is core HTML coding, true <ul> lists etcetera. I was often helped by User:Edokter, who did lots of coding in there (css, HTML, padding, margin; enwiki level). Maybe he can suggest on how to handle that mobile ws in there. Have a nice edit. -
DePiep (
talk)
19:31, 4 March 2017 (UTC)
(ec) Wow. I only just saw those lots of previous remarks over at that talkpage (thanks for pinging me there). So when this goes live people would make many arguable edits in the list (making the spreadsheet ~useless)? Maybe invite-ping all those 2 dozen of people now, before, to comment on your sandbox proposal? -
DePiep (
talk)
21:33, 4 March 2017 (UTC)
Done. Most of those people pinged never contributed to the discussion. Those who did contribute I believe are likely to agree with AuH20 in thinking our new version is an improvement. At least that's my hope.
YBG (
talk)
21:59, 4 March 2017 (UTC)
re mobile ws, consider this. Lists like {{ubl}} are very very well designed for wp pages and by w3c standards, using core HTML. These people also took care of the mobile view. Now if we see no broken effects, we can trust that the effects we see are by design. They have reasons to make it show this way, even if we don't understand. Let's trust them. It's OK. -
DePiep (
talk)
22:18, 4 March 2017 (UTC)
I've modified the examples above, puting each in its own single-cell wikitable. From this I see that the mobile view, even unmodifed, the between-item spacing is much, much bigger than the outside-list spacing. This doesn't seem right to me, but I guess I'll go with you and defer to the mobile view designers. Thanks again for your invaluable input in this effort.
YBG (
talk)
01:07, 5 March 2017 (UTC)
Thanks, nice way of working. Did you consider putting them in a template each (transcluded once)? One benefit is that it nicely allows sandboxing, since so many people have ideas in this. -
DePiep (
talk)
16:10, 5 March 2017 (UTC)
Right, I should have known that. I'll figure out appropriate template names and move those subpages into template space before changing the article.
YBG (
talk)
06:44, 6 March 2017 (UTC)
Change section title into "List of living Presidents". Remove most of intro text (belongs in Statistics section anyway). Maybe move Statistics section right below List section (Gallery downwards); keep as section.
Intended effect: in mobile view, the list is not collapsed. However, the Section is! So the mobile reader can easily collapse/uncollapse the table! Long intro text should be avoided, to visually get to the list asap. -
DePiep (
talk)
09:15, 7 March 2017 (UTC)
This is something we missed: both lists start with #1=red. As we wanted, using colors signifies: "same color=related". Especially since the lists are in one article, we now have declared #1-VP connected to the #1-Pres! That is bad. We should have started the VP's with like, #1=color4, then cyclic as usual. -
DePiep (
talk)
09:51, 7 March 2017 (UTC)
Not a problem IMO. We have many instances of the same color being not related, e.g., VP1 and VP10 are the same color but not related.
YBG (
talk)
22:14, 7 March 2017 (UTC)
There's a problem with collapsing. My intent is to have it collapsed on the template page so that the documentation shows up without scrolling, but have it start uncollapsed elsewhere, but I don't seem to be able to get it to work. Tried swapping things and removing the "mw-" but nothing seems to work. Probably something obvious that I've overlooked.
YBG (
talk)
22:24, 7 March 2017 (UTC)
Seems to work now - without anything having been changed. Probably because the cache wasn't cleared, although I thought I'd done that.
YBG (
talk)
06:16, 8 March 2017 (UTC)
We could put a short TOC in the very top, but the doc does not look very important. I personally prefer showing in template space for comfort. I left out a |state=uncollapse option for the articles. -
DePiep (
talk)
06:39, 8 March 2017 (UTC)
The
Arbitration Committee is the panel of editors responsible for conducting the
Wikipedia arbitration process. It has the authority to impose binding solutions to disputes between editors, primarily for serious conduct disputes the community has been unable to resolve. This includes the authority to impose
site bans,
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.
Hello, YBG. Voting in the 2018 Arbitration Committee elections is now open until 23.59 on Sunday, 3 December. All users who registered an account before Sunday, 28 October 2018, made at least 150 mainspace edits before Thursday, 1 November 2018 and are not currently blocked are eligible to vote. Users with alternate accounts may only vote once.
The
Arbitration Committee is the panel of editors responsible for conducting the
Wikipedia arbitration process. It has the authority to impose binding solutions to disputes between editors, primarily for serious conduct disputes the community has been unable to resolve. This includes the authority to impose
site bans,
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.
@
R'n'B: Thanks! I will fix it immediately. I'm in the process of revamping the templates, but it does take a bit of time.
YBG (
talk)
03:16, 25 August 2018 (UTC)
Oops, I see you already made the necessary change! Thanks. By the way, I was actually serious in my comment about ease in editing. I do recognize that it a bit opaque, but I think when I get finished with my next batch of changes I hope you'll agree it is less so.
YBG (
talk)
03:36, 25 August 2018 (UTC)
@
ImprovedWikiImprovment: Thank you for reaching out to me here. Your
2nd edit summary (MOS:BOLDAVOID links never put in bold. No discussion required)) made much more sense than your
1st one (MOS:LEADSENTENCE), which didn't seem to apply. Much as I am a big fan the
WP:BRD and generally dislike discussion via edit summaries, your explanation was succinct and to the point, and the linked policy clearly explained the situation. Many thanks and happy editing.
YBG (
talk)
02:15, 25 September 2018 (UTC)
@
AmYisroelChai: I'm using |style="background:#eeeeff;", which is a light purplish color. If the color isn't working, feel free to try a bolder color. Alternately, the problem could be that there is also a row style and it might be that on your browser the row style overrules the cell style. Do you see a color in the legend at the bottom of the table?
YBG (
talk)
20:44, 10 October 2018 (UTC)
@
AmYisroelChai: Try removing the row style on the |- line and see if that makes a difference on your computer. I'm still wondering if it is the color or the interaction between the row-style and the cell-style.
YBG (
talk)
21:38, 10 October 2018 (UTC)
I hope you are OK. Would like to see you back here. Do spend all time well, especially with people nearby. -
DePiep (
talk)
21:48, 22 March 2019 (UTC)
Welcome to The Wikipedia Adventure!
Hi YBG! We're so happy you wanted to play to learn, as a friendly and fun way to get into our community and mission. I think these links might be helpful to you as you get started.
Indigenous peoples of the North American Southwest
Your edit on
Indigenous peoples of the North American Southwest should be undone. It is factually inaccurate to have modern-day borders on a map of what things looked like in 1350 CE because those borders and places did not exist back then. They are completely separate. There is nothing helpful about including the lines people draw on maps today just because some people don't like when they're not there.
Myrhonon (
talk)
04:03, 9 January 2020 (UTC)
You are correct that it would be factually inaccurate to claim that modern borders existed centuries ago. But they provide context to the reader who might wonder, "Hey, I live in northwest New Mexico. Which peoples lived here long ago?". I believe it is contextually obvious that the map does not claim that those borders existed back then, but nevertheless, I have added a clarifying comment to the caption: "with modern borders to provide geographical context".
I also edited the lede sentence for clarity, but before and after my edit it refers to "the current states of Colorado, Arizona, New Mexico, Utah, and Nevada in the western United States, and the states of Sonora and Chihuahua in northern Mexico."
YBG (
talk)
20:26, 9 January 2020 (UTC)
You've got mail!
Hello! If you recall that, a few months ago, I promised to write you a big letter of my impressions. I'll send it to you now; I'll greatly appreciate it if you briefly let me know you have received and/or read it, even if you won't be able to write a reply right away or will not choose to do it at all. If you haven't received it, please write to me so I can send you wherever you tell me to. Thanks--
R8R (
talk)
19:25, 20 April 2020 (UTC)
Notice of Dispute resolution noticeboard discussion
This message is being sent to let you know of a discussion at the
Wikipedia:Dispute resolution noticeboard regarding a content dispute discussion you may have participated in. Content disputes can hold up article development and make editing difficult for editors. You are not required to participate, but you are both invited and encouraged to help this dispute come to a resolution. The thread is "
Periodic table".The discussion is about the topic
Periodic table.
Please join us to help form a consensus. Thank you!
Reunited group 12 with the rest of the d block as TM (because they use their d orbitals for chemistry);
Renamed AM+AEM to "s-block metals", Ln+An = ITM to "f-block metals", TM to "d-block metals", and PTM to "p-block metals" (because that's what they would be and it'd be a consistent name set);
Annexed metalloids to nonmetals, because anything that isn't a metal must be a nonmetal (except Sb which conducts electricity like a metal in its only stable form);
Unified all nonmetals, because the "17" and "18" atop the F and Ne groups already tell us what "halogen" and "noble gas" do;
Distinguished H and He as the only nonmetals in the s rather than the p block (which makes a difference because they're the only ones with so few outer electrons);
@
Double sharp: That leads me in this direction (obviously, we'd need to add some more colors):
Legend option 1
Legend option 2
12 02
metals & nonmetals in the s-block
12 02
s-block metals & nonmetals
15 06 15
metals, metalloids & nonmetals in the p-block
15 06 15
p-block metals, metalloids & nonmetals
40 28
metals in the d- and f- blocks
40 28
d-block & f-block (all metals)
The biggest disadvantage to this of this scheme that a number of terms that are generally used in the literature are missing. However,
Many of these terms are included in group names and can continue to exist quite well without the status symbol of being artificially promoted by enwiki into categories
No matter what category scheme we select, we will leave out many perfectly-good frequently-used collective names. Who are we to decide which ones to elevate to prominence?
We need some other better scheme to take note of the many
names for sets of chemical elements rather than arbitrarily picking winners and losers. Such a scheme should not break down when collections overlap. Resolving the issue of fuzzy borders would be a great plus. But all of this is another issue for another day.
Some of the advantages that I see in this scheme
By only classifying by block and broad metallicity categories, we automatically get a mutually exclusive and jointly exhaustive system with no fuzzy borders (save only Og)
It retains the term metalloid, which has the best-researched attestation in enwiki. I believe the
lists of metalloids is the gold standard as far as documenting use of element set names. We would be well-served if someone would create such articles for all of the named sets.
It introduces no new vocabulary. Legend option 1 even avoids descriptive phrases that could be construed as 2-word terms
PS, while I don't believe the
law of excluded middle applies here, I would not be heartbroken if metalloids were counted as nonmetals. It would improve the esthetics of the legend (a very very minor point).
YBG (
talk)
07:52, 12 October 2020 (UTC)
Ah, I forgot about having said this here as a first thought! Well, if you look at current
WT:ELEM you can see I've since proposed going even more radical and going blocks-only. I just want to keep things in one place, so in a couple of days if everyone is agreeable (since the ANI thread seems to be winding down) I should post something articulating my case for this and the group 3 thing clearly from explicitly stated sources. I just need a bit of time to do it. ^_^
Double sharp (
talk)
09:24, 12 October 2020 (UTC)
Quick comments, which can be elaborated at WP:ELEM.
That the categories have not been been constructed with the goal of mutual exclusivity and joint exhaustivity is characteristic of the literature. As with categorisation schemes generally, there is some variation and overlapping of properties within and across each category.
There is no actual universal agreement on which elements belong in blocks other than in a theoretical sense, which does not translate well on the ground. Scerri has acknowledged this, re the notion of a 15-element wide f-block.
Further, in a review of Rayner-Canham's 2020 book, "The periodic table: past present, and future", Scerri concludes:
"All in all, the book is highly recommended to philosophers of chemistry. As philosophers we have a natural tendency to concentrate on generalities and not to get too involved in the specifics and the details. Above all else, this new book reminds us that such an approach needs to be tempered by a detailed knowledge of the exceptions and features that go against the simplified generalities which we so cherish."
doi:
10.1007/s10698-020-09389-x
The fact that the categories have not been constructed with the goal of mutual exclusivity and joint exhaustivity is characteristic of the literature is, to my mind, the best possible argument for Wikipedia not to try to make them so. The literature doesn't use them that way; therefore we should not try to make them that way. In my view, creating a bunch of categories, clearly colouring each element as belonging to one and one alone, putting these categories in an exalted position in the infoboxes, and not giving a clear clarification that none of this is actually agreed in the literature is just not good. Now, that accords with my understanding of
WP:NOR: however, I have invited
User:EdChem to participate as he seems more in touch with the correct understanding of what WP policies really mean. I will have more to say about this at
WT:ELEM from the literature.
In fact, apart from the problematic elements La-Ac and Lu-Lr, there is zero disagreement on which elements belong in which blocks. This can easily be detailed in a single footnote about group 3 and the concomitant issues, and with that single footnote we would accurately reflect the situation in the literature. If one were to try to do it for the category-based scheme, it would instead lead to a mess where a large number of p block elements are called out as being uncertain as metals, metalloids, or nonmetals; and indeed where even category names in themselves are called out as differing between sources (post-transition metals? poor metals? p-block metals? B subgroup metals? etc.). It seems to me that any category-scheme translates far worse on the ground that a block-scheme by these standards.
The notion of blocks is at least more or less standard in the literature. Even though blocks are often not defined properly, all four are acknowledged by IUPAC, and there is no doubt as to which elements belong to which blocks today, with the exceptions of La-Ac and Lu-Lr that come from the group 3 dispute (which is also acknowledged by IUPAC). They are a standard thing in the periodic table. Categories as a way to split up the elements with mutual exclusivity and joint exhaustivity are not standard across sources. Different sources use different categories (are there metalloids, or just metals and nonmetals?), disagree on boundaries of the same categories (are group 12 elements transition metals?), sometimes put the same element in multiple categories (are the heavier members of group 3 also transition elements), and sometimes don't even emphasise categories to the extent of colouring a periodic table (Greenwood and Earnshaw certainly don't); and not all the categories we use have an acknowledgement from IUPAC. That is pretty much my case.
As I have been pinged, I'll offer a few general thoughts:
As an FYI: This discussion belongs on an article talk page or at a WikiProject, rather than at a user talk page, for the sake of involving all interested editors and avoiding the potential problems associated with
WP:CONLOCAL. Sounding out ideas here is fine, but any consensus decision to be implemented in article space needs to be achieved somewhere that anyone interested is likely to have seen it and had the chance to participate.
This discussion reminds me strongly that we all wear at least two hats in these discussions – chemist and Wikipedian – and it is helpful to remember which we are wearing at any given time. I say at least two hats as may of us are educators and thus wear a third hat. As a chemist, there are many approaches that can be taken and that is reflected in the literature. As an educator, I may choose an approach that is most illustrative and thus best suits my purpose in teaching, and that approach may be different for different students (depending on prior knowledge, for example), and may differ again when dealing with colleagues well-versed in the nuances in this topic. As a Wikipedian, however, I do not have the freedom to make personal choices that reflect my opinions / beliefs if those are not grounded in RS given DUE weight, etc. I also do not have the ability to craft text to suit an individual reader. Thus, I note the importance of Double sharp's point about OR: The fact that the categories have not been constructed with the goal of mutual exclusivity and joint exhaustivity is characteristic of the literature is, to my mind, the best possible argument for Wikipedia not to try to make them so. The literature doesn't use them that way; therefore we should not try to make them that way. Wearing my educator hat, I see how mutual exclusivity and joint exhaustivity are worthy goals, especially for novice and relatively inexperienced students. Wearing my chemist hat, I can see how these goals can be unnecessarily reductionist and can try to force a straight-forward answer onto a complicated situation – in effect, obscuring useful nuance. Wearing my Wikipedian hat, however, the prime responsibility imposed by policy is to reflect the sources and avoid personal preferences, etc.
I wonder if the question being discussed is the right one. It sounds like the debate has started from the position of needing a consensus position on what to include in the PT article – which makes sense – but would it be better to ask what do the sources say and only then turn to the question of how to reflect them in article space? If we can't agree on what the sources say (including whether that be one position or several), that is a good basis to consider whether the situation is that we need to cover the variety of positions and not try to adopt a single one in WP's voice. Does this make sense?
@
EdChem: Yes, I started this conversation more or less as some idle chit-chat bouncing an idea to YBG; the OP's idea is not in fact what I currently want to propose (it's a few days old). But I decided to make a short response so that YBG knows I'm aware of Sandbh's comments. ^_^ I want to take this to
WT:ELEM, as stated above, but I need some time to write it properly and collect the citations and quotes needed. I'm a bit busier this week than I was last week. ^_^ So this is just a preview without the explicit cites so far. When I finish writing the thing, it will start from the position of asking what the sources say about the two issues, don't worry. That is, what does the literature tend to say about categorisation, and what it tends to say about group 3. So I'll refer to some reliable sources and quote them to do that. ^_^
I really like, BTW, what you say about chemistry vs pedagogy vs WP, and the different hats involved in each of them. You phrased it really well. ^_^ But I agree that we shouldn't be doing this on YBG's talk page, so I will leave it here for now.
Double sharp (
talk)
19:42, 12 October 2020 (UTC)
@
EdChem: Thank you for pointing out that user space discussions like this are ok for initially sounding out ideas, but never should be viewed as a consensus. I'm fairly certain this has been our practice at
WP: ELEM, though I cannot say so definitively.
YBG (
talk)
00:37, 13 October 2020 (UTC)
That is a sensible process. I believe that the rules for user v. article talk should be viewed flexibly except in certain cases:
If it is time to bring up an editor conduct / behaviour topic, it is time to go to user talk. This both separates the discussion and is more direct and private. The more contentious the debate, the more desirable to make any comment at user talk rather than publicly in the middle of an article talk discussion, especially if it can be seen (or spun) as trying to "win" an article issue by using conduct rather than the relevant policies like RS, V, DUE, etc.
If a user talk discussion is evolving into an article topic where consensus might be needed, it needs to be open to all at the article talk page. Sometimes a WikiProject talk page is suitable (especially for multiple articles) but not without a cross-post to article talk so that any article watchers are aware and have the opportunity to participate.
If a user talk discussion is spreading out to a discussion involving several editors, consideration to moving it should be considered. In a case where the group of likely interested parties is smallish, and there is goodwill and collegiality, the need to relocate is reduced... but ultimately an article space decision should never be taken in user talk – if for no other reason that it will be difficult for an editor in the future trying to understand or considering a modification to find and take into account.
With regard to drafting an RfC, trying to do so on article talk to find a consensus wording can be wise; but it can also be nearly impossible if it will mean thoughts from a cast of thousands. There are times when drafting an RfC in user space can be more efficient. You can establish a page like user:WHOEVER/Draft_RfC_on_XXX. Being in user space, you can ask that only certain users contribute to the actual draft but open the user_talk:WHOEVER/Draft_RfC_on_XXX page for comments. You can start with a couple of people who are able to be balanced in the presentation, and when something concrete is available, invite comment from editors on both sides. Alternatively, you can propose that the discussion start with representatives of each perspective and ask that others stay out or stay on the user talk page. Once a draft seems stable, comment could be invited from the editors at the relevant article / WikiProject talk page for a day or several before the RfC goes live. There are no hard-and-fast rules on how to produce an effective RfC and there are some editors who are good at writing one from scratch, but a badly written / ill-considered / problematic RfC going live is an ineffective timesink waiting to happen. Remember also that an effective RfC can find consensus through the input of outsiders who are less invested in the article topic and more able to see what is most in line with encyclopaedic content. As such, the less an RfC depends on specialist knowledge, the better. I know that much of the Lu v La debate hinges on chemical properties and sitting with PT trends, etc, but outsiders will not be aware of these and likely will not comment if the issues are placed to the forefront of an RfC.
The rules of user space are deliberately flexible, but also biased to empower the host editor. So long as the participants in a discussion are content and anyone unaware or excluded is unlikely to be objecting, then the discussion is probably fine. The more things move to dispute that is ceasing to be robust collegial debate and becoming conflict (and especially personalised conflict) the more taking the rules literally and applying them consistently becomes wise. And, when they come to article space conclusions, move the discussion or at least link to it from article talk.
Flexibility / rigidity of rules is part of the reason that the ANI thread sprawled out of control. ANI is meant to look at behaviour and for admins to take actions to resolve problems where that is appropriate and has rules (both formal and informal). Not following them can result in sanction, or just in the thread being derailed and ineffective. It can't resolve content issues so they should be minimised as much as possible. Threads that devolve into back-and-forth between complainants typically result in no action as they take a lot of wading through to sort out, and neither party is behaving like a complainant coming to admins with clean hands looking for help – it looks like both / all parties behaving badly and promotes thoughts amounting to "let them fight and sort it out until they are willing to provide a strong and concise case to address" or "there are editors trying to work on the articles being drowned by the combat, let's remove the combatants and see if sanity is restored." There are other possibilities, of course, but these ones certainly happen. Also, if there is only one party flouting the rules of ANI, it is much more obvious (and actionable). If you have to go to ANI, a concise case, followed by a response, should be left for outsiders to comment unless the response raising things that NEED to be addressed. If the case says X happened, and Y gives a bunch of excuses, a reply that the diffs confirm X happened is sufficient. If Y makes accusations that show poor judgement / behaviours which did happen, a brief admission / apology etc is better... and if they didn't, just use diffs to refute briefly. Know what you are asking for, present the strongest, organised evidence for it, and then let those you are asking consider / respond / take action. If you are taken to ANI, rebut any accusations with diffs of strong evidence, make any counter-claim succinctly and with strong diff-supported evidence. Respond to questions from outsiders but don't engage in debate and certainly not with the OP.
Ok, enough thoughts on this – a stream of comments rather than a planned reply, so sorry that it rambles. Were this ANI, the above should be edited to be short, sharp, diff-supported, and easy for an outsider to comprehend.
EdChem (
talk)
01:55, 17 October 2020 (UTC)
The nature of WP. As I understand it, WP seeks to reflect, as best we can, what is in the literature, including the boundary overlaps that are characteristic of classification science, in general. Thus, the fuzziness and overlap phenomena are clearly noted in the periodic table article; the metalloid article; and the nonmetal article. That’s all that’s needed.
Clarifying the situation. As you suggested, we can clarify the group 3 and group 12 situation with a note in the graphic. All other categories, AE; AEM (separate or merged); Ln, An (separate or merged) PTM; metalloids per YBG’s gold standard (thank you YBG ^_^); halogen nonmetals; noble gases; and the moderately active, pre-halogen, or other nonmetals, fall naturally into place. Literature support is available for all of them.
Historical effort. As you noted, it isn’t particularly surprising there was no historical effort to try and make the categories mutually exclusive and jointly exhaustive. Subsequently, as you wrote, the result tends to either lead to "other" categories or categories without the same level of name recognition as the others.
That speaks to the iterative relationship between classifications, and science:
The importance of classification
Minelli, A.: The nature of classification: Relationships and kinds in the natural sciences—:By John S. Wilkins and Malte C. Ebach. Systematic Biology. 63 (5), pp. 844–846.
”At any given time, during the historical development of a scientific discipline, classification of available evidence offers itself as the explanandum that asks for a theory (or alternative theories) able to explain it. But this is just one segment in a potentially unending chain of recursive relationships between classification and theory. Theory and classification indeed change over time. As a consequence, the theory that provides explanation for the data organized in a classification at a given time can influence subsequent classificatory effort, and so on. “By means of this a discipline advances: each new pattern raises questions that call for explanations, and each verified phenomenon or fact gives a new pattern” (p. 163). What counts as a fact or a theory is a matter of temporal relativity. The authors’ “concern is that we do not replace observation with theory and think that we have made some progress. Science is founded upon empirical observations, no matter how these are tied up with local and cross-disciplinary theoretical commitments or stances. Once we abandon this aspect of science…science becomes little more than a matter of worldviews and epistemic statements of faith” (p. 163).”
Blocks. There is no precise, universally accepted definition of what a block is, that I can recall reading. Even thorium is problematic. The IUPAC Red Book does not define what a block is. A block-based period table does not solve anything. It hides information, rather summarising it via categories. As Christie and Christie (2000, p. 42) argued, “chemistry rests much more strongly on its…foundations of the 19th century and earlier, and much less on the insights of modern quantum physics.”
As I see it, per the
basic value template, this is a standoff, lopsided, or top-heavy situation rather than an example of synergy. With a few lines, the blocks can be shown on the PT graphic in addition to the categories.
Sandbh (
talk)
05:14, 13 October 2020 (UTC)
Changing the subject from content to process
@
EdChem: I would appreciate your thoughts on a couple of process issues that this discussion brings up.
Sometimes at ELEM, we find it difficult to explain our thoughts about a proposal we wish to bring forward without displaying it in context. Similarly, we sometimes find it difficult to understand another editor's ideas without seeing them fleshed out in context. This leads us to draw a whole periodic table to illustrate a new color scheme, or even to prepare a draft of an entire article before a consensus has been reached about the general direction we wish to go. How should one decide when such a draft is helpful in providing a general understanding before trying to reach a consensus?
I am ruminating on a few RfC that I think would be helpful for our project. What is the best way to do this? I'm inclined to try my best to get the wording the best before opening up the RfC, as I am afraid that a poorly worded 1st draft of the question could so muddy the waters that it makes it harder to reach a consensus. Any suggestions about thus? For example, would user space chats be wise to determine which subjects are most important and to determine the best wording?
I started this subsection asking for personal advice about how I should view project processes. But should I move this to
WT:ELEM before you answer? Just say the word and I will copy this sub-section over there. And if one point belongs here and the other there, that's ok too. Just let me know.
Hi YBG,
Double sharp,
Sandbh, and anyone watching / interested who I have missed.
FYI, I have seen the questions and posts at ELEM but have yet to have time to respond. It will happen, I'm just swamped with RL issues that are important and urgent. My apologies.
A quick reply on the RFC question: a contentious or unclear question is the best start if a long, heated, and ultimately useless discussion is sought. Thus, I concur that discussion to agree on an acceptable / fair / simple / etc question is very wise (as
Floqueanbeam also suggested at the recent mega-ANI thread). If there are only two editors in disagreement then on user talk can be ok to avoid cluttering a WT or article talk page. If more, perhaps starting a non-user talk thread saying "I think XXX is suited to being resolved in an RfC, let's try to come to a consensus on what to ask rather than one of us launching it unilaterally." This does not work in cases where the issues are ideological and the parties will not agree on what is neutral nor compromise (think a devoted advocate for Trump and a passionate anti-Trump advocate – leaving aside that WP is not for advocacy, the chances that they can agree on a neutral and fair question to let those who choose to participate decide is far-fetched), but it should work fine for issues where each side can see the desirability of a consensus and has RS-based reasons for their views and are open to compromise / persuasion – that is, I anticipate that it would be fine for ELEM. Note also that input on the set up of an RfC can increase the chances of avoiding a structure that seems fine to one editor but which is actually over-simplified (say) and risks sprawling out into multiple options. Many an RfC has been set up in good faith and evolved into something unhelpful because factors went unconsidered (or under-considered) in its formation. One way is to ask a question that is not for WP to address. For example, does "Lu belong in the d- or f-blocks?" is a question about scientific consensus, and if there isn't one or there is controversy, a huge amount of time can be spent arguing the issue, expressing opinions, engaging in OR, etc. A better question might be "should WP deal with the question of whether Lu belongs in the d- or f- blocks by (A) ... or (B) ... or (C) ...?" and then offer the options that emerged from a prior discussion.
PS: Apologies to
Floquenbeam for the mis-spelling... adding this to trigger the intended ping so you are aware that you were mentioned, and in case you want to comment.
EdChem (
talk)
23:45, 15 October 2020 (UTC)
Second apology to
Floquenbeam for mis-attributing the comments that I meant to her, when they were actually made by Softlavender. Courtesy ping to
Softlavender as having made the comments that I thought were valuable on RfCs, and in case she wishes to make a comment.
EdChem (
talk)
01:11, 17 October 2020 (UTC)
@
EdChem: It's OK, I'm also swamped. ^_^ I still plan an actual posting summarising what I feel the sources are saying on this and the categorisation issues. The latter may be getting closer to a consensus since
User:Sandbh has recently posted a blocks-up-front suggestion, but we'll see. The problem is that (1) I have little time right now and (2) one of the sources I need for the Lu thing is in Russian and I don't have an electronic copy, so it takes some time to actually find out what it's saying. Sorry.
Double sharp (
talk)
09:15, 16 October 2020 (UTC)