Main Area and Open Discussion > General Software Discussion

Separating features into Basic and Advanced

<< < (2/3) > >>

f0dder:
I like the Firefox model, as already mentioned - though I'd like to have some description of the config options.

For other scenarios, I really like what Eclipse (and others) are doing - a hierarchical tree that selects tabs (FARR is already doing this), combined with a "filter the tree" quicksearch box. This makes is pretty easy to find configuration options without digging through the tree structure, at least as long as things are logically named.

justice:
I really dislike options, both as a developer and a user. Of course im in the minority here. However, if you measure option usage somehow you could hide / remove those where nearly all users agree, and keep the focus on divisive options where many people disagree.

Worth thinking about. All the options are probably not needed and make it harder to understand the character of the program, introduce more bugs, and add a learning curve.

Also I would hide all divisive options you want to keep in a combo box and away from the interface.

IainB:
I can understand that some users may want to change one aspect or another of the FARR or other app. settings options, for reasons of purely idiosyncratic personal preference/opinion - i.e., even if nothing's broken
The probability that you will be able to please all of the people with the set of options AS-IS will tend to be 0.5 or less. One group of the user population will be happy with it, another won't.
The probability that you will be able to please all of the people with idiosyncratic changes to a new TO-BE options will tend be 0.5 or less.
One group of the user population will be happy with it, another won't. The members and distribution of each group will tend to differ to that of the groups in the first case.

Question: Are these changes that are required by some, but not by others, Urgent + Important and/or Mandatory?
If they are, then this is a required fix.
If not, then consider: In terms of prioritisation, why would you spend valuable time considering and implementing changes that were variously non-urgent, non-important or optional (non-mandatory), and probably not required by 50% or more of the users?

My suggestion: IIABDFI - If It Ain't Broke Don't Fix It.

Renegade:
(Not sure what Renny is referring to)
-TaoPhoenix (November 29, 2012, 10:45 AM)
--- End quote ---

I'm talking there about the difference between:

* Basic and Advanced options (for the same functionality - perhaps easier to understand as basic being presets)
VS.
* More options that are advanced

They're not the same thing. More is more. Whether you call them advanced or whatever doesn't really matter too much. But, what I described above is a simpler interface for options vs. a more complex and versatile interface for options.

The screenshot above that mouser posted is not "basic/advanced" as I described - it's "more" options.

phitsc:
I think limiting the number of options makes and application more accessible and more attractive especially to new users of your SW.

This is how the calendar app I'm using on iOS and Android is doing it:


only show basic settings:

Basic | Advanced | Expert | All

Category 1
 - Option 1
 - Option 2
 - Option 3

Category 2
 - Option 1
 - Option 2
 - Option 3


show basic and advanced settings:

Basic | Advanced | Expert | All

Category 1
 - Option 1
 - Option 1a
 - Option 2
 - Option 3
 - Option 4

Category 2
 - Option 1
 - Option 2
 - Option 2a
 - Option 2b
 - Option 3
 - Option 4
 - Option 5

--- End quote ---

It has 4 'level of detail' tabs at the top. Selecting one of these just adds / removes options in the list below (i.e. they act as a filter).

Navigation

[0] Message Index

[#] Next page

[*] Previous page