User:M Sipher/Sandbox:EditingLayoutGuide - Revision history

M Sipher: /* Custom tables */

2024-12-24T01:34:32Z

Custom tables

← Older revision		Revision as of 01:34, 24 December 2024
Line 192:		Line 192:
	<nowiki>		<nowiki>
	{\| style="margin-left:1em;" width="100%"</nowiki><br>		{\| style="margin-left:1em;" width="100%"</nowiki><br>
	<nowiki>\|width="20%" valign="top"\|<u>'''~~group~~ 1'''</u></nowiki><br>		<nowiki>\|width="20%" valign="top"\|<u>'''Group 1'''</u></nowiki><br>
	<nowiki>* Item 1</nowiki><br>		<nowiki>* Item 1</nowiki><br>
	<nowiki>* Item 2</nowiki><br>		<nowiki>* Item 2</nowiki><br>
	\|<br>		\|<br>
	<nowiki>\|width="20%" valign="top"\|<u>'''~~group~~ 2'''</u></nowiki><br>		<nowiki>\|width="20%" valign="top"\|<u>'''Group 2'''</u></nowiki><br>
	<nowiki>* Item 3</nowiki><br>		<nowiki>* Item 3</nowiki><br>
	<nowiki>* Item 4</nowiki><br>		<nowiki>* Item 4</nowiki><br>
	\|<br>		\|<br>
	<nowiki>\|width="20%" valign="top"\|<u>'''~~group~~ 3'''</u></nowiki><br>		<nowiki>\|width="20%" valign="top"\|<u>'''Group 3'''</u></nowiki><br>
	<nowiki>* Item 5</nowiki><br>		<nowiki>* Item 5</nowiki><br>
	\|<br>		\|<br>
	<nowiki>\|width="20%" valign="top"\|<u>'''~~group~~ 4'''</u></nowiki><br>		<nowiki>\|width="20%" valign="top"\|<u>'''Group 4'''</u></nowiki><br>
	<nowiki>* Item 6</nowiki><br>		<nowiki>* Item 6</nowiki><br>
	<nowiki>* Item 7</nowiki><br>		<nowiki>* Item 7</nowiki><br>
Line 209:		Line 209:
	<nowiki>\|width="20%" valign="top" rowspan=2\|[[File:exampleimage.jpeg\|right\|thumb\|upright=1\|]]</nowiki><br>		<nowiki>\|width="20%" valign="top" rowspan=2\|[[File:exampleimage.jpeg\|right\|thumb\|upright=1\|]]</nowiki><br>
	\|-<br>		\|-<br>
	<nowiki>\|width="20%" valign="top"\|<u>'''~~group~~ 5'''</u></nowiki><br>		<nowiki>\|width="20%" valign="top"\|<u>'''Group 5'''</u></nowiki><br>
	<nowiki>* Item 8</nowiki><br>		<nowiki>* Item 8</nowiki><br>
	<nowiki>* Item 9</nowiki><br>		<nowiki>* Item 9</nowiki><br>
Line 218:		Line 218:

	{\| style="margin-left:1em;" width="100%"		{\| style="margin-left:1em;" width="100%"
	\|width="20%" valign="top"\|<u>'''~~group~~ 1'''</u>		\|width="20%" valign="top"\|<u>'''Group 1'''</u>
	* Item 1		* Item 1
	* Item 2		* Item 2
	\|		\|
	\|width="20%" valign="top"\|<u>'''~~group~~ 2 '''</u>		\|width="20%" valign="top"\|<u>'''Group 2 '''</u>
	* Item 3		* Item 3
	* Item 4		* Item 4
	\|		\|
	\|width="20%" valign="top"\|<u>'''~~group~~ 3'''</u>		\|width="20%" valign="top"\|<u>'''Group 3'''</u>
	* Item 5		* Item 5
	\|		\|
	\|width="20%" valign="top"\|<u>'''~~group~~ 4'''</u>		\|width="20%" valign="top"\|<u>'''Group 4'''</u>
	* Item 6		* Item 6
	* Item 7		* Item 7
Line 235:		Line 235:
	\|width="20%" valign="top" rowspan=2\|[[File:SGRavage-EvanGauntt.jpg\|upright=1\|thumb\|Hi! I'm an image at "upright=1"! "200px" is also fine for these tables! Just stay consistent!]]		\|width="20%" valign="top" rowspan=2\|[[File:SGRavage-EvanGauntt.jpg\|upright=1\|thumb\|Hi! I'm an image at "upright=1"! "200px" is also fine for these tables! Just stay consistent!]]
	\|-		\|-
	\|width="20%" valign="top"\|<u>'''~~group~~ 5'''</u>		\|width="20%" valign="top"\|<u>'''Group 5'''</u>
	* Item 8		* Item 8
	* Item 9		* Item 9
Line 249:		Line 249:

	<span style="font-family: 'Courier New';">		<span style="font-family: 'Courier New';">
	<nowiki>\|width="20%" valign="top"\|<u>'''~~[[group]]~~'''</u></nowiki><br>		<nowiki>\|width="20%" valign="top"\|<u>'''Group'''</u></nowiki><br>
	<nowiki>* [[Item]]</nowiki><br>		<nowiki>* [[Item]]</nowiki><br>
	<nowiki>* [[Item]]</nowiki><br>		<nowiki>* [[Item]]</nowiki><br>

M Sipher: /* Image content (Or: Do you really need that image?) */

2024-12-21T21:35:38Z

Image content (Or: Do you really need that image?)

← Older revision		Revision as of 21:35, 21 December 2024
Line 67:		Line 67:

	===Image content (Or: Do you really ''need'' that image?)===		===Image content (Or: Do you really ''need'' that image?)===
	It is entirely possible to have ''too many'' images in a section. A good example of this is this [https://tfwiki.net/mediawiki/index.php?title=Windblade_(RID)&oldid=1579547\|older version of ''Robots in Disguise'' Windblade's cartoon writeup]. All of the text was sandwiched between two walls of images, and on wider browser windows, the pictures push each other down into ''multiple'' sections below (thanks to not using <nowiki>{{-}} or {{--}}</nowiki> breaks, while ''having'' those would have caused a huge whitespace gap between the image columns), ''severely'' janking up the page's layout and readability. Currently, the page has about half as many images: some were moved to other relevant pages, others were deleted altogether as they simply weren't necessary.		It is entirely possible to have ''too many'' images in a section. A good example of this is this [https://tfwiki.net/mediawiki/index.php?title=Windblade_(RID)&oldid=1579547 older version of ''Robots in Disguise'' Windblade's cartoon writeup]. All of the text was sandwiched between two walls of images, and on wider browser windows, the pictures push each other down into ''multiple'' sections below (thanks to not using <nowiki>{{-}} or {{--}}</nowiki> breaks, while ''having'' those would have caused a huge whitespace gap between the image columns), ''severely'' janking up the page's layout and readability. Currently, the page has about half as many images: some were moved to other relevant pages, others were deleted altogether as they simply weren't necessary.

	Remember, images are ''supplemental'' to the text, and should themselves relay information. Consider what's ''in'' the image and what it tells the reader, especially in relation to other images in the same section. Is it expanding on the character or scene in question in some way? Are you adding something useful, or simply contributing to clutter? A close-up bust shot of a character talking calmly in a section that already has multiple images ''probably'' isn't adding anything useful, while a close-up of a character showing extreme emotion... ''might''.		Remember, images are ''supplemental'' to the text, and should themselves relay information. Consider what's ''in'' the image and what it tells the reader, especially in relation to other images in the same section. Is it expanding on the character or scene in question in some way? Are you adding something useful, or simply contributing to clutter? A close-up bust shot of a character talking calmly in a section that already has multiple images ''probably'' isn't adding anything useful, while a close-up of a character showing extreme emotion... ''might''.

M Sipher: /* Image content (Or: Do you really need that image?) */

2024-12-21T02:27:01Z

Image content (Or: Do you really need that image?)

← Older revision		Revision as of 02:27, 21 December 2024
Line 73:		Line 73:
	So, what makes for a useful image?		So, what makes for a useful image?

	In most normal circumstances, it is best to use full, uncropped screen grabs or comic panels (or even more than one sequential panel in some circumstances), providing extra context. Of course, this is somewhat dependent on how much actual text the image is accompanying: if the section in question amounts to little more than a small cameo, a close crop on just the character (or group they're in, especially if it's a wide shot) ''might'' work better with the layout than a full-sized panel/screenshot.		In most normal circumstances, it is best to use full, uncropped screen grabs or comic panels (or even more than one sequential panel in some circumstances), providing extra context. Of course, this is somewhat dependent on how much actual text the image is accompanying: if the section in question amounts to little more than a small cameo, a close crop on just the character (or group they're in, especially if it's a wide shot, plus that one image can be used on multiple characters' pages!) ''might'' work better with the layout than a full-sized panel/screenshot.

	As ''Transformers'' characters often have different designs across different media, it's a good idea to make sure there's at least one image that shows as much of their differing design(s) in all modes, if available. Depending on the length of the section, it might be a good idea to take the two separate images of the robot and alternate mode and combine them into a single wider image. It's also generally good to focus on ''moments'', be they of action or emotional beats. If you can marry that with the "show the design off" intent of an image, all the better. [[Strika (BM)#Fiction\|''Beast Machines'' Strika's fiction section]] is a good example. Her appearances in each piece of (visual) media are supplemented with images that show off her differing designs, with alternate mode images, using full shots/panels, and generally are also plot-important (or simply bad-ass) moments to boot.		As ''Transformers'' characters often have different designs across different media, it's a good idea to make sure there's at least one image that shows as much of their differing design(s) in all modes, if available. Depending on the length of the section, it might be a good idea to take the two separate images of the robot and alternate mode and combine them into a single wider image. It's also generally good to focus on ''moments'', be they of action or emotional beats. If you can marry that with the "show the design off" intent of an image, all the better. [[Strika (BM)#Fiction\|''Beast Machines'' Strika's fiction section]] is a good example. Her appearances in each piece of (visual) media are supplemented with images that show off her differing designs, with alternate mode images, using full shots/panels, and generally are also plot-important (or simply bad-ass) moments to boot.

M Sipher: /* Not enough text! */

2024-04-20T08:54:26Z

Not enough text!

← Older revision		Revision as of 08:54, 20 April 2024
Line 125:		Line 125:

	This can often be a problem in Fiction sections of character pages when the character in question really doesn't do much. Rather than simply narrow-focusing on their ''exact'' actions, you can give a bit of broader context to what's going on around them. Try adding a general setup of the scene and what consequences (if any) there were that the character in question might not have even been directly around/alive for. Aside from the valuable context provided, this also helps cut down on whitespace if you have an image of the character to add to the section. Compare:		This can often be a problem in Fiction sections of character pages when the character in question really doesn't do much. Rather than simply narrow-focusing on their ''exact'' actions, you can give a bit of broader context to what's going on around them. Try adding a general setup of the scene and what consequences (if any) there were that the character in question might not have even been directly around/alive for. Aside from the valuable context provided, this also helps cut down on whitespace if you have an image of the character to add to the section. Compare:
	:"Flargotron got hit by a hurled brick at the Deep Oil Cleanse Riots."
	:"Eleventeen million years ago, Flargotron joined in a protest outside the Lubeorium during Cybertron's tumultuous Deep Oil Cleanse Riots. As the arguing between protestors and the state-run Regreasers reached a fever pitch, Flargotron got hit in the head with a brick thrown by rogue cop Bastion, knocking them insensible. This set off a spree of violence that would ultimately result in Senator Ratbat winning ''Kaon's Got Talent''."		: "Flargotron got hit by a hurled brick at the Deep Oil Cleanse Riots."

			: ...versus...

			: "Eleventeen million years ago, Flargotron joined in a protest outside the Lubeorium during Cybertron's tumultuous Deep Oil Cleanse Riots. As the arguing between protestors and the state-run Regreasers reached a fever pitch, Flargotron got hit in the head with a brick thrown by rogue cop Bastion, knocking them insensible. This set off a spree of violence that would ultimately result in Senator Ratbat winning ''Kaon's Got Talent''."

	If a character makes multiple very minor/background appearances across several installments of a cartoon/comic that can each be summed up in a sentence or two, then it might be good idea to consolidate them all into a single paragraph. Doing so lightly emphasizes/mirrorrs their briefness and "face in a crowd" nature, where a bunch of isolated sentence-paragraphs gives the feel of "highlighting" stuff that doesn't really need to be highlighted. It's certainly better than seeing this:		If a character makes multiple very minor/background appearances across several installments of a cartoon/comic that can each be summed up in a sentence or two, then it might be good idea to consolidate them all into a single paragraph. Doing so lightly emphasizes/mirrorrs their briefness and "face in a crowd" nature, where a bunch of isolated sentence-paragraphs gives the feel of "highlighting" stuff that doesn't really need to be highlighted. It's certainly better than seeing this:

M Sipher: /* Linebreaks and empty space */

2024-03-26T21:49:29Z

Linebreaks and empty space

← Older revision		Revision as of 21:49, 26 March 2024
Line 53:		Line 53:
	Normally, text "flows" around images. If you place an image in the code, any text you add below it will push up into the space to the side of the image... but other images will ''not''. This can lead to an image at the end of a section pushing down into the next, and pushing any images at the ''top'' of that section further down than they should be, messing up the layout. Placing a '''<nowiki>{{-}}</nowiki>''' or '''<nowiki>{{--}}</nowiki>''' at the end of a section creates a linebreak at that point, a border that prevents text below it from sliding up.		Normally, text "flows" around images. If you place an image in the code, any text you add below it will push up into the space to the side of the image... but other images will ''not''. This can lead to an image at the end of a section pushing down into the next, and pushing any images at the ''top'' of that section further down than they should be, messing up the layout. Placing a '''<nowiki>{{-}}</nowiki>''' or '''<nowiki>{{--}}</nowiki>''' at the end of a section creates a linebreak at that point, a border that prevents text below it from sliding up.

	~~Which one~~ should ~~be used varies on the situation. The~~ <nowiki>{{-}}</nowiki> places an ''extra'' linebreak, leaving a bit of empty space between what's above and below it. ~~Honestly, this is generally preferred, as it~~ gives a little bit of visual "breathing room" if the lowest thing in the section is text, keeping it from being too close to the next section's header title and looking smooshed. (It's why there's spaces between the subheaders on this very page!) <nowiki>{{--}}</nowiki> can be ~~better~~ if the lowest thing is likely going to be the bottom of an image... but ''sometimes'' this doesn't actually stop the image from pushing down in to the next header for uncertain reasons.		In most situations, you should use <nowiki>{{-}}</nowiki>. The single-dash version places an ''extra'' linebreak under the text (but not the image), leaving a bit of empty space between what's above and below it. This gives a little bit of visual "breathing room"/"stopping point" if the lowest thing in the section is text, keeping it from being too close to the next section's header title and looking smooshed. (It's why there's spaces between the subheaders on this very page!) <nowiki>{{--}}</nowiki> can be used if the lowest thing in a section is likely going to be the bottom of an image... but ''sometimes'' this doesn't actually stop the image from pushing down in to the next header for uncertain reasons.

	However, ~~this~~ can ~~''also''~~ cause ~~problems~~ as it can leave a massive block of empty space under the text, depending on how tall the image is. This is not ideal; large gaps can severely break the "flow" of reading, and just looks ''bad''. We don't like big blocks of empty white space. We've done a lot of work trying to reduce it (see "[[#Collists and Tables\|Collists and Tables]]"). Which means taking careful consideration of your image choices.		However, using these templates can potentially cause layout issues, as it can leave a massive block of empty space under the text, depending on how tall the image is. This is not ideal; large gaps can severely break the "flow" of reading, and just looks ''bad''. We don't like big blocks of empty white space. We've done a lot of work trying to reduce it (see "[[#Collists and Tables\|Collists and Tables]]"). Which means taking careful consideration of your image choices.

	This can be a problem with very short headers, such as describing a character's minor role in a piece of fiction. Try to use an image that is more horizontal than vertical in these instances. This is easy when using screen grabs of video media since most of it's already horizontal, but can be a bit trickier when dealing with comic panels.		This can be a problem with very short headers, such as describing a character's minor role in a piece of fiction. Try to use an image that is more horizontal than vertical in these instances. This is easy when using screen grabs of video media since most of it's already horizontal, but can be a bit trickier when dealing with comic panels.

M Sipher: /* Too much text! */

2024-03-11T01:17:14Z

Too much text!

← Older revision		Revision as of 01:17, 11 March 2024
Line 107:		Line 107:

	There's also ways of breaking up big text blocks with different layout/template options, but these are heavily dependent on what the section is about.		There's also ways of breaking up big text blocks with different layout/template options, but these are heavily dependent on what the section is about.

			[[File:GeordiHatesCrampedBullets.jpg\|upright=1.67\|thumb\|]]

	* Bullet points can be an important tool for visually breaking up a bulky section of semi-short paragraphs all following a list-like theme, as seen in "Toy images" above, or any page's "Notes" section. Simply put an asterisk (*) at the start of the line, and the wiki will add a bullet point there, providing a nice little eyecatch and helping to emphasize the distinctness of each piece of information.		* Bullet points can be an important tool for visually breaking up a bulky section of semi-short paragraphs all following a list-like theme, as seen in "Toy images" above, or any page's "Notes" section. Simply put an asterisk (*) at the start of the line, and the wiki will add a bullet point there, providing a nice little eyecatch and helping to emphasize the distinctness of each piece of information.
	* Generally, this should ''not'' be used in "in-fiction" sections. It's generally best for writing about "real world" stuff, but sometimes, ''sometimes'', a bullet point can be better at getting across information that might end up being a bit too complex to parse in normal paragraph form. (Or if it's particularly funny to do so.)		* Generally, this should ''not'' be used in "in-fiction" sections. It's generally best for writing about "real world" stuff, but sometimes, ''sometimes'', a bullet point can be better at getting across information that might end up being a bit too complex to parse in normal paragraph form. (Or if it's particularly funny to do so.)
			* Oh, it's a little thing, but... it helps to put a single space between the * and the following text. This will not effect how it looks on the page proper, but ''does'' make it a lot easier for ''editors'' to pick out an individual bullet point in the editing space when there's a lot of them and they're multiple "lines" long. You can also put an extra return in there if you really really want to when the bullet points trend towards larger paragraphs; again, the on-screen difference is negligible at most, but for anyone going in to edit a single one, it can save some eyestrain and annoyance.
	You can sub-bullet-point by following the next entry with () or (:*), but this should be used ''very'' sparingly. Not only are we not Wikipedia, we are not TV Tropes.		You can sub-bullet-point by following the next entry with () or (:*), but this should be used ''very'' sparingly. Not only are we not Wikipedia, we are not TV Tropes.

