Editing guide

[Nicereddy 109]

I'll probably base the landing page off of the Codrops CSS reference. I would personally suggest splitting the page into various different sections for each content section (e.g. Video Settings, Audio Settings, Infobox, Input Settings, System Requirements, etc.) and then offering two means of navigation:

 

* The current full page design, with each separate content section transcluded into the page so they'll always be updated simultaneously.

* Separate pages with a "< Prev"/"Next >" design (I can handle the logistics of that if you'd like)

 

I suggest this primarily because the page is pretty large at the moment, and if someone wants to just see the guide for Video settings, they have to wait for everything to load and then find the section. With a central page like the CSS reference linked above, editors only need to load one small page with a list of the different sections (each linking to their respective guide pages) as well as a link at the top to the "Full Editing Guide" which would essentially just be the current editing guide as it is now.

 

Hopefully that would appease everyone?

[Nicereddy 109]

Also, should we call it an "Editing Guide" or "Style Guide"?

[ThatOneReaper 51]

Also, should we call it an "Editing Guide" or "Style Guide"?

Editing Guide. This covers everything, not just the style.

[ThatOneReaper 51]

I'll probably base the landing page off of the Codrops CSS reference. I would personally suggest splitting the page into various different sections for each content section (e.g. Video Settings, Audio Settings, Infobox, Input Settings, System Requirements, etc.) and then offering two means of navigation:

 

* The current full page design, with each separate content section transcluded into the page so they'll always be updated simultaneously.

* Separate pages with a "< Prev"/"Next >" design (I can handle the logistics of that if you'd like)

 

I suggest this primarily because the page is pretty large at the moment, and if someone wants to just see the guide for Video settings, they have to wait for everything to load and then find the section. With a central page like the CSS reference linked above, editors only need to load one small page with a list of the different sections (each linking to their respective guide pages) as well as a link at the top to the "Full Editing Guide" which would essentially just be the current editing guide as it is now.

 

Hopefully that would appease everyone?

The Codrops style is a good place to start off with.

 

Everything else you stated are all great ideas. I'm all for this approach.

 

If we really want to be fancy, we can have headers (and Table of Contents icons) for each section of the guide. But it's ultimately your decision.

[Guest]

Cannot or Can't?

[ThatOneReaper 51]

Cannot or Can't?

Cannot. Text in wiki pages should be as formal as possible.

[Guest]

Cannot. Text in wiki pages should be as formal as possible.

Ah, so I was using the correct form, thanks.

[Mars icecream 57]

Cannot. Text in wiki pages should be as formal as possible.

Please use can not instead. Cannot is more casual, although still acceptable.

[ThatOneReaper 51]

Please use can not instead. Cannot is more casual, although still acceptable.

"Can not", while the most formal, looks silly in most cases. We're formal up to a point.

 

Use "cannot". All other variations are to be disregarded.

[Guest]

I was wondering, now that the Fixboxes will no longer look like absolute ass, which one of these is more optimal?

[Mirh 103]

I was wondering, now that the Fixboxes will no longer look like absolute ass, which one of these is more optimal?

Something like "replace intro files" in the header

And actual instruction below

[Guest]

Something like "replace intro files" in the header

And actual instruction below

You only liked using the second option for fixes and stuff? It's not a bad format, I just didn't use it too often on the current wiki as the fixboxes looked really ugly.

 

I will mostly use that format for very short paragraphs.

[Mirh 103]

I will mostly use that format for very short paragraphs.

Very short paragraphs sentences.

Or better a single sentence which consequently means one verb, thus one action.

 

Therefore "Use XXX parameter" is still fine imo, but not download the archive AND extract its contents somewhere.

Also, a hyperlink plus that awfully long path with another different markup is pretty heavy to read, at least for me.

[Guest]

Just encountered an issue not covered in the guide. I was adding an availability row for a game's official store, and the link contained equals signs in it, causing that row to be all messed up. After consulting with soeb on the IRC, I discovered the formatting should go like this:

{{Availability/row|1=Official |2=http://www.official/store/url?action=product&id=555 |3=DRM |4=Notes |5=Key }}

As the guide doesn't have this vital bit of information, it should be updated to include it; if it affects other availability row types as well, it should be noted for those rows as well.

[ThatOneReaper 51]

Just encountered an issue not covered in the guide. I was adding an availability row for a game's official store, and the link contained equals signs in it, causing that row to be all messed up. After consulting with soeb on the IRC, I discovered the formatting should go like this:

{{Availability/row|1=Official |2=http://www.official/store/url?action=product&id=555 |3=DRM |4=Notes |5=Key }}

As the guide doesn't have this vital bit of information, it should be updated to include it; if it affects other availability row types as well, it should be noted for those rows as well.

Thanks for bringing this up. I've added in the alternate syntax details.