User:RAP/1

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

1

 * 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.
 * While not started up an actual project, one page is set up as an example; they are: Wheel of Fortune (general)

1

 * 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.
 * Inspired from checking out this page, and thus created User:RAP/PNG

2

 * 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.
 * First implemented in Object file images from Acno ' s Energizer Objects page. Sample image file of the character Acno from the game.

1

 * 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.
 * Inspired from Chip ' s Challenge ' s Levels 1-20 page, and Battlestatons: Pacific's Walkthrough pages
 * First implemented in Boulder Dash ' s Objects page

2

 * 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.
 * First implemented in Boulder Dash ' s Objects page (1), and Chip ' s Challenge ' s Levels 1-20 page (2)

3

 * 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:  (example) . After typing the code, it will appear as this: (example)
 * Inspired from MarioWiki's Conjecture policy
 * First implemented in Acno's Energizer ' s Objects page

4

 * Selectively use 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.


 * First implemented in Emerald Mine ' s Level 0-20 walkthrough section, and Acno's Energizer ' s Level editor page

Minor

 * MINOR THINGS –
 * Make the tables position center (2013 July 20)
 * Reduce as much empty space as possible (2013 July 20)
 * Make the text size smaller on tables with a lot of info (2013 July 29) {first implemented in Game Dev Story ' s Combinations walkthrough section}
 * Add a caption pertaining to the image from the article page (2013 August 13) {first implemented in Emerald Mine ' s Level 0-20 walkthrough section}
 * 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 section, 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 section}
 * 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.

1

 * 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

 * 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

 * 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 ' s Obstacles section, and Boulder Dash ' s Objects page

1

 * 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.
 * Inspired from Super Bomberman ' s passwords page
 * First implemented in Chip ' s Challenge passwords page

2

 * Make the passwords or codes look nice in a new font type (2013 July 20) – this is done so by adding   in-between, an example resulting from "1N09aaW" to "1N09aaW"; I'm not sure why it renders like that, but it beats stuffing "  " repeatedly. UPDATE (2013 JULY 21) : It seems that  does the same thing as well. Changed it to   because it's has less characters. Change before and after my edit. I wonder if there are more of these things...
 * Inspired probably from Contra III: The Alien Wars ' Codes and passwords page
 * First implemented in Chip ' s Challenge passwords page

3

 * 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.
 * Inspired from Chip ' s Challenge passwords page
 * First implemented in The Guardian Legend ' s Passwords page, and Spider-Man 2: The Sinister Six ' s Passwords page.