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.
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.
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.
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.
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.