PathfinderWiki
Log in

Forum:Inline indexes?

From PathfinderWiki
Forums: Grand Lodge > Inline indexes?

Hey! Long time no see. I might be back for awhile. Maybe.

Anyways, my focus, mostly as it was last time, will be around Portal:Fiction.

What I'd like to explore is ... "inline indexes" or, in essence, "a list of keywords". Which is to say: how do we format a not-in-a-sentence dump of keywords mentioned in a fiction? We don't appear to do this anywhere on the wiki currently, though there have been some soft attempts here and there. There's, of course, User:Fleanetha's great existing indexes, such as on Called to Darkness/Index, but those are "too far away" from the main source for my tastes. Even with that external index on another page, we still have "soft" inline indexes running around, such as the "Character" section on Called to Darkness or City of Secrets 1 or the beastie listing on The_Skinsaw_Murders, or even the table of contents of Numeria, Land of Fallen Stars. All of these are, ultimately, a "list of keywords", and I'd like, at least for the fiction, a normalized "like other wikis" way of indexing them.

So, what do other wikis do? Welp:

With those in mind, here's something I'd like to see (as a mocked up entirely fake example from The Compass Stone:




Chapters

1. Opening Moves by Erik Mona - Burnt Offerings (80)

Venture-Captain Shevala Iorae presents a history of the Pathfinder Society to Eando Kline, and assigns him a seemingly innocuous mission. This chapter breaks from the normal style of the Pathfinder's Journal by presenting a background article on the Pathfinder Society itself instead of a first-person account of a pathfinder's exploits. It is included as part of this novella because it contains an introduction letter by Shevala to Eando and because it is part of the "Pathfinder's Journal" section of the book but, beyond that, the information contained in this chapter is not written in the same voice or style as the rest of the series. Shevala's letter is included in the compiled version, but the Society article is not; in his introduction, Sutter describes it as "a much-needed thing, given that it was our big debut and no one had yet heard of the group we'd named our world after."
4148 ARCholeric ooze swarmExample red linkFaerie dragonKernic QuicktongueMelfeshMount KallarisPutrid ooze4148 ARCholeric ooze swarmExample red linkFaerie dragonKernic QuicktongueMelfeshMount KallarisPutrid ooze4148 ARCholeric ooze swarmExample red linkFaerie dragonKernic QuicktongueMelfeshMount KallarisPutrid ooze





So, the above's an example of "keywords" per chapter, but in situations where we do want to categorize them (like pulling out the major characters or locations that appear in a novel) we might list both, one generically, and one specifically, something like:




Characters

Radovan VirholtVarian Jeggare

Contents

1. Opening Moves by Erik Mona - Burnt Offerings (80)

Venture-Captain Shevala Iorae presents a history of the Pathfinder Society to Eando Kline, and assigns him a seemingly innocuous mission. This chapter breaks from the normal style of the Pathfinder's Journal by presenting a background article on the Pathfinder Society itself instead of a first-person account of a pathfinder's exploits. It is included as part of this novella because it contains an introduction letter by Shevala to Eando and because it is part of the "Pathfinder's Journal" section of the book but, beyond that, the information contained in this chapter is not written in the same voice or style as the rest of the series. Shevala's letter is included in the compiled version, but the Society article is not; in his introduction, Sutter describes it as "a much-needed thing, given that it was our big debut and no one had yet heard of the group we'd named our world after."
4148 ARCholeric ooze swarmExample red linkFaerie dragonRadovan Virholt





Thoughts?

My goals here are:

  • To more adequately reflect all the things mentioned, name-dropped, or featured in a fiction.
  • To move the "click here for the index" pages into the main body of the article.
  • To solve the "well, I have the ebook version - these page numbers correspond to nothing" current index problem.
  • To be obsessive and create more backlinks for individual articles.

Good to see you back Morbus Iff after nearly three years! Great ideas above too.

I can straight away say re your:

  • To solve the "well, I have the ebook version - these page numbers correspond to nothing" current index problem.

We no longer apply page numbers to the indices and just list the elements within the index. Adding all the page numbers was very complex and time consuming plus it didn't really add much for those with ebooks and search facilities. To go back and strip them out of historical indices would be too painful after the work was done, however.

I'll be interested how this pans out then and let me know if you want any advice.

Welcome back!

I'm leery of long flat lists in the article body. These examples look good, especially with the descriptive text, but I'm more worried about how the 400+ entries on something like Heart of the Jungle/Index would work even when broken up by chapter.

That said, I like how the Trek wikia breaks the references into categories, which we could potentially tie into our existing category tree.

Also we have an {{hlist}} template and style now, so these lists can also be rendered with:

Thanks for the re-welcomes ;)

The {{hlist}} stuff looks great, though it renders vertically in the mobile theme (causing me great confusion when I viewed your comment off my phone).

I agree with the sentiment on the 400 entries - in hindsight, I think doing it "per chapter" might make it even more exasperating since you would expect that some things would stay the same from chapter to chapter (the main character, the primary location, the talking sword or pet, etc.). I think that's pretty much a death-knell for chapter-by-chapter indexing - too much duplication, too much page inflation, and no other wiki seems to have placed that much import on such narrow "locations in the text". Of course, this is "easy" to resolve for a full length novel (one complete work) but a little more complex for AP fiction (being both a full work and part of a larger work at the same time).

Incidentally, as another example of a wiki-with-index much closer to home:

http://forgottenrealms.wikia.com/wiki/Rise_of_the_King

References with categorization, but it's similar to the Star Wars wiki in that it's a giant list that is faaAArr too vertically-long for my tastes.

So, if we get rid of per-chapter indexing, then that almost seems like a vote for categorization too. I'm thinking of Heart of the Jungle/Index and imagining it as a giant {{hlist}} with no formatting, and it just wouldn't work. It "works" as it is now because it IS categorized (by letter) and because there's notable black text to break up the monotony of blue (more notable than just a  · that is).

Next step, then, would be to create (or steal and modify from another wiki) a list of notable categories that an index would have.

I'll investigate that for a bit.

The Forgotten Realms wiki doesn't appear to have templates or docs on which categories to use for a book's index. So, I made one:

  • Characters (these subcategories appear to always be used)
    • Main characters
    • Supporting characters
    • Minor characters
    • Mentioned characters
  • Locations (these subcategories are not always used and appear at odds with each other in purpose)
    • Surface
    • Underdark
    • Primary locations
    • Secondary locations
  • Creatures
  • Artifacts

The Star Trek wiki format is documented at http://memory-beta.wikia.com/wiki/Memory_Beta:Style and snipped below. If one category's listing gets too big, they allow smaller categories (which appear undefined): "For instance, dividing characters by their posting or affiliation, or making separate section for locations in space or on a planet. If the "other references" section becomes too long then additional subcategories may be used to break it up, "Foods and drinks" for instance. It should be noted whether subjects were actually featured in the story or merely referenced. For instance "The strange new alien rather reminded the Captain of a Gorn", references a Gorn without one actually appearing in the story."

  • Characters
  • Starships and vehicles
  • Locations
  • Races and cultures
  • States and organizations
  • Science and technology
  • Ranks and titles
  • Other references

