Summer 2024 Research Poster - Mohammad Bilal

[BilalM04]

Any feedback is appreciated 🙂

MohammadBilal_Poster.pdf

[samm82]

Just some minor notes. Great work!

• I think the description of Drasil could be improved:
  "Drasil: a software framework written in Haskell that generates all software artifacts (…) based on a single specification in a domain-specific language (DSL)."
• I don't know if we can claim "complete traceability", but we can definitely claim "improved traceability"
• It should be "MathJax", not "Mathjax"

[BilalM04]

@samm82 thank you for the feedback!

In the Drasil Position Paper it does claim "complete traceability." I do agree that "improved traceability" is a more accurate claim. @smiths what do you think?

[smiths]

@samm82 thank you for the feedback!

In the Drasil Position Paper it does claim "complete traceability." I do agree that "improved traceability" is a more accurate claim. @smiths what do you think?

"improved traceability" is more accurate for what Drasil currently does. "complete traceability" is our future target. 😄

[smiths]

The poster looks great @BilalM04! I have a few items of feedback:

• there is more text than we usually want on a poster. However, you have used bold to highlight the most important points. We could reduce the text, but unless you have more content to fill in the freed-up space, I don't think it is worth the effort
• consider flipping the objective and the introduction, and relabelling the introduction as "Motivation for Drasil". The objective could be rephrased to lead into the next section: "Generate Software Requirements Specification (SRS) in mdBook format from codified knowledge within Drasil. The reason for this recommendation is that the Introduction should introduce your poster, but your introduction, is background information on Drasil. It is good information, but it seems like the poster is going to about Drasil, not generating mdbooks.
• the figure in the centre panel is great, but unfortunately small and hard to read. Did you generate the code images as bitmaps, or as vector images? If they are jpegs, see if you can instead save them as pdfs. They will be crisper. Removing the red, yellow and green dots will free up space to make the fonts larger.
• quantifying the benefits of Drasil is great. Are the 1422 lines of user-written code the Drasil source code on the knowledge, or the internal representation of a document, or the DSLs for transforming Drasil's internal representation into specific formats? Is the 7242 the generated lines for all the case studies? We could improve this number just by adding more case studies. This comparison is great, but I'd like to know exactly what we are comparing. 😄

[BilalM04]

@smiths thank you for the detailed feedback!

---

there is more text than we usually want on a poster ... consider flipping the objective and the introduction ...

I have made the text slightly more concise and rearranged the order.

---

the figure in the centre panel is great, but unfortunately small and hard to read. Did you generate the code images as bitmaps, or as vector images?

The images are in PNG format. The smallest code images (DSL images) are approx. 6cm by 10cm, while the rendered table images, which are likely the focus, are approx. 10cm by 10cm. Viewing the PDF directly on GitHub may cause readability issues due to GitHub’s quality reduction in PDF previews. However, once downloaded and viewed at their true size, all images are readable.

I have also removed the dots.

---

quantifying the benefits of Drasil is great. Are the 1422 lines of user-written code the Drasil source code on the knowledge, or the internal representation of a document, or the DSLs for transforming Drasil's internal representation into specific formats? Is the 7242 the generated lines for all the case studies?

• The 1422 lines of user-written code represent the Drasil source code on the knowledge (i.e. code in drasil-example).
• The 7242 lines of generated code pertain to the Projectile case study, as indicated in the graph title, and consist solely of generated documentation (i.e. build/projectile/SRS/). I included only the generated SRS because the poster specifically focuses on generating software documentation.

As you mentioned, we can include all the case studies to improve the numbers. Additionally, in the last bar, we can include all generated artifacts, not just the SRS. Which approach should we take?

[smiths]

@BilalM04 png is a raster format, so not as crisp as pdf (vector image). I agree with you though that at the size you will print, it shouldn't be a problem to use a high resolution png file. Just for fun, I did create a pdf for comparison sake. Although the pdf is a little crisper on the letters, it isn't that dramatic a difference. Not worth making a change.

LayoutPdf.pdf

For the comparison of lines of code, I think you should make sure it is clear on the poster that 1422 is the lines of user code (the top box in your big diagram). For comparison, I like your idea of just using the projectile example. If we count the other case studies, then we have to count their lines of user code as well. Maybe you could have the number of 7242 for the documentation (SRS), and add another number for the total generated for all artifacts? The 7242 is the more important number though, because that's the one in the scope of your poster.