I've been doing some work on the node administer form at admin/content/node, to move the filter storage from a session to $_GET params in the URL. This could have several benefits:
- The filtered pages are then bookmark-able and shareable
- The filters will be reset every time a user navigates away for an extended period of time, or through multiple pages
There are also disadvantages:
- The undo option won't work any longer as we aren't storing the filter in an stack/order they were applied
- The filters will not be persistent until reset
A little more explanation on the persistence of the filters. Right now they are stored in the users session until they either log out, or they click the reset button on the form. At least for me, sometime I forget that these filters are in place and spend time looking for content that I previously filtered out (in a previous day using the site, for example). With using $_GET params, they are stored as long as the user stays on that page and uses the pager at the bottom, and they are persistent when clicking a link to edit a node, and submitting, returning to the node admin page.
About the inability to have an undo feature: Since the items are not stored in an array/stack anymore it isn't possible to determine what the last filter applied was. One obvious workaround for this, at least to me, is to add a button/link next to the display of each currently applied filter, to remove that filter. I would consider this a usability improvement over the current undo/reset method, as filters could be removed individually, without multiple undo or reset/reapply actions. (Also note I have observed users unsure of the difference between "Undo" and "Reset" as well, as either verb could apply to the whole set, or the last filter only)
So my question to the usability team are this:
- Overall, would this be considered a usability improvement, to be non-session persistent, and bookmark-able/shareable?
- Would individually removable filters be an improvement over the current system?
- What are the considerations for the UI for individually removable filters? Would someone like to work on a mockup?
Attachment | Size |
---|---|
node-admin-filters.png | 20.96 KB |
Comments
There's already a discussion
There's already a discussion going on about node administration over here: http://drupal.org/node/301902. Maybe you can share your ideas with them?
I don't think it'd be best
I don't think it'd be best to chime in on that issue yet, as
a) This is will eventually be a rather large patch, that is unrelated to the patch there
b) I'm not sure what the best interface for this is
c) I have a feeling that this grand of a change needs to be run through the usability team anyway (that's why there isn't a d.o issue yet)
Talked about this in IRC
Talked about this in IRC today and yoroy mentioned http://img.skitch.com/20090108-xxyhje7srxfhnhpckj37g8212y.jpg as an ideal interface. This makes sense to me, with a few exceptions.
In iTunes this dialog is brought up to start a new playlist, presumably on admin/content/node it will be sitting there until someone applies a filter, so I need to have some idea what the default values would be.
Also in iTunes this is in a dialog box that is then saved/dismissed to view the results. What would be the ideal process in this case, to tell Drupal to apply the filters and reload the page?
Mind you, I never said it
Mind you, I never said it would be the ideal interface, just that I was reminded of the smart playlist builder in iTunes! :)
Though in this case the "filter stack" is not hierarchical, another concept that might work here is something like the Hierarchical Select module UI.
I'llave to think about this some more…
Well maybe to me it came
Well maybe to me it came across as an ideal interface. ;)
Provided we solve the initial values and submitting the filters issues, with a healthy dose of AHAH, this could be *REALLY* nice.
I can also see adding more filters if we can get the query builder to support them, such as author, title, date, and so on as well as operators (contains, or before, after, and so on).
I really like the
I really like the hierarchical select interface, and think it could work well here. Having said that, even just separating the filters out in the way views exposed filters look like would make it a lot easier to deal with.
So here are my initial
So here are my initial ideas. (Please be patient as there are rough mockups in graffle, so the fieldset is probably sized wrong and layout may be off.)
Picture 1, the default state of the form.
Picture 2, the user has clicked "Add filter". This caused the "Apply filters" button to appear and the message to appear regarding clicking the apply button.
Filter types, operators, and allowed values
Status (is, is not) (dropdown of published, sticky, promoted)
Type (is, is not) (dropdown of all content types)
Taxonomy (is, is not(!!not sure how this would work, but would like to try!!)) (term browser as we have now)
Title (is, is not, contains, does not contain, starts with, ends with) (textfield (is and is not should be an autocomplete))
Author (is, is not, contains, does not contain, starts with, ends with) (textfield (is and is not should be an autocomplete))
Date (is, is before, is after, is between) (textfield maybe with a date picker widget (between would actually be 2 textfields))
Language (is, is not) (dropdown of all languages)
Questions
These are the questions that I have as of now. Obviously everything is open to change, but this is the general idea.
I'm already thinking the
I'm already thinking the "Add filter" button should be called "Add new filter" or just "New filter" to prevent confusion with the apply button.
I'm already thinking the
I'm already thinking the "Add filter" button should be called "Add new filter" or just "New filter" to prevent confusion with the apply button.
Counter-screenshots. :D
(Note: I ignored everything else in this thread and just reviewed the screen shots so that I'm "untainted." Apologies if I am re-hashing things that have already been said.)
Let's contrast this with Finder, which I think is what you're trying to emulate here:
I'm not sure what to propose as a "alternative" screenshot though. It's a tricky problem. Here's a rough idea which I am in no way married to:
Not sure. What do you think? A big challenge is making this degradable for people without JS. No idea what this would look like then... Hrm.
I much more like your
I much more like your screenshots. I didn't break mine up that much, although I am describing similar functionality. Two questions:
Does the next empty dropdown appear as soon as the first filter is selected? Use case: I want to configure 3 filters, then click apply without waiting for page loads in between all of them. This should be doable, but then do you have 3 Apply buttons next to each filterset? Which one do I click?
What happens when I get the filters wrong and change them? Do we then show an apply button next to each filter that I change?
This is why I think a global "Apply" button might make more sense. The best approach may be to just hide the apply button until a change is made to the filters.
Also, re the width of the dropdowns: They are intentionally wide because if we add some new filter types the operators could potentially become quite long. Compare "is" to "is not" or "contains" and maybe even (if I can figure out a way to write the query(shouldn't be to hard)) "does not contain". This would allow all the columns to line up. See the sample below:
I was thinking AJAX page refresh
So the table effect would be "instantaneous," rendering both of those concerns moot ("in theory" ;)).
Personally, I don't like the idea of building a big list of filters and not knowing what I'm getting until I click "OK." I like progressive reinforcement of what I'm doing. In your iTunes screenshot, if I didn't have any > 180 BPM tracks, for instance, I would want to know that immediately, before I enter another filter criteria. Otherwise, when I end up with no tracks in my filtered list, I'm not sure which of the three criteria was the reason, and I have to start over from scratch.
The width thing makes sense. I forgot to mention that one of my very favourite things about using select lists instead of the current ugly radios for this is the potential for other modules to add their own stuff here. Some very powerful things possible. So kudos for that!
Screenshots
Those are sweet looking. What application did you use to mark them up??
Cheers,
Neal
cool
http://drupal.org/node/265941
Some great proposals here. I especially like webchick's proposal.
Something that's always been missing from the page is a simple text search (over text+body+fields). The "Project" module does this well (ie. the issue tracker on drupal.org - ie. http://drupal.org/project/issues/search/drupal )
Emulating the iTunes smart playlist would be awesome - the "X items per page" option would be very good to include.
One of the problems with the current setup is that it's possible to filter for mutually exclusive properties - ie. you can add a filter for "published" AND a filter for "Not published", and you get no content. This wouldn't be a huge problem if there was a remove button, I guess.
It might also be worth having an "AND/OR" selection - this would make it possible to search for content in multiple categories at once.
there's also this:
there's also this: http://www.d7ux.org/content/comment-page-1/
nice "find content" interface
Cross referencing
The issue for this discussion is here: http://drupal.org/node/355820
Screenshots
Wrong comment thread, sorry
subscribing
subscribing
Filter contents by content type fields
Hi,
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.
Use Views Bulk Operations to make a custom content listing
Hi Drupalvino,
I recommend using Views for this. You can build a custom content listing, showing any fields you choose as table columns. Exposed filters will allow you to narrow your list by field value.
If you need any help setting up Views, check out the NodeOne learning video series, especially the episode about exposed filters.
Views Bulk Operations might also interest you. It adds customizable "bulk operation" tools to your view. Configuration can be tricky, because VBO is a powerful module and there are lots of ways to use it. It's a lot of fun though :-)
VBO includes a ready-made specimen view (content2) to get you started. it's similar to the the D7 content listing, but you can customize this view to meet your needs. Keep in mind that not all content types have the same fields. It might be a good idea to make a separate view to administer a particular content type.
(Subscribing)
(Subscribing)