Feedback related to current LodePay redesign spec communicated as a single epic. Feedback primarily based on the below artifacts and their sublinks/subtasks:

• https://lodeone.atlassian.net/browse/CORE-1118

• https://lodeone.atlassian.net/wiki/spaces/AA4T/pages/309788687/LODEPay+Wallet

At a high level BCF suggests this saga be broken down further into the following high-level epics:

1. Rebrand the existing mobile wallet screens to ‘LodePay’ adding no new functionality whatsoever

2. Add the ‘members portal functionality’ to the rebranded LodePay Wallet in mobile-only form. At the end of this milestone there should be 1:1 feature parity between the desktop members portal and the LodePay app but all features are accessible in mobile-only form factor.

3. Implement Web Wallet by adding desktop-responsiveness to all application screens. In certain screen situations where the the design spec dictates an entirely-different design for the desktop context (rather than simple responsive design) such designs are implemented at this stage. The wallet will be accessible from a web browser from this stage as well but mobile-only functionality such as QR-code reading will be hidden from the user.

BCF suggests the milestones be tacked in 1, 2, 3 order but there is some ability to tweak that ordering.

FINAL:

General

Across the board we need a swagger doc that outlines the available APIs for retrieving data represented in the new designs that is housed within Lode’s cloud environment. In some cases the members portal API will need to perform additional actions behind the scenes in order to build the dataset that is needed to populate some of these new screens.

• Example: Recent Activity

  • Need members portal to be adding ‘activity entries’ as user’s perform actions. In some cases the wallet (or related microservices) may need to call a specific endpoint on the members portal to register an activity; we need these APIs defined and documented

  • Activity types- we need to agree on a standard set of activity types and what the display entry for that activity type looks like. Currently we have a number of sample rows that relate to things like ‘direct payment’, ‘payment sent’ and some other un-titled activities. We need to finalize the list of these activities and what their display looks like.

• Example: Buy > Purchase History

  • The VDC microservice has some ability to provide a purchase history relative to certain assets but would need to be enhanced to provide a ‘proper’ purchase history for those assets.

  • For other assets we would need new API’s for purchase history specifically things such as purchases of LODE tokens.

• Example: Buy > Lode > Bank Wire

  • We don’t support this payment method at all in the wallet today so we will need documented APIs around the bank-wire purchase process.

1. Desktop designs have a navbar at the top with a ‘search’ field, what does this search across?

2. Designs for both desktop and mobile show users having an avatar but there is no way to set/upload an avatar, what should the expectation for avatars be?

3. There is also a notifications icon on the top bar but we have no designs of it ‘expanded'. What are the notifications expected in this area? Are they expected to persist in some way?

4. There is a ‘gift icon’ in the navbar, we aren’t sure what functionality is expected of this control.

5. Support - there is a nav item for support but no designs for a support page. What is the expectation when the user clicks this button?

Components

1. Need ‘loading component’ for

   1. Full page loading (currently large circle loader in AGXPayMobile, visible on VDC screen and Gas Station screen)

   2. Process pending (currently bottom-blue indeterminate loading bar presented when user is setting up a new wallet or restoring a backed-up wallet)

2. Dropdown design will require significant additional dev work to accommodate the custom ‘dropdown style’ shown in the mockup. Additionally this type of modification of the dropdown is non-standard for many modern applications.

3. Row component- we can use rows within lists as components (swipe left or right on the row to perform an action). We use this in the transaction-history view and need a design spec for it there (and can use it in other views JFYI for design team).

4. Feedback: Warning messages look very similar to buttons

Login

1. Design is not standard responsive

2. Where does the ‘Let’s get started' view show? The wallet setup step occurs before it making it unreachable

3. Desktop: Swipe picture to navigate slide set

   1. Text overlaid on slide (and animated?)

   2. Wallet-init controls displayed using button-panels to the right of the slides

4. Mobile: Swipe picture to navigate slide set

   1. Text displayed as header/subheader at bottom of screen

   2. Wallet-init controls displayed using standard buttons below the slides

Terms of Service

1. Desktop: Terms displayed to the right of the login-slides in self-contained scrolling panel. Should scroll independently of page. Agree/Disagree buttons should be visible at all times.

