this is a feature request and question. i don’t like or understand the VL node browser hierarchy. a breadcrumbs or accordion menu interaction would be a lot more intuitive compared to “deleting” category tags to move up in the hierarchy.
i could even live with this if it wasn’t in the wrong place. you navigate in a vertical list and then you have the hierarchy in the bottom right? feels wrong.
would be interesting to know what concept is behind this interaction.
The node browser is about
Intro to node references:
In VL all nodes come with Name and Category which is already a slight difference compared to vvvv, where all your project nodes are not categorized. Let’s for now think of this as a desirable improvement.
Often enough though you might not care to choose the right category right from the beginning and may want to clean up categorization of your nodes later on (if ever). This can happen to you as an end-user who just wants to have a big projects’ nodes be categorized in a clean manner, but more likely it happens to you as a library developer.
So if you do such a refactoring and not all patches that depend on your nodes are currently open, we can’t just fix them on the fly, we only can make all open patches be affected by such a re-categorization or renaming.
In any way when doing such refactorings you want to break as few patches that depend on your library as possible. So we wanted to provide a system that makes the chance of breaking patches just a bit less likely.
As a consequence of all these dry boring forward-thinking thoughts we decided to store just that bit of information that actually led to choosing the node and making that query unambiguous. If you searched for a node by name and the name in your patch is unambiguously resolvable as only one of that name can be found no further questions need to be asked and only that choice will be saved into your patch as a reference. If the node would get moved into another category in the meantime the node reference would still be resolvable next time the patch gets opened.
Another observation we made when thinking about folders or hierarchies in general is that often enough it is just not doable to think about everything in a hierarchical manner. Sometimes you start thinking: this is the main aspect and therefore we need these main categories and later on it turns out it would have been wiser to sort things by another aspect first. This is may happen to us, even though we will try to avoid this as much as we can or it may later on happen to library developer.
Just think of stupid things like ‘oh let’s move “Resources” or “String” to “Basics”’ and “3D” under “Graphics” or “Math”. Things like that can happen to others as well.
Our node reference system is pretty ok with such changes where categories get moved into other categories. Here is why:
When choosing a category in the node browser you tell us that you want to get a node somewhere under that category, no matter how deep it may hide in sub-categories and also no matter how deep that chosen category is hidden when looked from the root. So let’s say you type “Fo” you’ll find the “Foo” category under “X.Y.Z.Foo”. You choose Foo and afterwards a node inside. X.Y.Z won’t be stored. So Foo may wander and also the node may wander underneath Foo and show up in Z.Foo.A next time and still be found.
For the case that it actually can’t be found we still store the exact information of the full category, the file and even the package for a fallback system, for a converter system and for the user to show in a tooltip when everything fails.
So what are node references in short? They are sort of queries for a node, where the query might include infos such as look in these categories (optional) for a node with a certain name. As a user you can create these queries in different ways. Start by choosing a name or start by choosing a category (not necessarily a main category) and then edit your query. The browser will tell you if your query is ambiguous by asking multiple choice questions.
For those familiar with c#. The using statements can be seen as queries as well: “Look in all these namespaces when trying to make sense of the following code”. It would be quite hurtful to always write down the wohle namespace before each type that you want to use. Also again it would put too much unwanted information into your source code.
Our system though comes without patch-wide usings as this felt to much of a dry burden for the user.
Let’s get back to the op question :P
Why this ux? Well, this was the try to combine technical and dry ideas (storing as few info as possible) with a unified browsing experience.
The system delivers browsing top down and deep searching within the same mode. There is no choosing category view vs. by-name.
This system also tries to not confront you with long node names, but rather always break down the information in digestible bites of choices, each of wich can be canceled and re chosen.
What could still be better in terms of presentation?
Of course still many other options are possible of how to present upcoming choices and made choices.
When searching for nodes we could show the matching nodes within their categories (like in nested opened folders). But how would we need to interpret such a users choice? I guess we’d have to include all the categories into the query, as this is obviously what the user just chose.
Anyway. You now know some of the ideas behind it.
Ah: its down there because it felt right to have it near the cancel button.
Open to any suggestions or general criticism though
thanks for the explanation. ok it is tags then, once again…
and why would you place a tag filter near the cancel button ?
i would suggest that filters are placed above the list of things, similar to the vvvv website or any other website using tag filter. it would even feel a bit like breadcrumps in a way. i understand that you want to reinvent/rethink the wheel but learned interaction has the advantage of being kinda intuitive from the start.
thanks for your input!
the intuition was just that those made choices are not that important in the typical workflow: fire and forget, focus on the next choice. Also, all you can do to the made choices is to cancel them - e.g. pressing ESC several times will clear the stack one by one and when empty will “press Cancel button”. That’s why they are placed down there right now.
But: of course you are right and the placement of those filters can also be put above the text box or right below it and by that communicate that they have an impact on what’s shown below. Absolutely right.
i forgot to say where this is coming from. i tend to browse through the node browser to learn new nodes. this is what i teach my students as well. aka “checkout the 2d category” to learn more.
therefore the usablity is kinda crucial although it might not seem important if the “tags” are left or right, top or bottom… in the long run it makes a difference and for beginner it’s easier to understand if things are in context. it’s not just fire and forget, it’s also an indicator of navigation
in such a discussion i find it important to distinguish between browsing the library and looking for a specific node. for getting an overview, browsing, exploring and jumping around a classic tree structure in a bigger window might be just what you need. for creating a specific node the current node browser does just fine.
putting two different views onto the library into one UI results in a compromise which makes neither use case optimal. currently it’s more optimized for creating nodes. once that works well we can think of a more browsing friendly mode… if you have more ideas for that, i’d be interested to hear them.
gregsn said it already very thouroughly and i’m not asking for categories. this is not a discussion about that anymore, just positioning. the last post was meant to tell you where my complaint initially was coming from, what i expected as a user when using the node browser, right. could be valuable information for the design of things.
anyway, tags could still be more related to the list by putting them top or bottom of the list. top would be more usable since the list can grow bottomwise. more prominent tags would help to remember the tag filter collection for a specific node since it not just somewhere offcenter.
let’s leave it at this, i’d do it that way. you might prefer the off center position.
This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.