Feature Wiki

Information about planned and released features

Tabs

Mobile System Style

Page Overview

[Hide]

1 Summary

ILIAS should provide a dedicated mobile system style that adapts the interface to small touch-based viewports. It should improve readability, touch interaction, navigation, form use and content display while preserving the established functionality and visual identity of ILIAS.

The style should be selected primarily by responsive screen characteristics, not only by detected device type. This prevents unsuitable behaviour on large tablets, small tablets, foldable devices, desktop windows resized to narrow widths, and future device categories.

2 Problem Statement

A recent large-scale needs assessment, Igniting ILIAS Innovation, conducted by ILIAS.nrw shows that mobile usability is a substantial concern for ILIAS users. Smartphones are used by 63.64% of respondents and tablets by 52.79%, demonstrating that access to ILIAS on touch-based and smaller-screen devices is already a common usage scenario rather than an exceptional case.

The assessment identifies mobile usability as a high-priority issue. "Better mobile usability / mobile app" was selected by 41.78% of respondents, making it the third most requested predefined improvement. The most strongly supported mobile improvements was "Adaption of UI elements to the device" (73.79% agreement) and the third "Design elements adapted to the mobile context" (60.00%).

Open-ended responses describe common mobile problems: content and forms do not fit the viewport, controls are too small, navigation becomes more confusing, margins and interface chrome consume too much space, and some tasks such as completing surveys are difficult or impossible. Users also report that ILIAS feels cumbersome on smartphones and request an app-like experience, better overview and more reliable access.

The problem is not limited to one component. A desktop-oriented system style can make text, buttons, menus, tables, forms, object lists and interaction patterns technically available on mobile devices without making them practically usable. A dedicated mobile system style is therefore needed as a coherent presentation layer for small touch-based screens.

3 Concept

3.1 Mobile-first system style

ILIAS shall introduce a new mobile system style for small viewports. The style shall provide mobile-appropriate typography, spacing, controls, layouts and interaction patterns while retaining the same underlying ILIAS functions, permissions, content and workflows.

The feature is not intended to create a separate mobile product or reduce ILIAS to a limited mobile version. Users should still be able to complete relevant tasks, access course content and use standard objects. The system style shall instead adapt the presentation and interaction of existing functionality to the available screen space and touch input.

The mobile system style should apply to the entire user interface, including:

  • Main Bar and navigation controls
  • Slates and overlays
  • Breadcrumbs and context information
  • Course and group views
  • Repository object lists
  • Forms, settings and action areas
  • Buttons, links, icons and dropdowns
  • Tables and list-based views
  • Dashboard elements
  • Object headers and page titles
  • Notifications and status messages
  • File upload and download interfaces
  • Survey, test and exercise interactions

3.2 Responsive activation instead of device detection

The mobile system style should be activated primarily by viewport width and available layout space, rather than by browser user-agent or device detection.

Device detection alone is unsuitable because device categories do not reliably describe usable screen space:

  • Some tablets have large displays and can use the standard desktop-oriented system style effectively
  • Smaller tablets may require the mobile style
  • Smartphones differ substantially in viewport width, orientation and pixel density
  • Foldable devices can change their usable screen width during use
  • Desktop browsers can be resized to narrow windows
  • Split-screen use on tablets or notebooks can produce a mobile-sized viewport
  • Browser zoom and accessibility settings can substantially reduce available layout space

The system should therefore use responsive breakpoints and, where appropriate, container-based layout decisions. The exact breakpoints require design validation and testing; they should not be determined solely by device labels such as "phone" or "tablet".

A possible approach is:

  • Use the standard system style where sufficient horizontal space is available
  • Activate the mobile system style below a defined responsive breakpoint
  • Use intermediate responsive adaptations for medium-sized screens
  • Re-evaluate the layout when viewport size or orientation changes
  • Avoid forcing a mobile layout on a large tablet in landscape orientation if the standard layout remains clearly usable

