LifeWiki infoboxes

[confocaloid]

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.

Yes, most likely it would be "broad categories". Being a B0 rule (if reflected in the infobox at all) could be a property of an INT rule.

[galoomba]

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)?

Three people have stated that they agree with me. Why does that not count as "other people responding"?

[confocaloid]

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)?

Three people have stated that they agree with me. Why does that not count as "other people responding"?

Because you're continuing to either (a) argue with me, pretending that there is a consensus or (b) attempt to push your preferred changes yourself, instead of waiting until the issue becomes clear.

If you say that you have responded already, then let other people respond as well, and explain their opinions / arguments.

[hotdogPi]

There's a consensus. 4-1. On the side of the 4 is me, dvgrn, galoomba, and MEisSCAMMER.

[confocaloid]

There's a consensus. 4-1. On the side of the 4 is me, dvgrn, galoomba, and MEisSCAMMER.

Give time to let anyone interested to respond. A few days are not enough, especially when the thread is filled with an argument between two active editors.

Further, I think your claim is contradicted by the recent posts here:

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.

[galoomba]

Further, I think your claim is contradicted by the recent posts here:

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.

Maybe they meant Haycat2009:

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

[confocaloid]

Neither "3-1" nor "4-1" would be a consensus to make changes from the existing state (to be specific -- the changes would be introducing infoboxes to OCA-namespace pattern pages) --
(a) there was not enough time to understand and discuss these changes (a few days are not enough, even for "normal" discussions without heated arguments),
(b) there was not much opportunity to discuss these changes (the discussion places are filled by an argument between few active editors, giving little opportunity for others to respond and explain their opinions).

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.

[MEisSCAMMER]

To summarize the main points, if I may (the discussion appears to start here):

The pro-infobox people (galoomba, Haycat, hotdogPi) say:

• infoboxes are a compact and easy-to-read source of information about patterns;
• infoboxes are more maintainable and simpler than galleries/embedded viewers;
• in response to the below point about infoboxes not being optimized for OCAs, parameters do not need to all be filled out.
• they have the majority.

And the anti-infobox people (confocaloid) say:

• infoboxes are perhaps too compact, in that it ends up being harder to read overall;
• infoboxes are currently optimized for standard Life, and this creates some issues with parameters;
• galleries/embedded viewers are more maintainable and simpler than infoboxes;
• people focus too much on inputting parameters for infoboxes and not enough on actually writing quality articles.

I'd like to clarify my position as pro-infobox, contingent on confocaloid's idea of creating new infobox templates for different OCA rulespaces. I would be willing to implement any such templates.

Did I miss anything?

[confocaloid]

To summarize the main points, if I may (the discussion appears to start here):

I think the recent discussion starts on Template talk:Spaceship and LifeWiki:Tiki_bar#Alien_pattern_pages, then in this forum thread.
Before that, there was a relevant discussion (now archived) LifeWiki:Tiki_bar/Archive/2020#LifeViewer_and_RLE_on_OCA_subpages.

[dvgrn]

Did I miss anything?

The current set of reverts and un-reverts and re-reverts can maybe be described specifically as "pro-OCA-infobox" vs. "anti-OCA-infobox". It seems like the primary focus is on how to get this specific ongoing OCA-infobox-related revert war settled down. It might be better not to get too mixed up in the general question of the utility of infoboxes in this discussion.

On the other hand, the general question is relevant to my opinion on the specific OCA-infobox topic, so I'll spend a few paragraphs on it here:

Infoboxes: A Useful Annoyance?
I'm sometimes annoyed by infoboxes, since they kind of force me to go figure out information that I don't want to bother with right at the moment when I'm writing the article. But that annoyance is more than balanced by the fact that, in articles that already exist, I know exactly where to go to find a number of key pieces of information that I regularly look up about different patterns.

So then I'm really glad that the infobox format encouraged other people to fill in that information in a standardized way. It seems like putting all that stuff in customized captions or text around a gallery or embedded viewer would make it a lot harder to find when I'm looking for it.

That definitely puts me in the pro-OCA-infobox camp at this point.

A Little Documentation Can Help A Lot
It seems easy enough to write a little bit of documentation giving recommendations on when to use or not use OCA infoboxes -- "skip such-and-such parameters when they're not needed", "probably don't use infoboxes with rules using non-square grids", "use a gallery instead when there's a class of patterns sharing the same name", etc. Then if anyone is unclear about whether or not to use an infobox for a particular OCA pattern, they can go and get some advice on the subject.

