57

Currently in Dolphin it is easy to filter by specific text, or regular expressions that novice users won't be able to use, but to search by other criteria like date, file type (without regular expressions), permissions, and other such characteristics is not as easy. So one of my major goals was to come up with a way to accomplish this. As I said earlier, this method should also work equally well if you combine the filter and search bars, but even if you decide to make a separate search bar these special filters would still be just as useful. My proposed solution is below. This is probably the longest idea, so please bear with me.



The important part is the “More” text on the far right. This is a button, but a unique button that I have not seen elsewhere in KDE or Qt. It has a double arrow on the left side and an up arrow on the right. This is the result you get when you click the “More” text or click the up arrow on the right:



This menu shows the various special filters that are available. Each entry allows you to filter a folder by that specific criteria. Clicking one expands a sub-menu that allows you to set that filter. The “Advanced...” entry at the top, which is from bcooksley's recommendation, opens a dialog box that allows you to implement even more sophisticated filters (there is no mockup of this). I will cover the specific filter sub-menus in more detail later.

Also notice the two arrows pointing to the left. These cause the button to expand as if it were a collapsible toolbar. It expands into something like this:








These are three different ways that it could expand. These are not all meant to be implemented, I just could not figure out for certain which one would be best so I made mockups of them all. If the Dolphin developers decide to implement this they would also have to decide which one they prefer. The buttons all open the same submenu you would get by clicking the corresponding entry in the menu you would get by clicking the up arrow.

The first mockup causes the button to expand to the left into a small toolbar, shrinking the filter bar as it goes. The left arrow then switches to a right arrow, and the toolbar will remain in place until you click that button again. This is probably my favorite, since it allows you to set multiple filter more easily and allows people who prefer to keep the special filters available all the time can do so. This is also similar to my original mockup, which had a non-collapsible special filter toolbar. bcooksley rightly pointed out that this was too crowded.

The second mockup is similar, except that clicking outside of the toolbar causes it to automatically retract again. As such the arrow button does not change.

The third mockup saves horizontal space while having the drawback that it expands into the file browser area and covers part of the scroll bar. Like the previous mockup, clicking outside of the toolbar causes it to collapse. This is my least favorite.

Although the up button and side button are combined in this mockup, there is no reason they would have to be in the final program. I know they are redundant, I combined them here to make my work a bit easier. If the Dolphin developers like this idea they could implement just the expanding toolbar, just the menu, or both.


Next, take a look at the filter bar itself in this picture:



Notice that the “clear” button has moved to the left and “Folder” and “html” have appeared to the right of it, along with a small “x” next to each. This is how the user is told which special filters are currently in place. Any special filter you add will be included here. Clicking on the “x” button allows you to remove individual special filters without going into the special filter sub-menus and randomly resetting them. The "clear" button has moved to the left of the special filters because clicking that button will only clear typed filters, not special filters. They have those x buttons so I thought having the clear button clear the special filters, which are harder to set up, would increase the risk of frustrating errors while not significantly increasing the efficiency of the interface. Also notice that the file browser area is now blue. This is because of color-coding, I will go into more detail on it later.


Next, I will discuss the specific filters:

In the filter menu mockup above you can see that someone has clicked the “Type” entry. This allows the user to only see the file types they want. With all of these filters, the filter will be restricted to only those options that are actually present in the folder. So this folder has a subfolder, html documents, and PDF documents. The “text” at the top is a mimetype category. It allows you to show or hide all text files, including PDFs and html files (since they are considered part of the text mimetype category). By default, all file types and mime types are checked. A filter is only applied if you uncheck one. If you uncheck on file of a certain mimetype category, that mimetype category becomes unchecked (as here, where PDF is unchecked but html is checked). If the text mimetype were checked and you clicked it, it would also uncheck all of the file types that are a member of that mimetype category (in this case it would uncheck PDF and html). If the text mimetype were unchecked and you clicked it, it would also check all of its member file types (in this case it would re-check the PDF type while leaving the html type checked).


Here is the one fore file sizes:


