Documentation
UI guidelines
Messages and advanced signing

Messages and advanced signing

In the Transaction page, you’ve seen how to design transactions with fields that are properly parsed and formatted by your app for clear signing. In this chapter, you’ll see how to adapt the design of your operations when you have less control over the data to sign.

Message prompt and signature

The transaction structure presented in the previous page holds for message signing. Provide as much as information as possible to your users on the message prompt and the message signing screens.

When messages lack information about their type, structure, or network, the prompt and signature screens must follow this presentation:

App architecture

When there are no guarantees on the blockchain or the network used, you can use the generic “message” pictogram shown above instead of your app icon.

Adapting navigation

The navigation bars at the top of the screen adapt to the number of pages required to review all message fields:

  • if there are 6 pages or less (including the final signing screen), bars must be used;
  • if there are more than 6 pages, a numbering system is used.

App architecture

In some cases, it may be impossible for your app to display a number of pages because the length may be unknown or non-computable. In these cases, simply remove the progress indicators.

In some cases, it may be impossible for your app to provide backwards navigation, such as when transaction data is streamed to Ledger Stax. In that case, hide remove the back arrow in the top-left to let your users know that navigation is one-way.

App architecture

Progressive disclosure of unbounded data

When signing messages with uncontrolled structure and contents, you’ll often encounter data that is too big to fit in one field, yet alone in one page.

In some cases, you can hide the contents of a field behind an interaction to use progressive disclosure. This is useful to let your users go faster to signing, while still providing a preview of the field contents.

When the user taps on the “More” button, a modal containing the entirety of the field opens. If the field spans over several pages, navigation arrows appear at the bottom:

App architecture

⚠️

Use progressive disclosure with care.

  • - Don’t hide several fields under an interaction.
  • - Don’t use progressive disclosure on a field with data affecting your user’s privacy, security, or funds.

Skipping messages of unknown length

In some cases, the transaction or message data is streamed to Ledger Stax from the client wallet because it’s too long to be held in the device memory at once. This is the case for EIP191 and EIP712 signing in the Ethereum app, for example.

For your users, this can have the following implications:

  • they cannot navigate backwards through transaction data;
  • they may have to review a lot of pages before reaching signing;
  • they can’t measure their progress if page indicators are missing.

In this case, use a “Skip” option to give your users a shortcut to access the signing page:

App architecture

On tapping the “Skip” button, users are prompted for confirmation in a modal. This helps against accidental taps, as well as educating users over skipping information to review:

App architecture

Tapping on “Yes, skip” brings the user directly to the signing screen. From here, they won’t be able to navigate backwards.

Tapping on “Go back to review” brings the user to the review of the currently loaded data: they’re back to the same state they were before tapping the “Skip” button.

Key Takeaways

💡
  • - Cleary distinguish message signin from transaction signing to let your users know they should pay extra attention.
  • - Simplify signing flows by showing a compact form of very long fields, when it’s safe to do so.
  • - Browse Ledger’s examples of advanced signing design for reference.
Ledger
Copyright © Ledger SAS. All rights reserved. Ledger, Ledger Nano S, Ledger Vault, Bolos are registered trademarks of Ledger SAS