Proposal: Improve the dataset dashboard with a more visual card-view layout

[xuang7]

Hi everyone,

After the hackathon, we saw several creative interface ideas related to workspace discovery. I think this is a good opportunity for us to discuss a broader improvement to the current dataset/dashboard page.

Proposed direction

For the dataset dashboard, there are two directions worth exploring (some of these ideas may also apply to the workflow dashboard):

• Card-view layout: add a card view alongside the current line-by-line list, making it easier to browse and quickly understand what datasets are available.
• Richer metadata display: surface key fields at a glance on each card, such as dataset name, short description, owner, visibility, tags, last updated time, and an optional preview or cover image.

The goal is not necessarily to replace the current list view immediately, but to explore whether a card-based dashboard could make dataset browsing more intuitive and visually clear.

Related references:

• Dataset Bank hackathon project (PR #5097)
• Workflow dashboard card-view (PR #4216)

Current dashboard (today):

Reference: Dataset Bank (PR 5097) from the hackathon:

Reference: AI-generated sample layout (for discussion only):

Please feel free to share any thoughts, concerns, or suggestions. Thank you.

[chenlica]

I prefer the 2nd option "Dataset Bank (PR 5097) from the hackathon," as it is more compact.

[Yicong-Huang]

I also like card views. I think this is a good design. The "AI-generated sample layout" is on this direction and much more beautiful.

[zyratlo]

In general, I prefer the card-view layout over a list as it offers more space for descriptions, although we could have both and let the user toggle between them. I think tags are a great feature to have, as they offer both organizational benefits as well as searchability when these datasets are uploaded to the Hub. I am in favor of allowing the user to upload a cover image, as it can make datasets instantly recognizable.

[Yicong-Huang]

yup agreed

[mengw15]

I agree with @zyratlo. Having both list view and card view, with a toggle between them, seems like a good direction since they serve slightly different browsing needs.
I also vaguely remember that we had some previous effort around supporting list and card views for the dashboard. Maybe we can continue from that effort.

[carloea2]

Just wondering, should in general apache/texera main focus be to improve UI/UX?

I think there are other issues in the queue, like: "performance", "AI tools", etc.

[chenlica]

@carloea2 Texera has a user-facing interface. Improving its UI/UX is definitely as important as other issues.

[Yicong-Huang]

improving UI/UX is not conflicting with performance or other features that sounds more hard core. In fact, UI/UX is quite important to attract users.

[carloea2]

In general, based on my recent experience, I care less about traditional UI interactions and increasingly rely on chat-based agents to get things done.

At the hackathon, we saw a demo where the entire UI could be managed through chat alone, which reinforced this direction.

External collaborators also mentioned that Texera is difficult to run because it consumes a lot of resources. Given that, I think a higher priority should be optimizing the system so it becomes more accessible to a broader group of users.

[Yicong-Huang]

Yeah I'd love to make things more efficient! feel free to start a new discussion about how to improve performance! we can discuss about UI/UX as well: they are not conflicting.

[Ma77Ball]

I had opened the original PR on adding a card view. I think it is a good option.

[xuang7]

Yes, I saw your PR. It looks good! I think the card view is a good direction to explore.

[Yicong-Huang]

mind link the PR here for reference?

[xuang7]

refer: PR #4216

[Ma77Ball]

I do like the amount of new features from the PR in the hackathon. However, after a quick glance, I do see that it will need significant work and review to be production-ready.

1. It needs to be separated into separate PRs (too large to review in a timely manner).
2. Needs to leverage existing code to reduce the number of code additions strictly to UI/UX

Note

I think my PR and the hackathon PR are guilty of this, in that too many lines are added to achieve this feature, and I do agree with @carloea2 in that if adding card view will add a significant amount of code to our repo, it is not worth it. If either of these PRs is merged, they need to be heavily reviewed and refactored.

[Yicong-Huang]

of course, let's break down into small PRs for review and merging into main. Here the discussion is about direction/design.

[xuang7]

Agreed. In this case, I think I will start with a lighter PR focused on the new layout direction, rather than directly adopting the larger hackathon PR. The Dataset Bank (PR #5097) I mentioned is mainly an external-source dashboard, so I would use it as a design reference. For the actual implementation, I will try to keep the changes small.

[Xiao-zhen-Liu]

I also like the card view, especially the one shown in the Hackathon demo. The current list view might be okay for "Your Work", but for a community work discovery page, the card view looks more attractive and intuitive, and more "community-like". I think we could let "Your Work" and "Hub" have different visual styles.

[kunwp1]

I agree with this idea. I always wanted to improve the dataset UI.

[SarahAsad23]

I also like the card view. It looks clean and makes it easy to quickly view richer information about each dataset. It would be nice to have a toggle between both views, depending on how much information the user wants to see.

[chenlica]

The card view has the most support. Let's go with this layout then.

[xuang7]

Thanks everyone for the suggestions! There is an ongoing related effort for the card view display in another repo, and I will open a PR in this repo soon.

[xuang7]

Hi everyone , I would like to get some feedback on the implementation design for the proposed card view.

There are currently two possible directions for the dataset card view:

Option 1: Cover-image-based card view

This option uses a larger cover image to make the dataset listing more visual and easier to browse.

Sample 1:

Option 2: More text-based card view

This option uses a more text-focused layout, where the cover image is excluded, optional, or displayed as a smaller thumbnail. This may work better for datasets that do not have meaningful cover images.

Sample 1:

Sample 2:

Please feel free to share any thoughts or suggestions. Thank you!

[zyratlo]

I like option 1 more, I wonder what the best size for the cover image would be to both still be meaningful but take up less space to compact the design.

[Yicong-Huang]

I am unfortunately not in favor for option 1, the main concern is the image (there will not be any real user spend time to find a cover image for a dataset), and the lack of useful information on the card.

please see my detailed comments in #5215.

[xuang7]

Thanks everyone for the input! Regarding the images, I agree that many datasets may fall back to the default image if no cover image is provided. We could consider using the agent to generate cover images or providing more varied default images as future improvements. @Yicong-Huang

[zyratlo]

Randomly selecting a default image from a larger pool would help with all of the datasets looking alike. It could even be as simple as keeping the diamond pattern image but using different colors.

For the information on the card, am I correct in saying that everything currently included is all the metadata we currently save? We could have another discussion about improving the metadata, such as adding tags.

[xuang7]

Randomly selecting a default image from a larger pool would help with all of the datasets looking alike. It could even be as simple as keeping the diamond pattern image but using different colors.

For the information on the card, am I correct in saying that everything currently included is all the metadata we currently save? We could have another discussion about improving the metadata, such as adding tags.

That's a good idea! And yes, for the option 1 sample, we don't need to add new fields for now. We can adding tags or improving the metadata as a future improvement too.