LifeWiki infoboxes

[confocaloid]

This is a thread to collect all issues that are directly related to LifeWiki infoboxes.
(See also other existing threads: Thread for your website-related questions, Suggested LifeWiki edits.)

This thread might not get much use, as there are more general threads linked above. But it might be useful, since there are already several unresolved infobox-related issues. (E.g. at least three currently active discussions on LifeWiki:Tiki_bar have "infobox" in the title.) Maybe all those discussions can continue here, if it turns out more convenient?

[confocaloid]

For medium-sized patterns, it is possible to show the pattern directly in the lead section, with main text above and below the viewer. The infobox could then probably show only the data and not the pattern itself.

For approximate examples of how this could look like, see 54P94 and 72P119 (although in these examples the infobox still shows the same pattern -- I imagine the infobox copy of the pattern could be hidden).

[confocaloid]

For medium-sized patterns, it is possible to show the pattern directly in the lead section, with main text above and below the viewer. The infobox could then probably show only the data and not the pattern itself.
...

A variation of this is to show only a part of the pattern zoomed in the infobox. An example is the current version of Period-61 glider gun.

[confocaloid]

In Traffic lights extruder, I ended up reducing the infobox display to THUMBSIZE 4 and putting a copy of the pattern in a later section of the page.
Are there any objections to this, as a halfway solution for large patterns that can be shown outside the infobox?

I'm requesting an "official" way to disable display of the infobox viewer entirely (so that there is no viewer nor static image, and the infobox height and width are reduced accordingly). All the other data/text/links would still be shown as usual.
(I would probably do this myself, if I knew of a straightforward way to do so without Breaking Something That Works™.)

Previous related discussion: https://conwaylife.com/w/index.php?titl ... _infoboxes

[dvgrn]

I've had limited time lately to look at tricky LifeWiki formatting problems, but I'd like to continue a discussion here that has been happening in other places, such as galoomba's talk page.

The issue here is the tricky problem of getting reasonable results with infoboxes (at the top right) that are followed by LifeViewer galleries. When there are a lot of embedded LifeViewers, they can fit to the left of infoboxes as long as there aren't too many columns of them. At least when we set things up in the best way we collectively seem to know at this point, when there are three or more columns, the columns all get shunted down below the entire infobox, leaving a big annoying empty space where there doesn't need to be one.

Here is (what is currently) the latest edit of the 42P38 article. @Confocaloid, you've adjusted this so that there's only a single column of embedded LifeViewers in the LCM Oscillators section. It seems to me that on something like 99% of non-mobile screens, this wastes a lot of vertical space in a different way -- there's a huge amount of blank space left and right of the single column of LifeViewers.

Personally I very much prefer Galoomba's earlier version here, with two columns. Even on my not terribly large laptop screen, there's plenty of room for a 2x2 patch of embedded LifeViewers. I'd very much like to hear from other LifeWiki readers who either

1) have no difficulty with the two-column format, or
2) do have a difficulty with the two-column format and find the single-column format to be a better compromise,

or especially

3) have a clever solution for getting these embedded LifeViewers to flow better for all cases (narrow-width computer screens, standard width computer screens, and maybe mobile screens) without creating stupid amounts of whitespace.

[pzq_alex]

Personally I very much prefer Galoomba's earlier version here, with two columns. Even on my not terribly large laptop screen, there's plenty of room for a 2x2 patch of embedded LifeViewers. I'd very much like to hear from other LifeWiki readers who either

1) have no difficulty with the two-column format, or
2) do have a difficulty with the two-column format and find the single-column format to be a better compromise,

or especially

3) have a clever solution for getting these embedded LifeViewers to flow better for all cases (narrow-width computer screens, standard width computer screens, and maybe mobile screens) without creating stupid amounts of whitespace.

I'm in case 1, though I'd expect a case 3 solution.

[dvgrn]

I'm in case 1, though I'd expect a case 3 solution.

Me too! (both parts). But in actual reality, I've failed every time I've tried to get embedded LifeViewers to flow such that

1) as many columns of LifeViewers pile in to the left of the infobox as will fit there, and then
2) as many columns of LifeViewers pile up below the infobox as will fit there.

If someone can edit the 42P38 article in some magical way that accomplishes this, I can try updating LifeWiki documentation to explain and recommend the trick (whatever it is) for all similar gallery-plus-infobox cases.

[confocaloid]

When possible, I'm trying to reorder content so that wide parts (such as viewer galleries, tables, larger viewers) are placed in later sections. This is not always possible.
Sometimes it is possible to convert a gallery into separate viewers with text before and after each viewer, or extract some viewers from a large gallery.

Another possibility (a workaround) is to put a single viewer in the lead, displaying the same pattern shown in the infobox. That fills some of space in the beginning of the article. For medium-sized patterns, if a copy of the pattern is put in the lead and the infobox version is reduced in size, that can sometimes suffice to ensure that any later wide content is below the infobox. Again, this does not always work.