The user should not need to manually choose between a "desktop" and "mobile" style in ordinary use. However, an optional user preference may be considered later for cases where users deliberately prefer a compact or standard presentation.

3.3 Typography and readability

The mobile system style should provide a clearly readable typographic scale designed for small screens.

This includes:

  • A base font size that is readable without requiring browser zoom
  • Responsive heading sizes that preserve hierarchy without dominating the viewport
  • Adequate line height and paragraph spacing
  • Avoidance of long line lengths where content is displayed in a wide mobile viewport
  • Sufficient contrast between text and background
  • Clear distinction between headings, labels, metadata, links and body text
  • No reliance on small text for essential functions or navigation
  • No loss of content when users enlarge text or use browser zoom

Typography should adapt to the available space. It should not simply enlarge every existing desktop text size, because large headings, extensive metadata areas and oversized interface chrome can consume too much vertical space on small screens.

3.4 Touch targets and controls

Interactive elements must be designed for touch use.

The mobile system style should provide:

  • Sufficiently large touch targets for buttons, links, tabs, checkboxes, radio buttons, disclosure controls and icon buttons
  • Sufficient spacing between adjacent interactive controls
  • Clear visual distinction between interactive and non-interactive elements
  • Larger hit areas around small icons or compact controls
  • Predictable placement of primary actions
  • Persistent or easily reachable action controls for frequently used actions
  • Reduced dependence on hover interactions
  • No essential action that requires pointer precision

A visible icon is not necessarily a sufficiently large control. The clickable area should extend beyond the icon where necessary.

Controls must remain suitable for keyboard users, screen-reader users and users with motor impairments. The mobile system style should therefore improve target size and spacing without removing focus visibility or changing semantic interaction behaviour.

3.5 Layout and use of screen space

The mobile system style should minimise non-essential interface chrome and use available screen space efficiently.

It should:

  • Reduce excessive horizontal margins and padding
  • Avoid fixed-width content areas that cause horizontal scrolling
  • Reflow content into a single-column layout where appropriate
  • Avoid side-by-side controls where their labels become unreadable or targets become too small
  • Stack action controls vertically or place them in responsive overflow patterns when space is limited
  • Keep important content, actions and feedback visible
  • Avoid large header areas that push the main task below the fold
  • Avoid excessive vertical space caused by title areas, toolbars, borders or decorative elements
  • Ensure that virtual keyboards do not obscure essential form controls or confirmation buttons
  • Work in portrait and landscape orientation

For mobile screens, the content area should be prioritised over decorative framing, broad gutters and permanently visible secondary controls.

3.6 Navigation

The mobile system style should replace the current mobile presentation of the Main Bar with a navigation pattern that is easier to understand and operate on narrow touch-based screens.

3.6.1 Mobile Main Bar

The current tab-bar presentation of the Main Bar is not well suited to mobile use. A horizontal tab bar can become crowded on small viewports, especially where it contains several entries, long labels or nested functions. Depending on the available width, labels may be truncated or entries may become difficult to distinguish. This reduces discoverability and makes it harder to understand which functions are available.

The mobile system style should therefore replace the tab-bar presentation with a familiar hamburger menu. The hamburger control should be persistently available in the mobile header and open the Main Bar in a Slate.

The Slate should display all available Main Bar entries in a clear, readable and touch-friendly structure. It should support nested entries where necessary and provide sufficient space for complete labels rather than relying on abbreviated text or icon-only navigation.

The mobile Main Bar must:

  • Use a clearly recognisable hamburger menu control with an accessible name such as Open main navigation
  • Open the navigation in a Slate or comparable overlay
  • Display all Main Bar entries available to the current user
  • Show complete and understandable labels for navigation entries
  • Support nested navigation entries through accessible expandable sections where required
  • Clearly indicate the currently active Main Bar entry
  • Provide a visible and accessible close control
  • Close with the Escape key where a keyboard is available
  • Move focus into the Slate when opened and return focus to the hamburger control when closed
  • Remain fully usable with keyboard navigation and screen readers
  • Avoid horizontal scrolling as a primary mechanism for accessing Main Bar entries
  • Preserve the existing permissions and visibility rules for Main Bar entries

