Kodi Community Forum

Full Version: Settings level button for Gotham
You're currently viewing a stripped down version of our content. View the full version with proper formatting.
Pages: 1 2 3
(2013-09-25, 11:47)Martijn Wrote: [ -> ]I totally disagree with you (and for good reasons)! This is not bad design as you harshly put it.
Personally I think staying on the path of setting level toggling would be bad design but I do understand your view point at the same time. I think this is a perfect topic for discussion at Devcon to see if a Team consensus can be established, with that done maybe some progress can be made in getting something implemented to make for a better user experience.
Quote:This is not bad design as you harshly put it.

I didn't see this part of the message before, but I would like to specifically address this.

It's not a matter of being harsh or not. Saying it's bad design is not a personal attack on any person on the team. Let's not make design decisions into a personal issue. I have nothing but respect for Montellese for the settings work and Jezz_X for Confluence itself. It's not the level concept itself that is a "bad design", or any one particular thing. Like Montellese said, the settings levels are just a side effect of the settings revamp, and how to actually handle them in the GUI is another issue from what he did. How it's currently displayed in the GUI isn't something that anyone particularly worked on/strived for, in a manner of speaking.

Settings levels were added, and the way they're handled in the GUI was simply just a default and not even any particular goal or something that was worked on. The way it currently is was more of an example than the final work. This is a coat of primer, not the final paint job. Just look at the quote of Montellese in the first post in this thread.

So yeah, I'm harsh on primer. It's not an attack on anyone. There's no fire here. I just want to make that absolutely clear.
i know you don't mean it personal.
as i read it you wanted to remove the settings level completely and go back to the old horrible way it was done.
i've said this many times. don't stick with old crummy ways of doing something just because the public is used to the crappy way it was done.
who cares if they start screaming just because we changed something and they can't find it any more. the old way was bad and should never return.
people are stupid (this is just a fact and should not be taken personal by any one) and don't like and things change. they are used to something and even moving an option three lines down will render them insane because they can't find it any more.
I personally don't like settings hidden away in applications, but I understand the reason for it in settings-rich applications, which is definitely what XBMC is.

The trick is to make sure that things the average user needs to change are there when things start. Notice the use of the word "need" rather than "want". Users are quite happy with apps once they realise that the thing they want to change can't be done. Most of the time it's not a big deal and they get on with using it anyway. It's only stuff they need that they care about.

As long as those things are exposed by default, I don't have an issue with a settings level button for other stuff that isn't as important to the user.

What I do think is important is giving the option to skinners and those that produce alternate versions of XBMC for appliances (OpenElec, Pivos etc.) to easily alter the experience for a different target market than XBMC may serve. i.e. allow them to have settings levels if they want.

In Confluence, I'd tend to err on exposing as many settings by default as possible, with the "Advanced/Expert" toggle being used only for those settings that potentially break things. I do think it's important for the button to be there in Confluence, as that's one way that we can indicate to skinners and others that build on XBMC that the facility is there. Note that I think this should be skin-controlled in some way. i.e. skinners should be able to dictate the default base level they'll show settings at (overridden by the users' selection of level).

While I've come not to like the idea of levels, if we are to go that route then the level toggle must be along side the current level info so it's clear that it can be changed, so using Jonathan's suggestion with an addition of the level toggle:


I'm not sure however if it's possible to have a control in that part of the menu.

Apologies for my crap image editing skills.
that won't work well with all languages I guess (not much space with the additional spinner controls). Maybe rather add two buttons where "reset settings" is now. [Reset these settings] [change settings visibility]
In that case


Again crap editing on my part, the Advanced & toggle bit could be smaller in real life.
The reset takes a lot of space where the text could have been so now you shrink the settings list space.
If you're going to have a reset button then it has got to be somewhere there because the current implementation only resets the settings in the currently displayed page.
I think the button to change the level has to be next to "Reset settings", because if it's in the left bar you'd change the settings subsection to DVD (in this example screenshot) until you reached the spinner and you most likely want to stay in the same subsection.
Users are unlikely to screw around very much with that setting, just get it visible. Things can be tweaked later to get it more optimal. Instead of a spinner you could have a button that acts the same way as the view as button (i.e. increments the setting level) (make sure both are supported in the code).

Also, I'd navigate left off the left list of categories to the reset button (and then to any slideout menu, if still required) to aid in those that really need to switch the thing 100 times over.

The reset button can be kept quite small without all that much issue - the key is that the text is legible more than anything, so it can be at least as small as the description text.

I'm happy to provide anything on the C++ side if someone takes care of the XML.
this has been solved now with PR3498
Pages: 1 2 3