Message: 8 Date: Wed, 23 May 2012 21:49:57 +0200 From: Platonides Platonides@gmail.com To: wikitech-l@lists.wikimedia.org Subject: Re: [Wikitech-l] HTMLMultiSelectField as <select multiple="multiple"/> Message-ID: jpjf1s$b23$1@dough.gmane.org Content-Type: text/plain; charset=ISO-8859-1
On 23/05/12 19:16, Daniel Werner wrote:
Right now I am implementing a new option (as part of https://bugzilla.wikimedia.org/show_bug.cgi?id=36425) for which I'd
like to
use a <select multiple="multiple"/> html element with options. Right now MediaWiki always generates a list of selectboxes instead of that when
using
the HTMLMultiSelectField class. We are talking about 280+ selectable
items
here, so for now we came to the conclusion that a real multi <select/> would be nicer and less space consuming for now I have already managed to implement this multiple select, modifying HTMLMultiSelectField adding a new option 'usecheckboxes' which can be set to false to disable the known behavior and use a select
element
instead.
This would mainly be for the JavaScript-less ui. If javascript were enabled, we could still do something nicer, for example with something
like
jQuery chosen plugin here.
My question would just be, how I should implement these changes
preferably.
Is it ok with the new option for HTMLMultiSelectField or should this be
a
new class inheriting from HTMLMultiSelectField? I think HTMLMultiSelectField sounds more like describing what I just implemented rather than a bunch of select boxes, but of course renaming the existing one could "break" extensions (even though both are fully compatible and interchangeable). So one option would be simply naming the new one HTMLMultiSelectField2 if we don't want to stick with an additional
option
here.
No. You shouldn't need to know that HTMLMultiSelectField2 is a MultiSelect but HTMLMultiSelectField uses checkboxes. Your useCheckboxes looks good. I recommend you to make it a tri-state value, so you could force checkboxes, select or let it decide (eg. checkboxes for < 100 elements, select for more)
Alright, just submitted this for review to gerrit: https://gerrit.wikimedia.org/r/#/c/8924/
I implemented it as tri-state now. By default 'usecheckboxes' will be true, not set to a number. This could be changed (would make sense imo) but for now I didn't want to do this since it could for example affect the default search namespace user preference in wikis with many search namespaces. I think the plain multiple select HTML element is not that nice because it is not very obvious that you can do multiple selects by holding the control key. There should be some JavaScript ui element replacing this for users having JS enabled I think before using this as default for huge multiselect options. I think if all of that were implemented, 15 or 20 would be a good default value for the option.
Cheers Daniel
On Fri, 25 May 2012 09:11:20 -0700, Daniel Werner daniel.werner@wikimedia.de wrote:
Message: 8 Date: Wed, 23 May 2012 21:49:57 +0200 From: Platonides Platonides@gmail.com To: wikitech-l@lists.wikimedia.org Subject: Re: [Wikitech-l] HTMLMultiSelectField as <select multiple="multiple"/> Message-ID: jpjf1s$b23$1@dough.gmane.org Content-Type: text/plain; charset=ISO-8859-1
On 23/05/12 19:16, Daniel Werner wrote:
Right now I am implementing a new option (as part of https://bugzilla.wikimedia.org/show_bug.cgi?id=36425) for which I'd
like to
use a <select multiple="multiple"/> html element with options. Right
now
MediaWiki always generates a list of selectboxes instead of that when
using
the HTMLMultiSelectField class. We are talking about 280+ selectable
items
here, so for now we came to the conclusion that a real multi <select/> would be nicer and less space consuming for now I have already managed to implement this multiple select, modifying HTMLMultiSelectField adding a new option 'usecheckboxes'
which
can be set to false to disable the known behavior and use a select
element
instead.
This would mainly be for the JavaScript-less ui. If javascript were enabled, we could still do something nicer, for example with something
like
jQuery chosen plugin here.
My question would just be, how I should implement these changes
preferably.
Is it ok with the new option for HTMLMultiSelectField or should this
be
a
new class inheriting from HTMLMultiSelectField? I think HTMLMultiSelectField sounds more like describing what I just
implemented
rather than a bunch of select boxes, but of course renaming the
existing
one could "break" extensions (even though both are fully compatible
and
interchangeable). So one option would be simply naming the new one HTMLMultiSelectField2 if we don't want to stick with an additional
option
here.
No. You shouldn't need to know that HTMLMultiSelectField2 is a MultiSelect but HTMLMultiSelectField uses checkboxes. Your useCheckboxes looks good. I recommend you to make it a tri-state value, so you could force checkboxes, select or let it decide (eg. checkboxes for < 100 elements, select for more)
Alright, just submitted this for review to gerrit: https://gerrit.wikimedia.org/r/#/c/8924/
I implemented it as tri-state now. By default 'usecheckboxes' will be true, not set to a number. This could be changed (would make sense imo) but for now I didn't want to do this since it could for example affect the default search namespace user preference in wikis with many search namespaces. I think the plain multiple select HTML element is not that nice because it is not very obvious that you can do multiple selects by holding the control key. There should be some JavaScript ui element replacing this for users having JS enabled I think before using this as default for huge multiselect options. I think if all of that were implemented, 15 or 20 would be a good default value for the option.
Cheers Daniel
Yes, multiselect is a VERY bad usability choice. Frankly we shouldn't use it anywhere. If we're using JS to make a better UI it would actually be much better to output usable checkboxes and then turn the checkboxes into a special JS multi-select. Instead of outputting an unusable multi-select and compensating for it.
On Sep 29, 2012, at 4:51 AM, Daniel Friesen daniel@nadir-seen-fire.com wrote:
On Fri, 25 May 2012 09:11:20 -0700, Daniel Werner daniel.werner@wikimedia.de wrote:
Alright, just submitted this for review to gerrit: https://gerrit.wikimedia.org/r/#/c/8924/
[..]
Yes, multiselect is a VERY bad usability choice. Frankly we shouldn't use it anywhere. If we're using JS to make a better UI it would actually be much better to output usable checkboxes and then turn the checkboxes into a special JS multi-select. Instead of outputting an unusable multi-select and compensating for it.
+1 :-)
-- Krinkle
Hi guys!
In Semantic Form Inputs extension we use the multiselect that is stylized and more usable. Here is the library: http://loudev.com/
Some other options are: http://harvesthq.github.com/chosen/ (will be included in the next Semantic Form Inputs) http://www.erichynds.com/jquery/jquery-ui-multiselect-widget/
----- Yury Katkov
On Sat, Sep 29, 2012 at 9:38 AM, Krinkle krinklemail@gmail.com wrote:
On Sep 29, 2012, at 4:51 AM, Daniel Friesen daniel@nadir-seen-fire.com wrote:
On Fri, 25 May 2012 09:11:20 -0700, Daniel Werner daniel.werner@wikimedia.de wrote:
Alright, just submitted this for review to gerrit: https://gerrit.wikimedia.org/r/#/c/8924/
[..]
Yes, multiselect is a VERY bad usability choice. Frankly we shouldn't use it anywhere. If we're using JS to make a better UI it would actually be much better to output usable checkboxes and then turn the checkboxes into a special JS multi-select. Instead of outputting an unusable multi-select and compensating for it.
+1 :-)
-- Krinkle
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
On Sep 29, 2012, at 4:51 AM, Daniel Friesen daniel@nadir-seen-fire.com wrote:
Yes, multiselect is a VERY bad usability choice. Frankly we shouldn't use
it anywhere. If we're using JS to make
a better UI it would actually be much better to output usable checkboxes
and then turn the checkboxes into a
special JS multi-select. Instead of outputting an unusable multi-select
and compensating for it.
Sure, as long as there is JS available we should turn the multi-select into something nicer. But the original idea behind this was that a multi select would still be more user friendly than an endless list of check-boxes when having around 300 choices (e.g. for languages). Take jQuery chosen for example (thanks for the link Yury), it takes a multi-select as source and turns it into some very nice piece of UI. It doesn't matter whether you originally have a bunch of check-boxes or a multi-select from a JS perspective.
Anyhow, I would still appreciate if someone would merge the thing, it's sitting around for too long already and it seems that it got stuck because of some very minor issue once again: https://gerrit.wikimedia.org/r/#/c/8924/ Thanks!
On Sun, 30 Sep 2012 13:41:30 -0700, Daniel Werner daniel.werner@wikimedia.de wrote:
On Sep 29, 2012, at 4:51 AM, Daniel Friesen daniel@nadir-seen-fire.com wrote:
Yes, multiselect is a VERY bad usability choice. Frankly we shouldn't use
it anywhere. If we're using JS to make
a better UI it would actually be much better to output usable checkboxes
and then turn the checkboxes into a
special JS multi-select. Instead of outputting an unusable multi-select
and compensating for it.
Sure, as long as there is JS available we should turn the multi-select into something nicer. But the original idea behind this was that a multi select would still be more user friendly than an endless list of check-boxes when having around 300 choices (e.g. for languages).
Checkboxes would still be better for non-js users... in this case multiselect is even worse. Now not only do you have to worry about users not knowing they can select multiple items, when they try to actually select a bunch of items their own computer is going to inevitably screw them over at some point when they forget the ctrl or their finger slips off of it, they click, and poof the dozens of items they selected ALL disappear. That kind of situation is incredibly more anti-user than a list of checkboxes. And you can get most of the same scrolling effect just by giving the checkbox list an overflow: auto;
Take jQuery chosen for example (thanks for the link Yury), it takes a multi-select as source and turns it into some very nice piece of UI. It doesn't matter whether you originally have a bunch of check-boxes or a multi-select from a JS perspective.
Anyhow, I would still appreciate if someone would merge the thing, it's sitting around for too long already and it seems that it got stuck because of some very minor issue once again: https://gerrit.wikimedia.org/r/#/c/8924/ Thanks!
Hey,
On 30 September 2012 22:55, Daniel Friesen daniel@nadir-seen-fire.comwrote: Checkboxes would still be better for non-js users...
I'm sure people can find situations in which using a multiselect is not a good idea. Does that mean we should not have a multiselect input type developers can use when they think it is applicable? :)
Cheers
-- Jeroen De Dauw http://www.bn2vs.com Don't panic. Don't be evil. --
Nobody (afaik) is saying that jQuery chosen isn't better than a bunch of checkboxes.
The point is that <select multiple> (without javascript enhancement) is horrible and (imho) unacceptable. And no, it is not because we found situations in which it is not a good idea. It is because it is never a good idea, never.
The solution I'd propose (and Daniel also mentioned this various times here and elsewhere) to output checkboxes as fallback and an interface like "jQuery Chosen" as enhancement.
-- Krinkle
Alright, you convinced me that a scrollable(!) list of check boxes (using overflow scroll) might be better than a multi select. That is if you have at least CSS enabled. Without CSS I would definitely go for a multi-select because a list of 300 checkboxes still sucks more in my opinion.
I guess I could change my change set to add those css styles rather than using a multi-select, or even add some css per default to avoid utterly long lists of checkboxes.
On the other hand, this had been on the list and in review for months now and there are people who would find a multiselect useful apparently. It seems close to impossible to make it right for everybody. It doesn't really seem productive nor motivating to question small changes like this in all details after non trivial amount of work has gone into it by different parties (discussion, several patch-sets, reviews). For now I have abandoned this since I don't even need it anymore in STTL. So may someone else try to improve upon it or not.
Cheers, Daniel
2012/10/1 Krinkle krinklemail@gmail.com
Nobody (afaik) is saying that jQuery chosen isn't better than a bunch of checkboxes.
The point is that <select multiple> (without javascript enhancement) is horrible and (imho) unacceptable. And no, it is not because we found situations in which it is not a good idea. It is because it is never a good idea, never.
The solution I'd propose (and Daniel also mentioned this various times here and elsewhere) to output checkboxes as fallback and an interface like "jQuery Chosen" as enhancement.
-- Krinkle
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
wikitech-l@lists.wikimedia.org