FANDOM


This Forum has been archived

Visit Discussions
Forums: Index > Wiki Discussion > Project Flemeth: Shapeshifting the Wikia's Look
Note: This topic has been unedited for 2751 days. It is considered archived - the discussion is over. Do not continue it unless it really needs a response.

I started a new Dragon Age Wiki:Project Flemeth that encompasses the thematic changes that comes with the new Wikia skin. If you have artistic skills, have opinions, or just want to help out; I encourage you to read the Project and contribute any way you can. It could be as easy as finding pages and marking it with {{Adjust}} or making images, or suggestions. Cheers! -- tierrie talk contr 20:35, October 7, 2010 (UTC)


Wikia's new look is a major change to the way the Wikia is presented. Some of the templates like the Template:InfoBoxes now take up more space than they are worth. Other pages are compressed to the point where it no longer looks acceptable. The table of content and the front page of this Wikia also needs to be revised to allow the user the easiest navigation to the content.

Therefore, the purpose of this project is twofold:

  1. To revise the front page of this Wikia by improving the aesthetics and allowing a user easiest access to information
  2. Updating templates and pages to accommodate the fixed-width nature of the new Wikia


This project is in its first phase - identifying problem pages, soliciting feedback and brainstorming for design ideas.


Identifying "problem" pages

Changes to the skin should not affect the proper display of most pages. Some pages, however, will display incorrectly in the new skin. Initially, we will just identify these "problem" pages. If/when the switch to the new skin is imminent, the goal will switch to actually making the required changes.

Width

One of the largest changes in the new skin is the introduction of a 'fixed-width' content area. Pages will no longer stretch to fill the width of a screen. Instead, the width of all content on the wiki (Excepting the main page) will be restricted to 660 pixels in width. (See: Transition guide at the community wikia.) As much of our content was designed for a much larger viewing width, some templates, tables, and articles will not fit into a 660pixel wide area. Any pages that don't currently fit this size will need to be changed.

Category

If you see a page that looks like it won't display correctly in the new skin, please add {{Adjust}} to the page, and if needed, start a discussion for what changes will be required either on this project page or the article's talk page. Use discretion: if the required change is obvious (and uncontroversial), there's no need to start a discussion. However, if there is any doubt that the change would be accepted by all, err on the side of caution and start a discussion.

Layout Changes

InfoBox

Almost all our pages utilize InfoBoxes which took up a nice chunk of horizontal space in the old format. In this new one, that chunk represents nearly 30 to 40% of the 660px width available to our wiki. So, in order to maintain some semblance of sanity, the InfoBox needs to be moved, reworked, retooled or otherwise molded into a form that is acceptable to the new Wiki.

Main Page

Discussion at #Main page discussion. Part of the redesign would revolve around a new main page. To that effect I have mocked up a series of main pages that would be the first step towards redesign. I am looking to push this one through as quickly as possible with the understanding that we can always revisit it later.

Mockups can be found at #Style: Mainpage.

Thematic Changes

Background

Discussion at #Background discussion The splatter background has served us very well in the past but in the process of overhaul it would be nice to see if there are any other options or suggestions for background that might be an improvement over this one. If you have a mockup or a suggestion please contribute to the discussion.

Navigation

Discussion at: #Navigation discussion The navigation sidebar will be removed. In its place, there will be 4 links alongside the wiki's logo, each with 7 sub-links. As we have more than 32 links in our current navigation, we will have to reorganize our navigational links to accommodate this new style. The finalized (i.e. agreed upon) navigation will be included here.

Wordmark

Discussion at: Forum:Wordmark We need to update the Wiki's logo with what is called a word mark. Currently the Wiki's logo is this, and we're taking new suggestions for the logo. Mass Effect's wiki has some examples of gorgeous works and its a great starting off point for suggestions. Time to break out that artistic skills!

Favicon

See Forum:Project Flemeth: Favicons#Favicon suggestions for favicon suggestions.


Community Corner

Take a look at Naruto wiki's code regarding the Community-corner. See if we can integrate it into this wiki.

Discussions

Main page discussion

See Forum:Project Flemeth: Main page redesign#Main page discussion for main page design discussions.


Background discussion

Navigation discussion

The rules for the navbar is as follows

  1. 4 main categories
  2. No subtrees
  3. Should cover as many of our main sections as possible

Style 1

Here's my first suggestion

  • Dragon Age (to the Portal, not to the skimpy article)
    • Codex
    • Companions (or Characters?)
    • Classes (or Skills?)
    • Creatures
    • Downloadable Content
    • Equipment
    • Gifts
    • Location
  • Dragon Age 2
    • (to be filled out closer to the game release)
  • Guides
    • Achievements
    • Gifts
    • Romance
    • Quests
    • Walkthrough
  • Community
    • Forum
    • News (or Recent Blog Posts)
    • Manual of Style
    • Rules and Policies (or Community Guidelines)


Style 2

While I like #Style 1, it wastes an entire section for DA2 which isn't coming out for a while. Instead, I suggest we use this for a few more months until DA2 part of the wiki is fleshed out.

  • Dragon Age Series
    • Dragon Age: Origins
    • Dragon Age 2
    • Downloadable Content
    • Dragon Age: Origins - Awakening|Origins - Awakening
    • Dragon Age Journeys|Journeys
    • Dragon Age: The Stolen Throne|Novel - The Stolen Throne
    • Dragon Age: The Calling|Novel - The Calling
    • Dragon Age (comic)|Comic
    • Dragon Age (pen and paper RPG)|Pen and Paper RPG
  • Gameplay (for adjectives/verbs)
    • Achievements
    • Approval (or Gifts?)
    • Attributes
    • Romance
    • Quests
    • Skills
    • Spells and Talents
    • Walkthrough
  • World (for objects/nouns)
    • Codex
    • Companions (or Characters?)
    • Classes (or Skills?)
    • Creatures
    • Equipment
    • Gifts
    • Location
  • Community
    • Forum
    • News (or Recent Blog Posts)
    • Manual of Style
    • Rules and Policies (or Community Guidelines)


-- tierrie talk contr 23:34, October 7, 2010 (UTC)


Given that Bioware will soon be releasing an "ultimate edition" of Origins with all the DLC's included, I can see foresee a horde of new players descending on the wiki without a clue that they need to look under "Downloadable Content" to find information on Return to Ostagar or Witch Hunt. Perhaps we should start calling that section "Add-Ons" just as Bioware is now doing, or perhaps even more appropriately, "Dragon Age: Origins - Add-Ons". So then you could place Origins, Origins - Awakening and Origins - Add-Ons one right after the other in order. Dragon Age II could then follow until eventually enough material is released that it merits its own separate section.

I still need to give some thought on the top level sections. I do agree we have too many currently, but I'm not sure we need to drop all the way down to four. -Vim- (talk) 18:43, October 14, 2010 (UTC)

I'm going to ask a stupid question, but are you using Wikia's new skin? You can change it through your preferences. Adding a fifth menu breaks Wikia's ToU. --D. (talk · contr) 18:59, October 14, 2010 (UTC)
Working on what D-day said -- the new Wikia skin restricts the ToC to 4. Anything past that will not be shown. So, my plan is to rework the ToC so that it features 4 categories. -- tierrie talk contr 19:38, October 14, 2010 (UTC)
No I haven't been. Tonguesmiley So it wasn't a stupid question at all. Ok, I just switched over. I do see what you both mean by the restriction to the ToC. My first impression of the new skin is very mixed however. On the one hand the look is for the most part sharper, cleaner. On the other hand it seems oversimplified to the point where more clicks are needed to get to the same pages. I'm seriously missing all the options that used to exist on the sidebar to the left. I also am not sure I like the fact that it has a fixed width and doesn't seem to take advantage of wider windows. So I'm not sure I like the new interface at this point. It seems dumbed-down to me. That's just a first impression however, and may perhaps change as I get to know this skin better. -Vim- (talk) 20:11, October 14, 2010 (UTC)
Since the new skin is non optional, I just went with it. Wikia is going to phase out Monaco and in a few months (or weeks?) this and Monobook will be the only skins left. Correct me if I'm wrong D-day.
That skin is reason for this project. -- tierrie talk contr 20:17, October 14, 2010 (UTC)
It's actually very soon. The new skin becomes default for everyone on October 20th. Monaco gets canned on November 3rd. I don't think they plan to implement Vector, unless it becomes the default skin from the MediaWiki software, so the only other skin is Monobook. There are pros and cons regarding the new skin, but overall, I don't really like it. The fixed width is a problem when using tables and infoboxes, which is an issue brought on popular wikis. At least, there are no ads in the article to screw up the layout (and I hope Wikia keeps it that way).
The skin has gone through some changes, but I haven't noticed big differences from their earlier releases. They are most likely waiting to see how user's behavior when it becomes default. There are still bugs waiting to be fixed. --D. (talk · contr) 21:04, October 14, 2010 (UTC)

