Help Improve Pack Creation!

[TechAngel85]

Remember, we have been thinking about this stuff for nearly three years, so all would do well to study the Data Dictionary of our Semantic Mediawiki implementation of Mods and Packs in particular.
 
Please discuss or add input on the above-linked DD Talk page
 
All Pack-Mod-centric information needs to be consolidated on the page I linked in order to be implemented (so that we all know what is going on and why). A forum is just too convoluted for consolidating ideas. Let's get all of the good ideas onto that Talk page and revise the Packs tab in particular as necessary. Even if you just want to add links to posts over here on the forums ... THAT IS FINE. Just please help us to consolidate on the wiki (I am way too immersed in RL to take that on myself ATM).
 
At some point, I will tidy up the wiki page and consolidate everything neatly.
 
In short:

• Mod Template (i.e., mod pages) should contain all common, static mod-specific info about a given mod. These pages are absolutely necessary to driving the wiki for just about any implementation that is desireable. No getting around creating mod pages, so bite the bullet and get them created as necessary. They will NEVER go away
• Pack Template should contain all common, static pack-specific info about a given pack. Like mods, pack pages will never go away, but we can drastically change them to suit the needs of Pack users
• Guide Templates bring Mod/pack info together, and we could have more than one type of template even to produce whatever guide style is wanted.
• Versioning or tracking of other changing information associated with specific Mods/Packs/Guides (conflict res, instructions, version #s, patches, etc.) will need to be handled as Semantic sub-objects or some other method that is scaleable and practically maintainable.

Anyone interested in helping out needs to learn about Semantic Mediawiki. A prerequisite is a decent understanding of wiki markup in general as well as template creation and maintenance.
 
Lastly, anyone interested in helping with development of the SMW infrastructure as actual devs or just those willing to propose viable ideas and contribute in an organized way (this is you Nearox and Smile, et al.), please PM admin to get access to the DD forum thread and Pack implementation forum thread and get ready to read a lot of historic info.

---

 
Pack Proposal
 
With the release of STEP v2.2.9, STEP will shift it's focus to our new paradigm outlined out the STEP:Mandate page for STEP v2.3.0 and beyond. This also means STEP:Extended will be shifted from the main STEP:Guide to a Pack and will be the Official STEP Pack.  What is a Pack? Well to quote the Mandate:
 
 

One of the primary reasons for keeping STEP:Core pretty strict with regards to vanilla is that the overarching STEP project intends to evolve into a more community-driven initiative of mod 'recipes' constructed as extensions of a central core recipe (aka, STEP:Core). These mod recipes are simply extensible build instructions that we have been referring to as STEP 'Packs'. These packs are themselves extensions of STEP:Core that build on it in ways that express or support different visions of the game. ...

STEP Packs are where the substantive deviations from vanilla Skyrim can and will occur, depending on the vision of any given pack author. Some of the packs may be focused on gameplay changes, others on further graphic enhancements, but together they will allow users more flexibility and choice when determining their modded Skyrim experience. The real beauty of this paradigm is that ANY STEP member will be able to author their own STEP Pack and host their guide on the STEP wiki. Think of it as a 'Nexus' of mod-recipe add-ons that will serve to expand on the ideas of the Steam Workshop, the Nexus, TES Alliance, Planet Elder Scrolls, etc. as a "mod-setup-creation infrastructure" using a common set of development tools to derive a limitless expanse of potential outcomes, each with its own support infrastructure (e.g., forum threads, wiki resources, custom tools, etc.). ...

STEP:Core will provide a common, front-end Guide to modding Skyrim and articulate (via the Semantic Mediawiki infrastructure) with the community-authored Pack guides. The build interface will allow modders to assemble mod compilations complete with detailed instructions specific to mods, mod compatibility patches, Packs and Pack-compatibility solutions as well as a whole host of other relevant attributes, flags and tags for describing Packs and mods. This will be accomplished using forms on the wiki, and the result will be dynamically-created mod lists and Pack Guides that will "snap" together over STEP:Core. The result will be a series of (hopefully seamless) unique instructions for creating the particular build desired by the end user.

 
You can see a list of example Packs created by users here: https://wiki.step-project.com/Category:Packs Some are using the in-place infrastructure which we're considering to be a Beta format and some are simply using a normal Wiki page. Our goal is to have all Packs using the infrastructure that the Wiki Devs have put their hard work into; however, we need help from the community and that's where you come in!
 
The infrastructure is still in a Beta state; however, is working for simple Pack creation and should be mostly, if not completely, bug free. We need you, the community, to help improve this infrastructure by using it and providing feedback on its use. Even if you don't play on creating a Pack, you can use it to create a "dummy pack" for testing purposes and these "dummy packs" can be removed later. We're looking for all and any feedback! Everything from feature suggestions to changes and/or improvements on existing features and its use will be helpful. Even if there are Core mods that you think would be best shifted to Extended, we want to hear about it! If you're interesting in testing this out, please contact a Staff member to be added to the Pack Author group on the wiki.
 
 
Wiki Development
If you know your stuff with Wiki Development and are interested in becoming part of that team, please let us know! We're always looking for new members that can work in this area. Keep in mind the wiki uses https://semantic-mediawiki.org/ .
 
 
 
Feature Ideas, Suggestions and Improvements

• Ability to use a custom CSS file via the forms as well as a default one if no custom CSS is provided
• Add Pack Author group to forums with or without a badge
• Tabs to the form on the Mod Pages which users can access to for adding general and Pack information. See discussion starting here.
• See this post for Nearox's well rewritten ideas for mod tables, ToC and more. Clarifying post here.
• Addition of icons (see here)
• Load Order section (see here)

Features Implemented / Changes

• Removed the "Mod List:" text from the tables headers so only the user's desired titles will display. (Template edit)

[Smile44]

With the 2.3 ethos being that it is a base upon which to build packs there are still one or two subjective mods that should perhaps be in Extended, in particular Main Font Replacement and Lockpicking Interface. Neither of these are fixes and are only subjective improvements. I mention this here because for packs to work out of the box so to speak then CORE needs to be stripped down to fixes to vanilla including graphic ones. Anything that suggests a choice e.g. STEP recommends ... should be in Extended. Otherwise you end up with CORE mods becoming obsolete when a pack is installed over it. No Biggie I know but....

 

There are three Requiem packs in the menu but only one is relevant Pack:Requiem the other two Base and Extended Requiem packs are obsolete and should be removed but as far as I know I do not have access to that function though I did request it some time ago.

 

There are certain limitations currently to the information that can be added to new mod pages, as a pack author I frequently have to add mods to the wiki so that they can go into the tables, but can't put much detail about the mod on the page, again not a Biggie but irritating because it feels only half done.

 

Anyway just a couple of thoughts to get the ball rolling as it were.

 

[TechAngel85]

I deleted those for you.

[Smile44]

Splendid fellow.

 

[TechAngel85]

With the 2.3 ethos being that it is a base upon which to build packs there are still one or two subjective mods that should perhaps be in Extended, in particular Main Font Replacement and Lockpicking Interface. Neither of these are fixes and are only subjective improvements. I mention this here because for packs to work out of the box so to speak then CORE needs to be stripped down to fixes to vanilla including graphic ones. Anything that suggests a choice e.g. STEP recommends ... should be in Extended. Otherwise you end up with CORE mods becoming obsolete when a pack is installed over it. No Biggie I know but....

Any recommendation/suggestions in this area is also good. Core was decided on by the Staff; however, we're not infallible and recommendations on mod removals from Core to Extended will be looking into. Adding this to the OP. 

There are certain limitations currently to the information that can be added to new mod pages, as a pack author I frequently have to add mods to the wiki so that they can go into the tables, but can't put much detail about the mod on the page, again not a Biggie but irritating because it feels only half done.

Adding new mod pages comes with the territory of being a Pack Author. We'd love to have a vast library of mods for each category. Eventually over time as mods are added, this will be less necessary. What sort of details are you looking to add?

[Smile44]

Detailed description of the mod, pros cons, compatibility issues, general information a review if you will. From a pack point of view this information is less important because we can add the relevant detail there but from a browsing mod point of view and deciding whether or not to include it as an optional then there lies the problem. I do not mean that we should supplant the mod page, but to be able to have an objective description would be useful. Mods added to the STEP guides have this facility but it is locked and rightly so. Information could also include the packs it is used in for example my little Survival pack (which I keep meaning to update and expand sometime)  is almost completely supplanted by mods in SR but not STEP.
 
I understand that the STEP mods need to work in the way the do for the guide and these should be hard coded, but non STEP mods could be opened up, perhaps an admin only button that prevents unauthorized editing (as already exists), or a separate form for non - STEP mods, that automatically only allows admin, staff and the user who added the mod to edit it.
 
Perhaps this is all unnecessary but every time I add a mod to the wiki I keep feeling "Is that it?" 
 

[EssArrBee]

Detailed description of the mod, pros cons, compatibility issues, general information a review if you will. From a pack point of view this information is less important because we can add the relevant detail there but from a browsing mod point of view and deciding whether or not to include it as an optional then there lies the problem. I do not mean that we should supplant the mod page, but to be able to have an objective description would be useful. Mods added to the STEP guides have this facility but it is locked and rightly so. Information could also include the packs it is used in for example my little Survival pack (which I keep meaning to update and expand sometime)  is almost completely supplanted by mods in SR but not STEP.

 

I understand that the STEP mods need to work in the way the do for the guide and these should be hard coded, but non STEP mods could be opened up, perhaps an admin only button that prevents unauthorized editing (as already exists), or a separate form for non - STEP mods, that automatically only allows admin, staff and the user who added the mod to edit it.

 

Perhaps this is all unnecessary but every time I add a mod to the wiki I keep feeling "Is that it?" 

 

This is something I've though about quite a bit. I've come to the conclusion that leaving the form the way it is now is best from a permission standpoint. The addition of a tab or two to the form seems like the best option. One tab would be for added pack stuff, like flags that pack authors could use, and it would be editable by pack authors who are in that wiki group. The second tab would be an information tab that anyone has access to that could be information displayed after the STEP needed stuff which would make the page much more like a regular wiki page. I think it would act as an area more for FAQ type info, but would help for the more complex mods.

[TechAngel85]

Detailed description of the mod, pros cons, compatibility issues, general information a review if you will. From a pack point of view this information is less important because we can add the relevant detail there but from a browsing mod point of view and deciding whether or not to include it as an optional then there lies the problem. I do not mean that we should supplant the mod page, but to be able to have an objective description would be useful. Mods added to the STEP guides have this facility but it is locked and rightly so. Information could also include the packs it is used in for example my little Survival pack (which I keep meaning to update and expand sometime)  is almost completely supplanted by mods in SR but not STEP.

 

I understand that the STEP mods need to work in the way the do for the guide and these should be hard coded, but non STEP mods could be opened up, perhaps an admin only button that prevents unauthorized editing (as already exists), or a separate form for non - STEP mods, that automatically only allows admin, staff and the user who added the mod to edit it.

 

Perhaps this is all unnecessary but every time I add a mod to the wiki I keep feeling "Is that it?" 

 

I thought that might be it. Yeah, those fields for adding that information is locked for users due to it be essential to the STEP Guide. The only two  ways around this which I can think of would be to add in a text field which would be editable by users but not contain any relevant installation information, etc because that type of information would be specific to the Guide/Pack and may differ from Pack to Pack. The other way (which I don't know if it's possible) would be to create some type of flag for mod pages that are included in STEP. Mod pages with this flag would be locked to users by default as they are now and mod pages without the flag would be unlocked for user editing.

 

Either way, I'll add this to the suggestions.

 

EDIT:

Ninja'ed by EssArrBee...same ideas though!

[EssArrBee]

I thought that might be it. Yeah, those fields for adding that information is locked for users due to it be essential to the STEP Guide. The only two  ways around this which I can think of would be to add in a text field which would be editable by users but not contain any relevant installation information, etc because that type of information would be specific to the Guide/Pack and may differ from Pack to Pack. The other way (which I don't know if it's possible) would be to create some type of flag for mod pages that are included in STEP. Mod pages with this flag would be locked to users by default as they are now and mod pages without the flag would be unlocked for user editing.

 

Either way, I'll add this to the suggestions.

 

EDIT:

Ninja'ed by EssArrBee...same ideas though!

Yeah, are we also going to draw up a wiki proposal for this? The extended proposal seemed to work quite well for us. 

[TechAngel85]

Yeah, are we also going to draw up a wiki proposal for this? The extended proposal seemed to work quite well for us. 

Maybe when we get some more ideas and discussion flowing, but if and when we do it'll need to be outside of the STEP namespace so that the users in this discussion can also contribute since the STEP namespace is locked to Staff.

[Nearox]

I'm happy this thread has been opened. I'll also share some of my thoughts on the subject to brainstorm some ideas. I have this thing of wishing to much once someone throws a bone, but here is my write up of things I have had in my mind since I started working on packs 8 months ago:

 

Mod Tables

 

• Mod tables are not really useful for pack authors and users alike. They are often more of a hindrance than a convenience. Smile44 already mentions one point, namely that the table format just does not allow to provide sufficient space. Cramming the space with information will quickly lead to a loss of overview for the user.
• Most packs will be relatively small, so there is no need to compress the information via mod tables as all the information is just a few mouse scrolls away anyways. Descriptions and instructions under the mod's name suffice for both authors and users.
• Whereas STEP can put detailed instructions at the mod wiki page, packs often do not have that luxury due to having one or more mods included in the pack that are already in STEP. The reason those mods are included in the pack is usually because they need different instructions or additional patches specific to the context of the pack.  Not to mention multiple packs can use the same mod, which means instructions just cannot be put at the mod's step-wiki page. Which also brings me to my next point.
• Having to add mods to STEP wiki (in order to be even able to add them to the mod table) is time consuming and basically a waste of time. I can understand the need for this for STEP mods, but it feels like a huge redundancy. 
• Instead, make a 'mod installation' section as part of the table of contents (see next point) and standardize it. Each mod should at least have a description, author's name, version number at the top by default. Rest is up to author to fill in. Would be even greater if there are togglable options for mod cleaning/special instructions as many mods tend to require one of them. 

Table of Contents & General Pack Lay-out

 

• Table of Contents should be the foundation for every pack, and ideally be generated automatically. The wiki interface for authors should be built around this. I would argue this is the most crucial improvement necessary. It provides guidance to both authors and users. Without a table of contents, REGS or MMO (or also e.g. SRLE) would be a mess to navigate. Even smaller packs benefit greatly from this.
• The way I see it, every one of the more popular packs has basically mostly the same elements that make it a success for end-users:
  • Brief summary.
  • Introduction (explanation of pack concept).
  • Required tools (like tes5edit, ddsopt etc.).
  • Required pre-installation setup.
  • Mod installation (largest section).
  • BOSS/LOOT sorting order rules.
  • Compatibility (this section usually mentions specific mod incompatibilites and potential solutions).
  • Conflict resolution.
  • Merging ESPs.
  • Final steps. 
  • Changelog.
  • Credits/thanks.
• My suggestion is to include a default table of contents so that every pack has a more or less uniform look. At the moment, everyone seems to use a different format/layout which means that when the user is starting to look for a pack to install, he or she can get easily confused and/or overwhelmed.
• Importantly, this also provides guidance for would-be pack authors and it might get more people to consider developing their own pack. 
• It forces pack authors to think about the total package of things necessary to have a succesful end-result (like conflict resolution and compatibility).
• Table of contents does not need to be  limited, of course. The more advanced pack author can still add another section, when needed, by simply copying the code. 
• If/when you have decided on a default table of contents, you can design the wiki interface around it. Almost all of the elements (or call them 'chapters') can simply have a blank box to fill in (just like it is now with some current sections like pre-installation setup) except for Mod Installation (see point 4 of Mod Tables above). BOSS/LOOT rules could however be nice to have in table format.
• The end result should IMHO be a page layout that looks somewhat like SRLE/REGS. Easy and quick to navigate. Nothing difficult or complicated. 

Colorization and Font size

 

• One thing that really breaks a pack overview, or any webpage really, is the lack of visual distinction. 
• Having to mess around with colors and fonts via BBCode is a chore for pack authors, and I guess the main reason why hardly anyone does it. CJ and I did it for REGS, but it was a hell lot of work - at least until CJ's CSS but after that some BBCode was still necessary.
• I'd suggest: Combined with a Table of Contents should come a uniform default color and font setup for colors and font sizes for chapter/subchapter headings, paragraphs, mod links, mod descriptions (e.g. bold, italized), author (bold/italized), version (bold/italized). Basically, a pallette baked into every pack page. 
• Make lines under each heading, and have the line be a matching color for the heading but not the same color. 

The info section at the top left

 

• Remove Required pack, compatible packs and DLCs required . This is not necessary as it is usually explained by the author in the compatibiltiy section. 
• Keep the forum thread link.
• Instead of one of the aforementioned, add a last updated notification in that box instead, showing when last edit was made.
• Also add option to list pack authors and provide direct links to their profile at STEP and/or Nexus. 

The description at the top

 

• Currently if you use the wiki interface and add in a description for the pack, it ends up in a box at the top (see e.g. Requiem pack). Personally I prefer it much more to be under the info section, but centered in middle just like REGS has it. You could instruct pack authors to try to limit this to 3 lines or so. When I go to the requieme pack, I basically skip over the description in the dark box because it is too much at the top and the contrast in colors between text and box is not nice. 

 

 

I have no idea if you have the time to develop anything like this, but my personal view is that this would greatly benefit both pack authors and end-users. The user wants simplicity and a clear overview, and the pack author does not want to waste time on layout, colors, fonts, bbcode, adding mods to STEP wiki, clunky mod tables and whatnot. That stuff is just distracting from development of the pack content itself. 

 

My 2 cents... 

Edited August 17, 2014 by Nearox

[DoubleYou]

Pack proposal eh? I got plenty of ideas. Unfortunately, I don't really know how to implement them... yet. I might take a crash course in semantic mediawiki.

[TechAngel85]

Wow! Thanks, Nearox! This is the type of detailed information and feedback we're looking for. You've clearly put some thought into it.

[DoubleYou]

I really must agree with Nearox. There's a reason everyone has hacked their packs to use the Neovalen-style guide.

[TechAngel85]

I really must agree with Nearox. There's a reason everyone has hacked their packs to use the Neovalen-style guide.

I agree with most, if not all, of what Nearox said too. There's a reason SR:LE is so successful and the format/style of that the guide is developed in has something to do with that. I see that he's still using most the CSS I developed a long time ago as an alternative to the STEP:Guide.

 

The only thing I'm not sure can happen is the dropping of the mod tables. S4N would know best on this and would be the main developer along with Z so that one suggestion will be entirely in their realm. Some of the changes suggested though might be as simple as editing pack templates which is how I removed the "Mod List:" text from the table headers earlier. I couldn't figure out a purpose for that text so I removed it.

 

EDIT:

Looking at the templates, some of the changes would be fairly easy to make. Once we set up a proposal on some of these ideas and get the discussion, votes and approval some of the suggestions should be able to be done by Staff. Most of it looks like HTML which I'm no stranger to. Calling different parameters from the forums/wiki is another story but if they're already present on the page then moving them around and changing the HTML to fit different formatting will be easy enough to do without needing the Devs to do it.