diff options
Diffstat (limited to 'design-documents/053-wallet-ui.rst')
| -rw-r--r-- | design-documents/053-wallet-ui.rst | 57 |
1 files changed, 19 insertions, 38 deletions
diff --git a/design-documents/053-wallet-ui.rst b/design-documents/053-wallet-ui.rst index 5891eb37..5b5ba22d 100644 --- a/design-documents/053-wallet-ui.rst +++ b/design-documents/053-wallet-ui.rst @@ -4,7 +4,7 @@ DD 53: Wallet UI Design Summary ======= -This document proposes designs wallet UI. It defines what Android, iOS and +This document proposes designs wallet UI. It defines what Android, iOS and WebExtension should follow in order to have a coherent UI between platforms. Motivation @@ -12,8 +12,8 @@ Motivation We want user to be able to help each others independent of the implementation they are using. -We want user to be able to capitalize the effort of learning how to use one -wallet and be able to use a different one without the need to learn +We want user to be able to capitalize the effort of learning how to use one +wallet and be able to use a different one without the need to learn anything new. Currently development of different platform specific implementation are independent and every developer needs to choose the layout, texts and buttons and navigation. @@ -25,7 +25,7 @@ Every screen MUST be defined in a document with the following information: * **Identifiable UI screens**: every UI should have an unique identifier that will be use for development discussion and bug reports. There should be an option - in the application to enable an active rendering of the id. + in the application to enable an active rendering of the id. * **Description**: the reason to be of the screen, should help to define what will be included into, what is going to left for other screens and when and from @@ -41,24 +41,24 @@ properties is defined in the spec the implementation must implement it. The spec should be minimal to achieve the objective in the description. * **Info**: Spec of information that the user should have access. The type of info - could be a field (id and value) or a banner (information and instructions). - The spec will help to reuse the text for i18n across apps and defined + could be a field (id and value) or a banner (information and instructions). + The spec will help to reuse the text for i18n across apps and defined * **Inputs**: Spec of information need to provide in current screen. The type of input, range of values and validation should be defined if necessary. -* **Actions**: Spec of buttons and interactable elements that will have a significant +* **Actions**: Spec of buttons and interactable elements that will have a significant change in the current state. It should also mention navigation when applicable. - + * **Layout**: Spec position of elements when needed. The spec should be "soft" in a sense - that elements should be easy to find following directions like "close to X" or + that elements should be easy to find following directions like "close to X" or "at the start/end of the screen". -Screen should be defined using the most relaxed definition that are good enough to +Screen should be defined using the most relaxed definition that are good enough to be clear for the user. Platform will use this definition and adapt to the differences on the platform taking advantange of platform API and screen sizes. -When a screen have multiple uses for the same purpose, a substate section should be +When a screen have multiple uses for the same purpose, a substate section should be included with the difference with the main definition. Part of the screens that are reused shoud also be defined in this document as screen. @@ -84,11 +84,11 @@ fee, restrictions and ETA should be clear for the user. * exchange to be used showing the URL * table of details of the operation: use the ``operation-table-details`` screen * starting currency: if the exchange has the currency conversion service enabled user should be able to the details based on the wire transfer currency - * taler URI: show copy button or QR to complete the operation with another device + * taler URI: show copy button or QR to complete the operation with another device ``Inputs``: * age restriction: allow the selection of the restriction in the age group possible by the exchange - * service provider: allow the selection of different exchange + * service provider: allow the selection of different exchange ``Actions``: * confirm operation: on success will be redirected to the ``transaction-details`` screen where the detail of the current transaction will be displayed @@ -111,10 +111,10 @@ fee, restrictions and ETA should be clear for the user. * order summary * table of details of the operation: use the ``operation-table-details`` screen * receipt: order id - * payment deadline: absolute time before the claimed order expires - * taler URI: show copy button or QR to complete the operation with another device + * payment deadline: absolute time before the claimed order expires + * taler URI: show copy button or QR to complete the operation with another device * cant pay desc: if the user has enough balance but unable to use it - * payment status: if the + * payment status: if the ``Actions``: * confirm operation: if the payment is possible, on success will be redirected to the ``transaction-details`` screen where the detail of the current transaction will be displayed @@ -156,7 +156,7 @@ fee, restrictions and ETA should be clear for the user. ``Inputs``: * subject: short description of the transaction * expiration: absolute time/date after which the invoice is not valid anymore - * service provider: allow the selection of different exchange + * service provider: allow the selection of different exchange ``Actions``: * confirm operation: on success will be redirected to the ``transaction-details`` screen where the detail of the current transaction will be displayed @@ -225,24 +225,6 @@ fee, restrictions and ETA should be clear for the user. * review and confirm ToS: if the current selected exchange has a version of ToS that the user didn't yet accepted, use the ``accept-tos`` screen * cancel: user will be redirected to ``balance`` -cta-reward ------------ - -``Description``: this screen is used for the confirmation of the acceptance of -a reward from a merchant. -the success of this operation will be an will decrease the balance in the wallet. -fee, restrictions and ETA should be clear for the user. - -``Info``: - * amount: effective amount to receive - * exchange: from where this money comes from - * merchant: offering the reward - -``Actions``: - * confirm operation: on success will be redirected to the ``transaction-details`` screen where the detail of the current transaction will be displayed - * review and confirm ToS: if the current selected exchange has a version of ToS that the user didn't yet accepted, use the ``accept-tos`` screen - * cancel: user will be redirected to ``balance`` - operation-table-details ----------------------- @@ -252,12 +234,12 @@ the initial amount and the final amount with all the items related to the operat ``labels``: initial amount of the operation, and final amount are always shown. Fee should be shown as an extra row in the table if it is non-zero. -Converted amount should be shown as an extra row if initial amount currency is not the same +Converted amount should be shown as an extra row if initial amount currency is not the same as the final amount currency. Initial amount label by operation: - * payment -> Price + * payment -> Price * deposit -> Send * peer-pull-credit -> Invoice * peer-pull-debit -> Invoice @@ -286,4 +268,3 @@ user already accepted ToS) Q / A ===== - |