Organizing the Theory and Craft pages on ifwiki

IFWiki has a Theory page and a Craft page, with lots of helpful links.

As time goes on and more links are added to these pages, I wonder if there are any helpful tweaks we could make to the way they are organized.

It might be helpful to include more dates alongside the links, so that people browsing the page will have a better idea of how old the information is.

For the history section of the Theory page, I had been putting these links in order from oldest to newest. But would it be better to go from newest to oldest? Maybe seeing the oldest things first makes it look like the page hasn’t been updated in a long time?

Some categories are sorted in other ways, for example, by author last name.

Would it be helpful to put the links in a table, with separate columns for title, author, date, and so on? Sortable by date, or author? Would that make it too high maintenance, and discourage people from adding links?

Would it be helpful to put links to entire websites separate from links to individual articles? Right now they are mixed together.

Do all the categories make sense? Should history get its own page?


Agreed on this; I think a standard format (like Title, author name, date) would be nice. Or…

I personally would find this really useful; I’d love to be able to sort and filter the resources based on date written, system being discussed, etc.

Yes, I think so—or, if going the table route, have a column noting if it’s an article versus a site.

I would vote yes based on how long the Theory page is; breaking the History category into its own page would make the Theory page less overwhelming, and History does kind of seem like its own distinct category anyway.

And then for the Craft page, I think breaking out separate categories based on the system being discussed (Inform/Twine/etc.) and/or the type of game (choice/parser/other) would be helpful. I think a table would work well for this too, since then nothing has to be put into just one category; you could filter for all articles about parser game NPCs, for example.


Thanks for the feedback so far (both here and elsewhere)!

@Jonathan, on pages like this that are basically lists of external links, would it make sense to put the links into tables that can be sorted in different ways? I’m not sure one way or the other. How hard would it be? I also realized that to sort by last name, we’d have to enter the first and last name separately, or enter the name last-name-first, or something like that.

It also occurred to me that we could make links in a particular category (like NPCs) appear on more than one page, if we wanted. For example, NPC links could appear on both the Craft page, and on the NPC page. This is a separate question from doing it as a table, because I think it would be possible to do this with or without a table.


My personal opinion is: List the new entries first.

Not necessary but good imho: Give the history its own page.

I wouldn’t list the NPCs doubly.

Generally: I didn’t know about the craft page and the theory page, but now I like them very, very much. Very useful, not to be read in one shot, but when you need it, step by step.

As a player who avoids jams, comps, tournaments, online meetings etc. I don’t know about a lot of good stuff: IFDB, blogs and more.


Thank you!

I had another idea. Since there’s some overlap between Theory and Craft, maybe we could also have a navigation box that appears on both pages (and also the history page), listing all the subtopics that appear on all of these pages.

Here is an example of a nav box we already have for navigating the interpreter pages. But maybe instead of a row for formats, and a row for systems, we could have a row for theory topics, and a row for craft topics, or something like that.

Screenshot of existing interpreters nav box:

Here is the text of the interpreters nav box, copy and pasted:
By format ADRIFTAdvSysAGTAlanGlulxHugoMagnetic ScrollsTADSZ-code
By system BrowserAndroidiOSLinuxmacOSWindows
Browse Recommended interpretersSearch formDrilldown
Other software Authoring systemsUtilities


I like the box. It looks clean, and there seems to be a precedent.

1 Like

I’ve seen nav-boxes in different wikis. And I like them, I consider them quite useful.

Oh, and using tables seems like a good idea to me.

I’ve added dates to several of the links. We don’t have a consistent format for dates, but I figure the dates are easily revised later if a format gets decided on.

Some of the articles have no dates on them, or the web page has a range of years that seems to apply the website as a whole (along the lines of “copyright 1999-2001” or “copyright 1999-2010”). The lack of dates might make it tricky to sort links by date in certain categories. Maybe for some categories (like history), sorting by date would make more sense, and in other categories, sorting by author would make more sense?

And maybe we need a place to move the old links that might be of historical interest but are outdated from a practical perspective (for example, an old article comparing authoring systems as they were at that time). If we remove the links that are not so relevant anymore, maybe it won’t matter as much whether the remaining ones are in date order or not.


I think that Internet archive’s wayback machine can be abused as dating tool, because the date of capture is recorded, giving a solid terminus ante quem

Best regards from Italy,
dott. Piergiorgio.


In that case, what would be the best way to show that the date is approximate? Would you use the year from the earliest Wayback snapshot, and add “c.” before it, since we don’t know how long the site existed before the first snapshot was taken? So, “c. 1999” or something like that?

1 Like

Seems reasonable to me. Although perhaps “before [date]” (adding one day if necessary) is the most pedantically accurate way to handle the situation. For instance, if you’re looking at this URL for an Emily Short article, all you really know about the article from the Wayback Machine is that it existed in that form by the time that 13:24:25 of 21 December 2001 happened. For all that the snapshot URL tells you, It could have been written twenty years earlier. (In-article mentions of post-1981 games rule that out, but that’s based on internal textual evidence and human reasoning, not the snapshot URL.)

