Related to This Question, I'm interested in what I should do with a responsive design theme where the users have control over the columns which are displayed in a tabular, data rich page. Users are able to manipulate which columns are displayed, so I can't just limit the data to a few columns, as the other question's answers suggest. A potential work-around is to have a custom "mobile" query set up with pre-defined columns which I design for, but I can't control whether the users use this view or not.

Right now, I just have each column in each row stacking on top of each other and centered. I think this is not a very good design, as it wastes space and doesn't look organized. How should I best tackle this problem?


enter image description here

Mobile View:

enter image description here

  • 3
    I'd suggest turning tabular data into "cards" with a title (subject, #) and details within the card, rather than trying to keep a column structure.
    – Zelda
    Commented Dec 28, 2011 at 16:44
  • 1
    I guess not being able to see multiple records at a time will defeat the purpose because the comparative aspect would then be lost. That way, a table is a must and a record at a time will not help -- am I on the same page?
    – Kris
    Commented Dec 29, 2011 at 12:03
  • +1 for @BenBrocka 's suggestion. Collapsing tables into "display views" follows one of the main principles of responsive design: ALL your content is important (mobile clients don't want "less content"). See css-tricks.com/responsive-data-tables/ for a sample. Commented Dec 9, 2013 at 19:18

12 Answers 12


Good question! As always when it comes to small screen experiences you will have to focus on the core functionality. Ask yourself which columns could be removed and still present a meningful table and let the user select the additional columns that he is interested in.

This solution might help you: A Responsive Design Approach for Complex, Multicolumn Data Tables.

It essentially recommends what has already been said: use only essential columns...

tables on responsive design

...and give the user the option to decide which columns to show.

tables on responsive design

The good thing about the article is they throw in some code.

UPDATE: CSS-Tricks has published a Responsive Data Table Roundup article.


Since you say the data can't be limited to just a few columns, I suggest a couple heuristics to guide the interface design.

Start with a primary column, all others are secondary
Choose your key column to be at the left-most: hat do users look for first as an identifier? Here it is the subject. Then look at the most important margin: what do users look for change in first? Let's assume status is a good candidate, since users are likely to look for changes to that.

Let users scroll horizontally
Since you say you can't limit it to two columns, let users scroll to the right or left, a column at a time. But if one column is really key, let the lock it and only scroll the other column (just like in Excel or Google speadsheets).

Let users reorder column priority
The column priority determines what order columns appear, left-to-right. Start with a default based on your choice around the key column, but let them reorder it. Then display accordingly.

Make column headers clickable to sort the column. Allow people to add filters at the top.

mobile table wireframe

  • These are some good points. The clickable column headers to sort, and the user's ability to reorder columns and add filters already exist, as default functionality, albeit not in a drag and drop form. I was debating whether or not there should be a horizontal scroll. This would definitely allow the most data to show in the table and look the most uniform with additional columns. I originally really liked the idea of having no horizontal scrolling - but I'm not an experienced designer, so that's why I'm asking this here! Thanks!
    – xdumaine
    Commented Dec 31, 2011 at 15:42
  • 1
    Horizontal scroll for this sort of interface is a little unconventional, but it's tough not to have. Look to the mobile interface of Google spreadsheets if you can.
    – Taj Moore
    Commented Jan 2, 2012 at 0:24

There are a couple of implied assumptions in the scenario you've presented that, if thoroughly examined, will make your decision easier.

1 The data is tabular.

Just because you are returning records from a query and by default displaying them in a table, does not make the data "tabular" from a UI perspective. The key is that the primary function of tabular display is to compare multiple set items by one or more item characteristics. Think analysis of data. Grouping and sorting in tables are convenience options that make the analysis of the data easier to achieve using a single table, but are still secondary to the primary function of comparison.

Lists are usually better suited to displaying a set of data for the purpose of locating one or more items of interest based on a few key characteristics. Sorting and grouping a list of data facilitates bubbling items of interest to the top of the list for improved "findability". Ordered lists imply sorting by one or more characteristics, and grouping is achieved by multiple sequential lists or sub-lists.

In my opinion, based on a cursory look at the data you linked, you may want to question whether the occasion of use for your data is more comparing or finding.

2 The mobile use case is fundamentally the same as the desktop use case

This is the big question that underlies the decision to "go responsive" only. Responsive design primarily addresses displaying (mostly) the same information on different screen sizes. In some situations, the mobile use case [context, user goals, info needs] is different enough from the desktop need that a responsive solution forces an unacceptable level compromise for one (or more) sets of users. When this happens, a distinct mobile solution is a better option.

