LifeWiki infoboxes

[confocaloid]

Galleries are more flexible/maintainable than infoboxes

I don't know what you mean by "maintainable". To me, they seem less maintainable, in the sense that whenever we decide to change the formatting of infoboxes, we can do it all at once, but when we decide to change the formatting of galleries, we have to edit each one individually.

Within some limits. For example, the infoboxes have "viewerconfig" parameter, which changes reasonably frequently on individual pages.

For another example, if at some point it is decided that some numeric infobox parameter (previously added to many pages) should now be changed so that the values are negated (or otherwise changed from what they were previously), you'll have a choice to either edit every single affected page to update the values, or introduce a difference between which value is specified in the wiki markup and which value is displayed to the reader.

Embedded viewers are simpler / more lightweight, in the sense that they don't even attempt to pack multiple kinds of information in a single point. An embedded viewer can be used to show and explain a specific pattern. Any extended information can go in the surrounding text, or can be left in a footnote, or linked to via a forum link or otherwise.

Infoboxes require to fill a whole bunch of parameters at once

No, they don't. You can leave a parameter blank, and it just won't show up.

force to arbitrarily pick a single variant without allowing to add an explanatory caption for that variant

Most patterns don't have variants, and for those that do, usually there's a canonical variant. Cases where it's hard to pick a variant are rare. And if there's ever a really hard case, there's always the option of just don't have an infobox for that particular pattern.

I disagree with the whole idea to consider infoboxes the default option. An infobox is not generally needed, unless you really need an infobox on a specific page in a given case.

When creating a new page, "add the infobox" is a distraction. It is expected that whoever is adding the infobox, will (correctly) add most or all relevant parameters. That distracts from the main challenge, which is to write an article to describe / explain a pattern.
An "infobox-only" page, with one or two sentences in the main part, is not really an article.
A good article could do perfectly well without an infobox, giving all relevant information in plain text with embedded pictures / viewers / galleries / diagrams.

I believe the default option for alien patterns should continue to be an easy-to-create infoboxless article. It is much easier to add an embedded viewer (either with "rle" or "pname") than to fill an infobox. Any related information can be written in plain text.

[galoomba]

For example, the infoboxes have "viewerconfig" parameter, which changes reasonably frequently on individual pages.

So do individual viewers.

For another example, if at some point it is decided that some numeric infobox parameter (previously added to many pages) should now be changed so that the values are negated (or otherwise changed from what they were previously), you'll have a choice to either edit every single affected page to update the values, or introduce a difference between which value is specified in the wiki markup and which value is displayed to the reader.

Any specific example of such a change? This seems like a contrived hypothetical scenario.

Embedded viewers are simpler / more lightweight, in the sense that they don't even attempt to pack multiple kinds of information in a single point. An embedded viewer can be used to show and explain a specific pattern. Any extended information can go in the surrounding text, or can be left in a footnote, or linked to via a forum link or otherwise.

Surely having a table of numbers is more "lightweight" than having to somehow fit them into sentences? Or is your point that most of the info in the infobox is not very useful?

I disagree with the whole idea to consider infoboxes the default option.

You disagree, but everyone else agrees, so the majority's opinion should be followed.

When creating a new page, "add the infobox" is a distraction. It is expected that whoever is adding the infobox, will (correctly) add most or all relevant parameters. That distracts from the main challenge, which is to write an article to describe / explain a pattern.
An "infobox-only" page, with one or two sentences in the main part, is not really an article.

None of the articles you reverted were new pages or "infobox-only".

A good article could do perfectly well without an infobox, giving all relevant information in plain text with embedded pictures / viewers / galleries / diagrams.

I believe the default option for alien patterns should continue to be an easy-to-create infoboxless article. It is much easier to add an embedded viewer (either with "rle" or "pname") than to fill an infobox. Any related information can be written in plain text.

I disagree. Infoboxes are convenient.

Also, none of this is specific to OCA. Are you arguing that we should remove infoboxes entirely?

[confocaloid]

For another example, if at some point it is decided that some numeric infobox parameter (previously added to many pages) should now be changed so that the values are negated (or otherwise changed from what they were previously), you'll have a choice to either edit every single affected page to update the values, or introduce a difference between which value is specified in the wiki markup and which value is displayed to the reader.

Any specific example of such a change? This seems like a contrived hypothetical scenario.

For something that (at the very least) comes very close to a specific example, see displacements of conduits --

