Please don't make changes to this user article. Please use the talk page to discuss suggestions, comments, or additional ideas. Talk page headings should use text (instead of ToC numbering) to refer to specific content, as numbering will change as this article is revised and updated.

The article itself is transient, and may be overwritten in whole by a later version maintained on another wiki. Last modified: 20071020030018

Objectives

The goal of the reorganization is to support newly-announced (and future unannounced) Viva Pinata content (e.g. games on various/multiple platforms, merchandise, TV episodes) in a well-organized manner to facilitate ease-of-use in navigating, presenting, and maintaining content.

Discussions at this talk page (or forum's 're-organizing content...' thread) exist to help identify and explore options that are being considered. The reorganization is still in the design stage, so many alternate options may be presented.

In order not to clutter up the namespaces with various examples, actual links (or content) pertaining to example categories, articles, or template names may be unresolved until a future public testing period.

Status of issues

• Unresolved - Issue hasn't been discussed.
• Pending - Issue requires further investigation, testing, and/or discussion.
• Declined - Issue won't be resolved in this manner.
• Accepted - Issue has been accepted and will become future policy.

Tasks to be completed

Other general tasks

• Site needs to be "cleaned up" with regard to things like missing captions for images.
• "Replacement" images should be uploaded with same name, or old (unused) images should be deleted.
  • Need to do spring cleaning among unused images, etc.
• Style guide needs an update.
• CSS needs a major overhaul:
  • Most code shouldn't be in Common, as it probably conflicts with other skins.
  • Media types should be added to support screen/print styles.
  • New naming convention should be applied alongside prior names, and old CSS names depreciated.

Reorg issues

Naming conventions

Colon in article names

Proposal: Avoid use of colon in article names

Status: Declined

Resolution: Using a colon in an article name is acceptable, if the colon is part of the game's name.

A colon in an article name generally serves as a delimiter for an optional preceding namespace name. If no such namespace exists, the entire article title is treated as a pagename, and placed in the main namespace. Two issues are at hand. First, without knowledge of whether custom namespaces are used or not, it's ambiguous by simply glancing at a title which namespace an article may belong to. Second, if such a custom namespace were used in the future, prior pages would remain in the main namespace, creating a point of confusion or disorder, and require maintenance to relocate or rename an unknown number of articles as needed, possibly breaking links.

An article named Viva Pinata: Party Animals would either have its discussion page at Talk:Viva Pinata: Party Animals (not too friendly looking) or Viva Pinata talk: Party Animals (has a leading space in PAGENAME).

Order of names

Status: Accepted

Resolution: Species -> Sours -> Platforms; List of Species in Viva Pinata for Xbox 360

• Species -> Sours -> Platforms (with Sours) versus Species -> Platforms -> Sours (for a platform)

There are pros and cons for both orders, and choosing one would make the "other" queries a bit more difficult to explore.

• List of Species for Viva Pinata on Xbox 360 versus List of Viva Pinata on Xbox 360 Species

Order and disambiguation Achievements (Party Animals)

For versus on

Status: Accepted

Resolution: Using "for" to match official name, i.e. Viva Pinata for Windows

This is a very trivial issue, but for consistency's sake, it might be nice if a list of bulleted items or such don't switch between "Viva Pinata for Platform X" and "Viva Pinata on Platform Y." Is there some sort of convention that should be followed?

Category names

Proposal: Determine naming scheme. (Should be decided now, even if decision to split is deferred.) Also, switch to separate names now during this reorg, rather than defer it.

Status: Accepted

Resolution: Split category names by game and platform. (E.g. Domestic Species in Viva Pinata for Xbox 360)

Currently, with one game and one platform, we have one set of categories for Category:Species, Category:Evolved, Category:Sour, Category:Tree and so forth. Setting aside that these existing names are arbitrary and may be renamed as part of the reorg, is the plan to group all species for any/every future game into single large categories, or differentiate them by game and platform? (Perhaps a new game or platform may have a new Sour or Evolved species, that may not exist in an existing game or platform.)

This would lead to longer category and article names, e.g.:

• Category:Viva Pinata on Xbox 360 Species
• List of Viva Pinata on Xbox 360 Species (Article)
• Viva Pinata on Xbox 360 Species (REDIRECT)

It would seem necessary to move to separate categories by game and platform at some point, to support more unannounced games, and make it easier to list or identify species or garden items that pertain to a specific game or platform. Not separating categories now may simplify some organization (i.e. we're accustomed to it being the way it is; it's short and "simple"). However, it would mean more reorg work later, with even more pages and articles to revise. Also, one objective was to try to address "future" needs so we don't have to go through this "again."

Another issue with not using separate categories is that a visitor can't distinguish between species that pertain to certain platforms and/or certain games. There's no natural support to flag a species name with a platform or game icon. One option, if single categories are kept, is to disambiguate new species' articles, such as Jeli (Viva Pinata on Nintendo DS). This would "work" for a category page, however, it would be a poor distinction (distraction) for a Template:Species list of horizontal names. (The only way you could clearly distinguish such lists of names, is to maintain/display separate lists.)

Split off categories and articles

Status: Accepted

Resolution: Split Category content off onto (new) article pages.

Deal with article being a part of category which is not typical to the wrong way we've done it. (Also affects sub-category article pages.)

Long category names

Status: Declined

Resolution: Clarity precludes shorter names; longer names are a necessary evil. (Distinction will be at start of category.)

Long category names make it more difficult to navigate through a list of categories in the article footer. For example, the Sherbat belongs to four categories. (Placing the distinction at the start of the category name would help slightly.

Article, Template, and other names

Status: Accepted

Resolution: Adopt naming convention for articles, templates, etc.

Based on category name concepts, we should have a similar naming policy for articles, templates, and other name uses such as CSS classes and IDs.

Much of this depends on other decisions, such as whether articles are disambiguated, and/or categories are split into subcategories by platform.

At some point, though, some policy should be adopted to standardize names, such as within the Template namespace. Also, as colored boxes get put to use more, or dynamic content gets hidden by classed divs, some reasonable convention for naming new CSS classes and IDs should be setup, that doesn't conflict with existing use.

Navigation

Nav bar

The nav bar will have to support additional franchise content, such as new games (on different platforms), and new merchandise. Even if jump pages are used to help guide people to various related topics of information, a certain amo

Search above the fold

Proposal: Increase visibility somehow.

Status: Accepted

Resolution: Determine better location for search box.

The search box should be one important aspect of helping visitors find information at the wiki. Moving it above the fold would make it more visible. If space is at a premium due to ads and other navigation, one option is to give the search box a more prominent (visible) spot above the content area itself. Top navigation could also free up additional space by moving various links from the left navigation bar to a top navigation bar.

Traditional wiki search box relocated above content area

Special:Search layout, with sample nav links

Another option (not illustrated) is to locate the top search box to the far right, directly under the personal toolbar, leaving the left area open for a horizontal banner ad. The current horizontal banner ad at the top of the article content area can then move up above the content area, which frees up the top of the content area for content-specific visual information. (I.e. "Applies to" information, tabs or filter lists which support dynamic content, colored boxes, etc.)

Site Map

Proposal: Update Site Map to include recent and new content. Arrange it in a similar way to non Site-Map navigation.

Status: Accepted

Resolution: Update Site Map to match new organization and navigation.

One of the last steps of the Reorg is to update the Site Map to "mirror" the Reorg. Visitors shouldn't have to deal with diverse organization between navigating the site, and using at the Site Map, so its structure will most likely match the (navigational) organization/layout of the Reorg.

Site Index

Proposal: Add a "comprehensive" Site Index to allow topical jumps.

Status: Accepted

Resolution: Add some solution to help visitors "discover" content.

Plans will be underway to add a topical index, to aid in helping visitors find information about a subject.

Presentation

Disambiguation of articles

Status: Pending

Resolution: Investigate if existing solutions eliminate the need to (completely) disambiguate due to platform distinctions.

Game or platform differences may make articles mostly different, somewhat different, slightly different, or possibly not different at all. These may be some examples of many possible degrees of article differences (speculation at this point since details aren't available):

• Mostly different:
  • Achievements (Viva Pinata, Viva Pinata Party Animals)
  • Ranks (Viva Pinata, Viva Pinata for Nintendo DS)

• Somewhat different:
  • Shops (Some shops/shopkeepers may not be present in some versions)

It's uncertain at this point which articles may be slightly different, or possibly not different at all.

Disambiguation of articles has its own share of maintenance headaches, as n copies drift out-of-date, or demand more complex mechanisms to such as transcluding or substituting "common" material. Some contributors may not be familiar with where or how to edit common material, reducing the number of revisions or additions the site receives.

A related issue with disambiguation is that features like the MiniFAQ, which traditionally exist on one article, may need their questions repeated, for disambiguous articles.

Traditionally, disambiguation pertains to a title with multiple topic meanings. In the strict sense, Achievements wouldn't be disambiguated. However, if some articles are disambiguated by platform and/or game, we should clearly decide how, and when disambiguation is used, as well as a proper naming system. (It's important to keep in mind that titles chosen today shouldn't conflict with next year's unannounced content.)

Some of the pros of disambiguation:

• Articles are "self-contained" (i.e. you don't have to read about content pertaining to unrelated platforms or games).
• Articles are shorter.

Some of the cons of disambiguation:

• Content is clearly duplicated. While it may not seem like a big issue to keep two articles "in sync," five years down the road, when there is much more content and articles, there is much more likelihood that inconsistencies and errors won't be corrected in every version.
• Disambiguation is more "confusing" when articles are categorized. As an extreme example, mixing disambiguous species names, e.g. Bunnycomb (VP1 Xbox 360), and non-disambiguous names is a bit cluttered to visually navigate.
• Searches turn up larger numbers of articles, forcing the visitor to look through more results to find the relevant article to read.
• Multiple Talk pages makes it difficult to centralize discussion about a subject.

"Applies to" at top of articles

Proposal: Use some sort of visual indication at the very top of the content. Decide if it's necessary to also explicitly list non-applicable platforms/games.

Status: Accepted

Resolution: Use some sort of visual indication at the very top of the content.

Since a visitor could reach any page at the wiki, through a wide variety of mechanisms (forum link, wiki search result, search engine result, third-party link from another site, etc.), it should be readily apparent what the page pertains to, or doesn't pertain to. This would be the biggest issue for games and platforms. The worst case would be for a visitor to read a long page, see no disclaimer that it doesn't apply to platform X, then be confused when they try to figure out how why they can't access said feature on that platform. (In a related vein, if platform-specific information is in headings at the bottom of an already-long article, it's not helpful if the person has to read down to the plaform-specific content, to see that it isn't applicable.

Example of "Applies to" message

Long article length, and ToC

Proposal: Add support for ToC while "maintaining" presentation style

Status: Accepted

Resolution: Explore species/garden item layouts which will support the ToC.

Although an article Table of Contents (ToC) is used in some articles, there are specific articles where the ToC has purposely been suppressed. (I.e. Category:Species, Category:Tree, and so forth.) If (as) these articles possibly get longer, such as due to platform-specific differences, adding a ToC will facilitate a quicker recognition (and navigation) of the topics at hand. Adding the ToC may involve redesigning (or breaking up) an article's visual presentation style, to support displaying a ToC.

Side-by-side presentations

Proposal: Avoid side-by-side presentations where possible.

Status: Accepted

Resolution: Stack content vertically.

Side-by-side presentations may serve well with a small, fixed number of comparisons (e.g. 2 or 3), but don't grow well, when the number of comparisons increase. As the number of games and platforms increase over the years, it becomes more difficult to fit additional information (e.g. more sets of table columns) into a limited horizontal space. Since one objective is to support future unannounced franchise content, side-by-side presentations should most likely be avoided.

In lieu of side-by-side presentation, platform-specific content should either be stacked vertically, or dynamically displayed in place of other platform content.

Inline vs stacked information

Proposal:

Status: Pending

Resolution: Setup sample presentation of various options for different content such as tips or button press information.

Wiki content has traditionally provided tips or details (e.g. button press information) right within the body of the content, as the topic was being presented.

With additional platforms and games being released, all sorts of changes will exist, within tables, within lists, within Infoboxes, or within (color-coded) message boxes.

As the number of games and platforms increase, keeping this divergent information inline makes the article more difficult to visually read and navigate, due to the diverse "interruptions" to present a detail for platform X.

On the other hand, moving the information to "below" the main content, where it's displayed in platform-specific headings, makes it difficult in a different way, to easily get answers to what used to be readily available within the main content.

Dynamic content

Proposal: Determine if dynamic content can support current and future needs/aspects of reorg.

Status: Accepted

Resolution: Explore proposed solutions to decide if dynamic content will meet all needs.

Note: Dynamic filtering - n pics, where n increases.

Dynamic content (e.g. filtering information, displaying/hiding information in-place) seems to address many of the concerns of other methods. Separate articles aren't needed, avoiding multiple copy issues, transcluding, substitution, and knowing which common article to edit. Side-by-side presentations aren't needed since specific content can be displayed in place of other platform content by hiding (i.e. not rendering) unrelated content. Article length is reduced. Specific details (e.g. button-press, prices) are kept inline to the main content. Finally, content is contained in a single article, which maintains the existing simple, consistent approach for contributors to edit articles.

An example of an edited article, with multiple platform content, may look like:

...

<div class="Dynamic_VP1_360">{{Species2Infobox
| title = Bunnycomb
| image = "vp1_360_bunnycomb.jpg"
| value = 600 coins
...
}}
</div><div class="Dynamic_VP1_DS">{{Species2Infobox
| title = Bunnycomb
| image = "vp1_ds_bunnycomb.jpg"
| value = 1200 coins
...
}}

...

<div class="Dynamic_VP1_360"><div class="LittleBox_Buttonpress_360">To get the Bunnycomb to fetch a carrot,
  press the A button.</div></div>
<div class="Dynamic_VP1_DS"><div class="LittleBox_Buttonpress_DS">To get the Bunnycomb to fetch a carrot,
  double-tap the Bunnycomb with the stylus, and select "Fetch" from the menu.</div></div>
<div class="Dynamic_VP1_Windows"><div class="LittleBox_Buttonpress_Windows">No key to press.
  Bunnycombs only fetch carrots on the 360 or DS version.</div></div>

Despite the fiction of the example, it does illustrate the possibility of using a single article to display varying content, whether the platform differences be graphical, keypress, Infobox value, or other possibilities.

Using a single dynamic article can help avoid disambiguation (and platform-specific articles drifting out of sync), keep displayed article length short (by hiding unrelated platform content), and maintain a familiar approach to editing.

Dynamic content filtered by text links

Dynamic content displayed using tabs

It probably won't be possible to easily use tabs in the content area. It's included here, though, as an illustrated example, since it's a familiar concept for organizing content.

The strength of dynamic content would lie in being able to edit a single article, that contains differences for each platform. For example, using a CSS approach to hide DIV blocks for unrelated platform information makes it possible for most contributors to continue to edit a single article, in the same familiar and consistent way as before the reorg.

Issues with dynamic content

1. No suitable extension exists, and one would have to be custom-written.
2. Changing background color of content area to simulate filtering may be challenging.
3. A suitable fallback mechanism must exist to display all information, if a client's browser doesn't support recent standards.
4. Content that applies to two platforms but not other platforms, would probably need to be repeated twice, in a CSS show/hide approach, as OR mechanisms probably won't exist.
5. At some point, articles may become so "disambiguous" between current and radically different future releases of a game (e.g. VP1 and VP4), that content gets reorganized (e.g. disambiguated). Still dynamic content would avoid splitting an article longer than other methods, deferring any possible future reorg.

Todo: Determine if hiding spans for table rows works

Color, and colored boxes

Proposal: Determine how best to use color, to help present distinct sets of information (e.g. platform)

Status: Pending

Resolution: Determine if/how color will be used in conjunction with proposed solutions.

First, are colored boxes based on 1) games regardless of platform (e.g Viva Pinata), 2) on platforms regardless of game (e.g. Nintendo DS), or 3) on an individual color per game per platform basis (e.g. Viva Pinata on Xbox 360, Viva Pinata on Windows, Viva Pinata on Nintendo DS)?

