A generic corporate UI framework for eLTER RI Cyber Infrastructure services
Version 1.0 — September 2026
These guidelines translate the eLTER visual identity into a practical design system for scientific web applications. The objective is consistency, not uniformity: DAR, DEIMS, eLTER Vocabs, DataLabs and future services can retain application-specific workflows while sharing the same eLTER identity, navigation language and interaction principles.
The official eLTER Visual Identity & Guidelines remain authoritative for logos, corporate colours and typography. This document adds the web-application layer: layout, navigation, components, interaction states, responsive behaviour, accessibility and developer-oriented design tokens.
| Layer | Defines | Examples |
|---|---|---|
| Brand identity | Logo, corporate palette, typography, visual language | Official eLTER Visual Identity & Guidelines |
| Web design system | Application shell, UI roles, components, accessibility | This document |
| Application design | Domain-specific workflows and scientific interfaces | DAR, DEIMS, Vocabs, DataLabs |
- MUST / Required — necessary for an official, recognisable and accessible eLTER RI application.
- SHOULD / Recommended — strongly preferred for cross-service consistency, but adaptable for justified application needs.
- MAY / Application-specific — intentionally flexible for domain workflows, maps, scientific visualisation and specialist data entry.
The eLTER identity should be obvious through a small number of stable signals: official logo treatment, a dark-blue structural shell, consistent typography and restrained use of the eLTER palette. Scientific content should remain visually dominant.
- Prefer clarity and information density over campaign-style decoration.
- Use neutral content surfaces for maps, tables, forms, metadata and dashboards.
- Reserve saturated corporate colours for identity, interaction and selected emphasis.
- Do not force scientific data into the corporate palette when domain-appropriate colour scales communicate the data better.
Design rule: Corporate colours identify the application. Scientific colour scales communicate the data.
The outer application chrome should converge across services, while the content region remains adaptable. This is especially important because eLTER services are built by different teams and technologies.
| Token | Hex | UI role | Recommended use |
|---|---|---|---|
| eLTER Blue |  #0879C0 |
Primary interaction | Links, primary actions, active UI |
| eLTER Orange |  #ED9632 |
Brand accent | RI emphasis, selected branded highlights |
| Dark Blue |  #003972 |
Structural | Application header/footer, strong navigation |
| Green |  #40907A |
Secondary accent | Supporting categories, positive/environmental contexts |
| Light Green |  #96CE58 |
Supporting | Charts and non-critical highlights |
| Light Blue |  #BADFFD |
Supporting surface | Selection and information backgrounds |
| Light Background |  #F0F0F5 |
Neutral surface | Page/application background |
| Dark Background |  #0A2033 |
Dark surface | High-contrast footer/sections |
Recommended role mapping: Dark Blue = structure. eLTER Blue = interaction. Orange = brand accent. White/light grey = working canvas.
- Do not use the full corporate palette decoratively on every screen.
- Do not use orange as the default primary button colour; blue is the standard interaction colour.
- Do not infer semantic status from brand colours. Success, warning and error require a separate accessible semantic palette.
- Do not place normal multicolour logos on arbitrary coloured surfaces when an approved reversed/monochrome variant is available.
| Use | Typeface | Fallback | Typical weight |
|---|---|---|---|
| Headings | Montserrat | Arial, sans-serif | 500–600 |
| Body & UI | Helvetica Neue | Helvetica, Arial, sans-serif | 400–500 |
| Dense metadata | Helvetica Neue | Helvetica, Arial, sans-serif | 400 |
Recommended default type scale: H1 32/40 px, H2 24/32 px, H3 20/28 px, H4 16–18 px, body 16 px, * small/meta 13–14 px*. Avoid very light weights in dense application interfaces.
Applications MUST use official eLTER logo assets. Do not redraw the logo, reproduce it as editable text, recolour it ad hoc or place it on a low-contrast background.
Service names should read as members of the eLTER Cyber Infrastructure portfolio rather than independent brands. The eLTER identity is primary. The application name is clearly visible but secondary.
Examples:
eLTER | DAR - Digital Asset RegistereLTER | DEIMSeLTER | VocabularieseLTER | DataLabs
- Keep the logo at the left edge of the common header in left-to-right layouts.
- Maintain sufficient clear space around the mark.
- Use an approved white/reversed logo on dark-blue application headers.
- Avoid separate application logos unless there is a documented branding requirement.
The shared shell is the strongest visual cue connecting eLTER digital services.
┌──────────────────────────────────────────────────────────────┐
│ eLTER | APPLICATION NAME Navigation User/Login │
│ DARK BLUE HEADER │
├──────────────────────────────────────────────────────────────┤
│ │
│ APPLICATION CONTENT │
│ Maps • Tables • Forms • Search • Dashboards │
│ │
├──────────────────────────────────────────────────────────────┤
│ eLTER RI About • Contact • Privacy • Legal • Accessibility │
│ DARK FOOTER │
└──────────────────────────────────────────────────────────────┘
| Zone | Contains | Rule |
|---|---|---|
| Identity | Official eLTER mark + application name | Stable across screens and services |
| Primary navigation | Application-level sections | Short and horizontal on desktop |
| Utility | Search, language, account/login, help | Right aligned; persistent utilities only |
Use #F0F0F5 as the preferred page canvas with white content surfaces.
Spacing, typography and subtle borders should do most of the structural work; avoid excessive card nesting and
decorative shadows.
A common footer SHOULD contain eLTER RI identity and a predictable minimum set of links: About, Contact, Privacy/Data protection, Legal notice, Accessibility, and links to central eLTER services. Funding or project notices can be added where required.
Keep application navigation separate from cross-service navigation. Users should immediately understand whether a link changes context inside the current application or moves to another eLTER Cyber Infrastructure service.
| State | Required treatment |
|---|---|
| Default | High-contrast text; no unnecessary decoration |
| Hover | Visible change in background, underline or text emphasis |
| Active | Persistent indicator showing current location |
| Keyboard focus | Strong focus ring that is not removed by CSS |
| Disabled | Reduced emphasis plus non-interactive semantics; not colour alone |
- Use a single H1 per page for the page/task title.
- Use breadcrumbs for deep hierarchies or record detail pages.
- Keep actions close to the object they affect.
- Avoid mixing tabs, pills, side navigation and accordions without a clear hierarchy.
- Use descriptive labels; avoid unexplained internal acronyms.
| Level | Visual treatment | Typical actions |
|---|---|---|
| Primary | eLTER Blue background / white text | Save, Submit, Search, Create |
| Secondary | White background / blue border + text | Cancel, Advanced filters, View details |
| Tertiary | Text/link style | Low-priority supporting actions |
| Destructive | Dedicated accessible error treatment | Delete, Remove, Revoke |
Rule of one: a view should normally have one visually dominant primary action per task context.
- White background on the light-grey application canvas.
- 4–8 px corner radius.
- Subtle 1 px neutral border; little or no shadow.
- 16–24 px internal padding for standard content cards.
- Use cards to group related information, not as a wrapper for every paragraph.
Links use eLTER Blue and MUST remain recognisable as links. In dense prose, underlining is preferred. Avoid blue non-interactive text that looks clickable.
Use a consistent line-icon family. Icons support labels but rarely replace them for important actions. Avoid mixing emoji, filled icons and multiple icon libraries in one production interface.
- Place persistent labels above fields. Placeholders are examples, not labels.
- Indicate required/optional fields consistently.
- Validate close to the affected field and provide a concise error summary for long forms.
- Use fieldsets or section headings for complex scientific metadata forms.
- Keep units adjacent to values and make controlled-vocabulary selection explicit.
| Element | Recommended treatment |
|---|---|
| Header row | High contrast or neutral strong emphasis; sticky where useful |
| Body rows | White/neutral surface with subtle separators; avoid heavy grids |
| Clickable identifiers | eLTER Blue link treatment |
| Selection | Very pale blue background plus explicit selected state |
| Numbers | Right-align when comparison benefits from decimal alignment |
| Status | Text + icon/label; never colour alone |
Use typography and alignment rather than colour blocks to distinguish labels from values. Persistent identifiers, controlled vocabulary terms, units and provenance links should have consistent patterns across eLTER services.
The corporate palette is suitable for UI and small graphics, but it should not constrain scientific visualisation.
- Keep map controls consistent with the shared application components.
- Use a neutral basemap when overlay data is the primary information.
- Ensure symbols remain readable against multiple basemap contexts.
- Provide legends that explain data semantics independently of the brand.
- Europe-first framing and eLTER-specific filters may be appropriate while retaining access to broader network content.
| Scenario | Guidance |
|---|---|
| 2–6 branded categories | Corporate palette may be appropriate |
| Many categories | Use a tested categorical palette beyond corporate colours |
| Continuous values | Use perceptually ordered sequential/diverging scales |
| Uncertainty | Use interval, opacity, hatch or explicit bounds; not colour alone |
| Print/export | Check greyscale and colour-blind robustness where relevant |
Success, information, warning and error are semantic states and require their own accessibility-tested palette. Brand orange is not automatically a warning colour and brand green is not automatically a success colour.
Official eLTER RI applications SHOULD target WCAG 2.2 AA.
- Keyboard access for all interactive functionality.
- Visible focus states and logical focus order.
- Sufficient colour contrast for text, icons and controls.
- Semantic HTML and correctly associated form labels.
- Meaningful alternative text for informative images.
- No information encoded only by colour, position or animation.
- Support zoom/reflow and reduced motion where relevant.
Use content-driven breakpoints, not a fixed list of device models.
| Large screens | Small screens |
|---|---|
| Horizontal navigation | Collapsed accessible menu |
| Multi-column dashboards | Single-column or priority-based stacking |
| Persistent filter sidebar | Drawer, sheet or collapsible filter area |
| Wide data table | Horizontal scrolling or responsive column prioritisation |
| Full logo + application name | Compact approved logo + concise application label |
:root {
/* eLTER brand */
--elter-blue: #0879C0;
--elter-dark-blue: #003972;
--elter-orange: #ED9632;
--elter-green: #40907A;
--elter-light-green: #96CE58;
--elter-light-blue: #BADFFD;
/* surfaces */
--elter-bg-light: #F0F0F5;
--elter-bg-dark: #0A2033;
--elter-surface: #FFFFFF;
/* application roles */
--color-header: var(--elter-dark-blue);
--color-footer: var(--elter-dark-blue);
--color-link: var(--elter-blue);
--color-primary: var(--elter-blue);
--color-accent: var(--elter-orange);
--font-heading: "Montserrat", Arial, sans-serif;
--font-body: "Helvetica Neue", Helvetica, Arial, sans-serif;
}Recommended additional token groups: spacing, radius, borders, elevation, semantic colours and z-index/elevation layers.
| Required | Recommended | Application-specific |
|---|---|---|
| Official logo assets | Shared navigation behaviour | Scientific dashboards |
| Corporate palette/tokens | Buttons/forms/tables/cards | Maps and geospatial tools |
| Common header identity | Spacing and type scale | Domain-specific workflows |
| Common footer baseline | Service naming conventions | Specialist data entry |
| Accessibility baseline | Shared metadata patterns | Scientific visualisation |
Publish the design system in versioned releases. Token changes, component changes and accessibility decisions should be documented in a changelog.
- Identify a pattern repeated in at least two eLTER applications.
- Document the problem, accessibility requirements and visual behaviour.
- Prototype using existing tokens before introducing new brand variants.
- Review with application developers and eLTER communication/brand owners.
- Promote the pattern into the shared guideline/component library when stable.
The guideline is normative at the design and behaviour level, not at the framework level. React, Vue, server-rendered applications and third-party systems such as Skosmos can all conform through tokens, shell integration and equivalent accessible components.
- Brand: official logo variant used correctly; no redraw/recolour.
- Shell: header and footer follow the eLTER application family.
- Colour: dark blue = structure; blue = interaction; orange = accent.
- Typography: Montserrat headings and Helvetica Neue/compatible UI typography.
- Navigation: current location, hover and keyboard focus are clear.
- Components: primary/secondary/destructive actions have clear hierarchy.
- Forms: persistent labels, usable validation and accessible required-state handling.
- Tables: readable, sortable/filterable where needed, with explicit selection/status states.
- Maps/charts: scientific palettes chosen for data meaning rather than branding alone.
- Accessibility: keyboard, focus, contrast, semantics, zoom/reflow and alt text reviewed.
- Responsive: key tasks work at small and large widths without hidden essential controls.
- Cross-service: links to other eLTER services are clearly separated from in-app navigation.
Logo, corporate colour values and typography originate from the official visual-identity material. The common application shell and component rules consolidate recurring patterns from DAR, eLTER Vocabs and the DEIMS implementation concept. Accessibility, semantic-state separation, responsive behaviour and tokenisation are proposed normative extensions for modern eLTER RI Cyber Infrastructure web applications.
| Author | Affiliation | ORCID | |
|---|---|---|---|
| Martin Abbrent | eLTER RI | 0000-0003-1252-9107 | martin.abbrent+github.com@ufz.de |
This project is licensed under the EUPL License - see the LICENSE file for details.
This work was carried out as part of the eLTER EnRich project, funded by the European Union’s Horizon Europe Research and Innovation Programme under Grant Agreement No. 101131751.
