Updating IFWiki

I’m not arguing for anything in particular here, just thinking about how to make things work.

If we were to go the route of de-emphasizing game pages on IFWiki, one question becomes, what do you do when a game is mentioned on IFWiki? (For example, on a competition page.) Just make the game’s title plain text, with no link? Put in an internal link, but don’t put a wiki page at the other end? Or link to the game’s IFDB page instead? Then the person editing the wiki would need to look up the url for the game at IFDB each time a game is mentioned, instead of just typing the title in brackets. I wonder if there’s a way to shortcut that. I guess you could have a template that would automatically search for that game on IFDB, but that might be more annoying than helpful.

If some game titles are internal links and some are external links, is that going to confuse people?

I guess we could move in the direction of linking to IFDB once when a group of games is listed. If there’s a list of games authored by a particular person, you could link to a search for that author’s games on IFDB, and don’t link individual game titles. (Or maybe, in that case, you wouldn’t need to list the games at all.) Or if there’s a list of games in a competition, you could link to the competition page on IFDB.

2 Likes

When you talk about game and author pages being more like Wikipedia pages, are you suggesting that they would have different kinds of information than they currently do? Or would they have the same types of information, just in a different form? I’m not quite following.

I’ve slept on it and realised this too… and the same goes for the author pages. The answer maybe is to have minimalist pages for both. They could be linked together with automatic reciprocal links to help keep them updated. They could have automatic links to IFDB/CASA (search links and/or based on manually-added IDs).

I agree with what I’m sure he’s saying! The current game templates make the game pages look hopeless and too much work to improve. I think by “like Wikipedia” he means more free-form text.

IMO, the deepest problem this thread is revealing is how hard it is, culturally speaking, to delete anything, especially from IFWiki, but also from any public IF database.

For example, consider the IFWiki page about interpreters. Do you want to know the best interpreter available for Palm? Pocket PC? Symbian? You wouldn’t dare delete any of that, would you?

Half the interpreters on that list haven’t been updated in years, and are not remotely good choices for playing IF. But who has the temerity to delete an interpreter from this table? Not I.

Or consider @StJohnLimbo’s big list of things IFWiki is (or should be) great at. People often forget, but IFDB has pages for competitions, meetups (“clubs”) and a “download adviser” that’s intended to tell you the best interpreter for your preferred operating system.

The IFDB “competitions” page is pretty good; it was certainly updated faster than IFWiki! (Remember, this thread started when we noticed that nobody’d even remembered to create an IFComp 2021 page until this week.)

By comparison, the IFDB “clubs” page is pretty bad; it contains 13 clubs in all, and still manages to reference a bunch of defunct clubs. But are you sure they’re defunct? You’re not gonna delete a whole meetup, are you?? (IMO, this problem would be just as bad on IFWiki.)

As for IFDB’s download adviser, it’s a mess. It recommends Zoom for macOS, which doesn’t work on modern versions of macOS, and WinGlulxe for Windows, and it lists dozens of operating systems, most of which are no longer available. I’ve promised to work on it soon, but … what is the right interpreter to recommend on Windows 11? (…on ARM?) Could we just delete the download adviser, replacing the whole thing with a link to Lectrote??

As for authoring systems, IFWiki’s “authoring system” list includes a summary at the top:

The most commonly used (and talked about) systems appear to be ADRIFT, Alan, Hugo, Inform 6, Inform 7, Quest, TADS 2, and TADS 3. The newest authoring systems are ThinBASIC Adventure Builder and RAGS (released in 2006), and DreamPath (released in 2007).

This list is archaic. I bet IFDB could do better just by reporting which dev systems had released new games in the last year (or new good games, which we actually know about).

But if we did that, would anyone delete the IFWiki summary of authoring systems? (Or even update it?) I wouldn’t, that’s for sure…

3 Likes

I agree with the gist of what you’re saying here. For example, someone took the trouble to cut and paste the 2009 version Ron Newcombe’s Inform 7 for Programmers onto IFWiki. Despite thinking it’s not a good use of a wiki to cut and paste other people’s lengthy documents that are available elsewhere, and despite the 2009 version being out of date, I didn’t feel bold enough to delete all the out-of-date pages. I just added an introductory sentence linking to the more recent version elsewhere.

If something is not available elsewhere or should be archived for some other reason, it would be possible to keep a record on the wiki but separate from the main, up-to-date material. So, with the Inform 7 document above, it really just needs links to the 2009 version elsewhere, maybe with an upload of the PDF. With your examples, all the interpreters are probably historically interesting so should not be deleted entirely, but it would just need to be made clear which are out of date, which are useful for which purposes etc.

