2

I've noticed that some programs collapse child folders when the user collapses the parent. That is, when the parent is collapsed, then re-expanded, the child folders all appear collapsed. Others, however, remember the state of child folders - when the parent is re-expanded, the child folders appear in the state they were before the parent was collapsed.

Are there any guidelines on when it is appropriate to use one behavior over the other? Or does it come down to developer preference?

1
  • I didn't realize that there was a UI site. I agree that the question should probably be migrated there, but I'm not sure that I have the privileges to do so.
    – quanticle
    Feb 22, 2011 at 16:56

3 Answers 3

4

I don't think this question can be answered out of context. How often does the user access specific folders, and how much of her work is centered around them? If a lot of my work takes place in My Documents/Prototypes, then I'll be grateful if they'll both expand when I expand My Documents. On the other hand, if I'm working on 10 different projects and I keep switching between them, then the following will happen: I expand the Projects folder, and the last project I worked on is expanded. But I now need a different one, so I expand it manually. The next time I expand the Projects folder, two subfolders will be expanded, and I'll expand a third one, etc. Very soon I run out of real estate, the subfolders I do need disappear deep below the fold, and I need to either scroll or tidy the place up by collapsing folders manually. My navigation becomes inefficient and frustrating.

In short, my rule of thumb is - if the user is expected to be working with a few folders, remember their states and make them more accessible. If she is expected to be working with a lot of folders, try to reduce chaos and keep it tidy and efficient.

5

Personally I think it should remember the state of the child folders since the user did not explicitly close them. That seems more in keeping with the philosophy of not making things the user did go away without an affirmative action on their part.

In reality: I think the reason it is common for apps to NOT remember the state of sub-folders when the parent is collapsed is that it is much easier to code this way, not because someone decided the users like it better that way.

2
  • 1
    I agree on both points. I'd one thing: depending on context, I'd remember the state of sub-folders only for the duration of the session.
    – Hisham
    Feb 22, 2011 at 19:07
  • Actually, in most cases, it is harder to write the code to collapse the subfolders when collapsing the parent. To do so means that you would need to loop through all of the children to change their state as well, not just the state of the folder that you chose to collapse. Feb 22, 2011 at 19:41
-2

It all depends on the usage pattern. If you want to let the user customize the behavior, you can have a Yes/No type persistent setting that says "Collapse and expand child folders along with parent?". So if the user selects it, the child folders collapse and expand when parent folders are collapsed/expanded. The default behavior can be a deselected option.

5
  • 3
    This seems like too trivial a thing to bother the user with a preference for to me. Do this for everything like this and you'll drown the user in a sea of options.
    – ICR
    Feb 22, 2011 at 23:25
  • @ICR: The original question itself is too trivial thing to bother. My answer is a suggestion to the original poster to let the user decide what they want. If the user happy with the default option there is no action needed from the user's part. The setting I suggested is very similar to the folder options you select in Windows (e.g whether or not to display hidden files with the default being not to display).
    – yasouser
    Feb 23, 2011 at 3:21
  • arumug: it's deciding those trivialities that make the difference between usable and great.
    – peterchen
    Feb 23, 2011 at 10:20
  • @peterchen: I know that. But the original question wasn't able to decide which option to decide. Hence the suggestion to make it as a configurable option with a default choice (very similar to what facebook does with privacy settings). Those who doesn't care won't change it. And those who are very picky in the interface's behavior can alter it.
    – yasouser
    Feb 23, 2011 at 13:42
  • 2
    arumug: Maybe I should have been clearer: You are right that it's just a small detail, however, in virtuall all cases, such details should be decided by the developer. For a typical application, you end up with dozens, even hundreds of such settings - which scares most users. A typical user will not even realize the frustration when he collapses and expands a node, and can't go back to the previous sub node easily. But these small frustrations accumulate, give the user a feel of "not in control" without understanding why.
    – peterchen
    Feb 23, 2011 at 14:04

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.