How should we (as a community) handle MediaWiki


  • Coder

    I've been very annoyed at MW for quite a while now, but I've realized that it isn't something I'm going to be able to discard and still offer a useful hosting service, really.

    So, let's talk about what things are needed:

    • For game owners
    • For a game's power users and/or staffers
    • For a typical game player wiki user
    • For hosting providers like me
    • For game owner-and-hoster-types

    I've worn a variety of these hats and can talk especially about my concerns from the hosting side and potential solutions, and what they might mean for game owners. I suspect most of my options and their effects will be completely invisible from most people, but here's a good chance to speak up about what things make mediawiki a must-have feature for YOU.

    @surreality, @ixokai, and others who have nudged me to consider mediawiki still, please add your two cents. Use-cases, features, things that can be done right, things that can be wrong, etc. are all very relevant to my interests in this thread.

    Other hosting providers? Mechanipus isn't aiming to be competition in this area-- I specifically believe this isn't a viable business model, so I'm gearing this toward establishing the best way to do it as a community so I can put together some comprehensive game-in-a-box options including MU and wiki and forum and such-- either for use by aspiring game-owners; overworked and frantic code staff; naive but powerfully eager would-be hosters; or myself, who is often in all of those categories.

    Things like my wikinewshelp bridge and the like-- we can do this and do it better, and do it more portably.


  • Coder

    I haven't used MediaWiki for a MUSH game since, like, 2007. Wikidot has everything I need, and it's free, and I don't have to screw around with hosting options for it. With creative use of templates, includes and tags, you can do auto-generated RP log lists, faction pages, tutorial navigation, and everything else I've ever wanted to do.

    The only place that Mediawiki beats it, IMHO, is MUSH-to-wiki integration. As @Thenomain mentioned in another thread, you can use the SQL output from MUSH to write stuff directly into MW's tables, effectively adding things through a back door. It's kind of a hack, but at least it works. You can't do that with wikidot, but between in-game "here copy/paste this" commands and fill-in-the-blank templates, it's not been a big deal. YMMV.

    For an example of the sort of MU site you can set up with Wikidot, check out Marvel 1963 or The 100.



  • The Django web framework used for Arx (on Evennia) auto synchs things from the game to the site, and vice versa. I realize this isn't useful for packaging into a Mu-in-the-box scenario but I'm just here to fangirl.


  • Admin

    @Chime said in How should we (as a community) handle MediaWiki:

    I've been very annoyed at MW for quite a while now, but I've realized that it isn't something I'm going to be able to discard and still offer a useful hosting service, really.

    I've used several wiki platforms so far but nothing in-depth enough to warrant having an opinion. Can you give us a brief overview what the reasons you're annoyed at it are, just to figure out what the problem is?

    @surreality, @ixokai, and others who have nudged me to consider mediawiki still, please add your two cents. Use-cases, features, things that can be done right, things that can be wrong, etc. are all very relevant to my interests in this thread.

    Similarly, skilled wiki users - if you don't mind, what are the advantages of one over another for common MU* purposes?


  • Coder

    @faraday said in How should we (as a community) handle MediaWiki:

    I haven't used MediaWiki for a MUSH game since, like, 2007. Wikidot has everything I need, and it's free, and I don't have to screw around with hosting options for it. With creative use of templates, includes and tags, you can do auto-generated RP log lists, faction pages, tutorial navigation, and everything else I've ever wanted to do.

    This is a good point. (And what I'd been wanting people to do for a while, but there was considerable push-back, hence this thread...)

    The only place that Mediawiki beats it, IMHO, is MUSH-to-wiki integration. As @Thenomain mentioned in another thread, you can use the SQL output from MUSH to write stuff directly into MW's tables, effectively adding things through a back door. It's kind of a hack, but at least it works. You can't do that with wikidot, but between in-game "here copy/paste this" commands and fill-in-the-blank templates, it's not been a big deal. YMMV.

    ahahaha

    Okay, I was the one who wrote that stuff, e.g. for The Reach and most other places using it. So I guess it's my fault I'm stuck with this thing. Fair enough.

    It works well enough, but as you say-- it's an ugly hack. MediaWiki should be able to change their internal database structure without warning, and that would break all tools trying to do direct reads/writes of its database.

    It's far better to manipulate MediaWiki through their published API, but MUX at least will need some hardcode changes to be able to do this sanely.

    Note that WikiDot can do the same thing. If we can all agree that we should be doing this via the API and arrange for that infrastructure to work on the MUSH side, then:

    • We can have a MU wiki lib (with version for different MU types able to do RPC calls of various sorts); MUSH is the primary relevant one here, but hey I can probably do MOO too, etc.
    • That lib can have connectors for talking to MediaWiki, WikiDot, and other alternatives in a read/write fashion.
    • MU applications such as WikiNewsHelp, ticketing systems, bboards, etc. can then target that lib, allowing game owners to pick and choose apps and backend hosting independently.
    • That same lib could use local database edits to support existing systems that want to continue doing my particular dark witchery with a local mediawiki.

    WikiDot and MediaWiki have diverged considerably and use different syntaxes, but I suspect most of the same concerns apply as far as player and owner user-cases.


  • Coder

    @Chime The Wikidot API is somewhat limited and requires you to have a Pro account (currently about $50/year). I explored creating an automatic integration for AresMUSH but figured the number of people willing to fork over an extra $4 per month for it was pretty small. Instead I focused my attention on making the aforementioned "copy/paste this into wikidot to make your character page" type commands in the game. (Added bonus - with some configuration tweaks, that'll work just as well for MW.)

    For Evennia, making a MediaWiki integration might make more sense, since it's geared more towards advanced users. But since Ares is intended to be a "MUSH In a Box" turnkey installation, MW just isn't suitable. It's too much of a PITA to set up and configure and maintain (in my experience).



  • I strongly recommend looking closely at Semantic Mediawiki specifically.

    It has a lot more going on under the hood that even I don't fully grok -- but it's worth looking at. (Read: it's worth it for someone who actually knows what's really going on there server-side taking a look at it to see what the possibilities are; I just know what it allows me to do on the user end. I just follow the instructions to install it, this doesn't mean I actually know quite what I'm doing back there.)

    On the user/wiki-admin side, it allows for a lot of things that aren't standard in the box with mediawiki, and to the best of my knowledge are not in wikidot at all either.

    Forms are a big one for a number of reasons.

    They make things much easier on non-wiki-savvy users, for one; it's possible for a user to create a page without a single shred of code know-how with them, and templates can be made fairly easily for just about anything the game needs. (I've been working up some basic ones for things like grid locations, player pages, etc. similar to the ones on BITN's wiki, and when the generic versions are ready I want to have them up where they can be grabbed and shared.) It's possible to enter specific instructions for every step of the process, for every input on the form, with as much or as little information as players or staff may need to ensure the information is correct, useful. It helps ensure it's easy to understand what to do, how to do it, and why it's needed (or even if it's needed or optional). And this is all without needing to know a single thing about wiki code on the player (or data entry staffer) end.

    The extra bonus for forms is that it's possible to set up lists of default allowed values that will appear in the template; while that sounds little, it can be big for things that the MUX expects to appear in a very specific way. Whether something is 'Circle of the Crone' or 'The Circle of the Crone' can make a big difference code-wise, for instance; if it's set with a drop-down rather than entered manually, it's always going to be consistent and there's no need to remember how it's supposed to be done. (Because nobody always remembers. It always gets screwed up somewhere, some time. :( )

    I am also not sure if wikidot uses/allows the use of DPL or not at all. DPL is extremely useful to create auto-populating listings throughout the wiki that massively reduce the need for constant direct human maintenance.


  • Pitcrew

    Magic things MediaWiki does that make it worthwhile:

    Semantic MediaWiki combined with DPL. This is the thing that basically turns your entire wiki into a searchable database. All the fields you expect on a character page -- name, age, height, etc. -- or a log page -- participants, location, date, etc. -- become searchable and sortable properties. This is what made it so that @Tat could make a custom log search function that lets you search by date range, people in the scene, etc. It's what lets out organization pages remain largely untouched, because people can just mark their current or former associations, and we can build auto-generating lists of either that update themselves. This is, IMO, the big huge thing that MediaWiki has on Wikidot. It's definitely not true that Wikidot can do all of the things that any game wiki would want to do, because both of my games -- X-Factor and Lost and Found -- use extensions and functionality that Wikidot doesn't offer. Of course, do you need all those things? Not necessarily. Will you become pretty much addicted to them if you start using them as a wiki admin? Probably.

    The other big one for us is Semantic Forms. This is the answer to every player who goes "oh I'm so bad at wikis, I don't want to make my page, I just break everything." Build a template, then build a form to fill out the template. It's a lot more user-friendly than the autofilled templates, it's harder for players to break, and players also have to work a lot harder to change up the page template if you're a game has a standardized template you don't want to change up (which both of mine do -- I don't care about player creativity here, sorry).

    Again, do you absolutely need all these things to house a functional game wiki? No. Does it make the experience better both on the admin and user ends? IMO, yeah. It's incredibly useful for organizing plot pages -- you can autofeed logs that are associated with the plot, add people who were on the plot so that the plot shows up on their character pages as something they participated in, etc., etc. If you're a game that has a lot of plot threads, it can be incredibly useful for keeping things organized.

    And hey, I know that I suggested a few of these things to @surreality and now she's in love with them as much as I am, so clearly they're awesome. :D I bet I can summon Tat to this thread to expound at length, too.



  • @Roz Please explain the things with semantics other than forms. Please? Because I am not clueful enough to explain those -- and they're worth explaining.

    I am specifically wondering if they are set up in a way that might make the integration easier, since it has specific property definitions.


  • Pitcrew

    @surreality It's probably easier to just show you.

    Basically semantic properties act like database entries, allowing you to then search by those things. You can do this to auto-fill a list, as in our census page or our organization pages, or you can make a searchable form, like our log search.

    I can use templates to assign semantic properties behind the scenes (IE, a player never has to know that it's being done or how to do it), and then I can use those semantic properties to create lists of just about anything.

    I will probably never do another game without MediaWiki because of the power of this single extension. I spend a lot of time retroactively kicking myself for not doing it for the first game I built a wiki for - we filled out a lot of this shit by hand! We used to keep a list of character birthdays - now I can generate one automatically in like 5 seconds.

    Want to see characters by height? Sure, no problem. How about every plot an NPC's been involved in? Yup, we can do that. What about every log involved in a plot? Also done (for example).

    It turns your whole wiki into a searchable database that /players don't have to know how to use/. I'm not actually sure which part is more awesome.


  • Coder

    @faraday said in How should we (as a community) handle MediaWiki:

    @Chime The Wikidot API is somewhat limited and requires you to have a Pro account (currently about $50/year).

    They clearly have more business sense than I do. Alrighty.

    For Evennia, making a MediaWiki integration might make more sense, since it's geared more towards advanced users. But since Ares is intended to be a "MUSH In a Box" turnkey installation, MW just isn't suitable. It's too much of a PITA to set up and configure and maintain (in my experience).

    I'm going to need to do my homework and look at Ares and Evennia in more detail, it sounds like.

    @surreality said in How should we (as a community) handle MediaWiki:

    I strongly recommend looking closely at Semantic Mediawiki specifically.

    Thank you for reminding me. I peeked at it years ago and it seemed like a great direction to go but wasn't really fully implemented at the time. Might be exactly what I'd want to get the most out of MediaWiki...

    On the user/wiki-admin side, it allows for a lot of things that aren't standard in the box with mediawiki, and to the best of my knowledge are not in wikidot at all either.

    Yeah, even my Mechanipus mw setup had a bunch of extensions installed (some custom) and a lot of config tweaks.

    Forms are a big one for a number of reasons.

    Yes! Yesyesyes! I'm very glad you see this.

    I suspect there are a lot of important data-entry things with forms that can be useful even for games with no automatic integration; i.e. DPL views and the like that pull form-submitted data to generate code to paste into the MUSH.

    Direct is better, but even manual stuff can be a big timesaver.

    They make things much easier on non-wiki-savvy users, for one; it's possible for a user to create a page without a single shred of code know-how with them, and templates can be made fairly easily for just about anything the game needs. (I've been working up some basic ones for things like grid locations, player pages, etc. similar to the ones on BITN's wiki, and when the generic versions are ready I want to have them up where they can be grabbed and shared.) It's possible to enter specific instructions for every step of the process, for every input on the form, with as much or as little information as players or staff may need to ensure the information is correct, useful. It helps ensure it's easy to understand what to do, how to do it, and why it's needed (or even if it's needed or optional). And this is all without needing to know a single thing about wiki code on the player (or data entry staffer) end.

    I've seen a large proliferation of copy-pasted DPL queries that don't make much sense, because people tried to move things between games. It's a good idea though, and making that work safely and cleanly in a game-independent fashion as a separate project (think Sandbox Globals Project, but for MediaWikis serving MUSH communities) would probably be a good idea.

    The extra bonus for forms is that it's possible to set up lists of default allowed values that will appear in the template; while that sounds little, it can be big for things that the MUX expects to appear in a very specific way. Whether something is 'Circle of the Crone' or 'The Circle of the Crone' can make a big difference code-wise, for instance; if it's set with a drop-down rather than entered manually, it's always going to be consistent and there's no need to remember how it's supposed to be done. (Because nobody always remembers. It always gets screwed up somewhere, some time. :( )

    Yep.

    I am also not sure if wikidot uses/allows the use of DPL or not at all. DPL is extremely useful to create auto-populating listings throughout the wiki that massively reduce the need for constant direct human maintenance.

    DPL is fairly powerful and critically useful. It's also really ugly and difficult to explain to people. Sanding down those corners and making it accessible in standardized fashion to non-technical game owners will be important.


  • Coder

    @Tat said in How should we (as a community) handle MediaWiki:

    Want to see characters by height? Sure, no problem. How about every plot an NPC's been involved in? Yup, we can do that. What about every log involved in a plot? Also done (for example).

    I've done the latter two with tags in Wikdot, FWIW. Never done the height thing, but then again - I've never had a desire to :) Have listed all characters by faction, though, or by school class (junior/senior/etc.).

    Edit to add: Someone needs to have some Wikidot code skills to set it up (or at one point I had a template site you could clone; I intend to resurrect that after some revamps). But the average player just needs to fill in the blanks. For instance, when you click the "New RP Log" button on the wiki you're presented with a template like this:

    [[include LogInfoBox
    |summary=Log Summary
    |rldate=Day Month Year
    |related=If there are no related logs, put 'None' -- please, don't leave blank! 
    ]]
    

  • Pitcrew

    @surreality I've never staffed on a game that had the game-to-wiki integration, although I have assumptions about how it works and imagine there are some pretty awesome things you could do maybe. I don't know. Can you just slot in stats from the game into a specific property field on the wiki?

    This logs search is a great example of something awesome @Tat did that's made possible by SMW. This org page is a good example of a bunch of different kinds of lists -- currently affiliated characters, formerly affiliated characters, deceased characters -- that are housed entirely on the org template and are all updated automatically based on PCs and NPCs with the org listed on their pages and whatever category they're housed in. On this org page you can see how the plot the org is marked as being involved in has autopopulated at the bottom. This user page shows all the plots Tat has GMed automatically, and this timezone property page can give you a list of users, what timezones they're in, and what characters they play.


  • Pitcrew

    @faraday

    Never done the height thing, but then again - I've never had a desire to :) Have listed all characters by faction, though, or by school class (junior/senior/etc.).

    Ha, well. It's not really my thing, either, but we did used to have a player who kept one manually, because it was their thing.

    That's just an example, though - almost any piece of data in a plot, log, character, user, or NPC page is searchable and sortable. Birthday, date of death, age, plots involved in, logs involved in, plots GMed, affiliated org, previously affiliated orgs, mutations, aliases, the location of logs, the short introduction at the top of the page-- The possibilities are immense. We use a lot of them.

    The first wiki I did had templates like what you're talking about - just fill in the blank. A lot of people did them just fine, but we definitely had a lot more wiki hand-holding prior to semantic forms. Like, a LOT more. We have very, very little now.

    It's not a huge deal if all you're doing is character pages, but if you're also posting logs, it gets really nice.

    Did I mention that forms can autocomplete? So for example, you don't have remember the file name of a character icon. Just start typing the first few letters (we suggest people name their icons with a character prefix) and all the options pop up.



  • @faraday I've had too many users not really be able to handle that kind of template input, not understand how it works and just delete it, or break it.

    Forms can be set to the default or required method to edit the page (the template data) in semantic mediawiki. This prevents the template itself from being broken when entered onto the page, and ensures that the page is consistent with other pages of its type, as that type of page is essentially confined to by-form edits (no freeform editing).


  • Pitcrew

    @Chime said in How should we (as a community) handle MediaWiki:

    I suspect there are a lot of important data-entry things with forms that can be useful even for games with no automatic integration; i.e. DPL views and the like that pull form-submitted data to generate code to paste into the MUSH.

    If you get into Semantic Wiki and Semantic Forms, you don't even need DPL. I think we use it in one location (I'm not actually sure we need to, even - it's a holdover from an older wiki), but for the most part, Semantic actually does that pulling of data better and more smoothly.

    If you're interested in seeing it in action, I'd be happy to show you how to mess around with Special:Ask on our wiki.


  • Pitcrew

    @Tat Oh yeah, I actually forgot that #ask is specifically SMW and we almost never even use #dpl itself anymore.


  • Coder

    @surreality said in How should we (as a community) handle MediaWiki:

    @faraday I've had too many users not really be able to handle that kind of template input, not understand how it works and just delete it, or break it.

    Fair enough. I haven't had that problem, across numerous games. Perhaps since it's a different subset of users, they're just inherently more familiar with wikidot.

    Anyway, I'm not suggesting that text-based forms are superior - or even equivalent - to semantic MW. Not at all. But it's a tradeoff. An easier experience for people editing forms vs. an easier experience for people setting up and hosting the game. If you've already got someone who's effectively a sysadmin and can handle dealing with the hosting requirements and installing MediaWiki and installing the semantic plugin ... groovy. You're already way ahead of the game. But a lot of people don't have that.


  • Pitcrew

    Wikidot is absolutely a fine solution if you don't have anyone who already has some comfort with digging into wiki syntax and learning their way around SMW. But if you have someone who can do that and is willing to, you should absolutely take advantage of it.



  • I'm also reasonably sure that if there's any MUX/wiki integration, both the wiki and the game would need to be on the same server. I mean maybe it could be otherwise, but I don't know how wikidot, which is on its own servers, is going to feel about people having external non-user sources from another server (the game itself) yanking from or shoving to its server.


  • Tutorialist

    @Chime

    So, let's talk about what things are needed:

    • For game owners

    The bare minimum I believe:

    • The ability to decide whether the wiki is open-to-join or requires account creation by staffers.
    • The ability to decide whether the wiki is open to see or only members can see it.
    • The ability to create accounts.
    • For a game's power users and/or staffers
      For Staff:
    • Create accounts.
    • Lock certain pages.

    For Users:

    • Create pages based on games wikipolicy.
    • Upload images based on games wikipolicy.
    • For a typical game player wiki user
      See above.
    • For hosting providers like me
      The ability to say "this monstrosity is too big, cut down your image size". ... I'm not sure since I don't really know what hosting concerns there are other than 'size'.
    • For game owner-and-hoster-types
      See above.

Log in to reply
 

Looks like your connection to MU Soapbox was lost, please wait while we try to reconnect.