Responsive design using ng grid #461

Closed
rbansalit opened this Issue Jun 1, 2013 · 11 comments

Comments

Projects
None yet
8 participants
@rbansalit

How can we make ng grid responsive. So that it should be able to display proper on desktop as well as mobile.

@rbansalit

This comment has been minimized.

Show comment
Hide comment
@rbansalit

rbansalit Jun 4, 2013

is it included in future plan or we should work it separately and then submit the code

is it included in future plan or we should work it separately and then submit the code

@gonzalophp

This comment has been minimized.

Show comment
Hide comment
@gonzalophp

gonzalophp Jun 6, 2013

Maybe this patch is all you need

#469

Maybe this patch is all you need

#469

@robertjchristian

This comment has been minimized.

Show comment
Hide comment
@robertjchristian

robertjchristian Feb 14, 2014

The concept the original poster is looking for is "write once, display anywhere." The problem is that, in viewports with less horizontal space (anything that is more portrait than landscape such as a phone), the columns either shrink so small that they become unusable, or the table is fixed in width so that the table becomes the only part of the page that doesn't fit within the visible area of the screen (breaking responsiveness). The responsive (modern, mobile-friendly) approach that will work is one that stacks the columns as the width of the viewport shrinks (based on css media queries... twitter bootstrap hides a lot of this work from the developer). Here is a simple example that is more along the lines of what's needed http://css-tricks.com/examples/ResponsiveTables/responsive.php ... a better name for this is probably "stackable grid", or "responsive grid" ... and it wouldn't have any CPU strain. It's just "if phone then render columns stacked" ...

The concept the original poster is looking for is "write once, display anywhere." The problem is that, in viewports with less horizontal space (anything that is more portrait than landscape such as a phone), the columns either shrink so small that they become unusable, or the table is fixed in width so that the table becomes the only part of the page that doesn't fit within the visible area of the screen (breaking responsiveness). The responsive (modern, mobile-friendly) approach that will work is one that stacks the columns as the width of the viewport shrinks (based on css media queries... twitter bootstrap hides a lot of this work from the developer). Here is a simple example that is more along the lines of what's needed http://css-tricks.com/examples/ResponsiveTables/responsive.php ... a better name for this is probably "stackable grid", or "responsive grid" ... and it wouldn't have any CPU strain. It's just "if phone then render columns stacked" ...

@roblarsen

This comment has been minimized.

Show comment
Hide comment
@roblarsen

roblarsen Feb 14, 2014

Member

I'm curious about how well that concept would work with intensive data grids. You're displaying the information, sure, but I'm not sure how useful that layout is for thousands or millions of rows since, often, the row isn't the interesting piece of data, it might be the columns. This stacked view wouldn't allow you to scan columns.

My initial idea for this would be to add a weighting system to columns and then use MQ + calculated classes to show/hide or render/not render based on device characteristics.

Member

roblarsen commented Feb 14, 2014

I'm curious about how well that concept would work with intensive data grids. You're displaying the information, sure, but I'm not sure how useful that layout is for thousands or millions of rows since, often, the row isn't the interesting piece of data, it might be the columns. This stacked view wouldn't allow you to scan columns.

My initial idea for this would be to add a weighting system to columns and then use MQ + calculated classes to show/hide or render/not render based on device characteristics.

@c0bra

This comment has been minimized.

Show comment
Hide comment
@c0bra

c0bra Feb 14, 2014

Member

Agreed. This was in my head for a plugin.
On Feb 14, 2014 1:22 PM, "Rob Larsen" notifications@github.com wrote:

I'm curious about how well that concept would work with intensive data
grids. You're displaying the information, sure, but I'm not sure how useful
that layout is for thousands or millions of rows since, often, the row
isn't the interesting piece of data, it might be the columns. This stacked
view wouldn't allow you to scan columns.

My initial idea for this would be to add a weighting system to columns and
then use MQ + calculated classes to show/hide or render/not render based on
device characteristics.

Reply to this email directly or view it on GitHubhttps://github.com/angular-ui/ng-grid/issues/461#issuecomment-35115668
.

Member

c0bra commented Feb 14, 2014

Agreed. This was in my head for a plugin.
On Feb 14, 2014 1:22 PM, "Rob Larsen" notifications@github.com wrote:

I'm curious about how well that concept would work with intensive data
grids. You're displaying the information, sure, but I'm not sure how useful
that layout is for thousands or millions of rows since, often, the row
isn't the interesting piece of data, it might be the columns. This stacked
view wouldn't allow you to scan columns.

