Set up the filtering/display setting UI for future growth

Just wondering, after reading this my first thoughts are - why aren't we using faceted search filters? It seems we are bending a interaction to something its not designed to handle. The proposed interaction adds logic, requiring the user to take an extra step and understand the way that filters interconnect. Even without that argument, I am not sure if adding this improves the interaction - because it hides the functionality, making it harder to "just try out".

Do we have some analysis on which filters are currently used? We create a cockpit by adding filters without knowing what there actual usage it, but the most important there is what we should strive for and defer uncommonly used ones to an advanced search page or so.

pretty nice.

adding filter via ajax is better than "advanced search". we can add what we needed anytime instead jump to other page. (advanced search page may show all filters that fill in my half of screen.)

mainly, there has 2 roles in LDO. For my own experience over 1 more year, when I am a....
Admin - almost all filters each time (String ID + Context are less use).
translators - Project, Translation status, Suggestion status filters

maybe ADMIN and translators ratio is 1:1000 but make ADMIN more easy to use LDO is first priority (ADMIN only has ONE way to do their work in LDO.). I think we need to track how many users are really submitting strings via web UI.

@Gabor I understand, however if you agree to many requests it will inevitably become a cockpit. It's true that facted filters doesn't solve this completely, but it does allow for more space and orientation. It's something we should probally mockup, if it could work.

To be clear, it's not just about having quantitative data to proof a point, but its about having data to make an informed decision about which filters to add and remove in the future.

I agree with Gábor on forecasting the arrival of many more filters expanding our search form to an entire screen. In the meantime Ajax is good but require more clicks (one to select the filter to add, another to focus the select value, and another to apply), I would recommend to keep our top 3 filters (project, release, suggestions status) displayed while others can be added via the UI you suggested first (which is very nice btw, as it avoid clicks).

One thing I would like to be improved : the release search process. For now, I type in the project name, select it via down arrow, (press enter or not) and press tab, then the search begins. When the data comes back, the releases' select is replaced, and focus is lost.
Assuming that the search is on the blur event, could it be possible to bind it to the enter keypress too? That way the releases' select would be replaced while we're still in the project textfield, and pressing tab will change focus to releases as expected.

I'm also a bit annoyed with the limit, I would like to see it stored in a $_SESSION variable (as I am one of the people who likes 50) to not be obliged to set it again every time I visit l.d.o

Hoping to see this new UI (and new filters) soon, keep up the good work!

Can we use this UI ? :p

http://documentcloud.github.com/visualsearch/

Just kidding... This isn't Drupal-friendly :)

Some ideas on filters

- hope it has "SHOW ALL FILTERS"
- move "APPLY" to the right of filters or right bottom.
- move "X PER PAGE" to pager right or inside filters.

-------------

Another issue, move "SAVE" to the right side

edit strings / admin manage actions are on right side now, so I think move to right is better.

-------------

"Save and continue" is broken.

I've just thought about doing a proof of concept sandbox with this library. The idea:
Register on hook_field_widget_properties_alter (D7) or alter form element with this snippet (D6) and add JS library + CSS class to the select.
Of course some settings on when (minimum number of items in the select) this would appear and which field to include/exclude would be possible.

Glad you saw it too!

Not quick enough... http://drupal.org/project/chosen

Can we get this patch committed, please? Chosen looks cool, but we can follow up later.

Ok, so I suppose this UI is the most anticipated feature in D7.

Here's the result for now

It needs a lot of UX review before being committed but it's a start.

Updated to the latest version (requires jquery_update --dev) set to 1.8

I've set up a sandbox where you can try this http://issue-1118430-localize_7.redesign.devdrupal.org/translate/languag...

And here are some login links for this issue followers
Gabor http://issue-1118430-localize_7.redesign.devdrupal.org/user/reset/1/1380...
hass http://issue-1118430-localize_7.redesign.devdrupal.org/user/reset/292/13...
droplet http://issue-1118430-localize_7.redesign.devdrupal.org/user/reset/1455/1...
Bojhan http://issue-1118430-localize_7.redesign.devdrupal.org/user/reset/340/13...

for the others, contact me via IRC

Thanks @SebCorbin.

But it has "Access denied" problem on this page:
http://issue-1118430-localize_7.redesign.devdrupal.org/translate/languag...

(I've logged and joined the group)

Link does not work for me. Access denied.

Aside from the UI, can you add a case sensitive search feature, please? I have more and more troubles to find strings without. Mostly results of many thousands of unrelated strings.

Updated OG permissions, tested with droplet's account on test group.

Note that suggestion status and translation status are not working yet. I just need your feedback on the UX to see if I keep going forward :)

Can somebody please download and re-upload the linked images in the issue summary? I have switched this from full html to filtered html so that users without that input filter can comment.

Fixed the problems with translation status and release labels, added dependencies on jQuery update

Tests need to be rewritten.

Maybe I should create a new branch on git and push it to the staging site so that's easier to test?

What jquery_update module branch and what version is required? There is a 2.x and a 3.x branch and as you know if the module has been installed there is a setting where you are able to select a bunch of jquery versions. I think this requires more detailed .info entry and a hook_requirement to make sure the correct setting is configured!?

Here are some other findings. We are also using these libraries in navbar and I have navbar module installed on my translation server:

1. +++ b/l10n_community/visualsearch/vendor/backbone-1.1.0.js
   @@ -0,0 +1,1581 @@
   +//     Backbone.js 1.1.0
   

   We should use library API for this.

2. +++ b/l10n_community/visualsearch/vendor/underscore-1.5.2.js
   @@ -0,0 +1,1276 @@
   +//     Underscore.js 1.5.2
   

   Same here, Libary API should be used.

Per https://documentcloud.github.io/visualsearch/ it could be jQuery 1.4+, jQuery UI 1.8+, Underscore.js, Backbone.js

Visualsearch.js/css also need to be moved into a library.

Navbar module runs with Backbone.js 1.1.2 and Underscore.js 1.7.0. This will cause collision. The only way to prevent these is using library API to add the libs.

The rest looked good in a quick test. One thing was strange. When I loaded the translate tab the first time the visual search was empty. When I reloaded the tab several times the search items appear. This should be consistent I think.