The Star Wars wiki uses a template for the appearances list (which we'd do too, but theirs is overkill for our needs). They also use a comic-book-wiki-like list of appearance modifiers (like "first mentioned, "first described", "appears as a ghost", "heard only", "mentioned only", etc.). You'll note that this is also slightly done by the Forgotten Realms wiki with their header of "Mentioned characters":

http://starwars.wikia.com/wiki/Template:App http://starwars.wikia.com/wiki/Wookieepedia:Template_messages/Sources_of_articles#Appearance_templates

And, finally, the Marvel Comics database uses http://marvel.wikia.com/Marvel_Database:Comic_Template:

  • Featured Characters
  • Supporting Characters
  • Villains
  • Other Characters
  • Locations
  • Items
  • Vehicles

There's also our own conventions for adventures and PFS scenarios using {{Adventure overview}}, which takes keywords for level, location, faction, and adventure type, then renders the lists horizontally and categorizes the page accordingly.

So, per Oznogon earlier, the nearest thing we have is our existing primary categories:

http://pathfinderwiki.com/wiki/Category:Categories

Resulting in something like this first-draft:

  • Characters (synonymous with Inhabitants)
  • Locations
  • Creatures
  • Items
  • Other
    • This would contain "everything else" in one un-subcategorized list.
    • Per the Star Trek wiki, if this list gets too long, it could be broken down into:
      • Afflictions
      • Alignment (probably never used for fiction)
      • Art
      • Food and drink
      • Languages
      • Magic
      • Nature (for non-mob "life" not placed under Creatures)
      • Organizations (also covering Factions)

This would leave the following categories in our main tree left, not because they're unimportant or rarely-mentioned, but rather because any one book would likely not have enough to justify their own category. Sub-subcategories under "Other" should only be used if there's at least five entries, I'd say. There will always have to be occasional exceptions however, like Faiths of Balance rightfully needing "Religion" or "Philosophies".

  • Character options
  • Combat
  • Culture
  • Games
  • Geography (use Locations instead)
  • History
  • Philosophies
  • Planes
  • Religion
  • Sciences
  • Time
  • Trade and transport

Thoughts?

And what is our "term" for all this? "Appearances"? "References"? I vote "Appearances" (given we already use References for citations). I wouldn't vote for "Index", only because an "Index" is typically a word > location lookup table, which we're not doing (no direct page numbers, etc.).

Spent some time playing with {{hlist}} today, and I'm not a fan of it. The stated goal of it is to create more semantic HTML, but the result is:

<div class="hlist" style="margin-left:1.6em;"><div class="plainlist"><ul style=""><li style="">
<ul><li> <a href="/wiki/Eando_Kline" title="Eando Kline">Eando Kline</a>
</li><li> <a href="/wiki/Shevala_Iorae" title="Shevala Iorae">Shevala Iorae</a>
</li></ul>
</li></ul></div></div>

That's TWO divs, and then a list within a list. That's pretty ooky and not very semantic.

If anything, I'm not even sure why this is a template vs. just a CSS class.

We might consider https://www.mediawiki.org/wiki/Snippets/Horizontal_lists instead.

Some early entirely-unfinished-draft-only fiddling here:

After looking into the historical usage of HLIST over at Wikipedia:

https://en.wikipedia.org/wiki/Template:Hlist

it seems our documentation for HLIST is wrong, which is partly why I ended up hating it (above). Our documentation says "pass the whole list", but the actual documentation is "pass the list items as parameters, not the list". The fact that it works in the wiki currently (where we're passing a complete list as "the first list item") is luck - the generated output on, say, Portal:Fiction is "an html list with one item, which itself is an html list" which is "wrong".

When I use the WP documentation for hlist (passed piped items instead of passing a whole list), the generated markup is better/acceptable:

http://pathfinderwiki.com/wiki/User:Morbus_Iff/Sandbox/InlineIndex1

Discussion about {{hlist}} split off to the workshop.

UPDATE: Resolved. The {{hlist}} template was only exclusively used on about 10 pages, most of them portal pages; it's been replaced by {{flatlist}}. Also, the {{Appearances}} template had an issue that exacerbated the markup regardless of {{hlist}}. {{hlist/doc}} has been updated to better reflect its intended usage. Navboxes, {{Adventure overview}}, and other templates already using the .hlist CSS class were not affected.

Good stuff!

Alright, here's a second draft stab, and this what I'll be using as I reread The Compass Stone (the current examples are from that collection):

For the second draft, I left out all the "Other" subcategories mentioned above, mostly considering it "premature optimization" - that is, we don't really know if we'll ever need those subcategories in Other and too much work might mean no buy-in. If someone wanted to really "do the research" to see if we needed the subcats, they might take Heart of the Jungle/Index and see what it would look like in this categorized approach.

Reread AP #1 and #2 fiction and created categorized test index for it on User:Morbus Iff/Sandbox/InlineIndex1. Some notes:

  • We're definitely going to need a "mentioned only" template. Will do, based upon http://starwars.wikia.com/wiki/Template:Mo.
  • I'm not entirely sure I like the dates in "Other". They're good to have, but... maybe not in that way or form?
  • Not sure I like listing our races or classes. They seem too... ... "common" to really be useful in an index.

Fleanetha: given that you've done a ton of indexing, any unspoken rules that you followed? Speak them!

Thoughts?

Today's update:

Still don't really have a handle on dates in these lists.

I suggest we change these from "appearances" to "index". Dates, for example, don't really "appear", nor are elements that are merely mentioned. I think this is a great idea overall, but I don't really have much more on the topic than that. Those of you working on it seem to have it well in hand, but feel free to ask for my input on anything specific you might get stumped on.

And welcome back, Morbus Iff!

Hey, Yoda8myhead! Thanks!

Think of "appearances" as part of the phrase "words that appear in the work" vs. "things the characters can look at" (which wouldn't make sense from a non-prose sourcebook, where this "index" could also be used). My only concern with "Index" is that an index is usually a two-part thing: the term and the location within the text of the term. We're not planning to track the location in this new approach (the old indexes used to, but haven't been in recent memory) , so "Index" is a bit of a mischaracterization. Of the four other wikis this approach is modeled after, one uses "References" (which we can't use since that's being used for our citations), one uses nothing at all (which I'm not necessarily against), and two use "Appearances", which is what informed the current usage.

I'm not tied to "Appearances", but I'm not sure "Index" is right. What about "Keywords"? Or no word at all (moving each section up to an H2 vs. an H3)?

I think with the dates, specific days of the month haven't been getting thier own page, events have only been indexed by year, and the day mentioned on the year's page when we talk about the event and on the event itself's page. So for things like '12 Gozran 4707 AR' and '10 Gozran 4707 AR' just having one link to Gozran and one to the year would be sufficient, but years are common enough in the sourcebook type books that I do think years should be thier own category or subcategory.

Cpt kirstov: thanks!

I've tweaked User:Morbus Iff/Sandbox/InlineIndex1 to only use a single month/year date in "Other". For now, I'm holding off on doing subcategories in "Other" until we "get more data" on actual usage, as it were. But, should the need arise, a subcategory of "Other" for "Dates" would be doable without much work.

The Trek wiki calls them References, which is probably (and unfortunately) the best term; the fiction refers to the listed things and concepts, even if they don't necessarily appear in the story. Mentions might be decent alternative.

Either way, I like how these are looking.

And we use "Appearance" in our creature entries...

Unless we use something like "Indexes", "some other new word", or "no heading at all", it's gonna be slightly painful to get this in.

Tried my hand at one, though not inline: Nightglass/Index.

Oznogon - thanks for giving it a try!

Looking at Nightglass/Index, I like:

  • {{viewpoint}}
  • The sublists with things like Hellknight ranks and coins.
  • The bigger/smaller location sublist for Crackspike.
  • Sublists like that should become part of the Tips on {{Appearances list}}.

I don't like:

  • The distinction made between "main characters" and "other characters". I'd prefer all alphabetized, with book summary indicating "main characters".
  • The extra newline for Creatures. I see what's being attempted, but "big giant string of italicized text" is probably plenty noticeable already.
  • I waffle back and forth on {{mentioned}} now. Is it too much? There's so many here, it makes the not-mentioned ("actually part of") hard to find.
  • I took out things like druids, clerics, bards ("classes") from my in-progress attempt, same with races. They seem too common to be useful?

Thanks, Morbus!

I created {{Viewpoint}} to designate viewpoint characters, so breaking them out is redundant. No objections here to integrating them in the list, especially if {{Mentioned}} can be tamed a bit. If we keep using {{Characters}}, listing the same major and viewpoint characters in an inline {{Appearances list}} at all would be redundant.

The newline in creatures wasn't intentional. No time to look at the moment but I'm guessing there's something preventing the long bit of text from wrapping. I'm leaning to just cutting it since I can't identify it.

{{Mentioned}} is a bit much. It might work better as a single superscript letter (ie. AzlantM). {{Appearances list}} could integrate a legend, or maybe the M could link to a section of {{Mentioned/doc}} explaining what a mention represents.

I erred on the side of including things that were included in the book's glossary. I don't have many novels so I'm not sure if all of them have glossaries (and if all of them explain terms to the same level of detail). Classes and races are pretty common, but they're also potentially foreign to readers new to Golarion, and new readers probably have the most to gain from links to common terms.

I don't like the superscript M, personally, as I fear people will confuse it with the same character in the PFRPG to designate mythic versions of content. I wonder if we really need to distinguish between mentioned and appearing items at all. If we do, perhaps using divs to change the font, size, or coloration of one or the other might work. It just seems like there are currently so many parenthetical comments in the lists that they are unwieldy. One bonus of adding the templates after each entry is that we can just blank the template and still retain the information within the article without the parenthetical comments showing up, and if we decide to represent them differently later, such changes would cascade across all instances of the template.

Jumping in here after a gap away but looks good. Some general comments first:

  • Re the title of the section: Concordance or Register might work. The former is pretty much a description of what it is.
  • /index versus /Index: In Oznogon's example /Index is used. For articles with a '/' in them, we usually use lower case for the following text so /index is preferred. OK this point is usually true, but not for indices it seems (and I should know) so retracting this statement {{Index}} forces /Index.
  • However, using /index, or /Index for that matter, will prevent the creation of a 'standard' index in its usual place.
  • I wish to comment that looking at all these other wikis shows (i) how good our wiki is; (ii) how awful adverts are - we are very lucky to have this site and sometimes take it for granted.
  • all the novels have a glossary, Oznogon, at the level you found in the example you chose. I pretty much start with the map and glossary as the foundation of any index I make.

Re my experience of index making, we discussed this a bit here Forum:Fiction Indices. In addition to that older conversation, I'd say that the level to which I want to index has increased: as the Pathfinder world has expanded, more mundane elements that I would have ignored 5 years ago are now incorporated into an index. For instance, recently Dmeta has created a mole page - quite frankly, that would have been ignored and not indexed originally but now, well, they are familiars and they, quite rightly, have their own page on the wiki and variants too. In that vein, I try to index everything now as, some day, the concept might be important and my selectivity is purely subjective and thus not what a full index needs.

I am finding it hard though to see the boundary between this inline index and a more thorough index and why we would need both. Once we have a full index, then a shortened version is not needed unless it is very short - just the key elements like we currently have for main characters. Oznogon's example, for instance, was very detailed and begs the question about why not take it further to a full index.

I owe a fuller response in a bit but, Fleanetha, my goal here is to get rid of the "old" /Index (or /index) entirely, and have the "new" index on the main article itself. I'm not interested in maintaining subpage indexes. I want these "inline" indexes to be as complete as the "full" (old) indexes, but as important as the article - "inline" both as it is "inline" to the article (on the article page itself), and "inline" in that it is smaller, vertically, then the original /index.

Some further tweaks.

I've added parenthesis sublist support back to our hlist CSS. So, Oznogon, instead of:

* [[Crackspike]]: [[Desert Rose]], [[Long-Bottomed Lady]]

We can do:

* [[Crackspike]]
** [[Desert Rose]]
** [[Long-Bottomed Lady]]

Semantic and more list-like, but for some reason, our current CSS/theme is putting a space after the starting parens and before the ending parens, and I'm not entirely sure why. The same type of markup (using the same hlist CSS) on Wikipedia doesn't have the extra space. You can see the sublist support for Magnimar, Wartle, and Absalom here:

http://pathfinderwiki.com/wiki/User:Morbus_Iff/Sandbox/InlineIndex1

Per Fleanetha's mole note, I've also re-added terms I had originally taken out (races, classes), and added some more "Earth throwaway references things", like turtle (represented as a statue in a shrine to Desna), and butterfly (which ever so gently flitted over said statue). I left out, however, "bear" and "pig", which were only ever used as similes and metaphors (Eando Kline was "[sized] up [like] a succulent pig", etc.) in Eando's thoughts/memoirs vs. physically appearing or spoken thingies.

To address other comments above:

  • I'd be OK with leaving out the {{mentioned}} template entirely or, as Yoda8myhead suggests, keeping it but having it render nothing/blank. Based on early indications, name-dropping is prevalent and I don't want the word "mentioned" to overpower everything else, nor do I think a shorter hand abbreviation or style is ideal (from a end-usability perspective). Our original/existing indexes never considered it necessary. It was, if anything, "inspired by what other wikis did" and if it's just not gonna work here, fine. My only concern is the potential watering down of a term: if the Grand Lodge is mentioned in every book, then the power of a backlink is dilluted should one want to find or purchase "all books that involve the Grand Lodge").
  • I like "Index" better than "Concordance": Concordance seems like a lot more "work" than what we're doing, though it is a term I'd never heard before, so, yay for learning. I'll retract my earlier laments about Indexes requiring a term and a location and "our Indexes don't track location anymore!" and hand-wave it away with some murmuring backpedaling about "the wiki links point to locations, and the book page itself is a location, and murmer murmer skiddily doo". If everyone likes "Index" (and let's assume they do since /index is what's already established in the wiki), then I'll rename/redirect {{Appearances list}} to {{Index}} in a few days/replies.
  • And, just to clarify it again:
    • I DO NOT WANT two indexes (one on-the-article-page and one on the /index subpage).
    • I WANT a single index, on the article page with no /index subpage.
    • I WANT the index to be as in-depth as the most in-depth existing /index pages.
      • But just with a more "inline" style to reduce the size and girth of it.
    • The indexes should be as important as the summaries or any other part of the article page.

> for some reason, our current CSS/theme is putting a space after the starting parens and before the ending parens, and I'm not entirely sure why. The same type of markup (using the same hlist CSS) on Wikipedia doesn't have the extra space.

Poked at this a bit and it looks like the ::before and ::after pseudoselectors are sensitive to spaces at the beginning of list items and end of a list (at least on PFWiki, which appears to render the list items slightly differently from mediawiki.org). This might also be a side effect of being on 1.19 and mw.org being on something newer. Try removing the space between the bullet and the list item contents.

*do this
* instead of this

I've already made a couple tweaks to {{flatlist}} that should help with the extraneous space before the closing parens. EDIT: and documented this at {{flatlist/doc#Troubleshooting}}.

Not sure the sublists are gonna work out well - because we've got some stuff that says "don't wrap single list items" (the same cause of your "unidentified creature on a new line" problem), sublists and long entries won't wrap, distorting the thing entirely. It even happens on your existing "Crackspike without sublist" (being considered a single long non-wrapping thingy) if you resize your browser enough.

I'm giving up on sublists-as-lists for now - I do believe/agree it is due to MW version (as our created most-basic non-template source has extra spaces and newlines that WP's doesn't), and I spent some time today trying to "fix" the HTML with judicious use of {{#rreplace}} without much luck (I can remove the extra STARTING spaces easily enough, preventing us having to use "*thing" vs "* thing", but not the newline in the rendered HTML, since {{#rreplace}} is only getting the wikiformatting). We could probably "really" fix it with negative margins on the starting/ending parenthesis, but those are hacks. I'd rather NOT do something (i.e., sublists) than do it with "hacks that work in an old version but won't be needed in new version".

I did fix the lack-of-wrapping-on-single-list-item, though.

So, from my perspective:

  • Semantic-sublists-as-actual-lists aren't going to work in our MW version without hacks.
  • Comma-spliced non-semantic sublists are fine for now. We can fix 'em if we ever upgrade.

More explicitly, THIS IS NOT OK:

{{Appearances list
| locations =
* [[Magnimar]]
** [[Irespan]] {{mentioned}}
** [[Street of a Thousand Idols]] {{mentioned}}
| other =
* [[Hellnight ranks]]
** Paralictor
** Lictor
}}

THIS IS OK:

{{Appearances list
| locations =
* [[Magnimar]]: [[Irespan]] {{mentioned}}, [[Street of a Thousand Idols]] {{mentioned}}
| other =
* [[Hellnight ranks]]: lictor, paralictor
}}

This is the exact format that Nightglass/Index is using.

A lot of work is going into this and I am still a little uncertain the purpose as there is so much text above, but many thanks for the clarification above, and I do understand this project is evolving too. Summary: I think you are trying to get the /Index content moved onto its product page (good), to take less space there (makes sense), and to be categorized into subject areas---then alphabetically---rather than just a raw alphabetization of everything (that I'd see as super useful, but probably quite a lot of work on an already time consuming task): is that it? Sounds a good aim all round with that final caveat.

  • Though, in this new format the indices are still going to be massive if they do a proper job of indexing (which I now know they are supposed to do, rather than my initial understanding they are just summaries of the main key elements in a story - that idea still has some merit by the way).
  • I agree the {{Mentioned}} is somewhat dominating, especially when it is denoting something more minor plus your aim is to reduce space. I actually do like the superscript idea as it is neat---any confusion with Mythic I think would be removed with a simple key. Italicizing the item is a traditional way of showing lower importance (though this may get confused with book titles, ships, spells, etc.) Alternatively, tradition would suggest emboldening the key elements in an index---that might work and avoid the italics problem. Again a key is necessary, but I am sure you'll eventually put an intro text like we have today anyway to help the reader which would include such things.
  • On the saving space issue, if we have a character index, highlighting main characters in some way, now on the main page, we should probably then do away with the current {{Characters}} template to save space. however, that helps auto-categorize the page, which would also be lost.
  • What about this for a wild idea: have a look at {{Magnimar navbox}}. Isn't that close to what we need? A structured box containing lists of elements which are categorized and subcategorized then presented alphabetically. They even collapse to save space if need be. It may also help with some of the technical problems you allude to above. In effect, our navboxes are indices of a place, or pantheon, but could easily be reused as indices of a product. The Magnimar one already has many of the subject areas you want. I'll see if I can rustle one of these up now for Diamond in the Rough/Index.

So Diamond in the Rough/Index is finished - a simple example, as it is just web fiction, but you get the idea. Is this any good? I like it by the way - I like the extra structure the box gives over Nightglass/Index, but some comments:

  • To distinguish from navboxes, I suggest some standard changes to the navbox - colour for instance - change from the usual brown - so they look obviously different from navboxes.
  • I think they look much better not collapsed. They will not appear on any other page apart from the index page so we don't need targeted opening of the sections - all should be open straight away. The option to close sections needn't be removed, of course. I just cannot remember how to do this. I never knew how to do this but Oznogon has done it - many thanks - that looks a lot better. --Fleanetha (talk) 10:50, 23 March 2015 (UTC)
  • It is easy to add a new section in 'Other' or elsewhere. We could adopt a standard index model of the main things (see listings above) but, for each particular story, add pertinent subsections that make sense, for instance, 'Ships' and 'Afflictions' in this example. You'll note I have called Miscellaneous 'list 10' to facilitate this.
  • As a trial I have added superscript 'S' to items to denote where there is significant information in the story or it plays a significant part, for example, ConservatoryS. This avoids the Mythic issue.
  • I see 4 potential problems so far over a normal index:
  1. Adding extra detail - one element of existing indices is the ability to add useful information in [...] about a particular element, for example, a reference to artwork or a pen portrait of a character that can be used to ease the creation / updating of a topic's page on the Wiki. These could be added in-line as usual but I think that is very much sub-optimal. References might work moving the data to the foot of the page.
  2. Ability to generally add references & comments (as references) should work but might clash with the S. This should be easily surmountable as a problem though.
  3. The ability to cross reference within the index. For instance, to direct a reader to a person's appearance in the index under their surname when they have looked for it under the first name. This is a common requirement in indices but I cannot see a neat way of doing this. I do have to question whether it is so needed though in this new format when characters, for instance, are all brought together into the same section.
  4. I may have completely missed the point of this whole exercise

Tweaked some of Fleanetha's ideas into a floating infobox-like navbox at User:Oznogon/Sandbox#Index_test.

More later (sigh. life!). In short: Fleanetha might be on to something, but I'm not sure the floating sidebar is good - we already have pages that have overlong sidebars and no body text, and I wouldn't want to exaggerate them further. Good experiment though! Looks good otherwise.

So, my short answer is: I think I like this approach. The longer answer is: aaAAah, an entirely different set of "problems!"

  • Fleneatha: I agree with your summary. I think we might be on the same page (finally?)! :)
  • PRO: I like Oznogon's version better (minus the floating) because of the subcategories. Solves our sublist problems.
  • CON: Back to the drawing board for "what categories should we focus allow", or should we not enforce it at all?
  • MEH: Much more difficult template (but, then, I think the people making indexes currently can handle it).
  • MEH: No word wrapping (which, with subcategories is less a problem, but hurts the "extra detail" desire).
  • Re: {{Characters}} template: We could keep it for the autocats, but have it return no output when provided a (new) parameter.
  • Re: distinguishing from navboxes: I'm not entirely convinced we should do this, actually. One of the reasons I like this approach (besides the existing support for nice subcategories) is because an index is exactly like a navbox: you go there solely to be redirected elsewhere, which is the sole purpose of the existing navboxes already.
  • Re: superscript S: I'm not hugely a fan, but I don't have a better solution. I agree that it "solves" the mentioned issue (by simply drawing more attention to the significant elements vs. the name-drops), but I can easily see myself getting into moral quandraries about whether something is significant or not (vs. just being a namedrop). In a 16-part story, is the NPC who is the entirety of part 3 significant? Is the inn that a main character stays at and meets another character, who then follows him throughout the rest of the adventure, significant? For me, a lot harder to figure that out than it is a one-off namedrop (i.e., "mentioned").
  • Re: cross-reference family vs. given name, etc.: I don't consider this too important, but perhaps that's because I would Command-F vs. scanning a list. As you say, given that we'd be categorizing/subcategorizing things too, I'm not sure a single list (especially a character list) would be long enough to really justify the need for a secondary pointer.

Just finished my first attempt at doing an index (of a single chapter of The Lost Pathfinder) using navboxes:

http://pathfinderwiki.com/wiki/User:Morbus_Iff/Sandbox/Indexes

(Yes, I know, The Lost Pathfinder already has an index, but I'm reusing and expanding it.)

I've simplified the original navbox code a bit too, removing all the unnecessary (or non-existent) parameters, using "above" instead of "list1" for the (now-oneline) key, and using "Flora" and "Fauna" for the plants and animals mentioned during the text. Worrying about whether something was "significant" or not hasn't given me too much hassle (yet). I've also used lowercase for every term unless it was a proper name, which I think makes for a less "loud" index (and more accurately simulates a "real" paper index).

All-in-all, I'm pretty happy with this approach.

When I finish re-reading The Lost Pathfinder, I'll likely move the index into place (inline to the page) "for realz" and see how it looks.

I'm still filling in the per-chapter summaries to give the page more body, but:

I've "made live" an inline index for The Lost Pathfinder, using navboxes.

Some notes:

  1. I've moved The Lost Pathfinder/Index to The Lost Pathfinder/index instead. I know previously in this discussion there was a note that says "well, we use /Index because {{Index}} forces the capital I", but since we won't be using {{Index}} anymore (eventually), it's as good a time as any to use the same "subpages are lowercase" mentality that the rest of the wiki uses.
  2. I've set the Category:Indexes categorization to only happen in the main article page, not on the /index page. This will (eventually) create a much nicer and easier-to-read category listing without having to see /Index all over the place.
  3. The "v • d • e" links in a navbox always assumes the navbox lives in Template:. Since that's not the case for the indexes, I've hidden those "v • d • e" links, which make the index "hard to find" for someone who doesn't know the index convention. Currently, the only way to "know" would be to edit the main page and find the transclusion in the source in the "Templates used in this preview" list.

Thoughts? Excepting any grand "ya done goofed son", I'm considering this a "good enough draft" for production usage and will continue to (slowly) reimplement the existing indexes and create new ones based on re-reads. Given enough time for everyone to see this (a few weeks), I'll also clean-up the work-stuffs that is now irrelevant ({{mentioned}}, {{Appearances list}}, etc.).

Brilliant - some good progress being made here and, yes, I think we are close to being able to roll this out more widely now. So, I think it's time for some more comments:

  • Re /Index or /index - yes I think you are right but let's lose them both and solve two problems of not having the 'vde' on the navbox: let's just have the navbox code on the page. Why do we need a separate page - which is what I think the original inline element was about? The index won't be used anywhere else and the index will be easy to find and any editing will be done in-situ.
  • If everything is carried over from the old The Lost Pathfinder index then that one should now be removed to avoid confusion.
  • Are you aware of the /meta page for each fiction publication? It might need to be slightly amended for the new index style but you can use it to update progess against each publication. Have a look at The Lost Pathfinder/meta for an example. You could tick off the completion of the index in standard format now - penultimate line.
  • I am unsure we need the example of using the superscript 'S' at the top - the description of its use is fine; I have also added a {{s}} template for ease of applying the superscript. I am bothered by the 'S' on Major characters too but, as I put it there originally, I know why it is there.
  • I do like and think it is correct to use lower case for mundane, non-proper name elements in this form of index, as opposed to a more traditional index.
  • Re categories within the index, I don't see this as a big problem. We have a robust category tree and I think we should try to align the categories in indices to that. Actually, you have pretty much done that instinctively anyway but perhaps we should formalize that in any 'Guide to Index Writing' we create.
  • I think we need a 'Guide to Index Writing'
  • It'll be interesting to see how big the matrix is for a full novel - I am inspired and may start reading one soon as have been a bit slow doing this of late.
  • I still feel a new colour scheme should be adopted - I know you disagree - but these boxes are different enough from other navboxes to merit consideration. As they are now in-line there will be other navboxes on the same page (fiction list, suggested reading order, for instance) and there might be some confusion.
  • I am now only left, I think, with one worry about this new format: referencing other, more detailed information. Have a look at Skinwalkers/Index: that has a reference at the bottom attached to a number of elements plus many comments in [...] throughout. These are useful, albeit temporary in most instances. How do we deal with this in the new format?
  • Forgive me if any of this is too picky - I am just trying to get agreement / find what is right early as it'll save frustration and laborious change later.
  • /index vs. /Index and the v • d • e: My only concern with putting the index source directly inline to the article was its size, complexity, and potential for accidental screwuppityness, but it's a pretty minor one. Given the benefits of doing so, I'll just move the source into the main article and delete the /Index.
  • /meta: I had seen this out of the corner of my eye on some other page, but always (mis)took it as an old sandbox-style @todo list of the original submitter. Didn't know it was an institutionalized sorta thing.
  • S: Noticed your S template. Fine enough on all considerations. Will tweak. Will also move S from "Major characters" to characters.
  • Guide to Index Writing: Definitely agree. That has been in the back of my mind the past few weeks and I'll work on it.
  • Big novel: Yeah, I think they'll still be pretty big, but probably still smaller than some of our existing two column dumps. The first "big" one I'm in-progress on is The Compass Stone, but I plan to basically go through the whole fiction line in publication order. I want to reread most of the fictions anywhere.
  • Color scheme: Do we have similar color tweaks used elsewhere (for inspiration, not to challenge)? /meta is one such example. Others?
  • Other information: I experimented with this slightly in The Lost Pathfinder. You'll note next to some terms (Locations > Avistan > Kyonin, or Races > halfling, or Miscellaneous > Asmodeus) are italicized non-linked items. These are terms used in the book to reference the linked item in different, slang, or inferred ways. See also Miscellaneous > knucklebones (dice game). These seem to correspond similarly to Skinwalkers/Index use of "Pirate goddess", "Hunter god", "Jolly roger" or "Poker [game]". But, other Skinwalkers notes like "Byrni [Hazen's brother]" or "Chana [sound wise woman]" or "Milady [80' tall main mast, brig]" seem "wrong" to me. Most of these notes are next to red links, so it makes sense, per se: we don't have a full page on the thingy yet, but this is "his wife" or "a librarian". But, ideally, we'd want full pages for these people, with "a librarian" and "his wife" on those pages and, with that, those words in the index become duplicated data and unnecessary. Looking at Skinwalker with that in mind, I don't see any other type of note: they're either "to be duplicated on the full page" or an alternative name (which The Lost Pathfinder handles as italicized parenthesis after the canonical term).
    • I have seen, in other indexes, other types of notes like (unlinked) "unknown assassin" or "shapeless, limbless mass of flesh; see Gibbering mouther". I think those can both be handled easily enough using "gibbering mouther (shapeless, limbless mass of flesh)" or even something like "gibbering mouther <!-- pg54: shapeless, limbs mass of flesh -->", which is what you did for Nightglass/Index. My only general concern about this approach is that, the longer the phrase, the more chance it has to "corrupt" the display (due to the deliberate non-wrapping functionality of list items in a navbox).
  • I prefer pickiness and obsessiveness. Hell, creating indexes is pretty nerdy, picky, and obsessive already, on top of slavish devotion to make-believe.

Marvellous - progress and agreement!

Let me quickly correct a misunderstanding re the comments: I add the following text to any index I create:

Any comment in square brackets, [...], should be considered a temporary comment but provides particularly useful information for anyone who might create or amend a PathfinderWiki page about the subject. Please delete this data once it is subsumed within an article.

So, I would not want the comment text to persist after a red linked page was made. The idea is simply to give any future author of that page a few pointers and for the text to then be deleted. We agree - such a long line of text won't work in the new navbox hence the comment. Hmm, a reference would work but is more work. I know - what about another superscript to say that there is information useful to a future author on the Discussion page (a 'D' then) and the text being moved off the index entirely? Still more work but neater but yet another thing hanging in the air.

On colour schemes - no I can't think of an example here.

One final point - I think it wise we start putting a marker on a fiction page to say the index is being created by someone. It would be pretty galling to spend time creating an index to be trumped by someone else having doing the same work.

Color scheme: Do we have similar color tweaks used elsewhere (for inspiration, not to challenge)? /meta is one such example. Others?

The infoboxes have a hardcoded color scheme based on information type: Project:Template colors

The subcategories could follow some version of this scheme (character headers in blue, creatures in red, locations in green, etc.). I believe the navboxes only use the HTML colors beige, tan, wheat, or lavender, so using the template color schemes would immediately set the index apart.

Here's the current version of The Lost Pathfinder index box with a color scheme based on the template colors:

Most of the extra markup involves modifying the existing groupstyle color and adding titlestyle to modify each section's header. groupnstyle allows us to modify individual subcategory tabs.

Re: parenthetical information in indices,

My only general concern about this approach is that, the longer the phrase, the more chance it has to "corrupt" the display (due to the deliberate non-wrapping functionality of list items in a navbox).

I believe you addressed this with your modifications to .hlist; the only one I restored was the non-breaking space on the bullet points to prevent the bullets from wrapping. (EDIT: To clarify, I'm specifically referring to text that isn't linked.) That said, I'd vote for the inline HTML comments, as they don't show up on the page but still show up in search results where they'd be most likely relevant. (Saying "shapeless, limbless mass of flesh" inline doesn't add much to the article, and Fleanetha makes a good point by noting such extra details and cross-references are an inherent advantage of the existing index format.)

That said, I think we could make an argument for retaining the separate page for complex or long stories as an accessory to the inline index, and we could use something similar to {{Conflict}} to link directly to a relevant part of a more detailed index. Such a template could use an HTML tag with the title attribute to present a tooltip when hovering over such a symbol:

Asmodeus

I believe such text would also show up in search results.

Initial feeling is that's a little too colorful for my tastes.
I agree that it is a bit too colorful. We really don't use that much color anywhere on the site, and I think it makes the entire project look more professional. I wouldn't however, have a problem with the sub-categories being pastel shades of the associated infobox color, as I think it would look better than having all of them pale blue as is the default for the boxes. I've long felt that we should use a different shade of tan for those, but this is a great opportunity to use a few more colors without going overboard.
  • comment text and hints: Regarding "comment text" ("temporary text to provide hints to future editors"), I think I'm leaning toward "just display it". I don't really want to see yet-another-subpage that contains notes (if we absolutely had to have one, /meta as a workspace seems to make the most sense). Taking Skinwalkers/Index as an example, I've taken the first handful of characters with notes and mocked up how it'd look here (under "Minor characters"): User:Morbus_Iff/Sandbox/Indexes. And, if it looks ugly, my feeling is good. All the more reason to get real pages made up quicker ;) But, I'd also be +1 for including the annotation as a comment in the source.
  • Dib an index: I agree. I'll leave it up to someone else to hammer that out though. Probably just a new addition to /meta?
  • Template colors: Looking at the current color schemes, if I had to pick one, it'd be the purple from Characters because it is the most subdued. The color scheme for "Other" is subdued too, but too similar to the existing tan of the navboxes, such that it wouldn't distinguish enough.
  • Non-wrapping: Nah, User:Oznogon, it still happens because navboxes have always not-wrapped by design. You can see this in action on the "Miscellaneous" section of User:Morbus_Iff/Sandbox/Indexes. Whether it's linked or not, a long list item will never wrap.
Non-wrapping: Nah, User:Oznogon, it still happens because navboxes have always not-wrapped by design. You can see this in action on the "Miscellaneous" section of User:Morbus_Iff/Sandbox/Indexes. Whether it's linked or not, a long list item will never wrap.

I see it now. It's not that long list items break the navbox by expanding it, it's that they doesn't wrap alongside other list items. That's why you were switching the list items' hlist class back to display: inline from display: inline-block in Common.css.

Short version: We can fix the wrapping behavior if we're willing to allow hlist bullets to wrap to the front of a line when they collide with a navbox's edge, as Wikipedia behaves, instead of sticking with the previous list item as we currently behave.

CSS version: We can easily switch hlist list items to display: inline and enforce the now-unused nowraplinks class already applied to all navboxes to maintain the prohibition on wrapping links. However, by doing so any bullets that collide with the navbox edge will wrap to the front of the next row. display: inline-block forces the bullet to stay with the list item, but prevents line breaks.

Since the vast majority of navbox items are article titles, and almost all of them are much shorter than these annotated index entries, this hasn't been a problem.

Notably, we're stricter than Wikipedia about bullet wrapping in hlists. WP just lets them wrap. If we're willing to give up our bullet-wrapping behavior, at least just for these index navboxes, we can gain the list item-wrapping behavior User:Morbus Iff wants.

I added the new navbox-index class to the sample navbox index above, which applies this proposed behavior.

So I have started an index of Reign of Stars on its page - take a look and see what you think as I have tried to incorporate a number of the points above. So far pretty much only the bare glossary terms and the map elements are in and it is already pretty big. Some comments:

  • Colour: when I mentioned colour, in my mind I envisaged for an index pretty dull colours as indices are pretty dull to look at. So I chose simple black and white to distinguish from the brown navboxes. However, I did like a lot of the idea behind Oznogon's garish example and the compromise suggested by Yoda above has been adopted - pale colours associated with the infobox colour palette here: Project:Template colors. I also found this super useful page to help avoid the unfriendly hexadecimal: MediaWiki colour palette. All the colours I experimented with from that palette worked. I have chosen what I can see is the lightest colour of each type needed and used simple white for the Miscellaneous until they are brought up into their own section. Though at the end I may see if I can colour them if appropriate at the line level as I can see that is possible above.
  • Spaces: I notice both Oznogon and Morbus Iff have not used the non-breaking space in their indices: is this intentional? Do we not need them any more using the new template formats? If we don't, then that saves a lot of work.
  • Order: Sections are now in alphabetical order except I'll retain Characters as the first because that seems appropriate for fiction and Other for last as that is the bucket. Alphabetical order is also preserved within the subsections.
  • Titles: I am trying to maintain our category tree as the source of titles and subtitles.
  • Comments: haven't hit a need yet to do them but will consider ideas above, though I already have some pretty long elements due to parenthetical stuff.
  • What does 'Dib and index' mean please?

I hope you like nitpicking too ;)

  1. Not a fan of the adj/dem. stuff in the headers. Causes ugly wrapping in the header (top or side). I'm less antsy about them next to words in the index itself, but it still seems ... "weird"... like, if a snake snaked in the text, would we use "snake (adj: snaked)"? If a knife knifed someone would we use "knife (adj: knifed)"? Indexing all base forms of a word (vs. synonyms) seems too much? Why even both including "dem." and "adj." (as literally written out clarifiers) in the index itself, vs. "Taldor (Taldan)"?
  2. We're conflicting on terms for things, which I think we should hammer out/finalize.
    1. "Animals" vs. "Flora and fauna" (my rationale: "natural" plants and animals of a world; we use Flora/Fauna as category names already).
    2. "Monsters" vs. "Beasts" (my rationale: "Bestiary")
  3. "Alchemical item" seems duplicitous with existing "Items" header.
    1. Why not just "Alchemical"? If "Alchemical item", why not "Weapon item"?, etc.
    2. If we're gonna use a "Weapons & Armour", then I'd want to do that in The Lost Pathfinder too.
    3. Armor vs. Armour? What's PFWiki's default spelling/nationality? (Serious question. :)).
  4. Why "Other areas of Avistan" vs. just "Avistan"?
  5. There's an Index header still on the page, which I assume should go away?
  6. The muted colors you've chosen seem to work pretty well, especially with the black headings.
  7. Random "oh, i noticed": Probably delete the Chronology section. Covered in the Life & Times navbox.
  8. If we're doing alphabetized categories, that'd imply that The Great Beyond should go between Andorran and Numeria, which would feel weird (the sudden juxtaposition of solid ground Golarion vs. elemental plane, etc.).
  9. Spaces: I would not use them in an index.
  10. Dib an index: dib means "I called it" like "Dibs on shotgun!" when trying to get the passenger in a car. "Dib an index" is just my way of restating your "putting a marker on a fiction page to say I WILL CUT YOU IF YOU TRY AN INDEX COS I AM BARING THAT BURDEN ARGHHH!".

