You're right about the pixels. I used them because the examples set in pixels are the easiest to understand. I added a note that outside of these examples, the units used should be EM or REM. Thanks for the feedback!

Doing hateful css typography work today. It's hard enough to make ordinary stuff march in formation - I'm hitting both ceiling and deadline, which somewhat spilled over into the harshness of my comment.

That's ok. I actually wanted to include such note about the units in the first place but forgot (in the book I use REMs and pixels only as fallback but changed to pixels in the article for simplicity). Your comment reminded me to add this note in. And I know how frustrating it can be when working on typographic details on the web. Are you having any specific problems?

Nothing too specific, no, but thanks. Your tone and approach much appreciated.

That's really cool, but when I want to print it, it doesn't keep the business model canvas layout :/

Thanks for the feedback! I'll add it to the backlog

That's a great resource, thanks for mentioning it. I might add it to the page :)

Thanks. Go ahead, you can share it with anyone you want :)

No problem, I'm glad you found value in it.

Thanks, I'm glad you think it's well designed :)

Hey, Matej here, I'm part of the UX team at GitLab. I understand that it can look like we don't spend much time polishing the user interfaces and experiences that much but I can assure that we do. We don't have a split in % on how much time we should spend polishing existing things but maybe it's something we should consider doing.

Just to give an example of a recent redesign of an existing feature that I was involved in, it can be found here: https://gitlab.com/gitlab-org/gitlab-ee/issues/6089

Our application covers the whole DevOps lifecycle which means it takes a lot of effort to upkeep existing and constantly ship new features, but we always strive to do our best.

Thanks for the feedback, I think it will trigger internal discussions on how much time we should spend polishing existing features and experiences.

Re "polishing", part of that might be treating complaints about experience getting worse differently than requests for improvements. E.g. from a different subthread here: https://gitlab.com/gitlab-org/gitlab-ce/issues/39056 The report clearly is "this has been broken", but nothing in the issue suggests it being noticed as a regression and not just another potential for improvement, whereas the customer will remember "this worked, and they broke it".

This is really useful feedback @Karunamon! I see Sarrah already addressed it so I just wanted to add my bit: I also think that the approach we used for designing settings pages isn't optimal and suggested improvements in a discussion on a related issue:

https://gitlab.com/gitlab-org/gitlab-ce/issues/45219

After seeing your feedback (and confirming my assumption) I decided to open a new issue to specifically address this and would love to get your feedback on the proposed solution:

https://gitlab.com/gitlab-org/gitlab-ce/issues/47405

Thanks again for taking the time to write such detailed feedback down. It's really helpful to us. Cheers!

I agree that the Settings page is a pain to use or find anything. I prefer everything to be displayed in one page so I can do a quick Cnt+F and search for the string I am looking for instead of tediously mousing over every button to expand. See Jenkins->Manage Jenkins->Configure System

Oddly enough, I stumbled on the fact that Ctrl-F works fine on these pages. All of the items below the expands are still visible to the search, and the expand automatically pops open when your cursor jumps to the matching text.