2. Mobile: Terms displayed to the right of the login-slides in self-contained scrolling panel. Should scroll independently of page. Agree/Disagree buttons should be visible at all times.

3. Agree button should be disabled until user scrolls to the bottom of the TOS

4. TOS should be fetched dynamically

5. Currently there are no requirements around logging the user’s agreement to the TOS (its simply flagged in local storage)

New Wallet - Display Recovery Phrase

1. Different component displays the phrase on desktop v. mobile

New Wallet - Reenter Recovery Phrase

1. Different component displays the phrase on desktop v. mobile

2. Progress bar?

Existing Wallet - Enter Recovery Phrase

1. Should we center align form on desktop to match all other center-aligned desktop forms?

2. Progress bar?

Create Wallet - Link Lode Account on Setup

1. Why use option buttons on desktop rather than making it match mobile?

Create Wallet - Link- New account

1. Not standard responsive design

2. Desktop: “skip this step” button- artifact that should be removed?

3. What happens after you create a new account?

   1. You get an email with a confirmation code?

      1. The email has a link to automatically confirm?

   2. The app takes u to a page to enter the confirmation code?

4. What features should be disabled if the user signs up for a new account but hasn’t agreed to any of the investment contracts/TOS/etc outside of the initial TOS required in order to use the app to begin with.

Create Wallet - Link- New account enter confirmation code

1. details TBD

Create Wallet - Link - Existing Account

1. 2FA code input needs to be its own screen/experience based on if that user has 2fa enabled.

Dashboard

1. different designs for mobile and desktop, not simple responsive

2. in desktop mode, a QR code ‘address’ is shown, address will be different based on coin, which address are we showing here?

3. Dashboard shows a total sum of all assets. What do we do for assets that do not have a fiatValue datasource?

4. On desktop for >5 assets will the list just scroll horizontally or can it only be navigated using the arrows in the top right?

5. Why show masked VDC in assets list view when nothing can be done with it? Also we are no longer showing the VDC balance in assets view?

Buy

1. Why show token info modal prior to purchase? This will become redundant very fast and annoy users.

2. Different designs for mobile v desktop, not standard responsive

3. Will purchase methods be hardcoded per-asset or will it be dynamic in some way?

4. Designs show purchase flow for ‘buy LODE tokens with Silvercard’ - how do the flows for buying LODE with Silver Bullion or with Bank Wire look?

5. When purchasing tokens with a silvercard there aren’t designs to for choosing whether you are buying a new card or whether you are redeeming an existing epin.

6. There is a design for 'Add an item to deliver in exchange for Lode Tokens) but it seems to be the start of some kind of shopping cart experience? Ne`ed more info on the rest of the flow here / what happens if the user leaves mid-flow, etc.

   1. In mobile mode are the screens intended to be presented 1, 2, 3 sequentially or as-shown-in-design 1,2,3 one giant scrolling list that is dynamically updated as you perform actions in other areas of the screen?

7. What does the info icon in the top right of buy screens show?

8. Need an API for historical token price, in the case of LODE/AGX/AUX we would need the members portal to provide a special API for that data.

Assets

1. Nonstandard design for responsive layout

2. How is tx history display on desktop and mobile? Its unclear how a user chooses the asset they want to interact with on desktop.

   1. Will need members portal APIs to support ‘merged’ transaction history as represented in the design which supports pagination/loading more.

3. On mobile what happens when you press the action buttons from the main list view (ie: send, receive, buy)

4. Need an API for historical token price, in the case of LODE/AGX/AUX we would need the members portal to provide a special API for that data.

Assets - Coin Page

1. Where is history price history drawn from (what API source?)

2. What should we do for assets that have no fiat value data source

3. Assuming that tx history should remain as-is today aka ‘load more’ etc.

Gas Station

1. Not standard responsive design

2. same components can be reused on desktop/mobile but layout and routes will be different (routes… maybe)

3. Should consider GAS station for ETH?

Settings - Unlinked - FOR ALL SETTINGS SCREENS WE NEED API DOCS

1. Unlinked view not standard responsive design (although simple)

2. Showing 2FA alongside U/P is nonstandard, it needs to be a secondary step after U/P has been authenticated

