here is a new question for my fellow colleagues.

I am creating a framework and trying to standardize table creation, so I have to take under consideration all possible scenarios and am between decisions concerning large tabular data that expand off-screen with multiple row-actions.

I have already created two flavours of tables for small screens, either the table is scrollable off-screen or have a collapsible version of stacked cells.

enter image description here

  • Collapsible version. The vertical ellipsis icon includes row actions in a popover.

However, since our applications are using HUGE tabular data (like 100+ columns) and some of the rows have actions that cannot be translated into distinguishable icons (e.g. Flood reporting) I have to come up with a solution for large tabular data with many actions in text format. Stacking this kind of volume of data vertically is out of the question, so a solution has to be found for the scrollable version of the table.

enter image description here

  • Scrollable table

However, it is obvious that it is bad UX for a row to have actions off-screen. Keep in mind that these rows will probably have to be selectable as well.

I have thought of creating a fixed column with a popover on the right, but am not really fond of this solution; adding to the previous comment, imho, checkboxes should always be on the left of the row, so having two fixed columns - one on the left for checkboxes and one on the right for actions feels wrong. Having checkboxes and actions on the right feels even worse.

So, the best scenario I could think of, that is somewhat limiting, is to have a 'multi-select' icon off-screen, only appearing on small screen resolutions so that the checkbox row only appears on-demand.

I am wondering what kind of ideas do you guys have? I would like to avoid any swipe-related solutions due to these feel natural only on specific sets of devices.

  • These actions are in columns for themselves (or an icon inside a field)? How many of these action columns will there be?
    – Alvaro
    Commented Jan 9, 2017 at 11:18
  • They should be placed in their own column. There is no restriction to the number of the actions or text width - there is great variety of actions, so I am trying to think of the worst case scenario. Commented Jan 9, 2017 at 11:20
  • So, just to clarify, the actions will apply to the whole row, not to a particular field?
    – Alvaro
    Commented Jan 9, 2017 at 11:23
  • Yes, they should apply for the whole row. Commented Jan 9, 2017 at 11:48
  • Backing up a bit: Is there a use case for needing to access the actions on a huge table of data on a mobile screen? While I understand that you're trying to build out a framework, this seems like a scenario where something custom should be created if mobile usage is high priority.
    – Sullivan
    Commented Jan 9, 2017 at 14:15

4 Answers 4


In my opinion the way of displaying the data should adapt to the device where it is being displayed. Because users interact differently on each device. So my first suggestion is to give a reconsideration to non-scrollable (in X axis) solution for touch devices with small screens.

If you need a scrollable solution this my suggestion:

  • Keep Column name row always visible
  • Hide all the actions, behind a Menu always accessible. The Element row menu includes actions related to that row, while the Column row includes actions to apply to several rows.

.. ..

If you need to apply an action to several rows at one time, in order to avoid the first image, include a menu icon (perhaps different to the row ones) in the Columns row with several actions that would need to select rows.



Material design - Data tables

  • I like your answer. Was going to suggest almost the same thing, but I'd have rather kept the checkbox out of the action menu as it would otherwise make the concept of simultaneously selecting multiple rows senseless and all the more tedious if you have to click twice to select each row.
    – ikartik90
    Commented Jan 12, 2017 at 12:52
  • You are right, Ill clarify that. Adding that extra column adds even more fixed elements. But if the selection is important then it must be there I guess.
    – Alvaro
    Commented Jan 12, 2017 at 12:54
  • The menu could also be incorporated in a context menu on right click sort of fashion, the way google drive does. On mobile one could go for a click and hold for context menu.
    – ikartik90
    Commented Jan 12, 2017 at 13:20
  • 1
    @ikartik90 you mean press anywhere in the row to display? It frees up space but the bad thing is new users might become crazy looking for the menu icon.
    – Alvaro
    Commented Jan 12, 2017 at 13:22
  • 1
    @scooterlord As the Checkboxes are used for applying a certain action to more than one item, the proposal is: Displaying common actions in the Header row. Once selected the action the checkboxes appear, user selects and after clicks the apply or cancel button.
    – Alvaro
    Commented Jan 12, 2017 at 15:41

I dealt with a similar scenario working for one of our clients who had a similar situation. This is how I dealt with the problem:

Rows listed on left with selected row detailed on the right

I listed the table rows with the primarily required columns, that the users referred the most, directly visible to them. When a user wished to see a row's information in detail, they would click on the row and the right side fixed pane would pop out that was independently scrollable vertically within its bounds. On mobile, the number of columns of the main table would shrink as the size degraded and the right pane would pop out from the bottom of the screen as the user tapped on it. The actions pertaining to the row (eg. Edit record here) are listed in the right pane as the user clicks the particular row.