1) Distinguishing boxes per game would be the least-used aspect, if used at all, so that could probably be set aside.

2) Distinguishing boxes by platform would seem to "break down" if more future games are released. Imagine a Species article that presents Viva Pinata and Viva Pinata 2 differences, for both the Xbox and Windows. You'd have 2 sets of identical Xbox-colored boxes, and 2 sets of identical Windows-colored boxes, making it less easy to identify Viva Pinata versus Viva Pinata 2 differences.

3) Distinguishing boxes by game per platform leads to the most flexibility, and most combination of boxes. A possible color scheme would might be to use shades of a color per platform (e.g. Xbox games are certain shades of green, DS games are certain shades of orange). This would allow platform differences to stand out between the Xbox and DS, for example, yet also distinguish between older and newer games on the same platform. The only shortcoming would be that the increased need for colors may lead to gradually exhausting viable shades of a platform color, as more games are announced. (Assuming colors based on the 216 web safe colors, using orange as an example, perhaps only 6 shades of orange could be displayed.)

Still color serves as a helpful way to distinguish different sets of information, and should be used in some manner.

Color backgrounds

Status: Accepted

Resolution: Establish convention/policy for color backgrounds

Certain articles have used background colors for article content, e.g. Species pages are blue/purple with green Infoboxes, Garden item pages are green with blue Infoboxes.

Once other colored boxes are introduced on a non-white background, use of background colors may clash with colored boxes. Also, it's uncertain what the scope of a colored box is. In one case, it could be a one-sentence button-press explanation. In another case, it could be an entire filtered page or large heading section. Once the colored box takes up a large region, it's "background" color visually supersedes (overrides) the content background color. In short, colored boxes work well as little colored boxes, but fail as big colored boxes, especially if the site is inconsistent with use of color or boxes in (old) articles.