On Tue, Apr 7, 2009 at 3:40 AM, Markus Krötzsch <markus@semantic-mediawiki.org> wrote:
On Montag, 6. April 2009, Yaron Koren wrote:
> Sergey - it's true that creating a good UI is hard, but I don't think
> having each format provide its own forms is the way to go - first because
> it's a lot more work, and second because, if we do come up with a good UI,
> I bet it'll be fine across all formats.

I tend to agree here. The biggest drawback I see with the "class-generated
form" option is that you get only one possible form. This is useful for MW
prefs, since the UI into which the forms are embedded is known and fairly
stable. But I think one of the main motivations of extensions like Halo is to
improve the UI in new and fancy ways (e.g. with auto completion). If printers
were to ship ready-made forms, then Halo would not have much freedom to design
new interfaces, and the task of improving UI functionality would become a
responsibility of the printer developers (including me ;-). This is why I
would prefer an approach where only the relevant parameters are exported, and
the form construction is left to the code using this.

I think the following API would be most extensible and convenient:

* Have a function that returns an array of parameter names.
* Have further functions to retrieve extra information about a particular
parameter (the input would be the parameter name). Examples include
getParameterLabel(), getParameterDescription(), and maybe, one day,

Guys, I'll leave it up to you to take care of architecture - as long as stuff gets improved, I'm fine with it ;)

> To illustrate my point for both, I put together a mockup of what a simple
> interface, using the parameter declarations, could look like. Using
> Javascript, the form would change the set of parameters available for the
> user to fill out every time they re-selected a format from the dropdown.
> Here's what it would look like if the user selected the 'list' format:
> http://discoursedb.org/new-special-ask.png


Frankly, the first thing I would change for an improved Special:Ask would be
the two topmost text inputs. Especially adding printouts should be easier and
more structured. But Special:Ask so far was not meant to be very user
friendly, but rather as a web service that "further results" and data exports
can link to. I think it would be worth cleaning up the code (Special:Ask is
still rather messy) and then consider separating the UI aspects more clearly
from the web service aspects, maybe far enough to allow for simple subclassing
and customisation of the whole special page.

I think it's important to actively show Special:Ask to people as it represents main feature of SMW - ability to use you wiki as data, easily extract accumulated knowledge, format it as you want, and post it to other pages (instead of "wikipedia category hell").

There are definitely a few things to improve on top boxes, but they work already, but setting additional parameters so results can be copied to a wiki page (using code embed I just checked in) still not functioning so I'd go for adding the parameters first and improve overall UI next.

-- Markus