Row information displayed in an accordion

Another variant I had presented was displaying the data in an accordion like table, as @Alvaro has suggested above. The only issue with this one is that the table columns form a grid sort of a structure leading to the hampering of the overall readability of data.

  • I don't see any solution to the multi-select issue though.. Commented Jan 12, 2017 at 15:27
  • ..I see an 'export all' button at the bottom, but this design doesn't help on Iphones where clicking at the bottom of the page, the safari action row appears so you have to click twice.. Commented Jan 12, 2017 at 15:33
  • @scooterlord For iPhone, you could open a collapsible widget of actions from the right end of the screen listening for any actions on multiselect.
    – ikartik90
    Commented Jan 13, 2017 at 7:17
  • however the application we design should not be device-specific, so it has to look the same on all devices, so all device limitations have to be taken under consideration and functionality should be the same Commented Jan 13, 2017 at 9:41

So here is what I went with, and I find it a once-and-for-all solution for long tables that contain actions or multi-item actions.

If the problem was either solely mobile-oriented or desktop-oriented it would have been much easier since users depending on the device they are expecting different interfaces. In order for the design to make sense here is what was designed.

This is what the table looks like on a desktop device. If the actions are small, or icons are used, they can be expanded, for more actions the solution is a dropdown menu.

enter image description here

...as soon the table is larger than its parent overflown container and using javascript, shadows are added to the checkboxes and fixed actions column to indicate that their position is fixed and that the rest of the table is scrollable.

enter image description here

...when the table starts scrolling out of view, the header of the table stays fixed, and a shadow is added to indicate this as shown:

enter image description here

...following responsive principles, below a certain width, the multi-actions dropdown is essentially turned in a vertical ellipsis menu that contains the options.

The header multi-item actions:

enter image description here

The single-item actions:

enter image description here

For performance reasons, the fixed header on mobile is limited just to the item count and multi-action dropdown menu, since mobile devices cannot handle without performance decrease the re-positioning of the fixed table header cells. To be honest, I never saw a fixed header of an overflown table working on mobile properly, not even on applications, so, since it is not common, I find it more than acceptable to avoid it for mobile use.

enter image description here

Needless to say, it was a nightmare to make it work on all devices without noticing performance issues, while keeping its functionality the same along all browsers and devices, with the exception of the fixed scrolling header removal for mobile devices. I spent a lot of time on this one, and has been an issue that hasn't been dealt successfully forever - at least according to my standards, so I thought I'd share and (hopefully) make some of you happy, since it is is a cross-browser, cross-device solution that works great (tested on various devices - blackberry, windows phone, iphone, ipad, android mobile, android tablet) without performance issues. Enjoy!

  • Very nice solution you ended up with, thanks for sharing :) I was thinking maybe to improve the performance you could remove the shadows? Also for the opened menu, another option is to open it without the "close" button.
    – Alvaro
    Commented Feb 8, 2017 at 11:28
  • The shadows performance impact is not even visible, not even on my 50euro windows phone device. They render really fast - just for a heads-up, there is a also a trick with shadows, you can put them on an :after pseudo element with opacity:0 and change to opacity:1 when needed, so the heavy performance-wise shadows are rendered once and you play with cheap performance-wise opacity. I avoid the 'without' close solutions because the user might feel 'obligated' to click on an action, while they might click to any other part of the screen to close that might contain a link. Commented Feb 8, 2017 at 11:39
  • Nice solution though I expected you to keep the multiple actions in an action bar that would float above the fixed table header instead of repeating it per row.
    – ikartik90
    Commented Feb 8, 2017 at 12:37
  • What you are saying suggests that this multi-action bar is also visible on desktop screens as well... imagine viewing a table on a desktop that has enough space to fit its row actions but instead it has an action bar above it. Wouldn't that be confusing to users and waste of usable space? Commented Feb 8, 2017 at 14:53

Chris Coyier has published a table design where in the mobile version "each row is its own table":

enter image description here

Maybe this design could be useful for you. With that, it might be more easy to accommodate the action buttons for each "row".

In the mobile version, you could even make the rows collapsible in relation to a (user selected?) specific "column header". For example, while scrolling down you only see the last names and you only expand the full "row"-data, if you are interested.


https://css-tricks.com/examples/ResponsiveTables/responsive.php (DEMO: reduce browser width to see the effect)



  • 1
    I have seen these pages a million times. This still does not provide a solution to my problem concerning actions in a long row of data inside a scrollable table, that might be in a column that is off-screen. Commented Jan 9, 2017 at 17:58

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.