I would like to request an "official" optional way to configure an infobox so that the viewer is not shown there (and the height of the infobox is reduced correspondingly). Then the pattern could be put in the lead section (outside the infobox), shifting all the content further down the page. I think this combination could help in a significant number of cases.

Edit: here's an example: link. I added a viewer to show an oscillator which was previously mentioned in the lead. This shifts the remaining content down. I think moving the infobox pattern to the lead would solve the problem for this particular page. Or it might be possible to expand the page further.

[galoomba]

When possible, I'm trying to reorder content so that wide parts (such as viewer galleries, tables, larger viewers) are placed in later sections. This is not always possible.
Sometimes it is possible to convert a gallery into separate viewers with text before and after each viewer, or extract some viewers from a large gallery.

Another possibility (a workaround) is to put a single viewer in the lead, displaying the same pattern shown in the infobox. That fills some of space in the beginning of the article. For medium-sized patterns, if a copy of the pattern is put in the lead and the infobox version is reduced in size, that can sometimes suffice to ensure that any later wide content is below the infobox. Again, this does not always work.

I would like to request an "official" optional way to configure an infobox so that the viewer is not shown there (and the height of the infobox is reduced correspondingly). Then the pattern could be put in the lead section (outside the infobox), shifting all the content further down the page. I think this combination could help in a significant number of cases.

Edit: here's an example: link. I added a viewer to show an oscillator which was previously mentioned in the lead. This shifts the remaining content down. I think moving the infobox pattern to the lead would solve the problem for this particular page. Or it might be possible to expand the page further.

What's the point of all of this? It decreases whitespace on your (seemingly unusually small) screen, but it makes it worse for pretty much everyone else. Like dvgrn said:

It seems to me that on something like 99% of non-mobile screens, this wastes a lot of vertical space in a different way -- there's a huge amount of blank space left and right of the single column of LifeViewers.

[confocaloid]

As for the two columns: you seem to be the only person who has a problem with that. Two columns fit even if I set my screen to 720p. Just zoom out in your browser

What's the point of all of this? It decreases whitespace on your (seemingly unusually small) screen, but it makes it worse for pretty much everyone else.

You're trying to make it look like I'm the only one who has the problem. This is not the case. Infoboxes frequently conflict with wide content in the beginning of the page. Too wide content (galleries/tables) is problematic by itself, and having it in the beginning makes things worse. Instead of trying to put blame on me, what about trying to solve the problem?

The issue here is the tricky problem of getting reasonable results with infoboxes (at the top right) that are followed by LifeViewer galleries. When there are a lot of embedded LifeViewers, they can fit to the left of infoboxes as long as there aren't too many columns of them. At least when we set things up in the best way we collectively seem to know at this point, when there are three or more columns, the columns all get shunted down below the entire infobox, leaving a big annoying empty space where there doesn't need to be one.

[galoomba]

You're trying to make it look like I'm the only one who has the problem. This is not the case. Infoboxes frequently conflict with wide content in the beginning of the page. Too wide content (galleries/tables) is problematic by itself, and having it in the beginning makes things worse. Instead of trying to put blame on me, what about trying to solve the problem?

You're probably not the only one who has the problem, but it seems to not be a problem for the vast majority of people. And it's not like nobody is worse off if you make it one column, in fact it doubles the amount of space the tables take up.
Of course it would be best if we got a solution that worked on all screens, but I'm not qualified to code something like that.

[confocaloid]

I'm in case 1, though I'd expect a case 3 solution.

Me too! (both parts). But in actual reality, I've failed every time I've tried to get embedded LifeViewers to flow such that

1) as many columns of LifeViewers pile in to the left of the infobox as will fit there, and then
2) as many columns of LifeViewers pile up below the infobox as will fit there.

If someone can edit the 42P38 article in some magical way that accomplishes this, I can try updating LifeWiki documentation to explain and recommend the trick (whatever it is) for all similar gallery-plus-infobox cases.

The best "trick" that I know of is to try to avoid having any columns of LifeViewers to the left of the infobox, by moving the gallery down the page whenever possible, and/or by converting it into separate "singular" viewers.

Hence my request for an optional documented way to reduce infobox height by hiding the pattern. That would increase the number of cases where moving the gallery down works.

[Nathaniel]

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

[dvgrn]

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

I think the #2 option is maybe the closest I've seen to what I've been looking for. The gallery items don't all end up in a nice grid, but on the other hand the occasional awkward half-row one doesn't actually waste any space, the way other solutions have (including the #1 option).

With the #2 option, the half-row viewer(s) could be lowered to line up more cleanly with the grid, but that doesn't actually change the amount of whitespace in the layout, just moves it around.

I'd probably slightly prefer the #2 option to the #1 option, until something better comes along. Either #1 or #2 definitely seems better to me than the edits confocaloid made to pile all embedded LifeViewers in a gallery into a single column.
Other opinions?

[confocaloid]

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.