Is the displacement of Fx119 (20, -14), as in h-to-h-collection-26Aug2017.rle and the previous version of Bx106 article, or (20, 14), as in the Fx119 article, or (-20, 14), as in the Herschel conduit article? I've just edited the Bx106 to remove the weird wanted displacement category; for now the part about Fx119 is taken out due to the question above.

For another possibly relevant example, see LifeWiki:Tiki_bar#Volatility_rounding.

Embedded viewers are simpler / more lightweight, in the sense that they don't even attempt to pack multiple kinds of information in a single point. An embedded viewer can be used to show and explain a specific pattern. Any extended information can go in the surrounding text, or can be left in a footnote, or linked to via a forum link or otherwise.

Surely having a table of numbers is more "lightweight" than having to somehow fit them into sentences? Or is your point that most of the info in the infobox is not very useful?

My point is that it is easier to add a viewer than to fill an infobox, and viewers can be surrounded by text explaining the patterns. You don't have to have an infobox in an article.

I disagree with the whole idea to consider infoboxes the default option.

You disagree, but everyone else agrees, so the majority's opinion should be followed.

This is misleading -- few people replied so far. It is your opinion, and not everyone else's opinion.

When creating a new page, "add the infobox" is a distraction. It is expected that whoever is adding the infobox, will (correctly) add most or all relevant parameters. That distracts from the main challenge, which is to write an article to describe / explain a pattern.
An "infobox-only" page, with one or two sentences in the main part, is not really an article.

None of the articles you reverted were new pages or "infobox-only".

I think none of those articles need an infobox. I prefer the older versions of those articles, without an infobox.

A good article could do perfectly well without an infobox, giving all relevant information in plain text with embedded pictures / viewers / galleries / diagrams.

I believe the default option for alien patterns should continue to be an easy-to-create infoboxless article. It is much easier to add an embedded viewer (either with "rle" or "pname") than to fill an infobox. Any related information can be written in plain text.

I disagree. Infoboxes are convenient.

Also, none of this is specific to OCA. Are you arguing that we should remove infoboxes entirely?

This issue is specific to the OCA namespace. Unlike the main namespace, the OCA namespace did not have infoboxes on pattern pages before your recent edits.

[galoomba]

For another example, if at some point it is decided that some numeric infobox parameter (previously added to many pages) should now be changed so that the values are negated (or otherwise changed from what they were previously), you'll have a choice to either edit every single affected page to update the values, or introduce a difference between which value is specified in the wiki markup and which value is displayed to the reader.

Any specific example of such a change? This seems like a contrived hypothetical scenario.

For something that (at the very least) comes very close to a specific example, see displacements of conduits --

Is the displacement of Fx119 (20, -14), as in h-to-h-collection-26Aug2017.rle and the previous version of Bx106 article, or (20, 14), as in the Fx119 article, or (-20, 14), as in the Herschel conduit article? I've just edited the Bx106 to remove the weird wanted displacement category; for now the part about Fx119 is taken out due to the question above.

For another possibly relevant example, see LifeWiki:Tiki_bar#Volatility_rounding.

