This button seems to have the wrong hyperlink or maybe the page isn’t public yet?
I will echo the points that @swebb made below. I cannot figure out a way to view results tables in another window nor if we can have multiple workflows open at once. I hope these are just due to this being a preview and not the full version.
I found using the Bar Chart (KNIME Labs Extensions) node that the text for the chart title types in backwards “enacirruH” rather than “Hurricane” for example.
First of all thanks for the feedback – that kind of feedback is really helpful to us.
Regarding your feedback
We are considering whether to open the table at the bottom as a modal as well, like in the current version.
Yes, the frontend is completely web based. Someday in the future you need to rewrite the renderer to a format that will be a web compatible format (e.g. SVG/PNG …). However we will try to support the swing based renderer for as long as possible. The idea is that the output of the swing based renderer is turned into an image by the framework, but this is not entirely evaluated yet.
Like both of you noticed, at the moment it is only possible to open one workflow at once. However, it will be possible to open multiple workflows in the future.
The forum thread will be visible after the official release and then the redirection will work as expected.
I like to overall look and feel, but here are a few things I noticed and I wanted to give feedback on.
- No search in the open workflow selection window.
- Open workflow doesn’t get highlighted when hovered over, i.e it doesn’t go from yellow to black.
- No obvious way to open another workflow in addition to what is currently open.
- No table output view. This is especially crucial as the table output view has some core functionalities such as search, sorting, and table formatting (e.g making the font, column and width bigger)
But overall, I like the look and feel, and I am excited about the python integration!
first of all thank you very much for the valuable feedback. This is the kind of feedback we are looking for to get it into a shape where it is most useful for our users. Now to your points:
- The open workflow selection window is just a start and makes use of existing functionality. We want to improve that in the feature and I agree that a search field would make a lot of sense.
- This is intentional. The idea here is, that the ‘create workflow’ is the primary button and the ‘open workflow’ is a secondary button. That is why the highlight color is a bit different (changes from dark grey to black).
- This is a very good point and we are aware of this limitation at the moment.
- Also a good point. The table you see at the bottom is just a start. In the future we want to integrate the same table we are using in the new ‘Table View’-node. This new table will then also provide the functionality of searching, filtering, etc…
Great to hear that you in general like the new look and feel and if you encounter any other problems let us know.
Is there a way to open a component - the only options on right-clicking a component are Create Component and Expand Component. Without Open Component it is all a bit of a dead duck.
you can enter a component by holding command (mac)/ CTRL (windows/linux) and double click onto the component. But I agree that there should probably be an option in the context menu to do this.
Hope that helps,
This is actually a very good idea to make the use of Python easier. Question is could you check if a lot of important packages are tested and bundled. I noticed that OpenPyxl seems to be missing - a popular package to manipulate Excel files.
Good point about OpenPyxl @mlauber71 ! That was not on our list for KNIME 4.6, but we will take a note for upcoming KNIME releases. Keep the ideas coming
Below is the list of currently bundled packages, which will also be publicly released with the 4.6 documentation tomorrow.
@carstenhaubold I have tried a few things with the new Python integration and standard models and graphics seem to work quite well.
- h2o # there is obviously a knime implementation but for some advanced things it might be nice to have it - xgboost - lightgbm - auto-sklearn - autoxgb - pycaret # no deep experience - featuretools # feature generator - miceforest # Missing value replacement - prophet # time series analysis - openpyxl # Excel Reader - arrow - orc
Question would be which ones should feature in a standard Python environment since experience unsers could always use a custom environment. Also I understood that there will be some development where you could build nodes based on Python - this might be a way to integrate specific packages (or would they use a central python environment?). Looking forward to this.
Another idea could be to also fully integrate a R version (though the variety of packages might be even larger). The Conda Environment propagation allows for the (well) propagation of a R version via conda/Miniconda - for Windows there are the R Windows Binaries - but maybe this could be a way for other operating systems too.
the UI looks very modern… but all node configuration modals are “old-fashioned”… Do you see a chance to adapt these as well?
Moreover, it would be great to implement as many of the “old” “Right-Click” options in the new UI. At least for the “old” users, this might be very convenient.
An UI is always a topic for discussions, but I think that the shift to a webbased UI is the right step. And it looks very nice. Congratulation!
thank you for your feedback! Regarding the ‘old-fashioned’ dialogs: Absolutely, we are working on modern configuration dialogs, too. However, since there are thousands of nodes, it’s nothing we can achieve ‘over night’ and there will be a transition phase (that’s why we still use ‘old-fashioned’ dialogs in the modern UI). If you like to have a first impression how the modern configuration dialogs look like, just check out our new View nodes (still in Labs, more View nodes to come).
Your second question is best answered, e.g., by @schramm.
@mlauber71 I would advocate that the number of ‘standard’ packages in KNIME is kept to a minimum. The rational for this is version control and dependency management. It is important from a KNIME component development and system management perspective to set the versions for each package so that APIs remain consistent. It would appear that we are currently on Python 3.9 which is a good reference point from which to select other packages with known features and capabilities.
As the KNIME version increments so should the Python packages - with known breaking changes well publicised. If this is not managed and controlled from KNIME then all hell will break loose.
@DiaAzul I fully agree that KNIME will have to weight how much packages would be there in a ‘standard’ environment and which packages are left to experienced users that can (quite easily) configure their own settings with the help of the Conda Environment Propagation (which again might slightly differ between operating systems). With Python the management of dependencies is always a challenge.
I wanted to offer a few packages that I have in mind, specifically OpenPyxl since questions about additional Excel file manipulation come up in the forum quite often.
So packages might be chosen for the extension of critical functions (Excel, file formats, Graphics, Time Series, Machine Learning) and offer at least one option own all these fields preferably the most common one and leave out exotic examples and ones that are not well maintained.
It would also be great to see boto3 bundled to make it easier to interact with AWS services that do not already have KNIME nodes.
I worry about this increased emphasis on switching to PNG/SVG rendering of chemical structures.
These do not allow resizing like the renderers do. Also a very useful feature of the renderers is you can copy the cell to the clipboard and then paste into other chemically aware software programmes. That will be lost with image rendering.
It feels like we are taking increasingly retrograde steps with chemistry handling.
Totally valid points (in all threads btw) - all of the feedback everybody provides in one of the threads will be discussed internally (or already is) and considered. We want to get it right and the entire team is waiting for more input.
Obviously, some things will change and be done different in the future, but we really want to avoid complicating simple things or actually decrease the day to day experience of our users. Your (and the feedback from everyone else) is exactly the reason why we asked for feedback so early. Keep it coming and thank you
I worry about this increased emphasis on switching to PNG/SVG rendering of chemical structures.
This isn’t exactly what I meant, I think you mean something along the lines of using a Renderer To Image node? This is slow, requires everything to be pre-computed (no paged on the fly rendering) and as you say you lose things like copy the underlying serialised form of the structure.
What I meant is providing a PNG/SVG render for a chemical structure cell rather than the Java Swing implementation. I think RDKit renders may actually be generating a SVG that is then rendered in the KNIME table.
A solution like the first option will be bad (this is how I view structures in composite views and it’s has the drawbacks highlighted). With the switch to a new frontend technology we’d want to keep the capabilities around structure based cells we already have I agree !
Yes you are right, looks like we are discussing different issues !! I will be very upset if we lose the on-the-fly rendering of chemical structures with the underlying serialised form of the structure available to copy elsewhere. The Interactive Table View node is one of my favourite KNIME tools, and I get the feeling it is being slowly fazed out.
I also share your concerns on the Rendered to Image angle too, as I also make use of the Reporting capabilities.
This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.