Difference between revisions of "Doom Wiki:Central Processing/2017"

From DoomWiki.org

(2017 content)
 
m (Move back top thread...)
Line 3: Line 3:
 
This is the '''central discussion forum''' for wiki editing and administration activity on the Doom Wiki. Feel free to ask any questions or pose any concerns you have here, and you should receive a response shortly. Check the archived discussions for older threads. For extended discussion on long-range "to do" issues and project planning, please also visit our [[Doom Wiki:RFC|Request For Comment hub]].
 
This is the '''central discussion forum''' for wiki editing and administration activity on the Doom Wiki. Feel free to ask any questions or pose any concerns you have here, and you should receive a response shortly. Check the archived discussions for older threads. For extended discussion on long-range "to do" issues and project planning, please also visit our [[Doom Wiki:RFC|Request For Comment hub]].
 
{{Central Processing archives}}
 
{{Central Processing archives}}
 
== Navboxes wrap-up ==
 
 
In recent months several aspects of [[:Category:Navboxes for map articles|navboxes for map pages]] were discussed:
 
# [[#Navbox_template_font_size.3F|Font sizes]] of header, map names, and numbered 'other' maps on desktop and mobile
 
# [[#MAP10_or_MAP11_for_episode_1_templates.3F|Grouping]] classic Doom II-megawad maps by sky-based episodes
 
# [[Talk:Valiant#Map_templates|Organizing]] 'other' maps for modern episodic Doom II-megawad maps
 
