pippin wrote: > > I have to admit, though, that I do find some elements of the rest of the > UI pretty awkward. >
>Dragging an item onto a "Play" or "Add" command button is actually probably the most counter-intuitive form of control I've seen in a while. Hey, at least there is one area where the GUI ranks highly (I'm slightly disappointed that you didn't write "in my whole life") ;-) >That the buttons are greyed out and as far away from the source item as they could ever be placed in this UI doesn't really make things any better. How did you come up with the idea of >dragging things across the whole screen just to add them to a playlist that you even have to _pass_ on the way??? On the one hand, there are some technical challenges in handling a drop into the playlist. On the other hand, even the semantics are not that obvious: There are at least three meanings a drop could have: - Insert items at drop position - Add items to end of list - Clear playlist and play dropped items I agree about the buttons looking disabled not being optimal (see above post), and I've moved them nearer to the source panels >The only element that is even further away is the "Search" entry field. Why an entry field for something that completely happens in the lower left corner of the screen is >shon at the very top right is above me, sorry. Especially since you have a second one at the bottom. The search field on top doesn't do the same thing as the ones in the search panels: the former searches in artists, albums and tracks at the same time, the latter only in the category they are located >I would also re-think that little green back button. It took me a moment to find out the logic behind going back to the library through the "Music Library" tab-thing but then I found that more >logical, the green back button doesn't really have a place in the UI flow. That's slightly ironic - I just added the back button two days ago, since people asked for it. I didn't miss it myself before, but now it's here, I use it frequently, since I don't have to remember where I started my search/drill-down (e.g. there are ~5 starting points to get to the track result list) >The layout of the top control thing probably isn't finished, yet? well, it -is- beta >Every button seems to have a different size there and I also found using a slider for the position in the track unexpected. I actually like this idea but I believe the slider needs a >label for people to understand what it is for. Also quite interesting - up until now, the feedback about the control function was negative. There's no space for a label - I could put a hint into the mouseover, although I think this would look ugly. Since you can drag the other sliders (volume, track time), I assumed this would be clear - but maybe it's not. >I also miss a shuffle control. Shuffle and repeat also should support the customized functions for love/ban for some services, I don't know whether they do, I didn't test this. >Alternatively, you could put these functions somewhere else, but for some services they are really important. Services are not supported atm >Scrolling is also pretty slow and that's the case independent of the server speed (tried it with my Mac as a server, too). It looks like there's a lot going on concurrently while scrolling that >holds the UI and the browser up a lot. In Safari on a Mac I found it very hard to bring up the scroll bars, when I stop scrolling and try to hit them it looks like the UI is irresponsive for long >enough an interval to make them hide again (if you don't use a Mac you probably don't know what I'm talking about: OSX hides the scroll bars by default and only shows them while scrolling; >the UI is too slow to reliably allow me to grab them before they disappear). It's better in Firefox where there's a permanent scroll bar. Now this is odd - I never had any issue with scrolling speed (I assume you mean fully loaded lists, not on-demand, where server speed matters up until the whole list is cached). I tested this both with Chromium and Firefox on a mid-range desktop (Core i5) and Netbook (AMD-E450), and with all combinations it is instantaneous. It's slightly smoother in the active playlist, but in any list I tried, there is no delay at all. Just for testing, I created a playlist with ~6500 entries: Rendering takes 4sec in Chromium, 2sec in Firefox and after that it's instant access to any position without any noticeable load on the client (if I drag the scrollbar up/down as fast as I can, CPU is ~20%). Same is true for any other list (e.g. album list with 6000 albums, when it has been fully populated by the server) I wonder where this comes from on your setup - does it happen with Chromium and Firefox as well, or only with Safari? Is the CPU the bottleneck? >Right now I'd say it's a good interface to control the player and have a look at the currently playing music as well as to get related information on it, it's not really an option to browse the >library, yet. I guess that depends - I've been using exclusively for some time now, and it's actually really fast for me on rather moderate hardware. But then, I'm obviously biased. >Oh, and in Firefox I had to reload it four or five times before it loaded but that's probably also just a matter of tweaking. I've noticed that, but I have no idea where this comes from. It keeps improving, though - with FF17, it didn't work for me at all, FF18 barely, and with FF19 it's nearly there except for minor annoyances like this. ------------------------------------------------------------------------ Roland0's Profile: http://forums.slimdevices.com/member.php?userid=56808 View this thread: http://forums.slimdevices.com/showthread.php?t=98186 _______________________________________________ plugins mailing list [email protected] http://lists.slimdevices.com/mailman/listinfo/plugins
