105 replies to this topic

[Pyke]

Hello,

From a user of both STEP, SR:LE, REGS and Requiem pack : It is really easier to follow the infos from SR:Le and REGS. All the information about a mod are in the same place, for example no need to go on the Nexus to see the actual version. The instructions are in the right place. And the mods are in the order of installation.

Thanks for the works y're doing.

[Nearox]

Cleaning, tagging, and mod merging can just go under one big installation section. I've used that top down version for a while and find it easy to work with, but it might be best a template.

{{Template|Mod Name*field 1*field 2*field 3....closing stuff}}

I would then have to switch everything to a template, but it would make less work for others in the future.

Sounds good. One big installation section is allright too. However if we are talking about consistency though, I would prefer to see [color=#ffa500;]TES5Edit Mod Cleaning Required[/color], [color=#008000;]BOSS Masterlist/LOOT updating required[/color], [color=#ff0000;]Bash Tagging required[/color] all in the same style/colors in every pack. If that is possible by means of a template, great :) But why then not make these fields that the pack author can fill in, and which accordingly are shown in their respective style/color at the pack page?

 

Keep in mind I am not a programmer and have little knowledge about html, so I don't really have an idea if what I suggest is possible or viable to make. 

Edited by Nearox, 20 August 2014 - 01:22 PM.

[EssArrBee]

[color=#ffa500;]xEdit Mod Cleaing  [/color][color=rgb(255,165,0);] [/color]

 

I'm thinking site wide now that we cover every game, but morrowind covered and we all use that same style which could be made into a nice template for everyone to use.

 

I still like the mod pages for some things though. I imagine if we the ability to add more info to them like FAQs then mod authors could use them for that reason. It would be kinda late now, but someone like kryptopyr could have linked all her info for making mods compatible with CCOR to the mod's page. Just stuff like that which brings in more people to the site sounds good to me. Adding a bunch of install instructions is not good, but a list of packs that a mod exists on is something we should consider.

[TechAngel85]

A quick and easy format for the FAQs would be

;Question here:Answer here.

The ';' will automatically bold the question and the ':' will automatically indent the answer.

 

Although, if we can get the CSS we're looking into working on the wiki (in the PM...don't thank you're involved Ess...I'll add you) then that would be a very nice solution to use for the FAQs as well. It could be used for a lot of things actually.

[DoubleYou]

I think what Nearox wants are automated mod pages created within the pack form. That way, he can add all his mods to his pack with one go, rather than manipulating a pile of mod pages.

[stoppingby4now]

I don't know... In my experience it is very tedious and, from a pack author's point of way, unnecessary to add a seperate wiki entry for every mod added to the pack. Moreover mod tables also really limit your options with regards to layout. 

 

S4N I understand the need for consistency, but that is easily achieved by making packs in SRLE format... Unless you are speaking of a different kind of consistency. I don't think it benefits the packs if they are limited to mod tables for sake of having a similar look to STEP Core. We tried pretty hard with REGS, it was in mod table format for a month or so, but it just became unworkable after a while. After switching to SRLE formatting everything became a lot easier, and the feedback of REGS users at the time was exclusively positive about that change. 

 

As for intercoonectedness of data, what are you referring to? Even if 2 packs use the same mod, or if a pack uses the same mod as STEP but in different ways, having them all refer to the same mod wiki entry, while technically being interconnected, what is the benefit of that? Instructions are made on the pack page anyways, and I don't think it would be a good idea to have every pack author write the instructions on the mod wiki page as that would clutter them up real fast. 

Sorry for any confusion. I'm not referring to any need to have mod tables. The structure can change to whatever is deemed best suited for packs, and if mod tables are not cutting it, then they need to go.

 

Consistency and interconnectedness:

 

Mod data is all managed via Semantics. That means it is all available to anything on the Wiki via semantic properties. You are correct that pack specific instructions/data do not belong on the Mod pages, but the Mod pages provide semantic data such as...

• Link to a thread on the forum for discussion on the mod
• Download URL (mod project page)
• Resource usage
• DLC requirements
• Section (Ultimately needs to be non-STEP specific and geared towards the primary category a mod should be associated with)

All of this information keeps consistency by utilizing a single repository of information about a Mod that everyone shares. This eliminates discrepancies by providing that single source of information. If a download URL needs updating, change it once, and everything on the Wiki that references it is automatically updated. That is also how everything is interconnected.

 

Whatever the resulting design of a pack layout ends up being, the above information when implemented within templates reduces the editing burden across all pack pages. All while helping to ensure that basic mod information represented everywhere is accurate.

[DoubleYou]

Could we not somehow have Packs write their instructions to {{{mod}}}/{{{pack}}} ? Then somehow (categories?), link all those differing instructions to {{{mod}}} so that users can see the similarity in instructions between packs, or lack thereof?

[stoppingby4now]

Could we not somehow have Packs write their instructions to {{{mod}}}/{{{pack}}} ? Then somehow (categories?), link all those differing instructions to {{{mod}}} so that users can see the similarity in instructions between packs, or lack thereof?

I'm not a fan of sub-pages for things like this. They add extra maintenance, separate child information from their parent, and pollute searches.

 

A better solution would be to use sub-objects to tie instructions with a mod within the pack page. Semantic queries can then be used to provide reports on things like what packs have instructions for mod X, or what mods have instructions in Pack Y. This can all be automated as part of the management of mods in a pack.

[TechAngel85]

I remember someone asking for it, but I don't remember who or where so I'm just going to post it here and hopefully they'll find it. For those wanting to add a "last updated" time stamp to their page, here is the code:

:Updated: {{ #time: G:i:s j F Y "(UTC)" | {{REVISIONTIMESTAMP}} }}

[stoppingby4now]

I remember someone asking for it, but I don't remember who or where so I'm just going to post it here and hopefully they'll find it. For those wanting to add a "last updated" time stamp to their page, here is the code:

:Updated: {{ #time: G:i:s j F Y "(UTC)" | {{REVISIONTIMESTAMP}} }}

Adding update time to a page is unnecessary. It is built into the skin and already appears in the bottom bar on every page.

[EssArrBee]

Can we get {{TOC limit|n}} template, which will help shorten my ever growing table of contents? I can't get it to work and I've tried the Wikipedia and wikimedia versions. Also, would it be viable to make a table that is filled with templates like the one we described above for mods? I think could work something out that is a dynamic table but uses the srle model. And where would go to learn how to make a form?

[TechAngel85]

Adding update time to a page is unnecessary. It is built into the skin and already appears in the bottom bar on every page.

I've never noticed that. But I just pulled that code from the Guide pages. It's been added to them since before I started out as a Wiki Editor almost 2yrs ago. Haha!

[stoppingby4now]

Can we get {{TOC limit|n}} template, which will help shorten my ever growing table of contents? I can't get it to work and I've tried the Wikipedia and wikimedia versions. Also, would it be viable to make a table that is filled with templates like the one we described above for mods? I think could work something out that is a dynamic table but uses the srle model. And where would go to learn how to make a form?

I just added that template, and the necessary CSS to support it. Try it out.

 

I'm not sure what you mean by a table filled with templates. Could you expand on that more?

 

Forms are made with Semantic Forms. Some URL's to begin with:

 

https://semantic-med...elp:User_manual

https://www.mediawik...:Semantic_Forms

I've never noticed that. But I just pulled that code from the Guide pages. It's been added to them since before I started out as a Wiki Editor almost 2yrs ago. Haha!

I know I removed that code from a few guide pages a ways back. Someone must have added it back in. The modified time has been there from day one.

[EssArrBee]

Yeah, I just saw that my ToC in F&L had only a few entries. It works fine now, so there isn't a list that goes half the page.

 

I guess what I mean is a way to implement the style of of SRLE:

===== [<url> <mod name>] =====

* '''Author''':

* '''Version''':

...

 

Like how Nearox had listed it above, but we could do it as a template since SRLE, F&L, REGS, C&PD, and the Oblivion guide all use that way of implementing mods. Then if we could somehow make that into a table where you choose the mod then fill in the parameters of the template, then add another mod to the table, fill in the parame.... and so on and so on. That would bridge the gap between the style people are comfortable with and allow for a table to be used. By choosing the mod from a table it could also set a flag on the mod's wiki page for that pack to be listed somewhere. I think that makes sense. It wouldn't really work for F&L, C&PD, and the Oblivion guide unless we really expanded mod pages, but it could work for packs.

[stoppingby4now]

Yes, that would be possible. Expanding on the need for mod pages to exist on the Wiki, a pack author can add mods to their pack, which would allow the common information to be automatically  imported such as author, download URL, forum URL, description, DLC requirements, etc. Then the additional fields can be made available for each individual mod to provide the pack specific data.

 

All using templates of course, and semantic forms.

 

I haven't followed this discussion 100%, but if you folks want to start a mock layout of how the ideal pack page structure would look like, I can help get all of the semantics updated/implemented.