This new topic aims to tie up these topics and any loose ends.
 
 
I've written a [[User:XymphBot#navboxGen.php|new script]] to generate various types of navboxes that takes the outcome (if any) of the above topics, and further brainstorming on [[Doomwiki (IRC channel)|IRC]], into account.  Its results are [https://doomwiki.org/w/index.php?title=User:Xymph/Sandbox&oldid=128884 sandboxed here]. They use the [https://doomwiki.org/w/index.php?title=MediaWiki%3ACommon.css&diff=128844&oldid=113811 CSS class] '''dw-navvariable''' and family that Quasar recently created as per topic #1.
 
 
The main differences to current navbox styles are:
 
# The header ("<wad name> levels") is in normal font, not 'larger' (see C, E, J).
 
# Names for Doom(1)-style episodes have remained in normal font (see E).
 
# The active list of named maps is in 'smaller' font on desktop but 'normal' on mobile (all).
 
# The classic Doom II-type area of other, numbered maps uses a different background than the active list (see G, H, I).
 
# For modern episodic Doom II series (see J):
 
## the episode names aren't linked to another template;
 
## the active episode name uses normal font and the other ones are 'smaller';
 
## the episodes have separator bars (Quasar's suggestion);
 
## the maps in the other episodes are included as 'smaller' numbers for quick navigation as per topic #3.
 
Some layout details are still controlled in style divs but can be moved to the CSS files once sufficient consensus has been reached.  So, does anyone object to the structuring and styling of all these types of navboxes?  And if so, what would you suggest to change?
 
 
A new idea: for Doom(1)/Heretic multi-episode navboxes, a single line of small map numbers could be added to the non-active episodes to allow quick navigation, just like for Doom II style boxes (item 5.4). I.e. "E1M [[E1M1: Hangar (Doom)|1]] [[E1M2: Nuclear Plant (Doom)|2]] [[E1M3: Toxin Refinery (Doom)|3]] ... [[E1M9: Military Base (Doom)|9]]" or "E1 [[E1M1: Hangar (Doom)|M1]] [[E1M2: Nuclear Plant (Doom)|M2]] [[E1M3: Toxin Refinery (Doom)|M3]] ... [[E1M9: Military Base (Doom)|M9]]". Would that meet with approval or opposition?
 
 
Once that's settled, I will regenerate all existing Doom/Doom II/Heretic navboxes using these styles.  Per topic #2 the existing 01-10 / 11-20 boxes can also be regenerated as 01-11 / 12-20 boxes unless the megawad explicitly specifies another grouping.  (The existing navbotBot.php script can then apply the renamed boxes to the 20 pertaining map pages.) Are there objections to that?
 
 
Finally, two nitty-gritty details:
 
# In the header of existing navboxes sometimes the word "levels" is used (A-D, G) and sometimes "maps" (E-F, H-J); and the same inconsistency happens in reference to Secret map(s)/level(s).  I propose to use "levels" - okay?
 
# On map pages the navbox can be placed [[E3M1: Hell Keep (Doom)|above]] or [[E2M1: Foray (The Classic Episode)|below]] the <nowiki>{{map|}}</nowiki> template, which affects their relative alignment and whether or not the slot description line wraps next to the navbox in narrow(er) windows.  What would be the preferred template order?
 
A final observation: the generated navboxes can of course be manually adjusted afterwards, like the Obituary one.
 
--[[User:Xymph|Xymph]] ([[User talk:Xymph|talk]]) 13:46, 21 December 2016 (CST)
 
 
:Some opinions:
 
* For Ult. Doom and Heretic, I'd be in favor of just listing the other episode maps as M1, M2, M3, etc. The E1 part is kinda redundant with the episode name being just above.
 
* Map vs level? I'd be more in favor of "map" because it's shorter and I think more generally used than "level" in the Doom community. Though it seems this wiki has chosen [[level]] and [[level editor]], but then again it's not entirely consistent since we have things like [[:Category:PWADs with maps]] and [[:Category:Map views]]. No strong opinion either way but the map slots themselves are clearly called MAPxy or ExMy; not LEVELxy or ExLy.
 
*Template order: I think Hell Keep looks better than Foray, so I'd say above.
 
*Other points: no real idea right now. --[[User:Gez|Gez]] ([[User talk:Gez|talk]]) 16:52, 21 December 2016 (CST)
 
 
:* Listing other episode maps, agreed: see E1-E3 in the [https://doomwiki.org/w/index.php?title=User:Xymph/Sandbox&oldid=129538 current sandbox].
 
:* Sometimes the longer "levels" helps to beef up the box a bit (e.g. Galaxia), and [[level]] is indeed a reason why I proposed to use that, but usually a long wad name makes the shorter "maps" preferable, so I'm fine with that too.  Of the existing navboxes, the vast majority already uses "Secret maps" (although Doom II is one of the exceptions).
 
:* Placing navbox above <nowiki>{{map|}}</nowiki>, agreed as well.
 
 
::In the past two weeks Quasar and I worked on and off to tune the navbox styling of wikicode/HTML in tandem with CSS to look good and consistent on desktop and [https://doomwiki.org/w/index.php?title=User:Xymph/Sandbox&oldid=129538&mobileaction=toggle_view_mobile mobile].  The current sandbox has the result, which will be final (and deployed to all existing Doom/Heretic navboxes in due course) unless additional suggestions are made over the next few days. --[[User:Xymph|Xymph]] ([[User talk:Xymph|talk]]) 12:27, 9 January 2017 (CST)
 
  
 
== Map screenshots gallery dimensions ==
 
== Map screenshots gallery dimensions ==

Revision as of 15:23, 30 January 2017

This is the central discussion forum for wiki editing and administration activity on the Doom Wiki. Feel free to ask any questions or pose any concerns you have here, and you should receive a response shortly. Check the archived discussions for older threads. For extended discussion on long-range "to do" issues and project planning, please also visit our Request For Comment hub.

Central Processing archives


Map screenshots gallery dimensions

I presume everyone agrees that the default dimensioning of map screenshot galleries is somewhat underwhelming: the thumbnails are post-stamp size, and the borders too large and uneven. Larger thumbnails (with even borders around them) would make them more useful and the page more visually attractive. For my next scripting endeavor I intend to update all existing galleries with new dimensions (and also clean up formatting issues, if any). Empty ones too, to assist future contributors of more screenshots.

How much larger? I sandboxed a few possibilities. I propose to use option 1.3, and set 1.3.1 as default in the skeleton. Any objections or alternative suggestions? --Xymph (talk) 11:46, 30 January 2017 (CST)

Suggestion: using packed galleries; or at the very least noline. See this. Currently we have too much of our real estate pixels (real pixstate?) taken by entirely useless white noise such as borders and trims. By getting rid of these, we can have less poststampy screenshots without increasing the visual size of the page. --Gez (talk) 12:07, 30 January 2017 (CST)