Replace `view` styles with TUI for metadata exploration

[joelostblom]

I think the view command could benefit from being modeled less closely after the build command. In the current design, it is envisioned that view should take styles just as build, but I wonder if that design choice is limiting how we think of the view command.

For build a large reason for different styles is to choose how content is displayed to readers of a website; these readers have no possibility to change the style the metadata is displayed in, they just interact with the page that the designer created. So depending on the audience and the data package content, the designer can choose which style they think will be the most effective.

For view the audience will be the person typing the command in the terminal and there is no need to tailor the output to specific target audience. The content of the data package might still have some impact no how one would like to display it, but more importantly I think that someone using it from the terminal wants an effective way to explore the metadata rather than just different static viewing styles.

While I have been thinking about this for a while, I was sprung to write this issue after getting some first hand experience trying out flower with on-limit's feasibility metadata as mentioned in #327. There are many tables with so many fields that outputting it into stdout in terminal makes it unusable. Piping it to a pager helps and adds some search etc, but it is still too basic as it doesn't allow to easily search for fields across tables, see the existing resource, etc.

Currently, putting the metadata from a large datapackage on a webpage via build offers a better experience for exploration than trying to use view in a terminal. But it doesn't seem reasonable to require someone to build a web-page every time they want to explore the metadata from a large data package; especially for those personas that are more technical and likely to work with the metadata more extensively for their own discovery process rather than for the purpose of presenting it to an audience (e.g. me understanding how the metadata is structured in the onlimit feasibility study). I think what we want is a terminal user interface (TUI) that allows for more complex metadata exploration. At least that is what I would want for exploring metadata myself =) And aligning with the seedcase motto of that we are our own first customers, I built one. Here is a demo, and there is a PR of a more minimal implementation in #331

recording-2026-05-06_14.35.29.mp4

Some discussion questions:

1. Do you think this TUI would be a useful addition in flower?
2. Should this tui be the default (or even only) output for viewing metadata in the terminal?
   • I have been thinking about whether we should also support stdout (as currently) and/or pager. My first thoughts are that stdout could still be useful if someone want to pipe the output elsewhere, but a specific pager output might not be required (the stdout could just be piped to the pager if desired and I'm not sure how buil-in pager would support look crossplatform).
3. Do we want to deprecate the use of styles with view?
   • With the background of how I think view could be more useful, I'm struggling to imagine any use cases for styles in the terminal. We only have one style currently and it seems more relevant to be able to filter what metadata fields are included rather than how it is "styled" (and that is a job for a potential query language as per Some querying features would be nice in view #259). Implementing the TUI does not depend on removing styles, but unless there are any envisioned use cases I think we can remove them to avoid confusion around what they do and how they interact with e.g. the TUI.
   • In the browser, the main use case we have so far for styles is whether resources are shown on separate pages or all on one page. In the terminal this would be the difference of either outputting everything to stdout ("one page") or to the TUI. Supporting different styles within the TUI might be possible, but I can't envision the benefit here as I'm thinking that the TUI is more centered about a functional workflow than a specific presentation style of the content.
   • I experimented briefly with multipage styles in the pager by adding horizontal lines as page delimiters, but it isn't really a big difference from not having them and I think we could just always include them in the stdout output.
   • I also experimented with different styles in the TUI, but didn't experience any benefit and it is more performant to skip the markdown conversion and display and using built in DataTables etc instead of markdown tables, so we would need to support a different type of style for the terminal if we want them.

• Another option would be to keep view as is and instead introduce a new explore command or similar with the Tui functionality. But I'm leaning towards that we don't need both...

[joelostblom]

Tagging @seedcase-project/everyone since this is a larger change that it would be nice to hear from everyone before deciding on.

[lwjohnst86]

Very neat idea and I think going the TUI route for (at least our own uses) is something I've been thinking for a while. I also didn't enjoy using view for such a large dataset as ON-LiMiT. Having said that, here's some comments:

especially for those personas that are more technical

Using a TUI and using keys to navigate around is not just "someone more technical"... This is a highly technical, poweruser. These type of people are extremely rare in research and even in software dev are very uncommon. A fair number of software devs have no idea about vim keybindings (only me and you use vim in Seedcase), let alone TUIs. So, no view still holds a place for those who are "more technical than the average person", but not so "elite" as to be very comfortable in the terminal using only keybindings.

large datapackage

I think this is something to keep in mind. The average research dataset is not nearly as complicated as the ON-LiMiT data. So what you experience with using view is not the normal/typical experience for data packages. Even for data we will use, it won't be that extensive (e.g. DP-Next questionnaire, while having lots of survey questions, won't have that many tables).

1. Do you think this TUI would be a useful addition in flower?

Yes for sure!! 🎉 I would definitely use it.

2. Should this tui be the default (or even only) output for viewing metadata in the terminal?

No, definitely not. There is still a strong use-case for view as is. In fact, I think we should add another command called tui so we don't need to touch or modify the existing view.

3. Do we want to deprecate the use of styles with view?

No. See above.

[joelostblom]

Glad you like the idea and thanks for the comments! My comments on your comments to keep the brainstorming going:

The average research dataset is not nearly as complicated as the ON-LiMiT data....

I agree, but when I thought about simpler datasets, it was still a bit difficult to imagine when I would prefer to see the output in stdout rather than in the TUI. Even with our simple examples, it seems like an interface that allows for easy copy paste is easier to get started with, which is why I was thinking of it as the default? I can see the argument for programmatic interaction with the output e.g. via piping being easier via stdout, but it doesn't sound like what you have in mind. I'm not totally against having the current view as the default, but I couldn't think of a strong scenario myself.

Using a TUI and using keys to navigate around is not just "someone more technical"... This is a highly technical, poweruser. These type of people are extremely rare in research and even in software dev are very uncommon. A fair number of software devs have no idea about vim keybindings...

I think there might be a misunderstanding here. There is no requirement to use VIM keybinding in this TUI (or TUIs in general, just the ones you and I like xD ). The default keybindings include the arrow keys and I only added vim-keybinding because I wanted them. We can show key shortcuts in the bottom panel and it's also possible to use the mouse to navigate, even with the simple prototype I put up:

recording-2026-05-10_13.10.55.mp4

More generally I disagree that TUIs are more elite/technical than CLIs. I think interacting with visual elements such as in a TUI is often easier to get started with because it is more similar to GUIs, which most people are more familiar with. Particularly here since it's a point and click user interface, similar to a GUI, just that it runs in the terminal. I think this actually makes it easier than a CLI since you don't need to know how to interact with stdout in a terminal, how to copy paste, etc.

No. See above.

I didn't see any argument in favor of keeping styles in view. Can you elaborate / or we can discuss in person? As I wrote above, the main use case we have so far for styles for web pages is whether resources are shown on separate pages or all on one page. In the terminal this would be the difference of either outputting everything to stdout ("one page") or to the TUI. Maybe you have some other idea in mind for view styles that you can help me understand?

[martonvago]

The TUI looks really cool!! I definitely see how this can be more useful than a static printout, especially for packages that are too big to fit on the screen.

I can't really take a side on whether it should be the default. It depends on what terminal users would find most intuitive. I agree that using the TUI is not difficult, but it is also true that most people will not have seen a TUI before.