Line 115:		Line 118:
	{{bigquote\|You can sometimes break up a character page's overlong fiction section with a relevant quote about/from them from said fiction, using the <nowiki>{{quote}} (left-justified) or {{bigquote}} (centered)</nowiki> template.\|TFWIKI.net, "editing layout guide" page}}		{{bigquote\|You can sometimes break up a character page's overlong fiction section with a relevant quote about/from them from said fiction, using the <nowiki>{{quote}} (left-justified) or {{bigquote}} (centered)</nowiki> template.\|TFWIKI.net, "editing layout guide" page}}
	{{bigquote\|We don't use this terribly often, but consider it if a single section is multiple screens long and there's a ''really good'' line you can use as an illustrative example.\|TFWIKI.net, "editing layout guide" page}}		{{bigquote\|We don't use this terribly often, but consider it if a single section is multiple screens long and there's a ''really good'' line you can use as an illustrative example.\|TFWIKI.net, "editing layout guide" page}}

			Sometimes, there's just gonna be a lot of text. A big giant toy with loads of play features, for example, is just going to end up with a lot of text no matter how judiciously you edit. In these cases, bear in mind how the information within all that text is organized/placed. Try and keep "like" concepts together in the same paragraph: don't bounce from a deco note to a play feature then back to a deco note. Don't just tack new information onto the end of an already-existing writeup, figure out the best place to work it in, and rework other related sections if need be.

	===Not enough text!===		===Not enough text!===

