User:M Sipher/Sandbox:EditingLayoutGuide
So, you've got your new TFWIKI.NET account. You've gotten your greeting notice, and you're ready to edit. You'll just start small at first... add a picture or two to a character page, maybe add the newest (officially revealed) toys to a toyline page. That's simple enough, what could go wrong?
Well....
When we say "we are not Wikipedia", we're not just talking about snarky captions. In many respects, we simply do some fundamental things slightly —or significantly— different from other wikis. Over many years we've developed a lot of bespoke standards for page layouts and editing, along with many custom-made templates, designed with the specific goal of making sure any information we present is done in a way that looks as good as possible and makes the site physically easier for people to read, and we are a bit more stringent in maintaining that. We aim for a professional presentation, even when we're being silly. New editors unfamiliar with the backstage shenanigans of editing TFWIKI.NET may end up doing something that seems normal but breaks the "flow" of a page. Even experienced editors can sometimes slip up.
While there are guides on how to build entire pages from scratch, this page is here to cover some of the more common, sometimes "invisible" things that can come up when editing even just a section of an already-existing page. Basically, this is here to show you how to step back and look at how your edits can affect the whole of the page you're editing. Because focusing solely on the detail directly in front of you and failing to step back and look at how it works with the bigger picture is how you get a Michael Bay movie.
{{#if:||
}}
First things first
[edit]{{#if: LOLprowl-sm.gif |
{{#if: ||}}
|}} Please use the Preview button when making numerous small changes to a single page, using "Save page" only after all your changes are made. This way, you don't clutter the Recent Changes page with a ton of tiny little edits.
{{ #if: |{{ #if: | | |
{{#ifeq: User||}}{{#ifeq: User|File|}}
No, really. The "Preview changes" button is your friend. Welcome it into your life. It can save you a lot of hassle.
Images
[edit]Thumbnail size
[edit]The coding for placing a thumbnail image looks like this:
[[File:filename.jpg|thumb|upright=1.66|right|Caption goes here.]]
Our standard image thumbnail width is "upright=1.66", meaning 66% larger than the default thumbnail size automatically used if you do not indicate the image width. We use this slightly-larger thumbnail size as Transformers imagery is often very busy visually, which can make smaller thumbnails a bit of an eyestrain.
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-Cons and BotBots), then those horizontal images should probably be stretched out a bit. Particularly involved images used to illustrate an important point, such as 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 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 below for more on that scenario).
Placement
[edit]You don't actually have to put the "|right|" 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 "|left|" instead... but think about if you should. Left-justified images can cause some problems if not placed with care.
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.
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'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" below.)
Bottom: Doing so here would create a lot of whitespace, so a smaller, left-justified image fits better.
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 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 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 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: "[[:File:filename.jpg|descriptive text]]". 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:
- 1) Make sure to add "this file is text-linked to on [page name here], do not delete" in the file description, especially if the image is not used as a thumbnail on any other pages.
- 2) Depending on the image, you might instead want to merge it with one thumbnailed on the page, like the toy-variant example listed above, if there's room. Best to make it a smaller bordered "inset panel" with some text noting "Hasbro stock image" or such.
Linebreaks and empty space
[edit]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 {{-}} or {{--}} at the end of a section creates a linebreak at that point, a border that prevents text below it from sliding up.
In most situations, you should use {{-}}. 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!) {{--}} 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, 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"). 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.
There is one place where it can be perfectly okay to let an image drop down into the following subheader: in the "Notes" section. Generally the only thing that should go below Notes are things like "References" and "External Links", neither of which require images, and those typically leave a bunch of empty space on the right side of the page anyway. If the Notes section doesn't have any images, it's also okay to have images from the section above (usually "Toys"), drop down into Notes if otherwise you'd end up with a big hunka whitespace between the two.
Oh, and one last thing: captions. While this wiki is (in)famous for its image captions, we do have some standards (see the link), and one of those is a certain degree of brevity. Long "joke" captions run the risk of not just being unfunny, but of screwing with the layout. If the caption takes up more vertical space than the actual image, dial it back.
Image content (Or: Do you really need that image?)
[edit]It is entirely possible to have too many images in a section. A good example of this is this 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 {{-}} or {{--}} 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.
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, 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. 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.
That said, not every "important" moment needs an image. For a while, there was an issue where images of characters' deaths were added to many pages, which often led to clutter, extra empty space, and was just kinda gruesome. Be choosy in what you add.
Creating toy images
[edit]
While TFWIKI.NET does make use of official stock imagery as needed, we do encourage the use of original, user-created images for a multitude of reasons (among them, stock images are rarely of actual final product and may have differences from the real deal, plus many old stock images are low-quality "old web" images). If you plan to make images yourself, we do have standards for both quality and content. Out of focus, badly-lit images, or images of particularly ratty and incomplete toys will typically be deleted and replaced with available stock images. Also, it is generally frowned upon to replace images created by another user, though it can sometimes be acceptable to replace particularly old, smaller, or incomplete images (the wiki is nearly two decades old at this point, digital photography (and download speed) has come a long way in that time).
Please keep these guides in mind when creating a toy image. Note that these apply to both user-made photos and official stock photos that have been edited into a single image.
- Pictures should be against a plain, detail-less background, preferably white. Whether you leave your backdrop visible (as with Road Rocket's image to the right) or digitally remove the background to be a pure single color (as seen with Megaplex's image) is up to you, either is fine. The latter definitely takes more time to do in a way that looks nice, and we don't expect anyone to go that far (we do appreciate the effort though). Complex backgrounds can make the thumbnails cluttered, so avoid them if at all possible. But if the only stock imagery there is has the toy on a complicated backdrop, or if the only photo of a rare, unobtainable item you can find online is on someone's kitchen table, well, so be it.
- Try to keep the image generally horizontal. A 4:3 width/height ratio is a good "minimum"/target to work with; for example, a 600-pixel high image (which is generally big enough for most toys, we don't need super-huge images) should then be at least 800 pixels wide. If the toy doesn't fill all that width (like a single-mode Action Master or a combiner team's super-robot mode), honestly, that's fine, a little space on the sides doesn't hurt at all; some entries really don't have a lot to say about them, so horizontal images helps reduce the empty space below the text. Going even wider is of course fine if you need the space, but once you start getting close to a 2:1 ratio, you might want to see if you can do a bit of compressing or rearranging somewhere. Of course, more complex toys with more than two modes may require a more square image to capture everything (and a bigger pixel height at full size viewing; Megaplex's image is 700px tall to retain detail). Keep in mind the amount of text that will be next to this; a long writeup gives you a lot more leeway for a more vertical image.
- Be sure to include all official individual modes, and have all included accessories somewhere in the image. As long as their gun/sword/whatever is visible in at least one mode, you don't need to worry about adding it to the other(s) (unless you really really want to). Do not split alternate modes into separate images from the robot mode, keep them all in one image.
- Toys that can combine with others typically do not need to have their combined-mode forms in the images (such as combiner limbs), as those should appear in the separate images of the assembled "super robot" mode. There are some instances where it might be beneficial to include these modes, the most obvious being with the Micromaster Combiners where each individual forms only half a vehicle. Some of the Energon Autobots can form the torso or legs to a two-robot combiner but do not have any named "super robot" modes, thus there's no relevant page or combined-mode picture to feature them otherwise.
- Some features of the toy, such as deployed gimmicks and alternate accessories, can be in "inset" panels, zoomed in close to just show the bits that changed in order to save space. The more gimmicks and alternate parts a toy has, the more this might be needed. Try to keep insets grouped together, rather than scattered across the image.
- Minimize empty space at the top and bottom of the image; typically the robot mode would be the yardstick here. Ideally, their head and feet (or whatever bits are the highest/lowest) should come close to the top and bottom edges of the image. Of course, multi-changers can muddle this a bit, but still, whatever element is the highest/lowest should be right at the top/bottom edge of the image.
- It's not a requirement per se, but we really do prefer the "robot" mode on the left side of the image, with the alternate mode(s) to the right. Most of our images are like this, and it's good to keep that visual consistency.
- Oh and please add the TFWIKI.NET watermark to your image, which can be found HERE. Ideally it should go in an unobtrusive part of the image; bottom-right corner is usually good, but any empty space will work. Putting it at a 50% opacity helps too if it ends up needing to overlap the toy (which is fine if it does).
Text layout
[edit]Too much text!
[edit]The wiki is a very text-heavy site. It can be tricky to avoid creating a massive wall of text that will cause a reader's eyes to unfocus and drift off. As noted above, image placement can help with that, but a lot of the time it's simply up to the editor to know when to break or tighten things up.
When describing the action in a piece of fiction, you don't have to describe every little thing that happens in exquisite detail. We're not trying to be the novelization (especially when describing novels!), the goal is to summarize, not transcribe. Hit the major beats, be they of action or emotion, giving the reader enough to get a clear idea of what's going on (and why).
The same general principle applies to writing about non-fiction subjects. While these often to require a greater level of detail, learn to recognize that gray, fuzzy border of "too much". While it's helpful to cite multiple examples of a wider phenomenon, you don't need to go into every known instance.
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.
- 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.)
- 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 sometimes break up a character page's overlong fiction section with a relevant quote about/from them from said fiction, using the {{quote}} (left-justified) or {{bigquote}} (centered) template. | ” |
| {{#if:TFWIKI.net, "editing layout guide" page| —TFWIKI.net, "editing layout guide" page{{#if:|, {{{3}}}}} }}}} | ||
| “ | 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. | ” |
| {{#if:TFWIKI.net, "editing layout guide" page| —TFWIKI.net, "editing layout guide" page{{#if:|, {{{3}}}}} }}}} | ||
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!
[edit]It is also possible to have paragraphs that are too short. This doesn't mean you should stretch the wordcount like you're trying to reach a high school essay's page requirement, just that it can help to know when to elaborate a little.
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."
- ...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:
- "Then he was in the crowd when Bad Thing Happened. That Time He Was In A Crowd"
- "He was also present watching Someone Else do the cool thing. Someone Else Does A Cool Thing"
- "Then he was present for shoot me"
Collists and Tables
[edit]
As noted on our policies page, we hate lists. One of the reasons we hate them is they often result in vast swathes of empty, wasted space (as seen at right), which just looks amateurish and can be a real chore to read, forcing readers to scroll scroll scroll to find information. But sadly, lists are still often the best/only viable way to present, well, lists of information. As such we've taken steps to present these lists in a more compressed, easy-to-follow format that sorts the information into columns that can spread across the entire page (or, at least, most of it), reducing the amount of empty space and scrolling.
There are several different methods of arranging "list" information in a more screen-filling manner, though many are specific to certain types of page, such as the "Featuredcharacters" template that is used on most media installment pages. But there are two methods that are a bit more universal, and can be used in multiple types of page. One is simple to use as the template does most of the work, but is really only for simple lists and has a few quirks. The other is much more robust and gives the editor a lot more control over content and spacing, but can be quite intimidating to new editors.
Collist template
[edit]The Collist template is the easy one. This takes a bullet-point list and automatically splits it up into the specified number of columns. This is best used for simple lists, such as the members of a subgroup (like the Wreckers).
The template is vey simple:
{{collist|5|
* Walking stick
* Lobster shell
(etc)
|}}
And the end result looks like this:
{{ #if: {{#ifexpr: 5 }}
|
|
- Walking stick
- Lobster shell
- Cellophane
- Acid bath
- Legal pad
- Nitrogen
- Avocado
- Sleeping bag
- Rope
- Money for dope
- Russian hat
- Safety glass
- Jumping beans
- Hand grenade
- Almanac
- Butcher block
- Finger cymbals
- Liquid soap
- Money for dope
}}
Bear in mind, this template does have a few quirks. If the number of items in the list does not cleanly divide into the number of columns, the template might choose to divide them into distinctly uneven columns. And as it stretches the information all the way across the page (stopping for images, of course), this can leave a lot of space between columns on wider displays, which isn't great but is in the "not much to be done" realm. Meanwhile, in smaller browsers (or if there's an image to the right taking more space), longer single entries may take a line-break that can also futz with how it sorts by column. It also doesn't let you make "headers" to better organize columns; that's what the custom table coding is for.
Custom tables
[edit]As "Collist" was unsuitable for use on toyline pages in particular, which can be quite complex thanks to subgroups and wave breakdowns and are incredibly important pages, we have developed a standard custom table coding that allows for much more involved and controlled arrangements, including adjustable column width, headers, custom bullet points, and more. While the toyline pages make the most use of this formatting, it can be applied to other pages if needed, with minor adjustment.
In general, these tables should have five columns in total: the first four for text, and the fifth (rightmost) reserved for supplementary/example images. The template is adjustable to have any number of columns, but it is a rare circumstance where you will need either fewer or more. (More columns also causes problems on smaller browsers, especially mobile browsers; sadly, making the wiki "mobile friendly" is... well, "daunting" is the polite word for it, and we're more or less relegated to just minimizing the mess there.) The overwhelming majority of pages use the five-column layout, and keeping visual consistency is preferred, especially if you're using multiple tables on a single page.
The core of the table coding looks like this:
{| style="margin-left:1em;" width="100%"
|width="20%" valign="top"|<u>'''Group 1'''</u>
* Item 1
* Item 2
|
|width="20%" valign="top"|<u>'''Group 2'''</u>
* Item 3
* Item 4
|
|width="20%" valign="top"|<u>'''Group 3'''</u>
* Item 5
|
|width="20%" valign="top"|<u>'''Group 4'''</u>
* Item 6
* Item 7
|
|width="20%" valign="top" rowspan=2|[[File:exampleimage.jpeg|right|thumb|upright=1|]]
|-
|width="20%" valign="top"|<u>'''Group 5'''</u>
* Item 8
* Item 9
|}
Which produces:
Group 1
|
Group 2
|
Group 3
|
Group 4
|
| ||||
Group 5
|
This is the standard table layout, and should rarely be altered. The first "line" (everything above the |-, which marks the start of a new row) needs to have five columns to set the proper spacing. If your table does not have enough content for five columns, you can use |width="20%" valign="top"|<br> without content under it to create an empty column if needed to maintain spacing. Subsequent rows do not need to have the full five columns in the code if there's just not enough info there and it's the bottom row, as the example shows... but putting more columns than the top row has, or lacking the "blanks" in a middle row, can cause layout wonkiness.
The "rowspan" in the image column means that any images placed there will ignore the |- mark for layouts and continue down into the next row if they exceed their row's height, rather than leaving blank space. Depending on how large your table is, you may want to place multiple images into that one section to maintain a solid "line" of images, but be aware the table will put blank space between the rows if the image column end up taller than the text columns in total, so don't go nuts. You should rarely need more than two example images per table anyway, and again, it's best to try and use more horizontal images if possible.
Sometimes, you may need to spread a "group" across multiple columns to keep one entry from being much longer than the others in the row, leading to the dreaded unbalanced empty space. Luckily, this is very simple to do, and works on the same principle as a blank column:
|width="20%" valign="top"|<u>'''Group'''</u>
* [[Item]]
* [[Item]]
|
|width="20%" valign="top"|<br>
* [[Item]]
* [[Item]]
(((((show image of split entry... BotBots squad listing most likely)))))