Yes, “before [date]” is a possibility.

Another option: Wikipedia has a “circa” template: Template:Circa - Wikipedia. If you hover over the “c.” a tooltop pops up that says “circa.” I wonder if you could write “n.d.” or “no date” with a tooltip that says whatever information we have about the date, like “First Wayback Machine snapshot taken in 1999” (or you could do something similar with “c. [year]”, or a year followed by a question mark).

Another possibility would be to use an access date instead (“accessed Nov. 17, 2023”) but that seems less helpful for dates that are added long after the link was first added to the wiki, and I don’t know what “access date” you’d use for links that are already dead/archived.


A quick look at the How to Edit IFWiki page didn’t show me any information about use of templates on IFWiki in a way that’s comparable to the Wikipedia template that you pointed to, but I haven’t made any additional effort to determine whether that’s possible. One of the suggestions for further questions is to ask on the forums, so hopefully someone who knows more than me will chime in.

At a lower level, I suspect that the easiest way to do that would be with the HTML <abbr> tag, I think: something along the lines of <abbr title="first Wayback Machine snapshot taken on 21 December 2001">n.d.</abbr> would do the trick.

There are two immediate problems I can see:

  1. If the information is only available from a tooltip that is displayed when the mouse hovers over the abbreviation, then it is entirely invisible to people accessing the page with mobile devices, and (I think) potentially harder to access for visually impaired people using screen readers;
  2. I don’t know whether the IFWiki software provides an easy way for end-users to achieve this type of encoding.

I think that number 1 is the big objection, though: we want the information to be available to users on mobile and who have visual impairments.

I think that you’re right: giving the most specific information available is the best move.

1 Like

Maybe we could put the approximate year (with a c. or question mark) or the “before” date on the page itself, and then in the source of the page, maybe a comment saying where the date comes from. It could be like this
<!-- First Wayback snapshot was in 1999-->
or a parameter (in a custom “circa” template) that doesn’t get displayed. So everyone looking at the page would be able to see the approximate date, but if you wanted to see the explanation, you’d have to edit the page or “view source.”


It’s not a bad solution, but adding HTML comments to the wiki page seems like it makes digging the information about of the page source into an awful lot of work, and makes it hard for people to know that additional information is available in the first place.

I think if the intent is to avoid cluttering the screen with citations, maybe a better option would be to have a short form “best guess” date in-text, with a linked footnote to additional information at the bottom of the page or maybe in a popover?


The feedback I got was that people were in favor of putting history on its own page, so it is now on its own page: History.

There is now a “Theory, Craft, and History Resources” navbox at the bottom of the Theory, Craft, and History pages.

I’ll wait to hear from @Jonathan about whether it’s possible to do footnotes.


I’ve only skimmed this topic but in answer to the technical questions.

  1. It’s easy to create sortable tables (just begin a wikitable with class="wikitable sortable").
  2. We could install a tooltips extension.
  3. A footnotes extension comes bundled with MediaWiki and could be enabled.

My instinct though is that continuing with bullet point lists would probably be the best.

I like the new infobox but wonder whether it might be better for each link to be to a page rather than a heading within a page.

As opposed to tables? Or were you also commenting about footnotes, etc.?

Do you mean each section would get its own page? Or do you mean there would be only three links total (history, craft, theory)?

I just meant that bullet lists seem best. Tables would look nice but be harder for new people to maintain, and sorting wouldn’t add much as the lists aren’t too long and there would be so many vague fields (e.g. date). Tooltips are all right here and there for instructions, asides etc, but here I think would make the page difficult to skim read. The same would apply to <abbr> tags. Footnotes interrupt the flow of reading and I don’t think would be useful here.

I think I’d just prefer not to have those links. It would be easier to maintain if the infobox only linked to wiki pages. If someone edits a page’s section heading it would break the infobox link. Adding or removing a section heading would be easy too, but then we’d need to update the infobox. I’m not aware of any way to update the infobox links (to page section headings) dynamically. A middle ground might be to include a description of the page contents in the infobox.

Are you talking about reading the page source?

Any thoughts on how to handle approximate dates (e.g. if we have a date for the first wayback machine snapshot, but not an exact date for the article)? Would you leave it out, or just put something like “1999?” to show that it’s uncertain? Or “before Nov. 5, 1999” or “c. 1999”? Would there be someplace to explain where the approximate date came from?

My reason for thinking that including the headings might be helpful is that you don’t really know what topics are available until you see them all, and if you happen to be looking at the theory page instead of the craft page (or vice versa) you might not know that the thing you want is on the other page.

I hear what you’re saying about maintenance, but I don’t think these headings have changed in years (until today, when I made a new history page). I don’t think it’d be that difficult keep the navbox updated.

Would this include the heading names? (Not as links, just listed in text?)