Settings - Signup

1. Signup form is same component but shown in modal on desktop (why?)

2. confirmation code sent via email- same component but modal on desktop (why?)

Settings - Linked - This view is strange in the mobile v. desktop sense very different control paradigms at play

1. Profile

   1. Standard responsive form - special validators we need to know about?

2. Preferences

   1. Why is this view so dramatically different on mobile? are elements missing from desktop?

3. Account Info - these views are very different between desktop and mobile, its very jarring.

   1. Where is this on mobile?

   2. Change password screen

      1. Enhance rules UI

   3. Things like recovery phrase, wallet pin are not related to your account they can exist without a lode account at all, these should likely be in a different tab altogether.

      1. Pin change- modal on desktop, standard screen on mobile

      2. Recovery phrase - modal on desktop, standard screen on mobile

4. Investment Contracts

   1. different views for desktop v mobile (again, modal v standalone screen)

   2. What are the expectations for the various investment contracts and storing the user accepted info?

   3. What does ‘more information’ do in these views (desktop)?

Brad

1.  

   Open

   

   Which token is this qr code for? I would remove this but if this part of the design is removed it will throw the whole design off.
   
   

2. Designs show Full transaction history for Virtual cards. There is no support for this on the VDC API’s.
   
   

3. Mockups show the use of avatars but in the designs there is no method of uploading an avatar. Will also need somewhere to store avatars.
   
   

4. There are three colours of transactions , red (cancelled), orange/yellow and green. “Cancelled” is not a thing in Syscoin land, but may be in Ethereum - we would need to build all the “Cancel” functionality avaiable in Metamask for cancelling a transaction.

   Open

   

    

5. the left/right “Send Again” and “Copy Address” functionality is missing.

6. "recent activity" will need to pull from various API’s including "new affiliate" and “news” as seen in mockups. Which APIs and which events to include should be defined and listed.

7. I see "Bitcoin Support" on an older design. Confirm this has been removed.

8. "Lode" token support? Are we supporting Hyperledger tokens?

9. Buying Lode tokens with "bank wire" this will definitely not be easy. Is there a service available? Will probably need an entire development cycle just for this.

10. An older design showed no option NOT to have a LODE account, but the new design shows optional? Prefer optional.

11. Phone number,as mandatory is invasive. Current community members who JUST want to use the wallet for SYS or ETH will be very unlikely to supply their phone number.

12. There's a whole "notifications" section via email so there will need to be an smtp service that is not blacklisted

13. Network switcher is not in the designs (but should be in test mockups)

14. How are we connecting to these additional services such as password change etc.

15. “Support” is not defined at all. Does this link to an external site?

16. This section is a bit confusing because which asset we are sending is only signified by a tiny dropdown menu. It would reduce errors by having the user choose the asset before displaying the “send” form.
    
    This also has a link to gas station functionality which seems to be missing from designs. We may want to add that functionality for Ethereum (tokens) as well.
    
    This (dashboard) might be a good place to highlight the heirarchy of Ethereum and Syscoin as master chains vs tokens (agx/aux/usdc etc)

Argenis

1. Not sure if Show Recovery Phrase and Change Wallet PIN belong to this section. I think wallet-related stuff should go into its own Wallet tab.

   2. Amounts in AGX?

   3. Theres no loading state in any of the components or the views. No error state either

GDrive with all files:
https://drive.google.com/drive/folders/1bSTo1LnBusiyEzWWtMvnaUvMXQivXaYI

Dev considerations:

• Would it be wise to create a new repo? Fork? Apps are too different

• Keep angular-wallet-base strictly for wallet purposes. Even now there is stuff there that is AGXPay only. Might need to move some stuff before starting.

  • This means we'll have additional folders for services, reducers, actions, bla bla bla.

• Found an article with considerations when creating an app that is meant to run in both mobile and browser:
  https://ionicframework.com/blog/customizing-ionic-apps-for-web-mobile/

Dan

1. Button styles- there are no styles defined for the ‘click’ states of the new buttons, is that intentional?

2. For links does the hoer style make the font weight less? The seem less-visible on hover based on the components PDF

