On Tue, Apr 7, 2009 at 3:40 AM, Markus Krötzsch <
mar...@semantic-mediawiki.org> wrote:
> On Montag, 6. April 2009, Yaron Koren wrote:
> [skip-skip]
> > 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,
> getParameterType().
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
>
Sergey
------------------------------------------------------------------------------
This SF.net email is sponsored by:
High Quality Requirements in a Collaborative Environment.
Download a free trial of Rational Requirements Composer Now!
http://p.sf.net/sfu/www-ibm-com
_______________________________________________
Semediawiki-devel mailing list
Semediawiki-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/semediawiki-devel
