[bisq-network/projects] Implement new-user-onboarding and new UI design (#47)

Thu Jan 28 03:09:02 CET 2021

> _This is a Bisq Network project. Please familiarize yourself with the [project management process](https://bisq.wiki/Project_management)._

## Description
@pedromvpg created a while back a great new design including new-user-onboarding: 
https://xd.adobe.com/view/a83c2327-4730-4ec2-8938-e318b2749588-fd6f/ (not a finished version but should give a good impression)

For too long we did not manage to get that implemented. To boost that I contacted a few JavaFX experts to see if we can find a UI developer to get that done as well to have a long term committed dedicated UI expert in our team. I had a call now with a promising candidate and I would like to start an iterative process to get the work started. He is available from march on, so we should get our parts ready over the next weeks.

As the scope of the whole project is rather large and hard to estimate I cannot provide a meaningful estimation of costs. 
It requires more discussion how we can manage and structure the work so that it meets the goal to get deliveries in an iterative process. My below suggestings are meant to get the ball rolling and any improvements are very welcome!

The UI developer is new to Bitcoin and the DAO model is a bit too new for him to feel comfortable with. To not make that a barrier I will offer to prefund his work so he will work as sub-contractor for myself and I will do the compensation requests for him (if anybody else want to play that role please get in touch). Mid/long term he should fade into the normal DAO contributor model. I also made clear that we are looking for a long term commitment and even if there might not be enough work for a fulltime UI developer that he stay committed for at least 10-20 hours so we can rely on a longterm UI/UX expert. 

## Rationale
New users get a bit lost with the concept of Bisq and the involved complexity. To make it easier for new users @pedromvpg created a new-user-onboarding design where users are guided throught the first steps. 
The larger redesign improves the look and feel of the app and improves also the trade related areas, so it should lead to be better user experience for traders.
By applying a new design we intend also to rewrite the UI code base, as that got too much technical debt over time. Also with the API we have a secondary "client" and some code should be moved our from the desktop module to a new presentation module which can be shared by the API code base.    

## Criteria for delivery
We will approach an iterative delivery plan. Goal is to get short term deliveries (about 1 month) which can be rolled out. See below for more details.

## Measures of success
Hard to measure as development of revenue has many factors including external ones (BTC bull market vs. bear market). We could make some survey to find out if users liked the changes.

## Risks
There are several risks which should be limited by the iterative rollout plan. There is the risk of introducing new bugs and that the project gets stalled for whatever reason. Below I suggest some alternative paths in case the integration effort or code rewrite effort would be too high.

## Tasks
- [ ] Get onboarding design ready for implementation
- [ ] Evaluate suggested iterative delivery plan
- [ ] Figure out how many screen would require adoption with left navigation layout and how to solve the issues
- [ ] Get estimations for first tasks from UI dev

## Estimates
It is very hard to estimate but I think it wil be in the range of 30000 - 60000 USD. If we get to the higher limit we need to adjust our delivery plan (e.g. reduce scope of code re-write, disitribute some integration work to existing Bisq devs,...) 

## Delivery plan

To limit risks I suggest following delivery plan.

### Optional research project: Performance test app to see if FXML should be used or not
>From my experince FXML has some overhead specially for the XML parsing which leads to some noticable delay. If the UI dev has strong arguments for using FXML I would like to see a performance comparision using a test project where the same UI screens are implemented in FXML and in plain Java. If it turns out the performance difference is not critical we can use FXML otherwise not. There should be several views in a similar conext as used in Bisq (e.g. tabs) and some heavy content with different components to get some realistic simulation. I think parsing results are cached so difference might be visible only at first screen changes. 
As stated this is optional if the UI dev prefers FXML to be sure to not suffer performance loss. If we decide against FXML I would prefer to get rid completely of FXML and not even use it for the base containers as it is used now.
As all the following work depends on that decision to use FXML or not we should do that in the very beginning.

### Click dummy for new-user-onboarding
This is a JavaFx standalone application implementing the design and styling (light and dark mode) with all user interactivity using mock data (random data similar to real Bisq data). There is no domain knowledge about Bisq and the Bisq code base needed. One open challenge is how we deal with the payment method screens. There are a lot of payment methods. An area which will need a bit more discussion how to deal with it. 

### Integrate new-user-onboarding
Integrate the click dummy for new-user-onboarding into Bisq. Once integrated this will be released as the first user facing delivery. 

### Click dummy for new menu structure and layout
Like above an independent app implementing the design in dark mode style (light mode is not included in first version but should be considered for later). The content area can be filled with placeholders.

### Integrate new menu structure and layout
Integrate the new menu structure and layout into Bisq. Reuse or create a new persistable navigation framework. 
Apply all content into the new content container. This will likely require some adjustment as the available width will be smaller with the new design as the menu is on the left side. In case that some views cannot be adjusted without degrading usability too much we need to consider to implement those views with the new design as well. This package is a bit hard to estimate and delivery time will depend on the complexity and effort to get an acceptable solution without getting too far with implemting the new designs of the other content views.
Once an acceptable solution is implemented it gets rolled out in a release.

### Click dummy for create-offer and take-offer views
Same as above, independent design-only implementation. We should get a bit deeper here into user interaction and add the validation model as well. Currently we use a dynamic validation where on focus out the validation gets triggered. This has some issues as it is not always obvious to the user that focus out will re-evaluate validation state. Also there are quite some complexity in those views which lead to some weird behaviour/bugs. A more simple model would be to triggger validation only when clicking the action button. Has to be discussed and evaluated which validation concept we will use.

 ### Integrate create-offer and take-offer views 
Integrate create-offer and take-offer views into Bisq. This will be one of the more challenging tasks as that area carries most of the more complex domain logic. It also requires to move much of the validation, formatting, calculation code to a new presentation module so it is available for re-use for API or potential other new applications (e.g. mobile?).

 ### Continue with all other views
If a click dummy is needed for the remaining views can be decided later. Goal is to get one view completed and then move to the next one. At each release we include what is ready to get shipped. We should start with the views which the traders use most (wallet, portfolio, market,...). As the DAO is a kind of sub-application we can leave that to the end. Maybe the new design will find also a different solution to not include the DAO as main menue item but as something different (no concrete idea yet, but I think it is not perfect as it is now). 

 ### Misc
There are some other areas like loading screen, windows/popups, notifications,... which need to be considered as well.

With that iterative deployment plan we can limit the risks in case the project gets stalled for whatever reason to have at least part of our goal delivered. Alternatively if it turns out the effort for integration and/or effort for rewrite is too high we could limit the tasks for the UI dev to implementing the click dummies only and an existing Bisq dev who is already familiar with the code base can work on the integration. Code rewrite can be considered optional in that scenario as well (though it is a clear goal).

## Team
As the new UI dev is new to Bitcoin and to Bisq (as well as trading domain) we need some domain experts to guide the project.
It would be great if @pedromvpg and @ripcurlx can be a main lead for getting the UX right.
If @pazza83 would be available as trade domain expert would be great as well.
I can be available for dev related support and dev onboarding.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/bisq-network/projects/issues/47
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.bisq.network/pipermail/bisq-github/attachments/20210127/7cd5f761/attachment-0001.htm>