3.6.2 Contextual and Hierarchical Navigation

The mobile system style should also adapt navigation elements that help users understand their current context and move through ILIAS structures.

This includes:

  • Touch-friendly breadcrumbs that remain readable and operable in narrow viewports.
  • Clear back and close controls in Slates, overlays and hierarchical views.
  • Responsive handling of long course, group and object titles.
  • Adequately sized controls for opening, collapsing or expanding navigation sections.
  • A Slate or overlay presentation for secondary and hierarchical navigation where appropriate.
  • Preservation of the current location and navigation context when users open or close navigation elements.
  • Avoidance of relying solely on small breadcrumb links for upward navigation.

The mobile system style should remain compatible with the proposed global repository navigation and course/group table of contents. These features can use mobile-appropriate Slate and expandable-tree patterns to support orientation in complex hierarchies without permanently occupying screen space.

3.7 Content lists, tables and object views

Many ILIAS views present repository objects, administrative data, results or settings in tables and lists. Desktop-oriented tables often become difficult to use on small screens.

The mobile system style should support responsive alternatives:

  • Reflow simple tables into labelled cards or stacked rows
  • Keep essential column labels associated with their values
  • Allow horizontal scrolling only where a table cannot be meaningfully transformed
  • Clearly signal scrollable tables where horizontal scrolling is unavoidable
  • Prioritise core information and primary actions
  • Collapse secondary metadata or reveal it on demand
  • Avoid placing essential actions in narrow table columns
  • Ensure that object titles wrap safely and remain selectable
  • Present repository objects as clearly separated, touch-friendly list items where appropriate

A responsive table transformation must not remove essential information, make data unavailable to screen-reader users or change the meaning of the original table.

3.8 Forms and task completion

Forms are particularly important because open-ended response feedback specifically indicates that mobile completion of forms and surveys can fail due to layout problems.

The mobile system style should ensure that forms:

  • Fit within the viewport without horizontal scrolling
  • Use full-width or sufficiently wide text inputs where appropriate
  • Provide readable labels close to their fields
  • Use clear required-field indicators and error messages
  • Keep validation feedback visible and associated with the relevant input
  • Provide appropriately sized checkboxes, radio buttons and select controls
  • Avoid placing several small fields in one row when stacking improves usability
  • Keep primary actions such as distinguishable
  • Preserve entered data when validation errors, temporary connection problems or session interruptions occur
  • Work when a mobile keyboard is open
  • Support accessible input methods and browser autofill where applicable

The mobile system style should be tested especially with surveys, test questions, exercise submissions, file uploads, booking forms and settings forms.

3.9 System style boundaries

The mobile system style should define a coherent responsive presentation layer rather than a collection of isolated CSS exceptions.

It should include:

  • Shared design tokens for spacing, font sizes, component dimensions and breakpoints
  • Mobile variants for established UI components
  • Consistent rules for headings, buttons, forms, lists, tables, overlays and navigation
  • Reusable responsive patterns for common ILIAS object views
  • Documentation for component maintainers and plugin developers

Individual object implementations should not independently introduce unrelated mobile layouts. The feature should establish system-wide guidance and reusable components to avoid inconsistent mobile behaviour between ILIAS modules.

3.10 Best-practice principles

