Offerbook allow filter by "matching my payment methods"

[rodvar]

This feature involves:

• adding a button to the filters to show only offers that match my payment methods (in other words, only show markets which I have at least one payment method configured)
• this might involve a redesign, or allowing multiple "show markets" selection options
• if this new button is selected, hamburger icon for filtering needs to be green (as it happens when selecting "with offers")
• when this new option is selected only markets with offers which the user has a payment method configured for are shown

[jigglypuff-bsq]

I am now working on this issue. The current design for this bottom sheet is outdated, so I will first update it to match what's shown here (in Figma). Then work on showing a new way to filter offers that only match user's configured payment method.

[jigglypuff-bsq]

• On the bottom sheet: Move Show Markets up and bring Sort By bottom. Because users are more likely to perform a filter than a sort since there's already a search bar when they want to lookup a specific market/currency. So it makes more sense for this to be the first option
• Show Markets should be pre-selected to be All since this is the default expected behavior when presenting data. The current options of With Offers vs All isn't as useful as being able to filter by offers users have an account for. But to ensure the user is aware everything shown by default are markets with offers, we add a text right under the search field "Markets with Offers".
• Hamburger filter icon should only turn green when Short Markets is selected as "Matching my Payment Account", as this actually performs a filter that removes records in view. Whereas Sort By simply rearranges them and I think this doesn't warrant changing the filter icon state
  
  

[rodvar]

looks good to me @jigglypuff-bsq JP, just one question since you removed the "with offers" option, shouldn't we add it as a 2nd option in the new radio button component?
@nostrbuddha what are your thoughts?

[jigglypuff-bsq]

I forgot clarify one thing as I was writing a response. This proposed bottom sheet will basically display all markets with offers by default. Eliminating the option to view markets without an offer, as I assumed this to be not a very useful filter since there isn't much to do with the absence of this data. However, if you guys already know this be used enough to justify this filter option, please let me know and I'll adjust the bottom sheet.

But on this design, if users ever wonder if their market is even available in Bisq but just without offers at a particular time, they can use the create offer flow and find it to make sure. And keep in mind the new "Markets with Offers" text under the search bar will also let the user know if something is missing, it just means there isn't an offer for it.

[rodvar]

thanks for the clarification @jigglypuff-bsq , that makes sense!

So for the absolute edge case where no market has offers the app should show something similar to what we were doing when the user taps in a market that has 0 offers (Which won't be possible anymore with this new design). -> " no offers available, be the first to create offer"

Right?

[nostrbuddha]

This proposed bottom sheet will basically display all markets with offers by default. Eliminating the option to view markets without an offer, as I assumed this to be not a very useful filter since there isn't much to do with the absence of this data.

This is good. It makes the UX less clumsy, by showing only relevant minimal content.

So for the absolute edge case where no market has offers

@rodvar I don't think that will ever happen with bisq-easy.

[jigglypuff-bsq]

Excellent point! What you are describing is called an empty state, and i found that exact screen you're talking about from Figma, shown right below.

Mine has a few tweaks to update this empty state

• The empty box image has a little bisq logo I added for fun
• Made the text less verbose with a clear message in the least words possible
• I turned the "Create Offer" button into a secondary button instead of a primary. This is because I believe users aren't coming here to create an offer, therefore it shouldn't demand the attention given by the primary button. This is just my personal style, as I like using attention grabbing elements sparingly and tactfully. But open to using primary too as it's not too critical.
• The button is also in the next larger size, bigger than the button on the first screenshot. It is standard practice to use buttons with at least 44px in height in mobile interfaces, whenever there's space of course.

[rodvar]

Excellent guys, @nostrbuddha would you like to take this one based on the above definitions?

To summarise:

1. Modify current filters to match this design. The "All" radio button always filters markets with at least 1 offer.
2. For the empty state (when the current filters ends up in a no offer situation) the app should show the design above , notice the "create offer" becomes a secondary-button design :)

Are we all good @nostrbuddha @jigglypuff-bsq ? Please comment if I missed anything - Thank you!!!

[jigglypuff-bsq]

https://design.penpot.app/#/workspace?team-id=8142f5ea-6b10-801b-8006-66b90477b9c3&file-id=7ae66c33-6ede-81e2-8006-66b668b5ec7e

^Here is the Penpot file link with these new screens for us to test Penpot.

1. You must register and request access first. Unfortunately they don't have public view-only sharing yet.
2. Use the Inspect tab on the right panel, as you select screens and elements, browse through Info and Code sub-panels

Would love to hear the developers opinion on if this is useful. Figma's paid Dev Mode may still be a better option.

[nostrbuddha]

Excellent guys, @nostrbuddha would you like to take this one based on the above definitions?

Yes. I will do this.

[rodvar]

@jigglypuff-bsq @nostrbuddha Just realised yesterday, is it worth sicne we are changing the filters design to add a "Only my offers" option to the radio buttons?

That's useful for Bisq2 market makers I guess?

Let me know your thoughts guys, If this issue is already very progressed we can create another issue to do afterwards, cheers!

[rodvar]

for the payment accounts modifications should be good to consider this feedback from Henrik:

the Account created feedback is not needed IMO, but no strong opinion when clicking the account combobox i can change the account name text, but its not updated. should be not editable if > 4 lines the text area is scrollable but not clear to user. we have enough space to let it grow. the limit of the text length (1000 characters) should then never require scroll not sure if for delete we require a confirmation? its not a critical actions here btw. we might not allow that type of account in desktop BE anymore after MS is deployed as we add bisq 1 like accounts for all supported payment methods. not sure though how we exactly apply that to BE, so atm best to stick with what we have now in 2.1.7

[nostrbuddha]

I had some issue, while associating Currency with Payment accounts. Because in bisq-mobile, we havn't replicated the PaymentAccount hierarchy of classes, as it's in bisq2.

I will go through this again and check with Henrik on best way to move forward. Like if is this the right time to implement the hierarchy of accounts class replicating bisq2 structure or if there is any middle ground and take this forward.

[rodvar]

@nostrbuddha If this gets too complex I think we can leave it for a posterior release, it was not part of the MVP anyways

you can opt for doing the minimal work to have a consistent solution of what we have leaving the room for this feature later down the road - up to you

[rodvar]

moving to the backlog as this was not part of the original MVP, let's work on it on the side to get it done for a posterior release

[rodvar]

Converting to discussion and inviting @axpoems @HenrikJannsen to decide