My initial idea for this would be to add a weighting system to columns and
then use MQ + calculated classes to show/hide or render/not render based on
device characteristics.

Reply to this email directly or view it on GitHubhttps://github.com/angular-ui/ng-grid/issues/461#issuecomment-35115668
.

@robertjchristian

This comment has been minimized.

Show comment
Hide comment
@robertjchristian

robertjchristian Feb 14, 2014

I think in reality, a grid with (let’s say for dramatic impact) a trillion records is only going to show around 100 records max at a time (per page) by default on a laptop, and allow for filtering and paging. Moving it to the mobile responsive paradigm may mean that instead of 100 records per page, the default is closer to say 10 or 20. But this is natural anyway. There is no perfect way to get around having only 10% of the real estate on one device as compared to another and still keeping things legible and manageable.

I'm curious about how well that concept would work with intensive data grids. You're displaying the information, sure, but I'm not sure how useful that layout is for thousands or millions of rows since, often, the row isn't the interesting piece of data, it might be the columns. This stacked view wouldn't allow you to scan columns.

I think you definitely still need sort/filter/page capability. But who is scanning a significant number of records by the eye on a mobile phone? I’d say “Whoever isn’t aware that there is a better way to find what you are looking for.”

My initial idea for this would be to add a weighting system to columns and then use MQ + calculated classes to show/hide or render/not render based on device characteristics.

I think this works for some cases. But sometimes you just can’t give up fields. The only way to do it is to (a) stack it, or (b) fix the column width so that the majority of the grid ends up out of sight or too small to read when rendered on mobile. That’s why I suggest (a) for the general approach. With the ability to page and filter, it gets you the furthest without giving up legibility or data fields.

My two cents anyway.

On Feb 14, 2014, at 11:22 AM, Rob Larsen notifications@github.com wrote:

I'm curious about how well that concept would work with intensive data grids. You're displaying the information, sure, but I'm not sure how useful that layout is for thousands or millions of rows since, often, the row isn't the interesting piece of data, it might be the columns. This stacked view wouldn't allow you to scan columns.

My initial idea for this would be to add a weighting system to columns and then use MQ + calculated classes to show/hide or render/not render based on device characteristics.


Reply to this email directly or view it on GitHub.

I think in reality, a grid with (let’s say for dramatic impact) a trillion records is only going to show around 100 records max at a time (per page) by default on a laptop, and allow for filtering and paging. Moving it to the mobile responsive paradigm may mean that instead of 100 records per page, the default is closer to say 10 or 20. But this is natural anyway. There is no perfect way to get around having only 10% of the real estate on one device as compared to another and still keeping things legible and manageable.

I'm curious about how well that concept would work with intensive data grids. You're displaying the information, sure, but I'm not sure how useful that layout is for thousands or millions of rows since, often, the row isn't the interesting piece of data, it might be the columns. This stacked view wouldn't allow you to scan columns.

I think you definitely still need sort/filter/page capability. But who is scanning a significant number of records by the eye on a mobile phone? I’d say “Whoever isn’t aware that there is a better way to find what you are looking for.”

My initial idea for this would be to add a weighting system to columns and then use MQ + calculated classes to show/hide or render/not render based on device characteristics.

I think this works for some cases. But sometimes you just can’t give up fields. The only way to do it is to (a) stack it, or (b) fix the column width so that the majority of the grid ends up out of sight or too small to read when rendered on mobile. That’s why I suggest (a) for the general approach. With the ability to page and filter, it gets you the furthest without giving up legibility or data fields.

My two cents anyway.

On Feb 14, 2014, at 11:22 AM, Rob Larsen notifications@github.com wrote:

I'm curious about how well that concept would work with intensive data grids. You're displaying the information, sure, but I'm not sure how useful that layout is for thousands or millions of rows since, often, the row isn't the interesting piece of data, it might be the columns. This stacked view wouldn't allow you to scan columns.

My initial idea for this would be to add a weighting system to columns and then use MQ + calculated classes to show/hide or render/not render based on device characteristics.


Reply to this email directly or view it on GitHub.

@roblarsen

This comment has been minimized.

Show comment
Hide comment
@roblarsen

roblarsen Feb 14, 2014

Member

