BUG | NOT A BUG BUT UX SUGGESTIONS

Hi Samus

As discussed , here are my considerations regarding the current Sparta UX and some suggestions for improvement

All to try to make SPARTA the best platform for (passive) income streams on Binance

ongoing work...and open for ideas/suggestions Sparta Protocol Testnet V2.1 4_10_2021 UX suggestions .pdf

i hope the screenshots are good enough, else let me know...

talk soon Sonos21

Reading thru it now thanks @Sonos21 but as I said before these are mostly suggestions that are already planned for later phases and/or not the priority yet. Will add any agreeable ones that are priority now/soon to GitHub issues list to make this a bit more manageable for the distributed contributors. Thanks again for taking the time to do this; it will definitely help shape what gets built 👍

Have added the 'menu' issue to GitHub; this menu behaviour/style was only intended for these earlier phases; we had a full double-component menu for different device types (similar to what you want) initially in DAppV2 but ripped all of that out for the BUIDl stages as it makes more sense to build something to the smaller devices first and add the nicer extended versions in after. We were finding that building two different versions of everything was getting in the way of contributors willing to work on the DApp. Check the issue #562 to see screenshots of the intended design/behaviour of the menu for desktop/larger screens

As per the menu options/labels it's important to take into account the future/intended structure of the dapp and why some of those choices were made, however have made an issue to change:

'Overview' to 'Pools' as that's clearly a pool listing page; makes more sense. When (or 'if'; maybe we pivot) this page becomes the user dashboard we can reassess then, but for now i totally agree; this should be 'Pools' or something like that. EDIT: ADDED #563
'Liquidity' we should keep as 'Liquidity' that's important
'Swap' is fine as you said
'Synths' is fine/correct. You don't have a 'synths position' per se so no need to add/change anything there. And in my opinion, we shouldn't move 'Vaults' before 'Synths'; it's the logical flow of user-interactivity. ie. The user needs to obtain synths before they can stake them in the vault. However I've been thinking maybe to move 'Liquidity' just before 'Vaults' so that's an option relevant to your suggestions on menu-order.
'Vault' we will change to 'Vaults' that's a good point. Totally agree that 'Staking' will be a lot more commonly known and trigger less questions from the community, but we want people to ask the questions, people need to go 'whats that' as we don't want them thinking they are performing the usual staking that they are used to elsewhere, these vaults have a lot of nuances and we don't want people just blindly staking without finding out what they are doing and how it differs to what they are doing elsewhere. Having said all that, the plan is obviously to have these 'differences' and helpful educational pieces of knowledge in tooltips and easy bite-sized areas throughout the dapp to have the best of both worlds. EDIT: ADDED #563
'Bond' is fine in my opinion; don't forget the DApp is not by any means complete; it might be confusing not to have a button to actually perform a bond in there yet, but it's all a part of the longer-term plan, will try at least add the CTA button there and/or a tooltip or some info in the next week or so. Its position in the menu is fine in my opinion; it's in the same category as the Vaults; in fact, it is literally a BondVault so the question might be; why not move it into the Vaults page? I'll open a discussion GitHub issue around that as I'm at least on the fence to that idea and could lean in either direction 😆, might be something to it 👍 EDIT: ADDED #565
'Positions' is already going to be in the menu but not for your BondVault holdings as such; that's the next major feature. In V1 this was the way people could assess whether they were up/down and by how much etc; this is a very big job and will have its own page in the menu called 'Positions' so let's save that label for that more well-known and expected content for 'Positions'

Sorry for the long spiel; this is why I take a while to get around to things, I try to always take the time to explain instead of just saying 'yes' or 'no' 😄 hopefully you understand the above? If not, please do comment on Github issue #563 so we can hash it out and come to a consensus as a distributed group; the above is mainly just my opinions and I'm only one person!

'POOLS' Page This page is very far from the intended design; this is actually meant to be a user dashboard to perform all the user's functions and/or navigate the dapp. However that's not really priority until later on so for now its just one small piece of that intended design 😆 chance why it makes little sense to call it 'Overview' or 'DashBoard' as you mentioned. As i mentioned above; this will be changed to 'Pools', it was a good suggestion and one that was already on the minds of a lot of us.

Also whilst this page has changed a lot since you did up your PDF; it's still not anywhere near what it will be eventually; at some point when it moves up the priority list ill create an issue on this and pop up the screenshots of the mockups so you can see the intended 'pools' design is very similar to your mockups (for non-mobile users obviously) sorry buddy, i maybe should have sent some of the mockups before you spent time on them but i wasn't aware you were going to do full mockups of pages that we already have sorted!

Overview/Liquidity Pools

I'm pretty firm on the 'Curated' being extremely important to badge on the respective pools. Curated pools are the protocol, the normal pools are just standard AMM swap facilitators
It brings up a point to maybe put the 'Curated' badge in the areas of the DApp that are only relevant to the Curated pools though so that user's can associate 'Curated' between certain pools and features of the DApp even if they don't take the time to read the tooltips or info or docs (or ask) as we all know will be the case with the majority 😆 would you agree with this? EDIT: ADDED #564

Vaults