After giving in some thoughts, style 2 is what I would also suggest. The other problem with style 1 is if BioWare decides to make DA3 or something, and if, by then, Wikia has not changed the skin again for more menus or something. Moreover, I suppose we will not be making different articles for all creatures or characters, e.g. Darkspawn will have a section for Origins and DA2, rather than having a new page for the DA2 version. --D. (talk · contr) 02:50, October 21, 2010 (UTC)

Err, I forgot to add that... what I meant is that it might be redundant to have "creatures" more than once, as well as "location". It would seem more organized to have all the lore and such in one menu. --D. (talk · contr) 02:54, October 21, 2010 (UTC)

Some remarks. While I'm not a prolific wiki author, I've used gaming wikis for quite some time. One of the most important functions a gaming wiki has to its users is a reference manual. So a user - especially a frequent one - comes here with a specific question and looks for a definitive answer. This user needs an obvious and easy to understand way to arrive at his destination page with very few clicks - may two or three. The old navigation menu prided such a way (though it had a few glaring holes).

One example on how to solve this - especially in the context of multiple games - is provided by the Elder Scrolls wiki (uesp.net) - one of the largest non-wikia mediawiki sites on the net. They have a site portal, but also a game pportal for every game. (they also have very useful navigation sidebars, but the **P+PÜ*O at Wikia consider those unecessary, so we don't have that option). The particular game portal thenm has only a well structured list of links. For the Oblivion version have a look at the Oblivion page on the UESP Wiki.

We should have something like that for Dragon Age, too. The top menu doesn't cut it. Too small, not game specific.

Oh, and we should get rid of the huge Image on top. It does not serve any useful function, and generally just gets in the way. And, talking of getting rid of something - is it possible to ban those boxes on the right hand from the front page, too? Wefa (talk) 17:42, October 24, 2010 (UTC)

Tierrie is working on making portals on the main page; see Forum:Project Flemeth: What should go on the main page?. You may also view Forum:Project Flemeth: Main page redesign for a design overhaul of the main page.
If the huge image is the Wikia header you are talking about, it's against the ToU to remove it, so it has to stay. We cannot resize it either. I'm not sure which boxes on the right from the front page you are talking about, but if you're talking about the sidebar with the recent activity and the gallery, this also cannot be removed. --D. (talk · contr) 19:02, October 24, 2010 (UTC)

Favicon discussion

See Forum:Project Flemeth: Favicons#Favicon discussion for discussion about favicons.


General Discussion

You (or any admin) should edit the Community Corner and probably make a blog post regarding the upcoming changes. The site notice got canned with the new skin (because of the SEO, and because it's too big... Wikia's reasonings). --D. (talk · contr) 20:51, October 8, 2010 (UTC)
Is Community Corner even used in the new Wikia? -- tierrie talk contr 22:52, October 8, 2010 (UTC)
Yes, it's still in the Wiki Activity. Whether people are going to see it is another issue (I never use MyHome). --D. (talk · contr) 22:58, October 8, 2010 (UTC)
I just learned that they've added a feature regarding the Community Corner. "Users who are active on the wiki up to 24 hours after the community corner is changed will receive a notification about the change, similar to the notification for user talk page messages. These will disappear after 24 hours if not previously dismissed by the individual users." --D. (talk · contr) 15:55, October 9, 2010 (UTC)
I just looked through MediaWiki:Community-corner and it looks like its supposed to be news. I don't see any news in my Wiki Activity section. Is that right? -- tierrie talk contr 21:09, October 11, 2010 (UTC)
The blog posts/news were added by Loleil, they're not here by default (they also overflow). The section "Thanks for visiting" is what you want to edit, or you can make another section specifically regarding the announcement. I think we all get a little sticky note (you probably got it before), but I don't know if the message on the sticky note can be changed. I haven't seen it being widely used yet (I only know of Canaanpedia, and that's because of this forum post). Blog posts seem to be more used, and would probably attract more users (since the Community-corner sticky note only shows up for 24h, which is too short). --D. (talk · contr) 21:31, October 11, 2010 (UTC)
What I meant was that I don't see it in the wiki. I assume its supposed to render on the right side of the screen, but it does not. On what pages do the corner appear to you? Maybe something's broken on my end. -- tierrie talk contr 04:37, October 12, 2010 (UTC)
Yes, it's right under the "hot spots". Have you tried looking with another browser? --D. (talk · contr) 06:00, October 12, 2010 (UTC)
I typically use Firefox with IETabs. I should clarify: I see the community corner in monaco, but I do not see it on wikia. My question was whether it is used in wikia skins. -- tierrie talk contr 20:45, October 12, 2010 (UTC)
Yes, it appears on the new skin. Have you looked with another browser, or on another wiki (logged in and as an anon)? --D. (talk · contr) 21:00, October 12, 2010 (UTC)
Looks like it does appear on Special:WikiActivity. I usually use Special:RecentChanges instead as it presents me with everything in a statistical manner. That might explain my confusion. Does it community corner appear on any other pages? -- tierrie talk contr 21:19, October 12, 2010 (UTC)
Afaik, no. --D. (talk · contr) 02:42, October 13, 2010 (UTC)

