Device-specific designs

ADITO supports device-specific client variants for the following device types:

• Desktop
• Tablet
• Mobile

These variants also affect interaction patterns and layout behavior, especially for touch-oriented usage on tablets and phones.

Several ADITO models, for example Contexts and ViewTemplates, provide a devices property. Use this property to control on which device types a specific model should be available.

How device-specific designs work

ADITO determines a client variant based on the detected device and browser environment. In practice, this means the result is not controlled by screen size alone.

In particular, larger tablets often identify themselves with a desktop-like user agent. In such cases, the browser can open the desktop variant although a tablet-specific layout would be expected.

Supported browser environments

The following browser environments are supported for the available client variants:

Client variant	Operating system	Supported browser
Desktop	Windows 10 / 11	Google Chrome or Microsoft Edge in the latest available version
Desktop	macOS	Safari in the latest available version
Tablet	iPadOS	Safari in the latest available version
Tablet	Android	Google Chrome in the latest available version
Mobile	iOS	Safari in the latest available version
Mobile	Android	Google Chrome in the latest available version

On Apple platforms, the HTML rendering engine is part of the operating system. For that reason, the latest available operating-system version is required as well.

On Android, device-specific differences between manufacturers and device types cannot be fully accounted for.

Recommended orientation

At the moment, the supported orientation strategy is intentionally fixed:

Device type	Recommended orientation
Desktop	No fixed orientation
Tablet	Landscape
Mobile	Portrait

This recommendation exists because many current ADITO user interfaces were not designed or tested comprehensively in alternative orientations. On some devices, especially Android tablets with wide-screen formats such as 16:9, alternative orientations can lead to layout or usability issues.

On devices with more square aspect ratios, for example some iPads with 4:3 displays, these issues may be less visible. Even there, however, the recommended orientation remains the safer choice.

Manifest orientation and operating system behavior

ADITO provides dedicated manifests for the three client variants. Their orientation values are currently configured as follows:

Manifest	Orientation
manifest_desktop	portrait
manifest_tablet	landscape
manifest_mobile	portrait

These manifest settings should be understood as a preference, not as a guarantee. Some operating systems or browsers ignore or override the manifest orientation. This has repeatedly been observed on certain tablets, for example on iPads, where the operating system can take precedence over the manifest.

If a device does not honor the expected orientation, first check whether the orientation can be configured at the operating-system level.

When a tablet opens the desktop variant

If a tablet opens the desktop client instead of the tablet variant, the most common reason is the browser identification. Many tablet browsers use a desktop-like user agent by default, especially on larger tablets. In such cases, ADITO can classify the browser as desktop.

If the browser provides a setting to request the tablet or mobile site, enable that setting first. The exact location of this option depends on the browser and operating system.

On iPads, prefer Safari's built-in site-view selection instead of forcing a client variant through the URL. In Safari, this option is available from the two A symbols in the address bar.

If no such option is available, or if you need a reliable test setup, use the URL-based override described below.

Forcing a client variant through the URL

For demonstration and testing purposes, you can open a specific client variant explicitly through the corresponding client route:

• /desktop
• /tablet
• /mobile

Examples:

• https://your-system.example/desktop
• https://your-system.example/tablet
• https://your-system.example/mobile

This is useful when:

• a tablet opens the desktop variant because of its user agent,
• you want to verify a tablet or mobile layout on a desktop browser,
• or you need to reproduce a device-specific issue reliably.

When a client variant is forced through one of these routes, the selection is applied before login and persisted in a cookie. After that, even the regular /client URL continues to use the forced variant instead of the automatic detection.

To leave a previously forced client variant, open the auto route once, for example https://your-system.example/auto. Technically, this removes the cookie that stores the forced client variant. Depending on the current browser session, the automatic detection can take effect only after a new login, a fresh page load, or a new browser session.

warning

Do not use /tablet as a permanent workaround on physical tablets, especially on iPads. Prefer the browser's own site-view setting whenever it is available.

Testing in a desktop browser

To test the mobile-specific design in Google Chrome or Microsoft Edge, use the mobile route together with the browser's device simulation. The route forces the ADITO client variant, while the device simulation provides a narrower, touch-oriented viewport that is closer to real mobile usage:

1. Log out.
2. Close the browser tab in which ADITO was running.
3. Open the system URL with the suffix /mobile, for example https://your-system.example/mobile.
4. Press F12.
5. In the developer tools: Select the three-dot menu and choose Dock side → Undock. Select Toggle Device Toolbar.
6. Press F11.

To test the tablet-specific design, follow the same steps but use /tablet instead of /mobile.

To leave the browser's full-screen and device-simulation mode, press F11 and F12 again.

If you also want to return to ADITO's automatic client detection, open the auto route once, for example https://your-system.example/auto, so that the forced client selection cookie is removed.

note

In most cases, the mechanism works reliably. In some situations, however, browsers request pages before the manually changed URL is fully submitted. If the behavior still looks inconsistent, close the browser completely, open it again, and start with the auto route. If necessary, delete the site's cookies or log in again. This resets the behavior to the default state.

Current limitations

The current device-specific variants should not be interpreted as a fully responsive design system. Today, they are a pragmatic combination of device-specific layouts, touch-oriented behavior, and orientation assumptions.

Long term, the better goal is a more responsive client that adapts more gracefully across devices, aspect ratios, and accessibility needs. Until that work is available more broadly, follow the recommended orientations above when rolling out tablet or mobile usage in productive environments.