Production Mode & Site Health - improvement proposition

Site Health, that’s a great deal - thanks for that.
Production modes, a great deal, but…

For the staging mode a color was chosen (I don’t know if exactly) close to the warning class.
It’s a sensible solution.

However, there seems to have been no consistency in implementing the styling of this functionality, which makes navigating the dashboard confusing or disorienting, to say the least. Unnecessarily.

3 screens about the same 3 different colors - it’s a bit incomprehensible.

Below is a quick simulation of what it might look like after unification.
It’s just a cheeky suggestion. Though I think it’s worth considering.

Of course, I would love to see similar consistent markings for developer mode - this time maybe actually red - the danger class seems perfect.

What do you think?

I agree with your thinking here about keeping the colours consistent.
Only issue might be getting consensus about what the colours should be!

On my non-Concrete projects where I have local dev, staging and production, I add a few lines of code in to output a 10px dashed lined at the top of the body, in different colours.

  • for local, I use red.
  • for staging I use orange/yellow
  • for live the line isn’t there

It really helps when you’re testing things out, maybe different copies are in different windows, and you have the potential to edit live records…

But whether my colour choices make sense I’m not sure!

I think I picked red over green or blue, just so it would stand out more against most interfaces.

1 Like

Ryan,
I’m not a programmer, but I look at it from two positions.
• As a user - I get what I get and I don’t argue, but I’m confused
• As a UX/UI designer - I know what is wrong and I try to improve it for the sake of all of us

I don’t have any research on Contextual Colors at hand (probably I could find some), but I know what emotions certain colors evoke in us, so you’re doing it right.

Even if you think you used them unknowingly, you’re doing it according to nature, that’s how Design Systems are created, based on our natural perceptual predispositions (at least in theory).

I will not lecture here, but it seems to me that in this case, the issue of color code should not be subject to democratic discussion. We don’t need to reinvent the wheel.
The only thing we need is to convince decision-makers that we need it, at least in this form.

Thanks for your support and vote on this.

Best bet is to raise it as a consideration on github, perhaps with your mockups attached.

It’s just going to be a case of stating ‘colors are inconsistant when highlighting production modes’, with suggestions on what should be changed.

Better still, if you’re keen to do a pull-request, that might simply be agreed on right there and then, since it’s easy to review and merge.

I do not know too much about GitHub and I do not know what a pull-request is, could you explain it quickly? And how to do it?

I reported it as an enhancement suggestion

I’m not sure I can explain it quickly, but in summary:

  • Concrete’s development codebase is stored at Github, on a platform called git
  • Git allows multiple developers to ‘push’ code to it, handling merging the code, tracking different ‘branches’, showing history, etc. It’s really the only way you can have many people working on a codebase, whilst still being able to merge everyone’s work together
  • Some people can push their code changes directly to a project on github, members of the core team can do this
  • But everyone else, they need to create some code to merge in and then create a ‘Pull Request’, asking the owners of the code repository that you’d like your changes merged into the main development branch
  • To do that, developers ‘fork’ their code into their own copy, where they can make whatever changes they want.
  • Then finally through Github they make a pull request back to the original repository, and that then shows up here: Pull requests · concretecms/concretecms · GitHub

The whole process requires you to have a basic understand of git, and using it in development, so it’s unfortunately not something particular quick to work out.

It’s something you’d look to learn if you were thinking you’d want to regularly contribute to the codebase (or you want to contribute to upload other products on github).

In short, if you’re a PHP developer, learning git and github is very valuable. If you’d say you’re more of a designer/builders, and only dabble in PHP (rather than build new things with it), I’d say it’s not something to worry about - and instead bug reports and issue discussion is the way to go.

2 Likes

That’s a complete answer for me, thanks
Yes, I will definitely stick with the last suggestion.