It defines a range of file sizes, so it uses the Plasma right and left limit sliders used for setting the width or height of a panel. It goes up to 2 TB here, which is the limit for Ext3 filesystems. The real limit would depend on the largest and smallest files in the folder. Notice that it has evenly spaced 1B, 1KB, 1MB, 1GB, and 1T points. This is because the slider is actually on a logarithmic scale. This is invisible to users, but 1B, 10B, 100B, 1KB, 10KB, 100KB, 1MB, 10MB, 100MB, 1GB, 10GB, 100GB, and 1TB are all evenly spaced along the length of the slider, as opposed to 1B, 11B, 21B, 31B, etc being evenly spaced (at least in decimal mode, more on that later). All the user will see is that as he or she moves the slider from left to right, the amount of increase in file size that moving the slider one pixel will cause gets larger. There is no way that I can tell to cover the whole range of possible file sizes on a linear scale, and once again the user does not have to know that it is using a logarithmic scale or even what a logarithmic scale is, it should be intuitively obvious after a using it for few moments that the scale shifts. The text boxes reflect the exact value for the slider, and are natural language (i.e. 1000, 1000B, 1000 B, 1KB, 1 kilobyte, 1 KB, .001 MB are all the same). The drop down has two option, Binary and decimal. In decimal mode it uses the same units as SI, so 1KB=1000B, 1MB=1000KB, etc. This is the method used by hard drive manufacturers. In binary mode, it uses base-2 numbers, so 1KB=1024B, 1MB=1024KB, etc. This is how many filesystems do it natively. I do not know which is better as a default. This also works with the natural-language function. If use, for example, 1 KiB, 1 kibibyte, 1KB binary, or binary 1KB, it will always use binary mode no matter what the drop down says. If you use, for example, 1 decimal KB, decimal 1KB, or 1 KB decimal, it will use decimal mode no matter what the drop down says. If you use 1KiB binary or 1 KB decimal binary, it will return an error because you are contradicting yourself. The up and down arrows also work with the natural language function, and they change the smallest significant figure that is actually typed out. So if the text box says 1000, pressing the up arrow will change it to 1001. But if you have 1KB, pressing the up arrow will change it to 2KB. If you have 2.00 KB, pressing the up arrow will change it to 2.01 KB.

The next one is the permissions filter:

This one is pretty straightforward, it just checks the different permission bits of each file. The first is for the user access permissions, the next is for the group access permissions, and the final is the permissions for everyone. This uses the same terminology in the file properties dialog box. "Yes" only shows files that have that permission bit on, "No" only shows files that have that permission bit off, and "either" ignore that permission bit when doing filtering. The default (i.e. no filter) is to have them all set to "either".

These next two are the date and time filters. The first is what you get when you first open it (if today were February 4, 2009):


The next assumes a later date, and show how you set a range of dates:


The first thing to notice is the check boxes at the top and the bottom. These allow you to filter everything after a certain date, before a certain date, or between two dates. So as you can see in the first picture, if you have "From" checked but not "To", it will show all files created after the date specified in the "From" box. The "To" box is grayed out and shows "Now" to tell the user it filters everything after the specified date, and the area highlighted in the calendar is green to show that it goes on forever. It is green because "From" is where the search starts. Similarly, if you check the "To" box and uncheck the "From" box (not shown), it filters everything before the specified date, the "From" box is grayed out and shows "Forever", and the area filtered is red since the To box is where the filter stops. If you have box the "From" and "To" check boxes set it filters all files between the specified date. That is inclusive, it includes that date specified on both end. The area highlighted is blue, to signify it is a range. If you uncheck both boxes (not shown) it highlights the entire calendar in gray and says "From Forever" and "To Now". If you start using tags for filtering, which could potentially have dates set in the future, it might bet better to use "From Any Time" and "To Any Time". You can click on one of the text boxes and then click on a date on the calendar to set the date for that check box. If only one check box is set then you don't even need to click the text box, it will automatically be selected.

The text boxes deserve some further explanation. They are nature-language searches, like the file size boxes. So for instance if you have your short date formate set to m/d/y, then Feb 4 2009, Feb--4---2009, 4--Feb--2009, 2009-4-Feb, 2/4/2009, 2, 4+2009, 2009/2/4 2/4/9, day 4 month 2 year 9, and 35/2009 are all the same. There are a few separate issues at work here.

First, in cases where there are ambiguity the date format set in your personal settings is assumed. So for 2/4/9, it knows you have set the first number to the month, the second to the day, and the third to the year, so it uses that. For years it is assumed that you are talking about the current century or millennium when there is ambiguity, up to the present day, and if that doesn't work go with the most recent past century or millennium. So year 9 is treated as 2009, while 11 is treated as 1911 because we have not reached 2011 yet. If you want to specify 11 AD, you need to use 0011. If you want to specify 2011, you need to write it out completely because 011 will be treated as 1011.