1 Like

I mean different information, and not necessarily the same structure of information for every page in a given category (that’s what databases are for.)

Look at IFWiki’s page on Galatea. There’s almost nothing there that isn’t on its IFDB page, and nothing that tells you how significant it is in IF history.

Look at Wikipedia’s page on Galatea. That’s much more informative and enlightening, and uses the strengths of being a wiki page rather than a database entry.

If you asked a member of the IF community to talk for five minutes about Galatea and wrote down what they said, you’d get something much more like the Wikipedia page than the current IFWiki one. With IFWiki as I’d like it to be, you wouldn’t have to collar an IF community member to get that information. And you’d have that resource for any IF work, not just ones that are “notable” by Wikipedia’s somewhat arbitrary and highly variably-enforced standards.

6 Likes

I think IFWiki should have the confidence to operate on a sort of “meta” level where it actively tries not to replicate anything that is or should be elsewhere. I think that would entail some deletion of content (although not deletion of all game pages… I agree now and feel like such a Philistine).

So for games, it should aim to have links to IFDB, CASA and elsewhere, but not links to reviews (for example) if those belong better on IFDB etc. If IFDB or CASA has an API maybe it could automatically take a summary from there (and attribute it clearly).

For documents like that Ron Newcombe guide, it should link to but not reproduce them.

Even uploads for historical interest/archival maybe should be uploaded to and linked from IFArchive rather than uploaded to IFWiki.

With the out-of-date information that is presented as if it is in date, maybe we need to start again at the top of the page and keep the old table (or whatever) at the bottom of the table for reference, maybe temporarily.

This forum as a source of information too, including it’s own wiki posts, so maybe IFWiki should link to relevant topics here, like the big Inform 7 one, Inform 7 documentation and resources, or even smaller ones like List of glulx/.gblorb interpreters. Alternatively, maybe these forum-wiki pages in particular are cases where the forum should bow to the wiki as being the more appropriate place for the information.

That’s a very good question which I deliberately left out, because my post was already very long, and because I admittedly don’t have a good solution myself.

Maybe something like a new minimal template would help, as was mentioned above, which would just contain the most important information (as described by the top-priority items in question 9 in the survey thread you linked to: IFDB link, Title, Author, Release date, and Platform/Authoring system). Ideally auto-generated/-populated.

Basically, what you said in the thread that is, in turn, linked from that other thread:

If we are serious about de-emphasizing the game entries, then such a template could also contain a stub info with a sort of “reverse intent”: something which does not say

“This is incomplete, please help expand it.”

but rather

“This is a minimal game listing, please consider contributing further game information to the IFDB, because we aim to bundle the info in one place.”

I dunno ¯\_(ツ)_/¯.

2 Likes

Yes, hm, fair point (about the interpreters and also in general).

Part of that stems from a dual role that IF Wiki has: it serves partly as an encyclopedia and historical record, and partly as a source of up-to-date, currently-helpful advice and knowledge. Or at least, one would hope so.

For this particular case, maybe one could one add a separate section or table at the top, where only current interpreters on the most widely used platforms are listed.

Yes, to be honest, when I wrote the list above, I had actually momentarily forgotten about the clubs feature. :slight_smile:

Hmm, on the one hand I see the appeal and sort-of-agree about filling a different role/niche.

On the other hand, the structure makes it easy for volunteers to create new pages, because they know exactly what to do and what to place where.
(But admittedly, it is too much at once, which is discouraging.)

The structure also makes some aspects less intimidating, I think.
For example, in the people category, I would find it difficult to write about a person’s contributions in free-form sentences, whereas it’s easier (and also uncontroversial etc.) to add a new bullet point under game/tech/testing credits and so on.

Maybe there’s a way to have the best of both worlds, I don’t know.

1 Like

This is a good point about IFWiki serving a dual role.

What if we put the currently-helpful information on the “interpreters” page (or at least, only include platforms that have come out in the last N years), but include a link to a separate page where we keep the older information, for the historical record?

Also, one challenge of pages like the interpreters page is that it seems like fairly specialized knowledge. Even if someone has been involved in IF for years, they won’t necessarily know all the right information to put in that table. For instance, if you never use a given OS, you might not have reason to know what interpreters are good for that OS.

3 Likes

This is a good idea, and what I tend to do when a page would be too unwieldy with the older information. The interpreters page isn’t that big so you could do that, or just have the older stuff further down the page under a separate heading.