As promised, started writing a "Guide to index writing" in User:Morbus_Iff/Sandbox/Indexes. Still very early.

Responding to your nitpicking then Morbus Iff after a bit more work:

  1. The demonyms and adjectives are called out specifically in the glossary and used in the text assuming the reader knows what they mean, so they feel worthy of a mention (and have been in previous indices where a redirect made sense). Let me think on this, as I see your point. Maybe just including them in parentheses would work, as a definition is on the page referenced now anyway (it wasn't always that way).
  2. Yes here I hadn't got to where I wanted so you still saw a hybrid. Have a look now and it should be clear where I am going. Any other creature Types that get large can be called out separately too. Any plants will go in a Plant area or maybe under Nature. Technically, it should be 'Animals and Vermin' but for the index is that too much? Your second point has gone away.
  3. Again, I think now it is fleshed out you can see more where I am going. For a book about an alchemist, an 'Alchemical items' section seems necessary, but I think in other novels these items would just go under 'Other'. As to using Alchemical item, that's a blue link so useful. As I mention above for creatures, I think the flavour of a book will mean we need to vary these subsections, but if we use category tree elements, that'll keep us more consistent. The only problem is some of the elements are lower in the category tree, but we only have a 2 layered index here. It works so far for me.
    1. On language, well I use the one I know and the one that minimizes red-lining; though I have learnt a lot of Websterisms on this wiki. We always try to use Paizo's spelling for any proper names. I think this is a separate subject though from this forum subject. There probably is a policy doc somewhere too if you are seriously wanting to get a good definition. Here it is I looked it up: under National varieties of English here: PathfinderWiki:Manual of style
  4. Simply, because there are specific chunks of Avistan already called out above.
  5. I am unsure about removing the Index title as it breaks up the page of navboxes. It is a long way above the box though which looks odd.
  6. Ta
  7. Agreed and deleted
  8. Yes alphabetical here is weird - it seems natural to start local and then go wider. Hmm, it does break the rule but both of us have done this section instinctively this way.
  9. Excellent and saves a lot of time - thanks
  10. Oui je comprends

Great re index guide - thanks

I will push on a bit - you'll see the beginning of some [...] which I am unhappy about but I'll consider that issue later - good comments above.

One of these days, I'll figure out the best way to refer to previous discussions without swathes of quotes.

  • Alchemical items: My suggestion here wasn't that "alchemical items" shouldn't be their own subcategory, but rather that "Alchemical item" was "too wordy" for a subcategory label - it, along with "Magic item" duplicates the word "Item" from the header already. I agree that "Alchemical item" and "magic item" are the terms that roll off the tongue when we're typing about them, and I agree that "we have existing pages for those exact phrases", but I find the non-standard usage ("Alchemical ITEM" vs. "Technology" instead of "Technological ITEM", or "Magic ITEM" vs. "Other" instead of "Other ITEMS") to be annoying. I'd rather just see subcategories of "Alchemical", "Magical", "Skymetal", "Technology", "Weapons & Armor", and "Other". If we have to use [[Alchemical item|Alchemical]], I don't see that as a big deal.
  • Alphabetical vs. Locations: We agree that Characters should go first. We agree that subcategories should be alphabetical. But, for location, I think "bigger land" to "smaller land" to "weird things" makes more sense, like you're viewing the story from afar, and then zooming in on narrower locations (which, funnily, is the exact opposite of your suggestion, being to start local and expand out, though I agree that that ordering would fit more with "planes being at the bottom"). So, there wouldn't be "Other areas of Avistan", because "Avistan" (being the continent) would always go first. For Reign of Stars, I'm seeing it organized as Golarion (biggest), then Avistan (continent), then Andoran, then Numeria (alphabetical parts of Avistan), then The Great Beyond ("weird things"). I think I'd be fine with "smaller to bigger" (per your suggestion), but only if we could get rid of "Other areas of Avistan" and just let it be implied (like "Golarion" would usually be implied, or we're not labeling "The Great Beyond" as "Other planes than the Material Plane" or even including the Material Plane by default).
  • The index header: It's a long way from the navbox because navboxes are designed to take over the full width of the page - it'll always fall below any infoboxes, regardless of what's above it. There's no way to get the Index header "closer" to the navbox unless you add more stuff before the Index header (like chapter listings, or a chapter-by-chapter summary, etc.). Because of that, and because the navbox already has a header labeling it an index, I don't think the article header is necessary.
  • Everything else not mentioned: Looks better, agree, will copy into The Lost Pathfinder eventually, etc., etc.

Fired up another Workshop thread about non-breaking spaces to avoid disrupting this thread.

  • Alchemical items: Well I managed to miss the main point completely then - good point and changed. I am also going to consider incorporating 'Skymetal' in 'Alchemical'
  • Alphabetical vs. Locations: I accept your compromise: I'll lose the 'Other Areas...' but keep the small to big order which makes more sense to me, rather than starting big, going smaller then going colossal.
  • The index header: As it looks daft I'll remove for now. I'll jot down a worry though that, as we already have 3 navboxes on this page, we may end up with them all abutting each other. Some distance between, or a header, would help break up the monolith as the 'Chronology' header is effectively doing currently.
  • Standardization: in this vein I have been through and checked we have just one space between the sections to make it easier to read and have placed all parenthetical information in italics: it wasn't before but mixed case.

Nearly finished with what I envision for the "Guide to index writing" on User:Morbus Iff/Sandbox/Indexes.

First draft of "Guide to index writing" is finished: User:Morbus Iff/Sandbox/Indexes.

A little behind in reviewing currently and want to push on with Reign of Stars but will have a look at the new guide soon. In the meantime, two inconsistencies have crept into the aforementioned index for which I'd appreciate advice please about which way we should standardize to avoid subjectivity and inconsistency:

  • for the animals and vermin section, instinctively I placed 'fire ant' under 'ant, fire' yet, similarly, put all the other variants normally: river rat, river crocodile, etc., even though behind the scenes I have [[crocodile|river crocodile]] coded.
  • Parenthetical data: some are getting coupled with the internal blue or red link [Cheliax (Chelish)], while others are not linked and appear as standard black text [Erastil (Old Deadeye)]. All four terms here appear in the text. Obviously, where the parenthetical terms are distinguishable, as for ethnicities or languages, each term is individually linked.

I have changed mind re formatting again: now I am explicitly showing the entity referenced in cases where the novel does not mention it, but where an {{unnamed}} template can be used, rather than hiding it behind the [[...]]. Hopefully, this avoids confusion on behalf of anyone clicking a link and ending up at a page with no explanation as to why they have been so redirected. This new way also has the advantage of keeping alphabetical order.

So I have added new explanatory text to the top and this is the new construct:

* [[robot|''"metal men"'' ⇒ robot]] {{unnamed}}

and where the actual entity should be italicized:

* [[portable hole|''"portal to a pocket dimension"'' ⇒ ''portable hole'']] {{unnamed}}

Better? yes Best?

(The 'implies' symbol is actually an html code [& rArr ;] but I cannot get it not to render even with pre or nowiki)

Try &amp;rarr;
  • ant, fire vs. river crocodile: I would keep it as "fire ant". If we start going down the "ant, fire" route, it brings into question a ton of stuff, like whether names should be "Jeggare, Varian". Existing-factors-wise, I would take a look at the "index" in the Bestiary's as guidance: the "Alphabetical listing of monsters" in Bestiary I lists "Planetar (angel)" and "Astral deva (angel)" even though the page entries are entitled "Angel (Astral deva)". One might say those are "unique names" compared to "fire ant", to which I'd then point out the same thing for "Dire gorilla" and "Giant spider". They're alphabetized as such, even though their page entries are of the form "Spider, giant".
  • Parenthetical data: Never linked if it points to the same place as the non-parenthtical term. For me, the lack of link (and coloring, etc.) is itself a stylistic indicator of the canonical term vs. the slang, or synonym, or inference (which is why I'm not a huge fan of linking the inferences, as you've done in the latest version this morning). The differences in style break up the index visually and make it feel less like a giant link dump and more like a list of links with annotations. They give anchors for the eyes.
  • Arrows and inference: I don't mind the arrow (but I like → (& rarr;) better because it's less "crowded" and "dense" on the small font size). I also like the side-effect of getting the inference alphabetized inline. But, I'm not a fan of linking it (I'd prefer metal menrobot), and I'm slightly cautious of overexhuberance for "every unique phrase possible" (like "metal men" vs. "terrible metal men" unless it is very clear in the story that "terrible" means a different type of metal men, vs. just a really scary one).