How Big Is This Issue?
-- That said, at present I'm not seeing any great likelihood of a flood of specific named OCA pattern articles. How many notable OCA patterns are there that are desperately in need of their own articles at this point, with or without infoboxes? It seems like most OCA patterns are notable primarily in the context of their specific rules, and so they will naturally end up in a gallery on their OCA rule page.

So, honestly, I think it's not going to make a whole lot of difference in the near future if these template changes get made or not. For the moment, there are just a few pages that will be affected. The template changes provide an additional tool for OCA-pattern article writers to use or not use, as they prefer.

I've reviewed all of confocaloid's objections, here and on the LifeWiki. There are too many of them to address individually, and I hope to avoid seeing all of them repeated here again in response to this message -- so I'll just say generally that I acknowledge the various concerns. However, after thinking about them for a few days, I just don't find it at all likely that allowing optional OCA infoboxes will cause any significant difficulties in practice.

Encouraging OCA Pattern Articles
If anything, the change might help encourage better OCA pattern documentation on the LifeWiki, just because OCA patterns won't be so much like "second-class citizens" as far as infoboxes are concerned. Maybe the fact that infoboxes have been kinda sorta broken for OCA patterns, has been part of what has discouraged people from making articles.

I know in the past I've personally been reluctant to encourage lots of OCA patterns to get added to the LifeWiki, specifically because of them being likely to end up in categories where they're not really relevant. It looks to me like these template changes will be a big help in addressing that issue.

[Haycat2009]

There's a consensus. It is now 5-1. On the side of the 5 is me, hotdogpi , dvgrn, galoomba, and MEisSCAMMER.

[dvgrn]

There's a consensus. It is now 5-1. On the side of the 5 is me, hotdogpi , dvgrn, galoomba, and MEisSCAMMER.

And to prove that I am on the majority, I decided to remove the ability to hide infoboxes - it is confusing to newcomers.

This post was reported, and for good reason I would say. @Haycat2009, it's not at all clear to me what you mean by "I decided to remove the ability to hide infoboxes" -- but just for the moment, please don't do any LifeWiki editing that is based on the idea of being "on the majority". I'd also respectfully suggest that nobody needs to post any more "vote tallies" -- that point has been made plenty of times already, and it seems to have a tendency to get people thinking along the wrong lines.

However, it would certainly be nice to get this issue resolved! Here's an attempt to move things in that direction, though of course I'm not sure how well it will work out:

Neither "3-1" nor "4-1" would be a consensus to make changes from the existing state (to be specific -- the changes would be introducing infoboxes to OCA-namespace pattern pages) --
(a) there was not enough time to understand and discuss these changes (a few days are not enough, even for "normal" discussions without heated arguments),
(b) there was not much opportunity to discuss these changes (the discussion places are filled by an argument between few active editors, giving little opportunity for others to respond and explain their opinions).

@confocaloid, how long would you say is going to be enough time, for this specific discussion? People are understandably kind of frustrated, since it looks to them as if the issue is really fairly well settled. Without a definite time limit, your suggestion seems to amount to delaying any resolution indefinitely.

A definite time limit, on the other hand -- as long as it isn't measured in months or years! -- seems like it could be a good exercise in patience for everyone concerned.

What To Do In The Meantime?
These forums don't have a very large user base, and this is a fairly esoteric subject. It does seem quite possible that everyone who wants to express an opinion on this issue has already done so -- in which case, letting this thread go dormant for a few weeks won't really do anything useful.

@confocaloid, you've charged galoomba with "attempt[ing] to push your preferred changes yourself". On the other hand, every time you revert those changes, you're also effectively pushing your own preferences, rather than waiting for someone else to see the need to do that. The current series of reverts on this issue -- currently five in a row -- is really quite painful to watch, and it seems unnecessary.

If you can be convinced to stop reverting galoomba's changes for the time being, then we can actually see what effect those changes have in practice. If you're right that those changes aren't a good idea, then presumably that will become clearer as we make the experiment. We can always revert the changes later, as soon as there's a flood of complaints about OCA infoboxes.

[confocaloid]

@confocaloid, how long would you say is going to be enough time, for this specific discussion?