I know where you are coming from and agree in a sense; but i don't really agree here; people generally do care what vault the assets are in (they made this clear in v1 and in community discussions over the past 6 months around v2) and even if they didn't; they should. It affects a great many things. We want people to ask questions where there is the danger of making a mistake because the UX makes it too easy and simple (not that that is what you are saying; but that's kind of a similar category to a broader similar point to what you are making)
I would say the issue here isn't a structure issue; it's an 'incomplete DApp' issue (a lot of content is still yet to roll out over the coming months, especially around tooltips and educational things)
It's important the Vaults are separated not only from a user perspective but also (less importantly) from a code structure perspective; we are talking about 12 different contracts here calling 100s of different variables every second from the blockchain. We need to be careful not to put everything on one screen and have 10000s of calls instead of the siloed calls structure that you might notice throughout. I'll say though that infra costs, client memory usage and the structured codebase is a lower priority than user experience though so this is more of just an extra perspective point to highlight other things we have to consider

Mockups

In your next section you go over some great mockups; again thank you for that they are great.
It's very similar in structure to what was created for us in Figma and I can see you ran thru what you consider to be important to the user and built it around that which is clear.
Even though we already have existing mockups to work towards later on, your mockups will also help a lot, as they are based around the 'current DApp' rather than the 'proposed DApp' so it brings in another perspective; will definitely be referenced alongside the others when extending the interface for non-mobile devices on that overview/dashboard/pools page

Bonds

I might skip this topic as i think you have the wrong idea about what 'Bond' is (further solidifies the need to continue focus on documentation to make this knowledge more palatable)
I'll touch however on the 2nd parts of your comments:
You mentioned doing a Bond allocation right now instead of waiting for pool depth - Bond as a program is managed by the DAO; we need a distributed DAO before getting the DAO to start making decisions otherwise a couple of whales will be directing the protocol instead of the intended good DAO. So whilst its true also that pools need depth for the actual underlying Bond logic to work properly without too much slippage; the bigger issue is enabling the DAO too soon. So we will have to wait a bit for that, also Bond is quite complex, it makes sense to let the basic protocol have some time to attune itself before locking people into a Bond for 6 months
Also you mentioned doing some kind of a custom Bond program. Trust me I've been over that side many times suggesting similar things but we have to be careful when it comes to smart contracts. Remember these are smart contracts; we have built contracts (and had them put thru CodeArena) for a purpose; we shouldn't risk the protocol by creating some smaller one-time contracts now, it adds risk and takes contribution focus hands away from the wheel in the car they are already driving if you know what i mean?
Again though; trust me i know exactly what you are talking about and made suggestions like this even back in V1 Bond, i was quite adamant and had to learn the hard way about the smart contracts by literally cracking down and learning Solidity as much as i could between then and now to truly understand the things I was requesting (which seem simple on the surface) could present a lot of risks

Vaults/Staking

I know where you are coming from (with combining staking positions) and have discussed it many times in the past; as i mentioned earlier; my opinion now if firmly in the 'separate the staking/vaults sections'. Main reason (which is enough for me) is that each Vault is a vastly different thing to one-another and they should be treated as such.
Withdrawing/depositing/harvesting/etc all have completely different behaviours that are specific to the 'type' of vault and therefore when explained; should be done so in a vault scope
Restaking or 'compounding' is a cool idea; have touched on it in the past a fair bit, the problem is again similar to 'Bond' you are talking about adding features to the Smart Contracts that don't have comile room for anything extra, and importantly it adds a lot of risk when adding complexity to the smart contracts. Worth noting though that the SynthVault (because its not at it's compile limit and there was room for some extra complexity) actually does 'compound' or 're-stake' by default, but it depends if the caps are full or not etc, so once again; more nuance and more reason to keep the Vaults separate!

Positions Page

As i mentioned above, this is already a part of the plan; it's one of the major features of the DApp so it won't get left behind don't worry!

History Page

The plan in the next phase of the recent transactions component is to move it from the 'Footer' to the wallet modal in the future (under a history or recent txns tab)
I think you would agree as a user if you were looking for your wallet history you would probably click the wallet icon first so you probably agree with that? EDIT: ADDED (see comment touching on moving the recent txns component) https://github.com/spartan-protocol/SpartanProtocol-DAppV2/issues/542#issuecomment-933966263

Dashboard Panel

Agreed; would be great to finally see some of this history-based analytics front and centre; this task is slated to most likely be after the positions page is done and the work is done getting the dapp extended to the non-mobile screen sizes is done as we cant just pull this kind of data off the blockchain, some custom API work will be required and more infra costs and more importantly time expenditure. Most likely the same data source as what will be used for the Positions page will be used for this

Again; thanks a million for your work on this; a lot of that document will be used over the next few months to help shape things and don't let my robotic replies disguise my appreciation (I'm a robot 😆)

WOW Samus,

thanks a lot for this extensive answer!!

reminds me a lot about the technical discussions i tend to have with my developers. shows me, the Sparta infrastructure is thoroughly set up and constructed. ( but i already knew that :-) )

in fact that is "my frustration"... I know and have the feeling there is so much more into Sparta then is shown right now in the UX , so the user has "no idea he is driving in one of the top sport cars, but instead thinks he is drinving a normal city car..."

the comments i see in the TG channel, confirm this feeling and even your answers , for example the fact you say that "vaults are so much more than staking" but how do I know this as an end user...without going to visit a library and ask for the most technical description on Sparta Vaults...

LESS IS MORE and right now what is see happening in the Sparta UX is the opposite...it is becoming more cluttered everyday

have a look at the different Luna based products this week their new DEX , $LOOP, became available.... have a look compare it with the swap part within Sparta from a user perspective it is sooooo much cleaner and easier to use...

and have a look at Mirror ..their synths part within Sparta and all their other protocols this is all front end stuff!!! so you can and still should use the great Sparta backend..

Sparta can position itself as 1 integrated platform

but it has to make a big step towards the user!!

let me know if i can help with that and how to do so, without taking to much of your valuable time

keep up the good work!

we are sparta!

ciao reinoud

btw did you notice the font i used in the interface was......the Sparta font

spartan-protocol / SpartanProtocol-DAppV2

BUG | NOT A BUG BUT UX SUGGESTIONS #551