>> How about making it an option > >Funny that this request always follows. The answer should also be >likewise consistent: no. > I was being slightly tongue-in-cheeck with regards an "option" that would be user-configurable.
I disagree with a blanket consistent "no" as an answer for adding preferences. True, it's not great to have to support loads and loads of settings, especially if the request would be detrimental to maintenance and performance of the product. But each request should be taken and considered on its own merits, rather than instantly say "oh no, can't have more options". If 50% of a community want it one way and 50% want it the other, then not having an option will dissapoint 50% of people. That's okay when rejecting a new request, because generally people won't miss what they haven't already got. I don't agree that there are too many options. They just need to be organised properly. The vast majority of users don't need to (and shouldn't) see every last nitty gritty option, but they can be tucked away under properly organised advanced sections. Defaults for these should suffice for most people that don't like to tinker. I think SC7 options are layed out better now - there doesn't seem to be as many, but maybe they are all still there, but just organised better. Other software products handle options very well. Firefox looks quite minimal in the options pages, but go to about:config and there's stacks of hidden things. SC has prefs files - each item doesn't *have* to map to a WebUI prefs page item. Better to read constants from a prefs file than hard-code. For the record, I'm not bothered whether the search field is always displayed, pops up, or is available only from the music library page. I don't search all that much from the web UI, mainly from the playerUI, and there's a button on the remote for that (the remote button is always available, so in my opinion it would be most appropriate that the search bar in the WebUI is always available too). A constant in the code than can be found by tech-savvy users and hand-tweaked, or re-use the Roxy Music query string param (morethanthis) would fit in fine in my opinion. >You can always choose to edit the code to create your own custom >skin. in fact, I think a very good reason to say 'no' is to encourage >the generation of custom skins. > I don't like custom skins much - someone always creates one that has good potential but doesn't do everything, or becomes redundant/not-supported over time due to server code changes. They should just be look-and-feel related, not introducing lots of different functionality. >I'd love to see a community of >hundreds of varying skins, even some with just subtle differences, >like you see for many other software projects out there. > I think the impression is that it is quite hard to create a skin that just applies subtle differences. We were told that changes to colours for example is quite hard to do with the default skin, as there's loads of graphic files that would also need tweaking. Cross-browser support is also an issue. It's not like skinning WinAmp or Windows Media Player, where you're only supporting one platform. > Somewhere along the way, this one has gone wrong in creating an attitude that > >everything should be there out of the box and work for everyone all at >once. > Most things should be there out of the box, but configurable to work as one would want them to. Out of box, it should be ready to switch and and use and be simple, but at the same time adjustable with a bit of effort because many people have different views. Many things to do with tweaking the UI are not possible to do realistically as plugins or skins. _______________________________________________ beta mailing list [email protected] http://lists.slimdevices.com/lists/listinfo/beta
