There is also an Isotope table (divided) with its own talk page that you may want to look at. |
For instructions on using templates in the isotope table, see Template talk:Iso1.
This is one of the largest pages i Wikipedia. I have therefore tried to reduce its size on the danish copy. In IE 6 it looks OK, but it might not in others. If you use another browser, try and have a look. Jan Pedersen 12:55 23 Jul 2003 (UTC)
Thanx Bryan. I have substituted all "<div style=background-color" with "<td bgcolor". It is now even smaller than before. Would you take another look using Mozilla? Jan Pedersen 08:19 24 Jul 2003 (UTC)
Thanx again Bryan. Now I see what you mean, now I don't ;-). When using the "Cologne blue" skin as I usually do, the standard stylesheet is not used. I therefore never saw the effect indicating the isotopes with meta states. Do you think the missig stylesheet should be reported as a bug? Jan Pedersen 09:05 25 Jul 2003 (UTC)
Conventionally, the axes are defined the other way round, so that isotopes of an element exist in a horizontal line. Would it be not to tricky to write a little script which reorders the table? Pstevenson 17:22, 28 Feb 2004 (UTC)
I was trying to link to all the istoscopes from the chart not finshed someone else please help put [[ ]] around element abbreviations -David
This is a very neat table. In Firefox, the bottom left gridlines are still visible, though. There is probably a way to make them invisible on all browsers. - Omegatron 19:24, Jun 23, 2005 (UTC)
Originally the
Nynorsk copy of this article was more than 90 kB, which caused a lot of trouble. The most noticeable was that software introduced errors during edit/save, e.g. the isotope 75Ge (in code: <small><sup>75</sup></small>Ge
) was changed to <small>Ge (in code: <small><sup>75</sup></small>Ge
), and another place the attribute bgcolor="#993399"
was changed to bgcolor="#993399"
resulting in a black cell.
In order to reduce the file size and avoid such errors, and also to make editing of the table easier, I introduced a couple of templates to take care of all the colours and <small>'s and <sup>'s. The file size was reduced to less than 45 kB (*) and editing is a lot easier now. There is one template for one-coloured cells (~2000) and one for two-coloured cells (~200), with simplified syntax for white cells or white borders. The two-colour template could do everything but uses more text to do it, and is only used for the two-coloured cells. The templates are described in more detail at the article's talk page. The template code is in English so I believe most of it is understandable, although the talk page is in Norwegian. -- Eddi (Talk) 00:48, 26 July 2005 (UTC) / -- Eddi (Talk) 12:38, 27 July 2005 (UTC)
(*) For comparison the Danish copy discussed above is 63 kB.
The cell separators could have been in the templates but were left out to maintain a kind of uniformity in the table coding. Since it would only free about 2 kB out of 43 anyway, I think it's OK. Theoretically it allows for extra attributes such as font effects in individual table cells, which wouldn't work if the separators were in the templates, although I see no current need for such attributes. The same templates may also be used rather neatly in other contexts, e.g. the half-life colour chart on top of the article, like this:
{| align=right cellpadding=2 cellspacing=0 border=1 |+ '''[[Half-life|Half-lives]]''' (example: [[Gadolinium|Gd]]) |- | {{Iso1|145|Gd|-}} || Unstable |- | {{Iso1|146|Gd|V}} || 1-10 [[day]]s |- | {{Iso1|149|Gd|I}} || 10-100 days |- | {{Iso1|153|Gd|B}} || 100 days - 10 [[year]]s |- | {{Iso1|148|Gd|G}} || 10-10,000 years |- | {{Iso1|150|Gd|Y}} || >10,000 years |- | {{Iso1|152|Gd|O}} || Natural [[radioactive]] |- | {{Iso1|158|Gd|R}} || Stable |} |
|
Regarding escaped characters I don't really know what causes the errors, but I use Opera, too. I try to avoid errors by always previewing my edits and sorting out obvious flaws, then searching for any additonal <'s, >'s, "'s, &'s etc. (or just &'s or ;'s) that may have been introduced while pressing 'Preview', and in the end I just cross my fingers while pressing 'Save'... Not very scientific, that is. -- Eddi (Talk) 12:38, 27 July 2005 (UTC)
Would it be a good idea to introduce similar templates in the English copy? It would involve 2 main templates (Iso1 and Iso2) plus 8 colour templates (e.g. Iso/R containing the string ff9999). If such templates should be used here, would it be easier to transform it locally or translate the Nynorsk copy? The English copy contains a whole bunch of recently discovered unstable isotopes of both light and heavy weight that are not (yet) included in the Nynorsk copy. -- Eddi (Talk) 22:58, 27 July 2005 (UTC)
I have now proofread the draft table with respect to colours, and all the coloured cells have correct backgrounds and borders. I have not checked to see if all white cells are included, or if all links to special isotopes are in place. To check this I would like to overwrite the existing table with the templated one, and then look at the history diff to spot any missing cells or links. Would that be all right? -- Eddi (Talk) 12:56, 4 August 2005 (UTC)
If/when the templates are introduced in the live table, there must be an instruction for the use of the templates. I can copy the essentials from :nn. Should the instruction be in Template talk:Iso1 / Template talk:Iso2 or a section of Talk:Isotope table (complete)? (By the way, I think there should also be a more detailed explanation of the various border colours. This could be placed together with the template instructions.) -- Eddi (Talk) 12:56, 4 August 2005 (UTC)
I noticed that the draft table has "shadow" cell borders, that is, grey to the left/upside and white to the right/bottom. I think this may obscure the rightfully white borders of isotopes with multiple decay pathways. Could we keep the simple, grey cell borders of the current table? -- Eddi (Talk) 12:56, 4 August 2005 (UTC)
Now that the templates have gone live in the complete table, how about the divided table? (As you might expect, I'm all in favour.) Should the existing divided table be transformed, or should the already transformed complete table be divided? -- Eddi (Talk) 23:42, 4 August 2005 (UTC)
Some of Talk:Isotope table (divided) is also valid for the complete table, and vice versa. I suppose a redirect may be too drastic, but there could at least be a prominently displayed link between the talk pages. -- Eddi (Talk) 22:14, 10 August 2005 (UTC)
I have now inserted red boxes on top of each talk page with links in both directions. I didn't designate any of them as parent or child, but that may be done with little extra effort. -- Eddi (Talk) 20:59, 18 August 2005 (UTC)
Oh, this is lovely! When you are done, please come to WP:FLC to nominate it as a Featured list. -- ALoan (Talk) 12:58, 19 August 2005 (UTC)
If the isotope table is going to be nominated as a featured list candidate, I think a few issues should be addressed to meet the FLC criteria on usefulness, comprehensiveness, and accuracy (I believe the other criteria are already met):
A formal project may not be required, but a group of editors should be ready and prepared to handle any shortcomings of the article during the nomination period. I'll set up a list of interested editors below – feel free to add your name. -- Eddi (Talk) 20:52, 4 September 2005 (UTC)
Just got confirmation from Bryan that the now defunct http://www2.bnl.gov/CoN/nuchart1.html (BNL), which was the source for this data, indeed is the same site as the archive.org'ed [1]. (You might have to turn on javascript, play around with the link, and/or replace the date string with an asterisk to get that silly thing to work.) Their reference was given as
Femto 11:42, 10 September 2005 (UTC)
I cannot understand why International Atomic Energy Agency gets credit for Interactive Table of Nuclides? Interactive Table of Nuclides ( http://www.nndc.bnl.gov/nudat2) is developed and maintained by the National Nuclear Data Center (NNDC) at Brookhaven National Laboratory. International Atomic Energy Agency is only hosting it, providing the second installation in addition to NNDC.
So whichever is the exact meaning of "stable" or "natural radioactive", our definitions are BNL's definitions. Apparently, http://atom.kaeri.re.kr/ is the direct successor of that page, maybe there's also something buried in their FAQ. In the long run, and before a featured nomination, I agree though that it's absolutely essential for these articles to set their own definitions. There does seem to be no Wikipedia-wide agreement on those terms, let alone on the web. Femto 11:42, 10 September 2005 (UTC)
Commit myself? I'm crazy, but I'm not that crazy. :p Femto 11:42, 10 September 2005 (UTC)
Inspired by the Danish version of the isotope table, lighter colours were introduced in the Norwegian version by simple manipulation of the 8 colour templates. The contrast between cell text and background colours improved very much, not only for blue and red wikilinked text but also for normal black text. Compare the English version with any of those or, for an instant comparison, see the half-life colour chart in the Norwegian test version. Various colours have been discussed for various purposes at the isotope project and the deep colours were apparently chosen for the isotope table at some point, but I gather nothing is set in stone. Are there any objections to lighter colours here, perhaps except that it shouldn't be done before the templates have been implemented in the divided table? -- Eddi (Talk) 23:44, 19 August 2005 (UTC)
As mentioned by Femto above, some isotopes were missing in either the complete table or the divided table. I have now added or corrected the following entries in each table:
-- Eddi (Talk) 03:17, 4 September 2005 (UTC)
Can we somehow make the colour chart float over the article so that it's still visible when scrolling down and right through the isotope table? -- Eddi (Talk) 12:38, 27 July 2005 (UTC)
145Gd | < 1 day |
149Gd | 1–10 days |
146Gd | 10–100 days |
153Gd | 100 days–10 a |
148Gd | 10–10,000 a |
150Gd | 10 ka–700 Ma |
152Gd | > 700 Ma |
158Gd | Stable |
Cell | Code | Title | Code of title part of cell |
93Nb |
{{iso2|93|Nb|R|G}} |
Half-life – Isotope: Stable; Nuclear isomer: 10–10,000 years | Half-life – Isotope: {{iso/R/text}}; Nuclear isomer: {{iso/G/text}} |
91Nb |
{{iso2|91|Nb|Y|I}} |
Half-life – Isotope: 10k–103M years; Nuclear isomer: 10–100 days | Half-life – Isotope: {{iso/Y/text}}; Nuclear isomer: {{iso/I/text}} |
89Zr |
{{iso2|89|Zr|V|-}} |
Half-life – Isotope: 1–10 days; Nuclear isomer: < 1 day | Half-life – Isotope: {{iso/V/text}}; Nuclear isomer: {{iso/-/text}} |
The two-coloured cell for Ta 180 indicates that there is a nuclear isomer that is unstable (the white border). However, elsewhere on Wikipedia (under "nuclear isomer") we are told that Ta 180 has the only stable nuclear isomer.
One of these must be wrong - I suspect the first, since elsewhere there is reference to Ta 180 isomer stability - see [3].
I'm not sure if I can edit this, perhaps someone can have a go?
Edit - had a go now - looks ok
i fixed the one under He (moved column down), but others exist and should be filled in. e.g. 28S has a pretty long half life.. Eupedia 05:58, 5 April 2006 (UTC)
145Gd | < 1 day |
149Gd | 1–10 days |
146Gd | 10–100 days |
153Gd | 100 days–10 a |
148Gd | 10–10,000 a |
150Gd | 10 ka–700 Ma |
152Gd | > 700 Ma |
158Gd | Stable |
is there another version of this on the wiki that shows richer data for each isotope? plans for one? here's an idea: alternate text that would give the richer data upon mouseover somehow. not sure how to implement, tho. 24.5.187.236 06:02, 6 April 2006 (UTC)
Most charts that I have seen include the free neutron (p=0, n=1), as a natural extension of the table next to deuterium. The free neutron article even includes a mini-isotope-table picture (shown at right) with the free neutron included in the table. The neutron undergoes beta decay, just like many other nuclides, and has a known half-life (which according to the article is 15 minutes), so I think it should be included in the isotope table. Spoon! 02:54, 28 June 2006 (UTC)
This chart shows an isotope Helium-2, yet that is not listed in Isotopes of helium. Which is correct? Should Helium-2 be added to Isotopes of Helium, or should it be removed from here? Nik42 01:03, 15 September 2006 (UTC)
It has already been discussed above: The term "natural radioactive" is unclear. I think the corresponding entries should be divided up into the other categories. The source from which the data had been taken in the first place soon after changed their own data so that "natural radioactive" was no longer present. However, I don't have a problem with "stable". It says: "This nuclide is belived to be (absolutely) stable."/"No decay has been observed." Also, I agree with Spoon! that the neutron should be added. Quilbert 18:34, 26 January 2007 (UTC)
Most of the "natural radioactive" cells would fit in a "very long halflife" category with a threshold of, say 500 million years to include 235U. Also, a reasonable meaning of "natural radioactive" would be isotopes that have survived on the Earth during its lifetime. I agree that listing the few shortlived members in this category is misleading and that they should be classified according to their halflife:
3T 12.32a | 10Be 1.51E+6a | 14C 5.70E+3a | 215At .10ms | 231Pa 3.27E+4 a | 234Pa 6.70h | 234U 2.455E+5a |
-- JWB 06:06, 20 April 2007 (UTC)
Lead-204 is marked as having an isomer of >10000 years, but Isotopes of lead does not seem to list it. Does anyone know where this came from? -- JWB 08:21, 20 April 2007 (UTC)
How do you feel about using gray for stable isotopes?
I'm going to give gray (BBB) a try as nobody has objected so far. Discuss here or at Template talk:Iso1. -- JWB 19:05, 28 June 2007 (UTC)
Now that gray represents the most stable isotopes, I think we should also reverse the order of colors for the rest of the stability range so that darker, cooler colors (gray, purple, blue) represent more stable isotopes, and lighter, warmer colors (orange, yellow, white) represent less stable isotopes. -- IanOsgood ( talk) 19:53, 25 November 2007 (UTC)
In one way that's intuitive, but on the other hand it's reversed for glowing hot bodies, which start at red hot and move towards blue with increasing temperature, although the middle of this temperature spectrum is white instead of green. See Color temperature and Black body#Explanation. -- JWB ( talk) 20:16, 25 November 2007 (UTC)
Sure. However, humans have a different perception of color warmth. See Color symbolism and psychology and search for "warm". A lightness gradient from dark gray to white also makes the table look better on the typical white page background. -- IanOsgood 17:11, 3 December 2007 (UTC)
Any color comes in lighter or darker versions. Or are you proposing using grays only? -- JWB ( talk) 17:45, 18 December 2007 (UTC)
I fixed the colors of long-lived and stable isotopes as them are known today. Namely, the following changes were made:
Let me give a list of 31 nuclides that are known to be radioactive with half-life >7E8 yr (i.e. primordial radioactive nuclides) as for today (decay modes: alpha (a), beta (b), double beta (2b), spontaneous fusion (SF), cluster emission(CE)):
40-K (b), 48-Ca (2b), 50-V (b), 76-Ge (2b), 82-Se (2b), 87-Rb (b), 96-Zr (2b), 100-Mo (2b), 113-Cd (b), 116-Cd (2b), 115-In (b), 128-Te (2b), 130-Te (2b), 130-Ba (2b), 138-La (b), 144-Nd (a), 150-Nd (2b), 147-Sm (a), 148-Sm (a), 151-Eu (a), 152-Gd (a), 176-Lu (b), 174-Hf (a), 180-W (a), 187-Re (b), 186-Os (a), 190-Pt (a), 209-Bi (a), 232-Th (a, SF), 235-U (a, CE), 238-U (a, 2b, SF).
V1adis1av
14:40, 25 August 2007 (UTC)
This footnote, from Kilogram explains something clear enough:
Accordingly, I changed the color coding for 209Bi to “stable” (grey) but added a hidden editors note explaining the rationale for labeling it as so. Greg L ( my talk) 06:57, 3 February 2008 (UTC)
I don’t see any reason (even file-size-related ones) as to why Isotope table (divided) and this article can’t be merged into one featuring both styles of table. Why do the two styles have to be on separate pages so that two articles have to be maintained?
I don’t believe a case can be made now that two articles are necessary due to file-size issues. I see from this post: Templates make editing easier and file size is halved, that problems seemed to occur only when files grew to the 63–180 kB size range. That was back in 2005 though. Since then, templates have reduced this article to only 48 kB and the other is only 50 kB. And, of course, browsers have been updated since then to handle more complicated Web pages (and larger ones too, presumably). Isn’t it time to try a merged version? I suspect it would be under 100 kB and I’m sure modern browsers can handle that; after all, United States is 161 kB.
Maintaining two articles that are supposed to have identical content is not the way to do things on Wikipedia.
Having said all that, my highest complements to all who’ve worked on his—especially Eddi. Making templates takes a lot of time and his donation of all his time had to have been a real labor of love. This article is extremely useful and is an awesome resource. It would sure be nice though, to not have two of them to maintain. Greg L ( my talk) 18:33, 3 February 2008 (UTC)
I think the virtues of this unitized method are many: There is now a handy pictorial representation of the periodic table immediately below the TOC so users can quickly look up exactly which sub-section to click on. Further, links to this article from elswewhere on Wikipedia can now take a reader directly to an element of interest while still giving the reader freedom to scroll the entire contents of what used to be two entirely separate (but totally redundant) articles. Greg L ( my talk) 22:41, 17 February 2008 (UTC)
Sorry I missed your earlier query. I think this is a bad idea that if anything is negative for usability. It's precisely because the content is redundant that there is little reason for a reader to need both copies in one scroll. The whole idea of the divided table is to reduce the need for horizontal scrolling in the first place. If we are going to have an even bigger area to scroll through, that frustrates the original intent and we might as well get rid of the divided table.
Putting them on one page does nothing to make maintenance easier. You still have to maintain two copies of each entry, but have to do even more scrolling. If you could find a way to generate both formats from a single list that would not need double maintenance, then that might be useful.
50k is about the limit where splitting is suggested, plus this page is one of the slowest to load anyway, presumably because of the template evaluation. One reason I have spent a good deal of effort getting rid of empty cells is to reduce size and load/display time. Also, server load will be approximately doubled by putting both tables on one page. -- JWB ( talk) 02:07, 18 February 2008 (UTC)
I am truly astonished that the articles could be maintained and synchronized as well as they have been thus far. The whole notion of having two, independent discussion forums(!) to debate content issues in two articles that are supposed to stay in perfect synch—while novel—is nearly beyond belief. Greg L ( my talk) 02:54, 18 February 2008 (UTC)
I was expecting the periodic table image to be an image map that would take you straight to a particular element, but looks like it's just a picture.
→That’s a natural reaction and I doubt you’ll be the last to do it (once). I did my best with the caption: Use this pictorial
periodic chart as a guide in selecting the desired table from Contents below. Still, it’s quite handy. One can be directed to this article from, for instance, the
Kilogram article where they were reading up on
Bismuth. A handy periodic chart helps to figure out which isotope group to click on in the TOC.
Greg L (
my talk)
07:44, 18 February 2008 (UTC)
Looks like you placed the color key on each segment of the divided table. That's good, but could have been done as easily without combining the two pages, and does nothing for the single table. Not sure what other usability enhancements you are talking about.
I have always used the single table. It is harder to trace decay chains and trends across the divided table boundaries. The divided table segments are also smaller than they could be.
Render speed for the page seems fast, but when I edited the page, preview took 27 sec. I've experienced much slower before, so the server/load ratio must be better than at those times.
→I agree; slow for editors. Sweet for readers as they now “have it all” in one convenient place.
Greg L (
my talk)
07:44, 18 February 2008 (UTC)
There are more then two discussion forums - a lot of the discussion also happened at Template_talk:Iso1 and probably elsewhere. It's all too common and hard to avoid for discussion of a topic to spread over multiple articles, templates, etc. Eliminating just one page is not going to eliminate the problem. You still have to monitor and post on multiple pages. For the issue of updating specific entries in the table, it seems to have been handled by editors updating both, or at least posting in Talk saying what they did in one. But, as noted, two independent entries for each isotope still have to be kept in sync, it's just that they are on one large page. -- JWB ( talk) 06:52, 18 February 2008 (UTC)
Also, have you noticed how many versions of the Periodic table exist and are separate articles? -- JWB ( talk) 18:16, 18 February 2008 (UTC)
Also note when you edit this article or the divided table and preview, you get a warning message "This page is 101 kilobytes long.", or 53 for the divided table page. This is to tell you that the page is getting longer than recommended by policy. -- JWB ( talk) 18:11, 18 February 2008 (UTC)
Please see Wikipedia:Article_size#A rule of thumb. -- JWB ( talk) 18:26, 18 February 2008 (UTC)
Let’s also be fair while referencing Wikipedia advise on file size. The very article you referenced above stated here that “With some web browsers with certain plug-ins running in certain environments, articles over 400K may not render properly…” and went on to discuss browser limitations. The “100 kB” recommended size is borne out of desire to ensure that regular prose-based articles don’t suffer from bloat-itis and become boring. Notwithstanding this policy, there are still 28 Wikipedia articles that exceed 200 kB, and one, ( link to article) that is 430 kB! Anyway, non-prose reference tables are immune to this “boredom-based” file-size concern; they are almost entirely reference data. The beauty of Wikipedia is we can use the power of web browsers to make it extraordinarily easy to find what one is looking for and we have extraordinary flexibility in presenting the data to the reader. The past performance problems with these isotope tables seem to have been fixed—largely due to efforts of people like Eddie, who made the extraordinarily efficient templates they rely upon.
Now that this article has enhanced usability features like the ← Previous | Next → navigation links, color-code legends in each section, and the periodic table visual reference guide, this integrated version is, IMO, far more convenient than the separate versions ever were as stand-alones; the whole is greater than the sum of the parts. Absent any compelling performance problems (which I doubt will crop up due to modern browsers and Eddie’s work), it no longer makes sense to split up two views of identical content.
I think we’ve both conveyed our positions quite well here and suggest that we sit back and see how others feel about this. Clearly, there are going to be those who are disappointed with the change, want things back to the old ways, and will quickly find their way here to weigh-in. But hopefully, some users who visit this article and like it, will see fit to come to this discussion page and post a quick note regarding their impressions. To other authors and readers: please weigh in regarding performance issues. Notwithstanding that this article “previews” rather slowly while editing, does it suffer from performance issues when it loads while browsing? Greg L ( my talk) 20:47, 18 February 2008 (UTC)
Two exceptions are lists, and articles summarizing certain fields. These act as summaries and starting points for a field and in the case of some broad subjects or lists either do not have a natural division point or work better as a single article. In such cases, the article should nonetheless be kept short where possible.
I don’t pretend to speak for everyone else on Wikipedia and I hope you aren’t either. It seems the two articles have diverged into separate camps with their own turf when the original reason for bifurcating it in the first place—performance issues—no longer exists. The only real measures of whether this article is now better is to see how well received it is by the larger community and whether some users experience performance issues. It’s time now to take a deep breath and let others express their opinion too, JWB. My bet is that others will like this newly integrated multi-view with its “ ← Previous | Next → ” nav tools and other enhancements. I might be wrong; we’ll see. Greg L ( my talk) 00:46, 19 February 2008 (UTC)
P.S. I withdrew the merge tag myself. I wasn’t trying to piss in someone’s cornflakes; I thought that since all the damned info had been copied over, it was the proper thing to do. Fighting this has been most un-fun and I can think of better things to do. Greg L ( my talk) 02:34, 19 February 2008 (UTC)
JWB: A “consensus” isn’t required for an editor to edit or expand this article. A wider consensus is only required if Isotope table (divided) is to be merged (deleted) in the process. It is wholly inappropriate and in exceedingly bad form for you to copy and mimic the enhancement and features I’ve implemented here and then simply delete all my work before other editors have had a chance to evaluate its merits and voice their opinion. Here’s what “divided” looked like before I started my work over here, and here’s what it looked like after you copied many of my improvements and then deleted my improvements from here. When done the way you just did it, it’s no longer “copying” and is just simple “stealing.” What an astonishingly large degree of gall that took. It’s also a metric ton of weapons-grade bullonium and I’ll have none of it. Such behavior is simply not tolerated on Wikipedia and there are remedies such as Wikiquette alerts if you continue to operate this way.
In your edit summary where you deleted all my work, you wrote “Moved back to Isotope table (divided), if merge is approved by consensus, can move back here.” There was no “move” from “divided” to here, “divided” was left completely alone. If there was a “move” of any sort, it was when you copied all my ideas and hard work and then deleted them all here; now that’s a “move.” You need to be honest with your edits and your edit summaries and your discussions. If your position is that Wikipedia is better off by continuing to have the articles separate, then you must let others weigh in on the matter instead of taking upon yourself to delete the tables I added.
After several days of your furious typing here about integrating these two articles, you have been the only one who has objected to the integrated approach. No one is even afforded an opportunity to look at the possible advantages when you just delete it all. Having a single article to maintain makes just too much sense sense and I can’t help it if this possibly-better way of doing it threatens your desire to retain Isotope table (divided); it’s time to let others voice their opinion on the matter. Your arguments about file size issues are a red herring and have nothing to do with the matter; download speed is plenty fast.
My position is simple: Independently maintaining absolutely identical isotope data in two separate articles, each with its own separate discussion venue(!?!) makes absolutely no sense. Experts on isotopes who aren’t as proficient as you and I at editing Wikipedia often won’t even know to go hunt down the other article and make the exact same edits there. The “100 kB” recommended size you’ve referred to was borne out of desire to ensure that regular prose-based articles don’t suffer from bloat-itis and become boring. Notwithstanding this policy, there are still 28 Wikipedia articles that exceed 200 kB, and one, ( link to article) that is 430 kB! Non-prose reference tables are immune to this “boredom-based” file-size concern; they are almost entirely reference data. The beauty of Wikipedia is we can use the power of web browsers to make it extraordinarily easy to find what one is looking for and we have extraordinary flexibility in presenting the data to the reader. The past performance problems with these isotope tables seem to have been fixed—largely due to efforts of people like Eddie, who made the extraordinarily efficient templates they rely upon.
I think other editors and users will find that my proposed method is a convenient-to-use and attractive way of doing things but they have to be able to see and try the proposed new way (which you’ve copied the crap out of) in order to be able to offer an opinion! Still, all your copying doesn’t put both types of table in one convenient place nor does it solve the enormous problem of trying to keep two articles in perfect synch.
Let me make myself perfectly clear: In your attempt to avoid a consensus for merging by desperately improving “divided” you are not permitted to “copy” every single one of my handy usability and navigation features from here, duplicate them over on “divided” and then completely delete every single spec of my work here. That is a simple breathtaking display of theft. You may “borrow” and “copy” my usability ideas here to make “divided” look better (something you’ve shown great facility at)—Wikipedia and all its readers are the beneficiaries when you do so. Both articles may be improved and from hereon, others get an opportunity to evaluate its merits now. Decisions will be made by “consensus.” If there is to be a consensus, it will be by many others weighing in as to whether or not this integrated approach is better. If there is to be a consensus, it will be whether or not to “merge” (delete) Isotope table (divided). Your behavior here is beginning to look like an ownership issue and you’ve taken it entirely upon yourself to decide what will be permitted. As you’ve no-doubt seen by now, I’ve put the proposed “merge” tag back into “divided” so others can come here and be able to make an informed decision on the matter. Wikipedia is a “collaborative” writing environment; get with the game plan. Greg L ( my talk) 16:15, 19 February 2008 (UTC)
I'm the one who originally created both of these pages, and there actually is a very important usability reason for having both "complete" and "divided" versions. The "complete" version requires two-dimensional scrolling in order to follow the stable elements down the center. Having a really long page is not a big hassle for web browsing, and is very common; there are many easy ways to scroll up and down a page and people are quite used to it. Scrolling side to side, on the other hand, is much less widely supported and isn't as intuitive. It also may play havoc with some skins and layouts (haven't checked this out in detail). On the other hand, having a complete version all in one table is quite handy and more informative than the broken-up version. So both versions have value that the other is missing, and so IMO deleting one or the other will decrease the total value Wikipedia is providing. Not a good option. If the complaint is simply one of difficulty of maintenance, perhaps we could use templates for the contents so that each set of tables is actually generated by the same "source". I suspect that'll make editing the table much harder for new editors, though, since it'll be harder to find the right bit. Bryan Derksen ( talk) 01:55, 20 February 2008 (UTC)
Please add solutions to the list below if you feel that none of the proposed solutions so far are ideal. The proposed solutions are:-
Download times with this option wouldn’t be any different from what we currently see with this article because the actual HTML download-code (551,702 bytes) wouldn’t change; what has to be slapped up on the screen doesn’t change even though things are done differently behind-the-scenes. However, that amount of download code is comparable to the very frequently visited United States article, which has an HTML download size of 536,156 bytes. In order to better calibrate our mental “sizeometers,” in should be further noted that 2007 Texas Longhorn football team is a 598,925-byte HTML download and Area codes in Germany is 686,475 bytes. We should keep our eyes peeled for template-related speed issues. But in the absence of any unexpected speed problems, download speed with dual-view tables should be a non-issue.
With option #5, where both views of the data are presented in one article, readers following a link to the article are immediately aware of both view options and can use the one that suits them at a particular moment. Its convenient “ ← Previous | Next → Go to Unitized table (all elements) Go to Periodic table ” nav tools make it a better solution than the two separate articles ever were; the sum is greater than the parts. If you want to scroll and see the unitized table, that’s all you see and deal with because it’s at the top. If you want to jump around in the segmented view using the new nav tools, you never have to mess around—or even see—the unitized table. And for those users who want to instantly skip between both views of the data, that’s now ultra-easy. Further, as there is only one “display” article, there is naturally only one venue for discussions. Greg L ( my talk) 22:11, 20 February 2008 (UTC)
Note, BTW, that a number of proposals above would violate the GFDL if implemented. The authorship information of past revisions needs to be retained to stay compliant. In instances where people are proposing to merge and delete an article, that needs to be interpreted as merge and redirect instead. Bryan Derksen ( talk) 02:49, 21 February 2008 (UTC)
I scripted some of the templates that, at the time, contributed to making these tables smaller in file size and easier to maintain. Unfortunately I am not able to follow the current discussion, so I cannot vote on any proposal, but I have a few principal stands:
Someone, at least one familiar with Femto's and my work, may translate this into a vote for the relevant proposal. -- Eddi ( Talk) 02:21, 22 February 2008 (UTC)
Anyway, file-size concerns are really beside the point. There are plenty of other articles on Wikipedia—like “ United States”—that are as large or larger than this one (HTML download-wise) and no one has a problem with the download speed of those. So attempted fixes for file size is a solution looking for a problem. The issues we’re wrestling with have to do with there being multiple places to the exact same data, multiple places to look at the data, and multiple places to discuss things. Fixing these shortcomings requires change and change is seldom accomplished without controversy. Greg L ( my talk) 03:45, 22 February 2008 (UTC)
I also mentioned earlier, the 2007 Texas Longhorn football team article (which is bigger yet) and it has no file-size-related discussions on its talk pages. If everyone made the Internet so it was optimized for people with phone modems, it would pretty much suck today, wouldn’t it? I once had to battle some user over picture size because he used a phone modem and a 640 × 480 monitor. He made it his hobby to shrink the pictures on every single Wikipedia article he visited if it was too big for his taste. No Web site today lays out their pages to this lowest-common-denominator anymore and 1024 × 768 is the new minimum.
As I’ve mentioned before (because you persist in raising this bogus issue), the 100 kB file-size recommendation is to keep regular, prose-based articles from becoming boring. Reference tables don’t suffer from this “boredom” issue because no one reads them from end to end. There’s only one valid size-related criteria to judge this on: does this article load fast enough for the vast majority of users. If it does, then we’re doing our job right. Past performance problems seem to have been associated with a lack of proper use of templates and all that seems to have been resolved. Can we move on now please? Greg L ( my talk) 07:44, 22 February 2008 (UTC)
The main reason for having separate pages, however, is not to let readers select an appropriate display format from a variety of options. Rather (this is a Wikipedia-wide consideration), it's to enable them to avoid viewing (loading, navigating) what they're not interested in.
So, I definitely don't subscribe to an "all in one place" view. Since the content of these tables is the same and the reader usually only needs one version, this means there should be two separate pages. (If maintainability, server load, or page size can be improved by using a master database template, I think I'd welcome it, but that's really a different, secondary issue.) Femto ( talk) 14:03, 22 February 2008 (UTC)
I'll discuss Quilbert's and related ideas here to avoid further cluttering the vote section.
At first I assumed it would use a differently named template for each row section or block, but he is putting all the data in one template, and returning different subsections of the data using a switch statement. Therefore the template will be at least as large as the complete table in the current article. It's also an open question how fast hundreds of evaluations of a very large template will be. If the MediaWiki software is smart about it, it may not be too bad, but it would also be easy for the server to handle such a case badly.
I do not see any seams in the prototype so far, so for the moment let's assume that issue is solved.
Greg describes the issues as "multiple places to edit the exact same data, multiple places to look at the data, and multiple places to discuss things". Evaluating Quilbert's proposal on each of these:
I fully support Quilbert’s work and am deeply appreciative that he read the arguments of the proponents and detractors of the various proposed solutions and… 1) recognized how to resolve the problems, 2) has the skills required to help, and 3) is willing to donate his time as a volunteer to actually do something about. This exploration into this new and (probably) better way of accomplishing this is going forward. It’s time JWB, to accept that reality and to recognize that we’re trying to make progress here. You need to stop throwing your sabot (wooden shoe) into the gear-works in futile attempts to make things grind to a halt. Quilbert, please contact me if there’s something I can do to help. Greg L ( my talk) 20:38, 22 February 2008 (UTC)
The new page requires no horizontal scrolling on 800 × 600-pixel screens. This is even smaller than the current standard for Web use ( ABC News, CNN News, and MSNBC News, to name a few, all require 1024-pixel-wide screens to avoid scrolling). By “no horizontal scrolling,” I am of course, referring to situations where the reader elects to skip over the Unitized table, which always requires horizontal scrolling (unless you’ve got multiple monitors totalling at least 3,856 pixels in width).
As I mentioned above, with this method, both views of the data are presented in one article so readers following a link to the article are immediately aware of both view options and can use whichever one suits them at a particular moment. Its convenient “ ← Previous | Next → Go to Unitized table (all elements) Go to Periodic table ” nav tools make it a better solution than the two separate articles ever were; the whole is greater than the sum of the parts. Further, the new nav tools I added lately make it much easier for the disabled. If you want to scroll and see the unitized table, that’s all you see and deal with because it is conveniently located near the top and is the first thing you encounter when you start scrolling. For “click-happy” readers (I’m one of ’em) who often like to jump around in the segmented view using the new nav tools, we never have to mess around—or even see—the unitized table. And any reader can now instantly skip between both views of the data without having to go to an entirely different article.
Although this is “change” (which rarely occurs on Wikipedia without objection), it doesn’t appear to me that there are any downsides to Quilbert’s way of maintaining data tables and displaying the information. I think it’s a fabulous way of doing things and its advantages are obvious and compelling: there’s only one place to visit for reading, only one place where users would naturally discuss issues, only one place to edit the data, and the article’s code becomes exceptionally tight (at 38,876 bytes, it’s smaller than it’s ever been before). This has my enthusiastic support. Greg L ( my talk) 22:03, 23 February 2008 (UTC)
Ok, now that we've restructured the nuclide data so that one data set can be used in multiple places, let's get back to the merge proposal itself. This innovation eliminates one of the arguments for the merge, which was that the merge would allow editing of nuclide data in only one article instead of two (or more). The remaining issue is whether to merge the two articles with different presentations of the same data into the one that currently displays both.
Please vote for or against the proposed merge of Isotope table (divided) into Isotope table (complete). For decidability, clarity, and process as specified in Wikipedia policy, this is a yes/no vote only on the merge, and not on other proposals later mentioned during the discussion, such as
The later or hypothetical proposals can have their own consensus building or vote if needed, after this merge proposal has been settled. -- JWB ( talk) 22:12, 25 February 2008 (UTC)
What sort of games are you trying to play now with your “[We’re not considering] enhancements such as navigation aids within the isotope table articles” and “[Users] can create a third article to their liking”? Is the question Merg vs. Not merge? Or is it Merge vs. Revert “complete” to what it was a month ago and keep “divided” like it is after you’ve ‘adopted’ all of Quilbert’s and my hard work? Greg L ( my talk) 22:55, 25 February 2008 (UTC)
Suprise! You were actually planning to implement it as if a “No merge” vote was really “Revert ‘ (complete)’ to the state it was at before I worked on the article but keep ‘ (divided)’ in the state it’s currently in after you ‘adopted’ all of Quilbert’s and my ideas and hard work.” Just pardon me all over if I wait until someone a teensy bit more trustworthy steps in to help fashion a consensus regarding what to do about ‘ (divided)’. I’d volunteer to do it myself but the steaming example you just served up may have prejudiced everyone as to what I might try to do. Greg L ( my talk) 02:05, 26 February 2008 (UTC)
→ Regarding your first bullet point: if you define “consensus” as comprising you and one other human being: the guy who did all the hard work, Quilbert, that would be true. But it isn’t. Like most everything else from you, it’s pasture patties. All your exchanges are memorialized above at #Generating table via templates. That’s just you and Quilbert talking up there. Call it for what it really is: I liked Quilbert’s template and knew it was the better way of doing it and that no one would complain since the advantages were obvious. You did too and revised “(divided)” the same way—and after I did. So ease up on this effort to paint a picture that you’re edits have been anointed with the benediction of “consensus”. It’s so damned tedious pointing out the details of every little misrepresentation of yours.
→ Regarding bullet point #2: More pasture patties. I did no “merge.” A merge (which deletes “divided”) is what you were trying to avoid above by trying to deceptively game the vote only a few hours ago! As it currently stands, this article is a multi-view and “(divided)” is a single-view page. But they both exist (and shouldn’t).
→ Regarding bullet point #3: Not even worthy of a response.
I’m quite done dealing with you directly. Wikipedia is supposed to be a fun hobby and singularly shouldering the burden of having to deal with you is highly un-fun. Don’t take that as an invitation to haul off and undo all that’s been done here. If you feel that “(complete)” threatens “(divided)”, that’s tough; what occurs here will be done by consensus. And by consensus, I mean as Wikipedia defines it, not you. I suggest you take a hint and get out of the business of trying to define the nature of any votes conducted here because your tactics are profoundly biased and questionable. P.S. In case you’re confused, that last one wasn’t a “personal attack” either; it’s the simple truth. Greg L ( my talk) 05:19, 26 February 2008 (UTC)
So far, when the most stable and the second most stable nuclear isomer are in the same color category, Iso1 is used. I wonder why. Please use Iso2 instead and double the color statement (except when both would be white). I have changed Iso2 in that a dotted border is displayed in that case. I have found this to apply to at least Xe-133 and Rh-102.
My second point is: When do we display white borders? When a nuclear isomer has been detected, even when it is extremely short-lived? -- Quilbert ( talk) 04:34, 26 February 2008 (UTC)
P.S. I’ll bet either JWB or V1adis1av can answer both our questions. Greg L ( my talk) 05:42, 26 February 2008 (UTC)
I’ll try to construct a proposal everyone might be satisfied by:
I hope that from here, we finally come to a consensus. -- Quilbert ( talk) 08:37, 26 February 2008 (UTC)
Thanks again and here are comments on your three proposal points:
And then good news: when the Wikipedia server isn’t burdened and other articles are loading quickly, the new “complete” page loads and refreshes very quickly too. Greg L ( my talk) 18:00, 26 February 2008 (UTC)
We editors here are all intimately familiar with these tables. But when I first encountered these tables, it was at “(divided)” and I didn’t quickly understand what I was looking at. I tend to skip over the introductory text on Wikipedia and wade down into the meat articles to get a feel for what I’m encountering. I think this is something many of us tend to do at times. As I scrolled down through the different tables, on first glance, they are separate tables that seemed to represent different data sets of some sort. So I scrolled back up and read the introductory text, which referenced the “(complete)” table.
Well, one quick look at “(complete)” and I had my “ah HA!” moment. I instantly understood that the segmented tables were just pieces of a huge, contiguous, unwieldily single table. Now, I’m no dummy; I’ve got 15 patents to my name and they’re all “deep” in the technological fields. So if it took me a moment to figure this out, I’m confident many novices landing on these pages for their first time will have the same experience.
This was the genesis of my desire to get both views into a single page. It would be a place where I could link to from other articles. I wouldn't have to land the reader in “(complete)”, where they instantly get the “ah HA!” but are burdened with its unwieldily nature. I wouldn’t have to land a reader in “(divided)” where some would have difficulty quickly grasping the basic concept (that the tables are fragments of a whole). Instead, one good scroll through a dual-view version would expose the reader to the concept in one fell swoop and provide instant access to the segmented tables.
With Quilbert’s approach, both versions of this article can coexist and serve a valid purpose. If editors choose to, readers can be directed to the dual-view version where a link would make readers aware of the divided-only version. Since this is Quilbert’s vision—and since this is where he is currently headed—I’ve added a link in “(complete)” that points to “(divided)” and I’ve withdrawn the merge-proposal tag from “(divided)”. Greg L ( my talk) 19:52, 26 February 2008 (UTC)
There is also an Isotope table (divided) with its own talk page that you may want to look at. |
For instructions on using templates in the isotope table, see Template talk:Iso1.
This is one of the largest pages i Wikipedia. I have therefore tried to reduce its size on the danish copy. In IE 6 it looks OK, but it might not in others. If you use another browser, try and have a look. Jan Pedersen 12:55 23 Jul 2003 (UTC)
Thanx Bryan. I have substituted all "<div style=background-color" with "<td bgcolor". It is now even smaller than before. Would you take another look using Mozilla? Jan Pedersen 08:19 24 Jul 2003 (UTC)
Thanx again Bryan. Now I see what you mean, now I don't ;-). When using the "Cologne blue" skin as I usually do, the standard stylesheet is not used. I therefore never saw the effect indicating the isotopes with meta states. Do you think the missig stylesheet should be reported as a bug? Jan Pedersen 09:05 25 Jul 2003 (UTC)
Conventionally, the axes are defined the other way round, so that isotopes of an element exist in a horizontal line. Would it be not to tricky to write a little script which reorders the table? Pstevenson 17:22, 28 Feb 2004 (UTC)
I was trying to link to all the istoscopes from the chart not finshed someone else please help put [[ ]] around element abbreviations -David
This is a very neat table. In Firefox, the bottom left gridlines are still visible, though. There is probably a way to make them invisible on all browsers. - Omegatron 19:24, Jun 23, 2005 (UTC)
Originally the
Nynorsk copy of this article was more than 90 kB, which caused a lot of trouble. The most noticeable was that software introduced errors during edit/save, e.g. the isotope 75Ge (in code: <small><sup>75</sup></small>Ge
) was changed to <small>Ge (in code: <small><sup>75</sup></small>Ge
), and another place the attribute bgcolor="#993399"
was changed to bgcolor="#993399"
resulting in a black cell.
In order to reduce the file size and avoid such errors, and also to make editing of the table easier, I introduced a couple of templates to take care of all the colours and <small>'s and <sup>'s. The file size was reduced to less than 45 kB (*) and editing is a lot easier now. There is one template for one-coloured cells (~2000) and one for two-coloured cells (~200), with simplified syntax for white cells or white borders. The two-colour template could do everything but uses more text to do it, and is only used for the two-coloured cells. The templates are described in more detail at the article's talk page. The template code is in English so I believe most of it is understandable, although the talk page is in Norwegian. -- Eddi (Talk) 00:48, 26 July 2005 (UTC) / -- Eddi (Talk) 12:38, 27 July 2005 (UTC)
(*) For comparison the Danish copy discussed above is 63 kB.
The cell separators could have been in the templates but were left out to maintain a kind of uniformity in the table coding. Since it would only free about 2 kB out of 43 anyway, I think it's OK. Theoretically it allows for extra attributes such as font effects in individual table cells, which wouldn't work if the separators were in the templates, although I see no current need for such attributes. The same templates may also be used rather neatly in other contexts, e.g. the half-life colour chart on top of the article, like this:
{| align=right cellpadding=2 cellspacing=0 border=1 |+ '''[[Half-life|Half-lives]]''' (example: [[Gadolinium|Gd]]) |- | {{Iso1|145|Gd|-}} || Unstable |- | {{Iso1|146|Gd|V}} || 1-10 [[day]]s |- | {{Iso1|149|Gd|I}} || 10-100 days |- | {{Iso1|153|Gd|B}} || 100 days - 10 [[year]]s |- | {{Iso1|148|Gd|G}} || 10-10,000 years |- | {{Iso1|150|Gd|Y}} || >10,000 years |- | {{Iso1|152|Gd|O}} || Natural [[radioactive]] |- | {{Iso1|158|Gd|R}} || Stable |} |
|
Regarding escaped characters I don't really know what causes the errors, but I use Opera, too. I try to avoid errors by always previewing my edits and sorting out obvious flaws, then searching for any additonal <'s, >'s, "'s, &'s etc. (or just &'s or ;'s) that may have been introduced while pressing 'Preview', and in the end I just cross my fingers while pressing 'Save'... Not very scientific, that is. -- Eddi (Talk) 12:38, 27 July 2005 (UTC)
Would it be a good idea to introduce similar templates in the English copy? It would involve 2 main templates (Iso1 and Iso2) plus 8 colour templates (e.g. Iso/R containing the string ff9999). If such templates should be used here, would it be easier to transform it locally or translate the Nynorsk copy? The English copy contains a whole bunch of recently discovered unstable isotopes of both light and heavy weight that are not (yet) included in the Nynorsk copy. -- Eddi (Talk) 22:58, 27 July 2005 (UTC)
I have now proofread the draft table with respect to colours, and all the coloured cells have correct backgrounds and borders. I have not checked to see if all white cells are included, or if all links to special isotopes are in place. To check this I would like to overwrite the existing table with the templated one, and then look at the history diff to spot any missing cells or links. Would that be all right? -- Eddi (Talk) 12:56, 4 August 2005 (UTC)
If/when the templates are introduced in the live table, there must be an instruction for the use of the templates. I can copy the essentials from :nn. Should the instruction be in Template talk:Iso1 / Template talk:Iso2 or a section of Talk:Isotope table (complete)? (By the way, I think there should also be a more detailed explanation of the various border colours. This could be placed together with the template instructions.) -- Eddi (Talk) 12:56, 4 August 2005 (UTC)
I noticed that the draft table has "shadow" cell borders, that is, grey to the left/upside and white to the right/bottom. I think this may obscure the rightfully white borders of isotopes with multiple decay pathways. Could we keep the simple, grey cell borders of the current table? -- Eddi (Talk) 12:56, 4 August 2005 (UTC)
Now that the templates have gone live in the complete table, how about the divided table? (As you might expect, I'm all in favour.) Should the existing divided table be transformed, or should the already transformed complete table be divided? -- Eddi (Talk) 23:42, 4 August 2005 (UTC)
Some of Talk:Isotope table (divided) is also valid for the complete table, and vice versa. I suppose a redirect may be too drastic, but there could at least be a prominently displayed link between the talk pages. -- Eddi (Talk) 22:14, 10 August 2005 (UTC)
I have now inserted red boxes on top of each talk page with links in both directions. I didn't designate any of them as parent or child, but that may be done with little extra effort. -- Eddi (Talk) 20:59, 18 August 2005 (UTC)
Oh, this is lovely! When you are done, please come to WP:FLC to nominate it as a Featured list. -- ALoan (Talk) 12:58, 19 August 2005 (UTC)
If the isotope table is going to be nominated as a featured list candidate, I think a few issues should be addressed to meet the FLC criteria on usefulness, comprehensiveness, and accuracy (I believe the other criteria are already met):
A formal project may not be required, but a group of editors should be ready and prepared to handle any shortcomings of the article during the nomination period. I'll set up a list of interested editors below – feel free to add your name. -- Eddi (Talk) 20:52, 4 September 2005 (UTC)
Just got confirmation from Bryan that the now defunct http://www2.bnl.gov/CoN/nuchart1.html (BNL), which was the source for this data, indeed is the same site as the archive.org'ed [1]. (You might have to turn on javascript, play around with the link, and/or replace the date string with an asterisk to get that silly thing to work.) Their reference was given as
Femto 11:42, 10 September 2005 (UTC)
I cannot understand why International Atomic Energy Agency gets credit for Interactive Table of Nuclides? Interactive Table of Nuclides ( http://www.nndc.bnl.gov/nudat2) is developed and maintained by the National Nuclear Data Center (NNDC) at Brookhaven National Laboratory. International Atomic Energy Agency is only hosting it, providing the second installation in addition to NNDC.
So whichever is the exact meaning of "stable" or "natural radioactive", our definitions are BNL's definitions. Apparently, http://atom.kaeri.re.kr/ is the direct successor of that page, maybe there's also something buried in their FAQ. In the long run, and before a featured nomination, I agree though that it's absolutely essential for these articles to set their own definitions. There does seem to be no Wikipedia-wide agreement on those terms, let alone on the web. Femto 11:42, 10 September 2005 (UTC)
Commit myself? I'm crazy, but I'm not that crazy. :p Femto 11:42, 10 September 2005 (UTC)
Inspired by the Danish version of the isotope table, lighter colours were introduced in the Norwegian version by simple manipulation of the 8 colour templates. The contrast between cell text and background colours improved very much, not only for blue and red wikilinked text but also for normal black text. Compare the English version with any of those or, for an instant comparison, see the half-life colour chart in the Norwegian test version. Various colours have been discussed for various purposes at the isotope project and the deep colours were apparently chosen for the isotope table at some point, but I gather nothing is set in stone. Are there any objections to lighter colours here, perhaps except that it shouldn't be done before the templates have been implemented in the divided table? -- Eddi (Talk) 23:44, 19 August 2005 (UTC)
As mentioned by Femto above, some isotopes were missing in either the complete table or the divided table. I have now added or corrected the following entries in each table:
-- Eddi (Talk) 03:17, 4 September 2005 (UTC)
Can we somehow make the colour chart float over the article so that it's still visible when scrolling down and right through the isotope table? -- Eddi (Talk) 12:38, 27 July 2005 (UTC)
145Gd | < 1 day |
149Gd | 1–10 days |
146Gd | 10–100 days |
153Gd | 100 days–10 a |
148Gd | 10–10,000 a |
150Gd | 10 ka–700 Ma |
152Gd | > 700 Ma |
158Gd | Stable |
Cell | Code | Title | Code of title part of cell |
93Nb |
{{iso2|93|Nb|R|G}} |
Half-life – Isotope: Stable; Nuclear isomer: 10–10,000 years | Half-life – Isotope: {{iso/R/text}}; Nuclear isomer: {{iso/G/text}} |
91Nb |
{{iso2|91|Nb|Y|I}} |
Half-life – Isotope: 10k–103M years; Nuclear isomer: 10–100 days | Half-life – Isotope: {{iso/Y/text}}; Nuclear isomer: {{iso/I/text}} |
89Zr |
{{iso2|89|Zr|V|-}} |
Half-life – Isotope: 1–10 days; Nuclear isomer: < 1 day | Half-life – Isotope: {{iso/V/text}}; Nuclear isomer: {{iso/-/text}} |
The two-coloured cell for Ta 180 indicates that there is a nuclear isomer that is unstable (the white border). However, elsewhere on Wikipedia (under "nuclear isomer") we are told that Ta 180 has the only stable nuclear isomer.
One of these must be wrong - I suspect the first, since elsewhere there is reference to Ta 180 isomer stability - see [3].
I'm not sure if I can edit this, perhaps someone can have a go?
Edit - had a go now - looks ok
i fixed the one under He (moved column down), but others exist and should be filled in. e.g. 28S has a pretty long half life.. Eupedia 05:58, 5 April 2006 (UTC)
145Gd | < 1 day |
149Gd | 1–10 days |
146Gd | 10–100 days |
153Gd | 100 days–10 a |
148Gd | 10–10,000 a |
150Gd | 10 ka–700 Ma |
152Gd | > 700 Ma |
158Gd | Stable |
is there another version of this on the wiki that shows richer data for each isotope? plans for one? here's an idea: alternate text that would give the richer data upon mouseover somehow. not sure how to implement, tho. 24.5.187.236 06:02, 6 April 2006 (UTC)
Most charts that I have seen include the free neutron (p=0, n=1), as a natural extension of the table next to deuterium. The free neutron article even includes a mini-isotope-table picture (shown at right) with the free neutron included in the table. The neutron undergoes beta decay, just like many other nuclides, and has a known half-life (which according to the article is 15 minutes), so I think it should be included in the isotope table. Spoon! 02:54, 28 June 2006 (UTC)
This chart shows an isotope Helium-2, yet that is not listed in Isotopes of helium. Which is correct? Should Helium-2 be added to Isotopes of Helium, or should it be removed from here? Nik42 01:03, 15 September 2006 (UTC)
It has already been discussed above: The term "natural radioactive" is unclear. I think the corresponding entries should be divided up into the other categories. The source from which the data had been taken in the first place soon after changed their own data so that "natural radioactive" was no longer present. However, I don't have a problem with "stable". It says: "This nuclide is belived to be (absolutely) stable."/"No decay has been observed." Also, I agree with Spoon! that the neutron should be added. Quilbert 18:34, 26 January 2007 (UTC)
Most of the "natural radioactive" cells would fit in a "very long halflife" category with a threshold of, say 500 million years to include 235U. Also, a reasonable meaning of "natural radioactive" would be isotopes that have survived on the Earth during its lifetime. I agree that listing the few shortlived members in this category is misleading and that they should be classified according to their halflife:
3T 12.32a | 10Be 1.51E+6a | 14C 5.70E+3a | 215At .10ms | 231Pa 3.27E+4 a | 234Pa 6.70h | 234U 2.455E+5a |
-- JWB 06:06, 20 April 2007 (UTC)
Lead-204 is marked as having an isomer of >10000 years, but Isotopes of lead does not seem to list it. Does anyone know where this came from? -- JWB 08:21, 20 April 2007 (UTC)
How do you feel about using gray for stable isotopes?
I'm going to give gray (BBB) a try as nobody has objected so far. Discuss here or at Template talk:Iso1. -- JWB 19:05, 28 June 2007 (UTC)
Now that gray represents the most stable isotopes, I think we should also reverse the order of colors for the rest of the stability range so that darker, cooler colors (gray, purple, blue) represent more stable isotopes, and lighter, warmer colors (orange, yellow, white) represent less stable isotopes. -- IanOsgood ( talk) 19:53, 25 November 2007 (UTC)
In one way that's intuitive, but on the other hand it's reversed for glowing hot bodies, which start at red hot and move towards blue with increasing temperature, although the middle of this temperature spectrum is white instead of green. See Color temperature and Black body#Explanation. -- JWB ( talk) 20:16, 25 November 2007 (UTC)
Sure. However, humans have a different perception of color warmth. See Color symbolism and psychology and search for "warm". A lightness gradient from dark gray to white also makes the table look better on the typical white page background. -- IanOsgood 17:11, 3 December 2007 (UTC)
Any color comes in lighter or darker versions. Or are you proposing using grays only? -- JWB ( talk) 17:45, 18 December 2007 (UTC)
I fixed the colors of long-lived and stable isotopes as them are known today. Namely, the following changes were made:
Let me give a list of 31 nuclides that are known to be radioactive with half-life >7E8 yr (i.e. primordial radioactive nuclides) as for today (decay modes: alpha (a), beta (b), double beta (2b), spontaneous fusion (SF), cluster emission(CE)):
40-K (b), 48-Ca (2b), 50-V (b), 76-Ge (2b), 82-Se (2b), 87-Rb (b), 96-Zr (2b), 100-Mo (2b), 113-Cd (b), 116-Cd (2b), 115-In (b), 128-Te (2b), 130-Te (2b), 130-Ba (2b), 138-La (b), 144-Nd (a), 150-Nd (2b), 147-Sm (a), 148-Sm (a), 151-Eu (a), 152-Gd (a), 176-Lu (b), 174-Hf (a), 180-W (a), 187-Re (b), 186-Os (a), 190-Pt (a), 209-Bi (a), 232-Th (a, SF), 235-U (a, CE), 238-U (a, 2b, SF).
V1adis1av
14:40, 25 August 2007 (UTC)
This footnote, from Kilogram explains something clear enough:
Accordingly, I changed the color coding for 209Bi to “stable” (grey) but added a hidden editors note explaining the rationale for labeling it as so. Greg L ( my talk) 06:57, 3 February 2008 (UTC)
I don’t see any reason (even file-size-related ones) as to why Isotope table (divided) and this article can’t be merged into one featuring both styles of table. Why do the two styles have to be on separate pages so that two articles have to be maintained?
I don’t believe a case can be made now that two articles are necessary due to file-size issues. I see from this post: Templates make editing easier and file size is halved, that problems seemed to occur only when files grew to the 63–180 kB size range. That was back in 2005 though. Since then, templates have reduced this article to only 48 kB and the other is only 50 kB. And, of course, browsers have been updated since then to handle more complicated Web pages (and larger ones too, presumably). Isn’t it time to try a merged version? I suspect it would be under 100 kB and I’m sure modern browsers can handle that; after all, United States is 161 kB.
Maintaining two articles that are supposed to have identical content is not the way to do things on Wikipedia.
Having said all that, my highest complements to all who’ve worked on his—especially Eddi. Making templates takes a lot of time and his donation of all his time had to have been a real labor of love. This article is extremely useful and is an awesome resource. It would sure be nice though, to not have two of them to maintain. Greg L ( my talk) 18:33, 3 February 2008 (UTC)
I think the virtues of this unitized method are many: There is now a handy pictorial representation of the periodic table immediately below the TOC so users can quickly look up exactly which sub-section to click on. Further, links to this article from elswewhere on Wikipedia can now take a reader directly to an element of interest while still giving the reader freedom to scroll the entire contents of what used to be two entirely separate (but totally redundant) articles. Greg L ( my talk) 22:41, 17 February 2008 (UTC)
Sorry I missed your earlier query. I think this is a bad idea that if anything is negative for usability. It's precisely because the content is redundant that there is little reason for a reader to need both copies in one scroll. The whole idea of the divided table is to reduce the need for horizontal scrolling in the first place. If we are going to have an even bigger area to scroll through, that frustrates the original intent and we might as well get rid of the divided table.
Putting them on one page does nothing to make maintenance easier. You still have to maintain two copies of each entry, but have to do even more scrolling. If you could find a way to generate both formats from a single list that would not need double maintenance, then that might be useful.
50k is about the limit where splitting is suggested, plus this page is one of the slowest to load anyway, presumably because of the template evaluation. One reason I have spent a good deal of effort getting rid of empty cells is to reduce size and load/display time. Also, server load will be approximately doubled by putting both tables on one page. -- JWB ( talk) 02:07, 18 February 2008 (UTC)
I am truly astonished that the articles could be maintained and synchronized as well as they have been thus far. The whole notion of having two, independent discussion forums(!) to debate content issues in two articles that are supposed to stay in perfect synch—while novel—is nearly beyond belief. Greg L ( my talk) 02:54, 18 February 2008 (UTC)
I was expecting the periodic table image to be an image map that would take you straight to a particular element, but looks like it's just a picture.
→That’s a natural reaction and I doubt you’ll be the last to do it (once). I did my best with the caption: Use this pictorial
periodic chart as a guide in selecting the desired table from Contents below. Still, it’s quite handy. One can be directed to this article from, for instance, the
Kilogram article where they were reading up on
Bismuth. A handy periodic chart helps to figure out which isotope group to click on in the TOC.
Greg L (
my talk)
07:44, 18 February 2008 (UTC)
Looks like you placed the color key on each segment of the divided table. That's good, but could have been done as easily without combining the two pages, and does nothing for the single table. Not sure what other usability enhancements you are talking about.
I have always used the single table. It is harder to trace decay chains and trends across the divided table boundaries. The divided table segments are also smaller than they could be.
Render speed for the page seems fast, but when I edited the page, preview took 27 sec. I've experienced much slower before, so the server/load ratio must be better than at those times.
→I agree; slow for editors. Sweet for readers as they now “have it all” in one convenient place.
Greg L (
my talk)
07:44, 18 February 2008 (UTC)
There are more then two discussion forums - a lot of the discussion also happened at Template_talk:Iso1 and probably elsewhere. It's all too common and hard to avoid for discussion of a topic to spread over multiple articles, templates, etc. Eliminating just one page is not going to eliminate the problem. You still have to monitor and post on multiple pages. For the issue of updating specific entries in the table, it seems to have been handled by editors updating both, or at least posting in Talk saying what they did in one. But, as noted, two independent entries for each isotope still have to be kept in sync, it's just that they are on one large page. -- JWB ( talk) 06:52, 18 February 2008 (UTC)
Also, have you noticed how many versions of the Periodic table exist and are separate articles? -- JWB ( talk) 18:16, 18 February 2008 (UTC)
Also note when you edit this article or the divided table and preview, you get a warning message "This page is 101 kilobytes long.", or 53 for the divided table page. This is to tell you that the page is getting longer than recommended by policy. -- JWB ( talk) 18:11, 18 February 2008 (UTC)
Please see Wikipedia:Article_size#A rule of thumb. -- JWB ( talk) 18:26, 18 February 2008 (UTC)
Let’s also be fair while referencing Wikipedia advise on file size. The very article you referenced above stated here that “With some web browsers with certain plug-ins running in certain environments, articles over 400K may not render properly…” and went on to discuss browser limitations. The “100 kB” recommended size is borne out of desire to ensure that regular prose-based articles don’t suffer from bloat-itis and become boring. Notwithstanding this policy, there are still 28 Wikipedia articles that exceed 200 kB, and one, ( link to article) that is 430 kB! Anyway, non-prose reference tables are immune to this “boredom-based” file-size concern; they are almost entirely reference data. The beauty of Wikipedia is we can use the power of web browsers to make it extraordinarily easy to find what one is looking for and we have extraordinary flexibility in presenting the data to the reader. The past performance problems with these isotope tables seem to have been fixed—largely due to efforts of people like Eddie, who made the extraordinarily efficient templates they rely upon.
Now that this article has enhanced usability features like the ← Previous | Next → navigation links, color-code legends in each section, and the periodic table visual reference guide, this integrated version is, IMO, far more convenient than the separate versions ever were as stand-alones; the whole is greater than the sum of the parts. Absent any compelling performance problems (which I doubt will crop up due to modern browsers and Eddie’s work), it no longer makes sense to split up two views of identical content.
I think we’ve both conveyed our positions quite well here and suggest that we sit back and see how others feel about this. Clearly, there are going to be those who are disappointed with the change, want things back to the old ways, and will quickly find their way here to weigh-in. But hopefully, some users who visit this article and like it, will see fit to come to this discussion page and post a quick note regarding their impressions. To other authors and readers: please weigh in regarding performance issues. Notwithstanding that this article “previews” rather slowly while editing, does it suffer from performance issues when it loads while browsing? Greg L ( my talk) 20:47, 18 February 2008 (UTC)
Two exceptions are lists, and articles summarizing certain fields. These act as summaries and starting points for a field and in the case of some broad subjects or lists either do not have a natural division point or work better as a single article. In such cases, the article should nonetheless be kept short where possible.
I don’t pretend to speak for everyone else on Wikipedia and I hope you aren’t either. It seems the two articles have diverged into separate camps with their own turf when the original reason for bifurcating it in the first place—performance issues—no longer exists. The only real measures of whether this article is now better is to see how well received it is by the larger community and whether some users experience performance issues. It’s time now to take a deep breath and let others express their opinion too, JWB. My bet is that others will like this newly integrated multi-view with its “ ← Previous | Next → ” nav tools and other enhancements. I might be wrong; we’ll see. Greg L ( my talk) 00:46, 19 February 2008 (UTC)
P.S. I withdrew the merge tag myself. I wasn’t trying to piss in someone’s cornflakes; I thought that since all the damned info had been copied over, it was the proper thing to do. Fighting this has been most un-fun and I can think of better things to do. Greg L ( my talk) 02:34, 19 February 2008 (UTC)
JWB: A “consensus” isn’t required for an editor to edit or expand this article. A wider consensus is only required if Isotope table (divided) is to be merged (deleted) in the process. It is wholly inappropriate and in exceedingly bad form for you to copy and mimic the enhancement and features I’ve implemented here and then simply delete all my work before other editors have had a chance to evaluate its merits and voice their opinion. Here’s what “divided” looked like before I started my work over here, and here’s what it looked like after you copied many of my improvements and then deleted my improvements from here. When done the way you just did it, it’s no longer “copying” and is just simple “stealing.” What an astonishingly large degree of gall that took. It’s also a metric ton of weapons-grade bullonium and I’ll have none of it. Such behavior is simply not tolerated on Wikipedia and there are remedies such as Wikiquette alerts if you continue to operate this way.
In your edit summary where you deleted all my work, you wrote “Moved back to Isotope table (divided), if merge is approved by consensus, can move back here.” There was no “move” from “divided” to here, “divided” was left completely alone. If there was a “move” of any sort, it was when you copied all my ideas and hard work and then deleted them all here; now that’s a “move.” You need to be honest with your edits and your edit summaries and your discussions. If your position is that Wikipedia is better off by continuing to have the articles separate, then you must let others weigh in on the matter instead of taking upon yourself to delete the tables I added.
After several days of your furious typing here about integrating these two articles, you have been the only one who has objected to the integrated approach. No one is even afforded an opportunity to look at the possible advantages when you just delete it all. Having a single article to maintain makes just too much sense sense and I can’t help it if this possibly-better way of doing it threatens your desire to retain Isotope table (divided); it’s time to let others voice their opinion on the matter. Your arguments about file size issues are a red herring and have nothing to do with the matter; download speed is plenty fast.
My position is simple: Independently maintaining absolutely identical isotope data in two separate articles, each with its own separate discussion venue(!?!) makes absolutely no sense. Experts on isotopes who aren’t as proficient as you and I at editing Wikipedia often won’t even know to go hunt down the other article and make the exact same edits there. The “100 kB” recommended size you’ve referred to was borne out of desire to ensure that regular prose-based articles don’t suffer from bloat-itis and become boring. Notwithstanding this policy, there are still 28 Wikipedia articles that exceed 200 kB, and one, ( link to article) that is 430 kB! Non-prose reference tables are immune to this “boredom-based” file-size concern; they are almost entirely reference data. The beauty of Wikipedia is we can use the power of web browsers to make it extraordinarily easy to find what one is looking for and we have extraordinary flexibility in presenting the data to the reader. The past performance problems with these isotope tables seem to have been fixed—largely due to efforts of people like Eddie, who made the extraordinarily efficient templates they rely upon.
I think other editors and users will find that my proposed method is a convenient-to-use and attractive way of doing things but they have to be able to see and try the proposed new way (which you’ve copied the crap out of) in order to be able to offer an opinion! Still, all your copying doesn’t put both types of table in one convenient place nor does it solve the enormous problem of trying to keep two articles in perfect synch.
Let me make myself perfectly clear: In your attempt to avoid a consensus for merging by desperately improving “divided” you are not permitted to “copy” every single one of my handy usability and navigation features from here, duplicate them over on “divided” and then completely delete every single spec of my work here. That is a simple breathtaking display of theft. You may “borrow” and “copy” my usability ideas here to make “divided” look better (something you’ve shown great facility at)—Wikipedia and all its readers are the beneficiaries when you do so. Both articles may be improved and from hereon, others get an opportunity to evaluate its merits now. Decisions will be made by “consensus.” If there is to be a consensus, it will be by many others weighing in as to whether or not this integrated approach is better. If there is to be a consensus, it will be whether or not to “merge” (delete) Isotope table (divided). Your behavior here is beginning to look like an ownership issue and you’ve taken it entirely upon yourself to decide what will be permitted. As you’ve no-doubt seen by now, I’ve put the proposed “merge” tag back into “divided” so others can come here and be able to make an informed decision on the matter. Wikipedia is a “collaborative” writing environment; get with the game plan. Greg L ( my talk) 16:15, 19 February 2008 (UTC)
I'm the one who originally created both of these pages, and there actually is a very important usability reason for having both "complete" and "divided" versions. The "complete" version requires two-dimensional scrolling in order to follow the stable elements down the center. Having a really long page is not a big hassle for web browsing, and is very common; there are many easy ways to scroll up and down a page and people are quite used to it. Scrolling side to side, on the other hand, is much less widely supported and isn't as intuitive. It also may play havoc with some skins and layouts (haven't checked this out in detail). On the other hand, having a complete version all in one table is quite handy and more informative than the broken-up version. So both versions have value that the other is missing, and so IMO deleting one or the other will decrease the total value Wikipedia is providing. Not a good option. If the complaint is simply one of difficulty of maintenance, perhaps we could use templates for the contents so that each set of tables is actually generated by the same "source". I suspect that'll make editing the table much harder for new editors, though, since it'll be harder to find the right bit. Bryan Derksen ( talk) 01:55, 20 February 2008 (UTC)
Please add solutions to the list below if you feel that none of the proposed solutions so far are ideal. The proposed solutions are:-
Download times with this option wouldn’t be any different from what we currently see with this article because the actual HTML download-code (551,702 bytes) wouldn’t change; what has to be slapped up on the screen doesn’t change even though things are done differently behind-the-scenes. However, that amount of download code is comparable to the very frequently visited United States article, which has an HTML download size of 536,156 bytes. In order to better calibrate our mental “sizeometers,” in should be further noted that 2007 Texas Longhorn football team is a 598,925-byte HTML download and Area codes in Germany is 686,475 bytes. We should keep our eyes peeled for template-related speed issues. But in the absence of any unexpected speed problems, download speed with dual-view tables should be a non-issue.
With option #5, where both views of the data are presented in one article, readers following a link to the article are immediately aware of both view options and can use the one that suits them at a particular moment. Its convenient “ ← Previous | Next → Go to Unitized table (all elements) Go to Periodic table ” nav tools make it a better solution than the two separate articles ever were; the sum is greater than the parts. If you want to scroll and see the unitized table, that’s all you see and deal with because it’s at the top. If you want to jump around in the segmented view using the new nav tools, you never have to mess around—or even see—the unitized table. And for those users who want to instantly skip between both views of the data, that’s now ultra-easy. Further, as there is only one “display” article, there is naturally only one venue for discussions. Greg L ( my talk) 22:11, 20 February 2008 (UTC)
Note, BTW, that a number of proposals above would violate the GFDL if implemented. The authorship information of past revisions needs to be retained to stay compliant. In instances where people are proposing to merge and delete an article, that needs to be interpreted as merge and redirect instead. Bryan Derksen ( talk) 02:49, 21 February 2008 (UTC)
I scripted some of the templates that, at the time, contributed to making these tables smaller in file size and easier to maintain. Unfortunately I am not able to follow the current discussion, so I cannot vote on any proposal, but I have a few principal stands:
Someone, at least one familiar with Femto's and my work, may translate this into a vote for the relevant proposal. -- Eddi ( Talk) 02:21, 22 February 2008 (UTC)
Anyway, file-size concerns are really beside the point. There are plenty of other articles on Wikipedia—like “ United States”—that are as large or larger than this one (HTML download-wise) and no one has a problem with the download speed of those. So attempted fixes for file size is a solution looking for a problem. The issues we’re wrestling with have to do with there being multiple places to the exact same data, multiple places to look at the data, and multiple places to discuss things. Fixing these shortcomings requires change and change is seldom accomplished without controversy. Greg L ( my talk) 03:45, 22 February 2008 (UTC)
I also mentioned earlier, the 2007 Texas Longhorn football team article (which is bigger yet) and it has no file-size-related discussions on its talk pages. If everyone made the Internet so it was optimized for people with phone modems, it would pretty much suck today, wouldn’t it? I once had to battle some user over picture size because he used a phone modem and a 640 × 480 monitor. He made it his hobby to shrink the pictures on every single Wikipedia article he visited if it was too big for his taste. No Web site today lays out their pages to this lowest-common-denominator anymore and 1024 × 768 is the new minimum.
As I’ve mentioned before (because you persist in raising this bogus issue), the 100 kB file-size recommendation is to keep regular, prose-based articles from becoming boring. Reference tables don’t suffer from this “boredom” issue because no one reads them from end to end. There’s only one valid size-related criteria to judge this on: does this article load fast enough for the vast majority of users. If it does, then we’re doing our job right. Past performance problems seem to have been associated with a lack of proper use of templates and all that seems to have been resolved. Can we move on now please? Greg L ( my talk) 07:44, 22 February 2008 (UTC)
The main reason for having separate pages, however, is not to let readers select an appropriate display format from a variety of options. Rather (this is a Wikipedia-wide consideration), it's to enable them to avoid viewing (loading, navigating) what they're not interested in.
So, I definitely don't subscribe to an "all in one place" view. Since the content of these tables is the same and the reader usually only needs one version, this means there should be two separate pages. (If maintainability, server load, or page size can be improved by using a master database template, I think I'd welcome it, but that's really a different, secondary issue.) Femto ( talk) 14:03, 22 February 2008 (UTC)
I'll discuss Quilbert's and related ideas here to avoid further cluttering the vote section.
At first I assumed it would use a differently named template for each row section or block, but he is putting all the data in one template, and returning different subsections of the data using a switch statement. Therefore the template will be at least as large as the complete table in the current article. It's also an open question how fast hundreds of evaluations of a very large template will be. If the MediaWiki software is smart about it, it may not be too bad, but it would also be easy for the server to handle such a case badly.
I do not see any seams in the prototype so far, so for the moment let's assume that issue is solved.
Greg describes the issues as "multiple places to edit the exact same data, multiple places to look at the data, and multiple places to discuss things". Evaluating Quilbert's proposal on each of these:
I fully support Quilbert’s work and am deeply appreciative that he read the arguments of the proponents and detractors of the various proposed solutions and… 1) recognized how to resolve the problems, 2) has the skills required to help, and 3) is willing to donate his time as a volunteer to actually do something about. This exploration into this new and (probably) better way of accomplishing this is going forward. It’s time JWB, to accept that reality and to recognize that we’re trying to make progress here. You need to stop throwing your sabot (wooden shoe) into the gear-works in futile attempts to make things grind to a halt. Quilbert, please contact me if there’s something I can do to help. Greg L ( my talk) 20:38, 22 February 2008 (UTC)
The new page requires no horizontal scrolling on 800 × 600-pixel screens. This is even smaller than the current standard for Web use ( ABC News, CNN News, and MSNBC News, to name a few, all require 1024-pixel-wide screens to avoid scrolling). By “no horizontal scrolling,” I am of course, referring to situations where the reader elects to skip over the Unitized table, which always requires horizontal scrolling (unless you’ve got multiple monitors totalling at least 3,856 pixels in width).
As I mentioned above, with this method, both views of the data are presented in one article so readers following a link to the article are immediately aware of both view options and can use whichever one suits them at a particular moment. Its convenient “ ← Previous | Next → Go to Unitized table (all elements) Go to Periodic table ” nav tools make it a better solution than the two separate articles ever were; the whole is greater than the sum of the parts. Further, the new nav tools I added lately make it much easier for the disabled. If you want to scroll and see the unitized table, that’s all you see and deal with because it is conveniently located near the top and is the first thing you encounter when you start scrolling. For “click-happy” readers (I’m one of ’em) who often like to jump around in the segmented view using the new nav tools, we never have to mess around—or even see—the unitized table. And any reader can now instantly skip between both views of the data without having to go to an entirely different article.
Although this is “change” (which rarely occurs on Wikipedia without objection), it doesn’t appear to me that there are any downsides to Quilbert’s way of maintaining data tables and displaying the information. I think it’s a fabulous way of doing things and its advantages are obvious and compelling: there’s only one place to visit for reading, only one place where users would naturally discuss issues, only one place to edit the data, and the article’s code becomes exceptionally tight (at 38,876 bytes, it’s smaller than it’s ever been before). This has my enthusiastic support. Greg L ( my talk) 22:03, 23 February 2008 (UTC)
Ok, now that we've restructured the nuclide data so that one data set can be used in multiple places, let's get back to the merge proposal itself. This innovation eliminates one of the arguments for the merge, which was that the merge would allow editing of nuclide data in only one article instead of two (or more). The remaining issue is whether to merge the two articles with different presentations of the same data into the one that currently displays both.
Please vote for or against the proposed merge of Isotope table (divided) into Isotope table (complete). For decidability, clarity, and process as specified in Wikipedia policy, this is a yes/no vote only on the merge, and not on other proposals later mentioned during the discussion, such as
The later or hypothetical proposals can have their own consensus building or vote if needed, after this merge proposal has been settled. -- JWB ( talk) 22:12, 25 February 2008 (UTC)
What sort of games are you trying to play now with your “[We’re not considering] enhancements such as navigation aids within the isotope table articles” and “[Users] can create a third article to their liking”? Is the question Merg vs. Not merge? Or is it Merge vs. Revert “complete” to what it was a month ago and keep “divided” like it is after you’ve ‘adopted’ all of Quilbert’s and my hard work? Greg L ( my talk) 22:55, 25 February 2008 (UTC)
Suprise! You were actually planning to implement it as if a “No merge” vote was really “Revert ‘ (complete)’ to the state it was at before I worked on the article but keep ‘ (divided)’ in the state it’s currently in after you ‘adopted’ all of Quilbert’s and my ideas and hard work.” Just pardon me all over if I wait until someone a teensy bit more trustworthy steps in to help fashion a consensus regarding what to do about ‘ (divided)’. I’d volunteer to do it myself but the steaming example you just served up may have prejudiced everyone as to what I might try to do. Greg L ( my talk) 02:05, 26 February 2008 (UTC)
→ Regarding your first bullet point: if you define “consensus” as comprising you and one other human being: the guy who did all the hard work, Quilbert, that would be true. But it isn’t. Like most everything else from you, it’s pasture patties. All your exchanges are memorialized above at #Generating table via templates. That’s just you and Quilbert talking up there. Call it for what it really is: I liked Quilbert’s template and knew it was the better way of doing it and that no one would complain since the advantages were obvious. You did too and revised “(divided)” the same way—and after I did. So ease up on this effort to paint a picture that you’re edits have been anointed with the benediction of “consensus”. It’s so damned tedious pointing out the details of every little misrepresentation of yours.
→ Regarding bullet point #2: More pasture patties. I did no “merge.” A merge (which deletes “divided”) is what you were trying to avoid above by trying to deceptively game the vote only a few hours ago! As it currently stands, this article is a multi-view and “(divided)” is a single-view page. But they both exist (and shouldn’t).
→ Regarding bullet point #3: Not even worthy of a response.
I’m quite done dealing with you directly. Wikipedia is supposed to be a fun hobby and singularly shouldering the burden of having to deal with you is highly un-fun. Don’t take that as an invitation to haul off and undo all that’s been done here. If you feel that “(complete)” threatens “(divided)”, that’s tough; what occurs here will be done by consensus. And by consensus, I mean as Wikipedia defines it, not you. I suggest you take a hint and get out of the business of trying to define the nature of any votes conducted here because your tactics are profoundly biased and questionable. P.S. In case you’re confused, that last one wasn’t a “personal attack” either; it’s the simple truth. Greg L ( my talk) 05:19, 26 February 2008 (UTC)
So far, when the most stable and the second most stable nuclear isomer are in the same color category, Iso1 is used. I wonder why. Please use Iso2 instead and double the color statement (except when both would be white). I have changed Iso2 in that a dotted border is displayed in that case. I have found this to apply to at least Xe-133 and Rh-102.
My second point is: When do we display white borders? When a nuclear isomer has been detected, even when it is extremely short-lived? -- Quilbert ( talk) 04:34, 26 February 2008 (UTC)
P.S. I’ll bet either JWB or V1adis1av can answer both our questions. Greg L ( my talk) 05:42, 26 February 2008 (UTC)
I’ll try to construct a proposal everyone might be satisfied by:
I hope that from here, we finally come to a consensus. -- Quilbert ( talk) 08:37, 26 February 2008 (UTC)
Thanks again and here are comments on your three proposal points:
And then good news: when the Wikipedia server isn’t burdened and other articles are loading quickly, the new “complete” page loads and refreshes very quickly too. Greg L ( my talk) 18:00, 26 February 2008 (UTC)
We editors here are all intimately familiar with these tables. But when I first encountered these tables, it was at “(divided)” and I didn’t quickly understand what I was looking at. I tend to skip over the introductory text on Wikipedia and wade down into the meat articles to get a feel for what I’m encountering. I think this is something many of us tend to do at times. As I scrolled down through the different tables, on first glance, they are separate tables that seemed to represent different data sets of some sort. So I scrolled back up and read the introductory text, which referenced the “(complete)” table.
Well, one quick look at “(complete)” and I had my “ah HA!” moment. I instantly understood that the segmented tables were just pieces of a huge, contiguous, unwieldily single table. Now, I’m no dummy; I’ve got 15 patents to my name and they’re all “deep” in the technological fields. So if it took me a moment to figure this out, I’m confident many novices landing on these pages for their first time will have the same experience.
This was the genesis of my desire to get both views into a single page. It would be a place where I could link to from other articles. I wouldn't have to land the reader in “(complete)”, where they instantly get the “ah HA!” but are burdened with its unwieldily nature. I wouldn’t have to land a reader in “(divided)” where some would have difficulty quickly grasping the basic concept (that the tables are fragments of a whole). Instead, one good scroll through a dual-view version would expose the reader to the concept in one fell swoop and provide instant access to the segmented tables.
With Quilbert’s approach, both versions of this article can coexist and serve a valid purpose. If editors choose to, readers can be directed to the dual-view version where a link would make readers aware of the divided-only version. Since this is Quilbert’s vision—and since this is where he is currently headed—I’ve added a link in “(complete)” that points to “(divided)” and I’ve withdrawn the merge-proposal tag from “(divided)”. Greg L ( my talk) 19:52, 26 February 2008 (UTC)