If I have to give a specific time limit, then I'd probably say "a week or two", assuming that in the meantime the discussion places are not filling with more "vote tallies" and/or posts ignoring each other's points / misrepresenting positions of others.

When active people are arguing past each other and there are opinions directly contradicting each other, it seems clear that there is no consensus.

There are several different options, including
- "continue to not have OCA pattern infoboxes" (this is my preference for now, because I don't feel like the existing issues/questions with infoboxes are resolved. There are enough problems with existing infoboxes as they are in the main namespace.)
- "create different templates for OCA namespace"
- "create different templates for every broad rulespace" (this would be my preference among ways to add infoboxes)
- something else

If you can be convinced to stop reverting galoomba's changes for the time being, then we can actually see what effect those changes have in practice. If you're right that those changes aren't a good idea, then presumably that will become clearer as we make the experiment. We can always revert the changes later, as soon as there's a flood of complaints about OCA infoboxes.

If this is considered an experiment made before/without any specific consensus (rather than presented as something that reflects an already made community decision).

I won't object to an "experimental change", as long as it is presented/understood as such.

[GUYTU6J]

...
How Big Is This Issue?
-- That said, at present I'm not seeing any great likelihood of a flood of specific named OCA pattern articles. How many notable OCA patterns are there that are desperately in need of their own articles at this point, with or without infoboxes? It seems like most OCA patterns are notable primarily in the context of their specific rules, and so they will naturally end up in a gallery on their OCA rule page.
...

Yeah, I find myself unable to perceive a standalone article for an alien object, like, OCA:HighLife/p10, to be in favor of a short section on the mother page like OCA:HighLife before a)having the relevant templates and categories invented for adapting OCA patterns, and b)having gathered a sufficient amount of relevant notable information.

---

I could have been keep myself from "filling more vote tallies", but having skimmed a few arguments, I find this statement in need of some rebuttal that would somehow place me in 6-1.

I propose to phase out/deprecate the random soup animations that are shown on rule pages. ...
* The idea behind the template is flawed. Trying to illustrate an arbitrary rule by evolving a random (or "randomly-looking") soup does not do justice to the rule. For many rules, it does not make sense. Even when it does, a better illustration would be a specific pattern chosen by a human.

There are plenty of room for putting and arranging more than one specific pattern chosen by a sapient being in the main text by using the EmbedViewer template, which does not clutter infobox templates.

Meanwhile, the criteria of what "doing justice" or "making sense" for a rule entails are prone to be subjective. However, it is sensible to presume that many people develop their first impression of a rule based on evolution of random soups, observing how active it is or what can be produced. There may be technical details such as what density, symmetry and grid type should be used for illustration, perhaps leaving room for rule-specific customization, but the general idea remains.

[confocaloid]

... However, it is sensible to presume that many people develop their first impression of a rule based on evolution of random soups, observing how active it is or what can be produced. There may be technical details such as what density, symmetry and grid type should be used for illustration, perhaps leaving room for rule-specific customization, but the general idea remains.

That won't work for circuitry rules / multistate rules, when random soups don't highlight anything relevant about the rule.
Even right now, OCA:Seeds and OCA:3-4 Life (for example) show basically the same picture of a random chaotically growing soup.

My point is that randomly generated soups fail to be an illuminating presentation for a rule, unless one adds extensive rule-specific viewer configuration. At that point, it would be simpler and better to show a single pattern, always shown to all readers the same way, deterministically chosen by a human, and illustrating how a specific rule behaves / is supposed to behave.

