Original report by [mikey_p]
I tried to write some tests for this after seeing #308458: TestingParty08: Tests for admin/content/node and ran into issues. I talked to chx about this and he suggested completely reworking the filters so that they no longer use session to store their values, but to change all the filters into $_GET params for easier testing.
The undo feature won't work after this conversion, and the whole interface for this is clunky so I talked to the usability team about adding a 'remove filter' type of link/button next to each currently applied filter and yoroy suggested something like the iTunes smart playlist filters (screenshot).
FYI: $_GET params are passed through drupal_get_destination, tablesort and pager links, so neither the pager, the edit links on a node, or the table sort header links will destroy the filtered set.
EDIT by mikey_p: I changed the issue author to Abandoned modules since I don't seem to be able to un-follow this issue (I keep getting re-subscribed with each followup) and I really don't want anymore update on this issue. Please feel free to change it to someone else that is more appropriate
Comment | File | Size | Author |
---|---|---|---|
#31 | improved-filtering-355820-31.patch | 12.49 KB | David Lesieur |
#31 | improved-filtering-355820-31.png | 91.38 KB | David Lesieur |
#21 | content-type-filter.png | 60.25 KB | emarchak |
#18 | improved-filtering-355820-18.patch | 7.44 KB | David Lesieur |
#18 | improved-filtering-355820-18.png | 111.33 KB | David Lesieur |
Comments
Comment #1
mikey_p CreditAttribution: mikey_p commentedOh and this will come with tests.
Comment #2
bcn CreditAttribution: bcn commentedHere's a link to the discussion concerning this. http://groups.drupal.org/node/18008
Comment #3
webchickThis issue is less about usability and more that it needs UX team review, so marking as such.
Comment #4
sunsubscribing
@mikey_p: Is this issue intentionally assigned to you? I.e. are you working on it?
Comment #5
mikey_p CreditAttribution: mikey_p commented@sun: I'm not working on it at the moment as I guess I need to come up with some mockups for the usability team. This could be a pretty big patch and given it's mostly UX, I'd really like to get *some* feedback on the concept before writing a patch.
Comment #6
mikey_p CreditAttribution: mikey_p commentedNew mockups at http://groups.drupal.org/node/18008#comment-64978
Comment #7
mikey_p CreditAttribution: mikey_p commentedThis is probably dependent on #299267: Add "Extender" support to SELECT query builder Assigned to: Crell getting in first so that we can build a dynamic query that can be paged and table sorted.
Comment #8
sunComment #9
naught101 CreditAttribution: naught101 commentedThe best design for this is surely something akin to the project issue queue's advanced search? http://drupal.org/project/issues/search/drupal, particularly as it means you can make multiple changes in one page load, instead of the current horrible system of making single changes per page load.
Something like that could be done with views with exposed filters, couldn't it?
Fields as in the columns:
Name (contains): textfield
Type: multi-select
Author (contains): textfield
Status: multi-select (I think - otherwise spilt published/promoted/sticky status into separate selects?)
Updated: select less than/equal/greater than, textfield/datefield.
Comment #10
naught101 CreditAttribution: naught101 commentedSee also: http://drupal.org/project/improved_admin
Comment #11
David Lesieur CreditAttribution: David Lesieur commentedHere's the D7UX mock-up on this subject, which also adds a search box.
There is a request to add search to the content administration interface (#201493: Add a search box to content management option), and another to add search to the admin interface of each type of entity (#497804: [meta] Search entities (nodes, terms, etc.) within the administrative interface). Perhaps we could merge this issue with one of those two, as all are aimed at improving the admin interfaces, but I guess it would be easier to fix the filters first as a separate issue, then add the search feature.
Comment #12
David Lesieur CreditAttribution: David Lesieur commentedHere's my first attempt at this. It needs work but I'd like to gather feedback before going further. For now this is only for the admin/content page.
Notes:
Comment #13
David Lesieur CreditAttribution: David Lesieur commentedJust found out about the #empty_value and #empty_option form properties.
Comment #14
Gábor HojtsyCan you post a screenshot of how would this look like?
Comment #15
naught101 CreditAttribution: naught101 commentedRe: mockup image:
- Has no filter on title. This is a killer for me.
- Filter on author name should probably be an autocomplete, not a select. It's quite reasonable for a site to have hundreds of content authors.
- Also, WTF are "draft" and "closed"?
Comment #16
Gábor Hojtsy@naught101: well, the current patch just reorganizes the current filters as per the mockup. It does not add title filter or a user filter. Also, we can make the user filter be different depending on the number of users on your site. If you have a brochure site with 5 users, a dropdown would be perfect IMHO, otherwise we can make an autocomplete. However, once again, not for this issue :)
Comment #17
David Lesieur CreditAttribution: David Lesieur commentedTo me this issue is only about making this UI suck less. :-) I'd leave title and author filtering to #497804: [meta] Search entities (nodes, terms, etc.) within the administrative interface.
@Gábor Hojtsy: Then I'll add some styling to the patch before providing a screenshot.
@naught101: "draft" and "closed" are, perhaps, ideas from the D7UX process. Not related to this issue.
Comment #18
David Lesieur CreditAttribution: David Lesieur commentedHere's an updated patch and a screenshot showing how it now looks.
Not sure about the labeling. I'll ask around.
Comment #19
David Lesieur CreditAttribution: David Lesieur commentedThe status selectors are awkward and this UI won't work well with admin/people (which require multiple selections). emarchak has given me good ideas on how to do this well. Stay tuned.
Comment #20
Gábor HojtsyYummy, yum yum yum.
Comment #21
emarchak CreditAttribution: emarchak commentedAs David mentioned in #355820-19: Improve query filter UI on admin/content , we've been spending some time discussing this. Here is the first version of the admin/content screen. The admin/people screen will be coming along shortly.
We have kept the filters as drop down select lists inline with each other, as posted in previous mock-ups. In the previous version, we realized that there would be many usability and accessibility issues with requiring people to select multi items in the select box. Not only is this behaviour confusing, but it's near impossible for people with mobility issues.
What I did is use the select lists as the "label" of the fields, and list the active filters below the labels. Filters can be added by selecting them from the dropdowns, and then hitting "Add Filter." Filters can be removed by clicking on the "X" or the name itself and only the selected one is removed, this is communicated by marking up item as an anchor tag. This is similar to the current version, but adds a bit more functionality than the "Undo" or "Reset" buttons"
In terms of functionality, each of the filters act as an "or" search with in the select lists, and "and" filters between the select lists. This is communicated by displaying "or Filter Item" when a user adds more than one filter item from a select list. The search defaults to "All" when no filter items are selected from the lists. The actual search that is shown in the mock up would be:
AND
AND
AND
AND
Comment #22
Everett Zufelt CreditAttribution: Everett Zufelt commentedPerhaps this UI is too complicated to explain in text, which might mean that it is too complicated :) #21 does a reasonable job at attempting to explain, but it is still unclear to me, in particular:
"What I did is use the select lists as the "label" of the fields, and list the active filters below the labels"
Comment #23
Bojhan CreditAttribution: Bojhan commentedI do wonder, are we actually using the right form elements for this - I know we are set on select lists because its a) a common pattern b) it scales nicely. But its difficult to understand selection of several items and with few items, is better covered by a checkbox. I mean, faceted search is a pretty common pattern - with some tweaking it could very well apply here.
I do really love the thinking that has gone into this, and the overview is really usable. My concerns above a side, we could definitely pursue this. Can you shed more light on your general concept, do you want these filters to be collapsed by default, does the mass operation fieldset make sense? Where do we allow searching of this list to appear on this page?
@Everett Basically all the select lists are aligned horizontally, and each select list for example "Publishing state" has below it the selected option, for example Published. In a way (visually) are the select lists (Publshing states, Sticky states, Content types, Language) the table headers, and are the selected option(s) shown below in a row. Let me know if that makes sense.
Comment #24
Gábor Hojtsy@Bojhan: is it acceptable for you if it does not downgrade if JS is not there? Because we basically need a three-state checkbox here for many things. For publication status lets say, there is "I don't care, given me all", there is "Give me unpublished only" or "Give me published only". That is either a three item radio group / dropdown or a three-state checkbox (the later which is not a native browser control and would need JS). So if we want to have it a checkbox, we need a custom control for this and fall back on the select boxes I guess.
Comment #25
Bojhan CreditAttribution: Bojhan commentedFocusing the issue some more.
@Gabor isn't that the case for any faceted filter?
Comment #26
Gábor Hojtsy@Bojhan: Yes. Do we have any of those in core though that use checkboxes? No. So therefore the question of how to do it. New stuff, need to figure out, right? :)
Comment #27
Everett Zufelt CreditAttribution: Everett Zufelt commentedI am pretty opposed to requiring JS for functionality, but using a select or set of radios, progressively enhanced to a tri-state checkbox might be workable.
We'd need to do some testing with mixed-state checkboxs to see how far back AT support goes. WAI-ARIA provides an checked state, but I don't know how well it is supported.
See http://www.paciellogroup.com/blog/misc/ARIA/tristatecheck.html
Comment #28
Gábor HojtsyI'm not sure people understand tri-state checkboxes even. This is one of my favorite interview questions: please code a tri-state checkbox widget. Most people are stumbling on even finding out what it is. Do people understand them?
Comment #29
jhodgdonA title keyword filter (for nodes) would also be desirable. See #497804: [meta] Search entities (nodes, terms, etc.) within the administrative interface for discussion.
Comment #30
Gábor Hojtsy@jhodgdon: yes, this issue is about cleaning up the UI as in now so it can accommodate that filter and a user author filter better. :)
Comment #31
David Lesieur CreditAttribution: David Lesieur commentedHere's another proposal that:
The filter removal links in this screenshot are ugly, but would be overridden by the administration theme to use nice icons.
The patch is very rough and breaks admin/people. I'll refine it if we want to go forward with this interface.
Comment #32
jhodgdonI like this mockup, but why are Type, Status, and Language still available after already being specified? Does that allow you to change them from their current values? I was obviously confused by this... just one usability data point...
Comment #33
David Lesieur CreditAttribution: David Lesieur commented@jhodgdon: I had this described in @todo comments in the patch but forgot to mention it in #31. My idea was to remove options that do not make sense. If a language or type option is already active, no language or type selector would be offered. If a status option is selected (e.g. "sticky"), that option and any mutually exclusive option would be removed from the status selector (e.g. "sticky" and "not sticky").
One thing I'm not sure about is whether to leave the status selector alone, or to split it into "Publishing state is...", "Sticky state is..." and "Promoted state is..." (as in #18 and #21). Splitting might make things easier to understand by users, because then all selectors would behave the same way with respect to active filters.
Comment #34
Gábor HojtsyI think making them separate is easiest on users.
Comment #35
Gábor Hojtsy@David: are you working on this? That would be fabulous!
Comment #36
David Lesieur CreditAttribution: David Lesieur commentedSorry for the delay. I'll resume work soon!
Comment #37
naught101 CreditAttribution: naught101 commentedAnyone have any good evidence/links/reasoning for not using multi-select boxes with something like that done in #21? I think the assumption in the current discussion is that they don't work well with screen readers/keyboard navigation, but after a quick web search, I didn't find much, which is surprising, considering that they're a pretty widely used device. That kind of indicates to me that they're at least somewhat useable to keyboard users. I'm not claiming that's true, nor that it's not, I'm just suggesting that we get some evidence in before making a decision. Especially as that decision potentially involves introducing relatively new, and less well understood (and tested) interface devices.
Comment #38
David Lesieur CreditAttribution: David Lesieur commented@naught101: What I intend to work further is more like #31 rather than #21. Instead of introducing a new UI device, it simplifies the current one.
Comment #39
Gábor HojtsyAssigning to Bojhan for updated UX feedback. @Bojhan: we are looking to see your opinion on #31 and #21 and which one would work best, or you have better ideas for a third approach :) You've been advocating checkboxes above. I'm not sure a mixed set of checkboxes and select boxes would look good / clear. Would it?
@David Lesieur: Bojhan's feedback above basically is that we split the dropdowns per functionality (which I'd agree would simplify the filter UI).
@Bojhan: what about splitting this to distinct dropdowns for now and explore replacing three item dropdowns (don't care, yes, no) to tri-state checkboxes later once/if core has tri-state checkbox UI solutions? (We don't have that now that I know).
Comment #40
Bojhan CreditAttribution: Bojhan commentedI am very concerned, the approaches proposed are still far from thoroughly researched approaches (not very usable). I would love if we can review some of the existing solutions for this(in and outside Drupal), rather than straight of the bat inventing our own ones. Say, 10 different tools that provide this kind of filtering.
#21 Is the best one so far, because it isn't a direct boolean interface. I don't care so much for having or not having tri-state checkboxes. I am not really keen on designing a third solution, before we have done some research.
Comment #41
David Lesieur CreditAttribution: David Lesieur commentedIf we want the ideal interface, then we should probably look into integrating a faceted search pattern in core (Bojhan has mentioned this in #23; I like!). But I'm afraid we'd only get there in a far future.
Or we could pick a lower hanging fruit by going the easy way of an incremental improvement to the current UI, as hinted by #31... ;-)
Comment #42
Gábor Hojtsy@Bojhan: is there a larger scale plan to work on this? I'm interested in this to be able to serve as a translation dashboard too, and incremental improvements would be great for that too. If there is no overall work being done, is our current system better than the ones proposed above?
Comment #43
Bojhan CreditAttribution: Bojhan commented@Gabor No big plans, but in general I want us to think big rather than small in this brainstorm phase.
Comment #44
Gábor HojtsyTagging for the content handling leg of D8MI.
Comment #45
yoroy CreditAttribution: yoroy commentedLinking back to #1475204: [META] Provide a generic search/filter UI interface pattern for listing pages
Comment #46
klonoshttp://drupal.org/project/instantfilter
#1475204-5: [META] Provide a generic search/filter UI interface pattern for listing pages
Comment #47
drupalvino CreditAttribution: drupalvino commentedHi,
Im using drupal 7. In my case, I need to filter the contents by content type fields in admin>content.
Any idea about this. Is there any contributed module for this.
Plz guide me. Its very urgent.
Comment #48
yoroy CreditAttribution: yoroy commenteddrupalvino: this is not a support channel, your urgency is not our urgency and certainly do not cross-post the same question across multiple threads.
Comment #49
yoroy CreditAttribution: yoroy commentedDrupalvino, I apologize for being too harsh there. Klonos did better in his reply in the related issue.
Comment #50
drupalvino CreditAttribution: drupalvino commentedYoroy, Its ok. Its my mistake too. I am new in drupal and drupal.org. So I dont know how to ask my doubts. Thats why I asked here. Here after I'll post in forum. Sorry for disturbance. Thank you.
Comment #51
Noyz CreditAttribution: Noyz commentedSeems there's some cross over in the mockups I just posted regarding the find content UI: http://groups.drupal.org/node/219099
Comment #52
Gábor HojtsyD8MI is not going to resolve this.
Comment #53
tkoleary CreditAttribution: tkoleary commentedI have a new prototype for this which is based on work done by myself and dawhener at Bad Camp but with updated styles from Seven style guide.
The prototype is here: http://invis.io/R8F4K2BC
It's also posted in this issue: #1475204: [META] Provide a generic search/filter UI interface pattern for listing pages
Comment #53.0
tkoleary CreditAttribution: tkoleary commentedUnfollowing this issue seems to be broken since I am the original author, changing the author to Abandoned Projects, please feel free to change it to someone more appropriate for this issue.
Comment #54
xjm(Merging "node system" and "node.module" components for 8.x; disregard.)
Comment #65
quietone CreditAttribution: quietone at PreviousNext commentedThanks everyone for working on improving admin/content.
This is no longer relevant since the page is a view in Drupal 8.0. Closing as outdated.