This isn't exactly within the project, but perhaps it's time for a new favicon? --D. (talk · contr) 02:42, October 13, 2010 (UTC)

Haha, put it in the scope of work! :) -- tierrie talk contr (talk) 04:34, October 13, 2010 (UTC)

One thing I don't like is the width restriction. It also stops what appears on the left side on the monaco theme. The drop down menu's don't have the sub categories and there is no recent updates window whatsoever. --Tsavi (talk) 22:46, October 20, 2010 (UTC) Hey Tsavi! It sounds like your question is "Why are you restricting the width of the wiki to X pixels?". The restriction isn't my idea - it is Wikia's. The idea isn't going over very well with the other wikis - Halo decided to leave Wikia over the new skin.

Personally, I am not a big fan, but I don't see it as the end of the world. Instead, I see it as an opportunity to redo the front page. My goals are twofold - the first goal is so that we can get a fresh face for DA2. The second is so that we can lessen the visual impact of the width restriction placed by Wikia.

Any visual changes that you have seen so far is a result of Wikia removing the previous default (Monaco.css) skin and moving to the new Wikia (oasis.css) skin. It ain't mah fault! :)

These changes are not optional. There are some campaigns to ask Wikia to revert the changes but it looks like oasis is here to stay. However, here at Dragon Age Wiki we could use some feedback at the forums. Our goal is try to make the best of this "brave new world" that we are forced to use. -- tierrie talk contr 00:10, October 21, 2010 (UTC)

Hmm with the info that Wikia is being stupid (probably some exec who wants to browse a wiki with little data unlike here on a blackberry), I guess the choices are limited. Though if the drop down menu is expandable to include all the sub categories monaco allows then it isn't that bad per se. The width restriction can be brought into better use with stricter font sizes and defined column widths. The news box is too big but that would be defining a set width for it. Those are my ideas as per your response on my talk page. --Tsavi (talk) 00:41, October 21, 2010 (UTC)

The drop down menu is not expandable. Wikia gives us 4 main subjects and each of them can contain up to 7 (or 8) submenus so this is one of the tougher conversions. We have some ongoing discussion on that subject. -- tierrie talk contr 00:52, October 21, 2010 (UTC)

If that is the case it might be better to look for a new wiki site. Making navigation harder wasn't one of the goals Wikia stated on there community pages but it seems that's whats happening. If their web designers were any good they would also see the problem the box for latest activity and such should be a wrap-able frame instead of a column. That right there would alleviate some of the problems with the 'new' fixed look they want. --Tsavi (talk) 01:36, October 21, 2010 (UTC)