The next thing is that any number greater than 365 is assumed to be a date. So if you set 2009/2/4 it first sees that 2009 is a year, and sets the year to that. Next, it compares 2/4 to your short date format and sees month comes before day, so it sets 2 to the month and 4 to the date. This would work even if your short date format is m/y/d since month still comes before day. This is NOT the case with dates larger than 12 being counted as days. The reason is as follows. Lets say that is how it works and you use 18/2/2009 even though your short date format is m/d/y. That would seem clear enough, since there is no month 18. But now lets say someone thinks "oops, it was really the 7th I was looking for" and, without thinking it through, sets it to 7/2/2009. Now suddenly it changes to July 2 2009, since there is a month 7. I think this would lead to too many users errors, errors that are less likely with the year but very likely with the month and day. So if you set an invalid month it will return an error.

Next, that the delimiter is completely ignored, it doesn't matter whether you use a dash, comma, space, slash, &, or any combination therefore. The only things you cannot use is a colon, which is reserved for times (more on that later), and alphanumerics (which would be infeasible for the program to deal with).

Next, when there are only two numbers, both less than or equal to 365, it is treated as the month and day of the present year if it is from today or before, and if it is for a date that has not yet happened in the present year it is treated as that date from the previous year. If there are only two numbers one greater than 365, it is treated as the absolute date of that year, so for instance 35/2009 will be day 35 of the year 2009, or February 4 2009.

Next, you can spell out what you mean explicitly. So for instance you can say "day 4, month 2, year 2009" to force it to use certain numbers for certain values. As another example "day 4 2009" would be the 4th day of 2009, or January 4 2009. AD, BC, CE, and BCE are also acceptable when specifying dates, with or without periods. It also follows the proper rules for your calendar.

As for the time, you can also specify a time before or after the date using colons as delimiters. Similar rules apply, if you set h:m:s, then "10:" is treated as 10 AM, ":5: PM" is treated as 12:05 PM, and so on.

A "hidden" feature is the "Ago" function, which searches for events a certain amount of time in the past. So, for example, if you type "2/4/9 ago" it will set that as 4 days, 2 months, and 9 years in the past. Note that in this mode there is no assumption about the year, so 9 is not interpreted as 2009, 11 is not interpreted as 1911. The year is used literally as it is written.

Like all of the filters, the clickable areas of the calendar will be restricted only to date present in the folder you are looking. You can manually set the date outside this range in the text box, but the calendar will not let you click it.

The final thing is the radio buttons on the bottom. Those tell it whether you are searching for the date the file was created, the date it was modified, or a date present in its metadata tags (once Nepomuk is working properly).



This is part of my series of Dolphin ideas

I think this is too complex for file browsing. And KFind already does all (well, most of) this for searches.

What I think would be nice for Dolphin, however, is easily accessible filtering according to a generic type (i.e. "images," not only one of "gif," "jpeg," etc.; or "text documents," not only "txt" or "odt"). You idea of a filter bar could be very helpful in this case.

mutlu wrote:I think this is too complex for file browsing.

It is a lot less complicated than trying to filter with regular expressions, and the only way to filter by date or file size. In practice it really shouldn't be very complicated, you just slide the slider for the file size, check boxes for file types, click the dates you want for the date, etc. Also, vista's explorer already has this (although it is not as well-done IMO), so it is already in at least one file browser.

mutlu wrote:And KFind already does all (well, most of) this for searches.

First, as you said kfind is searches not filtering. Second, kfind is not integrated into dolphin at all, it is a stand-alone program.

mutlu wrote:What I think would be nice for Dolphin, however, is easily accessible filtering according to a generic type (i.e. "images," not only one of "gif," "jpeg," etc.; or "text documents," not only "txt" or "odt"). You idea of a filter bar could be very helpful in this case.

This is already in my idea. Look for the part talking about mimetype categories.

TheBlackCat, I am aware that you proposed filtering by generic mime types. I actually think that this is a really good idea (even though I may not have expressed it very well). I would certainly vote for it if it was a standalone suggestion. I believe that filtering by (generic) file type is really helpful for all kinds of users on a day-to-day basis.