Right - like all these points so will incorporate - many thanks. On your very last point, I think that is a product of doing the index on the fly which is unusual for me - normally I finish the book then create the index. But we are learning so much we may get quasi-duplicate entries - we can tidy them up if needed at the end.

  • Different colors for location size: Funnily, I was thinking the exact same thing! We'd need 5 different greens (minor settlements, major cities, nations and regions, continents, "Golarion") and then another for The Great Beyond? (This would be the only "multiple colors in one section" I would support, and only because it's hues of a single color; I think the changes you made to "Other" in Reign of Stars is getting dangerously close to "clownish", similar to Oznogon's initial example above - the colors just don't work well together. Loud, garish, and ugly.) Fiddled around with trying to find five (or six) good muted greens without much luck.
  • Text in double quotation marks...: I grow and shrink my browser window depending on the needs, and on my Downstairs Computer, the added text in the header wraps by a single word, which makes it look silly. Do we need it? Can we shorten it?
I notice several astronomical elements listed under the Great Beyond subheader, which is inaccurate. The Great Beyond is specifically the various planes; all planets, stars, etc. visible from Golarion are also on the Material Plane and shouldn't be listed under that header any more than anything else appearing on the Material Plane.

Fleanetha: all comments on User_talk:Morbus Iff/Sandbox/Indexes have been addressed there or here.