Thanks for adding these features! I think they will help to improve layout.

Out of two variants for galleries, I think the galleryContainer+galleryItem variant is more well-behaved. There is still unused space when the gallery begins early, but the advantage is that all the whitespace is continuous.

With the other variant (class="galleryItem" style="float:left;"), the whitespace can be irregularly-shaped and disconnected, for example:

galleryitem_floatleft.png (136.9 KiB) Viewed 7257 times

[Nathaniel]

I think I (finally) have a solution that provides the best of all worlds re: gallery items properly positioning themselves. See

https://conwaylife.com/w/index.php?titl ... l/SandboxC

Make sure you do a hard refresh of your browser's cache (Ctrl+Shift+R or equivalent) to see the effects. At all widths that I tried, the gallery items stayed in a proper grid (unlike SandboxB above) but also properly wrapped around the infobox (unlike Sandbox above).

[confocaloid]

When gallery items have different heights, is it possible to align them to the top by default (like in the galleryContainer/galleryItem case), rather than to the bottom?

[Nathaniel]

When gallery items have different heights, is it possible to align them to the top by default (like in the galleryContainer/galleryItem case), rather than to the bottom?

I have now made this change, so that the new "galIt" class aligns boxes to the top by default (you can now see this behaviour at https://conwaylife.com/wiki/User:Nathaniel/SandboxC). Again, you may have to do a hard refresh (e.g., Ctrl+Shift+R) to see the effect on that page.

In general, you can add something like style="vertical-align:bottom;" to the "galIt" div if you want to change where its vertical alignment baseline is.

[confocaloid]

I have added templates, which will hopefully be useful for making galleries in articles. The intent is to simplify update if/when formatting has to be updated later.

The templates are listed here: Category:Gallery templates
The current documentation for the three templates is here: Template:Gallery item/Doc

[Haycat2009]

I have added templates, which will hopefully be useful for making galleries in articles. The intent is to simplify update if/when formatting has to be updated later.

The templates are listed here: Category:Gallery templates
The current documentation for the three templates is here: Template:Gallery item/Doc

Good, but why do you hate infoboxes?

[confocaloid]

The question in the previous post is misleading. https://en.wikipedia.org/wiki/Loaded_question

Here is a quote from related discussion (LifeWiki:Tiki bar#Alien_pattern_pages):

Before committing to the whole idea of having infoboxes in the OCA namespace, it makes sense to consider more lightweight/maintainable/flexible alternatives.

[Haycat2009]

The question in the previous post is misleading. https://en.wikipedia.org/wiki/Loaded_question

Here is a quote from related discussion (LifeWiki:Tiki bar#Alien_pattern_pages):

Before committing to the whole idea of having infoboxes in the OCA namespace, it makes sense to consider more lightweight/maintainable/flexible alternatives.

Sorry, I just meant that you were always trying to convince others to have no infoboxes and add an option for "No infobox".

As for alternatives, what do you suggest?

[confocaloid]

Sorry, I just meant that you were always trying to convince others to have no infoboxes and add an option for "No infobox".

No infobox is the status quo for OCA namespace pattern pages. Infoboxes were not previously used on those pages, before recently pushed changes.

Several days ago, a few pages (OCA:HighLife/p10, OCA:HighLife/p7, OCA:Glider 3736, OCA:HighLife/Bomber) were edited to add infoboxes, and associated templates (Template:Oscillator, Template:Spaceship, Template:PatternPopulationAndBoundingBox, Template:InfoboxStart, Template:PatternDiscovery) were edited to change how they work. These changes were done without seeking consensus. My attempt to revert them was reverted back.

As for alternatives, what do you suggest?

Before recently pushed changes to add infoboxes, the pages used embedded viewers / galleries of viewers:
https://conwaylife.com/w/index.php?titl ... did=136366
https://conwaylife.com/w/index.php?titl ... did=131208
https://conwaylife.com/w/index.php?titl ... did=124472
https://conwaylife.com/w/index.php?titl ... did=124474

I liked those versions more than those with added infoboxes. I would prefer to restore those versions.
Galleries are more flexible/maintainable than infoboxes, they can be added incrementally (one viewer at a time), captions can be used to explain patterns, one can add interesting variants of the pattern.
Infoboxes require to fill a whole bunch of parameters at once, force to arbitrarily pick a single variant without allowing to add an explanatory caption for that variant, and are not very maintainable (in the main namespace, infoboxes attempt to collect too much information in one packed table).
In addition, alien rules are rather diverse (there are grids other than the square tiling, there are multistate rules, etc.)

[hotdogPi]

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

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

[galoomba]

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.

they can be added incrementally (one viewer at a time), captions can be used to explain patterns, one can add interesting variants of the pattern.

Having an infobox does not prevent a page from also having a gallery. That's a false dichotomy.

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.

in the main namespace, infoboxes attempt to collect too much information in one packed table

That is the purpose of an infobox - to provide the basic information in a compact, standard way.

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.