RFC: MediaWiki Style Guide (Forms)

List overview All Threads
Download

newer

older

MediaWiki Sanitizer and HTML5...

Fwd: Reg. Research using Wikipedia

Brandon Harris

10 Mar 2011 10 Mar '11

1:33 a.m.

One of my goals for the year at the Foundation is "Development of a MediaWiki Style Guide." To that end, I have completed the first draft of one section, focused on Forms and Form elements. This project has multiple goals: * To create consistency across various interfaces * To help modernize the MediaWiki interface * To make the overall user experience more enjoyable * To make writing user interfaces easier for developers In a perfect world, MediaWiki would have a standardized User Interface library where a developer can simply say something like $myInput = UIElements::getTextInput( type => 'text' name => 'elementname', label => 'The Label', helptext => 'Help text string', hint => 'Default value', instructions => 'Instructions string', errorconditions => array(blah blah blah) ); And have that do the needful, knowing how to display itself and handle errors for itself. We don't live in a perfect world, but we can start to get there. Here is the first draft. Attack at leisure, and feel free to ignore my pathetic mewlings as you cut my soul from my bones. http://www.mediawiki.org/wiki/StyleGuide/Forms I'm going to expand this further (with things like "tables" and such) but for now this is a start. You can comment here or on the talk page.

Show replies by date

MZMcBride

10 Mar 10 Mar

4:17 a.m.

Brandon Harris wrote:

...

One of my goals for the year at the Foundation is "Development of a MediaWiki Style Guide." To that end, I have completed the first draft of one section, focused on Forms and Form elements.

I think it's a good first draft. :-) My only comment is that some of the suggestions in the guide don't match current practice; for example, the location of the "discard changes" button vs. the "save page" button. (Or to be even pickier, the fact that "discard changes" is a button at all.) For now it's fine for there to be mismatches, but at some point the guide should be aligned with current practice. In most cases, I imagine this will mean updating MediaWiki (it certainly needs UI work), but in some cases I imagine it will mean updating the guide. (I foresee strong objections to moving the "save page" button in particular simply due to inertia.) MZMcBride

Dmitriy Sintsov

8:18 a.m.

* Brandon Harris <bharris(a)wikimedia.org> [Wed, 09 Mar 2011 16:33:59 -0800]:

...

blah)

...

); And have that do the needful, knowing how to display itself

and

...

handle errors for itself. We don't live in a perfect world, but we can start to get

there.

...

Here is the first draft. Attack at leisure, and feel free to ignore my pathetic mewlings as you cut my soul from my bones. http://www.mediawiki.org/wiki/StyleGuide/Forms I'm going to expand this further (with things like "tables"

and

...

such) but for now this is a start. You can comment here or on the talk page.

These should use more powerful Xml class, which would not just "linearly" generate inputs but also would allow to build a tree of them and to get / manipulate their nodes and attributes on demand. Arrays are a possible choice, however one might try SPL / SimpleXML / SimpleXMLIterator for that. Gluing output pieces together with concatenations is not nice for large nested output (tags "autoclosing" vs "do not forget to close all your tags manually"). Dmitriy

Neil Kandalgaonkar

7:50 p.m.

FYI, there are classes in MediaWiki like HTMLForm and HTMLFormField which abstract a lot of form creation in MediaWiki already. They are not used universally, but very very often. Those libraries are more useful for the technical details of forms (for instance, preventing cross-site request forgery is built-in) but if you want to standardize usability and style maybe you should start there. Ultimately we also have to deal with forms created entirely by Javascript interfaces (like a rich text editor will have). We'd want them to be as similar as possible to the ones created in PHP. But if you create the PHP library first it will be easy to figure all that out. On 3/9/11 4:33 PM, Brandon Harris wrote:

...

-- Neil Kandalgaonkar ) <neilk(a)wikimedia.org>

Chad

11:21 p.m.

On Thu, Mar 10, 2011 at 1:50 PM, Neil Kandalgaonkar <neilk(a)wikimedia.org> wrote:

...

FYI, there are classes in MediaWiki like HTMLForm and HTMLFormField which abstract a lot of form creation in MediaWiki already. They are not used universally, but very very often.

Actually, HTMLForm isn't used all that much. It's fairly new, and only came around when Andrew redid the preference system not too long ago. We also have the Xml and Html classes, the former has been around since forever but the latter should probably be encouraged more.

...

Those libraries are more useful for the technical details of forms (for instance, preventing cross-site request forgery is built-in) but if you want to standardize usability and style maybe you should start there.

+1. I think this is a great idea, and helps enforce UI consistency rather than hoping people Get It Right. An example of a UI element I thought of recently that could be used in lots of places and add a level of usability would be an auto-suggesting text field for places you type in a username (Email, blocking, dozens of other places). By hiding all the complexity in something like autoSuggestUserBox() it would encourage usage elsewhere. -Chad

Happy-melon

11 Mar 11 Mar

1:52 a.m.

"Chad" <innocentkiller(a)gmail.com> wrote in message news:AANLkTimLNFEWAzemTST4sV2uJexJ-f-UJpf+SRGoOWQZ@mail.gmail.com...

...

On Thu, Mar 10, 2011 at 1:50 PM, Neil Kandalgaonkar <neilk(a)wikimedia.org> wrote:

FYI, there are classes in MediaWiki like HTMLForm and HTMLFormField which abstract a lot of form creation in MediaWiki already. They are not used universally, but very very often.

Actually, HTMLForm isn't used all that much. It's fairly new, and only came around when Andrew redid the preference system not too long ago.

Indeed, it's currently only used in Special:ComparePages, Special:DisableAccount, Special:EmailUser, Special:Preferences and the new Special:Upload. I've been one of the more prolific implementers of it since Andrew drew it up for the preferences rewrite in 1.16; I have it in a mostly-completed cleanout of the Augean stables that is Special:Blockip, and a rather unpolished rewrite of Special:UserLogin which uses it as well.

...

... +1. I think this is a great idea, and helps enforce UI consistency rather than hoping people Get It Right.

+1 from me to. I'm absolutely of the opinion that HTMLForm abstraction should be used much more widely; and this is one good reason of many. HTMLForm produces a form which has a clear and (most importantly) consistent structure, and also means we can apply style guidelines like these in one fell swoop.

...

An example of a UI element I thought of recently that could be used in lots of places and add a level of usability would be an auto-suggesting text field for places you type in a username (Email, blocking, dozens of other places).

I've been thinking about that too; it would be completely invaluable. One thing I've been slowly working towards is a JS module for htmlforms, which is now in existence (/resources/mediawiki/mediawiki.htmlform.js). HTMLForm is highly extensible by creating new HTMLFormField subclasses; for the Upload form btongminh created a field for the file-on-your-computer input, with various bells and whistles attached for previewing, client-side validation, etc. A user field could very happily be implemented in exactly the same way, indeed probably should. I fairly recently introduced a field type for "select-dropdown-created-from-a-parsed-system-message-plus-optional-additional-reason-text-field" like we see on the deletion/protection/upload/block forms, in much the same vein. --HM

4801

days inactive

4802

days old

wikitech-l@lists.wikimedia.org

Manage subscription

5 comments

6 participants

tags (0)

participants (6)

Brandon Harris
Chad
Dmitriy Sintsov
Happy-melon
MZMcBride
Neil Kandalgaonkar