Design Call #19

[Zaxounette]

Date: 2021-09-23
Time: 5:00pm
Timezone: UTC
Duration: 1h
UTCTime: 2021-09-23 17:00 UTC

Agenda

Comment below to add items to the agenda.

Check your timezone

https://everytimezone.com/s/4559e8e7

Join the call

https://meet.jit.si/WeDaBestCrewEVA

Calendar invite

Subscribe to the BTCPay Server calendar. More info here.

[pavlenex]

Proposing agenda, fill free to add topics.

Agenda

• Kick starting warmup conversation around the navigation menu changes and explanation on the reasoning (Figma) @pavlenex @dstrukt
• https://github.com/btcpayserver/btcpayserver/issues/2619 @dstrukt
• LNURL and LNAddress progress @dennisreimann
• https://github.com/btcpayserver/btcpayserver/issues/2884
• https://github.com/btcpayserver/btcpayserver/discussions/2306#discussioncomment-1336629
• https://github.com/btcpayserver/btcpayserver/issues/2783

[dennisreimann]

Quick item: btcpayserver/btcpayserver#2915

Other than that it's just the LNURL UI discussion brought up on Mattermost yesterday from my side. Copying it and kukks' answers to the questions here for better overview.

LNURL setup options

Each of those options brings up questions that would need answering and to be honest, even I don't fully understand most of them.

• Is there a reason someone wouldn't want to use/activate LNURL?

  political agenda i guess. But no.

• What is classic mode and what happens if I turn it off?

  Classic mode is the current way of representing lnurl. This is LNURL1blablabla - a bech32 encoding with lnurl as the hrp with its contents being the lnurl endpoint url. There is a new proposal that changes from this to a much better format: a cleartext url but with the scheme changed to whicever lnurl protocol is being used. For example: lnurlp:kukks.btcpay.org/i/invoiceid

• I enabled LNURL, why wouldn't I want to also enable it for standard invoices?

  Because a user might be confused seeing both bolt11 AND lnurl pay payment options. When there is a bolt 11 invoice already generated, it is wasteful to provide a way to generate more invoices. That said, some of the cooler features such as lightning address, pay button and apps support will REQUIRE this to be on

• Why would one turn off BOLT11 if LNURL is used?

  Because it is wasteful to generate a bolt11 invoice and monitor that and then offer another payment method that generates even more bolt 11 invoices that need to be monitored (ln nodes are not as rock solid as we'd want to just mindlessly have them monitor thousands of bolt11 invoices) THIS CRITIQUE IS ONLY VALID FOR WHEN LAZY PAYMENTS = FALSE

• Would this only work with the internal node or possibly also a custom node?

  Nope!, As long as the connected ln node supports the featureset that's needed, you are good to use lnurl with it!

My take: I'd really like to strive for simplicity here, because I think this gets confusing really fast. We can always extend the set of options if there's a need for it, but doing so preemptively also means we have to document the questions/differences mentioned above.

[dstrukt]

Proposed Agenda (sorry planned to post way earlier, but had migrane and had to try to rest), some of these are duplicates of @pavlenex's, so we'll just move on to the others listed:

• Store Focused Views Discussion (Figma)

• Pull Payments Description (assign): https://github.com/btcpayserver/btcpayserver/issues/2625

• Improve Rescan wording:

• Refund flow:

• Discuss any actions for: https://github.com/btcpayserver/btcpayserver/pull/2804

• Updates on: https://github.com/btcpayserver/btcpayserver/pull/2878

• Total Balance Updates? https://github.com/btcpayserver/btcpayserver/discussions/2306#discussioncomment-1336629 & https://github.com/btcpayserver/btcpayserver/pull/2882

[dstrukt]

Any additional thoughts...seems pretty straightforward, but worth mentioning: https://github.com/btcpayserver/btcpayserver/discussions/2911

[Zaxounette]

Design Call N°19 notes Attendees: Rockstar, Zaxounette, Pavlenex, Dstrukt, Connor, Dennis

---

Last week we talked about empty state improvements and how we handle situations where users are new and have no store or wallet. We spoke about having a store centric idea and a pre-created store upon first setup of BTCPay Server or first user connexion.

We also discussed bringing this store centric idea to every view we have. Dstrukt presents the different approaches to these store centric views.

Discussing a pattern of swiping left/right to get access to the top menu items on mobile

• Usability, discoverability are not optimal
• And not a common pattern which will confuse users

The general direction this is going is good. One thing we're missing though is the meta hierarchy data.

• For example seeing all the invoices of all the stores in one place
  • Are we talking about the general BTCPay instance or a store in particular?
  • Could be made more clear in the UI and discussed
    • The top bar version make it easy to transition from desktop to mobile, whereas the Left column menu solution entails additional changes for mobile
    • We could think about the fact that on mobile you are less prone to upload logs, etc... and we can filter menu items based on what we can define the use-cases for mobile will be
    • Top bar can be relegated to server settings for example
  • The whole view is a dramatic change VS our current architecture
    • Need to make sure we aren't hitting walls, or defining the edge-cases
    • Where do we show this notion of "get started" guide or dashboard?

---

We discuss the invoices page being visible on a higher level that aggregates the invoices of all stores for easy retrieval and management.

• Server settings, invoices, wallets can be pushed on the top navigation bar
  • All other items are store tied or edge-case items and can be pushed down on the Left hand menu
• Ultimately when the dashboard is introduced, we could add these items to it directly
  • Can also be defined that if there is only one store, the menu items live on the Left menu, and as soon as more stores are created, the previously named items are moved to the top

---

Discussing creating a store on first connexion of a user

• No technical issues around automatic store creation

---

LNURL discussion

Kukks's PR has many areas we can talk about:

• We need to clear these options as much as possible from the end-user's view
• Each of the options are unclear even to us
• LNURL makes sense at this stage as a different payment method
• Unsure if there is a fallback to other payment methods in case of wallet incompatibility
• These options are all edge-cases
  • They make more sense in the checkout settings instead of the LN node set up view
  • In terms of usability, we should keep all of these settings together. They are tied to each other in a way
  • Main concern is that the best thing we can do to our users is to hide as much of the edge-case options as possible
• Dennis to discuss with Kukks if it makes sense to have the settings hidden as long as LN and LNURL are disabled and push them in the checkout experience settings

---

General update:

• Social icons in footer merged
• Total balance on wallet's page (lurking wife mode) being worked on
• Crowdfunding page redesign
  • No update on this from Dstrukt
  • Dennis started working on it
  • The PR is a good first step. Dennis to iterate on this tomorrow.
• Pull payments description
  • One of the things that was agreed is the addition of a description. We already have that for payment requests. Just adding a description to the editor and frontend view. Seems straightforward.
• Rescan wording
  • Dstrukt to open a PR and sync with Pav and Zax regarding wording.

---