Open Misjohns opened 1 week ago
If the full file path will not fit in field we should truncate the path using ellipses (...) in the middle of the path. The full path should display in a tooltips.
@Misjohns This looks much better, thanks for mocking this up. The only concern is (or I am over thinking :D ) , if the taxonomy directory structure deepens significantly this tree search component might go out of bound.
The typeahead should help the user locate a path endpoint fairly easily; only expanding the folders that a match is contained. If we feel the taxonomy will grow very deep then opening a dialog with a directory selector could be a better experience. Thoughts?
The typeahead should help the user locate a path endpoint fairly easily; only expanding the folders that a match is contained. If we feel the taxonomy will grow very deep then opening a dialog with a directory selector could be a better experience. Thoughts?
I think at this point, tree view looks like a really good user experience to me, so we can probably go with that. If we really hit the depth issue, we can revisit this and think of directory selector. No point in over designing based on hypothetical scenarios :).
The use of the PF tree view with guides provides a similar visual structure to the taxonomy by displaying data in a hierarchical view. A search input can be used to filter tree view items and provides the user with a quicker way to access nested path items with fewer clicks. We should support the ability for the user to quickly modify their selection by clicking the path, expanding the menu, and being able to click a different item (as seen in the PF menu select with typeahead). PF Tree with search | PF Tree with guides | PF Menu select with typeahead