Separating features into Basic and Advanced

[TaoPhoenix]

Elsewhere:

maybe it would be worth considering separating FARR's options into basic vs. advanced?

In many cases I approve of this kind of separation. Perhaps the challenge is which features are so fundamental they need to be in the Basic set, but roughly I think it helps discoverability.  I think this is one of the things Apple picked up on, though possibly to the frowns of expert users.

Echoing a remark I made elsewhere, I do a lot of simple-use-cases with programs that are capable of much more. Chops to Mouser for adding my one use into SC captor so that I didn't feel torn between DC loyalty and how I actually work. In other programs especially the graphics ones, I often do no more than cutting and pasting sections to blot out annoying portions, change the stretch dimensions, then resave the modded version. So I don't need all the wild fancy tricks that the pros use, and I'm happy for them to live behind some menu like "advanced".

What do y'all think? Do you approve of the hierarchical layering of features, or should they all be equally accessible?

[Renegade]

Funny that you should bring this up. I was thinking of starting the same thread. (Or very close anyways.)

90% of the time, I only care about BASIC stuff, but there are those times when I want/need/require ADVANCED control.

But, how do you properly handle transitioning between the two?

Do you treat them independently and have only 1 in effect at a time?

e.g.

Basic quality is set to "high", which in Advanced is 80.
Advanced quality changes to 70, which would be "medium" in Basic, but the Basic setting is left at "high".


Do you keep them in sync, but modify the one that is out of scope according to the settings you are currently working with?

e.g.

Basic quality is set to "high", which in Advanced is 80.
Advanced quality changes to 70, which would be "medium" in Basic, so the Basic setting is changed to "medium".

Two very different approaches. Preserve or adapt?

I'd like to know what people would normally expect.

They're fundamentally different, but both valid assumptions.

[mouser]

I tried this once, with my Find and Run Robot application.

In that case I had the options dialog toggle between an Advanced mode, which shows all options, and a Simple mode, which hid most.

First let me say, I am a complete believer in the concept that too many options can be overwhelming, scary, and make it harder to find the options to do what you want.

Having said that, most people who have seen my software know that I simply cannot help myself when it comes to adding options, and they tend to proliferate in my software.  I think that has to do partly with the audience.  I tend to respond most to people who are tinkerers and like to customize things, and the DC forums tend to attract such people.  And I don't spend too much time thinking about "How can we make this easier for new casual users."

Now back to the story of two modes in FARR:  Eventually I dropped the idea of having the Advanced and Simple modes, simply because it did not seem like something that felt unsustainable for me -- hiding options in the dialog just never looked right.

However, that was before I moved to my more standard TABBED options dialog which I have taken to using on most of my applications these days.  I think the TABBED options offers a fairly natural way to move Advanced options to a separate section of tabs, and keep the more basic stuff in other tabs.

It's still not a perfect separation, but I think it can serve an important role in helping people see which options are more likely to be useful to them.  A sample from the new Screenshot Captor options dialog:



This Advanced group is something I will probably add to my other programs as well.  The only disadvantage is that it means some options that would otherwise logically be grouped together may get separated (some in basic options and some in advanced), but I think that's a price worth paying.

[TaoPhoenix]

(Not sure what Renny is referring to)
I do agree that in some cases too much choice is overwhelming. So start with the Basic features, then say a few weeks/months later he user asks "can this do X" a 2 paragraph reply can show him how. But that wasn't his use case on day 1 when he just wanted to snap a screen shot.

[mouser]

One system that I think is a great tradeoff for balancing the needs of tweakers, developers, and casual users, is the system where some really advanced options are hidden away in an area that doesn't even have a nice option user interface.  Think of the firefox about config area, etc.

This is a good system because these advanced tweak options are hidden from normal user, available to tweakers, and don't require careful user interface design by the coder and make it very easy to expose new settings.

[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)

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

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).

[ewemoa]

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

I am reminded of The Magical Number Seven, Plus or Minus Two.

[anandcoral]

The main accounting app I develop for my company has a big 'settings' dialog. Initially I used to put all in one big window, separated by box/lines. As the options grew, I made them tab pages. Then again tab pages grew to multi-line tabs. Last I made them to tree, similar to mouser's screen shot.

What I have found that the initial loading of the 'settings' window becomes slower and slower, as all options with tab/tree are made. In fact I show a 'Please wait..' while loading the settings window.

Now as a user I get frustrated when I need to enable/disable just one/two options and I have to wait for the full window to load. I was thinking of some logic which allow me to show the window quickly the 1st tab/tree-node and build rest in background, then again user may just want to go to the last tab/node at first ! Haven't found a good way to have both.

In my freeware apps I generally keep the few settings in main window and add new ones in 'advance' button. The 'basic' options I decide on the options I gave in first few releases, as user expect them there in main window, and add few most used, based on experience or so, to it. The advance window may have tabs/tree and may take long to load. This way, I think, I can make both type of users happy.

Regards,

Anand

[Renegade]

The main accounting app I develop for my company has a big 'settings' dialog. Initially I used to put all in one big window, separated by box/lines. As the options grew, I made them tab pages. Then again tab pages grew to multi-line tabs. Last I made them to tree, similar to mouser's screen shot.

What I have found that the initial loading of the 'settings' window becomes slower and slower, as all options with tab/tree are made. In fact I show a 'Please wait..' while loading the settings window.

Now as a user I get frustrated when I need to enable/disable just one/two options and I have to wait for the full window to load. I was thinking of some logic which allow me to show the window quickly the 1st tab/tree-node and build rest in background, then again user may just want to go to the last tab/node at first ! Haven't found a good way to have both.

In my freeware apps I generally keep the few settings in main window and add new ones in 'advance' button. The 'basic' options I decide on the options I gave in first few releases, as user expect them there in main window, and add few most used, based on experience or so, to it. The advance window may have tabs/tree and may take long to load. This way, I think, I can make both type of users happy.

Regards,

Anand

You are looking for this:

http://www.infralution.com/virtualtree.html

The speed will blow your mind. I made a test application with a sick amount of data in it with ZERO wait. Try it out. There's a source version available as well.

[anandcoral]

Thanks Renegade for the link. I have forwarded the same to my colleague who is developing our ERP in .Net.

The accounting app I am maintaining is done in Xbase++ with TopDown. It is Clipper (DOS) like language. To save development time, our company went for it as our product is in Clipper originally.

Regards,

Anand