Filtering by using all other criteria, however, seems (user interface-wise) overkill to me. I don't dislike your mockup per se, but I strongly fear it would confuse most users and impede the discoverability of the mime type filtering function.

You might ask why I believe that are file types more important. Two reasons:

First, it is currently not possible to sort according to a generic file type. "Gif," "jpeg," etc. are spread throughout the view if a user sorts by mime type. This is not the case when sorting by size, date, owner or permissions. A simple sorting usually reveals what one looks for.

Second, I believe that file types searches (I use the word "search" in a very generic term; ultimately, filtering is searching as well) are much more common than other searches.

I still disagree.

First, there is no reason that we couldn't allow people to sort by mimetype categories as well. You could always submit a request for that feature here if you thought it was that important.

Second, for small folders yes sorting is probably sufficient, but if you have a folder with thousands of files it is far from helpful. Of course if users keep their stuff well-organized that is not a problem, but you can't count on users to do that and you shouldn't punish them for it.

Third, you personally think it is much more common than the other searches, but unless you have some concrete evidence to back up it is just your opinion. I have no problem with the current sort by filetype. I think I would personally use the date filter most often, since I generally know the file type of the file I am looking for. I also tend to organize my directories by file type category in the first place, so I rarely have heavily mixed folders. It all depends on how you use the file browser, how your memory works, and how you organize your files. A filter that is essential for one user might be almost useless for another. That is why we need them all.

Fourth, we are talking about 6 buttons vs one button, if users can't find what they are looking for in my structure I think it is unlikely they will find it if was just mimetype category. This is just a guess, but I think the sort of user who wouldn't bother to click a couple of buttons down there to see what they were probably wouldn't click one button, either. I actually think it might be more noticeable, since there are more buttons there (or a single, larger button). You would need a mimetype button either way.

Fifth, if you combine this with my search bar/filter bar combination idea, this layout become much more essential because searching for files in a certain date range, certain file size, or other similar properties is important when looking over your entire hard drive.

Sixth, as I already said it is already available in one of Dolphin's major competitors, so it is needed for feature parity.

TheBlackCat wrote:Third, you personally think it is much more common than the other searches, but unless you have some concrete evidence to back up it is just your opinion.

Why did I expect this reply...? This is indeed the weak point of my argument.

TheBlackCat wrote: I have no problem with the current sort by filetype. I think I would personally use the date filter most often, since I generally know the file type of the file I am looking for. I also tend to organize my directories by file type category in the first place, so I rarely have heavily mixed folders. It all depends on how you use the file browser, how your memory works, and how you organize your files. A filter that is essential for one user might be almost useless for another. That is why we need them all.

Fair enough. I concede.

nice input from you, theblackcat. hope to see several of your innovative ideas to get integrated.

I have a few ideas to expand on this:

• You could group a filter together into a named filter combining any of the available options, like "Old images" or "Large iso's".
• These filter groups could be user/system wide like places.
• By default available filter groups would be simple mime-type accumulations like "Images" and "Documents" that are easy to understand and use.
• Multiple of these filter groups could be active at one time, and add to the current selection, visible in the filter bar as in your mockup. This should be really easy to do, ie. minimise clicks to add multiple filter groups.
• Filter groups could reference other filter groups and make slight changes, so users can simply create the "Old Images" filter group with a few clicks for example.
• Because these conditions define everything needed for search except the location, these should tie into searches to prevent both code redundancy and users having to learn two interfaces to the same thing.

Possible bonus rounds:

• Text filtering for all fields, such that I can type "group:images modified:before:2008" in the filter box quickly and have it work. This also allows easy posting of useful filters on forums and blogs everywhere. If you could import a filter based on a string it would really easily allow sharing and storage.
• A commandline client that allows access to filter groups and searches and returns filenames from the current directory for filters or absolute filenames from searches. This would also have a recursive option and even better a find style --exec option for working with filesets.
• The filter change panel works like the plasma panel configuration in that it pops over content, but can be clicked unlimited times without it dissapearing. This seems to be a really efficient UI mechanism.
• Much of this could be implemented shared code and widgets for use in things such as KMail (Mailody?) that have their own filter implementation. This has the obvious benefits of consistency and reduced code redundancy but would require a fair bit of work.

That really seems complex search functionality. The Dolphin has just the filter bar, not search bar.

And I think that should be done smarter. Like digiKam has smart filter-bar. You can type anything to filter view and it shows the photos on that view what has the filtered text on it's metadata etc.