I definatly agree with the decision to remove the death template. When Dave Gross shared the Prince of Wolves index on his Facebook page, Chris Jackson mentioned including the deaths for the pirate promise one was a bit spoilery in one of the comments. When I started the the first indexes here I had a few goals 1) to remove a number of pages from the "pages without links" special page. 2) to assist in future page writing when one can go into the "what links here" link and find more sources. 3) if a reference is made in passing about the being a lich like the whispering tyrant, the reader could go to the index page and find the link to whispering tyrant, even if the page is actually titled with his name. Having spoilers in the index kind of hinders number 3

Busy week and catching up on the comments here and elsewhere. Thanks for updating the help page too. I have updated Reign of Stars with all the recent agreements. Re colour, I think we just need to distinguish cities from nations as per the infobox colours, so just two greens needed, plus I use grey for the planes as that is not particularly garish and again matches the infobox. In that vein, I am unsure about splitting smaller settlements from larger - it all gets subjective, so a simple alphabetical ordering of settlements, then of nations seems better to me.

I agree with Fleanetha on settlement sizes. Also, while there's not really much precedent for it, they can potentially change.

Updated all examples and existing indexes with three location colors. Added the following to docs:

  • When using a settlement or city as a subcategory, also specify its nation.
  • For locations smaller than a nation, use background color SpringGreen.
  • For locations larger than a city, use default background color PaleGreen.
  • For locations larger than Golarion, use background color Gainsboro.