The mobile system style should follow these principles:

  • Content first: Prioritise learning content and the current user task over decorative or secondary interface elements
  • Responsive, not device-specific: Adapt to available space and input conditions rather than assuming all phones or tablets behave alike
  • Touch first, not touch only: Optimise for touch while retaining keyboard and assistive-technology support
  • Progressive disclosure: Hide secondary details or actions until needed, but do not hide essential functions
  • One task per screen area: Avoid dense layouts that require users to distinguish many competing actions
  • Clear hierarchy: Use typography, spacing and grouping to make titles, content, actions and metadata distinguishable
  • Predictable interaction: Keep controls in consistent locations and use familiar patterns
  • No hover dependency: Ensure all important functions are available through tap, keyboard and screen-reader interaction
  • Fast perception: Avoid unnecessary animations, large assets and expensive visual effects that slow down or distract from tasks
  • Error prevention and recovery: Make status, loading, validation and submission states visible and understandable
  • Accessibility by default: Treat readable text, focus visibility, contrast, reflow and touch target size as standard requirements rather than optional improvements
  • Test real tasks: Validate the system style with actual ILIAS tasks, not only screenshots or component demonstrations

All points listed here should also be considered in the ongoing maintenance and further development of the standard system style Delos.

4 User Interface Modifications

4.1 List of Affected Views

View

Breadcrumb / Context

Modification

Global layout

All ILIAS views below the mobile breakpoint

Apply the mobile system style

Main Bar

Global navigation / Tree View

Use mobile-appropriate navigation layout, labels and touch targets

Slates and overlays

Global and object-specific Slate views

Use responsive width, spacing, focus handling and mobile-safe controls

Object header

Repository › … › Object

Reduce visual density and adapt title, metadata, actions and navigation controls

Breadcrumbs

Repository › … › Object

Ensure readable, touch-friendly, responsive path handling

Course and group view

Repository › … › Course/Group / Table of Contents

Use responsive object lists, action areas and content spacing

Repository object list

Repository › … › Container

Provide mobile-safe list layouts, object titles and actions

Dashboard

Personal Dashboard

Reflow tiles, blocks, course lists and actions

Forms

Object-specific settings and interaction forms

Stack fields, enlarge controls and preserve clear validation feedback

Tables

Results, members, administration and object-specific tables

Provide responsive table transformation or controlled horizontal scrolling

Survey and test views

Container › Survey/Test

Ensure all questions, answer controls and submission actions are usable in portrait orientation

File handling views

Upload, download, exercise submission

Use mobile-appropriate drop zones, file status and confirmation feedback

4.2 User Interface Details

The following details define the intended behaviour of the mobile system style.

4.2.1 Typography

  • Text must remain readable without mandatory browser zoom
  • Heading sizes must scale down where necessary while preserving hierarchy
  • Long titles must wrap or truncate accessibly without covering actions
  • Metadata should be visually secondary to the current title and task
  • Users must be able to enlarge text without loss of content or functionality

4.2.2 Buttons and links

  • Buttons and icon controls must provide sufficiently large touch areas
  • Primary actions should be visually distinct from secondary actions
  • Adjacent controls must have sufficient spacing
  • Labels should remain visible where they are needed to understand an action
  • Icon-only controls must have accessible names and visible affordances
  • Hover-only interaction must not be required

4.2.3 Navigation

  • Main Bar entries should adapt to the viewport without becoming cramped
  • Navigation controls must remain reachable with touch and keyboard
  • Long navigation labels must be handled responsively
  • Slates should use a mobile-appropriate size and include an obvious close control
  • Back or parent navigation must be visible in hierarchical views
  • Breadcrumbs must not be the only way to navigate upwards

4.2.4 Forms

  • Input fields, text areas and select controls should use available width effectively
  • Form controls should stack when horizontal layouts become too narrow
  • Validation messages must be visible and associated with the relevant control
  • Submission, save and cancel controls must remain easy to reach when a virtual keyboard is open
  • Required fields and status messages must remain understandable without colour alone

4.2.5 Lists and tables

  • Object lists should use touch-friendly rows with clear visual grouping
  • Object titles must remain readable and not be obscured by action controls
  • Simple tables should reflow to stacked layouts where practical
  • Complex tables may remain horizontally scrollable if transformation would impair comprehension
  • Scrollable tables must clearly communicate the possibility of horizontal scrolling
  • Essential data and actions must not be hidden beyond the visible viewport without indication

4.3 New User Interface Concepts

