> Just a couple of things I don't understand: > (1) In the web form section you wrote "Bill's Alternative: Just > add a new "Browse by Tags" command to the main menu. The first > step is for the user to select a tag to browse. This keeps the > regular browse commands the same way they are now. I'm a bit > leary of adding 6 or more lines to the list of choices in the > existing Browse commands. I understand that it might be easier > to implement the Multi-level Browse as a change to the > behavior of the existing commands. However, I think it makes > those commands more cumbersome to use."
> I don't understand the relevance of this to the web form. > Did you mean this to go at >the beginning of the discussion on the Remote UI behaviour? It relates to the way the multi-level Browse should work. My alternative takes one more step to choose the first kind of tag to browse on. The advantage is that all the existing browse commands work exactly the way they do now. A few cycles of posts ago, I proposed a setup screen to define a custom browse. The user picks a name for the browse and specifies the tag to be used at each step of the browse. This can be made shorter than the method you described or my alternative. You and Pat Farrell thought it was too much work to implement but I'm not sure. > (2) Your note "Bill's Note: this isn't consistent with your > specification about removing a menu item for browsing a tag > that has already been browsed." ... I changed the spec to > work the way I think you wanted it, there shouldn't be any > more references to removing a menu item, unless I missed > one (apart from where I said you can't browse a tag twice > if its only legal to have one of them, eg Artist) I wrote two notes about this. First you said " The multi-level Browse process could in principle continue forever" then later you said "The tags (Album, Artist, Year, Title, etc.) should only occur once so can be omitted from the "And Browse" entries" If you omit a "And Browse <nn> <tag>< menu item for an already browsed tag, the process end when you have browsed all tags. > (3) in the Web interface bit, you wrote "Bill's Note: I don't > think this is a useful alternative. If you want to define a > multi-level search, fine. > It isn't a replacement for a browse.". Actually, I think it > is - if you have the ability to see the result of the > selection criteria you have entered so far, and if the > selection boxes are prepopulated like Genre is, it is > exactly equivalent to a browse. I wrote this because it > occurred to me that the multi-level search (the extended > version of today's Advanced Search) could be combined with > the web version of the Multi-Level Browse. However, I'm not > that bothered to be honest - I can see that some users > will be more comfortable with seeing "browse" and "search" kept > separate, if only because it maps better on to the Remote UI > functions (which really do have to be different). You reply was mushed together with my test you quoted. I think I understand your original text now. I do have a comment about such a search: When you populate the lists initially, some will be too,long to be useful. So you may need to do a second or third step an requery the DB and repopulate the drop-down list. -- Listener ------------------------------------------------------------------------ Listener's Profile: http://forums.slimdevices.com/member.php?userid=2508 View this thread: http://forums.slimdevices.com/showthread.php?t=18767 _______________________________________________ Discuss mailing list [email protected] http://lists.slimdevices.com/lists/listinfo/discuss
