From StrategyWiki, the video game walkthrough and strategy guide wiki
Jump to navigation Jump to search
Ideas, ideals, and mindsets worth implementing
for the wiki to improve content quality and presentation
(It's more like a reminder of ideas I like from browsing the StrategyWiki pages or stuff I came up my own;
some of them are my opinions that I wanted guides to be like,
some of them are something that should be enforced in StrategyWiki.)
Table of Contents
[edit]
[OTHER] General Specific
Projects Files Presentation Writing Codes and Passwords

[OTHER][edit]

Projects[edit]

1[edit]

  • Pre-setup content with skeleton structures (2013 August 27) – this is so it will encourage future writers to fill in actual content after the pre-planners created the structure setup and implemented it, hence StrategyWiki's mindset of multiple writers working on the same game guide.
    While it requires the pre-planner to know the ins and outs of the game content for the game guide, laying down the structure signifies what the guide precisely asks what content needs to be filled and completed so that writers can finish the guide more easily.

GENERAL[edit]

Files[edit]

1[edit]

  • Compress PNG image files to the max (2009-2010) – since PNGs are lossless, compressing them will not lose any image quality; not only the compressed PNGs will retain the image quality, it will load faster! Good for lowering bandwidth usage from the servers' end and users' end.

2[edit]

  • Insert a link to relevant info pertaining to the image (2013 July 30) – it's similar to the "Create custom table of content tables" entry in the Presentation subsection of the General section. This is a somewhat minor thing that focuses on having substance in the image file page instead of leaving it blank or have no links in the description, aside from the links in the File Usage section.
It aims at three things, it's for someone who:
  1. ...is remotely curious about that particular image
  2. ...is browsing through a random pile of image files through Special:NewFiles, Category:Guide-specific images, or Special:Randompage/Image
  3. ...wants instant access to relevant info pertaining to the image.
It's just another minor thing that helps the overall experience of making the info feel complete.

Presentation[edit]

1[edit]

  • Italicize the names of the items, objects, moves, enemies, places, levels, etc., anything that is interacted or notable; regardless if the name is official or unofficial (2013 July 20) [not explained fully] – I cannot fully explain why I did this...having the context stand out from the rest of the text makes the reading have meaning. I could just underline the text instead of italicize, or have both to differentiate more, or maybe have bold mixed within.

2[edit]

  • Create custom table of content tables (2013 July 29) – this is so that it allows quicker access to the info users need; no tedious scrolling, pressing the Up and Down arrow keys, or Page Up and Page Down button, even using the "Find" function! They cover two things:
  1. There are a ton of list tables that are full of content and it's tedious to find the exact info.
  2. Table of content tables with a low amount of subsections in the page are bearable, but when it gets too long; it's necessary to discard the normal content table and implement a custom version.
How come it's better to click a link instead of using the "Find" function in an internet browser?
  1. Open up the Boulder Dash's Objects page.
  2. Start searching the term "Magic Wall"; typing it already slows down access, even if it is just typed partially.
  3. After typing what to search: There are 5 results, with more slowdown after repeatedly going to the next result until reaching to the info the user needs, wasting precious seconds to the end user.
Clicking the "Magic Wall" link instead of using the "Find" function instantaneously scrolls to the desired info the user needs. This usually applies when there's more than one repeating term, even then, those who prefer a mouse (or tapping the touch screen) over the keyboard (or virtual keyboard), it's worth the frictionless access.

3[edit]

  • Add a underline caption that says "Unofficial name." to conjectural names that that do not originate from the game text, manual text, company message, or anything that has to do with the game (2013 July 30) – this is so that it can inform the user that the name is unofficial or conjectural. If a game doesn't explicitly say or mention the official name of anything, a conjectural name takes place to best describe what it is about. A somewhat minor thing that benefits halting false info, and people who are into a game who wants info on official names and differentiate from unofficial names. It is also for those who want to hunt down the actual name.
It is added by typing this: <span class=explain title="Unofficial name.">(example)</span>.
After typing the code, it will appear as this: (example)

4[edit]

  • Selectively use <br> in the content writing (2013 August 21) – this is so that a particular sentence can be read more neatly in the article. Another somewhat minor thing in to the list, but it makes so much difference not only presentation wise, but also writing-wise so that the writing doesn't specifically focus on making sure it reads and displays properly under the limit of the width. It's the difference between these two examples for comparison, with color utilized to further drive the point:
(before)
The "Save" Button leads to section where the details can be filled out before being uploaded: the player name has a limit of 10 letter characters, while the level name has a limit of 13 letter characters. Pressing Esc will go back to the previous screen.
and
(after)
The "Save" Button leads to section where the details can be filled out before being uploaded:
the player name has a limit of 10 letter characters, while the level name has a limit of 13 letter characters.
Pressing Esc will go back to the previous screen.

5[edit]