In your case, I would decide first if the use cases are the same, or whether designing distinct experiences is a better fit. If they are the same, then examine the use case of the "tabular" data. If it's primarily finding item(s), then go with a list based solution and employ sorting/grouping options and potentially collapse/expand list items (perhaps only on mobile) if it helps focus attention on the characteristics of primary interest.

If the use cases are the same, and comparison of multiple items by characteristic(s) is the primary purpose of the data display, then collapsing the table down to fit 320px by removing or hiding data is actually worse for the user than zooming and/or scrolling horizontally over the complete table. In this scenario, fully responsive design is not appropriate.

Sorry for the long-winded response - hope this helps you make a choice.

  • Upvote for pointing out that the use cases on mobile may well be very different! I think this is often missed when first thinking about mobile design. Commented Feb 19, 2018 at 13:18

Responsive/Adaptive Table

I recently created this pure CSS/Bootstrap solution for mobile users. Works best with 4-5 column tables mainly. 3 columns seems to be the max you can show on a mobile device before serious truncation occurs (depending on your data of course)

enter image description here

Here is the Bootply link.


Here are several different kinds of solutions (with examples) to choose from depending on your needs. My favorite is the version that turns the table into a list on mobile screens (brilliant!):

Original table:

Original Table

Converted to list via CSS:

table converted to list


Also see: bootstrap version and the jQuery plugin, FooTables

  • 1
    Welcome to the site @Justin. Can you summarize the content from the links? Link-only answers tend to rot over time. Commented Dec 6, 2013 at 22:30
  • The beauty of this approach is that when the table is "listified", it still is a table in the DOM, which means javascript enhancements (such as client side filtering) still work. Commented Dec 10, 2013 at 23:59
  • This is an elegant solution and displays all data, all of the time - why should a mobile user be penalised? Hiding columns is not a good idea for a couple of reasons. If the data is important enough to be included in the table then it should be displayed, why should a mobile user not have immediate access to the content? Who decides which content gets hidden? Allowing the user to choose which columns to show assumes that the user knows what content is in each column by the label - not always obvious. Commented Jan 6, 2015 at 10:51

I think you would get a good result if you displayed the columns side by side and truncated the information in each field. The amount of truncation necessary would increase if the user chose to display a high number of columns.

Since the user gets to decide what fields they would like to display, they shouldn't be confused by shortened headers.

Implementing some functionality to expand columns if a user touches it on the screen would be a great, possibly essential, feature for this type of design.


Mobile Version:

I guess the best solution would be to display only a couple of most important columns which are always there in a list view and when you tap on anyone list item you have a dialog displaying the details corresponding to that list item.

like List View

21 Consider floating short table elements in list mode


20 "button" sizes should be 32 pixels or larger

And if you tap on no. 21, you can see the whole detail and you can also put next and prev button there to navigate in detail mode.


I like this approach outlined by the Fillament Group.

In essence, the article advocates looking at the columns and identifying which columns are the most important. After the columns have been prioritized based on this importance, see what fits on each of your viewport dimensions and remove columns as you scale down.

The article goes a step further in providing a button to allow the user control which columns to view which is a nice idea even though may not provide the best results for all datasets and devices.

Lastly, when the user clicks on the row; I'd recommend what other's have mentioned in providing a detailed/card view with all of the data associated with that particular record.


Think mobile first. Can this data be presented in meaningful way even if it's not in a table? Sometimes a table is a necessity, so you're stuck with it, but sometimes a list is as efficient if not more-so. This is typically true when there are a few key columns of data with the rest of the columns being ancillary to those primary columns.

In that situation, you can consider a list type of layout. The same data is presented but each row is visually shown as a 'card'. The key data columns are visually emphasized, with other key data minimally. If there is a significant amount of meta or secondary data, on a small screen it may be hidden by default and made accessible via a miller-columns (ie, a '> / see more' type of icon to show a new page).


download bmml source – Wireframes created with Balsamiq Mockups


In general, large tables aren't really mobile-friendly because of the limited screen space. Thus, you need to figure out what information mobile users need and work from there. If they absolutely need everything, the question that you linked has some great suggestions, such as card view.


On limited space, display the bare minimum, if a user picks a row, it switches to card view, and allows them to flip through the deck viewing all the details.


If it is possible from the coding point of view and it otherwise suits the application, I would suggest as below.

a) The table format would be essentially the same as you now have. Make all the columns standard width. That is, each column occupies table-width/#columns.

b) Each of the columns will display as much data as fits in the column.

c) When data in a column overflows, the full field value will be displayed only on the tool-tip.

The user is free to define the columns he wants to display, and will see the value in any field in a space that is practically as big as the application window permits, in the form of a tool-tip.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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