You’re right about the interpreters page in that it’s so technical and daunting to edit. It’s like being asked for directions and saying, “Well I wouldn’t start from here.”

I have to admit I’ve been running a wiki in a totally different area of life for about 15 years which is part of my interest here. I’d love to upgrade the software and add some extensions…

1 Like

But if the pages only duplicate IFDB, there’s no point in them doing so!

1 Like

True.

For new game entries, we could design the new template and/or style guide in a way to emphasize the possibility of free-form text?

Have the minimal template which I described above, and add in an invitation to characterize the game’s interesting features and its contribution to the IF landscape in free text; so as not to duplicate IFDB info or overwhelm the volunteer with categories. I don’t know, maybe that would go in the direction of “best of both worlds” which I mentioned above.

Regarding the people pages, they aren’t and wouldn’t be IFDB duplicates anyway, because of tech credits, review and article credits, organizational credits, testing credits, interview links, post-mortem links and all that. (And free-form entries are already allowed for people even now, AFAIK. Each section is optional.)

1 Like

There’s a good extension called Page Forms that could make it easier too.

1 Like

Another factor to consider is that IFDB is actively being worked on and features are being added. For types of information about games that IFDB doesn’t cover (for example, notable features of a game), it might be worth considering whether to add a field for it to IFDB. I’m not saying that IFDB is necessarily the best fit for everything–just that it might make sense to decide that first, before making major changes to IFWiki.

4 Likes

I searched IFWiki for pages on policy & purpose. This is what I found:

It took a bit of digging to make this (probably incomplete) list. The FAQ is linked on the front page, but again, it’s not a FAQ about the wiki.

I think it would help if IFWiki policy & purpose was more clearly defined on the wiki, and more prominently listed where it might encourage people to sign up and make edits. Some of the above discussion is fleshing out policy/purpose questions. Hopefully this grist makes it onto the wiki itself.

Side note: I couldn’t find any statements on the wiki whether or not game designers are permitted to update pages on their own games or bio pages. I know omission does not mean permission, but if designers are told explicitly they are free to add/update their own game pages, perhaps they’d be more inclined to help on that end of the spectrum.

– Jim

4 Likes

I wonder whether the IFTF would adopt the IFWiki the way they did for the IFDB. It might inject a new lease of life into what for the owner of IFWiki is probably now a chore (I’m just guessing based on things like how long it’s been since the software was upgraded, so could be entirely wrong). The IFTF already “own” this forum and IFDB so would have an interest in sorting out the demarcation between the sites. I wouldn’t suggest this for CASA as it seems to be thriving by itself.

I wrote on the discussion page of IFWiki’s Works style guide about my proposed revamp of work (game) pages.

It’d be cool if people who are interested in working on IFWiki join the discussion there. I don’t know who can authorise this sort of style/policy change, or whether the creator of IFWiki is even interested any more, but if enough active-ish editors can agree on something, that’s a start.

TLDR:

  • allow freeform text discussion
  • keep some formal data, basically what’s in the inset info box and the genre/awards/comp icons, but the vast majority of this either is on IFDB already, or should be, so replace it with a link to the IFDB page
  • nuke “How It Begins”, because it’s terrible

(Also, how do we change “What’s New” on the front page? It looks about five years old. Do you need special privileges to edit it, or am I just not looking in the right place?)

2 Likes

That looks good.

I do think a small amount of formal data is useful – this is what the inset info box is for. I think this can be left as it is now, but with a link to the work’s IFDB page added at the bottom of the box. (While I’m dreaming, wouldn’t it be cool if the info could be automatically retrieved from IFDB?)

From a quick look, I think the IFDB URL uses the TUID. It would be trivial for the IFWiki template to expect a TUID, and to create the correct IFID URL based on that if present. If the TUID is absent then it could (as CASA maybe does) instead automatically create a link to the IFDB search page for the IFWiki page title. The IFDB URL system may have more intricacies than I realise but I’m sure they could be handled.

If we were to add the Page Forms extension – which creates a data entry interface not unlike the one on IFDB – then the data entry form could link to the IFDB search page for the particular game and encourage editors to look there and enter the game’s TUID.

Edit: There’s already a template (Template:Babel) that does something similar to this, but it’s based on the IFID and it seems that the idea is to add it manually to a game page when the IFID is known.

1 Like

What I meant was if the data in the box, like release date and authoring system, could be automatically queried from IFDB, maybe using an IFWiki template supplied with the TUID. But I suppose that data doesn’t change very often.