UI update

[ljowen]

What this PR does

Major change to default theme and appearance:
May introduce breaking changes with existing maps so will be a major version.

Visual changes

• Generally increase padding
• Workbench now "floating" with variable height and semi transparent background
• Change to darker colours in default theme to increase contrast
• Font changed from "Nunito" to "Inter", generally increase font sizes
• More rounded corners, generally decrease border radius to 8px for major panels and 4px for smaller components

Before

After

Functional changes

• Bug fixed where tour would not work correctly if workbench was minimised
• Add config option to keep catalog open when adding / removing datasets keepCatalogOpen
• Remove dataset count shown on map
• Hide chart at mobile viewports

Test me

Before: http://ci.terria.io/main
After: http://ci.terria.io/ui-update-fonts

Checklist

• There are unit tests to verify my changes are correct or unit tests aren't applicable (if so, write quick reason why unit tests don't exist)
• I've updated relevant documentation in doc/.
• I've updated CHANGES.md with what I changed.
• I've provided instructions in the PR description on how to test this PR.

[CLAassistant]

All committers have signed the CLA.

[ljowen]

Thanks for the review @zoran995 I've addressed most of these now except for 6), I'm in conversation with our designer about reverting to the small "Show workbench button" which would be my preference

[irbian]

Our client love the new changes! there is any ETA of them?

[na9da]

Hi @irbian, thanks for the feedback. I also see that you have mentioned this before in #5169.

To address your points:

The reliance on vh and vw means that we can't add elements freely above or below the frame

I think this happens when we don't have those specific use cases in mind while making changes. It will be great if you can point out where specifically this has created problems and we will be happy to fix them.

The use of generated classes instead of semantic ones makes difficult to attach external styles to them

As noted in #5169, this is a problem that comes with the switch to styled-components. One solution might be to expose more styling options as theme variables or customizable components.

One problem I see with using external stylesheets for customizations is that it works like an implicit API that is more prone to accidental breakages when we change things in the UI.

[na9da]

Approving.

@ljowen - great job, looking good now 🎉

[irbian]

Hi @irbian, thanks for the feedback. I also see that you have mentioned this before in #5169.

To address your points:

The reliance on vh and vw means that we can't add elements freely above or below the frame

I think this happens when we don't have those specific use cases in mind while making changes. It will be great if you can point out where specifically this has created problems and we will be happy to fix them.

Our main case was to add a common organization level header to all apps in our domain, with links to other organizations apps. We did implement that one as a plugin that added a div just above the current header, but is something that would happen to any component added outside the frame

The use of generated classes instead of semantic ones makes difficult to attach external styles to them

As noted in #5169, this is a problem that comes with the switch to styled-components. One solution might be to expose more styling options as theme variables or customizable components.

One problem I see with using external stylesheets for customizations is that it works like an implicit API that is more prone to accidental breakages when we change things in the UI.

I can't speak about others, but for us it wouldn't be as much a problem as much as at least it would be possible to target the element to customization