On Fri, 2009-12-11 at 11:31 -0800, Adam Williamson wrote: > On Wed, 2009-12-09 at 13:46 -0500, Jon Masters wrote: > > > All paranoia and ranting aside, there is some truth to this. There is a > > definite trend in the Linux community to want to cater to the lowest > > common denominator by being more Mac/Windows-esque. I put up with it > > because I can usually ignore it (I refuse on principal to use a GUI to > > copy a file, for example, but that's just me being weird), but I don't > > see the harm in hiding the advanced stuff under a checkbox - the > > advanced mixer stuff is still there underneath after all. > > That kind of 'split' interface - with the advanced stuff 'hidden away' - > has several significant problems. It's much more difficult to support > when you have to consider the possibility of there being two different > interfaces the user could be using to the program. It's also been quite > solidly documented in usability studies that just about everyone tends > to consider themselves an expert and hence hit the 'advanced' button, > even when they don't actually have a freaking clue what they're doing. > > It also encourages lazy interface design - the designer can always think > 'well, I'll just make this a checkbox under 'advanced' somewhere', > rather than considering how to properly design a single configuration > interface. (or, also, how to properly design the underlying service that the UI is supposed to configure) Example: openvpn. It has literally 500 configuration options that must be set exactly the same on both the server and the client. It is too dumb to automatically negotiate options and thus keep the client configuration simple. Thus the hapless user is required to know that the "TLS Auth Direction" must be 1 on the the client because it is 0 on the server. Which requires the sysadmin to publish the server's configuration somewhere. Yay. One could make the same general complaint about ALSA. Dan -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