That's not going happen. The changes has their drawbacks and I see that as a challenge. For example, they are going to reduce the drop down to 4, that that as a viable TOC. Instead I am going to replace that system with a portal concept much like the one at Fallout. The width is also a challenge but D-day and I are working to reduce the size of the infoboxes, and make the space much better utilized.
So, while some admins like the ones at Halo chose to leave, I feel like this is a framework I can work with. So I am going to stay :) Stick around, you'll like what I have coming up. -- tierrie talk contr 02:01, October 21, 2010 (UTC)
The reason they have lowered the number of links in the menu was because users did not click on most of them. I understand that a lot of links is confusing, but when it's done right, it isn't. This is the same issue I have with the removal of MediaWiki:Sitenotice.
Moving to another wiki farm is only a viable option if there's a strong community consensus like WoWwiki, now Wowpedia (they have moved to Curse). It also only works if we can find a proper host for the wiki.
You can, however, change the layout as you please if you know CSS to your personal wikia.css. So you can change the width of the article space, remove the big Wikia header, etc. I forgot who had a stylesheet ready to be copied, but if anyone is interested, I'll try to find his wikia.css.
There's still Monobook available, although the wiki doesn't have a stylesheet for it yet. --D. (talk · contr) 02:50, October 21, 2010 (UTC)

Suggestions

My observations for now, in no particular order:

  • Article management tags will have to be resized. They become a problem when used with infoboxes (see The Reaper's Cudgel for an example).
  • The padding for tables can be reduced to 0.2 or 0.3. It effectively saves spaces, both in width and height.
  • For pages listing items in tables like longswords, the notes column should be changed. I don't think the description is necessary, but we should keep the notes if the item is from a DLC or in another expansion game, or if it is restricted to a character or class, or where it is found or how it is obtained (this is debatable as there is a consistency issue regarding this).

--D. (talk · contr) 15:52, October 8, 2010 (UTC)

I got a few ideas for ItemInfoBox.
  1. The first is where we can "hide" the ItemInfoBox and replace it with an icon like the spoiler. Clicking on the icon would expand the Spoilers. We can round the corners, and animate it with jQuery. It could move the article aside as it expands or it could float / hover above the article. It could remain "expanded" until turned off with a X, or it could remain "expanded" while the mouse cursor is hovering
  2. The next idea is to remove the ItemInfoBox element and move it to the left of the WikiaArticle page. This essentially gets around the width limitation by putting a hovering element to the left of the article space. That element could also open/close and scroll as the page scrolls. This idea breaks the Wikia's concept of a fixed article width and I don't think it is a good idea to do this.
  3. The third idea is to find a way to move the element to the RIGHT of the article space into the space reserved for the Recent Activity, Uploaded Photos, etc section. This is a lot harder since a css solution will most likely just float over those sections and block users from seeing it. The other solution is to hack together some javascript that took the div out and reinserted it in the right side onload.

I'll post more ideas as I come up with them. -- tierrie talk contr 19:28, October 8, 2010 (UTC)

I'm not sure with the iteminfobox. When expended, it's still going to screw up the article layout. Moreover, it seems to involve too much clicking, unless cookies are saved. I would not recommend using javascript for anything that is necessary for the wiki, unless a javascript-free option is presented.
There's going to be problems with using the sidebar or adding additional content outside the WikiaArticle space, as these suggestions break the ToU by shifting content around. Moreover, there are ads on the sidebar. --D. (talk · contr) 20:35, October 8, 2010 (UTC)
I agree that we shouldn't really be moving things outside the article space. I'm throwing ideas out there and seeing what sticks. -- tierrie talk contr 22:43, October 8, 2010 (UTC)


Style: Weapontable

One of the other options I considered during the early days when I designed this was to reduce the number of cols. Some columns can be merged to save horizontal space. For example

Instead of

Name Damage
Critical chance Armor penetration Strength modifier Runes Enhancements Notes

Blightblood may refer to:

Disambig gray This disambiguation page lists articles associated with the same title.
If an internal link led you here, you may wish to change the link to point directly to the intended article.


We can do this

Name Damage Enhancements Notes
Blightblood

Dragonbone
Requires: 31 strength

Damage: 11.20
Critical chance: 3.20%
Armor penetration: 4.00
Runes: 3
+3% melee critical chance
+2 attack
+10% critical/backstab damage
Poison: Venom
Restriction: Rogue


The tradeoff is that we can no longer sort by damage.

Alternatively, I can use the tooltip so that we can present minimal information in the table, and put all the info in the tooltip itself, like so (the tooltip needs to be expanded)

Name Damage Critical chance Armor penetration Enhancements
Blightblood may refer to:
Disambig gray This disambiguation page lists articles associated with the same title.
If an internal link led you here, you may wish to change the link to point directly to the intended article.

Dragonbone
Requires: 31 strength

11.20 3.20% 4.00 +3% melee critical chance
+2 attack
+10% critical/backstab damage
Poison: Venom

This does not have to be the final design, but we do need to implement something quickly based on what we perceive to be "most broken" from the Wikia change. We can always come back and revise them later. -- tierrie talk contr 23:10, October 8, 2010 (UTC)

I like the third format you are proposing. It's compact and I like the use of icons (I like seeing them). If another column must be added (I don't know for what though?), the columns for damage and critical chance can be further reduced. I'm just wondering what you have in mind for the tooltip. --D. (talk · contr) 00:42, October 9, 2010 (UTC)


