This thread will deal with suggestions related to the search function in OneSwarm. This includes the results returned from a search, how you can handle them (what you can do with them).
- Thoughts on searching/results/downloading -(2 posts) (1 voice)
There should be a checkbox to the right of the main search field that reads "Advanced". When checked advanced search options will be shown, otherwise hidden.
These options could be presented directly below the main search field, preferably as compact as possible. It would be best if the options are local for each opened search tab.
Depending on how the search system is built these advanced search options could just work as a filter of received results (updated in real-time) or they could be passed along with the search, so that no other results are returned other than the ones you are looking to find. The second alternative would decrease the traffic some over the OneSwarm network since not so many results are needed to be returned, however the first one will not only be easier to implement (its a interface thing only) - the user will also be able to see exactly how many results he is filtering out and can change the filter to show more files after the results has been returned, saving him from doing another search.
Some suggestions on what advanced search options to include:
* Selection of what types of files to search for.
Could be a list of elements, where the user can select none (to search for all types) or one or more (to only search for those types). The list could be long, but not tall in pixels to save space (use scroll bar in the list). This will allow the user to only search for music files/movie files/image files/archive files/document files/etc, or combinations. When hovering a element there should be some text describing what file type are included in that particular element (for example the "music files" element could show "mp3, wav, ogg, flac, xm" and so forth).
* Must not be in file name.
A second field for words that must not appear in the file name would be extremely useful, separated with ":". This will allow the user to for example search after "music files" but not files containing ".mp3", or search for "bookname karlsson" (in the main search field) and then filter away all results where the book author has "johan" in its name.
* File size.
Bigger than, smaller than, equals to, between X and Y in size. If the user knows it is only looking for files in the 20-50 MiB range it would be good to be able to filter away the perhaps hundreds of files bigger or smaller than that.
* Collection name search.
Should the search look in the file name or collection name, or both? Perhaps an option to search tags exclusively would also be proper.
These are a few advanced options I can think of straight away.
Other features I would like to see:
- After clicking on a result and getting the details window (the one containing the download button) you are downloading the whole collection by default. There should be a checkbox/button that you can tick/click to only select the file you clicked on from the collection. This will save quite some headache, sometimes you only wish to download one audio file from a collection that contains thousands of mixed audio files. Right now you have to manually locate the file and tick it in the "files" tab (after pressing the "select none" button that is at the bottom - these buttons should be moved up top).
- "More files from those that has this collection." Or something. When selecting a result it sometimes would be nice to be able to browse the user(s) that has the collection where the file is located. This in order to find related files. I understand that there is a privacy issue here, but perhaps it can be worked around. You could have a "Find related files" option for each result, if selected a new search tab will be created which automatically searches for related files to the one you clicked. These related files will be found by the following criteria: The files have the same tag(s) as the one you clicked, and the related files are shared by someone that shares the collection where the file you clicked belongs. This will allow you to "browse" a part of someone's share without it meaning that you are seeing files exclusively from his share - they can belong to anyone but was originally created with the same tag(s) which makes them related.
Here's an example of the above point: You search for "meat" and find "cooked meat.doc" - a delicious homemade recipe by "Bert Bertsson". This document was part of a collection named "Meat Recipes" however you want non-meat recipes also.
A) You select "Find related files" for "cooked meat.doc" - then a search is made.
B) First of all all resulting files must have the same tags as the "Meat Recipes" collection, this so that only collections from the same shared folder as "Meat Recipes" was from will be showed (say that "Meat Recipes" was a folder by the same name from a folder named "Recipes" - "Meat Recipes" thus probably has "Recipes" as a auto generated tag).
C) Secondly the files must be from a user that has the "Meat Recipes" collection in his share, this to filter out all other possible collections that also are tagged "Recipes" - though related to the subject these collections does not necessarily have to be related to the collection where the "cooked meat.doc" originally came from.
D) Some results came back; you now also have "Vegetable Recipes" - a collection that likely came from the same folder as "Meat Recipes". However when you download these new recipes you do not only download from "Bert Bertsson", half is taken from "Sven Svensson" - someone that previously downloaded both the "Meat Recipes" collection and "Vegetable Recipes" collection from "Bert Bertsson".
That is all for now, I hope you take these suggestions to heart, or at least comment on them should you see them.
Thank you for your time and continuous development of OneSwarm.
Edit: I just realized that perhaps the file's tags are not returned to the user making the search? That would be a pity. However if so maybe the related-feature can still be implemented just with some other algorithm? Or if the file's tags can be passed back to the one making the search? Can they perhaps be coded into the torrent?
You must log in to post.