While I like it and think it's elegant, I just don't see the stacked approach satisfying some of the use cases I'm looking at. The people I'm trying to please live in Excel. They think in Excel. They do wireframes for applications in Excel. Whether that's the right or wrong approach isn't really the point. I do a lot of work with data visualization, etc. too, so I understand there are better ways to get at some of these data points. Still, we need to solve this issue in a way that speaks to the person who thinks in Excel, since that's often the person making the requirements for a web grid.

So the weighted column approach (or something else that similarly keeps the connection between row and column) will have to be part of our solution.

If someone is looking at a row as a complete record, then the stacked approach is fine, but if you're comparing fields across rows (looking for a security with a specific set of criteria) then it's not.

Member

roblarsen commented Feb 14, 2014

While I like it and think it's elegant, I just don't see the stacked approach satisfying some of the use cases I'm looking at. The people I'm trying to please live in Excel. They think in Excel. They do wireframes for applications in Excel. Whether that's the right or wrong approach isn't really the point. I do a lot of work with data visualization, etc. too, so I understand there are better ways to get at some of these data points. Still, we need to solve this issue in a way that speaks to the person who thinks in Excel, since that's often the person making the requirements for a web grid.

So the weighted column approach (or something else that similarly keeps the connection between row and column) will have to be part of our solution.

If someone is looking at a row as a complete record, then the stacked approach is fine, but if you're comparing fields across rows (looking for a security with a specific set of criteria) then it's not.

@robertjchristian

This comment has been minimized.

Show comment
Hide comment
@robertjchristian

robertjchristian Feb 15, 2014

In an ideal world we’d have both, plus the ability to customize the grid after it’s rendered, adding back and removing additional columns.

On Feb 14, 2014, at 3:41 PM, Rob Larsen notifications@github.com wrote:

While I like it and think it's elegant, I just don't see the stacked approach satisfying some of the use cases I'm looking at. The people I'm trying to please live in Excel. They think in Excel. They do wireframes for applications in Excel. Whether that's the right or wrong approach isn't really the point. I do a lot of work with data visualization, etc. too, so I understand there are better ways to get at some of these data points. Still, we need to solve this issue in a way that speaks to the person who thinks in Excel, since that's often the person making the requirements for a web grid.

So the weighted column approach (or something else that similarly keeps the connection between row and column) will have to be part of our solution.

If someone is looking at a row as a complete record, then the stacked approach is fine, but if you're comparing fields across rows (looking for a security with a specific set of criteria) then it's not.


Reply to this email directly or view it on GitHub.

In an ideal world we’d have both, plus the ability to customize the grid after it’s rendered, adding back and removing additional columns.

On Feb 14, 2014, at 3:41 PM, Rob Larsen notifications@github.com wrote:

While I like it and think it's elegant, I just don't see the stacked approach satisfying some of the use cases I'm looking at. The people I'm trying to please live in Excel. They think in Excel. They do wireframes for applications in Excel. Whether that's the right or wrong approach isn't really the point. I do a lot of work with data visualization, etc. too, so I understand there are better ways to get at some of these data points. Still, we need to solve this issue in a way that speaks to the person who thinks in Excel, since that's often the person making the requirements for a web grid.

So the weighted column approach (or something else that similarly keeps the connection between row and column) will have to be part of our solution.

If someone is looking at a row as a complete record, then the stacked approach is fine, but if you're comparing fields across rows (looking for a security with a specific set of criteria) then it's not.


Reply to this email directly or view it on GitHub.

@awerlang

This comment has been minimized.

Show comment
Hide comment
@awerlang

awerlang Feb 18, 2015

+1 for stacked columns as default.

If someone is looking at a row as a complete record, then the stacked approach is fine, but if you're comparing fields across rows (looking for a security with a specific set of criteria) then it's not.

Wouldn't it be case for a grouping + drill-down? Or color-coding column content?

Anyways, having devices adapted for people (even excel people) is counterproductive, IMHO.

+1 for stacked columns as default.

If someone is looking at a row as a complete record, then the stacked approach is fine, but if you're comparing fields across rows (looking for a security with a specific set of criteria) then it's not.

Wouldn't it be case for a grouping + drill-down? Or color-coding column content?

Anyways, having devices adapted for people (even excel people) is counterproductive, IMHO.

@villelahdenvuo

This comment has been minimized.

Show comment
Hide comment
@villelahdenvuo

villelahdenvuo May 20, 2015

I also vote for stacked columns plugin or built-in.

I also vote for stacked columns plugin or built-in.

@ralberts

This comment has been minimized.

Show comment
Hide comment

+1 :-)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment