Tell me more ×
User Experience Stack Exchange is a question and answer site for user experience researchers and experts. It's 100% free, no registration required.
up vote 2 down vote favorite

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?

share|improve this question
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 '11 at 16:56

migrated from stackoverflow.com Feb 22 '11 at 17:36

3 Answers

up vote 3 down vote accepted

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.

share|improve this answer
up vote 5 down vote

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.

share|improve this answer
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 '11 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. – Charles Boyung Feb 22 '11 at 19:41
up vote -2 down vote

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.

share|improve this answer
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 '11 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 '11 at 3:21
arumug: it's deciding those trivialities that make the difference between usable and great. – peterchen Feb 23 '11 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 '11 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 '11 at 14:04

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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