M Sipher: /* Too much text! */

2024-03-04T08:53:46Z

Too much text!

← Older revision		Revision as of 08:53, 4 March 2024
Line 110:		Line 110:
	* Bullet points can be an important tool for visually breaking up a bulky section of semi-short paragraphs all following a list-like theme, as seen in "Toy images" above, or any page's "Notes" section. Simply put an asterisk (*) at the start of the line, and the wiki will add a bullet point there, providing a nice little eyecatch and helping to emphasize the distinctness of each piece of information.		* Bullet points can be an important tool for visually breaking up a bulky section of semi-short paragraphs all following a list-like theme, as seen in "Toy images" above, or any page's "Notes" section. Simply put an asterisk (*) at the start of the line, and the wiki will add a bullet point there, providing a nice little eyecatch and helping to emphasize the distinctness of each piece of information.
	* Generally, this should ''not'' be used in "in-fiction" sections. It's generally best for writing about "real world" stuff, but sometimes, ''sometimes'', a bullet point can be better at getting across information that might end up being a bit too complex to parse in normal paragraph form. (Or if it's particularly funny to do so.)		* Generally, this should ''not'' be used in "in-fiction" sections. It's generally best for writing about "real world" stuff, but sometimes, ''sometimes'', a bullet point can be better at getting across information that might end up being a bit too complex to parse in normal paragraph form. (Or if it's particularly funny to do so.)
	You can sub-bullet-point by following the next entry with (), but this should be used ''very'' sparingly. Not only are we not Wikipedia, we are not TV Tropes.		You can sub-bullet-point by following the next entry with () or (:*), but this should be used ''very'' sparingly. Not only are we not Wikipedia, we are not TV Tropes.


	{{bigquote\|You can sometimes break up a character page's overlong fiction section with a relevant quote about/from them from said fiction, using the <nowiki>{{quote}} (left-justified) or {{bigquote}} (centered)</nowiki> template.\|TFWIKI.net, "editing layout guide" page}}		{{bigquote\|You can sometimes break up a character page's overlong fiction section with a relevant quote about/from them from said fiction, using the <nowiki>{{quote}} (left-justified) or {{bigquote}} (centered)</nowiki> template.\|TFWIKI.net, "editing layout guide" page}}
	{{bigquote\|We don't use this terribly often, but consider it if a single section is multiple screens long and there's a ''really good'' line you can use as an illustrative example.\|TFWIKI.net, "editing layout guide" page}}		{{bigquote\|We don't use this terribly often, but consider it if a single section is multiple screens long and there's a ''really good'' line you can use as an illustrative example.\|TFWIKI.net, "editing layout guide" page}}


	===Not enough text!===		===Not enough text!===