As for settlements, the only time I would use them is if they were something even smaller within them, like the name of a pub or a well or whatever. If it's a just a one-term mention of the settlement though, aye, they'd be classified under their nation instead. You can see some examples of this for The Compass Stone at User:Morbus_Iff/Sandbox/Indexes.

So, finally finished reading the novel Reign of Stars and creating its index, apart from one last look at the unknown elements - I can certainly do a little better around the Council of Captains.

Morbus Iff, I have made a few small changes as I wrapped this up - if you like them then can you incorporate on the proto-help page please? But with a whole novel and some other works I think we are now in a position to make that help and the standard templates 'live' as a formal modification to the Pathfinder Wiki. Of course, there will be small changes needed as we hit 'special' problems associated with future books to be indexed, but I am sure we have a 'Great Fundament' (sorry) on which to build.

Lots of us have added ideas and helpful updates but a special thank you to Morbus Iff for starting this on 7 March and leading us through what, I think, is a really impressive improvement to our wiki and one of the most collaborative update programmes yet, especially as we are all building on Oznogon's vast improvements to the template structure and the ease-of-use amendments he has made recently.

Would someone check out my first attempt at one of these for Lost Treasures which I currently have at User:Cpt kirstov/sandbox? I want to make sure it looks ok before I move it to the product page, as it had some formatting issues when viewing in preview, and I was messing with it for a while.
I thought we were only going to use these for fiction...
I am very far behind. But, not dead! (Yay!) I will try to catch up soon.

