To access a mini program user's device and user information, mini programs must obtain the user's permission. This document contains design guidelines for developers and designers to create a user-friendly journey for users to authorize mini programs to access the following types of information:

• Device information
• User information

A popup message will be displayed when the mini program requires a user's permission.

Device information

Device information includes the resources on user's devices, such as the current location, camera, microphone, photos, Bluetooth, and contacts. For device information, the following JSAPIs are available in the container for mini programs to call:

• my.getLocation
• my.chooseImage
• my.saveImage
• my.scan
• my.getOpenUserInfo

For more information, see Developing Mini Programs > References > JSAPIs > Device > Settings.

User information

User information includes a user's personal information, such as mobile phone number, basic information, wallet member information, points, coupons, and so on. For user information, the wallet app either implements or develops the corresponding APIs to be called for permission.

In some cases, user terms also need to be displayed and users need to agree with the terms for mini programs to access user information.

Design principles

Use the following principles as guidelines to design the user flow for requesting permissions:

• Request permissions only when your mini program requires resources

We do not suggest to request for permissions at the launch of the mini program, or request all permissions together at one time. However, if users must agree with user terms before using your mini program, you must display the terms when users enter your mini program for the first time.

• Display clear choices for users to make

Buttons must clearly distinguish the choices for users to make. The primary button is Allow and the secondary button is Don't Allow. It is not suggested to use Cancel as the secondary button because users will be confused about whether the permission is granted or not.

• Explain the resources to be accessed specifically

Provide texts to explain the resources to be accessed clearly. For example, display the user's mobile phone number to be accessed and the source of the number, or list the personal user information to be accessed.

• Guide users to reverse the decision to grant permission

If the user denies permission requests, you can explain the benefits of granting permissions in related scenarios and provide a link to where the user can reverse the decision.

Applicable scenarios

The following illustrate how these design principles can be applied.

Granting permissions is required

In this scenario, the user cannot enjoy the service provided by the mini program without granting permissions. To ensure that the user understands this, we suggest redirecting the user back to the previous page if the user clicks Don't Allow. When the user wants to use the same service, display the bottom sheet component requesting the permission again till the user grants the permission.

Granting permissions is not required

While granting permissions allows the user to have a smoother mini program experience, it is sometimes not necessary for the user to use certain mini program functions. For example, if a user grants the mini program permission to access the current location, the user would not have to manually input the address to use the function. When the user uses the same service in future, the bottom sheet component is displayed again to request the permission.

Options to ignore permission request or reverse decision

When granting the permission is not required, you can add the selection of Do not ask again. If the user checks the selection, the same permission request is not displayed again when the user does the same action within the mini program. However, if permissions are required for certain actions within the mini program, display the bottom sheet component to request the permission and guide the user to where the permission can be reversed.

Request permissions to link the wallet and merchant accounts

If a user has used a wallet app to sign up for a merchant mini program account, such as with an email address or phone number, the mini program can guide the user to link the mini program account with the wallet account.

Component and samples

Permissions requests are communicated to users via a bottom sheet component displayed at the bottom of the screen.

Bottom sheet

Bottom sheet is a UI component that slides from the bottom of the screen when the user makes a specific action. On the bottom sheet, the user can start a new task, make a choice, or confirm the to-do action. The bottom sheet component is significantly less disruptive than the popup modal, which appears in the middle of the screen.

The bottom sheet used to request for permissions consists of three parts:

• Mini program name: A right arrow is placed on the right of the mini program name to indicate that the mini program name is a link. The mini program name is linked to the About Us page.
• Requested resources: All requested resources and icons are listed clearly.
• Buttons: Display two opposite choices for users to make, such as Allow and Don't Allow.

As the mini program must request permissions each time the user uses the mini program, we suggest adding the Remember my choice selection so that users will not be prompted again.

Samples

Permission requests for resources on the user's mobile device

Permission requests for the user device include the access to contacts, photos, current location, microphone, Bluetooth, and so on. See the following UI samples for details.

Permission requests for the user information

User information includes the user's account, avatar, phone number, and so on. When accessing the user information, comply with the following rules:

• Explain the source of the information if required. For example, the phone number is retrieved from the phone's address book.
• Provide a button to allow users to change the information if required. For example, when accessing the user account or phone number, provide an option for the user to use another account or phone number.
• Provide a link to the terms for users as a reference.

See the following UI samples for details.

Use case

Vodapay, a digital wallet, cooperates with more merchants in the form of third-party mini programs. When users use the merchant mini program in the Vodapay wallet app for the first time, the merchant mini program requests all required permissions so that users can enjoy services provided by the mini program. At the same time, users must sign the terms provided by the merchant before using the mini program.