View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0000096 | MMW v4 | Playlist / Search | public | 2003-02-12 17:39 | 2006-03-09 17:40 |
| Reporter | rusty | Assigned To | |||
| Priority | urgent | Severity | feature | Reproducibility | always |
| Status | resolved | Resolution | fixed | ||
| Summary | 0000096: New Logical Operators for 'Advanced Search' | ||||
| Description | It would be useful if additional logical operators could be used to help refine searches done via the 'Advanced search'. Specifically, 'not' operations. Possible Approach Discussed over IM: a) Give beginners the ability to construct some more complex queries: Add a new column of dropdowns (and / or / and not) for each search criteria that is entered (there was some debate as to whether this feature is valuable for beginners, and if it would cause confusion for advanced users). b) Note that the 'and not' is fairly important so that Condition dialogs could be made consistent, and so that queries are more understandable. This probably warrants further discussion though (i.e. AND xxx DOES NOT CONTAIN yyy is easy to understand, but it doesn't give the user the ability to enter queries such as AND NOT xxx EQUALS yyy). c) Each query entered would be prefaced by a letter e.g. a) ... b) . These would be used when users make advanced queries: -a possible approach is to have [x] Advanced Query [________________] at the bottom within which advanced users could enter queries such as (A and B) or (C and CD). If the user clicks the checkbox, then the leftmost column mentioned in a) would become disabled. Note: for a) and c), in cases where there are not brackets to indicate order of operations, AND takes precendence over OR. i.e. 'A and B or C and D' = (A and B) or (C and D) | ||||
| Additional Information | http://www.songs-db.com/forum/viewtopic.php?t=880 http://www.songs-db.com/forum/viewtopic.php?t=2279 http://www.songs-db.com/forum/viewtopic.php?t=2757 | ||||
| Tags | No tags attached. | ||||
| Fixed in build | 962 | ||||
|
|
I would prefer implementing c), because I think that a) doesn't add much value, it helps in same cases, but not in many. Also, if user understands a), there's not big change in using c), particularly when MM will help the user as much as possible (e.g. new added condition will be automatically added to the query formula line with 'and' operator, deleted conditions will be removed, etc.). |
|
|
Btw, in c) it would probably make more sense to mark conditions by numbers and not letters. One of the reasons is that if we localize operators, they can coincide the letters (e.g. 'and'='a' in Czech). |
|
|
Using symbols in c) makes this functionality even more unapproachable for the average user (though I understand that it's probably the only way to avoid problems). Another reason why I think a) does add value (using the a) approach symbols don't need to be used and localization isn't a problem) |
|
|
Given the fact we're not in agreement what's the best implementation and that we have to hurry a lot, I'd propose to defer it past 2.2 release. |
|
|
push23 |
|
|
Just came across the following which may have some useful ideas about UI for this: http://www.codeproject.com/aspnet/SqlWhereBuilder.asp |
|
|
As I review the Search/AutoPlaylist issues, I think we may want to finally resolve this one. Some new thoughts: a) In most cases AND, and OR will be sufficient (since our conditions already support 'doesn't contain' and 'doesn't equal', HOWEVER, AND NOT is also important for cases where user wants 80's Favorites but not Children's Music. b) Whatever we build should be usable by the average user and that we can worry about the really advanced functionality at a later date. c) We do not need to worry about nested conditions (at least initially) if we implement the ability to Query based on Playlists e.g. Playlist Equals Favorites), something that users have asked for anyway. For example if user wants to play (Rock from the 60's) OR (Pop from the 70's) they could create 1 playlist for Rock from the 60's, another for Rock from the 70's, and then a third playlist that mixes the 2. With the above in mind, all that is required is that for search Criterion table to add a column for And/Or (it doesn't need a column heading). In addition, every Criterion dialog subsequent to the first Criterian should have the following at the top: (o) And . ( ) Or . ( ) Not e.g. (o) And . ( ) Or . ( ) Not Property: __________ Condition:__________ Value:______________ . . . . . [Ok] [Cancel] Note: contrary to my original suggestion, to keep things simple, we should just have all AND/OR/NOT operations be independent (i.e. any OR operation would be in relation to the entire set). |
|
|
Here's a new proposal that takes the best of everything discussed to-date, giving a good solution for beginners, and a solid solution for more advanced users. The layout of the Advanced Playlist/Search dialog would remain exactly as it is today, with one exception: At the bottom, there would be a text box that displays the queries as they are entered. For example: Edit Query Details (use '(', ')', 'AND', 'OR', 'NOT'): ((ARTIST contains U2 or Beatles) OR (Genre = Pop)) AND (Added <= 1 month) AND (Rating >= ***) Any non-editable text would appear greyed out, whereas editable elements wolud appear in black. This text box would be dynamically assembled as the user enters his criteria, via a dialog along the following lines: (o) And . ( ) Or . ( ) Not Property: __________ Condition:__________ Value:______________ . . . . . [Ok] [Cancel] The order of precedence of operations (i.e. how brackets would initially be assembled) is something I'm uncertain of. Basically, this is the idea that Jiri had originally proposed, except with some refinements so that the user doesn't have to abstract quite as much. |
|
|
Problem is how to implement an edit line with partially editable and partially disabled text, there isn't any such component and it would be pretty tough to implement one. For that reason I'd propose to use the original idea of line like: 1 AND (2 OR 3) AND 4. I also think that this can be better readable because user immediatelly sees the conditions used, i.e. the whole structure of the query. Another option is to make it as you proposed, but also conditions would be editable in that edit line. However, in such case we would have to solve parsing of this edit line back to the conditions which could be particularly tricky if user makes some error or so. Just one more comment re. ( ) Not radio button. I don't think it should be present, it's an unary operator unlike binary AND and OR. Also, I'm not sure if these radio buttons should be present at all, because if user edits the operators in the edit line, it isn't clear which operator to make selected in the radio buttons in case user opens the dialog again. |
|
|
Re. your first comment, I think it's easier if the user doesn't have to abstract from 'A' to the actual criteria associated with 'A', but if this is a technical limitation then we have no choice. Re. your second/third comment, my assumption was that conditions would also be editable in the text box. So yes, it is possible that we would have to avoid entering them in the Criteria box. This leaves us with a usable implementation, but one that is really most ideal for advanced users. I did a quick hunt, and found the following component which seems to provide a UI that meets all of our needs, in a manner that gives us the functionality we want (it happens to use a UI that's very similar to how queries are constructed in WMP). Do you think that this would be worth considering? http://www.korzh.com/delphi/sq/ http://www.korzh.com/delphi/sq/images/ssmain1.gif |
|
|
Also, one other issue that we might want to consider addressing in this implementation is assigning a 'weight' for criteria that are 'OR'ed. e.g. Rock (5) or Pop (3) would result in a playlist with 3 times as many Rock tracks as Pop tracks. This could be a future feature, but it's something we should keep in mind. |
|
|
Pushed 2.6. |
|
|
Improving search using logical operators is _critical_ for version 2.6, however, in the interest of meeting users' expectations without spending an inordinate effort to implement a solution along the lines of http://www.korzh.com/delphi/sq/images/ssmain1.gif , we should also consider a much simpler means of meeting this need: 1) Allow the user to select whether to match any/all of the selected criteria (similar to iTunes). e.g. Match _all_^ of the following criteria: 2) Fix bug number 1987 Given our current limited resources, I suspect that this is a better short term decision. |
|
|
Assigning to Ludek to implement as the last proposal by Rusty suggests. |
|
|
Resolved in build 962. Added option to match ANY of the search criteria as described. Note: I would prefer to place the text line with ComboBox[All,Any] below. |
