Tree Behavior: Context Switching, Open in the Context Menu, and "Standards"

Sometimes a change makes sense, until you remember the details and revisit the use cases.
We were recently working on a tree navigation element in the next release of our UI.

If you're unfamiliar with a tree, see this picture I took from my last visit to the United States.

A (small) tree.

I meant this tree.

The team was thinking a context menu selection, using a right-click mouse action, on a tree node would make sense to also select the item. 

1. Right-click on a folder,
2. A property panel would open on the right side
3. And then the  context menu opens, right?

Well, not quite. One developer pointed out that the next action could be to copy the folder in the tree and then paste it in the already open folder.

Oh. Yeah. Scratch that. Leave the already open folder open.

In the process, I also finally realized why context menus have an "Open" or "Expand" option, when you can already perform these actions without the context menu.

Isn't this redundant?

I suspect these seemingly redundant actions are there because after pressing right-click, as a user you may realize you instead want to open or view the contents of this second folder. Rather than forcing you to change your behavior, the interface lets you continue on.

This reminds me of why rooms have multiple light switches. Or the time my colleague and I were both right on an elevator with two buttons to the first floor lobby. Either path works.

Mini Lesson

We often rely on familiar experiences such as Windows Explorer or Mac Finder, which often have years to decades of research, common practices, and basic user expectations built into them.

They often serve us well when designing similar experiences, such as above.

We still need to be careful to keep in mind revisit the use cases, even if a small change seems like an improvement. And I'm specifically saying "revisit" rather than "keep in mind" or design, because you can only design so much up front before the design starts to cost more than the implementation and follow-up adjustments.

We want working software, designed, built, tested, and managed by people with a variety of perspectives and backgrounds, validated through early user contact. We get there by reusing what's available, designing what we need, trying lots of things, and being respectful even while taking different view points.

A sense of humor definitely helps.