M Sipher: /* Thumbnail size */

2024-03-04T08:30:33Z

Thumbnail size

← Older revision		Revision as of 08:30, 4 March 2024
Line 28:		Line 28:
	Sometimes, it may be necessary to have a thumbnail larger than our standard. A good example is on pages where the "mainpic" at the top is more horizontal than vertical. Mainpics should have a decently large "footprint" to catch the reader's eye, and since most character page mainpics are more vertical than horizontal (typically being close-cropped images of a full-body shot when possible), the standard width means they take up a good amount of space. But if the only clear media images are close-ups, or if there are ''no'' media images and the mainpic is a photograph of a toy (typical for lots of [[Mini-Con]]s and [[Transformers: BotBots (toyline)\| BotBots]]), then those horizontal images should probably be stretched out a bit. Particularly ''involved'' images used to illustrate an important point, such as [[Gang-molding\|this image demonstrating "Gang-molding" in action]], may also need to be bigger, especially if they have more explanatory captions. "Upright=2" will often be enough, and on on rare occasion you might need to go up to 2.33... but any bigger is going to take a hell of a lot of justifying.		Sometimes, it may be necessary to have a thumbnail larger than our standard. A good example is on pages where the "mainpic" at the top is more horizontal than vertical. Mainpics should have a decently large "footprint" to catch the reader's eye, and since most character page mainpics are more vertical than horizontal (typically being close-cropped images of a full-body shot when possible), the standard width means they take up a good amount of space. But if the only clear media images are close-ups, or if there are ''no'' media images and the mainpic is a photograph of a toy (typical for lots of [[Mini-Con]]s and [[Transformers: BotBots (toyline)\| BotBots]]), then those horizontal images should probably be stretched out a bit. Particularly ''involved'' images used to illustrate an important point, such as [[Gang-molding\|this image demonstrating "Gang-molding" in action]], may also need to be bigger, especially if they have more explanatory captions. "Upright=2" will often be enough, and on on rare occasion you might need to go up to 2.33... but any bigger is going to take a hell of a lot of justifying.

	And sometimes, you might actually need to go ''smaller'' than our default, typically to cut empty space in sections without a lot of text (more on that below), but there's other reasons as well. "1.4" tends to be used for cartoon screen grabs to keep them from eating up ''too'' much space. Comic panel widths can vary depending on panel layout, naturally, and a more vertical panel should probably be displayed thinner. Regardless of what size you use, in ''general'' it is a good idea to try and keep the images a consistent width within a single subsection. Not setting a width will make the thumbnail default to "1", but you can also make sure of that by setting it in the code. Going even smaller than the default ''can'' be the best route when the image itself is really small or very thin, but in general the smaller you go the less point there even is to the image in the first place. At that point, you might want to consider changing the image itself to better work with the page layout, or even if you need the image ''at all'' (see [[#Image content (Or: Do you really need that image?)\|below]] for more on that scenario).		And sometimes, you might actually need to go ''smaller'' than our default, typically to cut empty space in sections without a lot of text (more on that below), but there's other reasons as well. "1.4" tends to be used for older, pre-widescreen cartoon screen grabs to keep them from eating up ''too'' much space. Comic panel widths can vary depending on panel layout, naturally, and a more vertical panel should probably be displayed thinner. Regardless of what size you use, in ''general'' it is a good idea to try and keep the images a consistent width within a single subsection. Not setting a width will make the thumbnail default to "1", but you can also make sure of that by setting it in the code. Going even smaller than the default ''can'' be the best route when the image itself is really small or very thin, but in general the smaller you go the less point there even is to the image in the first place. At that point, you might want to consider changing the image itself to better work with the page layout, or even if you need the image ''at all'' (see [[#Image content (Or: Do you really need that image?)\|below]] for more on that scenario).
	{{-}}		{{-}}

M Sipher: /* Thumbnail size */

2024-03-04T07:43:02Z

Thumbnail size

← Older revision		Revision as of 07:43, 4 March 2024
Line 26:		Line 26:
	{{note\|You might see some images on the wiki are at <nowiki>"upright=1.67"</nowiki>. This is fine, as the difference is almost imperceptible unless the images are close together... which they often can be, especially in a "Toys" section. It's best to keep the width consistent with whatever measurement the page is already using. Some pages still use pixel dimensions (<nowiki>"width=300px"</nowiki>), that is old code and should probably be replaced. 300 pixels is roughly the same width as 1.66.}}		{{note\|You might see some images on the wiki are at <nowiki>"upright=1.67"</nowiki>. This is fine, as the difference is almost imperceptible unless the images are close together... which they often can be, especially in a "Toys" section. It's best to keep the width consistent with whatever measurement the page is already using. Some pages still use pixel dimensions (<nowiki>"width=300px"</nowiki>), that is old code and should probably be replaced. 300 pixels is roughly the same width as 1.66.}}

	Sometimes, it may be necessary to have a thumbnail larger than our standard. A good example is on pages where the "mainpic" at the top is more horizontal than vertical. Mainpics should have a decently large "footprint" to catch the reader's eye, and since most character page mainpics are more vertical than horizontal (typically being close-cropped images of a full-body shot when possible), the standard width means they take up a good amount of space. But if the only clear media images are close-ups, or if there are ''no'' media images and the mainpic is a photograph of a toy (typical for lots of [[Mini-Con]]s and [[Transformers: BotBots (toyline)\| BotBots]]), then those horizontal images should probably be stretched out a bit. Particularly ''involved'' images used to illustrate an important point, such as [[Gang-molding\|this image demonstrating "Gang-molding" in action]], may also need to be bigger, especially if they have more explanatory captions. "Upright=2" will often be enough, and on on occasion you might need to go up to 2.33... but any bigger is going to take a hell of a lot of justifying.		Sometimes, it may be necessary to have a thumbnail larger than our standard. A good example is on pages where the "mainpic" at the top is more horizontal than vertical. Mainpics should have a decently large "footprint" to catch the reader's eye, and since most character page mainpics are more vertical than horizontal (typically being close-cropped images of a full-body shot when possible), the standard width means they take up a good amount of space. But if the only clear media images are close-ups, or if there are ''no'' media images and the mainpic is a photograph of a toy (typical for lots of [[Mini-Con]]s and [[Transformers: BotBots (toyline)\| BotBots]]), then those horizontal images should probably be stretched out a bit. Particularly ''involved'' images used to illustrate an important point, such as [[Gang-molding\|this image demonstrating "Gang-molding" in action]], may also need to be bigger, especially if they have more explanatory captions. "Upright=2" will often be enough, and on on rare occasion you might need to go up to 2.33... but any bigger is going to take a hell of a lot of justifying.

	And sometimes, you might actually need to go ''smaller'' than our default, typically to cut empty space in sections without a lot of text (more on that below), but there's other reasons as well. "1.4" tends to be used for cartoon screen grabs to keep them from eating up ''too'' much space. Comic panel widths can vary depending on panel layout, naturally, and a more vertical panel should probably be displayed thinner. Regardless of what size you use, in ''general'' it is a good idea to try and keep the images a consistent width within a single subsection. Not setting a width will make the thumbnail default to "1", but you can also make sure of that by setting it in the code. Going even smaller than the default ''can'' be the best route when the image itself is really small or very thin, but in general the smaller you go the less point there even is to the image in the first place. At that point, you might want to consider changing the image itself to better work with the page layout, or even if you need the image ''at all'' (see [[#Image content (Or: Do you really need that image?)\|below]] for more on that scenario).		And sometimes, you might actually need to go ''smaller'' than our default, typically to cut empty space in sections without a lot of text (more on that below), but there's other reasons as well. "1.4" tends to be used for cartoon screen grabs to keep them from eating up ''too'' much space. Comic panel widths can vary depending on panel layout, naturally, and a more vertical panel should probably be displayed thinner. Regardless of what size you use, in ''general'' it is a good idea to try and keep the images a consistent width within a single subsection. Not setting a width will make the thumbnail default to "1", but you can also make sure of that by setting it in the code. Going even smaller than the default ''can'' be the best route when the image itself is really small or very thin, but in general the smaller you go the less point there even is to the image in the first place. At that point, you might want to consider changing the image itself to better work with the page layout, or even if you need the image ''at all'' (see [[#Image content (Or: Do you really need that image?)\|below]] for more on that scenario).

	{{-}}		{{-}}

M Sipher: /* Placement */

2024-02-06T00:27:45Z

Placement

← Older revision		Revision as of 00:27, 6 February 2024
Line 34:		Line 34:
	===Placement===		===Placement===
	You don't actually ''have'' to put the "<span style="font-family: 'Courier New';">\|right\|</span>" in the image code, as the default placement is on the right side of the screen if it's left out. It's fine if you do have it in there though. However, if you want the image to be on the left side of the screen instead, then obviously you add in "<span style="font-family: 'Courier New';">\|left\|</span>" instead... but think about if you ''should''. Left-justified images can cause some problems if not placed with care.		You don't actually ''have'' to put the "<span style="font-family: 'Courier New';">\|right\|</span>" in the image code, as the default placement is on the right side of the screen if it's left out. It's fine if you do have it in there though. However, if you want the image to be on the left side of the screen instead, then obviously you add in "<span style="font-family: 'Courier New';">\|left\|</span>" instead... but think about if you ''should''. Left-justified images can cause some problems if not placed with care.
	[[File:Tfwiki badleft-goodleft.jpg\|left\|thumb\|upright=1\|Top: Ooof.<br>Bottom: That's fine.]]		[[File:Tfwiki badleft-goodleft.jpg\|left\|thumb\|upright=1\|''Top'': Ooof.<br>''Bottom'': That's fine.]]

	''Do not'' immediately open a subheader with a left-justified image. The natural inclination at a line break is to look back left for the next line, and putting an image there usually means the reader has to look ''right'' to find the text instead. If there's some short yet longer-than-the-image text that can go above the image, like an actor/voice-actor template or explanatory note, following that up with a left-justified image underneath might be fine, just check how this affects any headers below (having a header text shoved right because of an image dipping down does not look very good). You want a nice "flow" of text.		''Do not'' immediately open a subheader with a left-justified image. The natural inclination at a line break is to look back left for the next line, and putting an image there usually means the reader has to look ''right'' to find the text instead. If there's some short yet longer-than-the-image text that can go above the image, like an actor/voice-actor template or explanatory note, following that up with a left-justified image underneath might be fine, just check how this affects any headers below (having a header text shoved right because of an image dipping down does not look very good). You want a nice "flow" of text.
Line 40:		Line 40:
	In general, images should only be put to the left of the page in longer multi-paragraph sections, like in a major character's "Fiction" section, ''after'' the first right-justified image. Take a look at [[Spud Muffin#BotBots cartoon\|Spud Muffin's cartoon writeup]] as an example. Alternating between right- and left-justified images helps visually break up what would otherwise be a ''massive'' wall of text, giving the reader easy "checkpoints" to keep track of where they are. Generally, you want one image per two to three paragraphs, depending of course on paragraph and section length (and don't overload the section with images, see "[[#Image content (Or: Do you really need that image?)\|Image content]]" below.)		In general, images should only be put to the left of the page in longer multi-paragraph sections, like in a major character's "Fiction" section, ''after'' the first right-justified image. Take a look at [[Spud Muffin#BotBots cartoon\|Spud Muffin's cartoon writeup]] as an example. Alternating between right- and left-justified images helps visually break up what would otherwise be a ''massive'' wall of text, giving the reader easy "checkpoints" to keep track of where they are. Generally, you want one image per two to three paragraphs, depending of course on paragraph and section length (and don't overload the section with images, see "[[#Image content (Or: Do you really need that image?)\|Image content]]" below.)

	In Toy writeups, you may sometimes need more than one image for a single toy, typically when there's significant differences between the [[Hasbro]] and [[TakaraTomy\|Takara]] releases (which happens a ''lot'' less often now, hardly ever, but for quite a while it was a thing). Toy images should basically stay right-justified to make these comparisons easier (though if there's not ''enough'' text and that leads to empty space, ~~exceptions can~~ be ~~made~~). It is rare that an individual toy's writeup will become long enough to justify left-justified images, but it ''has'' happened with larger and more complex toys. The ~~complex~~ ''[[Transformers: Armada (toyline)\|Armada]]'' [[Optimus Prime (Armada)/toys#Armada\|Super Base Optimus Prime]] toy is a great example: something this big with major color variances between markets and major interactions with other toys requires quite a few images, and making them all right-justified would still end up much longer than the massive amount of text.		[[File:Tfwiki toyimage placement.jpg\|right\|thumb\|uprigh=1.66\|''Top'': There's more than enough text for two full-size right-justified images.<br>''Bottom'': Doing so here would create a lot of whitespace, so a smaller, left-justified image fits better.]]
	~~(((((Clocker_(Cybertron)#Toys Clocker image example)))))~~
			In Toy writeups, you may sometimes need more than one image for a single toy, typically when there's significant differences between the [[Hasbro]] and [[TakaraTomy\|Takara]] releases (which happens a ''lot'' less often now, hardly ever, but for quite a while it was a thing). Toy images should basically stay right-justified to make these comparisons easier, though if there's not ''enough'' text and that leads to large chunks of empty space, a smaller left-justifed second image might be in order (as seen in the image to the right). It is rare that an individual toy's writeup will become long enough to justify full-sized left-justified images, but it ''has'' happened with larger and more complex toys. The ''[[Transformers: Armada (toyline)\|Armada]]'' [[Optimus Prime (Armada)/toys#Armada\|Super Base Optimus Prime]] toy is a great example: something this big with major color variances between markets and major interactions with other toys requires quite a few images, and making them all right-justified would still end up much longer than the massive amount of text.

	You can also, rather than placing an image onto the page, instead [[:File:Rick Astley.jpg\|direct-link to an image file as a simple text link]]. All you need to do there is add a colon before the "File" in the markup, like so: "<span style="font-family: 'Courier New';"><nowiki>[[:File:filename.jpg\|descriptive text]]</nowiki></span>". This is best used when adding an image would jank up the layout pretty badly for not a lot of major benefit; for example, linking to a toy image when referencing it on a page for a piece of fiction, or linking to a stock image of a toy with minor changes from the finished product, instead of forcing it into a short toy writeup. Bear in mind, though, that if you do decide to text-link an image:		You can also, rather than placing an image onto the page, instead [[:File:Rick Astley.jpg\|direct-link to an image file as a simple text link]]. All you need to do there is add a colon before the "File" in the markup, like so: "<span style="font-family: 'Courier New';"><nowiki>[[:File:filename.jpg\|descriptive text]]</nowiki></span>". This is best used when adding an image would jank up the layout pretty badly for not a lot of major benefit; for example, linking to a toy image when referencing it on a page for a piece of fiction, or linking to a stock image of a toy with minor changes from the finished product, instead of forcing it into a short toy writeup. Bear in mind, though, that if you do decide to text-link an image: