The 2026 Drupal Business Survey is open. Your response will help shape the future of the Drupal business ecosystem.The main motivation is that most users are familiar with the search (Google...) metaphor when doing search/filter. One example is that I think some users may be confused coming back and not finding what they are looking for and then realising that their previous filter is still on (although that *is* a good idea).
Here is a rough mockup for search functionality. Instead of having a selectbox for all/translated/untranslated/has suggestion they have their own page. This is to make it easy to link to e.g untranslated strings (permalink) as well as limit the search. They could be implemented as secondary links for example. The permalink functionality, which I think is important ("Could you help me finish the translation of the Image module in Swedish?") will be implemented for individual strings ("What do you think of this translation?") in http://drupal.org/node/184566.
In 2 a search has been done. Note that the search also list if there are matches in all strings. This is analogous to the filter situation where the user might be unaware that they are just looking at e.g untranslated strings.
Image 3 lists the 2 matches.
It might be useful to have a search-as-you-type javascript implementation here (Firefox, Itunes), that is why I have omitted the button on these mockups.
| Comment | File | Size | Author |
|---|---|---|---|
| l10n_search.png | 11.92 KB | anders.fajerson |
Comments
Comment #1
gábor hojtsyBack through the life of l10n_server, I also played with having subtabs for filtering by state, but then realized that mixing the filter selections between tabs and regular form buttons might not be a good idea. So I had some code already to have tabs for states, but then decided this might not be a good idea after all. If more people think this is good, we can get it back for sure. (I agree that the dropdown provides worse overview, then the tabs).
Also, I think it is useful to be able to receive options as GET params, which would allow anyone to pass any of the filter options by URL, independent of whether we are using tabs or select fields.
Comment #2
gábor hojtsyUh forgot to mention that the search queries could be quite inefficient (ie. they are joining 5 or more tables at once), which become harder as more data comes into the system. This means that doing a live search might not be a good idea before fixing any possible performance problems (which need to be benchmarked).
Comment #3
anders.fajerson commentedI see. Lets wait with livesearch then (which would have been implemented after the back-end anyway, Drupal style).
It doesn't have to be tabs though. It seems that we agree on skipping the dropdown though, which was the main point I think.
I think it might be a good idea to mimic the search "language" in core, here is one example:
translate/search/user+interface+status:untranslated+release:5.2
You mention one big gain: permalinks for searches.
Comment #4
gábor hojtsyI implemented permalinks for filters, but still kept filters being remembered in alpha2. Also moved project selection to the filter, so you can do cross-project filtering even. Other suggestions in the meantime asked for a filtering combinations of "translated" and "has suggestions", so ideally we would have a three-state checkbox for both the translation status and the suggestion status, which would allow people to lego their filters together properly. Unfortunately HTML does not have three state checkboxes, and although I tried hard, I I have not been able to find jQuery implementations to reuse. That would however get us rid of the dropdown(s).
Comment #5
gábor hojtsyBTW also implemented a reset button on the filter, so all filters can be easily reset.
Comment #6
gábor hojtsyRemaining UI issues move to http://drupal.org/node/196865