Anyone who knows me well is also aware of the unhealthy obsession I have with backing up my data, manually. People who relate to that also understand the importance of keeping a track of one’s selections deep inside a folder chain, especially when one is working with large amounts of data. I have come across various ways in which some sort of a signifier is added to an element in a tree-list to convey its selection state and respective parent-child relationships that it may have. These range from the standard node connections used in the classic Microsoft Windows UI (now replaced with indentations) to common motifs in the icons which act like colored tags (as in the body and feature trees of some CAD modelling UI) .
This method of information display is the most familiar one across UIs whenever large file and folder chains are to be visually represented in a limited retail space; compared to an actual visual representation of the tree, it only makes a limited section of the list visible to the user – this, too, is displayed sequentially via scrolling action. Thus, it becomes easy to lose one’s location in a large folder tree, also, navigating out of it and in between the parent folders adds to the clicks and the scrolls unnecessarily.
To address some of these issues, I decided to work with a hypothetical file tree which would have two kinds of elements at every node, these would be the folders (expandable and collapsible elements) and files (nodes with a dead-end). Then constraining myself to not use anything similar to a line, to show the hierarchies, I decided to go with a very Gestalt approach to make this visible.
I also made use of a very wise solution noticed in the Visual Studio UI which highlights changes, additions and removals in the lines of code in a file in the scroll bar itself.
Also having the parent entities have an always-present representation for quick access made sense against scrolling all the way to the top to find the parent element.
I spent two nights just sketching the visually different concepts and seeing how they fare against the scenarios I had imagined in this hypothetical file tree. It was surprising how much a shift or spacing by a single character could make such a big difference in the overall interaction capabilities for such a UI component. Once finalized, spent a night creating the assets and animating them on Adobe After Effects.
The proposed concept takes into account multiple use-case interactions with a file and folder tree.
- The subdued gray dots convey the hierarchy between the list elements, these darken right from the top of the folder chain, when hovered over.
- Selections are marked blue and their appropriate node connections remain visible, a colored-dash signifier also appears in the scroll bar conveying the global location of the selections in the list.
- Once an expanded parent folder gets obscured, as it is scrolled out of the view window, an abstract element takes its place (this will be at the top as the file-folder lists are sequential and top-down) which can still convey the selection or hover state with a change of color. Hovering over this displays the name of the obscured parent folder and clicking on it snaps the view back to this element at the top.