Improve the visuals

[filip-jezek]

Hi @xogeny, I am rather opening a new issue instead of having a discussion in #34 .

You wrote:

But if there are issues about layout and responsiveness, ping me and I'll examine things and I'll contribute whatever comments I can to help

I have used the Tactile theme https://pages-themes.github.io/tactile/ and made necessary css modifications to have similar look as the modelica pages. But there are not really responsive and the scaling is also not satisfactory. As a side note, the visuals of the Modelica.org feels a bit like 90'.

The plus side is, that we can change the template without affecting the functionality of the pages by just modifying the default page template https://github.com/modelica/newsletter/blob/master/_layouts/default.html and css https://github.com/modelica/newsletter/blob/master/_sass/jekyll-theme-tactile.scss

Do you have some ideas about what changes do we need to make and how should it look like at its best? I am not really a graphic designer guy, but I could find one if needed.

Thanks!
F/

[xogeny]

Could you and @sjoelund perhaps enumerate what you think is wrong with the current design. My guess is that using flexbox layout will address most concerns. But I want a clear statement of what the problem is before I suggest anything.

P.S. - I certainly would not argue that the CSS on modelica.org is a model for what we want to do. It is quite old and out of fashion. I'm mainly concerned with using a modern, responsive approach that works well across devices.

[sjoelund]

I'm mainly concerned with using a modern, responsive approach that works well across devices.

That's my main concern as well. The lack of guidelines regarding width of columns, etc made me believe we finally had a good responsive design where we could avoid doing web design in pixels. But apparently that is not the case. And I didn't do web design for many years so I am not familiar with all fancy new CSS and JavaScript frameworks.

The main issue is naturally making the content flow naturally regardless of screen width. The issue with figure widths should be easy to fix with CSS to limit the max width of media content.

I should note that I usually use my laptop screen in 1920x1080 resolution due to problems with a few websites, but most of them work just fine in 4K. The main problem is any website that does sizes in pixels (especially text) since it's a 15" 4K screen and thus quite high DPI (making anything sized in pixels super-tiny). (Chrome taking forever to zoom a webpage on a 4K-screen does not help usability of these pages either)

[xogeny]

@sjoelund you say "the main problem is any website that does sizes in pixels". I'm not sure why you say this. I assume you are talking about the CSS unit px. But px is not pixels (as explained many places including here and here).

But in any case, this article suggests using em or rem units.

Note that the submission guidelines used to have a requirement that images not be wider than 400 pixels (not CSS pixels, actual raster pixels). I would suggest that we modify the CSS for the page to identify user submitted img tags and set their max-width property to be something with em or rem units. An initial guess would be 40rem.

My guess is that will address any issues with responsiveness.

@filip-jezek it would be nice if you could setup a preview site of the current repo so people could see a draft version. BTW, I used netlify for publishing the preview version of the FMI Standard site and it worked wonderfully (give me SSL with no effort on my end). You might want to consider that. The scripts that build and deploy the site can be found here.

[sjoelund]

I do believe those pages explain why things are rendered in quite different sizes on different devices.

Also, I checked the page on my phone now and only ~60% of the screen width is utilized in standing mode. Using the simplified view or zooming in helps the readability a lot. That's not a problem with the unit used to specify the width but figuring out how wide a column should be given the screen that we render on though.