> I was thinking more of a browse than a search model -
> and I was, BTW, allowing for a multi-level selection,
> at least in the more advanced of the options I described.
> You select, say, "conductor", and get a list of all the
> conductors... choose Karajan,
> get a list of all albums that match
> (this is the potentially long list you are worried about)
> BUT with an added set of selectors at the top for each
> of the other valid browse tags. So if you want to now
> specify a further value for ENSEMBLE, you can.
> Properly coded, this would give you the flexibility
> you want to specify selectors for any of the valid
> tags, in any order.
I understand what you propose now. It could give me the sequence of
browse steps I want. However, there is a problem with using the album
name as the name of the work.
Most often, I'd like to browse first on Composer, then the genre
(symphony) if there are a lot of works, then on the name of the work,
then on performer (artist). At the stage where I want to search for
the work, a list of album names for one composer would be too long. For
Beethoven, it would still be 100 album names for just Beethoven
Symphonies. In my scheme using just the name of the work as the album
name and displaying only distinct values, I would have a list of 9
works to select from.
Your scheme:
Select Browse composer => list of 40-60 names
I use 1st letter to jump, select "Beethoven" from effectively 2-10
names.
Select Genre for next browse ==> list of 6 names
(symphony, concerto, quartet, piano sonata, chamber, other)
I select symphony from the list.
Select Album for next browse ==> list of 100+ albums
(of the form "Beethoven - Symphony 3 - Szell - 1958")
I can't type one letter an jump because they all start with Beethoven.
I wade through the whole list and pick the extact work and performer I
want.
I'm done but the last step was a killer! I'd probably give up before
finishing. If my wife was selecting music, she would give up and come
kick me for my bad choice of the system.
My scheme:
Select Browse composer => list of 40-60 names
I use 1st letter to jump, select "Beethoven" from effectively 2-10
names.
Select Genre for next browse ==> list of 6 names
(symphony, concerto, quartet, piano sonata, chamber, other)
I select symphony from the list.
Select Work for next browse ==> list of 9 work names
(of the form "Symphony 3")
I can get through a list of 9 names.
Select Performer for next browse ==> list of 8-12 names
(of the form "Karajan")
I can get through a list of 12 names.
I'm done and it was all feasible for me. My scheme depended on having
a NON UNIQUE work name and presenting only distinct values to keep the
list short.
Some ideas come to mind:
- Why not browse for conductor before work?
When you get a sizeable library, you don't remember everything in it.
The point of a browse interface is to let the computer present choices
rather than making you guess.
- If SS depends heavily on the album name internally, why not put the
short Work name in a different tag? That would let you browse on a
long unique album name, keep SS happy and I could browse on a different
tag with a short, non-unique work name.
This work tag is analogous to the album nme as you proposed but it
could probably be wedged into the contributor table with a different
role. UGLY but it is a thought.
---
> The other function, though, is "Search", which is quite
> different (I think). The current standard Search
> functionality allows you to search (in albums, artists and songs) by
typing (mobile phone fashion) in on the keypad. The new Lazy Search
plugin makes this easier, by allowing you to type in just one keypad
number for each letter.
As I understand it, you can make a single search step using the SB
remote and display, then you get a list of album names to scroll
through. It doesn't scale well.
I'd just add composer and conductor (performer) to the list of tags you
can browse and let it go at that.
For the web interface, the advanced search function could be extended
with fixed fields for composer and conductor (performer). The genre
portion should have a a textbox allowing the user to specify a value
for an other genre in the dropdown list.
> Clearly the standard Search could be extended to look for
> Conductor etc, but I think the Lazy Search plugin
> would require more work and possibly changes to
> the database, from what I recall of how it works.
Well, Lazy Search beats the current method. Maybe it should be
incorporated in SS so that it works cleanly for any tag.
> Searching
> Ideally I suppose you'd like to enter partial searches
> on each of several different tags. I have a feeling
> that might be too difficult to use using the remote
> UI, though of course easy to do with a web interface.
> Maybe the right answer is to tell everyone that wants
> to do this to go out and buy a wireless PDA to use
> as their remote!!
I looked at buying a wireless remote as part of the system but at the
time, it cost much more tha an SB. That just seems wrong. I can't
stand the web interface UI on a full PC screen so using it on a PDA
didn't thrill me.
I thought I saw a way to make the SB/remote workable for me. And
perhaps, the web interface could be modified to provide the same
functionality. The lengths of lists would matter less in that case.
However, the current browse methods wouldn't be satisfactory on the web
interface either.
There is another idea here about the SS/SB system. When you buy one
SB, you are also making a decision on other purchases: server, lots of
hard disk space and perhaps a PDA or laptop to use as a remote. And
ripping and tagging 1500 CDs is a huge time commitment.
> BTW, keeping the Album title really short ("Symphony 1")
> won't work - it MUST contain enough information to make
> it unique vs all other albums, otherwise Slimserver
> (and other music players) will merge the tracks of
> the ambiguous albums.
I've absorbed the idea now but I think it is pretty dumb design in the
SS software. An F in Database 101. Assume that a field you don't
control will be unique.
As the market progresses, more users will want to use music files they
already have and not be sensitive to what's in the tags. A recipe for
problems.
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