I think the index format could be used for any publication, personally.

Alright. I'm gonna try to catch up here.

First off, let me thank Fleanetha for emailing me to make sure I was alright after an extended and unanticipated absence. Long story short: my wisdom teeth never came in when they were supposed to. Until they did, when they weren't supposed to. Having all four teeth yanked out at age 37 is considered "major" and "you idiot, you should have done this sooner" surgery, so sayeth my doctor. I failed my save, and the recovery did not go smoothly. I've turned the corner though, so yay.

Fleanetha: In your last message, you note that you made a few small changes to Reign of Stars that should be considered for the proto-help page at User:Morbus Iff/Sandbox/Indexes. I confess that I can't find them in the diff of the page from April 12nd to now. On a related note, will you be able to move the proto-help into the wiki's formal documentation? I don't know exactly where it belongs.

Cpt kirstov: Took a look at your attempt. Some notes:

  • I question the use of "Humans" as a header vs. simply "Characters". It would make sense, methinks, if there was a counter-category to Humans, like "Characters" (for everything else) or "Elves" (for a similar girth of names) or something. But there isn't one, so the necessity of distincting "Humans" instead of "Characters" seems moot. Also, "Humans > Races" should be handled as "Creatures > Humanoids > human (Ethnicities: ...". There are examples of this on Reign of Stars and my in-progress index in User:Morbus Iff/Sandbox/Indexes.
  • "Named Dragons" vs. "Dragons" (et. al.): Not a fan. When adding terms to the index, non-proper terms should always be lowercase ("air elemental" instead of "Air elemental"; "crystal dragon" instead of "Crystal dragon"). By doing this, when a named persona DOES come along, it becomes distinguished already simply because of the capitalized letter, removing the need to have "Named" and unnamed sections. As for the singular "Named" section - we don't have any further information on their creature taxonomy besides their names?
  • Lowercase vs. uppercase: As mentioned above, just again: most of these terms should be lowercased.
  • Alphabetize subsections unless called out in the docs: Items > Artifacts should be first.
  • The Location subcategories should be colorized per size. Valid colors in the proto-docs.
  • There are a few other minor errors here and there (a few misspellings, like "anitmagic field", some misalphabetizations, like "orb of dragonkind", a few oddities due to template complexity, like "Lake Hound", et. al. being in an unnamed category, etc.), but I don't want to beat it up too much: you've got the right idea, and certainly the right depth to the index.

Good stuff!

Well, I'm definatly glad you've turned the corner in your recovery!

I'll try to answer the points brought up in the same order: First Yoda8myhead:

  • Just fiction vs everything - The opening entry of this mentions chronicles books, so I figured it would be for everything. Considering we are putting together a "how to" page on it, I would hazard that telling someone "for fiction the index is a clean looking table on the product page, but for everything else you need to look to see if there is a /Index page for the product" would be confusing to a new user.

Morbus Iff

  • "Humans" as a header vs. simply "Characters" - I think it should be changed to humanoids instead of humans now that I think about it, as they are basically PC races. I didn't like the term "characters" for chronicles books as only 3-5 of those 100 plus names would be considered characters in the way you split them up for fiction - they would all be listed in other charater, and none in significant characters, in which case why split them up at all?. Most of them would just be considered name drops, mentioned once or twice, and that's it. I also didn't like the term "characters" because that would mean that the named undead, outsiders, and dragons would also be characters, sometimes more so than the humanoids (the name mentioned the most often in the entire book, is Mengkare). These I felt belonged in the creatures section. As I was making notes on the spreadsheet when I read the book, I wanted to keep as few notes as possible, that way if I needed to a search and replace or reorder I wouldn't accidentally leave behind columns of notes and have them on the wrong person/thing in the end.
  • I'm fine with combining "Named X" and "X" I just originally had them in the character section as noted above, but felt they fit better in the creature section... since I had "Outsider named" as my notes for them, when alphabetizing, they all auto-sorted into different groups, so I kept them that way.
  • Lowercase vs. uppercase - yup, Most of these were copied and pasted directly from the PDF, so they got whichever capitalization Google sheets recognized the fonts as having. I caught a bunch of these when I was converting it to wikitext, but there are some I missed.
  • The Location subcategories - Thought I had done that... I took the colors directly from the sample blank index in the help... i'll take a look at them. This was also an issue on how I take notes when indexing - for the first 10 pages or so I had all of the locations in a locations heading, but with no notes on what subheadings they would be in. This was also the hardest section for me to do, as many locations do not have country/city information laid out for you, and as this had already taken a week to index as it was, 1) I didn't feel it was necessary to look each up if the book didn't state and 2) there are a lot of countries and regions covered in chronicles books like this. I struggled with how many should receive categories, and how many should be just put into "Misc" field... I decided any location with less than 5 links would not get its own field. Otherwise the location box which is now 19 groups, would be almost 30. and I thought that was too many.
  • minor stuff - Most of this is copy/paste errors - Orb of Dragonkind originally had a space in front of it, so the google sheets alphabetizing put it in front, so I ended up doing that one by hand at the very end, and was rushing to finish before my fiance's father got into the airport.

Random note:

  • I'm not a big fan of having notes next to the links. Some of these the notes would be almost all of the information we have on a person. The only time I really feel they should be necessary is when we strip an honorific from a name.If someone wants to know what kind of outsider a name in the outsider area is, Jhavhul for example, they can either click the page for blue links, or request for a red link's page to be made (although it seems the 'request a page' link is no longer right in your face on the front page)

