Roland0 wrote: > 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") ;-) > You have no idea how bad some of the UIs I have seen are ;) > > On the one hand, there are some technical challenges in handling a drop > into the playlist. > Oh, I know that _very_ well. I thought it might be doable when directly accessing the server (it's not doable through the CLI, at least not in a reliable way; I've tried it...) > > 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 > sic > > - Add items to end of list > For that you could select up the whole playlist > > - Clear playlist and play dropped items > I would at least not do this from a drag&drop without an additional confirmation.
But hey... I'm not trying to design your UI here, I just say: the "drag&drop on a disabled button on the very opposite end of the screen" solution is bad. You can decide to trust me on that one or not, it's up to you. > > 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 > That doesn't change the fact that it's dramatically misplaced. Again: just sayin... Also: puttin g to similar controls that are both called "search" but that do different things on opposite ends in the UI doesn't make the difference any more obvious. Trust me with this one, I use a button next to the search field for the same thing in iPeng (to select what you want) and you can probably count the number of people who understood that using a single hand. > > That's slightly ironic - I just added the back button two days ago, > since people asked for it. > I know, I've seen that. I still don't think it looks awkward. Trust me again: other people will make awkward suggestions for your UI, too. That probably includes me :) I also don't challenge the idea of having a back button, just the placement and looks (it looks very different from all other elements in the UI) > > 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. > Can't you drag that one, too? My main problem was that on first glance I confused it with the volume bar; then I realized the latter had additional buttons and wondered: what's this for? It's not as bad as the D&D buttons but a bit confusing. > > Services are not supported atm > Sorry, that's nonsense. Just because you can't browse them with your UI doesn't mean people will not play them. Hey, I'm aware your web interface isn't finished, I just tell you what I am missing :) Shuffle also is independent of them. > > 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). > Yep. That's what I mean. Scrolling, especially with artwork, jumps at least one item at a time (it's not smooth) and if you scroll fast, it can be like 2/3rds of a page or even more of a time. What this means is that your eyes completely lose track of the items you were looking at before and you have to re-orient yourself in the page which is a) slow b) tiring The problem is not delays, the problem is a lack of smooth scrolling. It jumps, it doesn't scroll. I might be spoiled by the scrolling performance on iThingies which is generally better than for computers these days but it's still better with the default skin. It usually jumps at least a track at a time, sometimes more than one. > > I tested this both with Chromium and Firefox on a mid-range desktop > (Core i5) > ... > 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? > I tested it with Safari and Firefox (latest versions, both) on a MacBook Pro (i5) and iPad. Same on all of them. Don't plan to try Chromium. > > if I drag the scrollbar up/down as fast as I can, CPU is ~20% > Note: I don't drag the scroll bar, scroll bars are last millennium, I either use the mouse wheel or the track pad gesture to scroll. Actually I wrote about how I even failed to hit a scroll bar. Now I tried it using a scroll abr and I absolutely can NOT scroll a pixel at a time, it always moves at least half a row. To make things worse, it's usually different with every movement, sometimes it moves half a row, sometimes 1 1/2... In the albums view the scroll bars are also very inaccurate. Even the fully loaded list jumps back and forth while scrolling making the confusion complete. It's pretty clear that you are not using transformations for scrolling but positioning the whole content on the main thread which is probably what's causing the delays and jumpiness. iPad is best by far but it seems to get "stuck" every five items or so. > > 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. > Well, given Firefox' current release policy this probably means it will be just fine with FF 24 a month from now... ------------------------------------------------------------------------ pippin's Profile: http://forums.slimdevices.com/member.php?userid=13777 View this thread: http://forums.slimdevices.com/showthread.php?t=98186 _______________________________________________ plugins mailing list [email protected] http://lists.slimdevices.com/mailman/listinfo/plugins
