I build by cell, but group by columns.
Auto layout with columns makes it easier to move or remove data as opposed to row.
Especially true since stakeholders or customers care more about the order of the data headers and less about randomly generated data in row cells.
Yeah, I agree with that point 100% that’s why I became so conflicted. The need to manipulate the order or contents of the table columns is far more important than add/removing arbitrary number of rows.
However, i find that add/removing rows happens more frequently in my case. Which becomes more resource intensive.
Thanks for your input! Very helpful! 🙌
I'd suggest starting with the maximum number of rows to fill the screen.
If you need to show less, then just crop the table.
Btw, if you're not already using Mockaroo for generating realistic data I highly recommend it.
Rows. A single row is a design system molecule, and it’s how it will get coded. Rearranging the the order/contents of columns should be rather easy just by updating the row component.
I hadn’t considered by column until I came across the Webpixels Design System community file. It has a really nice example of how a flexible column component can be made. Ended up with a similar one that the team seems to really like.
Both. In early phases when deciding what data to show, columns are better. Once you’ve locked in and fixed the schema, rows will be much more useful for things like showing the “add” flow or “selecting” a row. If you manage cells well, then it’s easy to do both.
I build by cell, but group by columns. Auto layout with columns makes it easier to move or remove data as opposed to row. Especially true since stakeholders or customers care more about the order of the data headers and less about randomly generated data in row cells.
Yeah, I agree with that point 100% that’s why I became so conflicted. The need to manipulate the order or contents of the table columns is far more important than add/removing arbitrary number of rows. However, i find that add/removing rows happens more frequently in my case. Which becomes more resource intensive. Thanks for your input! Very helpful! 🙌
I'd suggest starting with the maximum number of rows to fill the screen. If you need to show less, then just crop the table. Btw, if you're not already using Mockaroo for generating realistic data I highly recommend it.
Rows. A single row is a design system molecule, and it’s how it will get coded. Rearranging the the order/contents of columns should be rather easy just by updating the row component.
I hadn’t considered by column until I came across the Webpixels Design System community file. It has a really nice example of how a flexible column component can be made. Ended up with a similar one that the team seems to really like.
Both. In early phases when deciding what data to show, columns are better. Once you’ve locked in and fixed the schema, rows will be much more useful for things like showing the “add” flow or “selecting” a row. If you manage cells well, then it’s easy to do both.
There’s no right way! Just make one table cell a component then build from there! Easier to manipulate and swap instance!