I am in the process of redesigning an interface with a lot of Tabular data that is previously simply used as tables that look like the 19th century. I was a bit confused whether to switch it to a Card View sort of layout and present the data in that way, or to leave it in a Tabular View itself and instead just style around it.

I would like to know what could be the better approach when it comes to User Experience and what seems more at ease to the customer as I want the product to be easier for the customer to use rather than looking complicated to them.

The users of the product would be on the financial sides of the industry so, if needed please keep that into consideration.

  • Per JohnGB's answer, I don't think there's enough 'meat' in this question to answer it. – New Alexandria Feb 3 '15 at 17:48

For me, the primary difference in these two layouts is content.

Tabular views allows users to see a lot of information in rows. Referencing the header when needed, the information is always available and takes precedence.

Card views allows the user to always have reference to the header information in each 'cell'.

The best option here would be to discuss both layouts with users and see which provides the best, most contextual information for them.

Don't just assume one is better; users can forgive a bad style choice. Confusion and lack of information can be less forgivable.

  • thanks for the precise answer mate, it surely solves my problems. – Tanmay Saxena Mar 4 '15 at 9:16
  • No problem, Happy to help! – Stewy Mar 4 '15 at 9:18

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.

  • Thanks for the reply mate. I will surely consider these things when going in for the data presentation part. – Tanmay Saxena Mar 4 '15 at 9:15

Card views and tabular views solve fundamentally different problems. Although I have to admit that card views have become the flavour de jour, they are often not the right choice.

Card views work best when your primary goal is to view the data for a single item. Tabular views work best when your primary goal is to compare data between items.

So which one is best for your situation depends heavily on what your primary use case is.

  • 1
    thanks for the reply mate, also for the precise overview of what suits what kind of purpose. – Tanmay Saxena Mar 4 '15 at 9:16

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.