Symphony.

nathanhorby, I'm imagining each row would become a card, with the column header on the left, and the content on the right. Instead of 15 rows, there would be 15 cards. If the content is larger than a row, it'd just break over two lines.

Sounds good. We should really have a look at the new Kirby 2 UI. They do a lot things very well regarding a responsive backend.

I think the last example, "No More Tables" would probably work best for us. What do you think?

"The Unseen Column" could work as well. Having extra content in a table on a larger screen is nice to have, but not really that useful if you have cards instead on mobile (you can't really scan and compare entries that quickly with cards on mobile or sort entries that easily by a specific column).

The "Unseen Column" one is tricky. How does the CMS know which column is less important than another?

I guess most of the times the first column should work fine. But obviously not always.

The "Unseen Column" one is tricky. How does the CMS know which column is less important than another?

Order of columns. Only the first column is really important, everything else is nice to have and could be made visible/invisible in order of appearance.

I guess most of the times the first column should work fine. But obviously not always.

Can anyone think of examples where it wouldn't work?

Can anyone think of examples where it wouldn't work?

Let's say you have a persons section and the first column is the first or last name. That would result in a rather useless list. Obviously this could be solved easily with a reflection field, but the point is it would need to be set up accordingly in order to work. Which would be ok for at least.

Since we don't have any delete or edit buttons in the table directly, I think there's enough room to show the first two columns even on small devices (iPhone).

I don't think it's fair to assume anything. If the developer has thought it's important enough to display it in the first place, who are we to hide it?

I wouldn't feel comfortable hiding columns automatically.

I don't think it's fair to assume anything. If the developer has thought it's important enough to display it in the first place, who are we to hide it?

Ok, agreed.

I'd agree that hiding columns is risky. It's not rare for me, for example, to fully utilise the first AND last columns as the important ones (Order Entry being a common candidate for the last column) - sometimes the second column could add important context, etc. As @brendo says there's just no way to guess, without introducing new conventions and restrictions for the developer, anyway.

I like the card idea, it seems like the best of a bad situation to me - if there's any voting that's what I'll vote for :)

Are you guys proposing the "card" idea as a standard UI interface and ditching tables altogether?

Are you guys proposing the "card" idea as a standard UI interface and ditching tables altogether?

Tables on larger screens, cards on smaller screens.

Tables on larger screens, cards on smaller screens.

I was just thinking cards could look much nicer for all contexts and it could be a better paradigm moving forward. Just a thought.

I was just thinking cards could look much nicer for all contexts

How to sort on a row that way if a table could fit? Think of many entries.

Cards are still not ideal, but the best of the rest

I'm not so sure that the table view should be abandoned so easily. Allowing a quick overview of items just one of its benefits.

How about letting users choose which columns are shown on a narrow screen:

How should large table columns be handled on a responsive design? (UX StackExchange)

(Tablesaw is the resulting project from this page linked in the above answer)

@Neither

How about letting users choose which columns are shown on a narrow screen

I don't think it's just a matter of choice. If you need the user to be able to review 3 columns at once then it doesn't matter that they can turn them on or off if 3 columns don't fit on the screen. I have a few other reservations about this method as well in this context, but I think that's the main stumbling block for me.

It's a fantastic resource though (thanks for highlighting it), there are definitely contexts I would like to use that method in.

Others may disagree though, of course :)

EDIT: Although I had missed the 'swipe'/scrubbing interaction alternative - which is essentially a fancy version of a scrollable table. I quite like that (although if you want the user to be reviewing the first and last columns it would still have issues).

Admittedly the card method has issues when it comes to row comparison - so no method is perfect for every scenario I guess!

Nice