So you should be able to filter on Dolphin just by typing "images" to to filter all that MIME-type class files. Or all files with owner by name or number when typed. So like typing 501 shows all the files what has somekind metainformation of 501 or UID/GID 501.

Then the actual search should be made trough nepomuk and it should be as easy just type what you search. No need to select any other information like "search only by Images".

It sounds a bit complicated, but in principle i like this.

Fri13 wrote:So you should be able to filter on Dolphin just by typing "images" to to filter all that MIME-type class files. Or all files with owner by name or number when typed. So like typing 501 shows all the files what has somekind metainformation of 501 or UID/GID 501.

How do you differentiate between file names containing the text "images" and image files? This is especially bad if you filter by all the file metadata. For instance, if you include all the file metadata, there could be any number of different metadata tags that might contain the string of digits "501" somewhere in that tag. You could very easily end up with a large, perhaps unmanageable, number of false positives especially for large directories.

Fri13 wrote:Then the actual search should be made trough nepomuk and it should be as easy just type what you search. No need to select any other information like "search only by Images".

This is even worse. If you search your entire hard drive for any file with the characters "501" appearing at any point in any tag the number of results would likely be unbelievable. I think we really need a way to limit the search only to certain metadata fields if we want nepomuk to be even remotely useful.

Fri13 wrote:That really seems complex search functionality. The Dolphin has just the filter bar, not search bar.

Actually Dolphin (at least in trunk) has a nepomuk based search bar.

And I don't think the user interface for this would be particularly complex.

[quote='TheBlackCat' pid='55011' dateline='1237689801']

mutlu wrote:I think this is too complex for file browsing.

It is a lot less complicated than trying to filter with regular expressions, and the only way to filter by date or file size. In practice it really shouldn't be very complicated, you just slide the slider for the file size, check boxes for file types, click the dates you want for the date, etc. Also, vista's explorer already has this (although it is not as well-done IMO), so it is already in at least one file browser.

mutlu wrote:And KFind already does all (well, most of) this for searches.

First, as you said kfind is searches not filtering. Second, kfind is not integrated into dolphin at all, it is a stand-alone program.

I agree with this...
The search must be integrated to dolphin and even the kickoff menu or Krunner

TheBlackCat wrote:

Fri13 wrote:So you should be able to filter on Dolphin just by typing "images" to to filter all that MIME-type class files. Or all files with owner by name or number when typed. So like typing 501 shows all the files what has somekind metainformation of 501 or UID/GID 501.

How do you differentiate between file names containing the text "images" and image files? This is especially bad if you filter by all the file metadata. For instance, if you include all the file metadata, there could be any number of different metadata tags that might contain the string of digits "501" somewhere in that tag. You could very easily end up with a large, perhaps unmanageable, number of false positives especially for large directories.

Fri13 wrote:Then the actual search should be made trough nepomuk and it should be as easy just type what you search. No need to select any other information like "search only by Images".

This is even worse. If you search your entire hard drive for any file with the characters "501" appearing at any point in any tag the number of results would likely be unbelievable. I think we really need a way to limit the search only to certain metadata fields if we want nepomuk to be even remotely useful.

why not to use gmail style search?
like to filter all pictures with keyword "cool", created within last 5 days, owned by my, size less than 10mb but greater than 700kb

Code: Select all

cool mime:picture date:+5days user:lukas size:+700kb size:-10mb


since so many conditions would be user not very often, i don't feel it would be too complicated to write


p.s. also recursive search would be cool

There are two problems with that. One, it is not easily discoverable. How do you find out what the keyword are and what their syntax is without looking at the help file? Second, it requires memorizing the keywords, something I do not think we should expect ordinary users to do. Of course that could be an option for advanced users, and probably deserves a separate thread, but I think it is unrealistic for ordinary users.

One of the overriding goals of my series of dolphin ideas was to make things simple and easily discoverable by users. One of the main ways I thought to do that was avoiding anything that requires memorizing keyboard shortcuts, keywords to type in, or reading help files to find when there is an alternative solution that is small, noticeable, and intuitive to use. If the user doesn't know it exists, they aren't going to go looking for it in the help files, and expecting every user to read the entire documentation in order to learn that a feature even exists is unrealistic in my opinion. Your idea, although good for advanced users, amounts to a hidden feature that I don't expect ordinary users will never realize exists.