> OK, so this is in principle do-able - I think it would be a > good idea to try to converge on what we want before asking Dan > or anyone else to code it up.
I agree that we should think a bit more before asking anyone to write code. I have made three dummy web pages to illustrate what I've done so far. (A setup page for selecting which tags to add to the Browse by tags menu, a setup page for creating a custom browse and a web interface advanced search page.) I haven't uploaded anything before so I'll try to upload them in separate steps. Some things to think out: 1) how would these changes work in a mixed library of classical and other things. 2)Are there any benefits for genres other than classical? 3) Are there things specific to opera or choral works? 4) How about hymns and religious music? 4) Anything different about jazz, blues, hip-hop or rap? There is a prospect that these changes could make Slimserver capable of using whatever tags are present in the music files. I don't know the table layout of the database but if it uses two tables, it should be doable: music file table (MT): MT primary key, file name, other stuff tag table (TT): TT primary key, foreign key reference to MT primary key, tag name, tag value This sort of structure provides several benefits: a) SS can store all the tags found in music files in the database. No need to cast choices in stone (code). b) The choice of which tags to list in the menus can be done in a setup page. c) SS does a Select query on the database to get a list of Distinct tag names in the database, keeps those the user has chosen in the setup screen and display the resulting list in the menu and in the drop-down lists to build a custom browse. d) Multiple Artist values can be accommodated easily. Some tags may not have a well defined text name and we don't want to display a cryptic mix of letters and numbers. The setup page that lets the user select which tags to put into the menu should contain a column for specifying a display name to be shown in place of the cryptic text. We can build a set of defaults once. i.e. checkbox tag name from file display name ... If the tag info is currently in the same table as the file name in fixed fields, a two table design would require a more complex Select query (and take more time.) However, it is clean and would make SS/SB more flexible than most players. > As I see it, the request for additional functionality in web > search is fairly straightforward - simply add some more fields > in the "advanced search" page so we can enter as many or as > few search restrictions as we like. Some thoughts about search: 1) Browsing in a list is often better than typing criteria for a search. If you can type a single character and jump into the list, it extends the size of a list that you can browse effectively. 2) Search needs to provide a way to find things that you can't find easily by browsing. 3) If we are making the Browse capabilities more flexible, we should try to do the same for search. I have a dummy advanced search screen for the web interface. I made the search field names drop-down boxes rather than text labels. And I added a couple of fields. I also experimented with the idea of adding a column with a drop-down box containing all the values for that tag chosen on that line. I understand that if you change the tag name in that drop-down box, you have to re-populate the drop-down box with available values. It will be clearer when you see the dummy page. Populating a drop-down box from the database rather than from a pre-determined list is especially important for genre. Specifying other for genre doesn't help much. I think that the key ideas for advanced search are 1) let the user to specify any tag to search on from the SB menu, 2) selectively display available values to making searching easier. > I think there are two main topics for debate (if anyone sees > others now would be the time to jump in!). > (1) What tags do we want to search on (in addition to > Artist/Album/Track which are givens)? > ... > ... Anyway, I guess that COMPOSER and CONDUCTOR are > straightforward. > I'd also like to vote for PERFORMER (not SOLOIST). I think we have an opportunity to make SS/SB flexible and able to use the tags in finds in the users music files. We don't have to wire in our choices. One additional capability might be good: Combining tags when they are equivalent. A user may have music files from different sources containing different tags. So his music library would be inconsistent. It would be better if SS can adapt to what it finds rather than requiring the user to have been completely consistent. SS has a setup option to lump Composer, Conductor and Band with Artist. A more general setup page might let the user specify one or more tags to lump with another tag. The user whould pick a tag he wants to browse and one or more tags to be combined. You don't have to lose the original information; you just change the SQL Select statement for a Browse or Search. > Note for coder: there could be multiple instances of any of > these tags in one file, all should be considered equally valid. > (2) The second problem is the desired UI behaviour when using > the remote. I sketched one model two posts ago - Listener has > decribed another slightly different one. I like mine - > obviously! Has anyone else got any suggestions to throw into > the pot? I do not agree that my proposal is slightly different. To me, this is the difference between a solution I can really use and something that just won't work well enough for me. I thought I could really see the light at the end of the tunnel. Thinking about how SS/SB should work for playing classical music has given me some principles for design: 1) It is important for classical music libraries to provide a method that allows a series of browses on different tags to narrow the list of music files. 2) No one order of browsing tags will fit all needs. The user needs to be able to pick the browsing order tht fits his current need. 3) The list you browse needs to be kept manageable at each step. 4) SS/SB should be database driven and flexible enough to use the tags that are present in existing music files. This will decrease the need for the user to tag his files in exactly the way we specify. I proposed a framework for performing a series of browses where the user can specify which tag to browse on at each step. It frees the SS/SB from a rigid choice of tags and browsing steps and it makes it far easier for the user to use SS/SB with an music files however they are tagged. Your approach as I understand would display one item for each full album title. With the album display you favor - Composer, work / conductor / conductor / year - that makes for a long list to browse. If I browse on conductor or first, I get a list with lots of "Beethoven - Symphony 3 - ..." entries. On the SB, that quickly becomes unworkable for me. My approach fits best with making the album title just the work name "Symphony 1". When I browse by conductor and select Beethoven, I get just one DISTINCT item for "Symphony 3". This scales much better. I'm beginning to see how to genre to separate Symphony from Concerto from chamber music. That really helps the UI scale even better. However, if you have more stuff in the album title, my approach still works as well as yours. > The only thing I'd add in either case might be a Settings > option to make searching or browsing by these extra tags > to be optional, otherwise we'll be cluttering the UI for > people who don't want to do this. There already is a setup page for tailoring the main menu. (Player settings / menus.) I think that adding a Browse by tag choice to the list is reasonable. And custom browse methods could be added to that page as well. I have a dummy webpage showing how that might work. ---- I'll try to upload the dummy pages I described. Bill -- 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
