in regards to a few another post of mine about Modern UI node configuration despite Classic UI being used, I noticed another inconsistency which significantly impacts user experience.
In essence, the classic UI is much leaner, self explaining and guiding the user i.e. by using icons for column types
Lacks contrast (many elements seem visually deactivated)
Lacks proper spacing (Checkbox margin left and right identical resulting in lack of visual grouping to corresponding label
Missing icons which are extremely helpful for visual orientation
Windows sizing disproportionate requiring longer travel paths for the cursor and eye
Tabs are missing like flow variables as they are hidden in the context menu
Pressing CTRL and clicking OK does not immediately execute the node requiring again extra steps
Some nodes have the new UI, other use classic (much preferred) UI resulting in an inconsistent user experience which requires the user to waste time for reorientation
Hi @mwiegand and thanks again for providing feedbacks,
Could you please explain this one a bit more preferably with examples e.g., screenshot?
I just created a ticket for this issue (UIEXT-1340).
We donât have icons for column types in Modern UI but if there is a request topic for this particular feature and it gets enough votes, I can discuss it internally.
Actually, you have already mentioned this issue here and here. Also, mentioned by @stefanomoscahere. So we already have it in our list.
Also, mentioned here. We have it in progress (UIEXT-1191).
There are thousands of nodes in KNIME AP and we are updating nodes to benefit the new dialog while improving the modern dialog appearance as well by utilizing your valueable feedbacks.
Great list @mwiegand - I would also love to see universal data type icons in the Modern UI. Incorrect data types tend to complicate and block the ETL process especially for new users. (For a very basic example: GroupBy canât calculate Sum on a string column containing all numbers.)
The easier it is to see the data types during configuration, the more obvious the issues become.
Edit: I posted it as a separate issue as you asked to get the voting started. I also think that icons would be a more obvious clue (and screen real estate efficient) in the ânode monitorâ view vs the current small italic font under the Column Name. It should be a uniform platform-wide data type icon as much as possible.
apologize for the duplication but I felt, since a few tickets had been created over time, that listing all in a consolidated manor and with a high level ticket description in addition to the actual suggest about the icons, might be a good idea. So thanks for checking all.
About the lack of contrast, this predominantly relates to the two column selection lists. However, here is a more explanatory example: Colour Contrast Checker
The example from @iCFO about GroupBy is just perfect! Icons also ease the understanding substentially. Just think about the different list types when configuring flow variables.
Surprisingly, the flow variable tab in the column filter node is still the âgood old fashioned oneâ but imagine the icons being gone! I wonder, though, why in this example again the UI becomes so inconsistent splitting the node configuration (1st tab) apart from flow variable configuration.
Adding to this no one will search for the other tabs like the âMemory Policyâ under that sub-menu. What about data streaming, which I didnât use for some time, wasnât there a special tab too?
Another backup from me on getting access to those flow variables during configuration. I donât get the philosophy of the split. Now we can only manage half of the settings in the Config window, then have to close it and right click to get to the flow variables. The worst part is that you canât even save / close the configuration window until you have acceptable âdummyâ values entered to pass the error checking, so that you can then leave / right click / setup up the flow variables which will overwrite those dummy values⌠Also you donât get that immediate feedback seeing that the flow variable setting greyed out the manual settings.
Prefer the tabs for easy access to the full config options.
I am not getting the philosophy neither. Quite often the setting in the flow variable tab is not names properly so you control the applied flow variable by checking the note at the bottom in the configuration tab and the change in the user interface (i.e. the input in the flow variable gets disabled).
It is just an unnecessary fragmentation, adding several clicks contradicting good UI design principle of grouping elements of similar function together and ultimately slowing down time to resolution and increasing the necessary efforts for beginners.
let me quickly jump in here and clarify a few things. The intend was never to fragment the UI nor to increase the amount of clicks. It was exactly the opposite that we tried to achieve, but we didnât manage to get that into 5.1. Therefore, we added the âold wayâ back to have the possibility to edit them at all. We received lots of feedback that in the classic dialogs it was hard to map a specific setting to a certain field in the flow variables tab. It might be named slightly different and is also hard to draw the logical connection (you have to switch tabs). Instead we want to provide a much smoother experience by providing the flow variables directly at the time and position you need them. (right at the dialog element they belong to).
I know that this is currently missing, hence it feels clunky at the moment, but let me give you a sneak of what is to be expected soon.
@DanielBog - I love it! It would be great to have an obvious visual indication when something has been assigned to a flow variable as well. Like the icon for flow variable or the entry field highlighted in red. Nice work!
There is already a little feedback. The Flow variable button will stay visible once you have set a variable. And there is also some minor indication if the flow variable is exposed or replaces a setting. (But might be way too hard to spot.). We will first focus on getting it done and into your hands and then we can iterate on that.
Love at first sight Thinking about the assignment of a variable what about:
A hint which type of variable is required like int, string, collection / list of strings etc.?
I assume only compatible variables would get listed?
In case of many variables being available, does the dialogue allow to type a name which then narrows / filters the available variable types?
What about the scenario (I only recall it from distant memories) if there are duplicated variables? The scenario was something like variable âAâ existing on the root level, passed and processed in a component which then transpires up again.
What is the first blank option in the appearing variable drop down for?
How does it look like when the formerly assigned variable becomes unavailable or invalid (type change)? Currently it is still present as some sort of placeholder to comprehend which variable is missing.
Since the new âchart nodeâ was displayed, which I love, I recently had an issue that required me to fall back to the current one. I havenât seen much movement about these (similar to the path type integration). Can you spoil any insights @DanielBog
PS: About the states if an input / config is managed through a variable. Iâd also ensure the border / stroke and the label are slightly gray-ish / transparent. I suppose it is also possible, since the interface is browser based (wasnât it?), to ensure the pointer is default basically adding the disabled attribute.
I agree with @mwiegand and @iCFO about the flow variables - it seems a really odd decision to hide that somewhere else at the same time that the help text is being moved from somewhere else (where actually it was quite useful and you could do stuff like print it if you wanted to) to more âintegratedâ.
not yet, but an improvement to all our dropdowns is planned
as far as I know a flow variable cannot exist twice. It would be overwritten by the last definition
basically to unset the variable. Might make sense to rename it to or similar
It will be almost the same. The flow variable is still set and it will prevent you from executing the node. We might want to highlight this case better in the future (red border or similar)
Not entirely sure what you mean with the âchar nodeâ so I can also not give any insights into this.
Ahh that makes more sense. What was the problem that you encountered with the new charts? (Sounds like a new thread would make sense). The new charts will continuously be improved and new charts will be added. Which are the ones you had to fall back to?
I cannot exactly recall what it was but something with flow variables. Going to crate a new thread when I manage to come back to this particular topic.
Thinking about the assignment of a variable what about:
