Hi, I've found that everything in Rise is wonderfully responsive, with the exception of table blocks. Content looks fine in desktop view, but when I preview in other views (the worst being portrait smartphone), the text in the table's cells is randomly chopped every which way. It looks like a word salad. Is there any way to mitigate this? Thanks.
Yes, I did manually alter some of the column widths after I created the table. Does that affect the responsive formatting?
I'd send you the share link, but I've already deleted the table and designed a workaround. I created a one slide Storyline block and inserted it into the Rise course. It doesn't look as nice as the table that's native to Rise, but it ensures that the copy isn't oddly chopped up when scaling it to fit other screen formats.
I'd like to know for future reference what you think is the issue, since the native table feature is a big plus. Thanks.
Hi Kevin! Another community member ran into a similar problem earlier this week, and the culprit was manually adjusting the column widths. Click here to read that discussion.
If you happen to run into this again in the future, send us the Share link so we can take a closer look!
Thanks for the link to the other discussion. So, it looks like manually-adjusting table borders (either column borders or row borders) somehow upsets the "breakpoints" that Rise has pre-programmed to automatically adjust the table responsively when a user switches between different formats: desktop/landscape, phone/portrait, etc. Since Rise doesn't know where to insert the line breaks as the format changes, it inserts breaks at odd places within words. It's unfortunate that this is the case, because manually-adjusting column and row borders in Excel tables is so common. I'll have to remember not to apply that method to Rise tables.
That sounds like what's happening here, Kevin. I'll have our team take a closer look at this behavior, and I'll let you know if I get more information that will help.
8 Replies
Hi Kevin,
Do you have any screenshots of what you are seeing?
Hi Karl,
Here's a screenshot
Hi Kevin,
Here is thread with someone having the same issue:
https://community.articulate.com/discussions/rise-360/new-in-rise-360-table-block?page=2
Hi Kevin!
Did you ever manually adjust the width of the table cells when you created that table?
I'd love to take a closer look from my side if you don't mind sending over the Share link!
Hi Alyssa,
Yes, I did manually alter some of the column widths after I created the table. Does that affect the responsive formatting?
I'd send you the share link, but I've already deleted the table and designed a workaround. I created a one slide Storyline block and inserted it into the Rise course. It doesn't look as nice as the table that's native to Rise, but it ensures that the copy isn't oddly chopped up when scaling it to fit other screen formats.
I'd like to know for future reference what you think is the issue, since the native table feature is a big plus. Thanks.
Hi Kevin! Another community member ran into a similar problem earlier this week, and the culprit was manually adjusting the column widths. Click here to read that discussion.
If you happen to run into this again in the future, send us the Share link so we can take a closer look!
Hi Alyssa,
Thanks for the link to the other discussion. So, it looks like manually-adjusting table borders (either column borders or row borders) somehow upsets the "breakpoints" that Rise has pre-programmed to automatically adjust the table responsively when a user switches between different formats: desktop/landscape, phone/portrait, etc. Since Rise doesn't know where to insert the line breaks as the format changes, it inserts breaks at odd places within words. It's unfortunate that this is the case, because manually-adjusting column and row borders in Excel tables is so common. I'll have to remember not to apply that method to Rise tables.
That sounds like what's happening here, Kevin. I'll have our team take a closer look at this behavior, and I'll let you know if I get more information that will help.
This discussion is closed. You can start a new discussion or contact Articulate Support.