Hello all, I was finding it frustrating to use the genome select drop down in Galaxy. On the public instance there are about 800 entries (mostly bacteria), and for many organisms there are multiple entries (e.g. five releases for human). I was thinking some kind of heirachy would be useful here until I realised how well the search works. I'm now facing the same problem with other long drop down select parameters (e.g. BLAST+ databases). Can the same nice search feature be enabled in any select parameter via the tool's XML definition? Thanks, Peter
I was finding it frustrating to use the genome select drop down in Galaxy. On the public instance there are about 800 entries (mostly bacteria), and for many organisms there are multiple entries (e.g. five releases for human). I was thinking some kind of heirachy would be useful here until I realised how well the search works.
I'm now facing the same problem with other long drop down select parameters (e.g. BLAST+ databases). Can the same nice search feature be enabled in any select parameter via the tool's XML definition?
Search for select should be automatically enabled whenever the number of options is greater than 20 and less than 3000; no need to modify the XML to get this functionality. Please let us know if you're not seeing the expected behavior. Thanks, J.
On Wed, Dec 22, 2010 at 3:18 PM, Jeremy Goecks <jeremy.goecks@emory.edu> wrote:
I was finding it frustrating to use the genome select drop down in Galaxy. On the public instance there are about 800 entries (mostly bacteria), and for many organisms there are multiple entries (e.g. five releases for human). I was thinking some kind of heirachy would be useful here until I realised how well the search works.
I'm now facing the same problem with other long drop down select parameters (e.g. BLAST+ databases). Can the same nice search feature be enabled in any select parameter via the tool's XML definition?
Search for select should be automatically enabled whenever the number of options is greater than 20 and less than 3000; no need to modify the XML to get this functionality.
Please let us know if you're not seeing the expected behavior.
Hi Jeremy, You're right - thank you: On closer inspection, it does offer search, but the default text isn't "Click to Search or Select", rather it is the first entry in the list, so it could be much more obvious. Peter
You're right - thank you: On closer inspection, it does offer search, but the default text isn't "Click to Search or Select", rather it is the first entry in the list, so it could be much more obvious.
The Javascript code that implements this feature is tuned to default values in tools and dbkeys. For reference, the code is in the function replace_big_select_inputs() in galaxy.base.js, and the relevant lines are: -- // Set initial text if it's empty. if ( start_value === '' || start_value === '?') { text_input_elt.attr('value', 'Click to Search or Select'); } -- So, if the select's start value of a select is empty or '?', the text will default to the prompt string. Can you imagine a better way to handle this situation? Thanks, J.
On Wed, Dec 22, 2010 at 3:49 PM, Jeremy Goecks <jeremy.goecks@emory.edu> wrote:
You're right - thank you: On closer inspection, it does offer search, but the default text isn't "Click to Search or Select", rather it is the first entry in the list, so it could be much more obvious.
The Javascript code that implements this feature is tuned to default values in tools and dbkeys. For reference, the code is in the function replace_big_select_inputs() in galaxy.base.js, and the relevant lines are:
-- // Set initial text if it's empty. if ( start_value === '' || start_value === '?') { text_input_elt.attr('value', 'Click to Search or Select'); } --
So, if the select's start value of a select is empty or '?', the text will default to the prompt string.
Can you imagine a better way to handle this situation?
Thanks, J.
That makes sense, but I guess somewhere before the Javascipt runs the start value is being set to the first entry in the list. I've tried adding value="" and value="?" to the <param type="select" ...> tag to no avail. Maybe I'm missing something. Should all browsers behave the same? Peter
That makes sense, but I guess somewhere before the Javascipt runs the start value is being set to the first entry in the list.
Yes, I think this is the case; there is also an 'accept_default' attribute that can be added to select parameters.
I've tried adding value="" and value="?" to the <param type="select" ...> tag to no avail.
Hmm. For genome/dbkey selection, the first value is often '?'; for datatype selection, the first value is often ''. Hence, the reason for those two values being special.
Maybe I'm missing something. Should all browsers behave the same?
Yes, all browsers should behave the same, modulo some IE quirks. Can you provide the XML for your param and I can take a look? Thanks, J.
On Thu, Dec 23, 2010 at 1:52 AM, Jeremy Goecks <jeremy.goecks@emory.edu> wrote:
That makes sense, but I guess somewhere before the Javascipt runs the start value is being set to the first entry in the list.
Yes, I think this is the case; there is also an 'accept_default' attribute that can be added to select parameters.
Good idea, I tried adding accept_default="false", but it doesn't seem to do anything (the first list entry is still picked, a bug regardless of the search feature?). I also tried combining this with force_select="true", again no change. BTW, having the default value for this and other param attributes as another column in the table on the wiki would be a big help: https://bitbucket.org/galaxy/galaxy-central/wiki/ToolConfigSyntax
I've tried adding value="" and value="?" to the <param type="select" ...> tag to no avail.
Hmm. For genome/dbkey selection, the first value is often '?'; for datatype selection, the first value is often ''. Hence, the reason for those two values being special.
I can insert a dummy entry at the start of my loc file like that, and then I do see the "Click to Search or Select" text. However, the drop down list includes the dummy entry - so this isn't a very good solution. I'd need to add a validator to block the dummy entry or something, but it would still be distracting.
Maybe I'm missing something. Should all browsers behave the same?
Yes, all browsers should behave the same, modulo some IE quirks.
Can you provide the XML for your param and I can take a look?
Easy, I'm currently playing with blastn (or any of the BLAST+ tools using nucleotides databases since I have lots of them. The blastp wrapper would have the same issues except currently I have less than 20 protein databases setup. See: https://bitbucket.org/galaxy/galaxy-central/src/default/tools/ncbi_blast_plu... Currently my best workaround so far is to add a help attribute, "When there are lots of entries, type here to search" (this needs to be worded carefully as when there are only a few databases setup you can't search). Thanks, Peter P.S. I will still be checking email, but our Institute closes today for the Christmas break, so I probably won't be able to try and code changes immediately.
Good idea, I tried adding accept_default="false", but it doesn't seem to do anything (the first list entry is still picked, a bug regardless of the search feature?).
Perhaps. We'll look into it.
I also tried combining this with force_select="true", again no change.
BTW, having the default value for this and other param attributes as another column in the table on the wiki would be a big help: https://bitbucket.org/galaxy/galaxy-central/wiki/ToolConfigSyntax
We'll try to augment the wiki with this information soon.
I can insert a dummy entry at the start of my loc file like that, and then I do see the "Click to Search or Select" text. However, the drop down list includes the dummy entry - so this isn't a very good solution. I'd need to add a validator to block the dummy entry or something, but it would still be distracting.
This is the core problem. The prompt can only be presented when no choice is required; if a choice is required, then--like all select boxes--a default choice must be present. If a default choice is present, the prompt cannot be shown because the default choice must be shown. There are definitely alternative approaches, such as putting a label next to the search+select that says "Click to Search or Select" or perhaps using a tooltip.
Currently my best workaround so far is to add a help attribute, "When there are lots of entries, type here to search" (this needs to be worded carefully as when there are only a few databases setup you can't search).
Yes, this is in line with the label/tooltip solution. Additional suggestions are welcome as well.
P.S. I will still be checking email, but our Institute closes today for the Christmas break, so I probably won't be able to try and code changes immediately.
Happy Holidays! J.
On Thu, Dec 23, 2010 at 6:45 PM, Jeremy Goecks <jeremy.goecks@emory.edu> wrote:
Good idea, I tried adding accept_default="false", but it doesn't seem to do anything (the first list entry is still picked, a bug regardless of the search feature?).
Perhaps. We'll look into it.
Great - should I file an issue on bitbucket or will you after a little investigation?
BTW, having the default value for this and other param attributes as another column in the table on the wiki would be a big help: https://bitbucket.org/galaxy/galaxy-central/wiki/ToolConfigSyntax
We'll try to augment the wiki with this information soon.
Lovely.
I can insert a dummy entry at the start of my loc file like that, and then I do see the "Click to Search or Select" text. However, the drop down list includes the dummy entry - so this isn't a very good solution. I'd need to add a validator to block the dummy entry or something, but it would still be distracting.
This is the core problem. The prompt can only be presented when no choice is required; if a choice is required, then--like all select boxes--a default choice must be present. If a default choice is present, the prompt cannot be shown because the default choice must be shown. There are definitely alternative approaches, such as putting a label next to the search+select that says "Click to Search or Select" or perhaps using a tooltip.
Currently my best workaround so far is to add a help attribute, "When there are lots of entries, type here to search" (this needs to be worded carefully as when there are only a few databases setup you can't search).
Yes, this is in line with the label/tooltip solution. Additional suggestions are welcome as well.
I think the option accept_default="false" would be fine (assuming it did what we want it to do, and triggers the search text).
P.S. I will still be checking email, but our Institute closes today for the Christmas break, so I probably won't be able to try and code changes immediately.
Happy Holidays! J.
Likewise :) Peter
Good idea, I tried adding accept_default="false", but it doesn't seem to do anything (the first list entry is still picked, a bug regardless of the search feature?).
Perhaps. We'll look into it.
Great - should I file an issue on bitbucket or will you after a little investigation?
Hi Peter, It turns out that accept_default is recognized only in very special cases and used for a particular purpose. I've removed it from the wiki for now since it's more of a undocumented/internal feature of Galaxy rather than something that useful to tool authors.
Currently my best workaround so far is to add a help attribute, "When there are lots of entries, type here to search" (this needs to be worded carefully as when there are only a few databases setup you can't search).
Yes, this is in line with the label/tooltip solution. Additional suggestions are welcome as well.
I think the option accept_default="false" would be fine (assuming it did what we want it to do, and triggers the search text).
I think the best solution to this problem is likely UI-centric rather than tool-centric, but let's keep an open mind. As such, I've created an issue that you can follow and comment on here: https://bitbucket.org/galaxy/galaxy-central/issue/441/better-help-text-in-cu... Thanks, J.
On Mon, Jan 3, 2011 at 6:40 PM, Jeremy Goecks <jeremy.goecks@emory.edu> wrote:
Hi Peter, It turns out that accept_default is recognized only in very special cases and used for a particular purpose. I've removed it from the wiki for now since it's more of a undocumented/internal feature of Galaxy rather than something that useful to tool authors.
...
I think the option accept_default="false" would be fine (assuming it did what we want it to do, and triggers the search text).
I think the best solution to this problem is likely UI-centric rather than tool-centric, but let's keep an open mind. As such, I've created an issue that you can follow and comment on here: https://bitbucket.org/galaxy/galaxy-central/issue/441/better-help-text-in-cu... Thanks, J.
Thanks - I've subscribed to the issue, and if you can fix this as a general UI issue for all select boxes with many entries that would be good. Failing that, a way to explicitly turn it on via the tool XML would be a useful plan B. Peter
participants (2)
-
Jeremy Goecks -
Peter