Help talk:Dialog

Third-Party Usage
I'm a third-party MediaWiki user and have been looking for something to make editing wiki pages a bit easier. I'm experienced with Semantic Forms, which is a big extension, and recently discovered the FormWizard gadget. Is there any future where Dialog will be usable by third-parties? Perhaps a package one could import and use? Ckoerner (talk) 19:24, 23 July 2015 (UTC)


 * Hi, Ckoerner. Pardon if my answer is a little long; I'd give a one-sentence answer if I had one worked out already.
 * Here's how I've been envisioning the future of these tools:
 * First there's a round of upgrades to the dialog tools themselves, to make them "ready for prime time". I'm hopeful those upgrades won't take too long &mdash; but we'll see.
 * I've always known that once the low-level tools were working, it would be necessary to learn how to use them effectively to build higher-level tools. I've actually started doing that already, at Assistant.  I expect there's a lot to learn about how to build such tools effectively, and I fully expect that from time to time that process will lead to upgrades of the low-level tools (notably, additional verbs for the do action; I've got a few improvements to the edit verb in mind as part of the current set of low-level upgrades).
 * Also, once I've completed this round of improvements to the low-level tools, I mean to start porting the tools to English Wikibooks. When I first started these tools, it didn't even occur to me (though I can only shake my head at the naivity, now) that there would be any call to port them anywhere else; I now have a general outline of what would be involved in such a port, at MediaWiki talk:Dialog/receive, but I expect there will be plenty of kinks to work out of the process as I port to en.wb.
 * It was always clear to me that if I tried to achieve my vision through the standard development process, the red tape and the politics would each be enough to keep it from ever happening (and so together would make doubly sure it could never happen), so I deliberately shunned the standard process &mdash; and I actually think I was right that the standard process would have been unworkable, given how long it's taken me to get this far even without those impediments &mdash; but part of the price of not going through channels is that there's no makefile for installing it. The good news is that extreme simplicity is part of what it's designed for, so "installation" consists (in theory, at least) of importing a bunch of pages in the MediaWiki:, template, and project spaces, installing one gadget, and adding a single line to common.js.  It may actually be easy to do, once I've done it once for the port to en.wb.  --Pi zero (talk) 20:08, 23 July 2015 (UTC)
 * I'd be quite interested in your advice on how to make these tools more friendly toward third-party wikis. --Pi zero (talk) 20:17, 23 July 2015 (UTC)
 * I just read the vision page you and the Dialog installation page. Sorry for not seeing those sooner. It looks like you've put a lot of thought into this. My challenges might diverge a bit from your goals, but I am interested in seeing where you go with this.
 * In my experience the condrum with anything that's not an extension is that it's not packaged easily for distribution elsewhere. Not impossible, but gathering up all the right files can be a little frustrating. I had the same challenge trying to get UploadWizard to work - and HotCat changes too. The latter changes so frequently that third-party use is complicated. I'll update MW and then HotCat will stop working! However, your instructions seem simple enough.
 * I think having more interactive editing that doesn't require much administration would be a great boon for editors. We use a lot of Semantic forms and templates due to the nature of our editors (A wiki inside of a healthcare organization. Not a lot of wikitext love). Most people are more comfortable with common form elements (fields, drop downs, etc.).
 * A total side note, have you thought of making this a VE module? It seems possible, but my understanding is limited. I know that it has a bit of a history, but for some folks it might be useful.
 * Ckoerner (talk) 18:29, 28 July 2015 (UTC)
 * Those two pages (vision, installation instructions) are rather hidden, so it's not remotely surprising you hadn't found them. The vision page I haven't actually linked from anywhere yet, and the installation instructions... well, I really have to have done it all once before I can really have confidence in the process. I see what you mean about diverging a bit in goals.  But yes, what I'm doing and what you're doing may really be compatible with each other despite a few differences.
 * I'm extremely aware that I'm outside the supposed safety net of the official process, and so I'm deliberately designing everything to be as robust as possible against changes to the underlying wiki software. I'm also just one person trying to do all this stuff, so even internally I'm designing it all to be as simple as I can make it; I keep thinking of the old VW beetles, of which it was said that you could fix them with a screwdriver.  As you say, the installation is almost entirely a matter of knowing which files are needed, and making sure I've got that straight is part of what I expect to do when porting to en.wb.  I'm seriously thinking about having a single dedicated category that would have every last required page in it (down to auxiliary templates like (*), just to make it all dead simple to do.
 * Although I am a big believer in wiki markup for the sisterhood, I can quite see that some third-party wikis would have a lot of users who'd be spooked by it. I suspect my dialog tools could be used to help end-users operate effectively without having to tinker with wiki markup, although doing so might call for addition of some specialized facilities in wikilisp &mdash; I've been carefully choosing facilities for wikilisp based on what I found was actually needed for what I mean to do with it, and it does seem to me that aggressively shielding end-users from wiki markup might call for some enhanced wikilisp facilities.  If it actually came to that, perhaps we could come to some agreement on what to add; the key is to really deeply grok the nature of what is needed and craft immensely general features to add to wikilisp, and thus avoid language bloat.
 * Regarding VE itself, there are multiple reasons I don't see that happening. The most obvious is that I philosophically disapprove of the direction I see VE going in; but it goes beyond that.  When I started my dialog-tools project, about... I think it's four years ago now, the first thing I had to work out was a basic technical strategy for moving the information around.  Since I came up with that strategy, there have been all kinds of newfangled gizmos added to the wiki software, like Lua, that could in theory have been used to rethink the whole underlying technical strategy; but it's impossible to get ahead by playing a perpetual game of catch-up.  If you keep redoing your own infrastructure in order to take advantage of infrastructure somebody else is developing, you'll never get anything done.  Also, I am trying to absolutely minimize my dependence on other things that might change, so that's another very good reason not to want to hitch my wagon to VE. That said, I know frankly less about VE than I should.  If at some point in the future I found time to pursue the alternative structured-editing strategy that I describe on the vision page, I imagine I'd have to understand VE a great deal better in the process.
 * --Pi zero (talk) 20:45, 28 July 2015 (UTC)