This isn’t a whole lot you can do with a card view that you can’t do just as well or better with a table. Both allow the user to easily see and interact with (e.g., edit in place) a modest number of attributes (or fields) for each data object. If you design your table to work on a mobile in landscape orientation, then you’ll be able to show about as many (or more) attributes per object and objects per screen-full as a card view. Both tables and cards can include graphic coding of attributes (e.g., colors, icons, sparklines). Both are relatively simple and likely familiar to your users (tables have a very long history in financial services; card-view-like UIs are common on the web –such as this web site). Both can be made complex-looking or simple-looking –whatever you want.
A table has the following advantages:
It’s easier to compare objects because the attributes are directly aligned on top of each other.
It’s easier to scan for objects of certain target attribute values because each attribute is alone in a column that’s easy to scan down. This also makes it easy to recognize the sort order.
Your attributes labels only need to appear once on the screen as headers at the top (assuming they don’t scroll away). With cards, you either have to repeat the labels for each card, or leave them implied. The former consumes real estate and the latter can cause confusion.
So what’s a card view better for?
When you have two-dimensional attributes, such as multi-line text boxes or medium-to-large pictures that don’t fit well in a table. Relatedly, when such “heavy” attributes vary considerably in size from object to object, and your cards adjust their size accordingly, then cards will make better use of the real estate.
When you have lots of attributes which would force the user to pan a table for each object even in landscape orientation. However, even then card view is only better if the user is looking at many attributes for relatively few objects, rather than relatively few (and adjacent) attributes for many objects.
The thing is, when you start getting heavy attributes or a truly large number of attributes (like so many you need to use tabs), you’re better off with something other than a table or a card view. You’re better off with a “paging” UI, where each object consumes the entire pane or screen. So card view is relegated for fairy narrow in-between cases between pages and tables.
You can endeavor to combine the advantages of tables and card view by having a master-detail UI, where the heavy or additional attributes of each object are shown in an “overflow” pane for the current object shown above in a separate tabular pane. That works very well when you have a fair amount of screen space, such as on a tablet, laptop, or desktop.