True, these issues should be fixed. (I don't know why no one has replied to that tiki bar post.) At least these specific ones aren't as relevant to OCA because there aren't any articles on specific OCA conduits and volatility etc. doesn't automatically put articles in categories.

Embedded viewers are simpler / more lightweight, in the sense that they don't even attempt to pack multiple kinds of information in a single point. An embedded viewer can be used to show and explain a specific pattern. Any extended information can go in the surrounding text, or can be left in a footnote, or linked to via a forum link or otherwise.

Surely having a table of numbers is more "lightweight" than having to somehow fit them into sentences? Or is your point that most of the info in the infobox is not very useful?

My point is that it is easier to add a viewer than to fill an infobox, and viewers can be surrounded by text explaining the patterns. You don't have to have an infobox in an article.

There's a difference between "you don't have to add an infobox when making an article" and "we should remove infoboxes from articles".

I disagree with the whole idea to consider infoboxes the default option.

You disagree, but everyone else agrees, so the majority's opinion should be followed.

This is misleading -- few people replied so far. It is your opinion, and not everyone else's opinion.

I knew you'd nitpick me on that, but there aren't a lot of active wiki editors, so 4 is a decent sample.

When creating a new page, "add the infobox" is a distraction. It is expected that whoever is adding the infobox, will (correctly) add most or all relevant parameters. That distracts from the main challenge, which is to write an article to describe / explain a pattern.
An "infobox-only" page, with one or two sentences in the main part, is not really an article.

None of the articles you reverted were new pages or "infobox-only".

I think none of those articles need an infobox. I prefer the older versions of those articles, without an infobox.

Again, you prefer the versions without the infobox, 3 other people prefer the versions with the infobox. Your opinion does not override everyone else's.

This issue is specific to the OCA namespace. Unlike the main namespace, the OCA namespace did not have infoboxes on pattern pages before your recent edits.

The only reason it did not have infoboxes is because that would automatically put them into CGoL pattern categories. I fixed that issue so that they could get infoboxes as the author intended.

[confocaloid]

Also, none of this is specific to OCA. Are you arguing that we should remove infoboxes entirely?

This issue is specific to the OCA namespace. Unlike the main namespace, the OCA namespace did not have infoboxes on pattern pages before your recent edits.

The only reason it did not have infoboxes is because that would automatically put them into CGoL pattern categories. I fixed that issue so that they could get infoboxes as the author intended.

I'm unsure whether "the author" even means anything in a wiki, where pages are edited by multiple people.
But I was the one who started the page OCA:Glider 3736, and I did not intend that page to get an infobox. I'd rather have an infoboxless page.

[galoomba]

This issue is specific to the OCA namespace. Unlike the main namespace, the OCA namespace did not have infoboxes on pattern pages before your recent edits.

The only reason it did not have infoboxes is because that would automatically put them into CGoL pattern categories. I fixed that issue so that they could get infoboxes as the author intended.

I'm unsure whether "the author" even means anything in a wiki, where pages are edited by multiple people.
But I was the one who started the page OCA:Glider 3736, and I did not intend that page to get an infobox. I'd rather have an infoboxless page.

I was referring to hotdogPi.

As the person who basically decided in the past that OCA pages don't get infoboxes, such as when I created the HighLife p7 and p10 pages: it was for technical reasons. I would have preferred them to exist. HotdogPi (talk) 18:17, 4 September 2023 (UTC)

[dvgrn]

But I was the one who started the page OCA:Glider 3736, and I did not intend that page to get an infobox. I'd rather have an infoboxless page.

Then perhaps a good compromise would be to remove the infobox from the OCA:Glider 3736 page, and allow the infoboxes to exist on the other three pages where reverts have recently occurred.

[galoomba]

Then perhaps a good compromise would be to remove the infobox from the OCA:Glider 3736 page, and allow the infoboxes to exist on the other three pages where reverts have recently occurred.

I might have phrased it wrong with the "author intended" thing. I meant that OCA patterns didn't have infoboxes not because infoboxes for OCA patterns are bad but just because it wasn't possible to implement at the time.

I still fail to see why OCA patterns specifically get this treatment. Almost all of the arguments here have nothing to do with OCA. The ones that do are one confocaloid hasn't elaborated on:

In addition, alien rules are rather diverse (there are grids other than the square tiling, there are multistate rules, etc.)

Not sure how this is relevant.

and this:

This issue is specific to the OCA namespace. Unlike the main namespace, the OCA namespace did not have infoboxes on pattern pages before your recent edits.

which is an appeal to the status quo, which was only like this because of technical limitations, not a style standard.

[MEisSCAMMER]

I'm just going to jump in and offer my own two cents here. I was going to say that I don't really know of anything you can get from an infobox that you can't get from an embedded viewer by pulling up the identify function. However, I do think that we should also be consistent, and since the infoboxes (infoboxen?) on the Life pages aren't in debate right now, I have to say that the infoboxes should go up on OCAs, for consistency's sake if nothing else.

[confocaloid]

I still fail to see why OCA patterns specifically get this treatment. [...]

As soon as you have a notable pattern in a rule on a grid other than the square tiling, the parameter "bounding box" will become irrelevant.

As soon as you have a notable pattern in a rule outside the 2-state range-1 Moore isotropic rulespace, the section "Rules" (rulemin/rulemax/isorulemin/isorulemax) will become irrelevant.

Regardless of rulespace, "apgcode" already becomes technically incorrect when it is used to link to the Catagolue page for an alien object. (It becomes "apgcode/rulestring" rather than "apgcode".) Partially already discussed: https://conwaylife.com/w/index.php?titl ... did=136654

Re: "it's not like any patterns in those rules currently have pages" -- allowing infoboxes for 2-state isotropic rules but excluding other rulespaces "by technical limitations" would be way way more arbitrary and short-sighted, than allowing infoboxes only for B3/S23.

To me, infoboxes do not appear particularly useful (and do appear sufficiently problematic, especially once you go beyond plain B3/S23), so that I prefer to avoid making them the "default option".

(Since the infoboxes on the Life pages were mentioned: I think many pattern pages in the main namespace do not really need infoboxes, either. For all I can say, consistently discarding infoboxes everywhere unless they are needed might happen to be an improvement.
It is just that in the main namespace, infoboxes are already taken for granted for several years.)

[galoomba]

As soon as you have a notable pattern in a rule on a grid other than the square tiling, the parameter "bounding box" will become irrelevant.

As soon as you have a notable pattern in a rule outside the 2-state range-1 Moore isotropic rulespace, the section "Rules" (rulemin/rulemax/isorulemin/isorulemax) will become irrelevant.

I've responded to this several times already: you can just omit those parameters.

Regardless of rulespace, "apgcode" already becomes technically incorrect when it is used to link to the Catagolue page for an alien object. (It becomes "apgcode/rulestring" rather than "apgcode".) Partially already discussed: https://conwaylife.com/w/index.php?titl ... did=136654

There are several easy solutions and workarounds for this.

Re: "it's not like any patterns in those rules currently have pages" -- allowing infoboxes for 2-state isotropic rules but excluding other rulespaces "by technical limitations" would be way way more arbitrary and short-sighted, than allowing infoboxes only for B3/S23.

I disagree. There are many different kinds of cellular automata and trying to account for all of them, even though 99% of the time we're working with rules very similar to CGoL, is ridiculous.

To me, infoboxes do not appear particularly useful (and do appear sufficiently problematic, especially once you go beyond plain B3/S23), so that I prefer to avoid making them the "default option".

(Since the infoboxes on the Life pages were mentioned: I think many pattern pages in the main namespace do not really need infoboxes, either. For all I can say, consistently discarding infoboxes everywhere unless they are needed might happen to be an improvement.
It is just that in the main namespace, infoboxes are already taken for granted for several years.)

Well, that's a different discussion that you can certainly open if you want.

[confocaloid]

Re: "it's not like any patterns in those rules currently have pages" -- allowing infoboxes for 2-state isotropic rules but excluding other rulespaces "by technical limitations" would be way way more arbitrary and short-sighted, than allowing infoboxes only for B3/S23.

I disagree. There are many different kinds of cellular automata and trying to account for all of them, even though 99% of the time we're working with rules very similar to CGoL, is ridiculous.

What I'm suggesting is, basically, that you don't need to account beforehand for any specific family of cellular automata, as long as you do not require "standard" infoboxes present by default. Giving the same information in plain text with embedded viewers/images will always be more flexible/lightweight, and it will work for any cellular automata.

[galoomba]

What I'm suggesting is, basically, that you don't need to account beforehand for any specific family of cellular automata, as long as you do not require "standard" infoboxes present by default.

What if we don't require it, but just allow it?

[confocaloid]

What I'm suggesting is, basically, that you don't need to account beforehand for any specific family of cellular automata, as long as you do not require "standard" infoboxes present by default.

What if we don't require it, but just allow it?

I expect that people (especially relative newcomers) will confuse one with another (given that I myself sometimes confuse one with another), and people will expect infoboxes everywhere "for the sake of consistency".
In one sense, that would be reasonable in that hypothetical future -- assuming that infoboxes are meant to list properties that are meaningful for all patterns.
In another sense, that would be unreasonable -- it is unreasonable to expect that adding a "standard" infobox will help on every single pattern page. (One of several ways how this is visible is that infobox viewers don't make much sense on pages about large patterns.)

My opinion is that an infobox is not generally needed, unless there's a clear answer for why it is in fact needed/useful in a given case on a specific page.

[galoomba]

I expect that people (especially relative newcomers) will confuse one with another (given that I myself sometimes confuse one with another), and people will expect infoboxes everywhere "for the sake of consistency".
In one sense, that would be reasonable in that hypothetical future -- assuming that infoboxes are meant to list properties that are meaningful for all patterns.

Isn't that your proposal, though? To only have infoboxes for some patterns but not others?

In another sense, that would be unreasonable -- it is unreasonable to expect that adding a "standard" infobox will help on every single pattern page.

It doesn't hurt either, though, does it? Ridiculously small screens notwithstanding.

My opinion is that an infobox is not generally needed, unless there's a clear answer for why it is in fact needed/useful in a given case on a specific page.

Valid opinion, but it doesn't seem to be the majority opinion.

[confocaloid]

Regarding recent changes, my proposal is to continue to avoid infoboxes on pattern pages in the OCA namespace. Infoboxes were not previously used on those pages, and there is no evidence that infoboxes are needed for this class of pages.

It doesn't hurt either, though, does it?

It does -- when information is not relevant, it is often distracting. Attempting to show a large pattern that cannot really be shown in the infobox is giving irrelevant information to the reader. Similarly, adding an infobox to an article that could do perfectly well without an infobox is distracting.

[hotdogPi]

The reason OCA pages didn't have infoboxes previously was solely because having them would add the page to categories. It was only a technical decision. When I created the pages on the p7 and p10 in HighLife, I would have preferred infoboxes, but technical restrictions prevented me from doing so. It was not a stylistic choice.

[confocaloid]

The reason OCA pages didn't have infoboxes previously was solely because having them would add the page to categories. It was only a technical decision. When I created the pages on the p7 and p10 in HighLife, I would have preferred infoboxes, but technical restrictions prevented me from doing so. It was not a stylistic choice.

Maybe it was not a stylistic choice, but it was still a (consistent) choice.

Relevant discussion started no later than 2020: LifeWiki:Tiki_bar/Archive/2020#LifeViewer_and_RLE_on_OCA_subpages There were several different points and suggestions (I'm not trying to overview them here).

Assuming that infoboxes are going to be used outside the main namespace, I think it would make sense to have different templates for different rulespaces, to account for their properties correctly. This is also an opportunity to correct any design-time mistakes that were noticed too late with the existing infobox templates.

In other words, being specific to a rulespace is more likely to lead to a useful template/set of templates, than trying to be as general as possible.

Separately from the above, I'm not really sure whether infoboxes (in their current main-namespace form) are sufficiently useful and/or needed, to extend their use to wider set of pages where more assumptions will fail.
Maybe it is time to reconsider usefulness of infoboxes in their current form.

[Haycat2009]

These changes were done without seeking consensus. My attempt to revert them was reverted back.

It was 2-1 (galoomba and me vs. you).

Make it 3-1 (galoomba, hotdogpi and me vs. confocaloid)

[confocaloid]

This misses existence of several different possibilities, and consensus is not a matter of counting votes anyway.

[dvgrn]

This misses existence of several different possibilities, and consensus is not a matter of counting votes anyway.

Here "consensus" is being used in the Wikipedia sense of the term:

Consensus on Wikipedia does not require unanimity (which is ideal but rarely achievable), nor is it the result of a vote.

A consensus decision takes into account all of the proper concerns raised. Ideally, it arrives with an absence of objections, but often we must settle for as wide an agreement as can be reached.

Now, as people say sometimes, LifeWiki is not Wikipedia... but Wikipedia guidelines for consensus and consensus-building are still useful tools, which we should probably reach for whenever we can.

That said, making a list of who supports an idea and who doesn't is not the same thing as voting. It's more like documentation of which way the consensus is building, and where the "widest agreement" is likely to be found. Poll threads here on the forums can serve a similar useful purpose, by getting a broader cross-section of the community to express an opinion.

If a poll shows a roughly even split between two opinions, that's a poor justification for making changes, regardless of which way the majority vote happens to go. On the other hand, if the dissenting group turns out to be only one person, or a very small number of people if we're talking about a larger group, then it's not necessary to continue to defer to the dissenting opinion indefinitely. That would basically amount to allowing stonewalling.

So I think it can be useful to take a poll or do a support/dissent summary occasionally, just to find out whether the discussion has reached the point yet where it makes sense to move on. If nothing else, it can help focus the discussion a bit, to break out of the loop of people simply re-stating their opinions without adding any new ideas.

Disclaimer: IANAWE (I Am Not A Wikipedia Editor) -- not recently, anyway. I just went and looked at some Wikipedia documentation, to understand better what confocaloid means by "consensus" in the quote above.

[confocaloid]

It seems like points mentioned above are basically ignored.

[galoomba]

It seems like points mentioned above are basically ignored.

I've responded to those points multiple times already.

[confocaloid]

It seems like points mentioned above are basically ignored.

I've responded to those points multiple times already.

Then maybe give time to let other people respond as well, rather than (making this an argument between two active editors) and/or (trying to push your preferred changes as if there was already understanding and clear consensus for them)?

[MEisSCAMMER]

It seems like points mentioned above are basically ignored.

A poll would not be incompatible with your idea of using different templates for different rulespaces — just include it as an option on the poll. However, I'm curious about what specifically you meant by "rulespaces" in the linked post; do you mean broad categories (LtL, INT, Generations, etc.), or a bit more specific (i.e., breaking down INT to B0, Whitespace, 1TFL, etc.)? I feel like the former would be workable, but the latter would get complicated very quickly.