We have an interesting thing that founded during QA testing on
MDLQA-17152. And we've made a new issue based on the finding on MDL-76346.
Here is the investigation result from
I did my investigation.
Feedback responses can download in many formats. One of the formats is PDF. The layout of the feedback responses is a table, the column is the questions, and the row is the participant's answers.
If I have 50 questions and 250 participants, then the PDF will generate 54 columns consisting of the following:
- Four columns describe the participant's information, like username and when the participants take the Feedback.
- Fifty columns are the answer.
And the PDF will also generate 250 rows based on the participant's amount.
With my local machine, generating a PDF with those amount of data takes 20-25 minutes, and the result looks like this:
Yep. I can't read at all because PDF has limitations regarding document width, unlike other formats, XLS, CSV, JSON, and HTML.
The real issue involves 250 rows and 154 columns (150 questions + 4 additional user information), and I assume it will take about 3 - 4 hours to generate a PDF document. For something that you can not read clearly, you have to take a lot of time and a lot of hardware resources, and It's not worth it.
I think this is not a bug. It's more like how we should design properly because of limitations owned by PDF documents.
I've been discussing with Hedgehog and we propose to remove the PDF option from the Download dropdown because PDF is not designed for a multi-column document.
We think we can improve it to get a better result, some of the ideas are:
- Give users a warning when predicting how many columns will be generated. "Your PDF will have more columns than the recommended amount of $x. Are you sure you want to proceed?"
- Create a new layout to get the proper information from the PDF generated by the system, not a multi-column layout.
- Remove the PDF option from the Download dropdown because PDF is not designed for a multi-column document.