3. Affiliates Page

   1. Design is non-standard for responsive

   2. The mobile version of the ‘My Connections’ section doesn’t seem to communicate much in respect to each connection’s status as compared to the desktop view.

   3. Need API documentation for members portal to ensure that it has the endpoints+responses required to facilitate the data rendered in this view and some of the functionality expressed in this view (such as paginated ‘My Connections’

4. Reward History

   1. API docs and responses

   2. does clicking on a reward take the user anywhere?

5. News

   1. API docs and responses

   2. Seems like mostly-standard responsive design

6. News Article

   1. API docs and responses

   2. confirm responsive mobile view simply drops right sidebar

   3. ensure any HTML coming from API is properly sanitized (warn API dev team about this)

7. Support

   1. We assume there will be an API for support questions and answers? Need API docs and responses

   2. Seems like mostly standard responsive design

8. Dashboard

   1. API docs and responses

   2. different designs for mobile and desktop, not simple responsive

   3. desktop version has new sections that will require need read and WRITE apis:

      1. recent activity

   4. in desktop mode, a QR code ‘address’ is shown, address will be different based on network, which address are we showing here?

   5. Dashboard shows a total sum of all assets. What do we do for assets that do not have a fiatValue datasource?

   6. On desktop for >5 assets will the list just scroll horizontally or can it only be navigated using the arrows in the top right?

9. Buy

   1. Seems mostly standard responsive

   2. Purchase history - Why different design for rows in desktop view vs. rows in mobile view

   3. Need to create APIs to support purchase history

10. Buy Step 2 - select payment method

    1. Different designs for mobile v desktop, not standard responsive

    2. Will purchase methods be hardcoded per-asset or will it be dynamic in some way?

    3. Designs show purchase flow for ‘buy LODE tokens with Silvercard’ - how do the flows for buying LODE with Silver Bullion or with Bank Wire look?

    4. When purchasing tokens with a silvercard there aren’t designs to for choosing whether you are buying a new card or whether you are redeeming an existing epin.

    5. There is a design for 'Add an item to deliver in exchange for Lode Tokens) but it seems to be the start of some kind of shopping card experience? Need more info on the rest of the flow here.

       1. In mobile mode are the screens intended to be presented 1, 2, 3 sequentially or as-shown-in-design 1,2,3 one giant scrolling list that is dynamically updated as you perform actions in other areas of the screen?

11. VDC

    1. Mostly standard responsive design with some exceptions

    2. Why use modal for form on desktop? When buying silver forms are not wrapped in modals… #consistency

    3. Recent activity related to VDC currently has no API support, no support for transaction history etc.

12. Assets

    1. Nonstandard design for responsive layout

    2. How is tx history display on desktop? Its unclear how a user chooses the asset they want to interact with on desktop.

    3. On mobile what happens when you press the action buttons from the main list view (ie: send, receive, buy)

    4. What is ‘recent activity’ on the main asset page mobile view drawn from?

13. Assets - Coin page

    1. Where is history price history drawn from (what API source?)

    2. What should we do for assets that have no fiat value data source

14. Gas Station

    1. Not standard responsive design

    2. same components can be reused on desktop/mobile but layout and routes will be different (routes… maybe)

15. Settings - Unlinked - FOR ALL SETTINGS SCREENS WE NEED API DOCS

    1. Unlinked view not standard responsive design (although simple)

16. Settings - Signup

    1. same component but shown in modal on desktop (why?)

    2. confirmation code sent via email- same component but modal on desktop (why?)

17. Settings - Linked - This view is strange in the mobile v. desktop sense very different control paradigms at play

    1. Profile

       1. Standard responsive form - special validators we need to know about?

    2. Preferences

       1. Why is this view so dramatically different on mobile? are elements missing from desktop?

    3. Account Info

       1. Where is this on mobile?

       2. Change password screen

          1. Enhance rules UI

       3. Pin change- modal on desktop, standard screen on mobile

       4. Recovery phrase - modal on desktop, standard screen on mobile

    4. Investment Contracts

       1. different views for desktop v mobile (again, modal v standalone screen)

       2. What are the expectations for the various investment contracts and storing the user accepted info?

       3. What does ‘more information’ do in these views?