Roadmap for the Table View in Modern UI

Feedback & Ideas
1

I’ve generally held back on going down the rabbit hole of comparing Modern UI with Classic, but I would be interested to know what the future direction of the Data Table presentation is. I made reference to a number of shortcomings of Modern UI’s data table presentation back in September last year, so apologies that I am repeating here some of what I said then, but I feel it is important.

With the various improvements that have been made to Modern UI, I enjoy using it, and mostly will do so in preference to Classic UI (although I do still switch between both).

I know there have been a number of discussions concerning the Modern UI Table views here on the forum, and as I have mentioned elsewhere, I am excited about the upcoming 5.3 release, but as yet I have not seen much mention of major changes to the data tables views.

I don’t want to jump the gun and from looking at the nightly build, I do know that 5.3 is likely to bring with it the introduction of shortcut keys for opening the various data ports both in the lower data panel (Shift+0 = Flow Variables, Shift+1=First data port, Shift+2=Second data port, and also as popup windows (Alt+Shift+0, Alt+Shift+1… etc). I’m not necessarily wild on the choice of key assignments - and would prefer to be able to define my own - :wink: , but it’s an improvement on having no keyboard shortcuts.

Besides the shortcut keys though, I’ve not spotted much else new with the table outputs themselves, and this is a key area that I’d like to see improved, as for me it is one area where I still find I’m working much less efficiently in Modern UI vs Classic UI.

Take a look at the following two windows. They both take up exactly the same amount of screen real estate, and are both presenting data from the same table.

image
image1027×912 64.4 KB

The top one looks more modern, for sure, and yes it does have a search field, but the lower one remains to me so much more efficient in actual use.

Key features:

  • I can read the Row ID beyond Row9, without any effort
  • I can view more rows at a time (less wasted space)
  • I can view more columns at a time (less wasted space)
  • I can wrap the column names (as shown) so I can read the entire column name for all columns with a single operation (and still see more rows and columns!)
  • I can page up/down using key presses
  • I can navigate between cells using key presses (Cursor Keys, Home, End, pgUp, pgDown etc)
  • I can select multiple non-contiguous columns or rows, using the Ctrl key for copy/paste e.g. to Excel (yes it’s a thing :wink: )

I use (almost) all of the above features pretty much all the time when using the classic UI or the “Interactive Table (legacy)” node, and I really notice the inefficiency of the Modern UI table, as soon as there are lots of columns, with no simple way of displaying (wrapping) “whole column names”, and no way to view entire column names without manually widening every individual column.

Don’t get me wrong, the Modern UI data table is slowly improving. The whole Modern UI is getting better. The ability to detach a table is an improvement from where we were with 5.0, but, I see the continued inefficiencies in the table view as likely to be the biggest blocker (notwithstanding Console Log) to adoption of the new UI by many of the stalwarts of Classic, so I’d be interested to know what (if any) is the road map for the above list of features.

To me, they aren’t just “nice-to-haves” but are essential to the ongoing success and adoption of KNIME and the Modern UI. I hope that efficiency and usability improvements to the Table Views are seen as a priority. If they aren’t…well… I think they really should be. Thanks. :slight_smile:

2

Yes, copy functionality (especially with column names) is something I’ve always wanted.

In addition, I would like to mention one more point about more compact data display. This is actually a problem that old users have been criticizing, that the information density is too low.

Of course, the KNIME team may have their own ideas. But I think if we are really not sure, it is better to add an option, such as normal display form, intensive display form, and then the team will conduct telemetry on this option. I believe it can get better data on user tendencies.

Btw, sometimes I think about this from the perspective of a software engineer, because the classic interface and the new interface use different technology stacks, and they have different levels of difficulty in implementing the same features. Some things that the modern interface has will be unlikely to appear in the classic interface, and on the other side of the coin, some features in the classic interface may not be added to the modern interface for a long time.

Roadmaps are a great way to align users’ thoughts with the team, especially on such a specific and concrete problem.

1 Like
3

Table visualization is an essential part of the power of KNIME. Indeed, assuming that visual programming emphasizes the speed of prototyping algorithms, it is essential to allow developers to modify intermediate parameters (intermediate nodes) based on the final results of a flow. However, if this flow handles large quantities of data, the creation of the visualization of the table for each node induces additional time during each modification of a parameter.

Overall, we notice a clear slowdown in the refresh (or even processing) speed when developing flows where we move from one node to another, quickly. The important thing for those who create a workflow is to have rapid feedback. Isn’t the goal to respond to a request and then there is always time at the end of the process to create a slicker presentation for those who will use the results.

It is certainly interesting to be able to create filters but this is possible directly via a specialized node leaving the other nodes the possibility of being quickly evoked.

The Eclipse interface oriented towards development offers a lot of visual facilities such as the tree of nodes visible continuously, constant visibility of complex workflows (folders, sub-workflows, etc.) the console allowing you to follow the progress of the installation of extensions and console messages. All these functionalities can be removed and put back depending on the use of KNIME (development/visualization) leaving the user with the choice rather than imposing it.

1 Like
4

Hey @takbb,

thanks for the detailed feedback. Let me give you a little insight of what we are currently working on and comment on a few others. The Table View is the most prominent view we have in the Modern UI and I totally agree with you that we have to get this one right. We are constantly trying to improve it, which makes these threads extremely valuable for us to see what we already achieved and what the areas are that we still need to put some work in. Lets focus on the points you mentioned:

I can read the Row ID beyond Row9, without any effort

  • It is not yet solved, but we at least increased the default space so that you are able to read the first 99 rows instead of only 9

I can view more rows at a time (less wasted space)

  • This is always a tradeoff between readability and being able to see as many rows as possible. We already introduced a compact mode and a larger mode, which is currently only configurable in the Table View node, but we might need to go over the compact mode again in order to safe some more space.

I can view more columns at a time (less wasted space)

  • This turns out to be very hard to solve properly. For sure wrapping the headline is one possible way, but this only helps if the content of the column is not large. We don’t yet have wrapping column headers but at least in the Table View node yo can already configure the columns to make themselves only as wide as the content (or content + headline). This will help in the cases where you are only interested in the values and not so much about the headline. Currently this cannot be configured for the port view, but we are aware of this issue and will introduce this in a future release. Would be nice if you could try it out and give us feedback if this already solves some of your problems.

I can wrap the column names (as shown) so I can read the entire column name for all columns with a single operation (and still see more rows and columns!)

  • Definitely something we are still missing and we will introduce this in the future

I can page up/down using key presses

  • Something that is on our list (internal reference: UIEXT-1865)

I can navigate between cells using key presses (Cursor Keys, Home, End, pgUp, pgDown etc)

  • Also something that is on our list (internal reference: UIEXT-1864)

I can select multiple non-contiguous columns or rows, using the Ctrl key for copy/paste e.g. to Excel (yes it’s a thing :wink: )

  • We already looked into it and it turns out to be not super easy to get this right. Doesn’t mean that we will not do it, but this will require a bit more time :wink:

Side note: Copying selections including the column header is already possible (just press CTRL + SHIFT + C), we are just missing the context menu to make this better visible.

Hopefully this helped a little. Please keep the feedback coming and rest assured that we are still heavily working on the table. (For the upcoming 5.3 we mainly focused on the performance of large tables (lots of columns), which should hopefully also increase the usability of the table by quiet a bit)

Greetings,
Daniel

4 Likes
5

Thanks @DanielBog , that’s exactly the kind of detail about future direction that I was hoping for. Good to know and greatly appreciated! :slight_smile:

1 Like