You already see the tooltip on the 3rd design yes? I was going to put the restriction, item descriptions and other info that would make it more in line with the in game tool tip. Its fairly complete with a few missing bits. I could even transform the rune numbers into some squares to represent the number of runes it could have. More polish than revolutionary work. -- tierrie talk contr 18:25, October 9, 2010 (UTC)
I like the idea of including the number of runes, as well as restriction (since that's included in-game), but the item description might make the tooltip really big depending on the equipment piece, unless the font is smaller. --D. (talk · contr) 18:48, October 9, 2010 (UTC)
My thoughts pretty much align with D-day's on the tooltip. I would miss the strength modifier column however since removing it reduces your ability to make a good decision on weapons based on a quick look at the table. An alternative possibility I suppose would be to have the damage column list damage*strength modifier instead of just the base damage. -Vim- (talk) 18:12, October 14, 2010 (UTC)

Style: Infoboxes

I've been looking at different ways to get the infoboxes display and I don't think they are that bad. One problem with them though is that images will stretch them, unless their width is set to 259px (with the way infoboxes are styled, and their width, 275px). This is eventually the same case if the image is very big in height (especially for armor/weapon pages). Currently, the font size has been changed (Wikia increased it recently, in case no one has noticed), so it's set at 9pt (it should be at 8pt). Infoboxes width could be decreased to 250px... even 200px (that might be pushing it, but it's do-able). Of course, there are exceptions! The infoboxes should perhaps be changed to look like navboxes and tables (the padding is a bit bigger). Yes, that's about 6px saved.

I've been working on updating the code for the template based on Wikipedia's code. It's basically going to look the same, except that parameters have changed, and it will not call other templates to make the infobox work. It's also more flexible.

There are some special cases/exceptions, namely Template:ConflictInfoBox and Template:ClassInfobox. I've also been working on them, but because it uses CSS (stored on my computer), they will not display correctly for everyone except me. Included within the infobox template, I've made it so it can be nested, and use collapsible tables. ConflictBox will more or less look like this (imagine the cells have no padding, so "Belligents" looks like a normal header). This show/hide can be used for anything that's extremely long. I have ClassInfobox as well (regarding that infobox, I have no idea what the third column is for). It's still based on my infobox code, but it's evidently different (again, that's an exception). Unless there's a need to make a new template just to support this particular styling, the code should be within that infobox template. I haven't added the option to make them not collapsed by default, but it can be added.

A suggestion regarding infoboxes in general, or just very long infoboxes, is to implement a way to show/hide the whole template. You can see how they look on Wookieepedia.

Regarding the article management templates and other article notices and how weird they look with infoboxes, we don't actually have to change them actually: it's a matter of placement. They should always be before the infoboxes codes. The only problem comes up when they are used for a section, where the infoboxes overflow. In that case, perhaps a section-like option could be given like Template:Section-Stub. To avoid make bunch of templates and reduce the need to update them everytime, the option can be made within the article management template instead. --D. (talk · contr) 16:13, October 16, 2010 (UTC)

