Skip to content

Branding and appearance

Branding and appearance

Sparkus can be dressed in your organisation’s own look — logo, colours, typography, and imagery — so that participants experience the programme as yours rather than as a generic tool. Branding is set once for the organisation and, where a particular programme needs to differ, adjusted just for that programme.

What branding covers

A branding theme is a single collection of appearance settings. It includes:

  • Colours — a primary gradient (a start and an optional end colour), a secondary gradient, an accent colour, and a success colour. These drive buttons, headers, highlights, and similar elements throughout the participant experience.
  • Logo — the main logo shown in the interface.
  • Imagery — a hero/banner image, an optional separate hero logo (with placement and maximum height), a secondary banner image, an infographic, a favicon, and a social-share image.
  • Hero text — a banner title and subtitle, their colour, whether the programme name appears in the hero, and its colour and size.
  • Typography — the font family used for the interface.
  • Dark mode — whether a dark variant of the theme is generated.
  • Custom styling — an optional block of custom CSS for fine adjustments beyond the fields above.
  • Email appearance — an email logo, custom email header/footer HTML, and toggles for which email branding layers are applied.

The two levels: organisation and programme

There are two places branding is authored:

  • Organisation (tenant) level — the default look for everything your organisation runs. This is the right place for the things that never change: your logo, your brand colours, your font.
  • Programme level — an optional theme for one specific programme, found on that programme’s Settings → Branding tab. This is where you make a single programme look different — for example, a distinct hero image or a campaign colour.

There is no separate branding editor per cohort. The one exception is the infographic, which a cohort can override on its own; every other appearance setting is decided at the organisation and programme levels.

Which level wins: the cascade

This is the part most worth understanding, because it decides what participants actually see.

The cascade runs programme → organisation → Sparkus house default, and it is applied field by field, not all-or-nothing:

  1. If the programme’s theme sets a value for a field, that value is used.
  2. If the programme leaves that field empty, the organisation’s value is used.
  3. If the organisation hasn’t set it either, Sparkus’s own default look is used.

The important consequence: overriding one thing at programme level does not throw away everything else. A programme that sets only a hero image still shows the organisation’s logo, colours, and font — the fields it didn’t fill in simply inherit. You never need to re-enter your whole brand just to change one colour.

A few refinements on top of that rule:

  • Custom CSS does not merge line by line. If the programme has a custom CSS block, it replaces the organisation’s block entirely; if the programme’s is empty, the organisation’s is used.
  • Individual CSS variables (named style tokens) do merge: the organisation’s set is taken as the base, and the programme’s entries override any with the same name while the rest stay.
  • Dark mode and show programme name in hero follow the programme’s theme whenever a programme theme exists at all, rather than being inherited field by field.
  • Email branding toggles are three-state: each can be on, off, or inherit. Left on inherit, they follow the organisation’s setting; if the organisation hasn’t set them either, they are treated as on.

The inherit switch on a programme

The programme’s Branding tab has an Inherit Tenant Branding toggle, and it behaves differently from leaving a field blank.

  • Toggle on, then save — the programme’s own theme is dropped completely (along with its saved version snapshots), and the programme falls back to the organisation’s branding. The badge on the tab reads “Inheriting tenant branding”.
  • Toggle off — the programme keeps its own theme, and the fields you fill in override the organisation’s; the fields you leave empty still inherit, per the cascade above.

So the toggle is a clean reset to the organisation’s look, not a per-field control. Saving with it on discards programme-specific work, so treat it as a deliberate action rather than a way to preview inheritance.

To help you see which is which, each field on the programme’s Branding tab carries a small badge reading either Inherited from tenant or Overridden here, based on the saved theme.

What participants see

Participants never choose or configure a theme — they simply see the effective result of the cascade for the programme they’re in.

  • Screens, buttons, and headers pick up the resolved colours and font.
  • The logo appears in the interface shell; where an organisation has no logo of its own set, a logo from one of its programmes may be used as a stand-in in the shell.
  • Emails follow the same cascade, subject to the email layer toggles described above.
  • If nothing is branded at any level, the house Sparkus look is used, so the product is never unstyled.

Previewing and checking a theme

Both the organisation and programme branding editors include a live preview that renders the theme as you edit — including a dark-mode toggle and desktop/tablet/mobile views — before you save.

The editor also runs a contrast check against the WCAG AA guidelines (roughly, 4.5:1 for normal text and 3:1 for large text and interface elements) and warns you when a colour pair would be hard to read. These are advisory warnings, not blocks: colours that can’t be measured (such as gradients or blank fields) are skipped rather than flagged.

Custom CSS is filtered before it reaches a participant’s browser: ordinary styling, media queries, keyframes, and style tokens are kept as written, while constructs that could be used to inject scripts or pull in external stylesheets are stripped out. If a rule you wrote seems to have no effect, that filter is a likely reason.

Version history

Branding keeps a version history at both the organisation and programme levels. Each snapshot records a previous state of that theme, and you can restore one to roll back a change you don’t want to keep.

Restoring a programme snapshot reverts the programme’s theme only — it doesn’t touch the organisation’s branding, and it doesn’t change what the programme inherits.

Practical tips

  • Put the durable brand at the organisation level. Logo, brand colours, and font belong there. Set them once and every programme inherits them.
  • Use the programme level sparingly. Override only the fields that genuinely differ for that programme — a campaign hero image, a distinct accent — and leave the rest blank so they track your organisation’s brand as it evolves.
  • Remember that blank means “inherit”, not “clear”. There’s no way to make a field empty at programme level while the organisation has a value; clearing it just hands control back to the organisation.
  • Changing the organisation’s branding flows through immediately to every programme that hasn’t overridden that specific field — which is normally what you want, and occasionally a surprise. If a programme must be pinned to a look, set that programme’s fields explicitly.
  • Check contrast before you ship a theme. A brand colour that reads well on a printed page isn’t always readable behind small text on screen.