Great work Cpt kirstov and you easily take the crown for the largest of the newly formatted indices. I'll weigh in with some comments too as you requested.

  • Scope: agreed they work just as well for fiction as non-fiction.
  • 'Character' question: agree totally that 'Characters' is a fiction-oriented phrase and has no place in non-fiction. Remember we are trying to match the sections in these indices with the wiki's category tree and infobox structure, so we are splitting off named people from generic creatures. I think if you keep that in mind it'll be simpler to decide where elements should go. Re nomenclature, let's keep it simple and use 'Inhabitants' as we do in the category tree. Then all named creatures get moved up into the blue section at the top and creatures remain in the pink section. This will also mean you can adopt standard 'Type' naming for the creatures as appropriate: humanoids, outsiders, undead, etc.. You can also then adopt sensible categories of inhabitants, like Pathfinders, as you have already.
    • 'Races' section could then be deleted as the contents are subsumed elsewhere if you adopt the above ideas. Have a look at Reign of Stars for dealing with human ethnicities
  • I agree with all of Morbus Iff's comments above and am also glad he is now on the mend.
  • Try to italicize spells, magic items, ships and artefacts as that is how they appear in the books and elsewhere on the wiki
    • ships as a section can go in items rather than the scrum at the bottom
  • To save space, an element that is a title doesn't need to also appear in the listings - so Hell is called out as a separate section but currently is also in the Great Beyond section. Similarly Absalom, Mendev, etc.
  • Finally, I agree about notes in the indices - they do look ugly - but I cannot think of a better way of doing it. I toyed with footnotes and maybe that is better? Any other ideas?

Re those last few changes, you stretch my memory. I also can't see now anything that isn't in the User:Morbus Iff/Sandbox/Indexes example. I did change the text at the top about significance but that seems to be updated anyway. Anyway, you'll see we have a new help page this morning.

Good to hear you're on the mend, Morbus Iff!

I agree about notes in the indices - they do look ugly - but I cannot think of a better way of doing it. I toyed with footnotes and maybe that is better? Any other ideas?

What function do the notes serve? If it's to provide context for the citation, like

"Whispering Tyrant" → Tar-Baphon

it serves as a useful, glanceable reference.

If it's to fill in that we're guessing what something in the book is, like

"Using another minor spell, I was able to pull my dagger" → mage hand (unnamed)

I'm not sure it's worth cluttering the index. It wouldn't appear in the index but would remain searchable if it was inside an HTML comment:

<!-- "Using another minor spell, I was able to pull my dagger" --> mage hand (unnamed)

Footnotes using <ref> could also work if we want the notes to appear on page, just not in the index, but that would still add superscript references as clutter.

Oznogon: I believe the notes they're talking about are most evident in the Characters section of Reign of Stars - the bracketed hints of what something is, vs. the inferring notes you quoted from The Lost Pathfinder.
I agree that notes and non-links in these indices should be hidden in HTML notes. This way they're there for when a potential editor wants to expand upon a red-link or existing article, but not cuttering the thing up. They're really unsightly and make the index really hard to read.

As this seems to be the subject of the moment, let's do a summary of where we are. There are three types of unsightly clutter currently:

  1. help for wiki editors: this is information usually in square brackets designed to give any editor of the page in question (usually, but not exclusively, a red link) some useful notes to help them construct / amend the page for the subject: perhaps a page reference to a the main description of the new character
  2. inferring notes: these have been used to give a rational for why a term not used in the book appears in the index. This is usually a direct quotation from the novel as evidence for the spell, monster, etc. that is in the story but not actually named. Note for this use, some lexicographers can't work out what is actually referenced and a third area of clutter has been adopted:
  3. the 'Unknown' bucket: this appears at the base of the index and is used to collect information about elements that are in the story that are not named directly and are either unknown or could be multiple things due to a vague description. Here there is a direct quotation from the text describing the mystery element.

This clutter does aesthetically spoil the new index format and, I agree, it also makes them harder to read. However, I think the solution to each one of these may be different.

  • 1
For instance, HTML notes for 1 are definitely not the way forward - we might as well put the data on Page no one ever reads. How would anyone know to look in the index code for such information - at that point it is just not worth doing them. Type 1 has been seen (Yoda!) as been one of the more useful things an index can provide, which is one of the main reasons I was loathe to do away with them in this new index format (see many comments above). So I think here the currently viable solutions are: delete entirely (a shame) or footnotes. So footnotes gets my vote currently.
  • 2
We spent a lot of time discussing these in evolving the new index format (see above). Unfortunately, I think this is the area of greatest reduction of readability. The reason for putting in a quotation is to show we haven't just made up a link and, also, so that someone might correct it if the attribution is wrongly made. Maybe here a simple page reference would suffice and that could also be hidden, as it is not needed for anyone but the very curious. Even if a fireball is not mentioned in the text, its effects are pretty obvious and its inclusion in an index is immediately understood without explanation. This is also perhaps of the three, the biggest candidate for just deleting the information for simplicity's sake. We also have the very useful (unnamed) template which gives a clear indication not to go searching for that term in the book. So I am thinking the unnamed template plus a hidden comment with just a page ref may be the best way forward here.
  • 3
This is my least favourite of the three as it looks particularly ugly and can get very large. I have already tried adding this information to footnotes, so that you'd have the Unknown section with just a trail of footnotes in it with the detail at the base of the page. However, that did not format correctly at all, so I gave up. Maybe we need to retry that? In essence, I found that, despite the width of the column, the wiki would only allow about 5 references in a row before line breaking - weird. I think we cannot delete this information - just because I cannot determine what a large ball of fire created by a wizard and sent via a small pea sized seed is, doesn't mean I should just ignore it and omit from the index. Another wiki editor might very quickly know what it is and update the index. So here, I might redo the footnote method and one of the more technically minded editors might spot the problem and be able to fix it?

Finally, I am loathe to adopt any solution that causes a lot of extra work, as these beauties take a lot of effort already to create; but are there any other viable options from those above? I might experiment later too.

Personally, I don't like any of these showing up, but I'll throw out more detailed thoughts below:
  • 1 This is the both the most useful and most aggravating of the types. I can see it being useful, but also causing issues down the road. I think this is best used for when you need to change a name from what is in the text as I did when I Changed 'Lictor Dilavos' to Dilavos [hellknight lictor] in the index. It tells the reader that the name was changed, and gives a bit of background. I think anything more than this can be dangerous in the index. If you have a sentence or two, you might as well write a third and make the page, or add your notes to the page with the ref link and save it as a stub. When someone is creating/editing a page from the link, they have to go to the source material anyway to get page numbers to reference, so you aren't really saving them time by adding the notes, and you're kind of doing them a disservice. Once they create the red link, they would have to go back and remove the notes from all of the indexes, causing page creation to take more time, or risking someone reading the note, getting enough information, and leaving without seeing the other person's work.
  • 2 and 3 go together for me. I don't see the 'end user' using these at all. In asking myself 'why would a non-wiki editor use an index?' The answer I give myself is 'to find out what a term mentioned in a source is/does. But for inferred or unknown elements, what it is/does is all that we know about it, so the reader wouldn't want it on the index. While some inferences are easy, such as 'house drakes' being Pseudodragon even that inference caused by the OGL has caused discussion on the message boards (at least 2 threads have opened up since Lord of Runes came out asking what a house drake was). In short, these create extra work for the indexer and article writer alike, without helping the reader, why have them?
  • I know it was mentioned above that when I strip a title from someone, the title doesn't need its own link in the index, I disagree. For things like the Ruby Prince - I never remembered which pharaoh his real name is, because its barely used when it comes up in novels/modules/adventures. I do think these should be redirects if not their own page. Same with the 'house drake' I mention above. The first reason is that the indexer may not know the OGL name for a creature, as pointed out by the house drake threads I point out above. The second reason is again 'how is a reader going to use this index?' is the reader of Lord of Runes comes looking for what a house drake is, and tries to use an index that has 'Pseudodragon', but not 'house drake', then the index has failed them.

I think all black text on these indexes that these notes cause should be used sparingly, and be under 5 words at any given time, otherwise they just create more time wasted for the indexer. As it is, the Lost treasure index took me over a week to complete, If I had added notes, it would never get completed, because I would give up around the six week mark. My limited time is what prevents me from writing many articles as it is. Doing things that take even more of that time away from the wiki with little benefit to it are wastes in my opinion.

I have set up a sandbox here where you can see what the changes of decluttering look like as was discussed above: User:Fleanetha/IndexSandbox. By using the 'diff' feature you can see the index change as Types 3 then 1 then 2 are decluttered. The original is here for comparison: Pirate's Promise.

I agree with Cpt kirstov on just about every point above. Seeing the footnoted version in your sandbox, Fleanetha, I have to admit I like it a lot. These indices are always going to appear on Real-world POV product pages, and those tend not to have many, if any, references. The only change I might consider would be to rename the header from References to Notes but that's a minor issue, and one we're inconsistent about elsewhere when we have both footnotes and citations together.

It's possible to have multiple groups of references on a page by using <ref group="groupname"> to cite and <references group="groupname" /> to list the references. See User:Oznogon/IndexSandbox for an example and Extension:Cite#Grouped_references for documentation.

Ok, both of these I've made I've screwed up and caused me to fiddle with for hours. what have I messed up for the one in my sandbox

Edit: Never mind - mismatched brackets - Fixed it, just need to check spelling on a few links before I put it up
Also, the novbox has a limit of 20 groups/lists. If you try to define a number 21, it doesn't give you an error, it just doesn't display. This forced me to put some locations into the Misc Golarion section that would have their own grouping. This did not display an error, it just didn't put the data into the displayed version of the index

Yes, I have hit that limit too especially as I try to leave a gap between line numbers so I can more easily insert another subject in between if it becomes necessary, without having to renumber everything below it. It would be useful to get a bit more headroom, but I do not know how to achieve this. We must also be careful too not to let these indices become too bloated with rows, I think, meaning some judicial consideration of what really needs to be broken off as a separate subject row. I shall add a comment now to the help page so people know of the current limit at least.