I suggest that you put the css into the code for the mockups. That way, regardless of what happens to the stylesheet in the future, we will always be able to see how it was designed and intended to look. I like the idea of making the infoboxes narrower. Make a few infoboxes with the different widths and lets see how it looks?
And your suggestion regarding the amboxes makes sense. We can withhold changes there until the infoboxes have been modified and then see if we still need to fix it.-- tierrie talk contr 00:42, October 17, 2010 (UTC)
Gave this some more thought - if you're not changing anything visually then there's no real need to do a mockup. Go ahead and post the changes at the InfoBox level. Let me know if you need me to unlock anything. -- tierrie talk contr 00:15, October 21, 2010 (UTC)
I've updated the template so it can include a specific style for every label and data cells. The show/hide will display as intended. ClassInfobox can be previewed on Mage, Rogue and Warrior (I suggest looking all of them, as mage is slightly different). Its width is set at 250px. The information is different from the current style. ConflictInfoBox can also be previewed on pages like Fifth Blight or First Blight (the images must have a specific width though). There's one slight issue regarding the line-height when small icons are used, but I'd rather fix this when the template has been updated with the proper codes. Its width is set at 275px. I found that if it's smaller, the infobox looks weird.
I have made mockups for the infoboxes in four suggested widths (it could be different than the ones I have added). Besides the width, there should be not changes from the current style (the padding for the header may be slightly different, but it's not noticeable). This is only for the item infobox, I don't know if we should change the width depending on the type of page. I'll be making mockups for a different infobox style (by mimicking the tables and the navboxes) another day. --D. (talk · contr) 02:50, October 21, 2010 (UTC)
I like style 2 and style 3. Somewhere between 250px and 225px appears to be the sweet spot. If I had to choose between those two, I'd pick style 3. I'll put a poll up for this. -- tierrie talk contr 06:54, October 21, 2010 (UTC)
Also looked at the ClassInfoBox and ConflictInfoBox, and they look awesome. The class pages need to be normalized but otherwise looks great. I am in favor of using a consistent InfoBox width - so if most items use 225px or 250px, then everything should swing that way if possible. Exceptions can be made once all other possibilities are exhausted. -- tierrie talk contr 07:00, October 21, 2010 (UTC)
Upon further reading, I'm not sure Wikipedia implementation of label1/value1 is the best. They designed their templates very early on and I feel that using a variable length system like the one currently used may be an improvement. What are the disadvantages of using those optional rows? -- tierrie talk contr 07:09, October 21, 2010 (UTC)
I feel it's easier to make infoboxes with Wikipedia's code, and like I have said, it's much more flexible. You can customize it while keeping it consistent with the styling, or change some infoboxes depending on the page if needed. This goes further with making all cells the same style different than other infoboxes, or just one being a tad different. If only one cell is needed, "data" can be used, and "label" will not appear. This is how my versions of ConflictInfoBox and ClassInfoBox work.
I suppose one of the issues you have with the template is that you can't change the order of the label/data with ease? Not sure about other advantages to calling other templates, so I'd like to know other reasons why they are an improvement. I know the system could be "upgraded" to allow more customization, which would somehow follow Fallout wiki's templates. I wouldn't use the exact same codes, I like to keep things standardized (using the same parameters on all infoboxes templates, same organization/system to keep things consistent–that is one problem I have with some meta templates on this wiki like Template:For, Template:See and other similar templates). It's currently a bit harder to read imo, but that can be changed as well (Wikipedia's code is cleaner and more organized). There are some tweaks I'm not sure if it will work as intended, but I'll try to look into it (I currently have limited time, so it'll be a bit slow). --D. (talk · contr) 17:02, October 21, 2010 (UTC)


I gave this more thought and I realized that prefer Vault's style mostly because I am used to it and that's how our TableRows are designed. Templates like {{ArmorTableHeader}} and {{ArmorTableRow}} need to have each row be a template because we don't know how long they are. That argument is a little harder to apply to InfoBoxes since it should have a limited number of rows. But, I still feel that it is somewhat valid and futureproofs us pretty well. The drawback is as you mentioned - it is difficult to do a box like ClassInfoBox and ConflictInfoBox using that style. Especially if we want to keep the hide/show tabs. Did I understand the problem correctly? -- tierrie talk contr 20:08, October 21, 2010 (UTC)
The table rows are something that I am also very familiar with, but those are tables, so it is a very different system to use. The infoboxes can have as many rows as possible, but I have limited it to 30 because I haven't seen a need for extremely long infoboxes yet. Infoboxes actually use the same system as navboxes.
I'm not sure if the rows will be a problem for the show/hide, I'll have to test it out and see how it goes. I'm also not sure how efficient it will be to make the other different infoboxes.
Not sure what to think of this, but on WoWwiki, Sannse wrote: "They are also working on solutions for wide tables across Wikia, and ideas for better handling infoboxes. Those will be global features, and not WoWWiki-specific." --D. (talk · contr) 23:12, October 21, 2010 (UTC)

Style: Mainpage

See Forum:Project Flemeth: Main page redesign#Main page mockups for mockups for the redesigned main page.
Community content is available under CC-BY-SA unless otherwise noted.