The Feature Request introduces a Mobile System Style as a responsive variant of the existing ILIAS system style.

It adapts existing components—such as the Main Bar, Slates, buttons, forms, object headers, lists and tables—to small touch-based viewports. It does not introduce a separate mobile application or reduce available functionality.

4.4 Technical Aspects

The feature affects the ILIAS system-style layer and responsive variants of existing UI components. System styles define ILIAS’s visual appearance through fonts, icons, templates and CSS/SCSS.

The mobile style should use responsive breakpoints and media queries based on available viewport width rather than device detection. This supports smartphones, tablets, foldables, split-screen use and resized browser windows consistently.

It should establish shared responsive rules for typography, spacing, touch-target sizes, navigation, Slates, forms, object lists and tables. The implementation must avoid isolated CSS fixes for individual objects.

Existing data, URLs, permissions and workflows remain unchanged. Operators with customised system styles may need to adapt their skins if shared component markup or responsive style rules change.

5 Non-Functional Implications

5.1 Security

The mobile system style is primarily a presentation and interaction change. It does not introduce new permissions, authentication methods or access rights.

All existing security requirements must remain unchanged. Responsive layouts, hidden secondary controls and overflow menus must not hide security-relevant information, bypass permission checks or expose actions that are unavailable in the standard system style.

If the style introduces client-side viewport persistence or a user preference for interface mode, this must not be treated as an authorisation mechanism. Access control must continue to be enforced server-side.

5.2 Privacy

The initial implementation does not require the storage of new personal data.

The system may process temporary technical information such as viewport width, viewport height, orientation and CSS media-query results to select an appropriate layout. This information should be used locally within the user interface and should not be stored or transmitted as personal usage data.

A future optional user preference, such as “always use mobile layout” or “always use standard layout”, would constitute a stored preference associated with a user account. If such a preference is introduced, it should be documented and assessed according to the ILIAS privacy guidance.

5.3 Accessibility Implications

The mobile system style has significant accessibility implications because it changes component dimensions, responsive layouts, visibility of secondary content and navigation presentation.

The implementation must ensure that text enlargement, browser zoom and responsive reflow do not cause loss of information or functionality. Interactive elements must remain keyboard operable, have visible focus indicators and provide accessible names. Touch target size and spacing must be sufficient without reducing keyboard usability.

Responsive transformations must preserve the meaning and relationships of tables, forms, labels, headings and navigation structures. Content that is collapsed, moved into an overflow menu or revealed through a Slate must remain available to screen-reader and keyboard users.

The mobile system style should be tested with:

  • Keyboard-only interaction.
  • Screen readers.
  • Browser zoom and text enlargement.
  • Portrait and landscape orientation.
  • Small smartphones, large smartphones, small tablets and large tablets.
  • Split-screen tablet and notebook use.
  • Form-intensive tasks such as surveys, tests, settings and exercise submissions.
  • Complex repository lists, tables, Slates and navigation structures.

6 Process Information

6.1 Involved Authorities

If this request is related to multiple components, please list both authorities for all related components.

6.2 Contact

Person to be contacted in case of questions about the feature or for funding offers: Becker, Matthias [matthias.becker]

6.3 Funding

Funding status and funding parties are listed in the block 'Status of Feature' in the right column of this page.

If you are interested to give funding for this feature, please get into contact with the person mentioned above as 'Contact'.

7 Discussion

8 Implementation

Feature has been implemented by {Please add related profile link of this person}

8.1 Description and Screenshots

{ Description of the final implementation and the changed behaviour in the related components. Please add screenshots to visualise the changes if possible. }

8.2 Test Cases

Test cases completed at {date} by {user}

  • {Test case number linked to Testrail} : {test case title}

8.3 Privacy

Information in privacy.md of component: updated at {date} by {user} | no change required

8.4 Approval

Approved at {date} by {user}.

Full Screen

Last edited: 17. Sep 2026, 13:50, Becker, Matthias [matthias.becker]