[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[taler-docs] branch master updated: first draft of UI spec
From: |
gnunet |
Subject: |
[taler-docs] branch master updated: first draft of UI spec |
Date: |
Tue, 26 Dec 2023 21:36:46 +0100 |
This is an automated email from the git hooks/post-receive script.
sebasjm pushed a commit to branch master
in repository docs.
The following commit(s) were added to refs/heads/master by this push:
new 00e43c15 first draft of UI spec
00e43c15 is described below
commit 00e43c15cd1211cf6c1a7bb50963ab15f2ae6ee0
Author: Sebastian <sebasjm@gmail.com>
AuthorDate: Tue Dec 26 17:36:40 2023 -0300
first draft of UI spec
---
design-documents/053-wallet-ui.rst | 289 +++++++++++++++++++++++++++++++++++++
design-documents/index.rst | 1 +
2 files changed, 290 insertions(+)
diff --git a/design-documents/053-wallet-ui.rst
b/design-documents/053-wallet-ui.rst
new file mode 100644
index 00000000..5891eb37
--- /dev/null
+++ b/design-documents/053-wallet-ui.rst
@@ -0,0 +1,289 @@
+DD 53: Wallet UI Design
+#######################
+
+Summary
+=======
+
+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
+==========
+
+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
+anything new.
+Currently development of different platform specific implementation are
independent
+and every developer needs to choose the layout, texts and buttons and
navigation.
+
+Requirements
+============
+
+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.
+
+* **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
+ where should be linked.
+
+The screen MAY also have:
+
+* **Predefined assets**: every implementation should resue the same icons,
images,
+ fonts and sounds.
+
+Additionaly the document COULD defined the components of the UI. If one of this
+properties is defined in the spec the implementation must implement it. The
specification
+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
+
+* **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
+ 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
+ "at the start/end of the screen".
+
+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
+included with the difference with the main definition.
+
+Part of the screens that are reused shoud also be defined in this document as
screen.
+
+Common definition:
+ * navigation between screen should not happen if the user didn't take any
action
+
+
+Proposed Solutions
+==================
+
+List of dall screens with the defined properties
+
+cta-withdraw
+------------
+
+``Description``: this screen is used for the confirmation of a manual
withdrawal,
+bank-integrated witdrawals and exchange withdrawals.
+the success of this operation will be an increase of the balance in the wallet.
+fee, restrictions and ETA should be clear for the user.
+
+``Info``:
+ * 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
+
+``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
+
+``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``
+
+.. attention::
+ User should be able to play with the amount, not possible in the current
design
+
+cta-payment
+------------
+
+``Description``: this screen is used for the confirmation of a payment to a
merchant.
+the success of this operation will be an decrease of the balance in the wallet
+and save a ticket/invoice of the purchase.
+fee, restrictions and ETA should be clear for the user.
+
+``Info``:
+ * merchant offering the order showing the URL
+ * 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
+ * cant pay desc: if the user has enough balance but unable to use it
+ * 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
+ * get more cash: if there is not enough balance, it will be redirected to
``cta-witddraw``
+ * cancel: user will be redirected to ``balance``
+
+cta-deposit
+------------
+
+``Description``: this screen is used for the confirmation of a deposit.
+the success of this operation will be an decrease of the balance in the wallet
+and save a deposit ticket for reference.
+fee, restrictions and ETA should be clear for the user.
+
+``Info``:
+ * bank account where the money is going to
+ * table of details of the operation: use the ``operation-table-details``
screen
+
+``Actions``:
+ * confirm operation: on success will be redirected to the
``transaction-details`` screen where the detail of the current transaction will
be displayed
+ * cancel: user will be redirected to ``balance``
+
+.. attention::
+ User should be able to play with the amount, not possible in the current
design
+
+cta-peer-pull-initiate
+----------------------
+
+``Description``: this screen is used for the confirmation of the creation of
+a peer pull transaction or invoice to request money from another wallet.
+the success of this operation will not change the balance immediately in the
wallet
+and allow the user to share a taler URI to the payer.
+fee, restrictions and ETA should be clear for the user.
+
+``Info``:
+ * exchange to be used showing the URL
+ * table of details of the operation: use the ``operation-table-details``
screen
+
+``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
+
+``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``
+
+.. attention::
+ Is the invoice creation always free of charge or does the exchange have a
mechanism
+ to impose a fee to pay on creation?
+
+
+cta-peer-pull-confirm
+---------------------
+
+``Description``: this screen is used for the confirmation of the payment of
+a peer pull transaction or invoice to send money from another wallet.
+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``:
+ * exchange to be used showing the URL
+ * subject: short description of the transaction
+ * table of details of the operation: use the ``operation-table-details``
screen
+ * expiration: absolute time/date after which the invoice is not valid anymore
+
+``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
+ * get more cash: if there is not enough balance, it will be redirected to
``cta-witddraw``
+ * cancel: user will be redirected to ``balance``
+
+cta-peer-push-initiate
+----------------------
+
+``Description``: this screen is used for the confirmation of the creation of
+a peer push transaction or transfer money to another wallet.
+the success of this operation will reduce the balance immediately in the wallet
+and allow the user to share a taler URI to the receiver.
+fee, restrictions and ETA should be clear for the user.
+
+``Info``:
+ * table of details of the operation: use the ``operation-table-details``
screen
+
+``Inputs``:
+ * subject: short description of the transaction
+ * expiration: absolute time/date after which the transfer is not valid anymore
+
+``Actions``:
+ * confirm operation: on success will be redirected to the
``transaction-details`` screen where the detail of the current transaction will
be displayed
+ * cancel: user will be redirected to ``balance``
+
+cta-peer-push-confirm
+---------------------
+
+``Description``: this screen is used for the confirmation of the acceptance of
+a peer push transaction or transfer money to this wallet.
+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``:
+ * subject: short description of the payment
+ * expiration: absolute time/date after which the invoice is not valid anymore
+ * table of details of the operation: use the ``operation-table-details``
screen
+
+``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``
+
+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
+-----------------------
+
+``Description``: with the table it should be clear how much the operation will
cost,
+the initial amount and the final amount with all the items related to the
operations (like fee)
+
+``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
+as the final amount currency.
+
+Initial amount label by operation:
+
+ * payment -> Price
+ * deposit -> Send
+ * peer-pull-credit -> Invoice
+ * peer-pull-debit -> Invoice
+ * peer-push-debit -> Send
+ * peer-push-credit -> Transfer
+ * withdrawal -> Transfer
+ * refund -> Refund
+
+
+accept-tos
+----------
+
+``Description``: this screen can be use everytime that the user is going to
interact
+with an exchange. since at any moment wallet may find that ToS changed the
user needs
+to be prevented from continue before reading/accepting new rules. If possible,
this
+screen should be used inplace of other actions and hidden if not required (for
example,
+user already accepted ToS)
+
+``Inputs``:
+ * format: allow the selection of a ToS format
+ * languange: allow the selection of a languange different from system lang
+
+``Actions``:
+ * accept tos: will mark this version as accepted in wallet core and redirect
the user to the screen from where it was invoked
+ * save/print tos: will save the ToS outside of the wallet
+
+Q / A
+=====
+
diff --git a/design-documents/index.rst b/design-documents/index.rst
index b37d8860..1199b1fc 100644
--- a/design-documents/index.rst
+++ b/design-documents/index.rst
@@ -64,4 +64,5 @@ Design documents that start with "XX" are considered
deprecated.
050-libeufin-nexus.rst
051-fractional-digits.rst
052-libeufin-bank-2fa.rst
+ 053-wallet-ui.rst
999-template
--
To stop receiving notification emails like this one, please contact
gnunet@gnunet.org.
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- [taler-docs] branch master updated: first draft of UI spec,
gnunet <=