Format content to fit under the varying limitations of page width size (2014 March 29) – this is so that it the content can be remained formal and readable in all the four available skins in the wiki. The most significant obstacle to how content is designed under those limitations is the width of the page: Monobook and Vector skins do not have fixed widths, while the Whale and Dolphin skin does have fixed widths.

If applied to existing pages that are not optimized, and future pages for all available skins:

  1. Shorten text while retaining the desired info. (2014 March 29)
  2. Decrease text size on tables with a lot of info. (2013 July 29)
  3. Implement a horizontal scrolling box onto tables that are too complex to be optimized. (2014 March 29)
  4. Shrink the image size in the page to make the spacing feel better. (2014 March 29)

This task may be daunting to make sure the content is uniform under all available skins; but it goes a long way to maintaining consistency.
Quick links to viewing content under a specific skin:

Dolphin (default) normal section page id page id with section
Monobook normal section page id page id with section
Vector normal section page id page id with section
Whale normal section page id page id with section

Quick access is key to making comparisons between the skins while editing!

  • Inspired from the new Dolphin skin implementation; resulting in using the Whale skin due to joining the wiki with that previous skin.
  • First implemented in:

6[edit]

  • Write an introduction sentence or paragraph consisting of the game name and info on the content (2014 March 29) – this is so that not only it reinforces what page is for what game, it also gives the user starting info on what the page will be about. It also makes the page feel complete by introducing the reader to the page properly regardless of any prior knowledge of the game. However, it not might be possible to cover all pages in the game page; in that case, the opening sentence or paragraph will just have the info without the game name.

7[edit]

Minor[edit]

  • MINOR THINGS –
    • Make the tables position center (2013 July 20)
    • Reduce as much empty space as possible (2013 July 20)
    • Add a caption pertaining to the image from the article page (2013 August 13)
      {first implemented in Emerald Mine's Level 0-20 walkthrough page}
    • Add the ability to switch the appearance of numbers from symbols [0] to words [zero] and back (2013 August 15)
      {inspired from implementing symbols and word numbers together manually in Emerald Mine's Level 0-20 walkthrough page, and from how Template:Control selector and Template:Control work on input controllers or keys}
    • Add jumplinks to the "Table of Contents" section to the top of the page before the introduction info to those that have a large custom Table of Contents section (2013 August 17)
      {first implemented in Emerald Mine's Scoring page}
This is about having small improvements that make a lot of difference to how the info is presented and read; these are usually self-explanatory.

Writing[edit]

1[edit]

  • Avoid writing anything having to do with "you", and use "players" sparingly as much as possible (2007) – this is because:
  1. Using "You" feels like the article or guide is focused on a single player as opposed to multiple players who will read the same content
  2. Even though this is a walkthrough website, personally, using "you" feels unprofessional.
While this is much more harder to do, the payoff is worth it because of gaining more experience from writing and improving language for the wiki.
  • Had this mindset from writing Mario Party series minigame articles on MarioWiki due to their "You"s policy

2[edit]

  • Avoid personalizing the writing [or have an informative tone] (2007) – it's similar to the " No 'you' " entry. Again, much harder, but the payoff is great on improving and practicing language.
    • Had this mindset on reading and writing content on MarioWiki; then again, it applies anywhere else most of the time

3[edit]

  • Use bulletpoints and tables to make info easier and faster to read (2013 July) – this is due to the amount of info people read everyday, especially online; cut the fat as much as possible and get to the point so that users can get the info easier and faster; it doesn't mean that everything should be done in that format though.
    • Inspired from reading a bunch of articles on the topic of bulletpoints and the average lifespan of how many books are read per user
    • First implemented in Temple Run page in the "Obstacles" section, and Boulder Dash's Objects page

SPECIFIC[edit]

Codes and Passwords[edit]

1[edit]

  • Add quick article links from the Passwords pages (2013 July 20) – this is so that users that need help can jump into the specific parts of the walkthrough pages if they are having trouble advancing through after entering a password.

2[edit]

  • Make the passwords or codes look nice in a new font type (2013 July 20) – this is done so by adding <tt> </tt> in-between, an example resulting from "1N09aaW" to "1N09aaW"; I'm not sure why it renders like that, but it beats stuffing "<font style="font-family:Courier New"> </font>" repeatedly.
    UPDATE (2013 JULY 21): It seems that <code> </code> does the same thing as well. Changed it to <tt> </tt> because it's has less characters. Change before and after my edit. I wonder if there are more of these things...

3[edit]

  • Entries should consist of the effect before the password or code (2013 July 21) – When reading from left to right, seeing the password or code first in the table doesn't tell any info unless one looks at the right and is informed of the effect by entering the password or code. Swap both of those places instead to make more easier to read. From an educated guess, the reason passwords or codes were placed before the effects is the old mentality of organization when it comes to editing plain text files. There weren't tables or wikis back then to make it look neat effortlessly.
Retrieved from "https://strategywiki.org/w/index.php?title=User:RAP/1&oldid=699969"