stac-browser icon indicating copy to clipboard operation
stac-browser copied to clipboard

Show cards in column mode or in deck mode?

Open christophfriedrich opened this issue 10 months ago • 8 comments

The results of a search returning 7 items are placed like this:

grafik

POST payload: {"datetime":"2024-03-04T16:00:00.000Z/2024-03-22T16:00:00.000Z","bbox":[9.855059787160437,53.706217520227575,9.958056613332312,53.746842207166445],"limit":12,"collections":["sentinel-2-c1-l2a"]}

christophfriedrich avatar Apr 04 '24 09:04 christophfriedrich

This is somewhat intentional. We are using Bootstrap Cards and they have two "layout" modes:

  • columns
  • decks

Decks (and default) are row-based and make the cards all the same height.

Columns are obviously column-based and allow flexible-height cards. We use columns and this leads to this behaviour because the columns are filled one by one and we don't have enough elements to fill the last column.

We chose columns because we have issues wrapping in deck and default mode correctly once the cards got too small.

This is maybe something to revisit with a CSS guru who can make the deck-based wrapping work. ;-) But the other question, should the cards all be equal height? Maybe not?

m-mohr avatar Apr 14 '24 21:04 m-mohr

Ah okay, that explains it. IMO the column mode is absolutely not intuitive. I would 100% expect results to be ordered from left to right, then top to bottom, just as we read text (in Western culture) and how file explorers do it etc. Hence me writing this issue.

Yes, there is newer UI that puts content by columns, e.g. image sites, but I think that's mostly because they often have content with very mixed dimensions -- which is not really much the case here, is it? To me it feels that thumbnails are always squares anyway. And searches will often give results from a consistently structured collection, so very homogeneous appearance. Also, our UI is not about filling as much screen space as possible with something that might catch the user's attention to keep them on our ad-run site longer, but about rendering technical things cleanly. Therefore my answer to

the other question, should the cards all be equal height?

is a fairly strong: "I don't really see a good point why they couldn't be all equal height, especially not one that outweighs the irritation caused by the current behaviour."


Regarding the issue blocking my desired behaviour:

We chose columns because we have issues wrapping in deck and default mode correctly once the cards got too small. This is maybe something to revisit with a CSS guru who can make the deck-based wrapping work. ;-)

If you tell me what issues exactly you're having I'm happy to see what I can do ;)

christophfriedrich avatar Apr 16 '24 14:04 christophfriedrich

@m-mohr Feedback has been given ;) If we agree on wanting to switch to rows, I would invest the time to fix that CSS issue.

christophfriedrich avatar Jun 10 '24 10:06 christophfriedrich

If it has the tag "feedback wanted" I hope for more than just one person, but I'd appreciate a PR so that we can experiment with it. I'm personally not sure yet, which approach to take. I think I agree with rows for most cases if we can make it work. (Thinking more internationally, maybe this even should be influienced by the writing direction?) From my experience with the initial experiments, we need to test quite a variety of catalogs and screen size scenarios.

m-mohr avatar Jun 10 '24 10:06 m-mohr

Hi there!

I hope it’s alright to jump in with a quick note that might seem off-topic. Have you considered using the grid system provided by Bootstrap (https://getbootstrap.com/docs/4.0/components/card/#using-grid-markup)?

I've been testing this locally with the STAC browser, and I’ve noticed that some catalogs lack complete information, leading to inconsistencies in card heights and a potentially disorganized user experience, especially with larger catalogs.

Here’s an example of the issue:

image

By making just a few tweaks to the code, I managed to implement the grid system for the cards. This adjustment ensures that the cards wrap properly and maintains a consistent height across rows, resulting in a much more visually cohesive overview:

image

I’d be interested to hear if you’ve tried this approach and if you’ve encountered any issues with it. I’d be happy to create a pull request to explore this further. However, please note that my experience with Vue is limited, so the code could probably use some further improvements.

JanssenBrm avatar Aug 13 '24 09:08 JanssenBrm

@JanssenBrm I'm happy to review PRs. I just can't find the grid system for cards in Bootstrap Vue right now so I'm not sure whether it's supported or "hacking" in pure Bootstrap? What's the difference to Card Decks?

m-mohr avatar Aug 13 '24 10:08 m-mohr

Thanks for the quick response @m-mohr !

The key difference in the implementation is that instead of using a card group, the cards are placed within a <div> that specifies a row, and each card is then enclosed in a <div> with column specifications. This setup allows you to set widths based on grid breakpoints, closely following the example from the link I shared earlier.

I’ll go ahead and create a PR to provide a clearer picture of this approach.

JanssenBrm avatar Aug 13 '24 10:08 JanssenBrm

Thanks a lot for jumping in @JanssenBrm! I appreciate that I'm not the only person who finds the current card layout a bit chaotic, and even more that you actually took time to think of a fix!

I was promising a PR that fixed the CSS issue, and did start experimenting, but didn't get on a promising path. So I put the issue onto the backlog to look at again later, but then that never happened.

-> If this new approach seems somewhat doable, I'd recommend to follow it, as my approach seemed like a dead end the last time I tried it.

christophfriedrich avatar Aug 13 '24 11:08 christophfriedrich