Posts: 3,746
Joined: May 2004
Reputation:
20
Livin
Posting Freak
Posts: 3,746
I vote for a web interface with FULL settings config... not just AdvancedSettings.
This would be fantastic as many of the settings, like ones where you need to "browse", are a PITA via a remote.
I'm not an expert but I play one at work.
Posts: 4,132
Joined: May 2004
Reputation:
4
sho
Team-XBMC Member
Posts: 4,132
Just imagine if some ingenious user decided to make a standalone advancedsetting app, instead of the umpteenth nfo generator (for Windows).
Posts: 26,215
Joined: Oct 2003
Reputation:
187
rcoops: The whole point of advancedsettings.xml is:
NORMAL USERS SHOULD NOT HAVE TO TOUCH IT.
Did I make that clear enough? If you have to alter something in there, then you are doing something that the vast majority of people should not have to do. If not, then whatever setting that's there needs to be in the UI.
If there's problems with the settings in the UI, as you mention, then please file a report on trac with what it was you were confused about, with some suggestions as to why you were confused and/or what could be done to improve the situation.
If there's things in advancedsettings.xml that you feel lots of people need to change, then please let us know what it is so that we can consider it for inclusion in the UI.
Cheers,
Jonathan
Posts: 87
Joined: Nov 2008
Reputation:
0
>The whole point of advancedsettings.xml is:
>NORMAL USERS SHOULD NOT HAVE TO TOUCH IT.
>If you have to alter something in there, then you are doing
>something that the vast majority of people should not have
>to do. If not, then whatever setting that's there needs to be
>in the UI.
The problem with this (all user config in the UI) is that the UI is not suited for text-dense output, given its relatively large font size. That means you can only fit so many settings per screen, necessitating large number of screens for a full user config. That's one definition of user unfriendliness. Another problem is that any explanation for settings has to be brief (again, because of low text density).
A second problem is that the UI is geared toward use of a remote, so navigation is awkward. You can of course use a keyboard/mouse in the UI, but the "look-and-feel" of a remote-control UI is different from a mouse-driven UI, making navigation unintuitive. This is all the more true when some of the keys are mapped to different XBMC commands, obviating their normal use per desktop UI convention.
Frankly, I'm a little surprised that for one who espouses usability as his role, that you would think that the in-program UI can be used for full customization. And the thought that the advancedsettings file can be made to that it satisfies most every situation is a bit presumptuous, given the wide diversity of circumstances and needs. If you were to give serious thought about usability, a suggestion is to sit down with someone who is an "apps user" that has no experience with XBMC, and let the person try to configure the program. That's what usability is all about, learning how normal users use a program.
What sho and some others said makes perfect sense: XBMC needs an external (PC-based) configuration module. It doesn't have to be just for "advanced settings."
Posts: 26,215
Joined: Oct 2003
Reputation:
187
Indeed "full customisation" is ridiculous from the UI. Those who need full customisation are those who will be quite happy with editing some settings outside of XBMC. Whether this be an advancedsettings.xml file directly (this is easy enough to do if we make a template available for instance) or via some advanced settings editor (that just pretties up this process) is irrelevant to the discussion at hand.
What I think we all agree on is that any settings in the UI need to be thoroughly thought through, and that they really have to cover sufficiently different usage requirements in order to justify being there.
Many of our current settings don't belong in the UI as most users shouldn't have to touch them. Some of our currently "advanced" settings possibly do belong in the UI.
The key is identifying which ones are needed by "basic" users, and ensure that those are available and are well described so as to be very clear. Anything else doesn't really need to be there.
We've got a couple of lists internally on thoughts on some of the settings we have in the UI that don't need to be there. I'll see if I can move that to a separate forum thread for a wider discussion if you wish to take part.
Cheers,
Jonathan
Posts: 87
Joined: Nov 2008
Reputation:
0
>What I think we all agree on is that any settings in the UI
>need to be thoroughly thought through, and that they really
>have to cover sufficiently different usage requirements >inorder to justify being there.
I agree in part, but I would not use the basic/advanced metric to judge for inclusion. The TV UI (also known as the 10' UI) is inferior in most every way to the PC UI when it comes to textual information display and interaction. My suggested rule of thumb is simple: Anything that can be configured outside of the program, should be.
There are two components to usability: the mental effort (figuring out how to change a setting), and the physical effort (the amount of motions needed to effect that change). Making things intuitive lessens the mental effort. Minimizing the number of button/mouse clicks and hand movements lessens the physical effort.
In my opinion, the entire array of settings under the System Config option belong outside the program. The majority of these settings are static and don't need to be changed on-the-fly. I can change them with less physical effort, and gain a better understanding of what I'm changing (with inclusion of contextual help and by seeing all the related settings in one screen) on a PC desktop than from the XBMC UI. Also, consolidating all the settings in one location, rather than have them be scattered throughout the XBMC UI, make things easier to manage and understand.
As an example, folder sort setting is now per folder, and I need to navigate into each one to change it. (Count the number of clicks required.) This would be easier on a PC config, where changing the default sort of a folder (on a graphical tree) only requires two clicks and two mouse movement of probably ~1cm distance each, with zero display lag. Compare and contrast.
So what settings should go into the program UI? Anything that requires ad hoc flexibility. Folder sort, to use the above example, would also be in the program UI. It's not an either-or situation; certain settings should be mirrored in both inside and outside configurators.
This resolves the dilemma Gamester17 raised, how to make a program plug&play, but also allow extensive customization. The answer is that you let the "installer" do the major customization outside of the program, and let the "user" do only minor changes within the program.
To sum, I suggest forgoing the basic/advanced paradigm, and instead use the static/ad hoc (or frequency of change) metric as the gauge. If an advanced setting needs to be changed frequently, then it would need to be within the program.
Anyway, this whole issue involves the "what", as in, what settings should be included in XBMC. My main beef with XBMC's usability is actually with the "how," as in, how those settings are implemented. To give you one of many: .. to denote a parent folder. This is a PC'ism that dates back to the 8.3 DOS days. And what's a "parent folder" anyway? Yes, I had to explain that to my mom, who has no PC experience. But I'll leave this beef to another time. I need to get current and install the new release.
Posts: 139
Joined: Feb 2009
Reputation:
0
Shadok
Senior Member
Posts: 139
I must agree with jmarshall on that point even if i like to customize everything.
Having too much direct available options is a pain. You'd have to spend hours to pass through and understand them all (if one day you want to change a detail, and you don't remember where exactly the option is or what its name is, you'll regret having this lot of options).