(For reference, it seems like the idea of random soups on rule pages was mentioned by GUYTU6J on LifeWiki:Tiki_bar/Archive/2020#Expanding_Covered_OCA_Rules.
The current relevant discussion is LifeWiki:Tiki_bar#Suggested_deprecation_of_EmbedViewerRule.)

Long story short, I believe a better illustration of a rule would always be a specific pattern chosen by a human.

[dvgrn]

If this is considered an experiment made before/without any specific consensus (rather than presented as something that reflects an already made community decision).

I won't object to an "experimental change", as long as it is presented/understood as such.

Okay, thanks! I've tried re-making the template adjustments with a note along those lines.

It seems like some more experimenting might have to happen, to get categories to do everything they're supposed to do -- or maybe I just didn't change quite everything that needs changing.

EDIT: Or maybe everything's okay now. I was seeing categories in OCA:HighLife/Bomber at first, even after the changes, but now after half an hour Ian07 has pointed out that they're gone.

[GUYTU6J]

That won't work for circuitry rules / multistate rules, when random soups don't highlight anything relevant about the rule.

Only so for rules with delicate manual design like WireWorld.

Even right now, OCA:Seeds and OCA:3-4 Life (for example) show basically the same picture of a random chaotically growing soup.

Of course these two rules behaves like that; it is just sooner or later that someone exploring them would find out the fact. But they are not "basically the same" if one notices the edges.

My point is that randomly generated soups fail to be an illuminating presentation for a rule, unless one adds extensive rule-specific viewer configuration. At that point, it would be simpler and better to show a single pattern, always shown to all readers the same way, deterministically chosen by a human, and illustrating how a specific rule behaves / is supposed to behave.

There are already lots of patterns shown, chosen and illustrating as such, as I have said, in the main text of articles. The problem is only having such predefined pattern(s): this practice leaves room for presenting a biased/skewed view. It would discredit the wiki if an editor manipulates the patterns, say, shown on OCA:Seeds such that they are all periodic and none explosive. And even there are a couple of selected explosive patterns, they are still a much weaker support than a randomly generated soup for a generalized statement as "the rule show explosive behaviour".

(For reference, it seems like the idea of random soups on rule pages was mentioned by GUYTU6J on LifeWiki:Tiki_bar/Archive/2020#Expanding_Covered_OCA_Rules.
The current relevant discussion is LifeWiki:Tiki_bar#Suggested_deprecation_of_EmbedViewerRule.)

Yes, it is me, and then?

[confocaloid]

My point is that randomly generated soups fail to be an illuminating presentation for a rule, unless one adds extensive rule-specific viewer configuration. At that point, it would be simpler and better to show a single pattern, always shown to all readers the same way, deterministically chosen by a human, and illustrating how a specific rule behaves / is supposed to behave.

There are already lots of patterns shown, chosen and illustrating as such, as I have said, in the main text of articles. The problem is only having such predefined pattern(s): this practice leaves room for presenting a biased/skewed view. It would discredit the wiki if an editor manipulates the patterns, say, shown on OCA:Seeds such that they are all periodic and none explosive. And even there are a couple of selected explosive patterns, they are still a much weaker support than a randomly generated soup for a generalized statement as "the rule show explosive behaviour".

Adjusting "technical details such as what density, symmetry and grid type should be used for illustration, perhaps leaving room for rule-specific customization" would leave room for bias just as well.

The most unbiased way to deal with this issue that I can imagine, is to avoid having any viewer/pattern (either random or chosen by a human) in the infobox for rule pages. One could leave only brief technical information in the infobox, and give any extended information and illustrations in the main text.

A curious reader will sooner or later find out how random soups behave -- let them explore the rule on their own.

(For reference, it seems like the idea of random soups on rule pages was mentioned by GUYTU6J on LifeWiki:Tiki_bar/Archive/2020#Expanding_Covered_OCA_Rules.
The current relevant discussion is LifeWiki:Tiki_bar#Suggested_deprecation_of_EmbedViewerRule.)

Yes, it is me, and then?

Those links are nothing more than links to previous relevant discussion, for future reference.

[galoomba]

A curious reader will sooner or later find out how random soups behave -- let them explore the rule on their own.

Withholding information for the sake of "exploration" is not something a wiki should do.

[confocaloid]

A curious reader will sooner or later find out how random soups behave -- let them explore the rule on their own.

Withholding information for the sake of "exploration" is not something a wiki should do.

Presenting randomly generated soups that change on refresh, as something that is supposed to serve as "illustration" of a rule, is certainly not something I'd expect in a wiki that aims to be an encyclopedia.

If an infobox is going to contain an illustration, it should be a specific picture or pattern, always the same for all readers, and actually illustrating the rule in question. Otherwise, leave only brief technical information in the infobox, and show any patterns/pictures in the main part of the article about the rule -- you do not need to "withhold" any otherwise relevant information.

[galoomba]

I have done two things that will hopefully help. Please let me know if these are actually helpful, and how they can be improved:

1. I have added a "hideimg" parameter to all infobox templates, which can be used to hide the image/LV that appears at the top of the pattern's infobox. Specify "hideimg=1" in the infobox parameters to hide the image/LV.

2. I have added some flexbox functionality that dynamically adjusts how many columns appear in a wiki page's image gallery, based on how wide the client's browser window is. You can see an example image gallery at https://conwaylife.com/wiki/User:Nathaniel/Sandbox to see how it works (you may need to do a hard refresh, like Ctrl + Shift + R, to update your browser's cache of LifeWiki's CSS before this will work). Try loading the page and then resizing your browser window after it has loaded to see how it works.

Edit: An alternative to #2 is here: https://conwaylife.com/w/index.php?titl ... l/SandboxB. In this one, the gallery items and float around the infobox a bit better, but it's still not perfect (e.g., sometimes you get weird stuff with one gallery item positioned awkwardly on its own half-row).

This gallery has the problem that it forces everything after it below the infobox:
Is there a way to fix this?

[confocaloid]

...
This gallery has the problem that it forces everything after it below the infobox:
...
Is there a way to fix this?

If this is considered a problem (rather than an intentional choice), I think this can be changed in Template:gallery bottom.
When I added the gallery templates, I tried to follow the formatting in the SandboxC page.

[galoomba]

...
This gallery has the problem that it forces everything after it below the infobox:
...
Is there a way to fix this?

If this is considered a problem (rather than an intentional choice), I think this can be changed in Template:gallery bottom.
When I added the gallery templates, I tried to follow the formatting in the SandboxC page.

I edited it, hopefully it didn't break anything.

Why do we even need {{gallery top}} and {{gallery bottom}}? They're both empty (bottom as of now, top as of always).

[confocaloid]

I edited it, hopefully it didn't break anything.

Why do we even need {{gallery top}} and {{gallery bottom}}? They're both empty (bottom as of now, top as of always).

It is possible that the underlying formatting will change in future, so that either of Template:gallery top / Template:gallery bottom / Template:gallery item will have to be changed.

The intent is to simplify update if/when formatting has to be updated later.

[Haycat2009]

There's a consensus. It is now 5-1. On the side of the 5 is me, hotdogpi , dvgrn, galoomba, and MEisSCAMMER.

And to prove that I am on the majority, I decided to remove the ability to hide infoboxes - it is confusing to newcomers.

This post was reported, and for good reason I would say. @Haycat2009, it's not at all clear to me what you mean by "I decided to remove the ability to hide infoboxes" -- but just for the moment, please don't do any LifeWiki editing that is based on the idea of being "on the majority". I'd also respectfully suggest that nobody needs to post any more "vote tallies" -- that point has been made plenty of times already, and it seems to have a tendency to get people thinking along the wrong lines.

However, it would certainly be nice to get this issue resolved! Here's an attempt to move things in that direction, though of course I'm not sure how well it will work out:

Neither "3-1" nor "4-1" would be a consensus to make changes from the existing state (to be specific -- the changes would be introducing infoboxes to OCA-namespace pattern pages) --
(a) there was not enough time to understand and discuss these changes (a few days are not enough, even for "normal" discussions without heated arguments),
(b) there was not much opportunity to discuss these changes (the discussion places are filled by an argument between few active editors, giving little opportunity for others to respond and explain their opinions).

@confocaloid, how long would you say is going to be enough time, for this specific discussion? People are understandably kind of frustrated, since it looks to them as if the issue is really fairly well settled. Without a definite time limit, your suggestion seems to amount to delaying any resolution indefinitely.

A definite time limit, on the other hand -- as long as it isn't measured in months or years! -- seems like it could be a good exercise in patience for everyone concerned.

What To Do In The Meantime?
These forums don't have a very large user base, and this is a fairly esoteric subject. It does seem quite possible that everyone who wants to express an opinion on this issue has already done so -- in which case, letting this thread go dormant for a few weeks won't really do anything useful.

@confocaloid, you've charged galoomba with "attempt[ing] to push your preferred changes yourself". On the other hand, every time you revert those changes, you're also effectively pushing your own preferences, rather than waiting for someone else to see the need to do that. The current series of reverts on this issue -- currently five in a row -- is really quite painful to watch, and it seems unnecessary.

If you can be convinced to stop reverting galoomba's changes for the time being, then we can actually see what effect those changes have in practice. If you're right that those changes aren't a good idea, then presumably that will become clearer as we make the experiment. We can always revert the changes later, as soon as there's a flood of complaints about OCA infoboxes.

Sorry - anyway the edit has been reverted and I will not attempt to redo it.