User Interaction Consultation/Wikidialog

From mediawiki.org
Jump to navigation Jump to search

Brief Description[edit]

This already just about exists; it's been under intensive development for several years. To quote from n:Help:Dialog:

The facilities have two main parts: a set of templates used to specify interactive elements on a wiki page, and a set of versatile "actions" that can be directed by those interactive elements. Using the facilities is meant to involve writing only wiki markup, so the interactive pages can be developed and maintained by the wiki community. From the user's perspective, interactive pages allow data to be entered through dialog boxes and similar input elements, and allow this data to flow to input elements of other pages, to template parameters, and to actions.

Almost everything is done with a single action, called "do", because this is much faster than switching between actions during a long interactive dialog.

You can see a simple demo here; and of course you can play around with the tools in any sandbox on English Wikinews.

(It seemed to me, when I saw this forum, that these tools are relevant to the conversation here. I'll address this below under Details.)

Problem it solves[edit]

The motivation is explained in this essay, and the variety of interactive tools that may be created with the facility has been discussed on its talk page.

The motivation, briefly: Make interaction part of what wiki markup can express, so that a wiki community can take over responsibility for developing interactive assistants for running the wiki (and perhaps for interaction with information consumers). Thus, interactivity is crowd-sourced, just as any other wiki content. This is the wiki way, users doing what is needed instead of asking someone else to do it for them; and the more purely everything is centered on wiki markup alone, the more effectively users are empowered (these points are further discussed in the essay).

Details[edit]

I've been designing the tools themselves using the same philosophy: that all design should flow from being deeply embedded in a wiki community (I've been a Wkipedian, a Wikibookian, and a Wikinewsie). For three or four years now I've been intensively developing the tools, learning what is needed next by trying to use what I had so far. At the heart of the dialog tools are some key bits of languages other than wiki markup, in service of helping wiki users to not have to use any language other than wiki markup — the key bits involve javascript and Lua. It became clear that, in order to take full advantage of the interactive templates, sometimes wiki markup needed to be able to do powerful manipulations — such as parsing and modifying the entire raw-wiki-markup content of a page — and to support this I also created a wikilisp facility (using Lisp syntax because it has extremely low syntactic overhead).

In the long run, I hope to build interactive assistants using the wikidialog tools. As with the low-level tools, I'm slowly gaining experience with how to build assistants. I hope to port the dialog tools to English Wikibooks later this year, learning how to streamline the porting process, and then learning to apply the tools to a wider variety of tasks (because Wikibooks needs different tasks than Wikinews).

Re this forum:

The development philosophy of these tools is different than the apparent philosophy behind this forum. It seems the forum is based on a model where people try to convince developers to do stuff, whereas the wikidialog tools were created from a belief that the things most needed would never happen if we spent our energies trying to convince others to do them for us instead of doing them ourselves. However, that said, there are some interesting questions one can raise.

For one thing, would the wikidialog facilities be faster if they were in the core php of the software? For years I assumed the answer was "yes, but that would make them much harder to make changes to, miring the process of improving the tools". I'm no longer entirely sure about the "yes" part, though. Once the wikidialog tools are loaded, an ongoing dialog doesn't do any full page loads with the associated loading of gadgets and whatnot. As a result, at times when the internet/servers are especially slow, I've observed that an ongoing dialog is actually faster than directly navigating around amongst ordinary wiki pages.

It's been very clear, throughout the development process, that the implementation of the low-level wikidialog tools is mostly about moving information around, and the chief obstacle to doing so is the way the wiki software is designed. I've tried to use techniques that would bypass the obstacles without depending on anything marginal in the underlying platform (these tools need to be robust against platform changes!). Text content flows between input boxes, template parameters, and javascript. Even though the wiki software design makes this difficult to implement, I don't believe any significant change to the underlying wiki platform can be justified; stability is crucial, the problems can be worked around, and even if one were designing the platform over from scratch I suspect we still don't know enough to produce a better outcome than the existing platform — there might easily be unanticipated problems that would far outweigh any benefit.