Rockbox.org home
release
dev builds
extras
themes manual
wiki
device status forums
mailing lists
IRC bugs
patches
dev guide



Rockbox mail archive

Subject: Re: Settings reordering.

Re: Settings reordering.

From: Jonathan Gordon <jdgordy_at_gmail.com>
Date: Wed, 24 Aug 2011 00:36:15 +1000

As a first step I've attempted to get every setting used by all
targets into a list which we can work with.
https://spreadsheets.google.com/spreadsheet/ccc?key=0AqzlOGMuRZ7OdGNvcFE4QUdOSENnX1JPVXFvMUFTaFE&hl=en_US

This is from the settings_dumper output from the h300, player, e200
and mr500 sims. That hopefully covers every setting but someone will
need to double check this! This also doesnt include any current menu
items which are not settings!

On 23 August 2011 23:45, Paul Louden <paulthenerd_at_gmail.com> wrote:
> Hey guys, so, we're contemplating trying this once more. Many of us
> regularly come to the conclusion that the settings are not organized
> in the best way possible. We also often never manage to do anything
> about it. So we'd like to try again.
>
> We're going to come up with a proper process under which to accomplish
> this. Some of the main points of this process are that at the end we
> will have a single .diff from our collaboration efforts, which will
> then undergo a yes/no vote. Everyone is welcome to contribute, but
> we're not discussing the existing layout or minor changes to it.
> Rather we're more or less starting from scratch.
>
> We're first going to be dumping the entire list of settings. Every
> single one of them. I think we're still not entirely sorted on the
> process by which we'll refine this into a new menu structure but we
> shouldn't be looking at the old structure as a reference or starting
> point. We want to go through the existing settings, as a group, and
> come up with a procedure by which we create the new one.
>
> Here is an example process by which we could do this. It's not the
> process anyone must follow, but it would allow things to be approached
> as a group. We do ask that if you're going to contribute, you
> contribute to the whole thing rather than just chiming in at parts.
> That means if you think there's a better process, speak up so that we
> can refine it before we start, rather than objecting to it later on.
> At the beginning of the process we would select a small group (3 or 5)
> of volunteers to arbitrate decisions at the each of each phase to
> ensure this project moves forward.
>
> The first step, then, would be looking at the whole list of settings
> and having people contribute a categorize list. Not a new menu
> structure, but just what categories they belong in. For example,
> "volume" could be categorized as "sound setting" or "dsp setting" or
> something new. These are only top level categories, so don't get into
> fine grained detail. The goal would to be to have these top level
> categories suggested in one week.
>
> After everyone has contributed top level categories, we look at what
> we have, see which ones are unambiguously categorized the same way,
> and in cases where there are conflict (X is playback for some, and
> Sound for others) we work that out, at this point, before moving on.
> We could spend approximately one week on this, possibly too if it
> turns contentious.
>
> Next we go into each broad category and attempt a similar thing using
> subcategories. Repeat this sort of thing recursively until we've
> decided we need no further sub-sub categories. At each stage we can
> discuss whether sub-categories are even needed under the previous
> level based on the number of items, and whether it will increase
> confusion (by not having settings immediately visible) or decrease it
> (by helping to shorten the list). This could be given 2-3 weeks.
>
> After everything is categorized, we approach each visible menu with an
> eye for order. At this phase we should determine some standard
> ordering rules, for example "the enable/disable option should always
> come before the parameter options." Note this is just an example, and
> while one I feel is a good rule, not one that must be adopted. This as
> well should be given one or two weeks.
>
> The overall deadline for the project would be the beginning of the
> feature freeze for the next release, so that the new menu layout can
> be available with the next Rockbox release.
>
> Again, this whole process is up for comments before we start. If we
> get enough people willing to commit to contributing their suggestions
> at each phase, we'll take it and go. If you object to the results of
> the phase after the phase is over, don't waste time starting
> arguments, just vote against it at the end. If the version contributed
> to by everyone is voted down, then we can entertain voting on
> contributed .diffs, but the real goal here is to use a process by
> which we incorporate a little bit of everyone's input into something
> that is, if never near perfect, better than what we have now.
>
Received on 2011-08-23


Page was last modified "Jan 10 2012" The Rockbox Crew
aaa