Automatic font size and column count adjustment?

[davidparsson]

We have our view filters configured so that the number of jobs displayed varies a lot. When all builds are stable we show all of our roughly 30 builds, but if for example one build fails we only show that build. Since we display our build status on wall mounted TVs, when something fails we want the information on the broken builds to be as easily seen, with fewer columns and bigger text.

Have you considered allowing the font size and column count to be automatically calculated from the number of jobs displayed?

[jan-molak]

Hi @davidparsson, yes, I've been thinking about how to approach this for quite some time now, but am not sure what the best solution is yet.

My initial thoughts on this matter:

• the height of the font should ideally be a percentage of the total height of the container(the JobView panel)
• as the length of the job name could exceed the width of its container, the name should probably be trimmed and an ellipsis displayed instead of the trimmed part

I'm not sure how easy/difficult it is to achieve with CSS itself; it seems like some javascript might be necessary to make this work.

edit: fittext might be an option here

What do you think?

[davidparsson]

@jan-molak, I've looked into something like fittext for this before, and while it did a good job making all job names visible, it also made a quite messy impression since it gave every job a different font size. It may still be the best option around, but I don't think it's perfect.

Another option might be to somehow calculate the font size based on the number of jobs visible, and allow users to relatively increase or decrease the calculated font size using configuration.

If the text can be readable when wrapped to two lines, I'd prefer that instead of trimming it and displaying an ellipsis.

When it comes to column count, I like the idea of allowing users to configure a desired ratio between the number of rows and columns, or possibly a desired aspect ratio for the jobs.

[jan-molak]

After a fair bit of experimentation with ng-FitText I agree with your view, @davidparsson, that while it makes the job names visible it also makes quite a messy impression as the job names, build numbers etc. can all appear in different sizes.

I've incorporated your suggestion and now:

• the base font size is calculated automatically based on the number of dashboard rows
• the user can still tweak the font size and make it up to 3x smaller or 2x larger than what's calculated automatically
• if the text doesn't fit the allocated space, it is wrapped to multiple lines
• if the number of displayed projects doesn't fit the screen, the dashboard becomes scrollable

Please have a look at the latest build and let me know what your thoughts!

All the best,
Jan

[davidparsson]

Thanks @jan-molak! I've taken a look, and it's definitely on the right track, but I have some comments.

First and foremost, I'm not a big fan of the scrollable page feature in its current form. It may hide entire builds without the user knowing it, partially because I see no scrollbar. Also, since we're using this plugin to display status on wall-mounted TV screens, manual scrolling is not a feasible option for us. Automatic scrolling could be a solution, but that too seems like a compromise. I actually think that it would be better to hide certain build information (such as build number and completion time, like what happened before), than to hide entire builds from the view. What are your thoughts on this?

Secondly, the build details texts (culprits, failure reason, ...) quickly becomes too small to be readable, becoming 6px (with the default text scale) when there are four rows of jobs. After adding a few more rows this also applies to the build number and completion time at the bottom of each job. It would of course be preferable to always be able to read everything, but when that's not possible it makes more sense to completely remove the small text. I however realize the technical reasons behind the current design.

Finally I'm wondering, was the automatic column count feature rejected on purpose? Should I create another issue for it? I still think it's a nice feature.

Please know that I really appreciate the work you're putting into this. Thanks again!

[jan-molak]

Hey @davidparsson and thanks for your feedback!

You're right about the scrollbar, I've just corrected that so it should be visible if it's needed. Please have a look at the latest build and let me know your thoughts.
I appreciate that a visible scrollbar doesn't entirely solve the problem you described, but should at least address the part where the user is not aware of the jobs that got "below the fold".

I like the idea of hiding the "build meta data" if it becomes too small too read. Would you mind raising a ticket or a PR for that?

I also like the idea for the Build Monitor to propose an initial number of columns - again a separate ticket or a pull request would be appreciated :-)

Thanks for helping me make Build Monitor better for everyone!

Best,
Jan

[davidparsson]

Done! I'm glad to be able to contribute.

[coosminus]

We installed the latest version of the plugin and found out that now the scroll bar is displayed for our set-up, which of course pushed down the jobs that did not fit in the screen. Before was better cause we were able to manually adjust the font size to match the screen size. We do have several jobs in our views, like 15-30 jobs.
BTW: how do you define "comfortably fits the screen"?

[jan-molak]

Hey @coosminus, automatic adjustment of the font size is quite a tricky subject because you have to cater for scenarios where people have relatively few jobs dislpayed (10-20) as well as when they have loads (300-400 for instance).

Here's how the font size is calculated.

So, the base size of the font (the 1em in CSS terms) is defined as 1/10th of the height of a widget or 10px, whichever is smallest (1/10 is a totally arbitrary number and may need tweaking).

Then the size of the title, build number and time, culprits etc is calculated as multiples of that base font.

To answer your question, a definition of "comfortably fits on the screen" would be "as many widgets as possible, as long as the base font size is 10px or more".

BTW: the base font size can still be adjusted using the "text scale" slider in the settings, so you can make it smaller than 10px. This way you should be able to fit more widgets without the scrollbar appearing.

BTW2: This solution is by no means set in stone and I'm definitely looking forward to comments, suggestions and pull requests! :-)

[dimkin-eu]

now, because of culprits, scrollbar appears.
before 1.8+build.201601112328 version there also were culprits, but, probably in smaller font

[coosminus]

Hi @jan-molak , I got the idea, thanks for detailed explanations.
The thing is now there is no way of disabling automatic adjustment of the font size. Cause if I reduce the size of the font so the scroll bar dissapears, then it will be too small to be able to read it from the distance (e.g. our project room, our case 3-4 meters).
Before I could re-size the text as much as I wanted without the scroll bar to appear, even though the end text of job name would not fit in the box (job names do not change that much over times, so in our case it was enough even we cut out some end letters).

But I understand the challenge using automatic adjustment anyway.

[davidparsson]

Is it perhaps useful to reduce the margins/paddings/space around the text blocks for each job to make more room for larger font sizes, when the font size is small?

[yveshanoulle]

I don't have many builds on my current project so I have no idea what happens, but I can give input based on something I have seen before.

I have the feeling that all builds now have the same size.

You can play with that.

F ew: green builds can be smaller, only builds that are broken of where the status changed from you can make the current size. that way you have a lot more room to show a lot of projects and keep the most important information readable.

[jan-molak]

@coosminus - I see, the trouble is that when people have jobs nested in folders, the displayed name becomes pretty long and with the old UI you might end up in a situtation where you see the name of the folder, but not the name of the job. The same thing goes for jobs that have long names.
The new implementation displays the full name correctly, however the relative font sizes might (and probably will) need tweaking to cater for the scenario you described.

@davidparsson - that's an interesting idea; so are you suggesting that when the font size increases, the margins/paddings shrink? That might work.

@yveshanoulle - thanks for the feedback! So the green builds would have a different base font size than red? Yes, that could work as well as long as greens and reds are separated and not displayed on the same row; We might need two "sinks" so to speak: a top one for the red ones and the bottom one for the greens maybe?

[davidparsson]

Yeah, it's worth a shot at least.

Regarding the different font sizes for different statuses, I actually think it makes even more sense to hide any stable and competed builds, if there are any unstable or failed builds, to bring full attention to the problems.

I have set this up using the View job filters plugin, but the configuration is quite complicated so including that functionality in this plugin would still add some value.